From 6f4d371691d1d8fa784e9c5ad83ad5be45f7904f Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Thu, 27 Jan 2022 11:38:20 +0100 Subject: [PATCH 001/203] Added EM and APM base_classes and MPES, EM, APM, Ellips application definitions --- applications/NXapm.nxdl.xml | 490 +++++++++++++++++++++++++++ applications/NXellipsometry.nxdl.xml | 396 ++++++++++++++++++++++ applications/NXem.nxdl.xml | 278 +++++++++++++++ applications/NXem_edxs.nxdl.xml | 439 ++++++++++++++++++++++++ applications/NXem_nion.nxdl.xml | 380 +++++++++++++++++++++ applications/NXmpes.nxdl.xml | 233 +++++++++++++ base_classes/NXcorrector_cs.nxdl.xml | 27 ++ base_classes/NXfib.nxdl.xml | 53 +++ base_classes/NXion.nxdl.xml | 32 ++ base_classes/NXlens_apm.nxdl.xml | 26 ++ base_classes/NXlens_em.nxdl.xml | 33 ++ base_classes/NXpeak.nxdl.xml | 35 ++ base_classes/NXpulser_apm.nxdl.xml | 70 ++++ base_classes/NXscanbox_em.nxdl.xml | 48 +++ base_classes/NXstage_lab.nxdl.xml | 41 +++ 15 files changed, 2581 insertions(+) create mode 100644 applications/NXapm.nxdl.xml create mode 100644 applications/NXellipsometry.nxdl.xml create mode 100644 applications/NXem.nxdl.xml create mode 100644 applications/NXem_edxs.nxdl.xml create mode 100644 applications/NXem_nion.nxdl.xml create mode 100644 applications/NXmpes.nxdl.xml create mode 100644 base_classes/NXcorrector_cs.nxdl.xml create mode 100644 base_classes/NXfib.nxdl.xml create mode 100644 base_classes/NXion.nxdl.xml create mode 100644 base_classes/NXlens_apm.nxdl.xml create mode 100644 base_classes/NXlens_em.nxdl.xml create mode 100644 base_classes/NXpeak.nxdl.xml create mode 100644 base_classes/NXpulser_apm.nxdl.xml create mode 100644 base_classes/NXscanbox_em.nxdl.xml create mode 100644 base_classes/NXstage_lab.nxdl.xml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml new file mode 100644 index 0000000000..9e49f3098d --- /dev/null +++ b/applications/NXapm.nxdl.xml @@ -0,0 +1,490 @@ + + + + Draft application definition for atom probe tomography and related field-ion microscopy, all summarized as atom probe microscopy experiments. + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + + Official NeXus NXDL schema to which this entry conforms. + + Version specifier which enables documentation of modifications to the schema. + + + + Ideally, a (globally persistent) unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. + + + Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in prose into this field. + + + ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant - this start time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and interpretation of the experiment. The user should be aware that even with having both time instances specified it may not be advisable to infer how long the experiment took or for how long data were acquired. More detailed timing data over the course of the experiment have to be collected. + + + ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended. + + + Commercial or otherwise given name to the program that was used to acquire/measure the dataset. Atom probe microscopy experiments are nowadays still in most cases controlled via commercial software. These are often designed as integrated acquisition and instrument control software. For AMETEK/Cameca local electrode atom probe (LEAP) instruments the least processed (rawest) numerical results and metadata are stored in so-called RHIT and HITS files, which are proprietary. Supplementary metadata are kept in a database which is connected to the control software. RHIT and HITS are proprietary binary file formats whose content must not be accessed with software other than of AMETEK (IVAS/AP Suite). In effect, RHIT and HITS store the experiment in a closed manner that is practically useless for users unless they have access to the commercial software. To arrive at a state that atom probe microscopy delivers a dataset with which one can study reconstructed atomic position and do e.g. composition analyses or other post-processing analysis tasks, these raw data have to be processed. Therefore, it is necessary that for an application definition to be useful details about the physical acquisition of the raw data and all its processing steps have to be stored to arrive at derived quantities like ion hit positions (on the detector), calibrated time-of-flight data, and from these results obtain calibrated mass-to-charge-state ratios, and finally the tomographically reconstructed atomic positions. In many cases cases, an APM dataset is useful only if it gets post-processed via so-called ranging. Ranging defines a set of rules how to map between time-of-flight and mass-to-charge data on ion types with which in turn one can decode elemental identities and resolve isotopes. All these steps are in most cases performed using commercial software. Frequently, though, ranging and post-processing is also performed with (open-source) research software. Therefore, there is strictly speaking not a single program used in atom probe to arrive at a useful reconstructed and ranged dataset. Hence, the reason to design the application definition with the acquisition and key post-processing steps. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is numerically recreatable in the same deterministic manner. + + + + Not the specimen name or the experiment identifier but the identifier through which the experiment is referred to in the control software. For LEAP instruments it is recommended to use the IVAS/AP Suite run number. For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, or the instruments in Rouen, use the identifier that is closest in meaning to the LEAP run number. As a destructive microscopy method, a run can be performed only once. It is possible, however, to interrupt a run and restart, still all using the same specimen. In this case, each evaporation run needs to be distinguished with different run numbers. # This is how most atom probe groups handle it across the globe. + + + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip archive ...). + + + A small image that is representative of the entry. For reconstructed datasets it is recommended to display the reconstruction as a 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories. + + + + What type of atom probe microscope experiment is performed. This field can be used e.g. by materials database systems to qualitatively filter experiments. + + + + + + + + + Contact information of at least the user of the instrument who measured this specimen or the principal investigator who performed this experiment. Adding multiple users if relevant is recommended. + + Given (first) name and surname of the user. + + + Name of the affiliation of the user at the point in time when the experiment was performed. + + + Postal address of the affiliation. + + + Email address of the user at the point in time when the experiment was performed. Given the most permanently used email is recommended. + + + Globally unique identifier of the user as offers by services like ORCID or Researcher ID. + + + (Business) (tele)phone number of the user at the point in time when the experiment was performed. + + + Which role does the user have in the place, and at the point in time when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principal investigator, guest ...). + + + + + Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen on e.g. the microtip array was taken. The user is advised to store the details how specimens were cut/prepared from samples in the sample history. + + + Ideally, a reference to the location of or a (globally persistent) unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. + + + ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these temporal details in the sample_history. + + + Possibility to give an abbreviation of the specimen name field. + + + Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus considered relevant from a scientific point. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history. + + + + Hard link to a location/locations in the hierarchy of the NeXus file where the data for default plotting are stored. + + + Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. An atom probe microscope (experiment) is different compared to a large-scale facility accelerator or an electron microscope in at least two ways. First, ionized atoms and molecular ion(s fragments) (in the case of atom probe tomography) and (primarily) imaging gas ions (in the case of field ion microscopy) are accelerated towards a position-sensitive and time-of-flight taking detector system. Hence, there is no real probe/beam. Second, the specimen is the lens of an atom probe microscope. Therefore, the reference coordinate system that is usually referred to in NeXus (McStas coordinate system) is modified when using this application definition. Specifically, the reference coordinate system is defined such that it represents the specimen coordinate system. To be consistent with accelerator and microscopy techniques we define that the positive z-axis points outwards from the apex of the specimen into the vacuum, i.e. towards the detector. The coordinate system remains/is a right-handed one. Clockwise rotations are considered positive rotations. + + Given name of the microscope, e.g Raptor, Oxcart, One atom at a time. + + + Geographic coordinates of the lab or the place where the instrument is installed using GEOREF geocodes ideally. + + + Manufacturer of the entire instrument (e.g. AMETEK/Cameca) to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model and instrument_capabilities. + + + Manufacturer brand/model to enable e.g. queries about microscope models (e.g. LEAP3000XS). + + + Hardware name/serial number or hash identifier given by the manufacturer to identify the instrument. + + + Free-text list possibly multiple terms of functionalities which the instrument provides. + + + The space inside the atom probe that ions pass through when they leave the specimen and travel to the detector. + + + + + + + + + + + + An (ideally globally persistent) unique identifier, link, or text which gives further details. + + + + + Details about the detector which is used to collect raw time-of-flight data and ion/hit impact positions. + + Description of the detector type. Specify if the detector is not the usual type of delay-line detectors. + + + + + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Affine transformation which aligns the Cartesian right-handed coordinate system which defines the detector space with the specimen space. In atom probe microscopy a frequently used choice is to discuss the so-called detector space image (stack). This is a stack of two-dimensional histograms of detected ions within a predefined evaporation ID interval. Typically, the set of ion evaporation sequence IDs is grouped into chunks. For each chunk a histogram of the ion hit positions on the detector is computed. This leaves the possibility for inconsistency between the so-called detector coordinate system and a specimen-affixed coordinate system. The transformation here resolves this ambiguity by specifying how the positive z-axes of either coordinate systems can be oriented. + + + Amplitude of the signal detected on the multi-channel plate (MCP). This field should be used for storing the signal amplitude quantity of within historic the ATO-formatted files. The ATO file format is used primarily by the atom probe groups in Rouen, France. + + + + + + + + + + + + + + + Given name. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. base temperature, during the measurement. + + + + The majority of atom probe microscopes come from a single commercial manufacturer AMETEK (formerly Cameca). Their instruments are controlled via an(/a set) of integrated instrument control system(s) (APSuite/IVAS/DAVis). By contrast, instruments which were built by individual research groups such as of the French (GPM, Rouen, France), the Schmitz (Inspico, Stuttgart, Germany), the Felfer (Oxcart, Erlangen, Germany), or the PNNL group (Pacific Northwest National Laborary, Portland, Oregon, U.S.) have individual solutions to control the instrument. Some of which are modularized and open, some of which realize also integrated control units with portions of eventually undisclosed source code and (so far) lacking (support of)/open APIs. Currently, the is no community-specific API for getting finely granularized access to such control settings. This motivates the current design of the application definition via an NXcollection. Holding heterogeneous, not yet standardized but relevant pieces of information is the purpose of this collection. + + Track time-dependent settings over the course of the measurement about the environment in the analysis chamber such as gas pressure values etc. + + Average pressure in the analysis chamber. + + + + + A place where details about the initial shape of the specimen can be stored. Ideally, here also data about the shape evolution of the specimen can be stored. There are currently few techniques to measure the shape evolution: One is via correlative electron microscopy but this usually evolves an interrupted experiment in which the specimen is transferred, an image taken, and a new evaporation sequence initiated. Another, less accurate method, though, is to monitor the specimen evolution via the in-built camera system (if available) in the instrument. Another method is to use correlated scanning force microscopy methods (pioneered by the imec group, Belgium). A continuous monitoring of the specimen in an correlative electron microscopy/atom probe experiment is planned to be developed by the Jülich group. + + Ideally measured or best elaborated guess of the initial radius of the specimen. + + + Ideally measured or best elaborated guess of the shank angle. This is a measure of the specimen taper. Define it in such a way that the base of the specimen is modelled as a conical frustrum so that the shank angle is the (shortest) angle between the specimen space z-axis and a vector on the lateral surface of the cone. + + + + This group in the hierarchy should be used to store the ion hit positions. Data post-processing step of analog-to-digital conversion of the detector signals into ion hit positions. For AMETEK LEAP instruments this processing takes place partly in the control unit of the detector and is instructed and monitored/supervised by the acquisition/instrument control software (IVAS/APSuite/DAVis). The exact details are, at least in the case of AMETEK instruments (the large majority of installations worldwide) kept proprietary and inaccessible. For instruments like Oxcart individual timing data from the delay-line detector are open and thus community software can be used to decode these data into ion impact positions. + + Symbols used in the schema to specify e.g. dimensions of arrays. + + + + Given name of the program that was used to perform this computation. Although, for LEAP from AMETEK this is often the same software as one would specify under program_name for the NXentry (usually IVAS or AP Suite), the field is required because in cases where data are post-processed with different software inconsistencies can occur. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Three-dimensional array of raw readings from the analog-to-digital-converter timing circuits of the detector wires. + + + + + + + + Evaluated ion impact coordinates at the detector (either as computed from the arrival time pairs or as reported as the result of a not further specified processing from commercial control software). + + + + + + + Average detection rate over the course of the experiment. + + + + Data post-processing step which is, like the impact position analyses also usually executed in the integrated control software. This processing yields how many ions where detected during the pulse as it is possible that multiple ions evaporate and hit the same detector pixel, which forms the foundation to analyses of the so-called multiplicity of the ion. Multiplicity must not be confused with how many atoms of the same element or isotope, respectively, built a molecular ion. + + Given name of the program that was used to perform this computation. Similar comments as to ion_impact_positions apply. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Number of pulses since the last detected ion pulse. For multi-hit records, after the first record, this is zero. + + + + + + Hit multiplicity. + + + + + + Number of pulses since the start of the atom probe run/evaporation sequence. + + + + + + + Like impact position and hit multiplicity computation ion filtering and are data post-processing steps for identifying which of the detected ions should be included in the voltage-and-bowl correction. + + Given name of the program that was used to perform this computation. Similar comments as to hit_multiplicity apply. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Bitmask which is set to true if the ion is considered and false otherwise. + + + + + + + Data post-processing step to correct for ion impact position flight path differences, detector biases, and nonlinearities. Also this step is usually performed with commercial software. + + Given name of the program that was used to perform this computation. Similar comments as to ion_filtering apply. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Raw time-of-flight data as read-out from the acquisition software if these are available. + + + + + + Calibrated time-of-flight. + + + + + + The key idea and algorithm of the voltage-and-bowl correction is qualitatively similar for instruments of different manufacturers or research groups but different specific calibration models exists. In the first draft of the application definition we do not wish to resolve or generalize these differences. Rather the purpose of this collection is to provide a container where model specific parameters and calibration models can be stored if users know these for sure. For AMETEK LEAP systems this should be the place for storing initial calibration values. These values are accessible normally only by AMETEK service engineers and used by them for calibrating for the detector and instrument. Furthermore, one could then also store here the iteratively identified calibrations which scientists will get displayed in e.g. AP Suite while executing the voltage-and-bowl correction as part of the reconstruction pipeline. + + + + Data post-processing step in which calibrated time-of-flight data (tof) are interpreted into mass-to-charge state ratios. + + Given name of the program that was used to perform this computation. Similar comments as voltage_and_bowl_correction apply. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Like for the voltage-and-bowl correction this collection should be used for storing vendor-specific calibration models if available. + + + Mass-to-charge-state ratios + + + + + + + Data post-processing step to create a tomographic reconstruction of the specimen based on selected calibrated ion hit positions, the evaporation sequence, and voltage curve data. Very often scientists use own software scripts according to published, so-called reconstruction protocols, i.e. numerical recipes how to compute x, y, z atomic positions. + + Given name of the program that was used to perform this computation. Similar comments as voltage_and_bowl_correction apply. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Qualitative statement about which algorithmic approach, i.e. reconstruction protocol was used. + + + + + + + + + + + + Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space. + + + + + + + Different models and associated algorithms, i.e. (numerical) protocols exist to reconstruct atom probe data. Although these approaches are qualitatively similar, each protocol uses different parameters (and interprets these differently). The source code to IVAS/APSuite is not open. For now we store the reconstruction parameter in a collection. + + + + Data post-processing step in which elemental, isotopic, and/or molecular identities are assigned to the ions. The documentation of these steps is based on ideas described in the literature (M. K"uhbach et al. 2021, Microsc. Microanal.). + + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step there have been a number of open-source tools been designed for this task. Therefore, it is essential to document which tool was used. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + How many ion types are distinguished + + + Assumed maximum value that suffices to store all relevant molecular ions even the most complicated ones. Usually a value of 32 suffices well. + + + Specifies the computation of the mass-to-charge histogram. Usually mass-to-charge values are studied as an ensemble quantity and binned so document here settings related to (eventual) binning. + + Given name of the program that was used to perform this binning. If the computation is a integrated into the ranging tool, type . + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type . + + + + Smallest and largest mass-to-charge value. + + + + + + Binning width + + + + Details of the background model which was used to correct the total counts per bin into used counts. + + Given name of the program that was used to perform the background quantification. If the computation is a integrated into the ranging tool, type . + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type . + + + + + How where peaks in the background-corrected mass-to-charge histogram identified. + + Given name of the program that was used to search and detect peaks. If the computation is a integrated into the ranging tool type . + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type . + + + + List of peaks. + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + + + + + + + + + + + + + + + + + + Placeholder for additional details and mathematical models used. + + + + + Details about how peaks, with taking into account error models, were interpreted as an iontype or not. + + Given name of the program that was used to perform identify peaks. If the computation is a integrated into the ranging tool, type . + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type . + + + + The individual ions and their set of mass-to-charge intervals (ranges). If ranging was performed as a computational step then the NeXus-writing software needs to assure that there is always a default ion type which is the unknown ion type. By definition this unknown type has 0 as the id and a default associated mass-to-charge-state ratio interval of [0, 0.001] Da. + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml new file mode 100644 index 0000000000..386639c8ef --- /dev/null +++ b/applications/NXellipsometry.nxdl.xml @@ -0,0 +1,396 @@ + + + + Draft application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. + + Variables used throughout the document, e.g. dimensions and important parameters + + + + + + + + This is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. + +The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description + + Unique identifier of the experiment, such as a (globally persistent) unique identifier. - The identifier is usually defined by the facility or principle investigator. - The identifier enables to link experiments to e.g. proposals. + + + + + Commercial or otherwise defined given name to the program that was used to generate the results file(s) with measured data and metadata (or a link to the instrument software). + + Either version with build number, commit hash, or description of a (online) repository where the source code of the program and build instructions can be found so that the program can be configured in such a way that result files can be created ideally in a deterministic manner. + + + Website of the software. + + + + FAIRmat-specific candidate proposal for an application definition exemplifying ellipsometry. For example: https://gitlab.mpcdf.mpg.de/nomad-lab/areab-appdef/-/blob/spectroscopic-ellipsometry-consolidation/optical_spectroscopy + + Ideally version with build number are commit hash of the application definition. If not available a free-text description. + + + URL where to find further material (documentation, examples) relevant to the application definition + + + + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. + + + Name of the affiliation of the user at the point in time when the experiment was performed. + + + + + + + + General properties of the ellipsometry equipment + + The name of the instrument + + The used version of the hardware if available. If not a commercial instrument use date of completion of the hardware. + + + + Name of the company which build the instrument + + + ISO8601 date when the instrument was constructed + + + Name (e.g. commercial) of the software that was used for the measurement + + Version and build number or commit hash of the software source code + + + Website of the software. + + + + Specify the used light source. Multiple selection possible. + + + + + + + + + + + If you specified 'other' as light source type, please write down what it is. + + + Were focussing probes (lenses) used or not? + + + Were the recorded data corrected by the window effects of the lenses or not? + + + Specify the angular spread caused by the focussing probes + + + What type of ellipsometry was used? See Fujiwara Table 4.2 + + + + + + + + + + + + + + + + + Ellipsometers require regular calibration to adjust the hardware parameters for proper zero values and background light compensation. + + ISO8601 datum when calibration was last performed before this measurement + + + Arrays which provide the measured calibration data. Multiple sets are possible, e.g. Psi and delta measured on an e.g. silicon calibration waver, and the straight-through data. We recommend to provide data that is measured under the same settings as the measurement was performed, that is if Psi and delta are measured for your data, also provide Psi and delta here. And use the same wavelenghts as there. + + What data was recorded for the calibration, The number of variables (N_variables) have to be set to the number of provided data columns accordingly, e.g. psi/delta -> N_variables= 2, Jones vector: N_variables = 4, Mueller martix -> N_variables= 16, etc. + + + + + + + + + + angle(s) of incidence used during the calibration measurement (excluding straight through mode) + + + + + + The wavelength or equivalent values (which are inter-convertible). The importer should convert all to one unit, and make the others accessible. Historically, energy is used in eV, but for visible spectroscopy wavelength is more common, for IR wave numbers in 1/cm units. +Possibly use the same type of data as for the measurement! + + + + + + Calibration is performed on a reference surface (usually silicon wafer with well defined oxide layer) at a number of angles, then in a straight through mode (transmission in air). + + + + + + + + + Free-text to describe which sample was used for calibration, e.g. silicon wafer with 25 nm thermal oxide layer. + + + + Incident angle of the beam vs. the normal of the bottom reflective (substrate) surface in the sample + + + + + + Sample stage, holding the sample at a specific position in X,Y,Z (Cartesian) coordinate system and at an orientation defined by three Euler angles (alpha, beta, gamma). The stage may be motorized or manual, special for liquids or gas environment. + + + + + + + + + + The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). +This transformation brings us from the NEXUS coordinates to the stage coordinates. +Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) +Last, provide the rotations of the sample + + If there is no motorized stage, we should at least qualify where the beam hits the sample and in what direction the sample stands in a free-text description, e.g. 'center of sample, long edge parallel to plane of incidence'. + + + + + For environmental measurements, the environment (liquid, vapor etc.) is enclosed in a cell, which has windows both in the direction of the source and the detector (looking from the sample). These windows also add a phase shift to the light altering the measured signal. This shift has to be corrected based on measuring a known sample in the environmental cell. + + the material of the window + + + Thickness of the window + + + Angle of the window normal (outer) vs. the substrate normal (similar to the angle of incidence). + + + Recorded data that can be used to calculate the window effect. Typically this is the substrate (e.g. silicon with thermal oxide layer) in air without window and in a known medium with the window. + + What sample was used to estimate the window effect. + + + Use the same wavelengths at which all other measurements are recorded + + + + + + Recorded data of a reference surface with and without window / medium. + + + + + + + + + + + Which type of detector was used, and what is known about it? A detector can be a photomultiplier (PMT), a CCD in a camera, an array in a spectrometer. If so, the whole detector unit goes in here. + + What kind of detector module is used, e.g. CCD-spectrometer, CCD camera, PMT, photodiode, etc. + + + + + + + + + + + If you specified 'other' as detector type, please write down what it is. + + + Integration time for the measurement. Single number or array if it was varied. + + + Define how many rotations of the rotating element were taken into account per spectrum. + + + Define which elements rotates, e.g. polarizer or analyzer. + + + + + + + + + rotation rate, if the revolution does not change during the measurement. + + + Specify maximum and minimum values for the revolution. + + + + + + + + Properties of the sample, its history, the sample environment and experimental conditions (e.g. surrounding medium, temperature, pressure etc.), along with the data (data type, wavelength array, measured data). + + Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus relevant from a scientific point. The purpose of this field is to allow materials database to parse the relevant elements without having to interpret the sample history or other fields. + + + + Ideally, a reference to the location or a unique (globally persistent) identifier (e.g.) of e.g. another file which gives as many as possible details of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample is not available, use this field as a free-text description to specify details of the sample and its preparation. + + + ISO 8601 date with time zone specified. + + + Qualitative description of the layer structure for the sample. For example: Si/native oxide/thermal oxide/polymer/peptide + + + A identifier to correlate data to the experimental conditions, if several were used in this measurement; typically an index of 0 - N + + + Select which type of data was recorded, for example Psi and Delta (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It is possible to have multiple selections. Data types may also be converted to each other, e.g. a Mueller matrix contains N,C,S data as well. This selection defines how many columns (N_variables) are stored in the data array. + + + + + + + + + + + Wavelength value(s) used for the measurement. + An array of 1 or more elements. Length defines N_wavelength + + + + + + Resulting data from the measurement, described by data type. + Minimum two columns containing Psi and delta, or for the normalized Mueller matrix, it may be 16 (or 15 if 1,1 is all 1). + + + + + + + + + + Specified uncertainties (errors) of the data described by data type. The structure is the same as for the measured data. + + + + + + + + + + An array of relative time points if a time series was recorded + + + Describe what was the medium above or around the sample. The common model is built up from substrate to the medium on the other side. Both boundaries are assumed infinite in the model. Here define the name of the material (e.g. water, air, etc.). + + + Array of pairs of complex refractive indices of the medium for every measured wavelength. Only necessary if the measurement was performed not in air, or something very well known, e.g. high purity water. Specify the complex refractive index: n + ik + + + + + + External parameters that have influenced the sample. + + + How many measurements were done varying the parameters? This forms an extra dimension beyond incident angle, time points and energy / wavelength (this is the length of the 4th dimension of the data). Defaults to 1. + + + Indicates which parameter was changed. Its definition must exist below. The specified variable has to be number_of_runs long, providing the parameters for each data set. + + + + + + + + + + + Was the sample modified using an optical source? Describe in this group the parameters of the optical excitation used. + + Specify the source for the external excitation + + + Wavelength value(s) or the range used for excitation. + In cases of continuous laser radiation a value or a set of values may do but for other illumination types, such as pulsed lasers, or lamps, a range may describe the source better. + + + Specify the FWHM of the excitation + + + CW or pulsed excitation + + + + + + + + + How long was the sample excited. + + + The integrated energy of light pulse. + + + + + Specify the voltage if the spectra were taken under bias + + + Temperature of the sample (sample holder, medium) + + + pH of medium (measured or set) + + + Pressure of the environment of the sample. + + + + What parameters are derived from the above data + + light loss due to depolarization as a value in [0-1] + + + + + A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. + + diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml new file mode 100644 index 0000000000..7ca1c69e9d --- /dev/null +++ b/applications/NXem.nxdl.xml @@ -0,0 +1,278 @@ + + + + Template for creating draft application definitions for storing data and metadata for experiments with (scanning and transmission) electron microscopy. + + + Official NeXus NXDL schema to which this entry conforms. + + Version specifier enabling to document modifications of the schema. + + + + Ideally, a (globally persistent) unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. + + + Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in prose into this field. + + + ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. + + + ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended. + + + Commercial or otherwise given name to the program which was used to acquire/measure the dataset. Electron microscopy experiments are usually controlled/performed via commercial integrated acquisition and instrument control software. In many cases, an EM dataset is useful only if gets post-processed already during the acquisition or shortly thereafter, i.e. while the scientists is still sitting at the microscope. Many of these processes are automated, if not they virtually involve GUI interactions with the control software. Examples include collecting of diffraction pattern and on-the-fly indexing of these. These situations and tools are realized with individual NXprocess groups which can hold more details and numerical data to these processing steps. Frequently, some of these NXprocess groups are performed with (open-source) research software. Therefore, there is strictly speaking not a single program used in electron microscopy, and thus each NXprocess has its own program name and description." + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is numerically recreatable in the same deterministic manner. + + + + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip archive ...). + + + A small image that is representative of the entry. This can be an image from the dataset or a thumbnail of a spectrum. Either way it is recommended to use 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories. + + + + Contact information of at least the user of the instrument who measured this specimen or the principal investigator who performed this experiment. Adding multiple users if relevant is recommended. + + Given (first) name and surname of the user. + + + Name of the affiliation of the user at the point in time when the experiment was performed. + + + Postal address of the affiliation. + + + Email address of the user at the point in time when the experiment was performed. Given the most permanently used email is recommended. + + + Globally unique identifier of the user as offers by services like ORCID or Researcher ID. + + + (Business) (tele)phone number of the user at the point in time when the experiment was performed. + + + Which role does the user have in the place, and at the point in time when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principal investigator, guest ...). + + + + + Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen was investigated and is represented by this NXentry. The user is advised to store the details how specimens were cut/prepared from samples in the sample history. + + + Ideally, a reference to the location of or a (globally persistent) unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. + + + ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these temporal details in the sample_history. + + + Possibility to give an abbreviation of the specimen name field. + + + Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus relevant from a scientific point. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history. + + + (Measured) sample thickness + + + + Hard link to a location/locations in the hierarchy of the NeXus file where the data for default plotting are stored. + + + + + + + + + Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. + + Commercial or otherwise given name to the program which was used to execute this analysis. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Remains to be discussed with colleagues which suggestions to put as enumerations. + + + + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + + Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. + + Given name of the microscope, e.g. NionHermes. + + + Geographic coordinates of the lab or the place where the instrument is installed using GEOREF geocodes ideally. + + + Manufacturer of the entire instrument to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model and instrument_capabilities. + + + Manufacturer brand/model to enable e.g. queries about microscope models. See comments on instrument_manufacturer on how to provide further specification. + + + Hardware name/serial number or hash identifier given by the manufacturer to identify the instrument. + + + Free-text list possibly multiple terms of functionalities which the instrument provides. + + + The source creating the electron beam. + + Voltage relevant to compute the energy of the electrons immediately after they left the gun. + + + Type of radiation. + + + + + + Emitter type used to create the beam. + + + + + + + + Ideally a reference to (another) file (ideally formatted using also an application definition) via a link, name, or a (globally persistent) unique identifier to give further details about the electron gun. + + + + Details to individual apertures in the instrument. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Relevant value from the control software as this is not always simply the diameter of (not even in the case) of a circular aperture. Details which choice was made should be explained under description. + + + An (ideally globally persistent) unique identifier, link, or text which gives further details. + + + Affine transformations and geometrical descriptions which detail how the aperture is placed and arranged in the microscope relative to the optical axis and beam path. + + + + Details to individual lenses in the microscope. + + + + + + + + + + + + + + + + + + Details about an eventual device which corrects spherical aberrations. + + Does the microscope have a spherical aberration correction unit and was it used? + + + + + + + + + + + + + + + + + + + + Description of the type of the detector e.g. CCD, scintillator, direct electron, image plate, CMOS. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + + + + + + + + + Free text option to write further details about the detector. + + + + + Exact definition as understood by HU colleagues remains to be communicated. + + + Exact definition as understood by HU colleagues remains to be communicated. + + + Exact definition as understood by HU colleagues and Nion remains to be communicated. + + + Details how computed needs to be confirmed by Nion. + + + + + diff --git a/applications/NXem_edxs.nxdl.xml b/applications/NXem_edxs.nxdl.xml new file mode 100644 index 0000000000..24a705e505 --- /dev/null +++ b/applications/NXem_edxs.nxdl.xml @@ -0,0 +1,439 @@ + + + + Draft application definition for storing data and metadata for scanning transmission, energy-dispersive X-ray spectroscopy experiments at the EPFL, Lausanne. User story how to use components of proposed NXem application definition and related NeXus base classes for a user of the NORTH tools. + + + Official NeXus NXDL schema to which this entry conforms. + + Version specifier enabling to document modifications of the schema. + + + + Ideally, a (globally persistent) unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. + + + Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in prose into this field. + + + ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. + + + ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended. + + + Commercial or otherwise given name to the program which was used to acquire/measure the dataset. Electron microscopy experiments are usually controlled/performed via commercial integrated acquisition and instrument control software. In many cases, an EM dataset is useful only if gets post-processed already during the acquisition or shortly thereafter, i.e. while the scientists is still sitting at the microscope. Many of these processes are automated, if not they virtually involve GUI interactions with the control software. Examples include collecting of diffraction pattern and on-the-fly indexing of these. These situations and tools are realized with individual NXprocess groups which can hold more details and numerical data to these processing steps. Frequently, some of these NXprocess groups are performed with (open-source) research software. Therefore, there is strictly speaking not a single program used in electron microscopy, and thus each NXprocess has its own program name and description." + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is numerically recreatable in the same deterministic manner. + + + + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip archive ...). + + + A small image that is representative of the entry. This can be an image from the dataset or a thumbnail of a spectrum. Either way it is recommended to use 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories. + + + + Contact information of at least the user of the instrument who measured this specimen or the principal investigator who performed this experiment. Adding multiple users if relevant is recommended. + + Given (first) name and surname of the user. + + + Name of the affiliation of the user at the point in time when the experiment was performed. + + + Postal address of the affiliation. + + + Email address of the user at the point in time when the experiment was performed. Given the most permanently used email is recommended. + + + Globally unique identifier of the user as offers by services like ORCID or Researcher ID. + + + (Business) (tele)phone number of the user at the point in time when the experiment was performed. + + + Which role does the user have in the place, and at the point in time when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principal investigator, guest ...). + + + + + + + + Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen was investigated and is represented by this NXentry. The user is advised to store the details how specimens were cut/prepared from samples in the sample history. + + + Ideally, a reference to the location of or a (globally persistent) unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. + + + ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these temporal details in the sample_history. + + + Possibility to give an abbreviation of the specimen name field. + + + Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus relevant from a scientific point. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history. + + + Density of sample. + + + + + + (Measured) sample thickness + + + + Hard link to a location/locations in the hierarchy of the NeXus file where the data for default plotting are stored. + + + + + + + + + Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. + + Commercial or otherwise given name to the program which was used to execute this analysis. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Remains to be discussed with colleagues which suggestions to put as enumerations. + + + + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + + Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. + + Given name of the microscope, e.g. NionHermes. + + + Geographic coordinates of the lab or the place where the instrument is installed using GEOREF geocodes ideally. + + + Manufacturer of the entire instrument to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model and instrument_capabilities. + + + Manufacturer brand/model to enable e.g. queries about microscope models. See comments on instrument_manufacturer on how to provide further specification. + + + Hardware name/serial number or hash identifier given by the manufacturer to identify the instrument. + + + Free-text list possibly multiple terms of functionalities which the instrument provides. + + + The source creating the electron beam. + + Voltage relevant to compute the energy of the electrons immediately after they left the gun. + + + Type of radiation. + + + + + + Emitter type used to create the beam. + + + + + + + + Ideally a reference to (another) file (ideally formatted using also an application definition) via a link, name, or a (globally persistent) unique identifier to give further details about the electron gun. + + + + Details about nominal properties of the electron beam at the locations where it enters the surface of the sample upon the measurement(s). + + (Nominal/average) probe diameter when the beam probes the sample surface. + + + Energy of the beam. + + + Current of the beam. + + + + Details to individual apertures in the instrument. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Relevant value from the control software as this is not always simply the diameter of (not even in the case) of a circular aperture. Details which choice was made should be explained under description. + + + An (ideally globally persistent) unique identifier, link, or text which gives further details. + + + Affine transformations and geometrical descriptions which detail how the aperture is placed and arranged in the microscope relative to the optical axis and beam path. + + + + Details to individual lenses in the microscope. + + + + + + + + + + + + + + + + + + Details about an eventual device which corrects spherical aberrations. + + Does the microscope have a spherical aberration correction unit and was it used? + + + + + + + + + + + + + + + + + Specific convention how the sample holder is tilted against the gun coordinate system has not been shared yet by EPFL colleagues. + + + Specific convention how the sample holder is tilted against the gun coordinate system has not been shared yet by EPFL colleagues. + + + + + + Description of the type of the detector e.g. CCD, scintillator, direct electron, image plate, CMOS. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + + + + + + + + + Free text option to write further details about the detector. + + + + + Exact definition as understood by EPFL colleagues remains to be communicated. + + + Exact definition as understood by EPFL colleagues remains to be communicated. + + + Exact definition as understood by HU colleagues and Nion remains to be communicated. + + + Details how computed needs to be confirmed by Nion. + + + + + Description of type scintillator. + + + Energy resolution, how measured?, how defined? + + + Specific convention on how they define this angle in relation to the gun coordinate system has not been shared yet by EPFL colleagues. + + + Specific convention on how they define this angle in relation to the gun coordinate system has not been shared yet by EPFL colleagues. + + + + + + + + + Container for holding numerical data which represent the set of collected EDX spectra, i.e. counts, for each position on the sample surface where an EDX spectrum was measured. The spectra have to be post-processed to identify accumulated counts which substantiate the presence of specific elements. Plotting these accumulated counts for a given element for all probed positions via post-processing yields a so-called EDX mapping. + + + + + + + The three-dimensional data stack. + + + + + + + E.g. X-ray photon counts + + + + + + + + X-ray energy + + + + + + + + Label for the x axis + + + + + + + + Label for the y axis + + + + + + + + + Container for holding an image (e.g. electron backscatter, secondary electron, or high-angle annular dark field), which resolves the pixel location at which edx_spectra where taken. + + + + + + The two-dimensional image. + + + + + + X-ray photon counts + + + + + + + + Label for the x axis + + + + + + + + Label for the y axis + + + + + + + + Details about computational steps how peaks in the EDX spectrum were indexed as atoms. + + Commercial or otherwise given name to the program which was used to execute this analysis. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Name and location of each X-ray line which was indexed as a known ion. + + Human-readable identifier to specify which concept/entity the peak identifies. + + + + + + List of the names of identified elements. + + + + + + + Container for reporting individually processed element-specific EDX mappings from the edx_spectra data cube. + + Commercial or otherwise given name to the program which was used to execute this analysis. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + + + diff --git a/applications/NXem_nion.nxdl.xml b/applications/NXem_nion.nxdl.xml new file mode 100644 index 0000000000..7b794a18ce --- /dev/null +++ b/applications/NXem_nion.nxdl.xml @@ -0,0 +1,380 @@ + + + + Template for creating draft application definitions for storing data and metadata for experiments with scanning transmission electron microscopy with a Nion instrument. + + + Official NeXus NXDL schema to which this entry conforms. + + Version specifier which enables documentation of modifications to the schema. + + + + Ideally, a (globally persistent) unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. + + + Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in prose into this field. + + + ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant - this start time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and interpretation of the experiment. The user should be aware that even with having both time instances specified it may not be advisable to infer how long the experiment took or for how long data were acquired. More detailed timing data over the course of the experiment have to be collected. + + + ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended. + + + Commercial or otherwise given name to the program which was used to acquire/measure the dataset. Electron microscopy experiments are usually controlled/performed via commercial integrated acquisition and instrument control software. In many cases, an EM dataset is useful only if gets post-processed already during the acquisition or shortly thereafter, i.e. while the scientists is still sitting at the microscope. Many of these processes are automated, if not they virtually involve GUI interactions with the control software. Examples include collecting of diffraction pattern and on-the-fly indexing of these. These situations and tools are realized with individual NXprocess groups which can hold more details and numerical data to these processing steps. Frequently, some of these NXprocess groups are performed with (open-source) research software. Therefore, there is strictly speaking not a single program used in electron microscopy, and thus each NXprocess has its own program name and description." + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is numerically recreatable in the same deterministic manner. + + + + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip archive ...). + + + A small image that is representative of the entry. This can be an image from the dataset or a thumbnail of a spectrum. Either way it is recommended to use 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories. + + + + Contact information of at least the user of the instrument who measured this specimen or the principal investigator who performed this experiment. Adding multiple users if relevant is recommended. + + Given (first) name and surname of the user. + + + Name of the affiliation of the user at the point in time when the experiment was performed. + + + Postal address of the affiliation. + + + Email address of the user at the point in time when the experiment was performed. Given the most permanently used email is recommended. + + + Globally unique identifier of the user as offers by services like ORCID or Researcher ID. + + + (Business) (tele)phone number of the user at the point in time when the experiment was performed. + + + Which role does the user have in the place, and at the point in time when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principal investigator, guest ...). + + + + + Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen was investigated and is represented by this NXentry. The user is advised to store the details how specimens were cut/prepared from samples in the sample history. + + + Ideally, a reference to the location of or a (globally persistent) unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. + + + ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these temporal details in the sample_history. + + + Possibility to give an abbreviation of the specimen name field. + + + Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus relevant from a scientific point. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history. + + + (Measured) sample thickness + + + + Hard link to a location/locations in the hierarchy of the NeXus file where the data for default plotting are stored. + + + Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. + + Given name of the microscope, e.g. NionHermes. + + + Geographic coordinates of the lab or the place where the instrument is installed using GEOREF geocodes ideally. + + + Manufacturer of the entire instrument to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model and instrument_capabilities. + + + Manufacturer brand/model to enable e.g. queries about microscope models. See comments on instrument_manufacturer on how to provide further specification. + + + Hardware name/serial number or hash identifier given by the manufacturer to identify the instrument. + + + Free-text list possibly multiple terms of functionalities which the instrument provides. + + + The source creating the electron beam. + + Voltage relevant to compute the energy of the electrons immediately after they left the gun. + + + Type of radiation. + + + + + + Emitter type used to create the beam. + + + + + + + + Ideally a reference to (another) file (ideally formatted using also an application definition) via a link, name, or a (globally persistent) unique identifier to give further details about the electron gun. + + + + Details to individual apertures in the instrument. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Relevant value from the control software as this is not always just the diameter of (not even in the case) of a circular aperture but a rather a value from a list of predefined ones in the control software. Which actual settings are behind these should be Details which choice was made should be explained under description. + + + An (ideally globally persistent) unique identifier, link, or text which gives further details. + + + Affine transformations and geometrical descriptions which detail how the aperture is placed and arranged in the microscope relative to the optical axis and beam path. + + + + Details to individual lenses in the microscope. + + Which type describes the type of the lens closest? + + + + + + + + + + + + + + + + + Details about an eventual device which corrects spherical aberrations. + + Does the microscope have a spherical aberration correction unit and was it used? + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Stage tilt A. Exact definition as understood by HU colleagues remains to be communicated. + + + Stage tilt B. Exact definition as understood by HU colleagues remains to be communicated. + + + StageOutX, Y, Z. Exact definition as understood by HU colleagues remains to be communicated. + + + + + + + + + Description of the type of the detector e.g. CCD, scintillator, direct electron, image plate, CMOS. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + + + + + + + + + Free text option to write further details about the detector. + + + + + Exact definition as understood by HU colleagues remains to be communicated. + + + Exact definition as understood by HU colleagues remains to be communicated. + + + Exact definition as understood by HU colleagues and Nion remains to be communicated. + + + Details how computed needs to be confirmed by Nion. + + + + + Container for reporting individually processed images with the HAADF detector ? + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + HAADF annulus inner half angle ? + + + HAADF annulus outer half angle ? + + + + + + + + + Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. + + Commercial or otherwise given name to the program which was used to execute this analysis. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Remains to be discussed with colleagues which suggestions to put as enumerations. + + + + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Detailed settings of an internal board(s) in the scanbox device. Further information exchange/discussions with Nion is needs to elucidate what these are. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Container for holding an image (stack) taken with the HA(A) ? DF detector. + + + + + + Image intensity values. + + + + + + + Label for the y axis. + + + Pixel barycenter position x-coordinates. + + + + + + Pixel barycenter position y-coordinates. + + + + + + + + + diff --git a/applications/NXmpes.nxdl.xml b/applications/NXmpes.nxdl.xml new file mode 100644 index 0000000000..0744cc478b --- /dev/null +++ b/applications/NXmpes.nxdl.xml @@ -0,0 +1,233 @@ + + + + This is the most general application definition for multidimensional photoelectron spectroscopy. + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + + + + + Title describing the entry. + + + ISO8601 formatted date time of the start of the measurement. + + + Official NeXus NXDL schema to which this file conforms. + + + + + Version specifier enabling to document modification of the schema. + + + + + + Type of source. Any of these values: - Synchrotron X-ray Source - Rotating Anode X-ray - Fixed Tube X-ray - UV Laser - Free-Electron Laser - Optical Laser - UV Plasma Source - Metal Jet X-ray + + + + + + + + + + + + + Free text name of the source. + + + Type of probe. In photoemission it's always photons, any of these values: - x-ray - ultraviolet - visible light + + + + + + + + + Properties of the beam at the sample. + + Distance of the point of evaluation of the beam from the sample. + + + Incident photon energy. + + + FWHM energy linewidth of the incident photons. + + + Incident polarization specified as a Stokes vector. + + + + + + + + Free text description of the type of detector. + + + Energy resolution of the analyser with the current setting. + + + List of the axes that are acquired symultaneously by the detector. + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. + + + + + + + Scheme of the electron collection column. + + + + + + + + + Labelling of the lens setting in use. + + + The space projected in the angularly dispersive directions, i.e. real or reciprocal. + + + + + + + + + Energy dispersion scheme employed. + + + + + + + + + + energy of the electrons on the mean path of the analyser. + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + + Type of electron amplifier. + + + + + + + Description of the detector type. + + + + + + + + + + + + + + Calibrated energy axis + + + + + + + Has an energy calibration been applied? + + + + + + Simple and descriptive name of the sample. + + + Chemical formula of the sample. + + + Ideally, a reference to the location or a unique identifier or other metadata file. In the case that is not available, free-text description. + + + ISO 8601 date of preparation of the sample for the ARPES experiment (i.e. cleaving, last annealing). + + + Free-text surface preparation technique for the ARPES experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. + + + Temperature of the sample. + + + + Residual gas pressure at the sample. + + + + + Processed plottable data. + + + + diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml new file mode 100644 index 0000000000..dd005aa7af --- /dev/null +++ b/base_classes/NXcorrector_cs.nxdl.xml @@ -0,0 +1,27 @@ + + + + Draft of a base class for a device in a (transmission) electron microscope which corrects for spherical aberrations. The device consists of multiple NXlens_em instances and other components. + + Does the microscope have a spherical aberration correction unit and was it used? + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Ideally an identifier, link, or free-text which gives further details about the component. + + + Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin of the coordinate system is placed in the center of the gun pinhole as the virtual point-like assumed source of the electron beam. A right-handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. The translation actively brings the coordinate system under depends_on into registration with the reference coordinate system in the gun. + + + diff --git a/base_classes/NXfib.nxdl.xml b/base_classes/NXfib.nxdl.xml new file mode 100644 index 0000000000..0fa0bede64 --- /dev/null +++ b/base_classes/NXfib.nxdl.xml @@ -0,0 +1,53 @@ + + + + Draft of a base class for describing focused-ion beam capabilities of an instrument. The class is designed to be used as an additional component of e.g. an electron microscope to describe sample/specimen preparation and the collecting of data and metadata for (scanning) electron microscope/focused-ion beam, (S)EM/FIB instruments. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Ideally a reference to persistent documentation which specifies further details for the device. If this is not available, add a free-text description to deliver further details about the focused-ion unit. + + + + The type of source which creates the ion beam. + + + + + + + + Which ionized elements or molecule are ionized to form the beam that sputters material. Examples a gallium, helium, neon, argon, krypton, or xenon, O2+. + + + Average/nominal (discuss further with colleagues) brightness of the ion beam (at which location?). + + + Ion flux + + + Charge current + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + Needs further discussion with colleagues how this should be defined. + + + + A right-handed Cartesian coordinate system is used whose positive z-axis points in the direction of the ion beam, i.e. towards the sample. For modelling ion milling it is relevant to document the illumination vector. NXtransformations offers a place to store how the ion gun coordinate system has to be rotated to align its positive z-axis with the positive z-axis of e.g. the electron beam and ion beam respectively. + + + + diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml new file mode 100644 index 0000000000..41d61f7143 --- /dev/null +++ b/base_classes/NXion.nxdl.xml @@ -0,0 +1,32 @@ + + + + Atomic architecture of a (molecular) ion (fragment) which can be used for example to label charged molecule ions identified from mass-to-charge histogram data as appearing as signal in e.g. time-resolved mass spectrometry techniques like atom probe or secondary ion mass spectrometry. + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + Ion type aka ion species identifier. The identifier zero is reserved for the special ion type unknown ion type. + + + A vector of ordered isotope hash values. The values have to be arranged in the array 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. Hashvalue = Z + N*256 where Z is the number of protons and N the number of neutrons of the isotope. Z and N have to be 8-bit unsigned integers for this hash function to work. + + + + + + Signed charge of the ion in multiples of the elementary 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 the charge state is not recoverable explicitly, the value should be set to zero. This is for example the case when using classical range file formats (RNG, RRNG) because for atom probe microscopy these files do not document the charge state explicitly but report just a integer fraction of the theoretical mass-to-charge-state-ratios. + + + Human-readable ion type name (e.g. Al3+), i.e. ASCII UTF-8 character array, ideally using LaTeX notation to specify the ion and charge state. Examples 12C+, Al3+ or H+. Although human-readable and intuitive, parsing such names becomes impractical for more complicated cases. Therefore, the isotope_vector is the preferred machine-readable format. + + + Lower (mqmin) and upper (mqmax) bounds of a mass-to-charge interval [mqmin, mqmax] (boundaries included) where assigned signal for the respective ion is labelled as this ion. + + + + + + diff --git a/base_classes/NXlens_apm.nxdl.xml b/base_classes/NXlens_apm.nxdl.xml new file mode 100644 index 0000000000..9405a342b3 --- /dev/null +++ b/base_classes/NXlens_apm.nxdl.xml @@ -0,0 +1,26 @@ + + + + Draft class definition for a component of an atom probe instrument which details an eventually available reflectron device whose purpose is to deflect the flight paths of the ions to realize what is effectively an energy compensation. + + Specifier if the instrument has a reflectron (true) or not (false). + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Free-text field to specify further details about the reflectron. + + + Affine transformation(s) which detail where the reflectron is located relative to e.g. the origin of the specimen space reference coordinate system. This group can also be used for specifying how the reflectron is rotated to the specimen axis. The purpose of these more detailed instrument descriptions is to support the creation of a digital twin of the instrument for computational science. + + diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml new file mode 100644 index 0000000000..b107d10ce5 --- /dev/null +++ b/base_classes/NXlens_em.nxdl.xml @@ -0,0 +1,33 @@ + + + + Draft base class definition for electro-magnetic lenses as they are used e.g. in an electron microscope or reflectron device in a local electrode atom probe microscope. + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Ideally an identifier, persistent link, or free text which gives further details about the lens. + + + Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin of the coordinate system is placed in the center of the gun pinhole as the virtual point-like assumed source of the electron beam. A right-handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. The translation actively brings the coordinate system under depends_on into registration with a coordinate system in the center of the lens. + + diff --git a/base_classes/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml new file mode 100644 index 0000000000..c471da5652 --- /dev/null +++ b/base_classes/NXpeak.nxdl.xml @@ -0,0 +1,35 @@ + + + + Proposal for storing mathematical models of peaks, their functional form or at least their measured support. + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Human-readable identifier to specify which concept/entity the peak identifies. + + + Is the peak described analytically or empirically via intensity/counts as a function of an independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, this array holds the positions were independent variable values were taken. + + + + + + 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 this group can be used to hold parameter of the functional form. For example in the case of Gaussian peaks mu, sigma, and cut-off values and background intensity. + + diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml new file mode 100644 index 0000000000..64c542da86 --- /dev/null +++ b/base_classes/NXpulser_apm.nxdl.xml @@ -0,0 +1,70 @@ + + + + Draft for a class which can be used for representing a coarse-grained description of all those components of an atom probe microscope which realize the pulsing capabilities, whether it be for the laser or the high-voltage pulser, which trigger the removal of ions (atom probe tomography) or the excitation of gas ions (field-ion microscopy). + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How evaporation is physically triggered. + + + + + + + Atom probe microscopes use controlled either voltage or laser pulsing to trigger a sequence of field evaporation events. Many microscopes have a laser installed enabling measurements of poorly conductive specimens. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Nominal wavelength of the laser radiation. + + + Average power of the laser source while illuminating the specimen. + + + Average (??) energy of the laser at peak of (each) ?? pulse. + + + Set of transformations which describe the geometry between how the laser focusing optics/pinhole-attached coordinate system is defined, how it has to be transformed so that it aligns with the specimen coordinate system. A right-handed Cartesian coordinate system, the so-called laser space, should be assumed whose positive z-axis points into the direction of the propagating laser beam. + + + + Details about specific positions along the focused laser beam which for atom probe illuminates the specimen. + + Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. + + + Track time-dependent settings over the course of the measurement where the laser hits the specimen. + + + + Frequency with which the high voltage or laser gets pulsed. + + + Fraction of the pulse_voltage that is applied in addition to the standing_voltage at peak voltage of a pulse. + + + NEED TO DISCUSS WITH APM COLLEAGUES IN DETAIL WHAT THIS IS SPECIFICALLY! + + + + + + Direct current voltage between the specimen and the (local electrode) in the case of a LEAP instrument. + + + + + diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml new file mode 100644 index 0000000000..0a6b374c5a --- /dev/null +++ b/base_classes/NXscanbox_em.nxdl.xml @@ -0,0 +1,48 @@ + + + + Class for describing the scan box of an electron microscope. + + + + + + + Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. + + Commercial or otherwise given name to the program which was used to execute this analysis. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + Remains to be discussed with colleagues which suggestions to put as enumerations. + + + + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + + Remains to be discussed with colleagues how to use and interpret this. + + diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml new file mode 100644 index 0000000000..fe635a3f67 --- /dev/null +++ b/base_classes/NXstage_lab.nxdl.xml @@ -0,0 +1,41 @@ + + + + Candidate class for a component or a set of components which is coarse-grained into one logical unit. The role of the stage in an experiment is to hold/align/orient the sample/specimen and eventually offer a controlled environment and further devices to apply stimuli. Having an own candidate class is justified as contemporary specimen/sample stages are such multi-purpose/-functional tools with multiple actuators, sensors, components, and thus also the need to store the various (meta)data that are generated with manipulating the sample. Modern stages realize a hierarchy of components for achieving these tasks. For example the specimen might be mounted on a multi-axial tilt rotation holders which itself is fixed in the support unit that connects to the microscope. In other examples, taken from atom probe microscopy for instance, researchers may work with wire samples which are clipped into a larger fixing unit for convenience. This unit is known in atom probe jargon as a stub. Stubs in turn are positioned on pucks. Pucks are then loaded onto carousels. This NXstage class reflects two layers of this hierarchy. 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. Applied to examples, a nanoparticle is attached on a copper grid. The copper grid is the holder. The grid itself is fixed to the stage. An atom probe specimen is fixed in a stub, in this case the stub can be considered as the holder, while the cryostat temperature control unit reads more as the stage. A microtip on a microtip array is an example of a three-layer hierarchy commonly employed for efficient sequential processing of atom probe experiments. For a single experiment though only one microtip of the array at a time can be measured. Therefore, the microtip is the specimen, the array the holder and the remaining mounting unit that is attached to the cryo-controller the stage. To cover for an as flexible design of these complex lab-like modern stages users should nest NXstage_lab objects for reflect the differences between e.g. a holder and a stage. + + Principal design of the stage. + + + + + + + + + + + + + + + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + Given name of the manufacturer. + + + Ideally a link to a (globally persistent) unique identifier which documents or can be used to infer further details of the component. If not available use this field for a free text description to give further details to the stage. + + + Set of transformations which describe how the stage-affixed coordinate system is defined and how it has to be transformed so that it aligns with the specimen coordinate system. + + + From 0fc141a170a2e30ade30fc31bcd7289dd1599c49 Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Thu, 27 Jan 2022 12:37:25 +0100 Subject: [PATCH 002/203] Removed not needed Application definitions for now --- applications/NXem.nxdl.xml | 278 -------------------- applications/NXem_edxs.nxdl.xml | 439 -------------------------------- 2 files changed, 717 deletions(-) delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 applications/NXem_edxs.nxdl.xml diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 7ca1c69e9d..0000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,278 +0,0 @@ - - - - Template for creating draft application definitions for storing data and metadata for experiments with (scanning and transmission) electron microscopy. - - - Official NeXus NXDL schema to which this entry conforms. - - Version specifier enabling to document modifications of the schema. - - - - Ideally, a (globally persistent) unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. - - - Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in prose into this field. - - - ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. - - - ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended. - - - Commercial or otherwise given name to the program which was used to acquire/measure the dataset. Electron microscopy experiments are usually controlled/performed via commercial integrated acquisition and instrument control software. In many cases, an EM dataset is useful only if gets post-processed already during the acquisition or shortly thereafter, i.e. while the scientists is still sitting at the microscope. Many of these processes are automated, if not they virtually involve GUI interactions with the control software. Examples include collecting of diffraction pattern and on-the-fly indexing of these. These situations and tools are realized with individual NXprocess groups which can hold more details and numerical data to these processing steps. Frequently, some of these NXprocess groups are performed with (open-source) research software. Therefore, there is strictly speaking not a single program used in electron microscopy, and thus each NXprocess has its own program name and description." - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is numerically recreatable in the same deterministic manner. - - - - Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip archive ...). - - - A small image that is representative of the entry. This can be an image from the dataset or a thumbnail of a spectrum. Either way it is recommended to use 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories. - - - - Contact information of at least the user of the instrument who measured this specimen or the principal investigator who performed this experiment. Adding multiple users if relevant is recommended. - - Given (first) name and surname of the user. - - - Name of the affiliation of the user at the point in time when the experiment was performed. - - - Postal address of the affiliation. - - - Email address of the user at the point in time when the experiment was performed. Given the most permanently used email is recommended. - - - Globally unique identifier of the user as offers by services like ORCID or Researcher ID. - - - (Business) (tele)phone number of the user at the point in time when the experiment was performed. - - - Which role does the user have in the place, and at the point in time when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principal investigator, guest ...). - - - - - Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen was investigated and is represented by this NXentry. The user is advised to store the details how specimens were cut/prepared from samples in the sample history. - - - Ideally, a reference to the location of or a (globally persistent) unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. - - - ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these temporal details in the sample_history. - - - Possibility to give an abbreviation of the specimen name field. - - - Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus relevant from a scientific point. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history. - - - (Measured) sample thickness - - - - Hard link to a location/locations in the hierarchy of the NeXus file where the data for default plotting are stored. - - - - - - - - - Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. - - Commercial or otherwise given name to the program which was used to execute this analysis. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Remains to be discussed with colleagues which suggestions to put as enumerations. - - - - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - - Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. - - Given name of the microscope, e.g. NionHermes. - - - Geographic coordinates of the lab or the place where the instrument is installed using GEOREF geocodes ideally. - - - Manufacturer of the entire instrument to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model and instrument_capabilities. - - - Manufacturer brand/model to enable e.g. queries about microscope models. See comments on instrument_manufacturer on how to provide further specification. - - - Hardware name/serial number or hash identifier given by the manufacturer to identify the instrument. - - - Free-text list possibly multiple terms of functionalities which the instrument provides. - - - The source creating the electron beam. - - Voltage relevant to compute the energy of the electrons immediately after they left the gun. - - - Type of radiation. - - - - - - Emitter type used to create the beam. - - - - - - - - Ideally a reference to (another) file (ideally formatted using also an application definition) via a link, name, or a (globally persistent) unique identifier to give further details about the electron gun. - - - - Details to individual apertures in the instrument. - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Relevant value from the control software as this is not always simply the diameter of (not even in the case) of a circular aperture. Details which choice was made should be explained under description. - - - An (ideally globally persistent) unique identifier, link, or text which gives further details. - - - Affine transformations and geometrical descriptions which detail how the aperture is placed and arranged in the microscope relative to the optical axis and beam path. - - - - Details to individual lenses in the microscope. - - - - - - - - - - - - - - - - - - Details about an eventual device which corrects spherical aberrations. - - Does the microscope have a spherical aberration correction unit and was it used? - - - - - - - - - - - - - - - - - - - - Description of the type of the detector e.g. CCD, scintillator, direct electron, image plate, CMOS. - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - - - - - - - - - Free text option to write further details about the detector. - - - - - Exact definition as understood by HU colleagues remains to be communicated. - - - Exact definition as understood by HU colleagues remains to be communicated. - - - Exact definition as understood by HU colleagues and Nion remains to be communicated. - - - Details how computed needs to be confirmed by Nion. - - - - - diff --git a/applications/NXem_edxs.nxdl.xml b/applications/NXem_edxs.nxdl.xml deleted file mode 100644 index 24a705e505..0000000000 --- a/applications/NXem_edxs.nxdl.xml +++ /dev/null @@ -1,439 +0,0 @@ - - - - Draft application definition for storing data and metadata for scanning transmission, energy-dispersive X-ray spectroscopy experiments at the EPFL, Lausanne. User story how to use components of proposed NXem application definition and related NeXus base classes for a user of the NORTH tools. - - - Official NeXus NXDL schema to which this entry conforms. - - Version specifier enabling to document modifications of the schema. - - - - Ideally, a (globally persistent) unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. - - - Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in prose into this field. - - - ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. - - - ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended. - - - Commercial or otherwise given name to the program which was used to acquire/measure the dataset. Electron microscopy experiments are usually controlled/performed via commercial integrated acquisition and instrument control software. In many cases, an EM dataset is useful only if gets post-processed already during the acquisition or shortly thereafter, i.e. while the scientists is still sitting at the microscope. Many of these processes are automated, if not they virtually involve GUI interactions with the control software. Examples include collecting of diffraction pattern and on-the-fly indexing of these. These situations and tools are realized with individual NXprocess groups which can hold more details and numerical data to these processing steps. Frequently, some of these NXprocess groups are performed with (open-source) research software. Therefore, there is strictly speaking not a single program used in electron microscopy, and thus each NXprocess has its own program name and description." - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is numerically recreatable in the same deterministic manner. - - - - Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip archive ...). - - - A small image that is representative of the entry. This can be an image from the dataset or a thumbnail of a spectrum. Either way it is recommended to use 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories. - - - - Contact information of at least the user of the instrument who measured this specimen or the principal investigator who performed this experiment. Adding multiple users if relevant is recommended. - - Given (first) name and surname of the user. - - - Name of the affiliation of the user at the point in time when the experiment was performed. - - - Postal address of the affiliation. - - - Email address of the user at the point in time when the experiment was performed. Given the most permanently used email is recommended. - - - Globally unique identifier of the user as offers by services like ORCID or Researcher ID. - - - (Business) (tele)phone number of the user at the point in time when the experiment was performed. - - - Which role does the user have in the place, and at the point in time when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principal investigator, guest ...). - - - - - - - - Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen was investigated and is represented by this NXentry. The user is advised to store the details how specimens were cut/prepared from samples in the sample history. - - - Ideally, a reference to the location of or a (globally persistent) unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. - - - ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these temporal details in the sample_history. - - - Possibility to give an abbreviation of the specimen name field. - - - Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus relevant from a scientific point. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history. - - - Density of sample. - - - - - - (Measured) sample thickness - - - - Hard link to a location/locations in the hierarchy of the NeXus file where the data for default plotting are stored. - - - - - - - - - Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. - - Commercial or otherwise given name to the program which was used to execute this analysis. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Remains to be discussed with colleagues which suggestions to put as enumerations. - - - - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - - Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. - - Given name of the microscope, e.g. NionHermes. - - - Geographic coordinates of the lab or the place where the instrument is installed using GEOREF geocodes ideally. - - - Manufacturer of the entire instrument to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model and instrument_capabilities. - - - Manufacturer brand/model to enable e.g. queries about microscope models. See comments on instrument_manufacturer on how to provide further specification. - - - Hardware name/serial number or hash identifier given by the manufacturer to identify the instrument. - - - Free-text list possibly multiple terms of functionalities which the instrument provides. - - - The source creating the electron beam. - - Voltage relevant to compute the energy of the electrons immediately after they left the gun. - - - Type of radiation. - - - - - - Emitter type used to create the beam. - - - - - - - - Ideally a reference to (another) file (ideally formatted using also an application definition) via a link, name, or a (globally persistent) unique identifier to give further details about the electron gun. - - - - Details about nominal properties of the electron beam at the locations where it enters the surface of the sample upon the measurement(s). - - (Nominal/average) probe diameter when the beam probes the sample surface. - - - Energy of the beam. - - - Current of the beam. - - - - Details to individual apertures in the instrument. - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Relevant value from the control software as this is not always simply the diameter of (not even in the case) of a circular aperture. Details which choice was made should be explained under description. - - - An (ideally globally persistent) unique identifier, link, or text which gives further details. - - - Affine transformations and geometrical descriptions which detail how the aperture is placed and arranged in the microscope relative to the optical axis and beam path. - - - - Details to individual lenses in the microscope. - - - - - - - - - - - - - - - - - - Details about an eventual device which corrects spherical aberrations. - - Does the microscope have a spherical aberration correction unit and was it used? - - - - - - - - - - - - - - - - - Specific convention how the sample holder is tilted against the gun coordinate system has not been shared yet by EPFL colleagues. - - - Specific convention how the sample holder is tilted against the gun coordinate system has not been shared yet by EPFL colleagues. - - - - - - Description of the type of the detector e.g. CCD, scintillator, direct electron, image plate, CMOS. - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - - - - - - - - - Free text option to write further details about the detector. - - - - - Exact definition as understood by EPFL colleagues remains to be communicated. - - - Exact definition as understood by EPFL colleagues remains to be communicated. - - - Exact definition as understood by HU colleagues and Nion remains to be communicated. - - - Details how computed needs to be confirmed by Nion. - - - - - Description of type scintillator. - - - Energy resolution, how measured?, how defined? - - - Specific convention on how they define this angle in relation to the gun coordinate system has not been shared yet by EPFL colleagues. - - - Specific convention on how they define this angle in relation to the gun coordinate system has not been shared yet by EPFL colleagues. - - - - - - - - - Container for holding numerical data which represent the set of collected EDX spectra, i.e. counts, for each position on the sample surface where an EDX spectrum was measured. The spectra have to be post-processed to identify accumulated counts which substantiate the presence of specific elements. Plotting these accumulated counts for a given element for all probed positions via post-processing yields a so-called EDX mapping. - - - - - - - The three-dimensional data stack. - - - - - - - E.g. X-ray photon counts - - - - - - - - X-ray energy - - - - - - - - Label for the x axis - - - - - - - - Label for the y axis - - - - - - - - - Container for holding an image (e.g. electron backscatter, secondary electron, or high-angle annular dark field), which resolves the pixel location at which edx_spectra where taken. - - - - - - The two-dimensional image. - - - - - - X-ray photon counts - - - - - - - - Label for the x axis - - - - - - - - Label for the y axis - - - - - - - - Details about computational steps how peaks in the EDX spectrum were indexed as atoms. - - Commercial or otherwise given name to the program which was used to execute this analysis. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Name and location of each X-ray line which was indexed as a known ion. - - Human-readable identifier to specify which concept/entity the peak identifies. - - - - - - List of the names of identified elements. - - - - - - - Container for reporting individually processed element-specific EDX mappings from the edx_spectra data cube. - - Commercial or otherwise given name to the program which was used to execute this analysis. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - - - From 2798f71ea3099c3c20a2f7dc11b05074cc8fa8e3 Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Thu, 27 Jan 2022 14:19:42 +0100 Subject: [PATCH 003/203] Added required base_class by MPES reader --- base_classes/NXcollectioncolumn.nxdl.xml | 51 ++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 base_classes/NXcollectioncolumn.nxdl.xml diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml new file mode 100644 index 0000000000..de5095c8a1 --- /dev/null +++ b/base_classes/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,51 @@ + + + + Draft subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum microscope, etc. + + + Voltage applied to the extractor lens + + + Indicating leakage, field emission or arc currents to the extractor lens + + + Distance between sample and detector entrance + + + Set of names of electron optic lenses + + + + + + Array of corresponding voltages + + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + The magnification of the projected image in the angularly dispersive direction + + + The size and position of the field aperture inserted in the column + + + The size and postion of the contrast aperture inserted in the column. + + + deflectors in the collection column section + + + Individual lenses in the collection column section + + From 39fd5e4636530767b7034b47a1665aac07986f96 Mon Sep 17 00:00:00 2001 From: Carola Emminger Date: Tue, 1 Feb 2022 12:00:50 +0100 Subject: [PATCH 004/203] Updated version of NXellipsometry.nxdl file --- applications/NXellipsometry.nxdl.xml | 30 ++++++++++++++-------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml index 386639c8ef..da9bdd34a6 100644 --- a/applications/NXellipsometry.nxdl.xml +++ b/applications/NXellipsometry.nxdl.xml @@ -11,9 +11,18 @@ - This is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. + Thi s is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description + + FAIRmat-specific candidate proposal for an application definition exemplifying ellipsometry. For example: https://gitlab.mpcdf.mpg.de/nomad-lab/areab-appdef/-/blob/spectroscopic-ellipsometry-consolidation/optical_spectroscopy + + Ideally version with build number are commit hash of the application definition. If not available a free-text description. + + + URL where to find further material (documentation, examples) relevant to the application definition + + Unique identifier of the experiment, such as a (globally persistent) unique identifier. - The identifier is usually defined by the facility or principle investigator. - The identifier enables to link experiments to e.g. proposals. @@ -28,15 +37,6 @@ The application definition defines: - elements of the experimental instrument - Website of the software. - - FAIRmat-specific candidate proposal for an application definition exemplifying ellipsometry. For example: https://gitlab.mpcdf.mpg.de/nomad-lab/areab-appdef/-/blob/spectroscopic-ellipsometry-consolidation/optical_spectroscopy - - Ideally version with build number are commit hash of the application definition. If not available a free-text description. - - - URL where to find further material (documentation, examples) relevant to the application definition - - Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -59,7 +59,7 @@ The application definition defines: - elements of the experimental instrument - Name of the company which build the instrument - + ISO8601 date when the instrument was constructed @@ -318,7 +318,7 @@ Last, provide the rotations of the sample Describe what was the medium above or around the sample. The common model is built up from substrate to the medium on the other side. Both boundaries are assumed infinite in the model. Here define the name of the material (e.g. water, air, etc.). - + Array of pairs of complex refractive indices of the medium for every measured wavelength. Only necessary if the measurement was performed not in air, or something very well known, e.g. high purity water. Specify the complex refractive index: n + ik @@ -389,8 +389,8 @@ Last, provide the rotations of the sample light loss due to depolarization as a value in [0-1] - - - A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. + + A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. + From 87746b4eca8b5de0715c71d84776de93367d538c Mon Sep 17 00:00:00 2001 From: Carola Emminger Date: Tue, 1 Feb 2022 19:32:33 +0100 Subject: [PATCH 005/203] NXellipsometry.nxdl NX_COMPLEX changed to NX_NUMBER --- applications/NXellipsometry.nxdl.xml | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml index da9bdd34a6..8857c5d435 100644 --- a/applications/NXellipsometry.nxdl.xml +++ b/applications/NXellipsometry.nxdl.xml @@ -1,7 +1,7 @@ - Draft application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. + Draft application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. In this application definition, times should be specified always together with a UTC offset. Variables used throughout the document, e.g. dimensions and important parameters @@ -11,23 +11,28 @@ - Thi s is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. + This is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description - FAIRmat-specific candidate proposal for an application definition exemplifying ellipsometry. For example: https://gitlab.mpcdf.mpg.de/nomad-lab/areab-appdef/-/blob/spectroscopic-ellipsometry-consolidation/optical_spectroscopy + An application definition for ellipsometry. - Ideally version with build number are commit hash of the application definition. If not available a free-text description. + Version number to identify which definition of this application definition was used for this entry/data. URL where to find further material (documentation, examples) relevant to the application definition + + + Unique identifier of the experiment, such as a (globally persistent) unique identifier. - The identifier is usually defined by the facility or principle investigator. - The identifier enables to link experiments to e.g. proposals. - + + UTC offset should be specifiec. + Commercial or otherwise defined given name to the program that was used to generate the results file(s) with measured data and metadata (or a link to the instrument software). @@ -59,8 +64,8 @@ The application definition defines: - elements of the experimental instrument - Name of the company which build the instrument - - ISO8601 date when the instrument was constructed + + ISO8601 date when the instrument was constructed. UTC offset should be specifiec. Name (e.g. commercial) of the software that was used for the measurement @@ -114,7 +119,7 @@ The application definition defines: - elements of the experimental instrument - Ellipsometers require regular calibration to adjust the hardware parameters for proper zero values and background light compensation. - ISO8601 datum when calibration was last performed before this measurement + ISO8601 datum when calibration was last performed before this measurement. UTC offset should be specifiec. Arrays which provide the measured calibration data. Multiple sets are possible, e.g. Psi and delta measured on an e.g. silicon calibration waver, and the straight-through data. We recommend to provide data that is measured under the same settings as the measurement was performed, that is if Psi and delta are measured for your data, also provide Psi and delta here. And use the same wavelenghts as there. @@ -265,7 +270,7 @@ Last, provide the rotations of the sample Ideally, a reference to the location or a unique (globally persistent) identifier (e.g.) of e.g. another file which gives as many as possible details of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample is not available, use this field as a free-text description to specify details of the sample and its preparation. - ISO 8601 date with time zone specified. + ISO 8601 date with time zone specified. UTC offset should be specifiec. Qualitative description of the layer structure for the sample. For example: Si/native oxide/thermal oxide/polymer/peptide @@ -318,7 +323,7 @@ Last, provide the rotations of the sample Describe what was the medium above or around the sample. The common model is built up from substrate to the medium on the other side. Both boundaries are assumed infinite in the model. Here define the name of the material (e.g. water, air, etc.). - + Array of pairs of complex refractive indices of the medium for every measured wavelength. Only necessary if the measurement was performed not in air, or something very well known, e.g. high purity water. Specify the complex refractive index: n + ik From 719a5d96e09f97dc120fb3891434387c6553dc53 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Fri, 4 Feb 2022 15:04:42 +0100 Subject: [PATCH 006/203] Added definitions for default plottables NXapm --- applications/NXapm.nxdl.xml | 87 ++++++++++++++++++++++++++++++++++++- 1 file changed, 85 insertions(+), 2 deletions(-) diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml index 9e49f3098d..0cf0fe6f05 100644 --- a/applications/NXapm.nxdl.xml +++ b/applications/NXapm.nxdl.xml @@ -344,7 +344,7 @@ - + Data post-processing step to create a tomographic reconstruction of the specimen based on selected calibrated ion hit positions, the evaporation sequence, and voltage curve data. Very often scientists use own software scripts according to published, so-called reconstruction protocols, i.e. numerical recipes how to compute x, y, z atomic positions. Given name of the program that was used to perform this computation. Similar comments as voltage_and_bowl_correction apply. @@ -374,6 +374,61 @@ Different models and associated algorithms, i.e. (numerical) protocols exist to reconstruct atom probe data. Although these approaches are qualitatively similar, each protocol uses different parameters (and interprets these differently). The source code to IVAS/APSuite is not open. For now we store the reconstruction parameter in a collection. + + To get a first overview of the reconstructed dataset, the format conversion computes a simple 3d histogram of the ion density using one nanometer cubic bins an no smoothing of the histogram. + + Given name of the program that was used to perform this computation. Similar comments as voltage_and_bowl_correction apply. + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + + + + + + + + + A default three-dimensional histogram of the total number of ions in each bin. + + Which is the dependent signal to plot, here the counts. + + + Which axes are plotted, here the three principal coordinate directions. + + + Array of counts for each bin. + + + + + + + + Bin positions along the x axis. + + + + Bin edge end along x. + + + Bin positions along the y axis. + + + + Bin edge end along y. + + + Bin positions along the z axis. + + + + Bin edge end along z. + + + Title of the diagram. + + + Data post-processing step in which elemental, isotopic, and/or molecular identities are assigned to the ions. The documentation of these steps is based on ideas described in the literature (M. K"uhbach et al. 2021, Microsc. Microanal.). @@ -389,7 +444,7 @@ Assumed maximum value that suffices to store all relevant molecular ions even the most complicated ones. Usually a value of 32 suffices well. - + Specifies the computation of the mass-to-charge histogram. Usually mass-to-charge values are studied as an ensemble quantity and binned so document here settings related to (eventual) binning. Given name of the program that was used to perform this binning. If the computation is a integrated into the ranging tool, type . @@ -406,6 +461,34 @@ Binning width + + A default histogram aka mass spectrum of the mass-to-charge-state ratio values. + + + + + Which is the dependent signal to plot. + + + Which axes are plotted, here counts over bins. + + + Array of counts for each bin. + + + + + + End of mass-to-charge-state ratio bin. + + + + Label of the mass-to-charge-state ratio bin axis. + + + Title of the diagram. + + Details of the background model which was used to correct the total counts per bin into used counts. From c2dc05b02a6570070c4c02c4d3ae9849f402483b Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Mon, 14 Feb 2022 12:56:54 +0100 Subject: [PATCH 007/203] Updated NXellipsometry with attribute in the plot group --- applications/NXellipsometry.nxdl.xml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml index 8857c5d435..d2b48cbcaa 100644 --- a/applications/NXellipsometry.nxdl.xml +++ b/applications/NXellipsometry.nxdl.xml @@ -395,7 +395,11 @@ Last, provide the rotations of the sample - A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. + A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. + We set wavelength as a default attribute, but it can be replaced in the case of not full spectral ellipsometry to any suitable parameter along the X-axis. + + wavelength + From b9c6524023e07e9692d2bc25b669cfae06068b30 Mon Sep 17 00:00:00 2001 From: Carola Emminger Date: Mon, 14 Feb 2022 13:42:40 +0100 Subject: [PATCH 008/203] Updated doc string of axes attribute in plot in entry. --- applications/NXellipsometry.nxdl.xml | 29 ++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml index d2b48cbcaa..62465fb2a6 100644 --- a/applications/NXellipsometry.nxdl.xml +++ b/applications/NXellipsometry.nxdl.xml @@ -4,11 +4,21 @@ Draft application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. In this application definition, times should be specified always together with a UTC offset. Variables used throughout the document, e.g. dimensions and important parameters - - - - - + + Size of the energy / wavelength vector used + + + How many variables are saved in a measurement (e.g. Psi and Delta, Mueller matrix) + + + Number of incident angles used + + + Number of sample parameters scanned + + + Number of time points measured + This is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. @@ -395,11 +405,10 @@ Last, provide the rotations of the sample - A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. - We set wavelength as a default attribute, but it can be replaced in the case of not full spectral ellipsometry to any suitable parameter along the X-axis. - - wavelength - + A default view of the data, in this case wavelength vs. Psi and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. + + We recommend to use wavelength as a default attribute, but it can be replaced in the case of not full spectral ellipsometry to any suitable parameter along the X-axis. + From bb1b16cbe5a84e7edfa078f470084f2a1b6256b1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Fri, 18 Feb 2022 13:25:37 +0100 Subject: [PATCH 009/203] Create nexus-fairmat-gen-docs initial commit docs-gen workflow --- .github/workflows/nexus-fairmat-gen-docs | 152 +++++++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 .github/workflows/nexus-fairmat-gen-docs diff --git a/.github/workflows/nexus-fairmat-gen-docs b/.github/workflows/nexus-fairmat-gen-docs new file mode 100644 index 0000000000..d8277118fb --- /dev/null +++ b/.github/workflows/nexus-fairmat-gen-docs @@ -0,0 +1,152 @@ +name: Generate Webpage + +on: # push + push: + branches: [ main ] + #pull_request: + # branches: [ main ] + # if you would like to trigger manually the execution of this workflow (e.g. from the actions tab) + #workflow_dispatch: +jobs: + nexus-fairmat-manual-gen: + runs-on: ubuntu-latest + steps: + # + #- id: addKey + # name: Add key for staging push + # uses: webfactory/ssh-agent@ee29fafb6aa450493bac9136b346e51ea60a8b5e + # with: + # ssh-private-key: ${{ secrets.STAGING_KEY }} + + #- uses: mshick/add-pr-comment@v1 + # if: ${{ failure() && steps.addKey.conclusion == 'failure' }} + # with: + # message: "Staging key could not be imported, cannot push to + # oscovida/staging to create test website instance. If this PR is + # external it may not have access to the required secrets." + # repo-token: ${{ secrets.GITHUB_TOKEN }} + # repo-token-user-login: 'github-actions[bot]' + # allow-repeats: false + + #- name: Early exit for missing staging keys + # if: ${{ failure() && steps.addKey.conclusion == 'failure' }} + # uses: andymckay/cancel-action@0.2 + + - name: Set up Python 3.9 + uses: actions/setup-python@v2 + with: + python-version: 3.9 + persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal access token. + fetch-depth: 0 # otherwise, there would be errors pushing refs to the destination repository. + + #- name: Checkout oscovida/staging + # uses: actions/checkout@v2 + # with: + # ssh-key: ${{ secrets.STAGING_KEY }} + # repository: oscovida/staging + # persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal token + # fetch-depth: 0 # otherwise, you will failed to push refs to dest repo + + #- name: Checkout oscovida pr branch + # uses: actions/checkout@v2 + # with: + # path: oscovida + # ref: ${{ github.event.pull_request.head.sha }} + + #- name: Set up oscovida and webgen + # run: | + # pip install ./oscovida + # pip install -r ./base/requirements.txt + #- name: Run pre-generate hook + # run: | + # ./oscovida/tools/oscovida.github.io/pre-generate.sh + #- name: Generate new reports + # run: | + # export PR_NO=$(jq --raw-output .pull_request.number "$GITHUB_EVENT_PATH") + # cp -r ./base $PR_NO + # export WWWROOT=$(readlink -f $PR_NO) + # echo $WWWROOT + # cd ./oscovida/tools/ + # ln -s $WWWROOT ./wwwroot + # ls ./wwwroot + # python3 -m report_generators.cli --debug \ + # --regions=all \ + # --workers=max \ + # --log-level=INFO \ + # --log-file=./wwwroot/report-gen.log + #- name: Run post-generate hook + # run: | + # ./oscovida/tools/oscovida.github.io/post-generate.sh + + - name: Update pip and install sphinx and required tools + run: | + echo $GITHUB_WORKSPACE + pip install --upgrade pip + pip install lxml Sphinx sphinx_comments pyRestTable six + + - name: Pull the state of the source repo, i.e. the one with the rst source code + run: | + cd $GITHUB_WORKSPACE + mkdir -p source + cd source + ls $PWD + git clone https://github.com/Tommaso-Pincelli/definitions.git + #git clone git@github.com:Tommaso-Pincelli/definitions.git + cd definitions + make all + cd $GITHUB_WORKSPACE + mkdir -p target + cd target + ls $PWD + git clone https://github.com/mkuehbach/definitions.github.io.git + #git clone git@github.com:mkuehbach/definitions.github.io.git + cd definitions.github.io/docs + echo "Carrying changes over to local version of the repo!" + cp -R $GITHUB_WORKSPACE/source/definitions/manual/build/html $GITHUB_WORKSPACE/target/definitions.github.io/docs + ##currently in the target repo + ls $PWD + #git config --global user.name "GitHub Actions Bot" + #git config --global user.email "<>" + cd $GITHUB_WORKSPACE/target/definitions.github.io + echo $GITHUB_EMAIL + echo $GITHUB_USERNAME + echo ${{ github.actor }} + #git config --global user.email "$GITHUB_EMAIL" + #git config --global user.name "$GITHUB_USERNAME" + #git config user.email "markus.kuehbach@rwth-aachen.de" + #git config user.name ${{ github.actor }} + git config user.name ${{ secrets.GH_USER }} + git config user.email "${{ secrets.GH_MAIL }} + echo ${{ secrets.GH_USER }} + echo ${{ secrets.GH_MAIL }} + git remote -v + #git remote set-url origin git@github.com:/mkuehbach/definitions.github.io.git + git remote -v + git add . + #git status + git commit -m "Auto-committed through by tommaso pincelli's definitions git repo" + git status + #REMOTE=https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }} + #echo $REMOTE + #git push #${REMOTE} master + git push + + #- name: Update HTML pages + # run: | + # source .venv_pelican/bin/activate + # cd ./oscovida/tools/pelican + # make publish + # - name: Commit files + # run: | + # export PR_NO=$(jq --raw-output .pull_request.number "$GITHUB_EVENT_PATH") + + # git add $PR_NO --all + # git commit -m "Generated preview for PR $PR_NO on $(date)" -a + # git push + # - uses: mshick/add-pr-comment@v1 + # with: + # message: "View web reports generated with this branch at + # [staging/${{ github.event.number }}/](https://oscovida.github.io/staging/${{ github.event.number }}/index.html)" + # repo-token: ${{ secrets.GITHUB_TOKEN }} + # repo-token-user-login: 'github-actions[bot]' # The user.login for temporary GitHub tokens + # allow-repeats: false # This is the default From 95167ff740f72e46f839a197a6abab8ca50ae59c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Fri, 18 Feb 2022 13:25:58 +0100 Subject: [PATCH 010/203] Delete nexus-fairmat-gen-docs typo --- .github/workflows/nexus-fairmat-gen-docs | 152 ----------------------- 1 file changed, 152 deletions(-) delete mode 100644 .github/workflows/nexus-fairmat-gen-docs diff --git a/.github/workflows/nexus-fairmat-gen-docs b/.github/workflows/nexus-fairmat-gen-docs deleted file mode 100644 index d8277118fb..0000000000 --- a/.github/workflows/nexus-fairmat-gen-docs +++ /dev/null @@ -1,152 +0,0 @@ -name: Generate Webpage - -on: # push - push: - branches: [ main ] - #pull_request: - # branches: [ main ] - # if you would like to trigger manually the execution of this workflow (e.g. from the actions tab) - #workflow_dispatch: -jobs: - nexus-fairmat-manual-gen: - runs-on: ubuntu-latest - steps: - # - #- id: addKey - # name: Add key for staging push - # uses: webfactory/ssh-agent@ee29fafb6aa450493bac9136b346e51ea60a8b5e - # with: - # ssh-private-key: ${{ secrets.STAGING_KEY }} - - #- uses: mshick/add-pr-comment@v1 - # if: ${{ failure() && steps.addKey.conclusion == 'failure' }} - # with: - # message: "Staging key could not be imported, cannot push to - # oscovida/staging to create test website instance. If this PR is - # external it may not have access to the required secrets." - # repo-token: ${{ secrets.GITHUB_TOKEN }} - # repo-token-user-login: 'github-actions[bot]' - # allow-repeats: false - - #- name: Early exit for missing staging keys - # if: ${{ failure() && steps.addKey.conclusion == 'failure' }} - # uses: andymckay/cancel-action@0.2 - - - name: Set up Python 3.9 - uses: actions/setup-python@v2 - with: - python-version: 3.9 - persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal access token. - fetch-depth: 0 # otherwise, there would be errors pushing refs to the destination repository. - - #- name: Checkout oscovida/staging - # uses: actions/checkout@v2 - # with: - # ssh-key: ${{ secrets.STAGING_KEY }} - # repository: oscovida/staging - # persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal token - # fetch-depth: 0 # otherwise, you will failed to push refs to dest repo - - #- name: Checkout oscovida pr branch - # uses: actions/checkout@v2 - # with: - # path: oscovida - # ref: ${{ github.event.pull_request.head.sha }} - - #- name: Set up oscovida and webgen - # run: | - # pip install ./oscovida - # pip install -r ./base/requirements.txt - #- name: Run pre-generate hook - # run: | - # ./oscovida/tools/oscovida.github.io/pre-generate.sh - #- name: Generate new reports - # run: | - # export PR_NO=$(jq --raw-output .pull_request.number "$GITHUB_EVENT_PATH") - # cp -r ./base $PR_NO - # export WWWROOT=$(readlink -f $PR_NO) - # echo $WWWROOT - # cd ./oscovida/tools/ - # ln -s $WWWROOT ./wwwroot - # ls ./wwwroot - # python3 -m report_generators.cli --debug \ - # --regions=all \ - # --workers=max \ - # --log-level=INFO \ - # --log-file=./wwwroot/report-gen.log - #- name: Run post-generate hook - # run: | - # ./oscovida/tools/oscovida.github.io/post-generate.sh - - - name: Update pip and install sphinx and required tools - run: | - echo $GITHUB_WORKSPACE - pip install --upgrade pip - pip install lxml Sphinx sphinx_comments pyRestTable six - - - name: Pull the state of the source repo, i.e. the one with the rst source code - run: | - cd $GITHUB_WORKSPACE - mkdir -p source - cd source - ls $PWD - git clone https://github.com/Tommaso-Pincelli/definitions.git - #git clone git@github.com:Tommaso-Pincelli/definitions.git - cd definitions - make all - cd $GITHUB_WORKSPACE - mkdir -p target - cd target - ls $PWD - git clone https://github.com/mkuehbach/definitions.github.io.git - #git clone git@github.com:mkuehbach/definitions.github.io.git - cd definitions.github.io/docs - echo "Carrying changes over to local version of the repo!" - cp -R $GITHUB_WORKSPACE/source/definitions/manual/build/html $GITHUB_WORKSPACE/target/definitions.github.io/docs - ##currently in the target repo - ls $PWD - #git config --global user.name "GitHub Actions Bot" - #git config --global user.email "<>" - cd $GITHUB_WORKSPACE/target/definitions.github.io - echo $GITHUB_EMAIL - echo $GITHUB_USERNAME - echo ${{ github.actor }} - #git config --global user.email "$GITHUB_EMAIL" - #git config --global user.name "$GITHUB_USERNAME" - #git config user.email "markus.kuehbach@rwth-aachen.de" - #git config user.name ${{ github.actor }} - git config user.name ${{ secrets.GH_USER }} - git config user.email "${{ secrets.GH_MAIL }} - echo ${{ secrets.GH_USER }} - echo ${{ secrets.GH_MAIL }} - git remote -v - #git remote set-url origin git@github.com:/mkuehbach/definitions.github.io.git - git remote -v - git add . - #git status - git commit -m "Auto-committed through by tommaso pincelli's definitions git repo" - git status - #REMOTE=https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }} - #echo $REMOTE - #git push #${REMOTE} master - git push - - #- name: Update HTML pages - # run: | - # source .venv_pelican/bin/activate - # cd ./oscovida/tools/pelican - # make publish - # - name: Commit files - # run: | - # export PR_NO=$(jq --raw-output .pull_request.number "$GITHUB_EVENT_PATH") - - # git add $PR_NO --all - # git commit -m "Generated preview for PR $PR_NO on $(date)" -a - # git push - # - uses: mshick/add-pr-comment@v1 - # with: - # message: "View web reports generated with this branch at - # [staging/${{ github.event.number }}/](https://oscovida.github.io/staging/${{ github.event.number }}/index.html)" - # repo-token: ${{ secrets.GITHUB_TOKEN }} - # repo-token-user-login: 'github-actions[bot]' # The user.login for temporary GitHub tokens - # allow-repeats: false # This is the default From 6c155aaa43d043deff600560ddff0e0599d2dd67 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Fri, 18 Feb 2022 13:26:24 +0100 Subject: [PATCH 011/203] Create nexus-fairmat-gen-docs.yml initial commit docs-gen workflow --- .github/workflows/nexus-fairmat-gen-docs.yml | 152 +++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 .github/workflows/nexus-fairmat-gen-docs.yml diff --git a/.github/workflows/nexus-fairmat-gen-docs.yml b/.github/workflows/nexus-fairmat-gen-docs.yml new file mode 100644 index 0000000000..d8277118fb --- /dev/null +++ b/.github/workflows/nexus-fairmat-gen-docs.yml @@ -0,0 +1,152 @@ +name: Generate Webpage + +on: # push + push: + branches: [ main ] + #pull_request: + # branches: [ main ] + # if you would like to trigger manually the execution of this workflow (e.g. from the actions tab) + #workflow_dispatch: +jobs: + nexus-fairmat-manual-gen: + runs-on: ubuntu-latest + steps: + # + #- id: addKey + # name: Add key for staging push + # uses: webfactory/ssh-agent@ee29fafb6aa450493bac9136b346e51ea60a8b5e + # with: + # ssh-private-key: ${{ secrets.STAGING_KEY }} + + #- uses: mshick/add-pr-comment@v1 + # if: ${{ failure() && steps.addKey.conclusion == 'failure' }} + # with: + # message: "Staging key could not be imported, cannot push to + # oscovida/staging to create test website instance. If this PR is + # external it may not have access to the required secrets." + # repo-token: ${{ secrets.GITHUB_TOKEN }} + # repo-token-user-login: 'github-actions[bot]' + # allow-repeats: false + + #- name: Early exit for missing staging keys + # if: ${{ failure() && steps.addKey.conclusion == 'failure' }} + # uses: andymckay/cancel-action@0.2 + + - name: Set up Python 3.9 + uses: actions/setup-python@v2 + with: + python-version: 3.9 + persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal access token. + fetch-depth: 0 # otherwise, there would be errors pushing refs to the destination repository. + + #- name: Checkout oscovida/staging + # uses: actions/checkout@v2 + # with: + # ssh-key: ${{ secrets.STAGING_KEY }} + # repository: oscovida/staging + # persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal token + # fetch-depth: 0 # otherwise, you will failed to push refs to dest repo + + #- name: Checkout oscovida pr branch + # uses: actions/checkout@v2 + # with: + # path: oscovida + # ref: ${{ github.event.pull_request.head.sha }} + + #- name: Set up oscovida and webgen + # run: | + # pip install ./oscovida + # pip install -r ./base/requirements.txt + #- name: Run pre-generate hook + # run: | + # ./oscovida/tools/oscovida.github.io/pre-generate.sh + #- name: Generate new reports + # run: | + # export PR_NO=$(jq --raw-output .pull_request.number "$GITHUB_EVENT_PATH") + # cp -r ./base $PR_NO + # export WWWROOT=$(readlink -f $PR_NO) + # echo $WWWROOT + # cd ./oscovida/tools/ + # ln -s $WWWROOT ./wwwroot + # ls ./wwwroot + # python3 -m report_generators.cli --debug \ + # --regions=all \ + # --workers=max \ + # --log-level=INFO \ + # --log-file=./wwwroot/report-gen.log + #- name: Run post-generate hook + # run: | + # ./oscovida/tools/oscovida.github.io/post-generate.sh + + - name: Update pip and install sphinx and required tools + run: | + echo $GITHUB_WORKSPACE + pip install --upgrade pip + pip install lxml Sphinx sphinx_comments pyRestTable six + + - name: Pull the state of the source repo, i.e. the one with the rst source code + run: | + cd $GITHUB_WORKSPACE + mkdir -p source + cd source + ls $PWD + git clone https://github.com/Tommaso-Pincelli/definitions.git + #git clone git@github.com:Tommaso-Pincelli/definitions.git + cd definitions + make all + cd $GITHUB_WORKSPACE + mkdir -p target + cd target + ls $PWD + git clone https://github.com/mkuehbach/definitions.github.io.git + #git clone git@github.com:mkuehbach/definitions.github.io.git + cd definitions.github.io/docs + echo "Carrying changes over to local version of the repo!" + cp -R $GITHUB_WORKSPACE/source/definitions/manual/build/html $GITHUB_WORKSPACE/target/definitions.github.io/docs + ##currently in the target repo + ls $PWD + #git config --global user.name "GitHub Actions Bot" + #git config --global user.email "<>" + cd $GITHUB_WORKSPACE/target/definitions.github.io + echo $GITHUB_EMAIL + echo $GITHUB_USERNAME + echo ${{ github.actor }} + #git config --global user.email "$GITHUB_EMAIL" + #git config --global user.name "$GITHUB_USERNAME" + #git config user.email "markus.kuehbach@rwth-aachen.de" + #git config user.name ${{ github.actor }} + git config user.name ${{ secrets.GH_USER }} + git config user.email "${{ secrets.GH_MAIL }} + echo ${{ secrets.GH_USER }} + echo ${{ secrets.GH_MAIL }} + git remote -v + #git remote set-url origin git@github.com:/mkuehbach/definitions.github.io.git + git remote -v + git add . + #git status + git commit -m "Auto-committed through by tommaso pincelli's definitions git repo" + git status + #REMOTE=https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }} + #echo $REMOTE + #git push #${REMOTE} master + git push + + #- name: Update HTML pages + # run: | + # source .venv_pelican/bin/activate + # cd ./oscovida/tools/pelican + # make publish + # - name: Commit files + # run: | + # export PR_NO=$(jq --raw-output .pull_request.number "$GITHUB_EVENT_PATH") + + # git add $PR_NO --all + # git commit -m "Generated preview for PR $PR_NO on $(date)" -a + # git push + # - uses: mshick/add-pr-comment@v1 + # with: + # message: "View web reports generated with this branch at + # [staging/${{ github.event.number }}/](https://oscovida.github.io/staging/${{ github.event.number }}/index.html)" + # repo-token: ${{ secrets.GITHUB_TOKEN }} + # repo-token-user-login: 'github-actions[bot]' # The user.login for temporary GitHub tokens + # allow-repeats: false # This is the default From 22ef08d1adaa5d661731f5aa3f30783b670d8c37 Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Fri, 18 Feb 2022 13:35:23 +0100 Subject: [PATCH 012/203] Update nexus-fairmat-gen-docs.yml --- .github/workflows/nexus-fairmat-gen-docs.yml | 59 ++++++++++---------- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/.github/workflows/nexus-fairmat-gen-docs.yml b/.github/workflows/nexus-fairmat-gen-docs.yml index d8277118fb..34d0d4fb75 100644 --- a/.github/workflows/nexus-fairmat-gen-docs.yml +++ b/.github/workflows/nexus-fairmat-gen-docs.yml @@ -1,12 +1,13 @@ name: Generate Webpage on: # push - push: - branches: [ main ] + #push: + # branches: [ main ] #pull_request: # branches: [ main ] # if you would like to trigger manually the execution of this workflow (e.g. from the actions tab) - #workflow_dispatch: + workflow_dispatch: + jobs: nexus-fairmat-manual-gen: runs-on: ubuntu-latest @@ -36,8 +37,8 @@ jobs: uses: actions/setup-python@v2 with: python-version: 3.9 - persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal access token. - fetch-depth: 0 # otherwise, there would be errors pushing refs to the destination repository. + # persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal access token. + # fetch-depth: 0 # otherwise, there would be errors pushing refs to the destination repository. #- name: Checkout oscovida/staging # uses: actions/checkout@v2 @@ -87,44 +88,44 @@ jobs: - name: Pull the state of the source repo, i.e. the one with the rst source code run: | cd $GITHUB_WORKSPACE - mkdir -p source - cd source - ls $PWD - git clone https://github.com/Tommaso-Pincelli/definitions.git + # mkdir -p source + # cd source + # ls $PWD + # git clone https://github.com/Tommaso-Pincelli/definitions.git #git clone git@github.com:Tommaso-Pincelli/definitions.git - cd definitions + #cd definitions make all - cd $GITHUB_WORKSPACE - mkdir -p target - cd target - ls $PWD - git clone https://github.com/mkuehbach/definitions.github.io.git + #cd $GITHUB_WORKSPACE + #mkdir -p target + #cd target + #ls $PWD + #git clone https://github.com/mkuehbach/definitions.github.io.git #git clone git@github.com:mkuehbach/definitions.github.io.git - cd definitions.github.io/docs - echo "Carrying changes over to local version of the repo!" - cp -R $GITHUB_WORKSPACE/source/definitions/manual/build/html $GITHUB_WORKSPACE/target/definitions.github.io/docs + #cd definitions.github.io/docs + #echo "Carrying changes over to local version of the repo!" + cp -R $GITHUB_WORKSPACE/source/definitions/manual/build/html $GITHUB_WORKSPACE/docs/ ##currently in the target repo ls $PWD #git config --global user.name "GitHub Actions Bot" #git config --global user.email "<>" - cd $GITHUB_WORKSPACE/target/definitions.github.io - echo $GITHUB_EMAIL - echo $GITHUB_USERNAME - echo ${{ github.actor }} + #cd $GITHUB_WORKSPACE/target/definitions.github.io + #echo $GITHUB_EMAIL + #echo $GITHUB_USERNAME + #echo ${{ github.actor }} #git config --global user.email "$GITHUB_EMAIL" #git config --global user.name "$GITHUB_USERNAME" #git config user.email "markus.kuehbach@rwth-aachen.de" #git config user.name ${{ github.actor }} - git config user.name ${{ secrets.GH_USER }} - git config user.email "${{ secrets.GH_MAIL }} - echo ${{ secrets.GH_USER }} - echo ${{ secrets.GH_MAIL }} - git remote -v + #git config user.name ${{ secrets.GH_USER }} + #git config user.email "${{ secrets.GH_MAIL }} + #echo ${{ secrets.GH_USER }} + #echo ${{ secrets.GH_MAIL }} + #git remote -v #git remote set-url origin git@github.com:/mkuehbach/definitions.github.io.git - git remote -v + #git remote -v git add . #git status - git commit -m "Auto-committed through by tommaso pincelli's definitions git repo" + git commit -m "Auto-committed " git status #REMOTE=https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }} #echo $REMOTE From 7a84a9e749b61d4425ba20b41998551e3d28530d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Fri, 18 Feb 2022 17:25:18 +0100 Subject: [PATCH 013/203] Create nexus-fairmat-gen-docs.yml experimenting with using original nexus_definitions docs publication workflow file with our fork of the NIAC repo --- .github/nexus-fairmat-gen-docs.yml | 94 ++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 .github/nexus-fairmat-gen-docs.yml diff --git a/.github/nexus-fairmat-gen-docs.yml b/.github/nexus-fairmat-gen-docs.yml new file mode 100644 index 0000000000..4d7e3813a4 --- /dev/null +++ b/.github/nexus-fairmat-gen-docs.yml @@ -0,0 +1,94 @@ +name: Publish Sphinx Docs to GitHub Pages +on: [push] + +# see: https://sphinx-notes.github.io/pages/ +# see: https://github.com/marketplace/actions/sphinx-to-github-pages + +jobs: + + build: + runs-on: ubuntu-latest + + steps: + - name: Checkout + uses: actions/checkout@master + with: + fetch-depth: 0 # otherwise, you will fail to push refs to dest repo + + - name: Install build requirements + run: | + pip install -r requirements.txt + - name: Diagnostic + run: | + pip list + - name: Run the test suite + run: | + # stops publishing when known problems are found + python utils/test_suite.py + - name: Prepare for out-of-source Sphinx build + run: | + rm -rf ./build + mkdir ./build + python ./utils/build_preparation.py . ./build + - name: Diagnostic + run: | + ls -lAFGh + ls -lAFGh ./build + - name: Install LaTeX + run: | + sudo apt-get update -y && \ + sudo apt-get install -y \ + latexmk \ + texlive-latex-recommended \ + texlive-latex-extra \ + texlive-fonts-recommended + - name: Build impatient guide + run: | + make -C ./build/impatient-guide html latexpdf + ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf + # Copy to documentation source directory + cp \ + ./build/impatient-guide/_build/latex/NXImpatient.pdf \ + ./build/manual/source/_static/ + - name: Build PDF of manual + run: | + # expect next make (PDF) to fail (thus exit 0) + # since nexus.ind not found first time + # extra option for "levels nested too deeply" error + ( \ + make latexpdf \ + LATEXOPTS="--interaction=nonstopmode" \ + -C build/manual \ + || exit 0 \ + ) + # make that missing file + makeindex build/manual/build/latex/nexus.idx + # build the PDF, still a failure will be noted + # but we can ignore it without problem + ( \ + make latexpdf \ + LATEXOPTS="--interaction=nonstopmode" \ + -C build/manual \ + || exit 0\ + ) + # Copy to documentation source directory + cp \ + ./build/manual/build/latex/nexus.pdf \ + ./build/manual/source/_static/NeXusManual.pdf + - name: Include other PDFs + run: | + wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf + wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf + - name: Build (html) and Commit + uses: sphinx-notes/pages@master + with: + # path to conf.py directory + documentation_path: build/manual/source + + - name: Publish if refs/tags + # remove/comment next line to push right away + if: startsWith(github.ref, 'refs/tags') + uses: ad-m/github-push-action@master + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + branch: gh-pages From c482ccdb6e3fd97fb96062f693674fb0fb37d768 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Fri, 18 Feb 2022 17:32:06 +0100 Subject: [PATCH 014/203] Update nexus-fairmat-gen-docs.yml restricted workflow to treat only pushes on the fairmat branch and support for manual triggering of the action --- .github/workflows/nexus-fairmat-gen-docs.yml | 235 +++++++------------ 1 file changed, 90 insertions(+), 145 deletions(-) diff --git a/.github/workflows/nexus-fairmat-gen-docs.yml b/.github/workflows/nexus-fairmat-gen-docs.yml index 34d0d4fb75..aefef1db38 100644 --- a/.github/workflows/nexus-fairmat-gen-docs.yml +++ b/.github/workflows/nexus-fairmat-gen-docs.yml @@ -1,153 +1,98 @@ -name: Generate Webpage - -on: # push +name: NeXus/FAIRmat-Experimental Sphinx Docs to GitHub Pages +on: #push: - # branches: [ main ] - #pull_request: - # branches: [ main ] - # if you would like to trigger manually the execution of this workflow (e.g. from the actions tab) + # branches: + # - fairmat workflow_dispatch: -jobs: - nexus-fairmat-manual-gen: - runs-on: ubuntu-latest - steps: - # - #- id: addKey - # name: Add key for staging push - # uses: webfactory/ssh-agent@ee29fafb6aa450493bac9136b346e51ea60a8b5e - # with: - # ssh-private-key: ${{ secrets.STAGING_KEY }} - - #- uses: mshick/add-pr-comment@v1 - # if: ${{ failure() && steps.addKey.conclusion == 'failure' }} - # with: - # message: "Staging key could not be imported, cannot push to - # oscovida/staging to create test website instance. If this PR is - # external it may not have access to the required secrets." - # repo-token: ${{ secrets.GITHUB_TOKEN }} - # repo-token-user-login: 'github-actions[bot]' - # allow-repeats: false +# see: https://sphinx-notes.github.io/pages/ +# see: https://github.com/marketplace/actions/sphinx-to-github-pages - #- name: Early exit for missing staging keys - # if: ${{ failure() && steps.addKey.conclusion == 'failure' }} - # uses: andymckay/cancel-action@0.2 - - - name: Set up Python 3.9 - uses: actions/setup-python@v2 - with: - python-version: 3.9 - # persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal access token. - # fetch-depth: 0 # otherwise, there would be errors pushing refs to the destination repository. - - #- name: Checkout oscovida/staging - # uses: actions/checkout@v2 - # with: - # ssh-key: ${{ secrets.STAGING_KEY }} - # repository: oscovida/staging - # persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal token - # fetch-depth: 0 # otherwise, you will failed to push refs to dest repo +jobs: - #- name: Checkout oscovida pr branch - # uses: actions/checkout@v2 - # with: - # path: oscovida - # ref: ${{ github.event.pull_request.head.sha }} + build: + runs-on: ubuntu-latest - #- name: Set up oscovida and webgen - # run: | - # pip install ./oscovida - # pip install -r ./base/requirements.txt - #- name: Run pre-generate hook - # run: | - # ./oscovida/tools/oscovida.github.io/pre-generate.sh - #- name: Generate new reports - # run: | - # export PR_NO=$(jq --raw-output .pull_request.number "$GITHUB_EVENT_PATH") - # cp -r ./base $PR_NO - # export WWWROOT=$(readlink -f $PR_NO) - # echo $WWWROOT - # cd ./oscovida/tools/ - # ln -s $WWWROOT ./wwwroot - # ls ./wwwroot - # python3 -m report_generators.cli --debug \ - # --regions=all \ - # --workers=max \ - # --log-level=INFO \ - # --log-file=./wwwroot/report-gen.log - #- name: Run post-generate hook - # run: | - # ./oscovida/tools/oscovida.github.io/post-generate.sh - - - name: Update pip and install sphinx and required tools - run: | - echo $GITHUB_WORKSPACE - pip install --upgrade pip - pip install lxml Sphinx sphinx_comments pyRestTable six - - - name: Pull the state of the source repo, i.e. the one with the rst source code - run: | - cd $GITHUB_WORKSPACE - # mkdir -p source - # cd source - # ls $PWD - # git clone https://github.com/Tommaso-Pincelli/definitions.git - #git clone git@github.com:Tommaso-Pincelli/definitions.git - #cd definitions - make all - #cd $GITHUB_WORKSPACE - #mkdir -p target - #cd target - #ls $PWD - #git clone https://github.com/mkuehbach/definitions.github.io.git - #git clone git@github.com:mkuehbach/definitions.github.io.git - #cd definitions.github.io/docs - #echo "Carrying changes over to local version of the repo!" - cp -R $GITHUB_WORKSPACE/source/definitions/manual/build/html $GITHUB_WORKSPACE/docs/ - ##currently in the target repo - ls $PWD - #git config --global user.name "GitHub Actions Bot" - #git config --global user.email "<>" - #cd $GITHUB_WORKSPACE/target/definitions.github.io - #echo $GITHUB_EMAIL - #echo $GITHUB_USERNAME - #echo ${{ github.actor }} - #git config --global user.email "$GITHUB_EMAIL" - #git config --global user.name "$GITHUB_USERNAME" - #git config user.email "markus.kuehbach@rwth-aachen.de" - #git config user.name ${{ github.actor }} - #git config user.name ${{ secrets.GH_USER }} - #git config user.email "${{ secrets.GH_MAIL }} - #echo ${{ secrets.GH_USER }} - #echo ${{ secrets.GH_MAIL }} - #git remote -v - #git remote set-url origin git@github.com:/mkuehbach/definitions.github.io.git - #git remote -v - git add . - #git status - git commit -m "Auto-committed " - git status - #REMOTE=https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }} - #echo $REMOTE - #git push #${REMOTE} master - git push + steps: + - name: Checkout + uses: actions/checkout@master + with: + fetch-depth: 0 # otherwise, you will fail to push refs to dest repo - #- name: Update HTML pages - # run: | - # source .venv_pelican/bin/activate - # cd ./oscovida/tools/pelican - # make publish - # - name: Commit files - # run: | - # export PR_NO=$(jq --raw-output .pull_request.number "$GITHUB_EVENT_PATH") + - name: Install build requirements + run: | + pip install -r requirements.txt + - name: Diagnostic + run: | + pip list + - name: Run the test suite + run: | + # stops publishing when known problems are found + python utils/test_suite.py + - name: Prepare for out-of-source Sphinx build + run: | + rm -rf ./build + mkdir ./build + python ./utils/build_preparation.py . ./build + - name: Diagnostic + run: | + ls -lAFGh + ls -lAFGh ./build + - name: Install LaTeX + run: | + sudo apt-get update -y && \ + sudo apt-get install -y \ + latexmk \ + texlive-latex-recommended \ + texlive-latex-extra \ + texlive-fonts-recommended + - name: Build impatient guide + run: | + make -C ./build/impatient-guide html latexpdf + ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf + # Copy to documentation source directory + cp \ + ./build/impatient-guide/_build/latex/NXImpatient.pdf \ + ./build/manual/source/_static/ + - name: Build PDF of manual + run: | + # expect next make (PDF) to fail (thus exit 0) + # since nexus.ind not found first time + # extra option for "levels nested too deeply" error + ( \ + make latexpdf \ + LATEXOPTS="--interaction=nonstopmode" \ + -C build/manual \ + || exit 0 \ + ) + # make that missing file + makeindex build/manual/build/latex/nexus.idx + # build the PDF, still a failure will be noted + # but we can ignore it without problem + ( \ + make latexpdf \ + LATEXOPTS="--interaction=nonstopmode" \ + -C build/manual \ + || exit 0\ + ) + # Copy to documentation source directory + cp \ + ./build/manual/build/latex/nexus.pdf \ + ./build/manual/source/_static/NeXusManual.pdf + - name: Include other PDFs + run: | + wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf + wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf + - name: Build (html) and Commit + uses: sphinx-notes/pages@master + with: + # path to conf.py directory + documentation_path: build/manual/source - # git add $PR_NO --all - # git commit -m "Generated preview for PR $PR_NO on $(date)" -a - # git push - # - uses: mshick/add-pr-comment@v1 - # with: - # message: "View web reports generated with this branch at - # [staging/${{ github.event.number }}/](https://oscovida.github.io/staging/${{ github.event.number }}/index.html)" - # repo-token: ${{ secrets.GITHUB_TOKEN }} - # repo-token-user-login: 'github-actions[bot]' # The user.login for temporary GitHub tokens - # allow-repeats: false # This is the default + - name: Publish if refs/tags + # remove/comment next line to push right away + if: startsWith(github.ref, 'refs/tags') + uses: ad-m/github-push-action@master + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + branch: gh-pages From 0b9f8c9d845ac0810c61b96657167499809bb78b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Fri, 18 Feb 2022 17:40:02 +0100 Subject: [PATCH 015/203] Update nexus-fairmat-gen-docs.yml remove default steps executed when building nexus pdf manual --- .github/workflows/nexus-fairmat-gen-docs.yml | 140 +++++++++---------- 1 file changed, 70 insertions(+), 70 deletions(-) diff --git a/.github/workflows/nexus-fairmat-gen-docs.yml b/.github/workflows/nexus-fairmat-gen-docs.yml index aefef1db38..53c001e241 100644 --- a/.github/workflows/nexus-fairmat-gen-docs.yml +++ b/.github/workflows/nexus-fairmat-gen-docs.yml @@ -15,79 +15,79 @@ jobs: steps: - name: Checkout - uses: actions/checkout@master + uses: actions/checkout@fairmat with: fetch-depth: 0 # otherwise, you will fail to push refs to dest repo - - name: Install build requirements - run: | - pip install -r requirements.txt - - name: Diagnostic - run: | - pip list - - name: Run the test suite - run: | - # stops publishing when known problems are found - python utils/test_suite.py - - name: Prepare for out-of-source Sphinx build - run: | - rm -rf ./build - mkdir ./build - python ./utils/build_preparation.py . ./build - - name: Diagnostic - run: | - ls -lAFGh - ls -lAFGh ./build - - name: Install LaTeX - run: | - sudo apt-get update -y && \ - sudo apt-get install -y \ - latexmk \ - texlive-latex-recommended \ - texlive-latex-extra \ - texlive-fonts-recommended - - name: Build impatient guide - run: | - make -C ./build/impatient-guide html latexpdf - ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf - # Copy to documentation source directory - cp \ - ./build/impatient-guide/_build/latex/NXImpatient.pdf \ - ./build/manual/source/_static/ - - name: Build PDF of manual - run: | - # expect next make (PDF) to fail (thus exit 0) - # since nexus.ind not found first time - # extra option for "levels nested too deeply" error - ( \ - make latexpdf \ - LATEXOPTS="--interaction=nonstopmode" \ - -C build/manual \ - || exit 0 \ - ) - # make that missing file - makeindex build/manual/build/latex/nexus.idx - # build the PDF, still a failure will be noted - # but we can ignore it without problem - ( \ - make latexpdf \ - LATEXOPTS="--interaction=nonstopmode" \ - -C build/manual \ - || exit 0\ - ) - # Copy to documentation source directory - cp \ - ./build/manual/build/latex/nexus.pdf \ - ./build/manual/source/_static/NeXusManual.pdf - - name: Include other PDFs - run: | - wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf - wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf - - name: Build (html) and Commit - uses: sphinx-notes/pages@master - with: - # path to conf.py directory - documentation_path: build/manual/source + #- name: Install build requirements + # run: | + # pip install -r requirements.txt + #- name: Diagnostic + # run: | + # pip list + #- name: Run the test suite + # run: | + # # stops publishing when known problems are found + # python utils/test_suite.py + #- name: Prepare for out-of-source Sphinx build + # run: | + # rm -rf ./build + # mkdir ./build + # python ./utils/build_preparation.py . ./build + #- name: Diagnostic + # run: | + # ls -lAFGh + # ls -lAFGh ./build + #- name: Install LaTeX + # run: | + # sudo apt-get update -y && \ + # sudo apt-get install -y \ + # latexmk \ + # texlive-latex-recommended \ + # texlive-latex-extra \ + # texlive-fonts-recommended + #- name: Build impatient guide + # run: | + # make -C ./build/impatient-guide html latexpdf + # ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf + # # Copy to documentation source directory + # cp \ + # ./build/impatient-guide/_build/latex/NXImpatient.pdf \ + # ./build/manual/source/_static/ + #- name: Build PDF of manual + # run: | + # # expect next make (PDF) to fail (thus exit 0) + # # since nexus.ind not found first time + # # extra option for "levels nested too deeply" error + # ( \ + # make latexpdf \ + # LATEXOPTS="--interaction=nonstopmode" \ + # -C build/manual \ + # || exit 0 \ + # ) + # # make that missing file + # makeindex build/manual/build/latex/nexus.idx + # # build the PDF, still a failure will be noted + # # but we can ignore it without problem + # ( \ + # make latexpdf \ + # LATEXOPTS="--interaction=nonstopmode" \ + # -C build/manual \ + # || exit 0\ + # ) + # # Copy to documentation source directory + # cp \ + # ./build/manual/build/latex/nexus.pdf \ + # ./build/manual/source/_static/NeXusManual.pdf + #- name: Include other PDFs + # run: | + # wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf + # wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf + #- name: Build (html) and Commit + # uses: sphinx-notes/pages@master + # with: + # # path to conf.py directory + # documentation_path: build/manual/source - name: Publish if refs/tags # remove/comment next line to push right away From bbdfc36dc8535a28bb6add088cb9960c3ed29f25 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Mon, 28 Feb 2022 10:40:15 +0100 Subject: [PATCH 016/203] Integrated Tommaso Pincelli's customization of the NeXus manual for the NeXus-FAIRmat-Proposal and modified descriptions, taking into account technique-specific rst documents from Carola, Tamas, and MarkusK, and templates for rerouting the manual into versioned sub-directories --- applications/NXmpes_ARPES.nxdl.xml | 274 +++++++++++++++ base_classes/NXcalibration.nxdl.xml | 45 +++ base_classes/NXdeflector.nxdl.xml | 46 +++ base_classes/NXdistortion.nxdl.xml | 38 +++ base_classes/NXelectronanalyser.nxdl.xml | 61 ++++ base_classes/NXenergydispersion.nxdl.xml | 38 +++ base_classes/NXlens.nxdl.xml | 47 +++ base_classes/NXmanipulator.nxdl.xml | 68 ++++ base_classes/NXregistration.nxdl.xml | 32 ++ base_classes/NXspindispersion.nxdl.xml | 35 ++ manual/source/Makefile | 6 +- manual/source/_static/blockquote.css.bak | 23 ++ manual/source/_static/to_alabaster.css | 65 ++++ manual/source/_static/to_rtd.css | 10 + manual/source/apm-structure.rst | 59 ++++ manual/source/classes/Makefile | 2 +- manual/source/classes/applications/Makefile | 4 +- .../applications/canSAS/2012-minimum.png | Bin 0 -> 8405 bytes .../applications/canSAS/Q-geometry.jpg | Bin 0 -> 12380 bytes .../applications/canSAS/minimum-required.txt | 18 + manual/source/classes/applications/index.rst | 187 +++++++++++ manual/source/classes/base_classes/Makefile | 4 +- manual/source/classes/base_classes/index.rst | 312 ++++++++++++++++++ .../classes/contributed_definitions/Makefile | 4 +- .../container/ComplexContainerBeampath.png | Bin 0 -> 7089 bytes .../container/ComplexExampleContainer.png | Bin 0 -> 25103 bytes .../classes/contributed_definitions/index.rst | 83 +++++ manual/source/conf.py | 72 +++- manual/source/ellipsometry-structure.rst | 74 +++++ manual/source/em-structure.rst | 61 ++++ manual/source/fairmat-cover.rst | 197 +++++++++++ manual/source/img/FAIRmat.png | Bin 0 -> 114746 bytes manual/source/mpes-structure.rst | 111 +++++++ manual/source/nexus-index.rst | 20 ++ manual/source/sed/entry-page.html | 6 + manual/source/sed/landing-page.rst | 58 ++++ 36 files changed, 2040 insertions(+), 20 deletions(-) create mode 100644 applications/NXmpes_ARPES.nxdl.xml create mode 100644 base_classes/NXcalibration.nxdl.xml create mode 100644 base_classes/NXdeflector.nxdl.xml create mode 100644 base_classes/NXdistortion.nxdl.xml create mode 100644 base_classes/NXelectronanalyser.nxdl.xml create mode 100644 base_classes/NXenergydispersion.nxdl.xml create mode 100644 base_classes/NXlens.nxdl.xml create mode 100644 base_classes/NXmanipulator.nxdl.xml create mode 100644 base_classes/NXregistration.nxdl.xml create mode 100644 base_classes/NXspindispersion.nxdl.xml create mode 100644 manual/source/_static/blockquote.css.bak create mode 100644 manual/source/_static/to_alabaster.css create mode 100644 manual/source/_static/to_rtd.css create mode 100644 manual/source/apm-structure.rst create mode 100644 manual/source/classes/applications/canSAS/2012-minimum.png create mode 100644 manual/source/classes/applications/canSAS/Q-geometry.jpg create mode 100644 manual/source/classes/applications/canSAS/minimum-required.txt create mode 100644 manual/source/classes/applications/index.rst create mode 100644 manual/source/classes/base_classes/index.rst create mode 100644 manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png create mode 100644 manual/source/classes/contributed_definitions/container/ComplexExampleContainer.png create mode 100644 manual/source/classes/contributed_definitions/index.rst create mode 100644 manual/source/ellipsometry-structure.rst create mode 100644 manual/source/em-structure.rst create mode 100644 manual/source/fairmat-cover.rst create mode 100644 manual/source/img/FAIRmat.png create mode 100644 manual/source/mpes-structure.rst create mode 100644 manual/source/nexus-index.rst create mode 100644 manual/source/sed/entry-page.html create mode 100644 manual/source/sed/landing-page.rst diff --git a/applications/NXmpes_ARPES.nxdl.xml b/applications/NXmpes_ARPES.nxdl.xml new file mode 100644 index 0000000000..da5a52086e --- /dev/null +++ b/applications/NXmpes_ARPES.nxdl.xml @@ -0,0 +1,274 @@ + + + + This is the most general application definition for multidimensional ARPES. + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + + + + + NeXus convention is to use "entry1", "entry2", for analysis software to locate each entry. + + + + + ISO8601 formatted date time of the start of the measurement. + + + + + + + + + + + The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + In the case of a monchromatic beam this is the scalar energy. Several other use cases are permitted, depending on the presence of other incident_energy_X fields. In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. Here, incident_energy_weights and incident_energy_spread are not set. In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_energy_weights as a 2D array. In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + + + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in the energy spread, this is a 2D array of dimension nP by m (slow to fast) of the spreads of the corresponding energy in incident_energy. + + + In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding energies in incident_energy. In the case of a polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np by m (slow to fast) of the relative weights of the corresponding energies in incident_energy. + + + Incident polarization specified as a Stokes vector. + + The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: 'farad' for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. Here: SI units are 'V2/m2'. + + + + + + + + + Free text description of the type of detector. + + + Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. + + + Angular resolution of the analyser with the current setting. May be linked from a NXcalibration. + + + List of the axes that are acquired symultaneously by the detector. These refer only to the experimental variables recorded by the electron analyser. Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. Examples: Hemispherical in ARPES mode: fast_axes: [energy,kx] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] Tof: fast_axes: [energy, kx, ky] Momentum microscope, spin-resolved: fast_axes: [energy, kx, ky] slow_axes: [spin up-down, spin left-right] axes can be less abstract than this, i.e. [detector_x, detector_y] If energy_scan_mode=sweep, fast_axes: [energy, kx]; slow_axes: [energy] is allowed. + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples. + + + + + + + Scheme of the electron collection column. + + + + + + + + + Labelling of the lens setting in use. + + + The space projected in the angularly dispersive directions, i.e. real or reciprocal. + + + + + + + + + Energy dispersion scheme employed. + + + + + + + + + + + energy of the electrons on the mean path of the analyser. Pass energy for hemispherics, drift energy for tofs. + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + Aperture generating the momentum and/or energy filtering. + + Type of aperture inserted in the beam. + + + + + + + + Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc. + + + + + + + + + + + + The relevant dimension for the aperture (slit width, pinhole diameter etc). + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Calibrated kx momentum axis. + + + + + + Calibrated energy axis. + + + + + + + Has a distortion correction been applied? + + + + + Has an energy calibration been applied? + + + + + Has a momentum calibration been applied? + + + + + + + + A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. Ideally, a full report of the previous operations, in any format (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. + + + ISO 8601 date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). + + + Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report of the previous operations, in any format(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. + + + In the case of a fixed temperature measurement this is the scalar temperature of the sample. In the case of an experiment in which the temperature is changed and recoded, this is an array of length m of temperatures. + + + + In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures. + + + + + + + + + + + + + + + + + Processed plottable data. + + + Data containing the energy axis + + + Data containing the k parallel axis + + + + diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml new file mode 100644 index 0000000000..437fd90bce --- /dev/null +++ b/base_classes/NXcalibration.nxdl.xml @@ -0,0 +1,45 @@ + + + + Draft subclass of NXprocess to describe post-processing calibrations. + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + + + 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. + + + For linear calibration. Scaling parameter. + + + For linear calibration. Offset parameter. + + + A vector representing the axis after calibration, matching the data length + + + + + + 2 vectors, representing how the raw points get mapped on the calibrated axis. + + + + + + + Class to describe freely the procedures employed. + + diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml new file mode 100644 index 0000000000..bd69b407bd --- /dev/null +++ b/base_classes/NXdeflector.nxdl.xml @@ -0,0 +1,46 @@ + + + + Draft class definition for electro-static deflectors as they are used e.g. in an electron analyser. + + Qualitative type of lens with respect to the number of pole pieces + + + + + + + + + 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. + + + Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin of the coordinate system is placed in the center of the gun pinhole as the virtual point-like assumed source of the electron beam. A right-handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. + + + Following transformation_type argument of NXtranslations but allowed value is only translation. + + + Following vector argument of NXtranslations. The translation actively brings the coordinate system under depends_on into registration with a coordinate system in the center of the lens. + + + Enter the path where the reference coordinate system for the instrument is defined. + + + + diff --git a/base_classes/NXdistortion.nxdl.xml b/base_classes/NXdistortion.nxdl.xml new file mode 100644 index 0000000000..4b7bcf97f1 --- /dev/null +++ b/base_classes/NXdistortion.nxdl.xml @@ -0,0 +1,38 @@ + + + + Draft subclass of NXprocess to describe post-processing distortion correction. + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + + + Has the distortion correction been applied? + + + For symmetry-guided distortion correction (https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub), where a pattern of features is mapped to the regular geometric structure expected from the symmetry. Here we record the number of elementary symmetry operations. + + + For symmetry-guided distortion correction. Here we record the coordinates of the symmetry centre point. + + + + + + For symmetry-guided distortion correction. Here we record coordinates of the relevant symmetry points. + + + + + + For general non-rigid distortion corrections. 2D matrix mapping the original distorted field in the undistorted one. + + + + + + Class to describe freely the procedures employed. + + diff --git a/base_classes/NXelectronanalyser.nxdl.xml b/base_classes/NXelectronanalyser.nxdl.xml new file mode 100644 index 0000000000..08ade2d91c --- /dev/null +++ b/base_classes/NXelectronanalyser.nxdl.xml @@ -0,0 +1,61 @@ + + + + Draft subclass of NXinstrument to describe a photoelectron analyser. + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + + Free text description of the type of the detector + + + Name or model of the equipment + + Acronym or other shorthand name + + + + Overall energy resolution (FWHM of gaussian broadening) + + + Overall momentum resolution (FWHM) + + + Overall angular resolution (FWHM) + + + Overall spatial resolution (Airy disk radius) + + + List of the axes that are acquired symultaneously by the detector. These refer only to the experimental variables recorded by the electron analyser. Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. Examples. Hemispherical in ARPES mode: fast_axes: [energy,kx] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] Tof: fast_axes: [energy, kx, ky] Momentum microscope, spin-resolved: fast_axes: [energy, kx, ky] slow_axes: [spin up-down, spin left-right] axes can be less abstract than this, i.e. [detector_x, detector_y]. If energy_scan_mode=sweep, fast_axes: [energy, kx]; slow_axes: [energy] is allowed. + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples. + + + + + + class to describe the electron collection (spatial and momentum imaging) column + + + class to describe the energy dispersion section + + + class to describe the spin dispersion section + + + class to describe the electron detector + + + deflectors in the collection column section + + + Individual lenses in the collection column section + + diff --git a/base_classes/NXenergydispersion.nxdl.xml b/base_classes/NXenergydispersion.nxdl.xml new file mode 100644 index 0000000000..74897e91a1 --- /dev/null +++ b/base_classes/NXenergydispersion.nxdl.xml @@ -0,0 +1,38 @@ + + + + Draft subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. + + tof, hemispherical, cylindrical, mirror, retarding grid, etc. + + + Pass energy in dispersive electrodes + + + Center of the energy window + + + The interval of transmitted energies. It can be two different things depending on whether the scan is fixed or swept. With a fixed scan it is a 2 vector containing the extrema of the transmitted energy window (smaller number first). With a swept scan of m steps it is a 2xm array of windows one for each measurement point. + + + Size, position and shape of the entrance slits in dispersive analyzers + + + Size, position and shape of the exit slits in dispersive analyzer + + + Diameter of the dispersive orbit + + + fixed or sweep + + + Length of the tof drift electrode + + + deflectors in the energy dispersive section + + + Individual lenses in the energy dispersive section + + diff --git a/base_classes/NXlens.nxdl.xml b/base_classes/NXlens.nxdl.xml new file mode 100644 index 0000000000..060ead8678 --- /dev/null +++ b/base_classes/NXlens.nxdl.xml @@ -0,0 +1,47 @@ + + + + Draft class definition for electro-static lenses as they are used e.g. in an electron analyser. + + Qualitative type of lens with respect to the number of pole pieces + + + + + + + + + + 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. + + + Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin of the coordinate system is placed in the center of the gun pinhole as the virtual point-like assumed source of the electron beam. A right-handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. + + + Following transformation_type argument of NXtranslations but allowed value is only translation. + + + Following vector argument of NXtranslations. The translation actively brings the coordinate system under depends_on into registration with a coordinate system in the center of the lens. + + + Enter the path where the reference coordinate system for the instrument is defined. + + + + diff --git a/base_classes/NXmanipulator.nxdl.xml b/base_classes/NXmanipulator.nxdl.xml new file mode 100644 index 0000000000..e5061b10f3 --- /dev/null +++ b/base_classes/NXmanipulator.nxdl.xml @@ -0,0 +1,68 @@ + + + + Draft extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + + + Name + + + Description + + + Type of manipulator, Hexapod, Rod, etc. + + + Coordinates of the manipulator position (x,y,z) + + + + + + Angles of the manipulator orientation (polar,tilt,azimuth) + + + + + + Effective positions assumed by the manipulator during the measurement. + + + + + + Effective angles assumed by the manipulator during the measurement. + + + + + + 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 + + + Current to neutralize the photoemission current + + + Possible bias of the sample with trespect to analyser ground + + + class to describe the motors that are used in the manipulator + + + class to describe the transformations used. + + diff --git a/base_classes/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml new file mode 100644 index 0000000000..812f66e37d --- /dev/null +++ b/base_classes/NXregistration.nxdl.xml @@ -0,0 +1,32 @@ + + + + Draft extension of NXobject to include fields to describe image registration procedures. + + Has the registration been applied? + + + Coordinates of the new centre point. + + + + + + Coordinates of the rotation centre. + + + + + + Scaling factor to compensate shrinking from distortion correction. + + + + + + To describe the operations of image registration (combinations of rigid translations and rotations) + + + Class to describe freely the procedures employed. + + diff --git a/base_classes/NXspindispersion.nxdl.xml b/base_classes/NXspindispersion.nxdl.xml new file mode 100644 index 0000000000..d7477993ed --- /dev/null +++ b/base_classes/NXspindispersion.nxdl.xml @@ -0,0 +1,35 @@ + + + + Draft subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. + + Type of spin detector, VLEED, SPLEED, Mott, etc. + + + Figure of merit of the spin detector + + + Effective Shermann function, calibrated spin selectivity factor + + + Energy of the spin-selective scattering + + + Angle of the spin-selective scattering + + + Name of the target + + + Preparation procedure of the spin target + + + Date of last preparation of the spin target + + + deflectors in the spin dispersive section + + + Individual lenses in the spin dispersive section + + diff --git a/manual/source/Makefile b/manual/source/Makefile index c2d77e41aa..cfd7cef7dd 100755 --- a/manual/source/Makefile +++ b/manual/source/Makefile @@ -24,13 +24,13 @@ all :: types.table units.table nxdl_desc.rst subdirs types.table: ../../utils/types2rst.py ../../utils/units2rst.py ../../nxdlTypes.xsd - python ../../utils/types2rst.py ../../nxdlTypes.xsd > $@ + python3 ../../utils/types2rst.py ../../nxdlTypes.xsd > $@ units.table: ../../utils/units2rst.py ../../nxdlTypes.xsd - python ../../utils/units2rst.py ../../nxdlTypes.xsd > $@ + python3 ../../utils/units2rst.py ../../nxdlTypes.xsd > $@ nxdl_desc.rst: ../../utils/nxdl_desc2rst.py ../../nxdl.xsd - python ../../utils/nxdl_desc2rst.py ../../nxdl.xsd > $@ + python3 ../../utils/nxdl_desc2rst.py ../../nxdl.xsd > $@ clean :: $(RM) types.table units.table nxdl_desc.rst diff --git a/manual/source/_static/blockquote.css.bak b/manual/source/_static/blockquote.css.bak new file mode 100644 index 0000000000..4ce6e9b98f --- /dev/null +++ b/manual/source/_static/blockquote.css.bak @@ -0,0 +1,23 @@ +/* + * blockquote.css + * ~~~~~~~~~~~~~~~ + * + * custom Sphinx stylesheet -- define margins in blockquotes with NXDL documentation + * + * :see: http://stackoverflow.com/questions/23462494/how-to-add-custom-css-file + * + */ + +/* do NOT import, causes sidebar to disappear, see issue 341 +@import url("basic.css"); +*/ + +/* -- page layout ----------------------------------------------------------- */ + +/* github issue 341: nicer to solve this just for NXDL documentation files + * but this works for now + */ + +blockquote { + margin-right: 100px; +} diff --git a/manual/source/_static/to_alabaster.css b/manual/source/_static/to_alabaster.css new file mode 100644 index 0000000000..32ccc19a69 --- /dev/null +++ b/manual/source/_static/to_alabaster.css @@ -0,0 +1,65 @@ +/* Theme override commands to control the html aspect in alabaster sphinx theme */ + +/* Override sidebar background color default (#FFFFFF) */ +.sphinxsidebar { + background: #005F73 !important; + } + + /* Control logo positioning */ +.sphinxsidebarwrapper p.logo { + margin-top: -8px !important; + margin-bottom: -8px !important; + text-align: center !important; +} + +/* Control sidebar headers (non clickable)*/ +.sphinxsidebarwrapper h3 { + font-size: 18pt !important; +} + +/* Control logo name string */ +.sphinxsidebarwrapper h1.logo { + margin-top: 0px !important; + font-size: 21pt !important; + margin-bottom: 10px !important; +} + +/* Control TOC tree top level links */ +.sphinxsidebar ul li.toctree-l1 > a { + font-size: 11pt !important; + line-height: 1.8 !important; +} + +/* Control TOC tree second level links */ +.sphinxsidebar ul li.toctree-l2 > a { + font-size: 10pt !important; + line-height: 1.8 !important; +} + +/* Control quick search bar */ +.sphinxsidebar input { + margin-top: 5px !important; + margin-bottom: 12px !important; +} + +/* Control quick search bar wrapper, nasty alignment with the google search bar */ +.sphinxsidebar div.searchformwrapper { + width: 209px !important; + align-self: center !important; + margin-left: 3px !important; +} + +/* Control text blurb explaining the project under the logo name */ +.sphinxsidebarwrapper p.blurb { + margin-top: 10px !important; + margin-bottom: 20px !important; +} + +/* Slightly increase the padding in the body */ +.bodywrapper div.body { + padding: 0 45px 0 45px !important; +} + +.body h1 { + margin-bottom: 50px !important; +} \ No newline at end of file diff --git a/manual/source/_static/to_rtd.css b/manual/source/_static/to_rtd.css new file mode 100644 index 0000000000..0b69475425 --- /dev/null +++ b/manual/source/_static/to_rtd.css @@ -0,0 +1,10 @@ +/* Theme override commands to control the html aspect in read the docs sphinx theme*/ + +/* Sidebar header (and topbar for mobile) */ +.wy-side-nav-search, .wy-nav-top { + background: #FF331C; + } +/* Sidebar */ +.wy-nav-side { + background: #005F73; + } \ No newline at end of file diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst new file mode 100644 index 0000000000..5376b6d4bb --- /dev/null +++ b/manual/source/apm-structure.rst @@ -0,0 +1,59 @@ +.. _Apm-Structure: + +======================================== +Atom Probe Microscopy Structure +======================================== + +.. index:: + IntroductionAPM + ApmNewAppDef + ApmNewBC + + + +.. _IntroductionAPM: + +Introduction +############## + +Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. + +.. _ApmNewAppDef: + +New Application Definitions +############################ + +We created one new application definition whose intention is to serve both the description of atom probe tomography and field-ion microscopy measurements: + + :ref:`NXapm`: + A general application definition with many detailed places of leaving metadata and procedural/computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). + +.. _ApmNewBC: + +New Base Classes +################# + +We developed new base classes to structure the application definition into lab experiment and computational steps: + + :ref:`NXion`: + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described.: + + :ref:`NXlens_apm`: + A base class to describe an eventual reflectron device that influences the flight path of evaporated ions. + + :ref:`NXpeak`: + A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + + :ref:`NXpulser_apm`: + A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. + + :ref:`NXstage_lab`: + A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage` base class is insufficiently detailed to represent the functionalities which modern stages of an + atom probe microscope or especially an electron microscopy offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and in an atom probe, given that both offer fixture functionalities and additional components such as for applying stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. + +Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually +a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. + + +.. + https://stackoverflow.com/questions/4783814/how-to-comment-a-string-in-restructured-text \ No newline at end of file diff --git a/manual/source/classes/Makefile b/manual/source/classes/Makefile index 909fd4e19c..762e1bae15 100755 --- a/manual/source/classes/Makefile +++ b/manual/source/classes/Makefile @@ -33,4 +33,4 @@ clean :: $(MAKE) clean -C base_classes $(MAKE) clean -C applications $(MAKE) clean -C contributed_definitions -# $(MAKE) clean -C $(SUBDIRS) +#$(MAKE) clean -C $(SUBDIRS) diff --git a/manual/source/classes/applications/Makefile b/manual/source/classes/applications/Makefile index 76d1060750..7900363341 100644 --- a/manual/source/classes/applications/Makefile +++ b/manual/source/classes/applications/Makefile @@ -43,10 +43,10 @@ all :: index.rst $(RSTs) $(TARGET_NXDLs) index.rst :: echo "Adding summaries to applications/index.rst" - python $(NXDLSUMMARY) applications + python3 $(NXDLSUMMARY) applications %.rst : %.$(NXDL_SUFFIX) $(NXDL2RST) Makefile - python $(NXDL2RST) $< > $@ + python3 $(NXDL2RST) $< > $@ clean :: $(RM) NX*.rst NX*.nxdl.xml diff --git a/manual/source/classes/applications/canSAS/2012-minimum.png b/manual/source/classes/applications/canSAS/2012-minimum.png new file mode 100644 index 0000000000000000000000000000000000000000..84f7159d86f2c45ec4acef83cc5162a294bd5af9 GIT binary patch literal 8405 zcmbuF2T)UMxA%h_K}12CC_y+Py-V*XRiuN|(DX>JO793FO?oE+(tD5^S|Ez_CcQTi zr1u^Y?!!6nedo^oX1@E~`DU0**o3{Gz4ltq`u+baVH#?Rw{Ozigg_v-m7d9IK_J&y z!TXjQ*T5?*{tI~h6QU&d^o7T#tyzD4?GqH?uKMRlc&}{6rIWB z$`S%nA$tr~hHxNI(fhTCvT=={Sa`D zxfgaDNZ+%HkchBoHm|bI`aSKMMw@UA%3EF%kcDldmO6ByuG*8MAXf-Gs9ZSJhUq)pw>cZq|~%-uYw_vgQSh1 z0#u$cIlIzyTKi5HTTfV6wCC?r@#8iZL9sWV^=k~w*Q)g~rN<$h>32QDXQVqbeG|%J ziXuj8{h;H0lhpjszGM1&hyIt*zFl1;co6ihdcUZSo{osnk6t-gNZLwZdsa%(WI{$f zqEo{vT(AYxxAV69?Pjz|XuLmJzG zc!e3!+`rUsYNaIcO(dLh;37*bR95L@uI*d3agm3HGiJrbgvPX$+~x6oU4-3?@~WR2 zbJVtAPiEpdI6OYwJ?>QNjZzKe8ll|(y?weBRb6J?ce`&|3t3^0lUa^jj^hoRw3@qv z%xb8iaR%AN|LZ(Uh+)X+$L8r42?O5pM8_~Q<)@`oa|ez@b*OKky8WB z1OFGXS%r4RA5}wZTnueEY;+dckKPKxDSn!7^~QDQ#_=k(RuC|}Dr)UlolWTW5@qR8 zV=hzvNr=@?rSMjt$#c97;gzoUD~!B)Vt#v(UO5N_JyiMm3R?Aec)-=!o_bnKI8S#A z@hX@pD~{QoLOMl3u9AvxOuh2hV8C`DvrH0}X51~tA;(BUdB6lyLr(ZJW(Sk<2nfPM zJI5U33p%$*!|>Zs#whnS4*a_El+}sjC?P%MHH-4q!jxLK;n#}B^b$IaCE3e^7rQhO zG1vWwPp^-$9B0J5f9}=jb$06xVfZ9D{^g(kZYQMDN=x*=GHV4@>orp=SeIttzuU{Z z2m(@VcdRxrH)NZ6i$2R|vqd#XdC)`)r@{J24#ejC<}PZBCcmq9@s3H^y1hD%{q`t0 z?Hg_Y1JbrOnww#NcRywGZLIR62ix~)=v@U*8*`tHDylWWNOgksg8U7;{zJ~Mf&guKIA^)7Ldt6)QIguQg{#Y6w?NL%4g zr)_wUl>&o`;=aYM>lY1{4Bgtx24Y;twiEYq=ITVPo!_`tFvz|XN;~i=4Clyq-t0k4Rb_ zHifi8Xi9y@Narti#oT?5mP#IwR9H5X4L%=zj>~`H)*UH5n^O8X@aZnvE@0tZQN7|W zTHv9Fnb4D6^hiDl-T1&B1Wo$|rSF@EoL(C>S=*X3DRuLzSungo2XP8iN4Q0Pye*EJ zimg}#??q9DPF&+W1q1>0xp_L5En8f2302lC)6VTbcK2A)NePr3qHg7}343{Ypz=!2 znxbI~TL-VFbQ!#q^(b0i>)2x-W2&M?A2f(c9GcykD-$G~U0T|pUt zvLGHjfL2VM8&r(@dru9wMuf7PO!sxf1r1h^sgss-pl1E)&=j&OG@xCI^p$7M9?V3* zrEs~0h?89=hlkHif;W*<~?fEC+bl?W?GH<`bJq14(IQM>3mvLj|9t%vsk#@n- z7KE#6AdU#x;n-`Bgo`=c24vu_*`J^8xMq`P*w49pTr?$3=nvC*SsW93N4X&HFj9+Q zDzkB(2kp4f9$-@yE?H2=Q2rBC+2N?TE@(rZ#Z9GwoMYOHNQ3AQ$^D5j$43nINL{_0 zVO<-8;8N#SSLZf(_#~Zf?}LXPpn;!PFtm=U)-~QOH|(V|EWfFp*sRH(sMMj*&Ue?G z)1W37S#ko-zPWY^wpv3q9$mlYr)+t}I=#=P#snB%mG7S~^b*p4It$pcj7BFHbWV1dclGG+ zs;JVkTBK(kC%L`(Tz8C4wjH*|3fX3k4q3l^$dafuNo+JjmN7~IS@7vrF<%IJ$6xv# zce}G&B`@S8cSqNaXLSz(5qXNn$CFFI*)@bD6JB*&&>K#aw;hLsDz0UwNiP%o+u#yh zZSzwK>P_GJ_pBwArW?o!2=Uc!gc)D;A?T69arfh1aHd{c+*4dwQP@Df1c!Po9M*>~ zOrS4e#Zkkw9tRrD1UWu~mc6cZxZrsG#)|F%B^5g#<@8&YM?7zdisM~QoI@cC77Ue z;`wNI#o}W(3RctTR{N~Y+3w>V^V+|=CLjg2NN?o6aWKXM0$0v-hN^yQncSGh z&94W7VpF>$#_oZc&_A=ev7bxe5bduT({`3Ee;klF&3>vGSTAh{L8SGPsCwZnd(c%G zf5mC7N-|78pX?>Yacw$4yg}0eDA-itb5VxRv`(&F6_&0h2SP4tF3NAGGn*ym-trCt zF(Q%7nCzUgH<@Q7Y-##&V`ZW>O>I+hQ3GH3fop6- zLrnuH6Z8Bb4M$eZ=`>Nm>6sM{z8!j`9i* z1)aKmDUw7mB~7(kg~^+g%GXufWob_VB%yTYWxt^yuI(WN;tu)B?;RQWv7%#!4?q~n z^;<_D0Q7=PitK=PkOtl+y*2F*Sh|MO^M0n-g$5mViPb2qfl)%p=e5=QV1s9Jo&4Sz zvG0|hk1&;f@v3iFt;ts2F<$3$<=Tar6$*#qw`~@MZVEnBkvF+c*5~6y3R$7MRnrHS zVWcc~KY|bN+()lR(`&o8SdAm2Lj9Vze#=pkll|nqk(83Ak17{aPtteZp3O@&X{>LDs*lhk^?UIfWi0}ug>P0KoG(rir5eE&Yp zV?j8#X+vr6i*D^-gZrz1UwpK~IyD?`M3SJy{Xx5RT;1zc02KlPKzMKk%%hm%$)ABN z`x(#l;pk-RAt8WnrG)V~yYrRYz6+RGC~E;{$Mitso<~mJaOKGwDo#VmPG<9Xf2)+( zwQ}?Idj5;!4ALT%^?J0k^UzA9xX}LBc7nrPzBQKg%r6L1|4?-vL`aqC$e%=sfSyY6 zI4RHGNkJgqU?ExnR#R(LrpwA4%G6X;tBG7Bve&y*hNgEMEBV$@}vR5`j=A7O4p!Xj!z*@HQw=71t*^kTrmLj4jE23`MSd0tc zad>rb*5wa;0OzWJ-)D2}!&O6FhfJ@bt)(!-qe;407CmVu~)&_$%A(z{Yyyp?}X)qLS?|4l@8AVY$HPWN1(Tk z2ymP@cYnLrrO1+GS5<(ARQGSnfB0r6KwZjHD5=p1(rUaFMEAJdpPDcn<amO;PEjQ7-v6d9jqj|cm`efsr0aN@mw2;n5RkH8iAn(W!REh7{iyeK4HPgpJvo_{_h+}g z;7lx(#V}LWS{`27Is@Ie^DAG;p1xsnZ+TF$A#frrxb9HH8m)TyMgUS0QXHPwP1=NWQ1$62@ci^k>3i0WBe;%8$xl0)S z218OeV|saP#4D9y}l-BAQLB zilo}uX_=cJSCsR4?^2zb{pywYl*+OAq#r|N%X_nJ)CqLjbi%+e_VWCld%D)cK*CSx z)}ElqHG7`U0Z2c>2bA(;9zoBCrJJ;Es62RD-%v-1JFf{u+68rE*{ z_~|{gqu9~epDAATP&<8pg0$QOB_p?$AKlc{MC>kQTJC+>yVgz}Vd5bmFDfEpb(Y&` zaw0`0c@)8N?b>#H8`sO_5;YtPSsuG?u#Yh3sW@r6w7bGxWNzW9^!qcLCjUtFPVDju zyfuip$=A{Z3KrVxXD=LJ>-+X-Y3Bp+2-oUP3vPR@{p66|!^>;gZu+4q?d02v$(|l~ zC<&cs-|#R8_P2Vew$#4I)cNYY`(#~96#DbQp(OM^p7T8+zxIgas<$S&+T?k@$ek_o z4=@$5hCOQ*i3?RwR6PBnWO(*$vHy4Qna%N4%uZ&hPbV`GYW~&sH*aK=FD{7-&u2li zPIU^lne>p~&U}0<2UYm$x_^&*FUP)pi5Q(9r@rGvFWuGRVsLTk=fP&Z{OF<|jmE5% zyyGJjcJTSC6%q=TFxnw#2hSrJ7#_AgN=pcz-?Vq+$4#zRo``Yp?%k(x>yJd%MgO+F zMRIE{ErKr8X9UnL2LYjzqF79H^3IPRG0NPMB35vxmV%RUPHAYfsCCf5CkG!~eHk(R zh1+)RMcgdLVx)Nz51_eoWQ)jdd!*k>1Qiv9_fk7`sVu*k*nY)XboYp>-1i;3`U%=Q zPV?_Mt~Ik@agX~r>@YIU!_hCKQ+LVf;g_dY;rn~lN1Bf-RDaJm!sdT%__QDSVczYC zgW#+6>kOZ*+q+IyLG#DK{c&ZaT>nkF znGSw+rr#R_n+A*Px&e)8*poep{i=KK==&`y4tHnMqJ$`5$gz3<^u9fnmty9$>(q12 zl6fu%nMidE-B8ia(v=?Ued=xEv8*>B$?=PdMJ0HRvD>9vMYn}lYHdvn+b^zexguU7 z1C(3u)5^}g{gm7wo<<9HDMkU8N+PIxLY4V}@>#jao`F5k?J4kD%N?(i^!7_1l;Nqe zx0hGnuBKhp_a8rgXd6J|lMBR7+9dw|+%`7ZvB_l5p~ss`8uMnI+VnS?h=++TLTWC~)|Z@91pYu?b;?rGf6DI(LNW+ZvQkkDUKr zQqHotw1vU9K6DSto8~u7=qRgG)&u@7dd7VoxqZ1d)tiavb8(doxN&93{mJ`3+r8g> zB_K}IKE6Idcf*WkZ>FHY+X9jB1-yW1AzqP%b>;wQD~S33)-?X#SS>^u2zC5Oeu8JZY+V}9Xtpmw8+gV%Q@050lyAYUD+TM5Z)1j?EyOhy)6XadgPeY z#{28-3hliL2d@j9XN>^A13KMUX+DDb^^|lGfObK-zThmlodo3BzQR`gJgrC zhc6;Mlhh(4{bdAX;WN2VMip{$vh1=Epc9W3%Z=+TE;VDbzVK+o>V56de`S;HtAvr= zv{Exr8{IAjD#VDi;HEYkf1-hS)g~c+7%L+~t_sY}a-Q0(|H*DZW88Zs;I3}_dO6z5 z+uO;M+6CKn6*GYjzSvL?=p#`zQ7$3(Is25xcUR{N%BY5C#?@J!BX&2#ZWuJ#>7C3nrj{xlQpN|RQ;q@MnMi(j>l3c_gS7XfO!nrU`ba7wgILz z?UkyRn%9+-2TvVHu)n>@08e6B`-S$Kg28R0Z4b#F=38hFe#qYZzA2%Tfejri(o+Z0 zkCTq_{!OLAUqEqPXv%-ct}NmMI5cEkR92`HTr$!#s(^}pFsf?oth65{AisGfR{9vsqQ->0niRZ?0_#y%`kq1k=%WHzfIHY+x1nCqfJgpkgJ&aQe(%zbvohOX{0`pBm* z+&qvQffSpxO6t!2n^FP8a}~h! z?*qGI>lGZKP|&Gy@2DO4A3`DuazI;I!-f-}iGV2kQJzur(pf7XR`!4Qw7vVeu)6>d zyUC|1T!=D~$6~9>g2jSD6XckH8Vy%8cOSRwPg4k5^`Qsa*fq5Q3>-qv;sS#4F5Kd4 z*_fq1>|l9;^sfE>`SJh`y2bq-NG<)1jkty@&gDueBT zFL6h+Pf_rA^crLZoRy7_5)4QRx|j5%VVF{k^NF$ylUC};lqDD?jOCWU5wTT0PXlQP zo~P;=u(XAQ1r8LIN0^LAskx$=8AdG<^M=2Lgkyijv`$RH73W;)x+gj(P6@^z6kqLi zWMK}o4a@670Z@uCIc^_aD6F*i$mwD;LPVnp<imd7Cna2R0c|I+ zGcY^vRuL(k9tw)nPu?}G;roakIbpaxwibvO?W!W+2ndDhRcEn+2v8A|kb+%eVqFjc z*A6aW%py0>2S`-noLFC~BlnAXLD=apG!J?pn4@?}?#*e7L>(>I0KeCKZB2<>A?^2h zBG(g_ymxZwG&{4pyZSyF`9|cmP#TYEg9J!N-pzJusVnIis`_9L!-H}U3)L;wJtsV? zGNFb=_N|kWkRI>ugQS!8xoq8-IU0>FPkOHeHZ-Vz!{Z}a_igq+NP7ux(51vq-jU$- z1#fQicKr8wVecOLXb>^R}G^>!Lzset9V z)Y1jnCI^V||1*dDSCf#H!TZD}Ce)Bq);d}iuofO3W+PnF*g$na5=e+n6`K;<<#rM# z|GPu1Jo@L7KbG(UltRDZw###d{iYpMllbq@VHw}V6>fZU?$91vTtU~%l$7g=DA2DDqf@Bq;~dkQ~j z_X}1o9tojzaZ&;X?|?BvG(nqU`_H(RlN*wv|F#)N(r?&=Gq)7}eq9138Mdl@P@t9S z^6eTiy$P#bgqa#30F}+&3@Uf0q-P0o<&D^QV#b$oDW@r5?$uHku(2Z1BngzftDqPn z1cp7e8Lz!FL-PTk%C+LYV&JZT{Q%>!KB_$#HVFnrV22%QU{p%^Uekw<`~Vze6`&D$ z*CWBmFs)iOLXV3ik_0=m?|Ia0qg2RP@@LOz8U6|LmB=cYhVX7M{@&PeDO43mrXv@_ z#flo|b8A;AU5$4|seiHn(KY{M@hax=ab+=Gx}CIcG)L`&@EmSy(%##EwCW_6a&9ct zn!N#j;J*gd-!z~B{9w?rkeB4}y<@y%R5c|Ugr{FXgm-nF8Pe-^&j#e@Q(z}Uo@jtm zK<-ff7fL0wyzYPg->y^_O<1_# zgauy)h`IVMfY~*Z`6d=oQ-4AhZj;N(s_ARI`uE5?C8VNnTA3A!8Q!AEjq#SpWb4 literal 0 HcmV?d00001 diff --git a/manual/source/classes/applications/canSAS/Q-geometry.jpg b/manual/source/classes/applications/canSAS/Q-geometry.jpg new file mode 100644 index 0000000000000000000000000000000000000000..ecde6d88daf70a32c966d9d0cff0a05eacbf1108 GIT binary patch literal 12380 zcmb_?2Q-{r*Y=DaT|^(FNAE-@qD7C+2qFk$j5fMRltc@I(V|E11f#d;M0BGQLG&(4 zB=|hf`#$ggyx;$=@BhBF{xfUcYtK3NoPF-O_ugk;*V#8SH`f3MTRT^%jR(}lnc3w9 zvxkEnv#s3=sI#3dv%Q@Q+|I+@_qNm8G(&&*}*?!oNs;tpee?#ukd&clvb!wwF$cIF1$>;Y1rIJkJYARJs=nMDPJ0FsZ? zwQ+C&f3yG)mJdMl|KmbHSbhMazv%~IJ^4@HB>)5>LPBCfl0qVYn`HpGhN`+M00;yC zfVUsO%{)K}fQN&Nhl_)Uhl_`gk4HdAPDps?4&gmgGGcO?d$hDP_o%7q89A8f8Q4J7 z)XaR$Z1*|2dARAA_=WhnggCgkx&D|0h>wp?NI*zQNJz;=PfgGDziv0502BnkJ3urx zkQIPM0mP;N-gE;PZx@LTzy|)Y;D5H;Rbt~1U;*#k4x5kzfY{hTTx?w2d$>fne?Ao! zHV!TY9{ybxVMR(k>wBysZb4Mk`f=F=G;E?`l8=l{p1TLXLB%KJ)QnHCD;Xdhe6_U(KW*c1Q-z^Mi+GeLMDD=Q#89P4kQU|(aI zP5L=rZ7zF!AXb4RzqN{Shr{@^qjc$_R&>}UU)lR{p`({0*euQEq`l`@D`Obz7QPyi zyy^j&snYxpWdUuWsRdh}4!D!(X#AQHa@)9W5qXg7DoP3~$I7g1r)9mZ??ueAm%E92 zOy^QWxqRR2$hf*E2J=t`?Z=%n9RlpA4Y}^M#$nl~D?TV6RI^52>A<00#+R(*YyjLZ z(oz&AlVI^WXKY;P)q?J~8$iltyIfCOK+850X72`Y1K|0{I=yGV4Lh4SWtQu2ui5gO zJN$jJSL~1xW4udp1EBiBUF-B(WAX>;br~e};2I@5e@*B~9Z+_qR$tT{8yw(5BfTeK z^lgo@BkS6J^#&k?uzGY_W_@Xg>@gf08nfVt=$o7XGSwaxCzu(nt3Ne7WmPR}RXNp( zZWy>OG}GifV2=)n_SP9Gb%G!hJcn8*R)278Yu`)kj^Hi!R(72Or!nc2loiNfjJMyD zbzgK|$tX`SVWx+;_d}7s1ZU!JAG40Mv_G;uyCOKqqzX%c?~49XvZ)~cz2C>gvz|Xa z2g&hzBd~#={bsL(`?lz!9-ZYBL9#CS4&DPjtV+Y7Q8a z9|w)D$12j{c&a>%j@z8Oyu<&Y$F{5liS!fFwZs1IwdSt8r1b>})5N3qKKT^V`r4R9 zTs#3%czdCsc>G>j8Aw5nqx_J9O4On0SdJWS(VFwk{ahm-?Xj1`C+IOe%+Rz!>a!l$ zn6r|HQitZEd>D0kLoF!NL8kr@AbF0@f7)8ZHfLxm8^3Z@4}));8eY&I7pbz5dFYr2 z94Ci9L)U(9Fhp4xBcgtX6W}bCY%fnZ-iKdRK?m$&V-7h2KPH=0>ETxv)+H9v=p7Vh zeL&fBK_|)RN)9UeFHD)0S+bPpSx$aZL50I|;oJOUO|}q7FOnVQi~A(=)W2=bbQNAO z=WAlr)2hdHfTRrUSlE)h+AuotO!!*sfhLoxGi#O@WKu6l$DU(cVzagh+}=Q6g&Szp zLWTvMG!l0jTB~@&)F9iI?5#glj$IM$9tpz>=ixD<^A}}=uQCas*-nOIYQ)-W{d4qV zyF_tR_V<5sH%hs8vhvaX;d_Jf4l)^?UkmoM>M@gJ)dkHpsT#f(3=3oTki<*Qq<82x z&g5$qXQoOT<~^fvOB|ab-`VvHza7)%&7+VN9)``Q$MrPlk>dNyQP=AWr-ppb*s&se zx(LOH^T6RDT^5%%f>GY5a;)L+tULblb;6}l$*s-69~o}-wOMaqEF?c4L$E&VD9%0T z!au7|RhUUozX3dI=S{lSzp9L7WnD7+>z7#lo=M_NL)f`a&E=@19yRgxT>SV2f60zh zNwFBn6faNlW^rCoc_xpaPp=hUB{57bLKdsHj@z?-+oE8P>`7fkrbfheZf@=~FEI4E zGfp&gwP`gZ^Y94+F}dIWeMhq71;FHF z!%@UPw+!a&b?J}x@=q8ks`q{A49jAOVH{?s4v7`g1xQ!EfRaR-m7lZtV@{3eYxJ5) zJuL=DqQe^F(gX3eHW-B}lgqhnTNn3eWb)hSQwKHEFC|)Rl{bL#NVQlt*>D`Uht@X$ z(HGsS8If6r+uP4vbe*plLFJdRU|rYi(er?q%H*6ea@_TRMmXmJWBX>4mu|C)JqzZ& zB=%?7={3)8^9pe7R>&v2*V1)qE*Occyr(c2`gEIqzQ?dyZ$ev%*DmS7B}+8_V7)0l zsgyPFib};`RwbZ!wWbv3yh*x=Hy3J7q9yLy#Em_>PD9;*B~kC)szOfPee16jfPcB} zA0jT9*6YmE(DOTTGcsMxm*VmVyZc#=AGw4^5Owdof)?1C#(S*j4p6d6TxSvkx4}<` zhsyZ=u$^bb$MAP%MStuU4QU40C0QD?E8=|5;>Pf!&(J9B@O2>b(IFQB|LcP1n5O3? zQ|I9Yl1Z7*MQ1-xBxRW>Eo<~VKxDfd!S62ZUZpcQr ze>$*VzE%|FHAZ8+<(`cmlds+}(^h%>1z*>I*T%-(Rb+!4PrVZx9f|c00(IPaBL+zt zFyLOMBYCOoc81UW1BM5I#fFDJtJpz7_s}M?cL(hPBoDRC{HaVk@0?FMAwCz4526TX((ihul?&&k@&)fI=xF$Sz)XJBjSO`6 z;K&EHQ4S<9h!6l2NVN6mMnVBFt(a_U;7@pE{_A61e&n9!PVlVS_x5H2lHz}CHUHUk z)f~p?HFy{mX-~>d&L$|P5?9@wF7VU;9B;ul!#*Brd4KR6q@odb^kkLMd6aiLMeh8N7+b2k%F92v$ZpG z!m+Gjs-ZdwMKi)1I6&gS{yWH5z(UQtXtKsp6{D{1ld3bSPIqbgE&SpT0RTLU0@)r} zrp>A3lw4(3KA3mAPL{<{9(QY7R;m}B@TXnviafTkP&PCe!1eFpP`3AaTp}NO240zd z_SSf7h~wj>U?9BAvFW&ZZt1Ru>9>=S`K@y~ikhL)aVxvf`Pa4{G$yhAYtTzvr5NUM zpQ`Swh>b3sOrj^2DihMGN2U3;)J=51QF>t}nsiRYE}f+EDTmIw0!opm`NX6JIfX$d z^4=;8rgpL4N0@DVE;3a4r%xwVaoid(Au6`!X=4ZLqi-#UcbC`+eahDiJR35_@gFuZT462erl%0 zX!e0b2PMCyuLcjjg3_m$zxX&_FZZUlBJN__jG zIw-E$^GFs8d(IDZS0>iIHgbzd3=3r6H439R^zMI_%7WuC{< zk4m9*nXCDg>YDsY<9E}4+QC8xKh9>+U zt+HHU7VV74rBy0+c~UmqK1|<1mIIBQAzCso;6R0Zd4r4z<-D(%}EyX{}|OD@0PF$#lsU0X%KTI z`WQ}{xH7HoohybJJE-xIL*kP~td9AEBx}2}L649V^*mX;#Wj{-Mns;2{|gclswa1q z>;SI#%(b7~T{l4(*;2?#rbE$k+Y{A|={b-iHrAZwu=+NcEefqp zqECe~@KFj^tDYSr9{00N5q^J21Nm-_+Y||D%4H5_N%nG+RzvjRq3;F+dFcW5(;TR& zyU)eX8JEXZ;YL0qn^SB#ZH`TZ$YBy2yCjs-CyeL8Wc0abHs;NY^OV_JW4KzP4GX_nNTW9r8 zrxhWm&ksFNdsVCGRwr*Vt|O7_5!=S9w%me!%op!y^_2Rv0{_*FxqgpV{%MC(?(x^f zH+Yl(4*UK>fW@hG3ht-cIX{-jjh|yo{d~KdGWsTu&&cR7LrO3ig9AUvh9Xf2kKLP8 z@85UQHdJo_J^qk@ND<`sU{T~I`Xy`3#Poejrw2Rf+6#7evYx=gH1AYWvhd-1!5g5= zTck;}R`vGV_i{mO;LHlv<)5fRMREFL_TCl%*C;`s8S}KT1D(&H5*RM;*C~4SzB{ln`r?)n+ zG5YXpKNrzAdrH|_U2X$0KBt%$|9n|?Mi42Zx9~Pg*FwOqc_lIllCgBvOJlR9&y$}S zs)p7sU*L8=t&0}EM;@uJb$41z=8@$RDX~3ENL;dgxU6((Xiueg>2(aM{)rZk?QtVp zVbShf7oRo>9m@yeu(Rl8{2b~#AAYoUnJ(t$yghb4M75!hc0-U)5rYAJl8nE7v05!0 z>n9-P=*fE&1W;(Mlb(==11-26GNGZL=Kj*_dc=A~#zH~6KHugM_mn9j2@w_}`1>at zI{cm6Y9}i*v*6N;@-Z?OeCZ7_<*Tji5;rCWh9lm&9E&h`Iod;E)^HMY4Ht{M0W6u+ zdWFSq&ifKiSUAGY&@LPejrd4;=?1c86CM?oJt&ueBfnbL zPdw49Nq8b8M!Dn{zv8YDuhOveM{;6ycM!zCl(=i-Yu5(^o`n-Ile?1{ja9VF^Pjrv zPcJwWmpBrTcZu!UtZ@dCK&9lnalj!r0M2(6nchHX@nQkfW;N+JpO1t<)N7A&jZ*j9 zG5FmPV@Vay{G>(BsH$~`SNDJF_Le`!y2vzL4puMlH@gQH^iOxC2Mllo6qTE~B<>**kN{qq{d*wr;+#K^g4dvFVyG z58YZ0c@7EtOr(@G^MLO}aPPgUtm>UJ!I6~A61HlXXYr>VH}s$!BV6=C{*H2`7f9Mx zl8UN~dwAM2zhdwqqd-&@#@A@Lws6zPlY|y7>kLj3@eY@ylY98kQCbKiqc#)W-HIs) z#+G`WXS+M!ng#l9*Q|fJT&MTbWxsPSiMLj;g2;|3>3Wy>LEhgoa?_-da6ltmIL=^N@p9a+rjBCB)JWkpdZwl$Bp zEGJe#$8wRL2>U6mwV`$G58>}{9^Hn3>ge)4aEx+x}ds&FVMoF2SUen{<7R_9V!%ZM8=VkPZ3YepPH zb{s)Rg7b{>$9*jPRH?>K$rSNHq0!X7Hie<;g>i9844O;l4dUevbnNl{xKA4OWgxv{ zrWU&SwBLB&uQu$2ZuKu+2)W{ezAk^&A|83TO;j-4W>2UYJ*sZxmZ_%Zke}rrux@e% z43l*my7;z!Xz=S{^~6?ru%oY_09<>nAaKCKjG6Rht~u6;<z#N`7-WIi+fOv& zi;QIJZbUs^|2e!o5%s-|izx9W2H#E^a%#HKRJSzf*=gTC{;h$Nv%B}_EAd>eXcH&9 z5p_#`>klF&k&doYQO~4B#$uuaw#`tDaF>4W{xXBe-!?x^(XvE>A-(^0Pb zL!Pomp{3S57`lnG?&3$TDdPb>Jg?<+4PIg9StV?QciF@c6O-?=*RXQ{DPT1T$z>ao zMY`eq{K`}B@Nc2>1p>y>wBfKUkDypQG{w3arR7s~Iy#wh(C=O6G)HD4s=4H8-0GOY z*Iv|(8x$wSQ5fM1{T$D$ttgr;dmjy$%lL_Zv;U$xN{VDGbXzyM;dlW znb>9Jqj+0SkGAZOM4`#CAr3i10kTMkVNf4w?hQc57fhrv&A`#BZ&Bjt(aJ0E;4;F3 z7dp?&nuN8Y?ve=^AJxT9Uk#PC?V77IDl6R}E~@K-#jyE7n%;j6nhfpU*qD5LiiD*} zQ(35SYzGW?bvLn2K*x*qxQg;tCPrvsv^&4klD?d(W9IaU-h8q3jBA}d)w0jwa28Pu z!mYqAIFshp4;;OG9{+gjqCCOHqtItiY@gO+TqZ4is~;c@zy~`9c$j>-$e766(H=dv zTa{gvQ+OEOW*ZkL)TUM&1zK1Qq}IkC7wna*7Lu317dyf&WUie2Cnrh)q|BDwW^~XM zc7NM8!d57GyOC9Bq~*lemwLWoBK3338V)ME0iY{1vvofs%LQ2p!V9!mS+P>kaN;W$ zTsg6($Ro$x@USMLTi%MdqaP6g zUC_W5U`L+-$QTt)SXVS|xns3QvlD z4V;U6-Y%uNv1ny}-E;$3)lJVo*{>|W0a&~~`XH9^0eVt`hL3+9V7Qm42k29f$=-8C zAdo2zBVm3kdDSE4Wq8?*ACSkaR7)kk+G9QMANLx*GA+^?r?i=D@qDv-9^1K|vBe$4$`gdCbokcSP6z5d&5+v; zh0EdYO;j^@podEK@>#O08nZveZ}avU-6eR2GV$Ysx}D)}6NovPz!S~TLrdygizK-0 zx-SKQUr_f&TgZLtleFar+=|3I_ z*E!c#cAk361{1u? z_5FbQuF4#`YVP87=na2t3Rd&ZoF?`c?SM-#t{GYR8NG&I#{WpT0SxH=O@0W8GYZ%; zx~kvS9XGfEaLD~l20E%3o#&gJeJxf{*ZrOFHxakk$b%{EL7}~|W#LaVhW72hPiX<+ z$Gha_`Kn!V%Eo9ST=f1d;TmxcS-9eCEWe1QQT`vV#SF^oDaR+&2DSHaA`uykK97~- zdkNM#p#Lny^9z%Qs@G^=(*w(dxQq*7$tgId6xA0sbV`WR} zMZLC_M=>%9MUgzf@`>@2cYHsvJ5v*D+T65pX^|hCB{H`c#xJ@-B}#@RpCo7LEx^BW zk5gZ4%67OSK4)g8;AJ)zvX$~P%_S-A<-6*J6zr0nOx4=pKCE8Ml zcc88_vwZ`g=4N1Px2rID<4Ou81%!MG!H^_4Hi@(8%k~uh1nbYXrFxZN5)zP6ZHqeV zlT*!Lmlvdvt_x>?&GG^G9i}wNt?X1YZiu5K;h+P*^&UI!BTllI_keq_@dS6T8le`3`6sSS3D2bt3+GRt+j zl5^s+Oxo`e9b>K8L#}IzD}--SA81pqBxaAb=2t+s$!;@e!Ia}o20r(OCWz_FNHwtC zp=9UEO9Y*9`B&9Q{a_mvNx}Tz43GpmE9l(k@J- z=ND<#3gg0kL+1(eS+nwK;MS-GHwS)WWx}JApSPC9<4tsT;L)~Z<|9^q+-FVokV}|R zT}fM$;-8?VE?eCk-uXtNXQk3m)3+sEe zuhduDmSd9!BJA?>T#|S@CDGzB zzl756E98h7N#_l~Sim!m{9@VGKjEl3n|ZAzq(7akwI5d}x>bdPbM*VpHQ!i1On-53 zu945$?RclNZ?L$y_lVue-yJ)UjSWBYQrUuSg@wYfuCNG(Zi^~ug3Rh{7ibd0_vW7V zhV@U~eaM`p83u;oeKyQDb}J+`@BEcCX=#=W^;=Sp3el5i*74`s+&ae(%b@e#e3$>UKSI$Lh3?2-n&X*AhQe2?Z@!)zroNk<#?aSXRo?)9`cVIREy@r1nc}Lf z;@a~6G@-w4pwccqoNdc}ZCaG~-fu=C>^Dt-$AdCNO|%k|SuqpfNW?err87}m$-)`; z;u%4B>AhPz>7R$YH34OC%B5y=r<(BZty)9J8`0|qLdS?O6R@O9s4g+Ss=l6?U7C#a zbZxGS3*&e)!8p}x2WlEeID;p;8#24`PAEBDOrsCKMxJ5Facj5amsznGN7Dv^-_vGM zOkb{?giQGJ#ra1mTT#ve1d?zj?~z_ctqGWe=CZ(N9W~}v+RR`iUQ&B*oH0FqrYtRb z-hJrsYsGD)Ri*~cwa8Rp^8qo>Z(Au&rC%@UQ2_wie*l()Nk)vIDg}wO&Y`WhUYv7)?uV2h+Ppa3#Bfq`;TZ;4Fi#!Zk-f*W{bNoWLrtw|{Jc*x5H-P8( zWRCGq>P>zXq93z@o>h;fFfQ1qe`}lSV`xRa6)S!!JBTm8Zk8#B#mdj&`WF)`$Om`- zYM_X2?hZ&t4Om{3a5JPg!Oz5la{B@*9Kb-o3|DP6O*t(p$_XV76?rX@*1#s&D8_N0 zD5TGmVqAS0v*|JM$W*zJmI*T-*vWM!9aZ*j=DApO!MLVY0(#G>!iDp(PfLvXyO>%X zR_^o^^?^otQ)Oi#Uw>Gl=PEQcm}c6f8c!WNJEB%ZJlZ9`r>7hrd-&_wcf{^AxY{fG`PJ{HncU)i9DYk9c*7&}G$ z%;>DS=I{p448E4`jrzgiqL1=CoKCLr*YuMAy-`(=!}`(Z4=5Vc@R^SuMf9uTi7r8Q zL)Pvb$bz`Ms}ezxg$iWX z;(8B(lr6;%o7df^vi^Z<Ms*&z25L}le4y4TvO z`$6;Y_@G3FHS%F)18UPf9An>WD9jhZR;Xd{K80M;+msfy1@s-hvt6KlMi@b zTbM!FC&<01Ba;Aj^|?Zr7j0K0 z6KwK(j8B=UZ+4Ln^zmgzyMP5Gv0MFE(iq0deFSsLr-zh<;9DFR76;J;$yM_15g?lvuTC9tj*N_` zpb%wm?DHLQlR_-`CQG8!We08<+zOiiiHH6HTaRh{`$HCfMHvu*bi7d}y`2{;Q7C2o zRgScjMN&2ov;;foZFbI^<${m>h6N>jBK3+E>TdaV+HEC-CEk}J9nAh@MM$EL4bBiw zodupOBmQbGUaKvmvBt@o=4p173iA3qoFoDUrOG)gho6t% zz3Uzew=%r1$il67_hDvg0JJ`D2mWx#7#sb`lQYc*b{;?_lk27R9BZCeTZGO3@!Xvu8 zn(UFrVd8tT9r!_n`2vYe=18%jt=MsooW_US?^hYeTI4Dn4&8h}f!MT-tX+}Gs;YYW zn`4iU8J+fVw)&5{WG33>B|r6*a!$3)7ka9wVNx?u>ENVarq)c+d?@UlMR2}{3a$oG z6|O2#m9BHBQZi1sf z%k;>ft@pO@uTkAC@4b=gOldJ^0Kb-#ltWw?oy$^#bAvq+B-*3FMgQO@b^9c`;zR`o z-4{NW5k4dB3*V*7>SWyZeNxO=?XZqP&Y~$Ol&2_YR+naGHd;H%90uGZ0p1@J^h^TI zMlp{!oyaj(_V^y}5ZJ5GeUI+&)R#mjBf-0U4j39s@zcpV9-Av80xEGFpFuWnh7}y= zLvN#Mv3!Bv8NKudHNP!HHhMfYE#FR#QBrb`Ggi29e_&@hC#Usk#e&#kQjWt2&tT{& zqvR2ANJOEFcu|1>VNe&qVpnTK*k4Sd(oO6Ow^`Iv2)`?f8e3iJMG_aNO(~9Y?*x?Eh#P8X3 zR?+$gxs1y`ubfy{5rgrzI((nn!`f~#n%b~WyxaVUe7a-DVpVbJ8in&M2U*&|n#HlI zIi97}Z7jaT{`srU%HI?D2cFEwsGJ9SAN{(AVb}MmUaH`_P(o^h)a`0a7G4z;Q(N1M``&bl-QDq-E)fXCleF5$F9Jibj^6zFQ2s$FhHK%ZjVgpk&iLHVu nPX4HpvW3HF$3km!0i??` + I : NX_NUMBER + @units = + Q : NX_NUMBER + @units = NX_PER_LENGTH diff --git a/manual/source/classes/applications/index.rst b/manual/source/classes/applications/index.rst new file mode 100644 index 0000000000..40a7034d5b --- /dev/null +++ b/manual/source/classes/applications/index.rst @@ -0,0 +1,187 @@ + +.. do NOT edit this file + automatically generated by script /home/mkuehbach/SPRINT06-GITPAGES-TOMMASO/definitions/manual/source/classes/applications/../../../../utils/nxdl_summary.py + + +.. index:: + ! see: class definitions; application definition + ! application definition + +.. _application.definitions: + +Application Definitions +######################### + +A description of each NeXus application definition is given. +NeXus application definitions define the *minimum* +set of terms that +*must* be used in an instance of that class. +Application definitions also may define terms that +are optional in the NeXus data file. The definition, in this case, +reserves the exact term by declaring its spelling and description. +Consider an application definition as a *contract* +between a data provider (such as the beam line control system) and a +data consumer (such as a data analysis program for a scientific technique) +that describes the information is certain to be available in a data file. + +Use NeXus links liberally in data files to reduce duplication of data. +In application definitions involving raw data, +write the raw data in the :ref:`NXinstrument` tree and then link to it +from the location(s) defined in the relevant application definition. + + +:ref:`NXapm` + Draft application definition for atom probe tomography and related field-ion microscopy, all summarized as atom probe microscopy experiments. + +:ref:`NXarchive` + This is a definition for data to be archived by ICAT (http://www.icatproject.org/). + +:ref:`NXarpes` + This is an application definition for angular resolved photo electron spectroscopy. + +:ref:`NXcanSAS` + Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. + +:ref:`NXdirecttof` + This is a application definition for raw data from a direct geometry TOF spectrometer + +:ref:`NXem_nion` + Template for creating draft application definitions for storing data and metadata for experiments with scanning transmission electron microscopy with a Nion instrument. + +:ref:`NXfluo` + This is an application definition for raw data from an X-ray fluorescence experiment + +:ref:`NXindirecttof` + This is a application definition for raw data from a direct geometry TOF spectrometer + +:ref:`NXiqproc` + Application definition for any :math:`I(Q)` data. + +:ref:`NXlauetof` + This is the application definition for a TOF laue diffractometer + +:ref:`NXmonopd` + Monochromatic Neutron and X-Ray Powder diffractometer + +:ref:`NXmpes` + This is the most general application definition for multidimensional photoelectron spectroscopy. + +:ref:`NXmpes_ARPES` + This is the most general application definition for multidimensional ARPES. + +:ref:`NXmx` + functional application definition for macromolecular crystallography + +:ref:`NXrefscan` + This is an application definition for a monochromatic scanning reflectometer. + +:ref:`NXreftof` + This is an application definition for raw data from a TOF reflectometer. + +:ref:`NXsas` + raw, monochromatic 2-D SAS data with an area detector + +:ref:`NXsastof` + raw, 2-D SAS data with an area detector with a time-of-flight source + +:ref:`NXscan` + Application definition for a generic scan instrument. + +:ref:`NXspe` + NXSPE Inelastic Format. Application definition for NXSPE file format. + +:ref:`NXsqom` + This is the application definition for S(Q,OM) processed data. + +:ref:`NXstxm` + Application definition for a STXM instrument. + +:ref:`NXtas` + This is an application definition for a triple axis spectrometer. + +:ref:`NXtofnpd` + This is a application definition for raw data from a TOF neutron powder diffractometer + +:ref:`NXtofraw` + This is an application definition for raw data from a generic TOF instrument + +:ref:`NXtofsingle` + This is a application definition for raw data from a generic TOF instrument + +:ref:`NXtomo` + This is the application definition for x-ray or neutron tomography raw data. + +:ref:`NXtomophase` + This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. + +:ref:`NXtomoproc` + This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. + +:ref:`NXxas` + This is an application definition for raw data from an X-ray absorption spectroscopy experiment. + +:ref:`NXxasproc` + Processed data from XAS. This is energy versus I(incoming)/I(absorbed). + +:ref:`NXxbase` + This definition covers the common parts of all monochromatic single crystal raw data application definitions. + +:ref:`NXxeuler` + raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` + +:ref:`NXxkappa` + raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` + +:ref:`NXxlaue` + raw data from a single crystal laue camera, extends :ref:`NXxrot` + +:ref:`NXxlaueplate` + raw data from a single crystal Laue camera, extends :ref:`NXxlaue` + +:ref:`NXxnb` + raw data from a single crystal diffractometer, extends :ref:`NXxbase` + +:ref:`NXxrot` + raw data from a rotation camera, extends :ref:`NXxbase` + +.. toctree:: + :hidden: + + NXapm + NXarchive + NXarpes + NXcanSAS + NXdirecttof + NXem_nion + NXfluo + NXindirecttof + NXiqproc + NXlauetof + NXmonopd + NXmpes + NXmpes_ARPES + NXmx + NXrefscan + NXreftof + NXsas + NXsastof + NXscan + NXspe + NXsqom + NXstxm + NXtas + NXtofnpd + NXtofraw + NXtofsingle + NXtomo + NXtomophase + NXtomoproc + NXxas + NXxasproc + NXxbase + NXxeuler + NXxkappa + NXxlaue + NXxlaueplate + NXxnb + NXxrot diff --git a/manual/source/classes/base_classes/Makefile b/manual/source/classes/base_classes/Makefile index c6f740bd4c..659d88399a 100644 --- a/manual/source/classes/base_classes/Makefile +++ b/manual/source/classes/base_classes/Makefile @@ -43,10 +43,10 @@ all :: index.rst $(RSTs) $(TARGET_NXDLs) index.rst :: echo "Adding summaries to base_classes/index.rst" - python $(NXDLSUMMARY) base_classes + python3 $(NXDLSUMMARY) base_classes %.rst : %.$(NXDL_SUFFIX) $(NXDL2RST) Makefile - python $(NXDL2RST) $< > $@ + python3 $(NXDL2RST) $< > $@ clean :: $(RM) NX*.rst NX*.nxdl.xml diff --git a/manual/source/classes/base_classes/index.rst b/manual/source/classes/base_classes/index.rst new file mode 100644 index 0000000000..7840e46345 --- /dev/null +++ b/manual/source/classes/base_classes/index.rst @@ -0,0 +1,312 @@ + +.. do NOT edit this file + automatically generated by script /home/mkuehbach/SPRINT06-GITPAGES-TOMMASO/definitions/manual/source/classes/base_classes/../../../../utils/nxdl_summary.py + + +.. index:: + ! see: class definitions; base class + ! base class + +.. _base.class.definitions: + +Base Class Definitions +###################### + +A description of each NeXus base class definition is given. +NeXus base class definitions define the set of terms that +*might* be used in an instance of that class. +Consider the base classes as a set of *components* +that are used to construct a data file. + + +:ref:`NXaperture` + A beamline aperture. + +:ref:`NXattenuator` + A device that reduces the intensity of a beam by attenuation. + +:ref:`NXbeam` + Properties of the neutron or X-ray beam at a given location. + +:ref:`NXbeam_stop` + A device that blocks the beam completely, usually to protect a detector. + +:ref:`NXbending_magnet` + A bending magnet + +:ref:`NXcalibration` + Draft subclass of NXprocess to describe post-processing calibrations. + +:ref:`NXcapillary` + A capillary lens to focus the X-ray beam. + +:ref:`NXcite` + A literature reference + +:ref:`NXcollection` + An unvalidated set of terms, such as the description of a beam line. + +:ref:`NXcollectioncolumn` + Draft subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. + +:ref:`NXcollimator` + A beamline collimator. + +:ref:`NXcrystal` + A crystal monochromator or analyzer. + +:ref:`NXcylindrical_geometry` + Geometry description for cylindrical shapes. + +:ref:`NXdata` + :ref:`NXdata` describes the plottable data and related dimension scales. + +:ref:`NXdeflector` + Draft class definition for electro-static deflectors as they are used e.g. in an electron analyser. + +:ref:`NXdetector` + A detector, detector bank, or multidetector. + +:ref:`NXdetector_group` + Logical grouping of detectors. When used, describes a group of detectors. + +:ref:`NXdetector_module` + Geometry and logical description of a detector module. When used, child group to NXdetector. + +:ref:`NXdisk_chopper` + A device blocking the beam in a temporal periodic pattern. + +:ref:`NXdistortion` + Draft subclass of NXprocess to describe post-processing distortion correction. + +:ref:`NXelectronanalyser` + Draft subclass of NXinstrument to describe a photoelectron analyser. + +:ref:`NXenergydispersion` + Draft subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. + +:ref:`NXentry` + (**required**) :ref:`NXentry` describes the measurement. + +:ref:`NXenvironment` + Parameters for controlling external conditions + +:ref:`NXevent_data` + NXevent_data is a special group for storing data from neutron + +:ref:`NXfermi_chopper` + A Fermi chopper, possibly with curved slits. + +:ref:`NXfilter` + For band pass beam filters. + +:ref:`NXflipper` + A spin flipper. + +:ref:`NXfresnel_zone_plate` + A fresnel zone plate + +:ref:`NXgeometry` + legacy class - recommend to use :ref:`NXtransformations` now + +:ref:`NXgrating` + A diffraction grating, as could be used in a soft X-ray monochromator + +:ref:`NXguide` + A neutron optical element to direct the path of the beam. + +:ref:`NXinsertion_device` + An insertion device, as used in a synchrotron light source. + +:ref:`NXinstrument` + Collection of the components of the instrument or beamline. + +:ref:`NXion` + Atomic architecture of a (molecular) ion (fragment) which can be used for example to label charged molecule ions identified from mass-to-charge histogram data as appearing as signal in e.g. time-resolved mass spectrometry techniques like atom probe or secondary ion mass spectrometry. + +:ref:`NXlens` + Draft class definition for electro-static lenses as they are used e.g. in an electron analyser. + +:ref:`NXlens_apm` + Draft class definition for a component of an atom probe instrument which details an eventually available reflectron device whose purpose is to deflect the flight paths of the ions to realize what is effectively an energy compensation. + +:ref:`NXlens_em` + Draft base class definition for electro-magnetic lenses as they are used e.g. in an electron microscope or reflectron device in a local electrode atom probe microscope. + +:ref:`NXlog` + Information recorded as a function of time. + +:ref:`NXmanipulator` + Draft extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. + +:ref:`NXmirror` + A beamline mirror or supermirror. + +:ref:`NXmoderator` + A neutron moderator + +:ref:`NXmonitor` + A monitor of incident beam data. + +:ref:`NXmonochromator` + A wavelength defining device. + +:ref:`NXnote` + Any additional freeform information not covered by the other base classes. + +:ref:`NXobject` + This is the base object of NeXus + +:ref:`NXoff_geometry` + Geometry (shape) description. + +:ref:`NXorientation` + legacy class - recommend to use :ref:`NXtransformations` now + +:ref:`NXparameters` + Container for parameters, usually used in processing or analysis. + +:ref:`NXpdb` + A NeXus transliteration of a PDB file, to be validated only as a PDB + +:ref:`NXpinhole` + A simple pinhole. + +:ref:`NXpolarizer` + A spin polarizer. + +:ref:`NXpositioner` + A generic positioner such as a motor or piezo-electric transducer. + +:ref:`NXprocess` + Document an event of data processing, reconstruction, or analysis for this data. + +:ref:`NXpulser_apm` + Draft for a class which can be used for representing a coarse-grained description of all those components of an atom probe microscope which realize the pulsing capabilities, whether it be for the laser or the high-voltage pulser, which trigger the removal of ions (atom probe tomography) or the excitation of gas ions (field-ion microscopy). + +:ref:`NXreflections` + Reflection data from diffraction experiments + +:ref:`NXregistration` + Draft extension of NXobject to include fields to describe image registration procedures. + +:ref:`NXroot` + Definition of the root NeXus group. + +:ref:`NXsample` + Any information on the sample. + +:ref:`NXsample_component` + One group like this per component can be recorded For a sample consisting of multiple components. + +:ref:`NXsensor` + A sensor used to monitor an external condition + +:ref:`NXshape` + legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. + +:ref:`NXslit` + A simple slit. + +:ref:`NXsource` + The neutron or x-ray storage ring/facility. + +:ref:`NXspindispersion` + Draft subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. + +:ref:`NXstage_lab` + Candidate class for a component or a set of components which is coarse-grained into one logical unit. The role of the stage in an experiment is to hold/align/orient the sample/specimen and eventually offer a controlled environment and further devices to apply stimuli. Having an own candidate class is justified as contemporary specimen/sample stages are such multi-purpose/-functional tools with multiple actuators, sensors, components, and thus also the need to store the various (meta)data that are generated with manipulating the sample. Modern stages realize a hierarchy of components for achieving these tasks. For example the specimen might be mounted on a multi-axial tilt rotation holders which itself is fixed in the support unit that connects to the microscope. In other examples, taken from atom probe microscopy for instance, researchers may work with wire samples which are clipped into a larger fixing unit for convenience. This unit is known in atom probe jargon as a stub. Stubs in turn are positioned on pucks. Pucks are then loaded onto carousels. This NXstage class reflects two layers of this hierarchy. 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. Applied to examples, a nanoparticle is attached on a copper grid. The copper grid is the holder. The grid itself is fixed to the stage. An atom probe specimen is fixed in a stub, in this case the stub can be considered as the holder, while the cryostat temperature control unit reads more as the stage. A microtip on a microtip array is an example of a three-layer hierarchy commonly employed for efficient sequential processing of atom probe experiments. For a single experiment though only one microtip of the array at a time can be measured. Therefore, the microtip is the specimen, the array the holder and the remaining mounting unit that is attached to the cryo-controller the stage. To cover for an as flexible design of these complex lab-like modern stages users should nest NXstage_lab objects for reflect the differences between e.g. a holder and a stage. + +:ref:`NXsubentry` + Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. + +:ref:`NXtransformations` + Collection of axis-based translations and rotations to describe a geometry. + +:ref:`NXtranslation` + legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. + +:ref:`NXuser` + Contact information for a user. + +:ref:`NXvelocity_selector` + A neutron velocity selector + +:ref:`NXxraylens` + An X-ray lens, typically at a synchrotron X-ray beam line. + +.. toctree:: + :hidden: + + NXaperture + NXattenuator + NXbeam + NXbeam_stop + NXbending_magnet + NXcalibration + NXcapillary + NXcite + NXcollection + NXcollectioncolumn + NXcollimator + NXcrystal + NXcylindrical_geometry + NXdata + NXdeflector + NXdetector + NXdetector_group + NXdetector_module + NXdisk_chopper + NXdistortion + NXelectronanalyser + NXenergydispersion + NXentry + NXenvironment + NXevent_data + NXfermi_chopper + NXfilter + NXflipper + NXfresnel_zone_plate + NXgeometry + NXgrating + NXguide + NXinsertion_device + NXinstrument + NXion + NXlens + NXlens_apm + NXlens_em + NXlog + NXmanipulator + NXmirror + NXmoderator + NXmonitor + NXmonochromator + NXnote + NXobject + NXoff_geometry + NXorientation + NXparameters + NXpdb + NXpinhole + NXpolarizer + NXpositioner + NXprocess + NXpulser_apm + NXreflections + NXregistration + NXroot + NXsample + NXsample_component + NXsensor + NXshape + NXslit + NXsource + NXspindispersion + NXstage_lab + NXsubentry + NXtransformations + NXtranslation + NXuser + NXvelocity_selector + NXxraylens diff --git a/manual/source/classes/contributed_definitions/Makefile b/manual/source/classes/contributed_definitions/Makefile index 1031a4c2e5..4b8196265c 100644 --- a/manual/source/classes/contributed_definitions/Makefile +++ b/manual/source/classes/contributed_definitions/Makefile @@ -43,10 +43,10 @@ all :: index.rst $(RSTs) $(TARGET_NXDLs) index.rst :: echo "Adding summaries to contributed_definitions/index.rst" - python $(NXDLSUMMARY) contributed_definitions + python3 $(NXDLSUMMARY) contributed_definitions %.rst : %.$(NXDL_SUFFIX) $(NXDL2RST) Makefile - python $(NXDL2RST) $< > $@ + python3 $(NXDL2RST) $< > $@ clean :: $(RM) NX*.rst NX*.nxdl.xml diff --git a/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png b/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png new file mode 100644 index 0000000000000000000000000000000000000000..597cee834c0426bd0e60b1afbf6554a5f3b04a99 GIT binary patch literal 7089 zcmbVxgT!j8lW(I7CP9R3l4E<2>J5 z)AI_IpP{<#g$8#av2ACx&qHz?7*6{wc9+~vb1nw=8zsvCGZ@1U!ma35{YCTeb^go#}G;SGXdmMbu z&k(dLz+>M0rk*>Sf)`6r0rqXS-WdWA6B8%4ZJE%EdqQPyjwzkRB;aOHTl>4)o5x|d zk^nCj4;eIl%(n^F+aGp�Z2d70QK#NZGhGGt4!*DVv+aK@%#_`tEYYN5riu(%l4#$J*D7^Wj?wMl{e?}qh~ zY>s%K&(C)zD>TXgDhM0}O&=C2r+yy#K3pp3G_SZgw*E;r78oa{=-eoZRr2X4M1X%T zpwKhuUnefLT1P?+p*cUDbF;27;urNXIdV3GP9r`-Tm1Iz!5axr2q&_2aKHv)6R*sV zoC86Z4ZQcMBBg7vGph*EBH-3c92|H`VKT=wJcAF`QUTL~RppiMF@&7l+%|jh=q_Yl zl(4Ai%5;s*CbbwAZH2$YiG@Y5cQ^ujWfjnl_}!#bRb1n>F}OTlrVE!&9&uFk^!!4^ z;FHzbDye5^Xk#UxwXh=zxB3+h)q$p^rRmjVynV~|G~Rjyp=(MM0mu_vg>= zxp&taB#b47RTc~^Sn`WBaGB9RJ~<@SMf)iaypK+F>MgC7zsG<%r}Pqabh%S?=ZlnO z^3i`NU#PHfxzukcD5suN`yh?Xm0-C9poTO!`bZon&_&qD+`{Bx!n8>beH987Qkx%6 zRNOt{;*|T%y-h7HKpqjqJ|6|a$DY4jlDeCYdZAn2&+t{t*H<)>RWW_m=_B!yXoyoi~j%|VXyXk z04CaDLB0Woc^Km9>6tgSGvc<^MsnrPilHHjLv>{cIk;b)x=dF3^O!*;WI(#z7`=S_P(B*fsh&^#>LCqbFwo<4%S1-m5+rtCdO_86H82|ZC-J$ z^0QbYQ`^F#vI*`-R!K??acY7!^%XsR4*+eK%Hj)EVh@1o1ZacHTr3XZeXE%-cJZ^~ z?igTnbhO%Wgc-Tl^we?eguId(P0owu>bd@t3XpYIWGuOgQ3;QMy?OJ-3M_sY35mfq zuL>o*x~!TS!N0WzGR3%G{DKF@zLYPS60_t>W-)`#e=IG9h1bEVcPafZw@P#@ERv6p zy`y8B4KrpKCaWw_2M6wwSG%=MfhV6$c;?N^>W7f6Z-J zDZ9VEuFcES$qeV@;ra2!?iU#qRgB+afU-yn!0$B5%45;`0FQ+Jpvg1>NBLMTz?jA| z)(osl*JpZq(Vf!EzRs{Z#ZpRbFK?ztkBILl;4p?=3tZpa=+|-|^w7C6v9sgywH;Fs z5D@4!^2MZlIShqt{M-5$5}9@b3BTNuH88kO!XO#foj}bZFw%z41MhYee!kk11Oklz z`dh>Fa}3e4#Q&K^U0w$2y?M`4s?}sm*A~AeYh%N5dpXtdeQ1dE*Lyz0`5f+^M4G6z zHCqtGR@VAntA~)o{%h9k?(R;MI#dUbIHEcyL@Z3EPxQq*VzL9^&^mv_@!);Obxb`s0N9NAtehd-L8uV}6C42C7z=Ib>PI6$H_DA_up%NN{Fh^> z@6}Hj#FD_{!Tfx_zu5NJ|A5Ka53{$5E!*l!AM|fiPAus(m+^;m79F8dyynf(?=1rH zL1Z)>HwZHN>dAH-*ru$A9m`(xn;An7#+IpHMW`trs;7o`dodKo%*qNKlD;Z0@SS}M zHU)v8)BotDgVO^R+R17TGolBVnK8I7s(9m@l)VE3NI5x(eSbQnP-m9fpg%(h52&{L zb-y_Dz`Ik#*O}nHg zNlM)8!9#x}(&v1I@WQ?csp#Kj<(@;5C9WOi9N+_lr(szFV>MwNGCcRs0*lZ|JIVP9 zA=!WCs+T1Mg;0=m61V*fl8wT){%kq|Mn?2fwDZ(fo$MHgwK`?lUyM`_1(0Ukfxp`(RR^z-IUr-0Hi-PWow{Cu;JB3(UcuYs*w zS4*6aR_LvhhkwGVo|nTL3j)wU85OH)F@&*_VhEf6T494$f9%^o{wW)R-E2MjvGeza zFSC{4jJ5&0C5fpaM@X8+x{0vKT$s9P6dx_!2}!7${-?<)v7eVYfycvLXmo&twy8~2 zSzgxcRWV?%+mDKmCxGJOHY}zf zBEzVtsQQD4x4pr}DhW>kTOQr`_F+|Id_uJWpE4krDs1n$j^ z4~#^#*Vo<6%_-@S^o6&xx9o;ptbyqcres_rlnA$?e4mR+7B4CynP7Ygfwge$eLz}V zGHzyvt(_DOG`TG4bC_tSFx*_?tgdwH@@G^c9{#)#bZ|j__6fymYZZ3A(t^oZFRLDJ z<|7pqNdZ|D!)U?g&d%b-{%;MSR7p(6^ymT)h)QkekSh-{N&J1hTjn*>H)-(^OFEn3 zfYf#FlAvDXSZH;}`L!fzojkUZ-u6h1~<|ldl38{cs(Tz z^yf0hlCvn;jF)zoekSZnWBb{^yuUDabL6)Zuf3|k>+R2D zMvZ^Gh-lu&y-J9rKP7y=AV`reWqLvN9_W;5A}8f@GEIFJ>MP(|aY1j>ljymVg<{x4 zjTFww#AKCVyAHqe?wr(PU0Yvgn<*~*(cO)Zkf1efbUo?C5fXKog#!N9hvflQ_Ei@1S=cn*o&~0NkFVWeV!*?(Mf@_YaIXRWBoSN8N{9R{?_E)?I0Pl)- zSk3-lc6VCwGx2l6)(wj|_KY$|AtH*hpC?w_!mj9Eym)c1V@Ac9UMldOv9Ym=hDLYW znZ#o0TO2BlDK1H~Tb&O}SYUmu{fUFUp;BFPRH*QlWfB*sA(cD;7K8SsKm<0T%Jh2< zl25-sW)G5-%1!FyUy%-yRq84#LT$7pDM1{kASaKA|J*&W{>_j1Bet3!Q3ERr3${`r zxt8<=t9tQd$(x@834HBwAge03Xrmn&8TmB#UY;zXJtTXHv-mT3HX4_wdxXvk*q_u~ zB^KOt1>j_xQ&o(Mfjf`PTK&m~q|UNl_(H6f+C%*J+s^o{zeB+URn(uW&@u3)lKb|J z;p;&>2N*w%=;1HNUykTZO0!8|{kbxXs;a8Jy}g~u@F#jT#yUC?U%fU8K$QTFg)4oE z%_J{+UxjhaAyD}a+Cs@wwyCv08}-sKhMprLBO|M=zF~n3htt&!q@|o7$!ghePmm7z z=+^r^QYn-8Z8ux1OeYQ)J;h$WBE@i|1QQu8Z9J*;IbdgJ7r&Ia))|34-QYs^?AbGZ z=Sd!<%U1ubM*O7q$3I697l{b1@r}c zb#YGrIZ^e>4+;7>IyR=G?@1{o-#w>byhE2awIfv-SjnB5>qWm1bS$f`p7=skW1XFT zab*!&nTEAa*pl^45h`few>x}ywmtEbT}whUI9L)~CN=kUf=-|A2g^ng;RDWaM3N{S zftMEMw&v9*0uNO={Kbrmkq%3Z5NXTI?3koyUB@P}H98^f}=x3TKl?q2}O2mR_|A|nL zG%`hFHXWWohRc4KLB~t}UJ|dtfA+lL(mfBsorQsVS4B-NvMQG`*|mrnY;qfg*hFN{ zAVt)=7mvOnW!V#zSZ;&1_0}9V3d%PhmV*IWUO1bT7+5{`@uWt=L$Aen^UF!p7wjLOt42~RsEI<~v438pG3D_0z4+^UFEz|`) zvuD@Lii^O;!@>~8S9gxNMoiLx4hhjF6<`Q53Q7mdctdkR2MJQ(Hb3194@9I}(Z6jDB zJ-!i-Y^d~bBcC&hzN{R&7{>TGfa3hb5Hl;n^pGGf31?*`JccmBb>U5|n<%zhE5z0o zFs#D*K1$Z!-dX3=Ia(A>%e}X|NL+4)pCwH^KJlswMT6a+iTAMxVxlBhGDD=E4w!Xl zR`oTwY|rFK!#R0fgRZJNaIvu794Qm5yb=~B`#Y=?lD|D9mB+$H zGGJ}T z>oxbA*&q6uHWjLhk7x@@K%-tEY!@WtNf=nyYKLH|PiyahN^|b2kcg7p`!3!)O1;1M zD8B@WA@E4Zz66RO5QvrA8XNqw&$>ONTwlKIRz-bacHh*#f`TAOsjnZcp1tkwDX9tt zZ{qN8LFksZFmv_H?%aH{-5m}-3H#ct$VIS<=6#fu9l;H<{q^2lw`hBNw4T9Fhg>pw z-#_9?|jjKcL2)~hIOYm38(_cRw(@DuF$S@N9u3V*z!Az)-2&b_hHdUq^ z3xAG=x_$BS|6XF^xpYf4D&8f*`ZGCZZ*GH5cAFtri0_{bBW7wN&i!X;U;vBKFoUaB z6dC4ff2%rVim5w%$osJCH6|G^oQf{XGA&-h3Vz9;(IbvVh*_!@a$6 zyTloD+(iBw#EpzJ3i{pq)k`)&d?7g=D>&G!kx|lUUOLEtfpK)Sl+m;S2)lf}(;y}2HdDyC+iQAu1*gEi}#v~#)tauKr>f77x zt6>sJhdB3RN6g7o#Nn!O5c2@$o2<(txGSh4PEM)$;^+L99-&Aj;AE5vj1>sQN8#5B zF>QemN{)ubKP~$|T#CZT>1e}^Yd5Ps9XV5SNamaJ%QYO<)?X+s!HDn+>w zgkDCoQRbQqMq)6TbMKLEM=HzKk<4|35{?o}k|!F4XAzn)`Jp=2rzD#7Y<@KZ9_6xr z9pG^flGkOg=6S@9K%*$XI8h=F4-3p?WM;QM;o1v@ECrnoCksU7yJVMox*z0C<2SkI zpI;8id|nc0`Y*%L>%eNNE3z$!^6!M<_Bk7b8p6h(>7>O`A0 z<+Zv*G%oobe{*ED{dM1NZ?PGvV#``j4cAc7NNPgGz!Dkv{TaS@;b(}yo^=0#PGFJz zZnL536YPaW4f$FI*7aZ8k+WfKpLp58WA|%}Q@wZTZb|N&MlBd(NM`?fsxmB0elg5a zyhTfzYtn^Y>O}{*Xk9rgF>z5nn_pVy(}ezLUu)}VJ-yP^B{+!VuV+ohkm{K0X1(jcKbDH?b&>a_(vxDPrweFG!4ZAQaM@IzzoNjj}rA zDd{kJNtN8Ib6~C!yRUCI`0r^kQiz=V_+lWl4sGU=mKMH|Lz&xg`au%S7JWZM-(ZyC zY#>w0b+bZ4{R69Ou8h`8GW{N}ZKwn{hbDlMWY(nFn;@L7Cww3hUttM6+E&%TSqy$H zO&vQlZoeprsc76h-5UFw_||P67JNj!psA8~0(<040j;#8ZhWd1PAZ)@XY#1pN)8>I z64k46S?F;kD#aHQ)0rptsTt&LEW5MFr}iV=DwtlH#MuJc^?~}{NW{(*GKiKKp`5JJSn=tL zWw`ym#rh3c5D}+>zU7-!QKX}9Q^r3wOy16eEhKnz|J>v1gl6sbZ`IcmKef_PdcMtKNSG<9Xx4}|=|E$9hEynSWZfFpV5_G*B%drKT zf{p37pZB$gbas&@46(47YZbb@8iCPEJw!2f+^TU{;OoX*ofcVd4Ci}K&W{udOOZ=t z#S%e0z1B4hVGwq$;tgot*W3B8oi}G=XMrnFctcBY#-FJdPMc3$vx24TVrm__`JV{r zWa$;L>gx-iP}rwlo)7P^BtBUGJ-T&NRCFAm0y}ZW$gYQY;R;z9O3Hq_ZqLg}D}5gC-$dChBeP#=_&Wpc z6)^{U=SlU}^T*LAGHTrz*Ap~tFkB5b#KBBH*19n!!Q|!N93nX5?j!e>NF|R`ZpIhF zfmx@Ej=QHU&3KG@J$PDno7xgmx2veFAUE;jl8Mo>b>~UIVQ`vsRSAk>_BorqYgesWGUr@`D=W&OA`>A)AQ05o^3v}i5Lh$_1g0Db0lX8X^R58= zdf_PfS`7(&c_EpEf#a8U@*f-_5PbCK9~ip&QWWqep_7c3ld7$mldF+~Da6&)mG!fY zrK7QtohhrW!>5!(VIl~G0`gi~Ld`98f5FvDO??sJ_>&oD^1wR}x|gq!KA*>kW5EVw zuUbm{adpZ^)|#v<)Y9k-VZzhDP{*;_)>cuIo~8+KLbAq6P{#TvKm7Nd=TnVILXyxI zl%HESKB7158}lhreFI-Shi*ud+gI%T>QLF(*pdb}OAZlKLK#?DW!>D|G+hJ3hT`Qk zUH!BpqoSlOEG)n~d3pyk6^H@?0(uLmRDw!Sw1tuBKgK6BpE8`C`NC!=5?;L}APMt; zaR+}E78d4#hJZ*#MU@cM>JN@+jO{4EQ73XtfufD`t#80g8K5T(wmmSFzPQ|niIO#% zUOgN34?|k1wVv~&`)qK;1#&U|SUpzI;H)JFc+BQ?Po4OrOMFz>WFf8o z9?c@2ej~~&m*e?<85w(3)Uwse+1)OJ5mUdcTO9zA|L5vGqJP89V4Q zLZPB^_-L2eM9r>zZP#fA*Ywo1dUUg(N4JSGKmb1D~NPY=dncQ+j0(tM>i z71eHtTc`hR$-q0qBmFFo^&dP6g{;}xe&oJ58oC&mDk$LbTt#kZ%08?1cO#%9_&ha! z=6r>TS=o|>yj!oBigB55F8cCxgpz^-)9q%XWDg%xg|BN_+0eZBF}=T!_U223F&dv=VeyWm~`2Y7bj>l_ksTBB;}*4 z>ovbvbPPNMuVab10~F*RHt0m-_7C7u{h#Nam|r;$`Vz9_J>_!8qVvNhmTZCJc^C9eHBn(jF{TXU6 z?l($^k2k|5du(8~I>BrOzJGatj(yyL-BO_5hBy24PUxp~61hoX@4Ez(1+<<+#b!p43p z8BdoPDYKhnsF1fTi;HMzYZKAFOY%b{=1pDjr_WytMKR6p?dJ8bS?k)$j!QJG(4eesX z6PgCmwT@dZ*IPU0OI~NFi|$)#Xivgd3$Em>_50=ErSy0;2miqUYVn7Zd;qA)nY?!`;cw*oY5aGy9sqo=jkm9DvOR~@huRbmO4pY=SL?N zwlDEmw1Z?K@tmh`_-q%W@>PGkOy7iu{a7RU|6maK?^q;UR|f|S^2I<3A38CgjnzfX zf=y_ziKMr;NV?DMXXX#(KT$lUf}Z179x*)wgM_|*`W)}X#6;RS@f5$B#Q(fyCqIW^ z5HS5JEvMQ({`u=MzhXxrBt*Qkv!gdsIQgGoS_f0Cv3Dw9V6ddPAMQy~@P8o84&)RH zJ@4z52KTcv`?W5O*tr82g6J;R?Rfs@$ewMJ`Sa%scXxNag=k*;ynz1$@jtfY5CR+y zjOA2GaOcO*7d7oG;w~<{|Hj7ZGc`d}2mZ$yPP=$=!?CHUDQz12>VIba##{F9%&VUPR2&MNw#8UcrRPQcZL zn4j+>uW%t_Q9vFL@KtZ2QV~QJX=(4-d{xxvo65?fel%`8Zh=$DKA0>fjtWD<9p7zg zEb)8Z8@H(wg>V0SR>kGyvW&~HbrAJA>4aeoY;W=39op5e{!a+-9@4SJHM+YLq@gX~ z_@v1H@85m=kKKMd3Yh0OaY4kxqhYn69a&VQ9TY@wzvLaCeX!`s_R`2G9SQY7=L~xm z?my?5XZY&Ju;>I$pdq4dr>PUM)wE2R+7a-+n+q4&*L&U$d2*gN8(*etE70QO8Ff9a zk>0<*k4spMjHhm_ud{5#dcKVFTeAvMA=gPtt_nP&Xp*Z%CZ7w#i2~^t@a`0}U4>sf zr}>@@My2|spG|$bp_Yh{kZ1Z&4w_j7`ysnk(j>T}$PZ0CLG1rrj95w39XeMv(Kb8` zr~3Prnr8z2^JgCdvBlqo^|GJXpDz?@+0-2P`#02ek&t!va3gVT`JlL^%xE#;(lv9a z`+25GKX%6mS}p2E4-62QnDHJQu{-5~`^djO*&AT}CtwK7DI3lH>A@YWhW~qp_U%zo z`L~v{Oa30L&l^tAGC0`G#B`#~%yBt4MN(#tSqBd#`CZ=c%u&1ftctH*$1p`aJfto@ z&nH``x>S)pJ=mg_mj}gS(+xoUI;1Q6m+e-9AJb+!$!rg1E6cQ)i^*L1NqUBcWIa6U zex8x|ZW1OTBhS`*Dn8rJc<#-aWBfODxLVz$oMW*kY$r3z&uBt_@rx&&dEWlFD|$ZB zTUY%X?uQRNBYOumkGB}3yh_5DsG)F4+`afdK3;p&yLh{eL$JmfQqYMpE^umQ&lKc}o?D z5U>_18IE(-a%HA(c_0*wZ-R+!kT%NT{*!`?M{*w?DeGBx4kSxtTOT%yAz#gpq37o} z%`f>65e33kzE@R+%NgB1y(uVQ{8XQifR%Wl#)u0G3p?BB>#bmI%>qRT?B8NyVoE!h z_ZAZt5y2$r=^t!VP>9C$y;s>IahYz?n_i+6)j#0m*R>D6UUNFM;zh(k{-Eiaqsq>& z%oK^w*0noPIA>LD(u)NmOUK3;m)Sr|hzpUyUjO6cRkQI#fx2~-=k-eH$#FY+y_cwn z2x$tRtxb2jimTm0WoVgw4#uXpH*S*P1o`LBZI5W&HQqNH z5^hfqKT8fj{sz;Sn7iQ3w2s^U9sEdX1l`W5Y;)P>w)ym zTNYMJs)4jQbWL5%pugN=Q1YP%(xJq57%gTrH;)Jd5dtwEzIU|sXFggr z(!igi(JX|4xbSH*4r{E{;)seu(bi}6Y?(v(XXemt4+ovr0_nkyWZ-1D{Zl{viL z?0&xEi=5GzgE>oJJ7BXDJ@5GfMy8J+8|?O{;j_DSJ&UgyksOAts*Im}L>wHVMs}c| zM5B5Jd6sXs*6fzNi>r^n_xj-*L`jMJAtoen%fET=+W#xRphunnjWnR$B3Pj`v`xVq zDZl8`_m7N$frP*%)I~Ct@Gq0NC>L&kU76@9l!{n50h0{Pc0@ltQveTFeb)32;rysn z@=XMJTf2x}x+=4>6JJ43uIP``(@av)`-Y)Ue949kY={tgDamIqBiR4Pm^PK)sB67< zRbsiMzRe!EJm5gvlQ=|K*%DRXR#x)vFBzbxDb{$5xZzT=4TnV&%Z2$gBBH6SC4c%j ztSc}=K`DV+S?3ycmY1EKT3uLeC2+K?Ty2a<^68C{CnsGvw} zgqWD=^o&2~JqDurB93mv+eQN3yn5_v^6`eZsoN<#YYGj8!XdaBbw!EisjaT`kEw>x zrHAdrHM#ISeIB#BpZNp>p-cBfTXCI-3632W$T*r-RT8lEj3w;{E@&LnY)~-Fwpj#K zyap-?ypKTms0|_=N1d{UnS_hW*aTdfqE@Bdea*{n-x#tTk!cmrJ5M+4hujhE?JelP zd0$yXKYe8wfs#Snv!u-FS!5n_VyTQa`WywPdhrdUFLD)z?y~siK`9~a#9B~L#P2c? zq>|Ghlaay0L=cGZIqt`9$|g!s`&as#L@-_tp3Cdr^Tz&1Zql&=noZ=nNxEs zbew(I#CyS^WV=f$3kUI3_$-o#0q_t%RokZU5Y^upPq%x@7m1h7!ayxGy_DtaiyK3pK{5MSHP;e``f}&!@^S6bfvVUuxnfjPS4Ba&~A=A)Wu$#y2{XoQ~yZyM@aaa-T z^yvqmEg7%P{PeDU{la0@k5c+%=KucbPnr_OuYRp0u9Ukk8a zM-c`Zi9NiC<@)9ac17Os*q${#J-gAi^2x>F&d%fUX@U?F=Vj*uDH=KNau23dVIAUH z_uXA`1aSm`2f9HB!KG~3-OafJfK=f&_0$1{lPe{J^m0F6&aMorvvakO^stVJ z#B~98vA1#G3l+75iB{jC*9UAamqm2s_f!n8qvNSNx7;9YWpK_MwInN!n-u5Yb(BvY zuIQic9mj3v5FCxN%pHR@P@2!3Ug&#qwAnP`l2P5wfzYdx;c&Ge*zn{tW@gyh`eq=N zp~$67oAmg2d!gc_SOc-V;(|qknftNc&WI-6*T-+${^|Y`GY&EZ!|T8fX`X<9q2hZ1 zXVls^!Eu(QGCh@3un=ZbQ()b}m32gDg}7w?{>ljOtz67d&R=&&EFcD5FuDlYtp>gP z^JlgFAobUcUW@F*^s!HT8P*%DP)WP_e9gJ#y}aNZ|LsM>(; zs@#|WdWnaNOF1Glb|FI|UAD`~t^pl=@5RY2~Z}&w5Kh5F1E4t;aq(r#7Hc_)* zF8%_s-pAdboThKXas2MtxHoPu@`ifErR+JZDl3)UJf#SUkdNZ2SHw(_8|0!ByhIT~ z6~87Xh8{IPEm{+&42Co`2p92J=udw0JZi*`aGXE=kw@KdcUV8Ncfp#mRPiacA}u!M zv>H@61QYu*McHku4#Fb58uU!5-#0_Y)x@Gm=NzwG>6t1FuMX?X3h{z`BO?a*oy=3W zP~wVGT{_gi8M!c5&#=#9Z*k4TOsZoshU888hF%Iu6@;IT&Wcaym`)d>=Nd3E^O ziaq>=zWq+(yf|fnEB{XIIZ1S=bt6E6o-a?pVNEFOMtS4wBelmU}{rukC-1=+%M|t zy5tFclG@v^hk(w6LZaY;0o&~)8RBS)5n?5XZ)l|rt^L>GsXI z0?dYj+NSU)nxA4q60m@`S!dRQ4EM;t(DSM7KjY$e^6y!fhbD8br^YPYuWVi(KvjhP z-C8a@S`qJ=DBtl*XUsij5J9@xt+kQ9v!+cRT)Eo0UKq}luU#Lv=f2AD_a_@#c@fx( zP+WCkABbql?q+wSvm%jJy55ei0)ix@g-e*^Z(6o`KQ+QrC(~$bIdYii2j6g`b;B<43G;rQVb`dh7~OOKOg=H{$6Hx6IDZyAcz)$?X+;-7Do z*tzQWoKy6^nFk)0?QLY)XVI;x)} zJVV|dQoCroQn#m#uR^t3V&&{SG`AZRR3W;^rJILg;aKta2Y8Hm?aBfICJmg`p7>k} z44j|RZz9+V3X74T`}c{MUwUImg?6aSOblE@#}-w}qCnaF^9V)s_KWUI6V92H z6-w*{+m&m3Y+9woy@sO|N-5n`eAZeTjM34O>V`v>U%BDBDl&3XxoT}je=_&ahB4h{ zOcP>@m#Wbb($FBwTsEowF2H|#$Mu?YXZV7e&hEO53?3d^I+PTTEvD_?FH%htd4pF{ zkF2j;9xz@mixz3~V3amL(t+Yu*u-d{m4&QJWz5Ff>$b!!he7 z@MeR^{?*mj($c@)hai&gv)z)YDE*qS&=cL-+he*B=6JeB1S5dmcOhw7K^R|jCBJ=o zI2yV^QFIZCs;$ktz0f4_Jrv*uxHbf-`N73J6wTQk)TP;?KeO8c+Cx!mwzI{5=H61V zC`>O&{IbaS<5M_8UO(lz`gI8Iw-a*eKle<2Isbx>0-|}0p_9$dZt|(-t!Ymsft{(b zJm?Q7Y)#j|rRe=*eW2Wpy#M`9VjGn&bH8GExok%Hde*WmRWy2?>+U^w-`(9({MB+G z3)vYVAKD3%W}S#wAe;*NrwT#kvbiwoWDk;F?&WJAYW=BK60GGjqas)5?QOyFTRdW| zdYv78syl8gr@2}1&B{Vl304FmW6;Rg2${}yNHJ9_|2(7lYihB?KZg#dQS7216zib` zXOKr|7Q;f^Iy?T_nAp}z3!dku#MM~f;@FgU0oF)bWU`9Q^0p*Imluf*33P;FLW^5qfw zMikkK6p7R)X|5QYp1ctnMShyPspeb?@3HRxjbU=QvNp)Yes{6}Q%+WpI}kB%jX?8m zghD_)QsT2Vc-7Lcqs?D7Ly}iqNl77oZ)$k5nloLNh2>ZFl>=1O9L8SH$>;-4LxU34 z1MkU!XL#Nj{JWG8zt3Z-GFcEqD;HiI3!bm7t#R&E=~Lr);665++bTJZZ+GQxS?dT)ki5#8Nobsb()G(Bi|VF7opQgb$BNAoH_ zJ}%Q=w*3d9w1`FphxkQ{|CTf3^M#kUGMG*lJzqV8RIgtLo}JY2vu$6j`mQiF{?JEa zHbX2zMa%QeBn@zLcUsPZXd~u1N+NKOLx{g=02hvFc{&HuHyl?hNPvSd*`y>=O1Ecqy?6;HI zmYjVIp=mdf-5|D6jm?Lo?VCm~(Kf$4Wv`o!LIQr}1Bcj`RJ(J`8ynBLc0 zqD514`%v1&bd7zDc~&-XLhZ%XA+6nVFpY}{wYs!*O95G3A-{ib2puu0a|Y4nu|Haf zNuz4i?uY)?#0v;Sq!gIBxPL*lE3)fyD7~R1)~c%&7LrY+#mJ~V;Ar>j&-eD;jeeCn zkIFN9Q#|r?6Cm)1*4hRfnN{;k6`&}4J9@UF}Hh#bglo3a7d7+K{ zF)nuL5x(hT3iDaV1nYC@vK+T&6uIPJ%`vT=&q;VG>4eDYaH&AKVi6xDS#dFp3q1R?VKN0#KEW~hhW*O z4FA>qp+LfyZ@yHcuD{dA@MPrsI|3^bx#cQLJ!&27CeSgVX18f>8`Y!n)-)7 z9?s$0U$AMfKeoL%A*}`VB+j>Q#nn$xsM>1PTt{M%^_)he^_+!FM*YL3-6*n4W2LW- z=&7W)>7H$YYvzLKM&rEo8yvD9NE9!aG{3jB=j4kWEQlE*@D>#X%;#(fG{WJ^H!FB~ z`yTSbIaIy;0>iS&WOwhztWiY2ANS~euEIb>R3a{rT}JjhE%vSr?z4F#Di?*WNRLGS zD_ITxICSa~X(TiWbV5I7wKek!mqld?1Pf{L;7AN4+#gN0!SV=pEW9>F!P>=Lmj{*8 zO^tYe{^&o$)}uaFvue=~cY87!DPm%6G9R|t?@wJ=geQu9b3+x*WY5{zM$aBjUEslX z9|%dNXNEfZh|SjfcE_d|vJXg`X5sB={%xQUw9=k+o3777+xz}4z1Ed4hQ$BO(Y51h z$|OBd6{4~B_3VVetrm*rsS@f;Z+%fi!ud6|wvS>{HfW71Oi6yA(;R|*JZ=12TUgXs zHnSf;ovn$!y+FM)dw9WKt|oFBBT$LF5LS6&H`#MB#)*(b)cx;^5F%o~xp>W~^9S>z zM^aHMaqoqLyizy~wg=0nT>#K3kzIsj<(~8@2>Z!gZxXkdGuvD}*4_$ug3Xv{>lG`i z?f2uyr1w!+Df!(L$HUz+9C~8witg=IFWoP##=46=d7TH(eJDtiEPf`AJ3WMUbZxpT@!m~ZEM z;unukEgsuykQP>T~owx~fV!b^JNW%yzAE|Uy=)0eW9*8`B z<^x%Ds#+>OM4w#V-!9m9lWH{zV)s|wBgZz6b6lzQV{%E}D->jp1oTO+u&sV#t0QU; zg|4!+Sp@^+?$M$(VMxS^5 zY8Z}VPr4Uu7akHHXO{72Z(UWkGZ6PRR=jTN&rTlOuKoZxdLYfyvHq&`=HK+@>gqTW zDlWP9EFe%cEcYspNKY<|p9FJ#;SdWjvHtly^!IaRH#A&)Yp%NeJw^zkdF-}*^yXkn zXf!cjmB+kIb-OutHX#3it<$7?>@rkueQsS5?~D~&Jx?^qrlp44T>UtWiqO;8kO@T% zzUqlT&ftUx*)Cdai}>r`=KzJOzbPE!(X?$ktns9_`&E58tj=#oN8g9G6ekG@W%p^| zYiQ_LqL|C^6(?KmF3dVlc)UQ0cuz(D<{JJRlhg4Py49Iu#_*M9)`$e0EsglB)d~f@ zPU8(<9dcF;au$0_2uohqBbOtwg;8fHe=xc|@)R|6Ds#tTLWw^*tp=yXyx~~#WeD^{ z=6yn$WZS~~!h+8Q-8hxh^7VSOXqKtKThcHfGm>BelkqC!XH8G07Ahuy@cQ$AU6rFUC>*&%v? zb1QaDF*`e#{)IaH$EdjfTg;%h!%zjamH_GzDMS&3EK`DQbhaRB^3F2DJq;0`yW*jn z`I9wl4AKQbr{qDGq(QXn+Xw?%8Y&C)N}cMDOXoXf^$es7sSAeUk4sN6x88T`+iS54 zA&7u6;tR->M!t`y;k z&S~UOfAsS;!Fey;aYXp%i6JIlyobk2zVo}eCA(X(r`Gs6n?Qxq?vqa$GS{T8Efof0 zqX5;wNUJ7d{(yz->+8!;(gH@X)umzF^_OJvnL<5kOnf0uuRuz67(TCS6dS=|+|ez* zxBC~;)X|WK9VUM&2@)sFa7JmG{5XD1znI3xrpy@tc8PzK?L ze+1V6Q()Cas&Dl>WowpRZ@h}A+PLJGK9Hw{3qhOsxY&SH^nnX$XJ_@TRDT~c0jCM# z>gwZj6j4z#2~qrnp{L6FMF8RzS;N6N{{2Jz#b=&L7N*WUzO)uV&=o8B$ePB(qn&g@ zrN`eUqo5cu(nBE9Ec(n0+}sgKV&tG$hJo-960**nM8K)w+wqgQt;d_2m`xgvDXgjlf{qbgvQ`Y)No@ax{p!dt{0Lu)$< zt4!qET|^aS!>&;B?}q2*_F;`_}& z!ly?8%xGAQ%__l^ckYk3C+Rc89Ip}>^kT{=v%DvuMgA2+)cbl=RJ;l}{Gpdl2+&A( zX2sOFwILzrnw?zbB0VAb^O}GE5MI2XU)kC55x~QARzkBJ!}>IQd<0c$h|0}OJLB${wn6#oF_w;K!>iw(sgHj&7 z?0cPQWtxt6Z8@<`2jyDmkb!h>B;R|=uLFv2-e=^$&1zk4CHncRmQ~`d^g{Qh9t*%F%shk7>e6!|=2irsw`A zNoS|A-Q9s41oCj}zIrjW#^LGGxH>_`P zF|gPm@A#6$;5uY_SU0UqA}b0Z4mKx#qb7VPR8W)*&cG8@4xbHy1a16iG5VCP$sCtN zvGK;N(3pC282_@+F0j=<4<9A=sv|r0*7%7HpVGYrUaNfF+r&f-kl~Zo?v`JAS?f~r zas1<5UdToq*-X=O55=6%DbNq8WNw$i)-k{G^M|BMxz{S56GV3UM26FKoVxyf0M(B`hqW$p#;KOk%{^d?Y|PM7M0e#ZeGld`kJHqk+1By z$D0#_(Bpna1#nt%n-a`=mkEKyAI*0*A0x9r4C3Pbz$DDKu(TmiDP3RL3e7_#Ge4QW zo}WJx+HxmVkZx3TC`VZG75m%SL=3bBp|Wc>*V)EP$sjR*t{%6%0b4zY1R_B309P{^1j~K@PNm}_Mzm10xVT=i5R{wj+t5B@; z-9y#F)^@3opcj>M58@D`@Es6Tx1A8~A3ZB80yh7ChIz(DwmE()@`x9HYafnfD;&Q7 z^n;V*W~SA_EbrWp(=+?iPJERrGt>l)QrVWjpKa#O=u*RGqu<%c{G&lhpyi1ktD9xo z`l{&vJNE^Jz(l~h8jA3QC}ha`rMai)X>aZ?OQ5eh{aJQUTR+&0$0i!V*32yDRzrt{ ztuyqy=KeHuXqz{F%s?t|z8_`x+AS|TCo3W%pty-_^9vmaoPM=s7!X5N#B+&_qh(&PI-e^iw0Di!?s-9+zAXg1b84Z=$j)K>vHGi=Ee^(97y6AnzJd^f-$LV;KWBYd^DJwfa8a5pR&P@ zR0OmeJVRIaZqEps$J7|m^#SJ6ZZh|JHPT~iWC&Q8vjFDVwhA=@^cYK$@It%l)?>@M zbb7i%RG-Tn1K^H9zlsJ-i4j6$%y{AW<{@9dyErR>-j7f?J1&8@QH8I*gT-=P%$EY% zn)mO$I6fyB#HL5_TYTlyD6uNY{LDTbpJM5!_^Bi4<*MZ|pmOEqr_q#@j0(>;J-vVa zye=WHRsTixYzCs8?J{H)6g{z|lrb zE$dcqMV;7h_w=CB(~DX1zR1A9-?kZ-RaN-x9do)HDEqU4?+!y!%2Qh~PG+tg1e||g zCIx_6mG7IMBIEW-zIYWqE=z!P17c1n{ut4km9xHyoMm*h_@BXz-CvpQsx2qH9lB8) z`;D0S(}e0-xYd(qf7p1k68b7hY{{G9U@_Z3OsV1YjjFpfh~Evul+rYG^-Z(vKKC|i z8rm4ddlT8Lozs6r34|su?2w&{M|5l?M)yi{cB_}-u3F&2JRjYAgcpXr^Ox%J5ld?k zfJ7m#7sKJ8l68)g|8I2&g5k!S6}F#U%}K(-kiyEh^)ll*+~{b=-BtYz#7we_&WY^J z**~SHV0;UU+Bld9}?N!X~Lgn4Kw9RZ#^!!|0szBmseUE33w9)mo`O295qReeACQcT5zqN zO>7$-@q6Gh%k=2S`&3y4W-t)I0srw@=?;$mgj{|B0lD2aweSQy$k+W4(RMp^@dp?;$~aOHRIzXnXDkPWNuA=Eqm~CBpMwT*r%^dUI^q z>A5EnQpy;1Xk6{XQ|g-VIdy`#o|of7p?u}#7G=hAq&78_f5+~|NP9L~{(~#DcrQey z*dWV%%%1%q;RwnrNSk8e%*?80Y+oPq@o^j_dz|g-gHGQ*oG8$IRabu~InfpEw}4g( z11CLak&s|0=mG`sNzAlq|18PmvTJ_h%^lp^?~q7*l7AMstFjgC5Vw z4g2vx-;>d{Z3mL!y1d~eb7nMtt>Z7XzSOtWV-Kr25Y|EGud3%a&x};s%KY`e6`;BhXMEKeT>Ysec z|2K6KTF$83^J&yo<(QAv7XGpS1+cti4hTUeNE49 zpUw7O^}%i{Z6z#XH$`R+gw7=X(TCHi&ttHL6)#(v>AJ&;n2j>fgC!9HDHYC>faVZ* z< z*$rxPvO=}DmtP*eQGV{mz#}>$8d5)x*rQfn;=f>!%j&ng-w2(mfqA-}hpYm)dY-eB2xWN}H>B zZBo7b<#0MfMtbo!9b2GDRzW|RdNts>06*^-TUM8CAN(%_wdMXs+$hV=w-uH`gmimK z={_~BV@lH>C}lfdB_f&rBqk!6t}H}r4~?9P;CJZo)6{1G6uO-$m1xtIQr*|KIUWDe zoJJ0hzk9PdQX%Gl-0Xi=@OJVorG`8VnD-2&<;VmE®w_`d`gV3yjY{|b6NDG+(F z+Dfp*;kmaQ( zgpwxhnx_R<$?z+(zcBOG)xj(O-onKv&u}*Y!5QxL?cP`t?_fsj3Ui*C1C%hkGmf%^ z$sYlM5zvGrsp|LslzMZq9neG{PhO9SWE6y`=nDqj z1!%~VaeKI+f{24Yh5YfiTrykv1_s2|_N4heH8s^wYtsen8*a~)!^|IO3%vpGm`S1{nVrYa5Y=)!`dfCh0Rn_j zm(8`DmU7cSLw9JQWpjCopTxDauI}8wxVyF3n_>Ml8_BFdMt#r0e~v37)8hNY#B3_$ zfiq(6_mhS~fUxGc4Uesct@)l)-)3G`xg!LX*ly=n;_61Ce%o{7)XTJ^xpdD%0pY88 zN1%RdaOcWZOpDk`_r^Qh929y|N=iX#IE}EoixKkU;>s85%vWuxvKDu*Wq)CRHfT+r zGsd%^_-41J$(cGl94Iq+59(F4XZ=7A0hE}QjKol{eFad^uSSB(p%@Qe|YfeXzUdkFO8W_f}7`qNU|fp^x<*l}Vf9 z+x02ZF!KF&Fc*A>P3K}`N6!dbQY%|?u*bB|Ug&g&f1a-@{yN-FhZW!F`(0)kyOOSB z^qwFm@QUH4{V{Onv#wIpE&b^DdN^PK5W*Kt=Ch=>ysY-QhX2llv}W;fB?rB-yu0EP z!NZ`?HO(u*do2H}?Vn1ryc+5MDIF%=Eqm|wt=`ej?-WTXO#&|2>5S}b*t}wRpL@)j z(>GHG35bU|Ug1ztpIgzuFOQy>l zZ<11~->-5khf1P!O3D!^VSpbBTM(z(Eg3Tut#Kydl|mLJ6|7d}8?C3syj)qg74JK1 zqvgZ=-$6!^ufNp&tRL@uyoS4;YObq7cMxFrU zy=`(ee)9{8O^Y-aD0ZEByyvqX2J_rCP`)Xl7=tPHpceiW#~_Mi2NgY5RGB@$`p=xo z`J@hit(U+6ol>0*-51L12quiX^RW>$^2N>1gd`q?-giNn5G1yO6h63@FIncUZ(wYj z7@}UW8L%>c(y1vk?KRjX-rWT%GF%^oy4kmEFwIY_1A6?<$ONJ!0QNE5Rij{6){+33 zr$QDC2C|Hdoa=`~Pa*)daLWfu1nRPl>NGdOUM;chr({kr0@elnxsL`&wEuEHk*SVl zmI8e>KffhjfzQpagDx~gMc+FXMm{U?)7eU-&m^o){;gTn7ESH5|9%xqNjVOSGU+*JN?!^@FQXL%yo@TU$)hH`Q zs~s^1%AqYXb{luqdc%Pp&49gR9VTAk=PqFSe)*uNT8qN@>`>y z!!$xH_uUC11dA9x~48ZFS z`0DB)!=iXv2~`1*Gp=>N3>n~XA=J4u7)Bd1ePBJn+b-COB zOAF9)ePUf*n*X_O@THk|H`sJ*F7-P*Ee}^Hnt63_l|*j$_C{nwCu@>%^eniSe+YP? zVNv_LWS0!c!9|17zndPaV9~`=(IH4^8iIv7xw*)=cmhh?(Uu*gdWqHR$=mxmU+WEDh<=CA(S=MtUcBI}$q(dspoKg__2F0wzUgL@8?t=7 zV&8x~8uHxV_^-y)iwhKvpify|Ny+w%Wby~mv%DL~#P&*fr2@aa3t5j9>zWKh0(w*M z0cb3<0bS0_{V)9N*Mb%h^RGM~E^=$xfhrUOd#v&yi;Rt5%WElG?5RlVeS(`g5V;s# z9SR=S!_*XYpg@|MN?bo!52-0bx|3fI!KnUDpV-n233?7ayH|(7E6Wmz2iIt$Q`U0` z4Hw^mV?#{$ZL++RN~0F4|17yu^r7t=Vz$d<%~42wBVW^XHWYB%5b*yd7QK&zPet9%Octy%~{j4aaLGWQ&Ab33uzBsp*D@t z;ff|UalgK+w`yM=(cIX8;W9&7n}e{MgeeOocrEV#+^YpCrV8YQVoCY_GEp`1ki--x){S~laCA$%ViX;?S7!J_$ zZDQ9+65(mndK-T12*LRn(zb8GZIUZK4(05V#b)J47ohds?SNMv&TO6y_p>{i@dgBxvwK}DGV3NqJ_`|hzicY*f4-toWyBP=#DhG`^_1(( zqJOUK(_*6yrn4~jA_53Gx4#NZ+#tFbL^T&;YTEW-)E>lh*XZ28fkq_<&+Uc+rxKJ| zau}ud?OPj=B1q9AZJHsfWgl8y?qf8Z$O@Ycqe+1J#kSEInQy^~V03g&S=n%R_t3dE z?B*=3+VQZ7*c|{W{X1i}#`Omz8CfPMe>Y#vg5&nY>nl zTYMj>zosAhn{X0B{%-kVyaGuHB5i zmo!D14NAFtI2+ zxFf<(WH5s2{ny15IOxE`BS8(j5di{x$m#u1@>(O;QR7vxV^C-{?DsU+Th&s15f!xr zhy*{NQ&_CR|dJ2w--ev$C&PANTG!2#n;bM z%myW%Fm)x-gDEk?A)YQVh`NJrOoNE!IBYwj1Me7*-lflkHB1B>e=d? zJOY?+_uk87q6Aq-RU;(ZOe5%VgwPVj!ik3junQg=P5YgMUcM1@ z-6dnUgT%b*f@q&jto)@R?|eX9&FGYg{sCKQ!SiM)L#}tG;==aLuQEbmf+`=M3pUX0 zgL?2NFI{Xl$*lMLqm>oMP%4AOyC|C_)O;NIx5S~M-cYvg`46v6IH55S0b}PoH5DK& zQ=xCQLn$7gC9*LxI@Ybl(l|UETuf=rVj8pXhez3!3JiuXv!@=(d@AJHTWS_VGe@UD zcU=x>8Z;Q`D^T{={n=_ZP0q2K6Klso^TM^%V2bVM1g~IoN}ON)R0-u)BwI%{i{}NF z4(;xvI+S3fZsqV-q7!j4&(^leavS`@NfcpA7-rp?{hD?utMtLZ@Gzc_Pu)iO-sM7A zBvV&sq^UwkNK_Q#*RN`>ySQw6TSLKn^R;;mj)=duhNZrI2`oq@5ibmW_bXtq%*ZZ@ zJxhiq3yP*UlVZF39TUNcixz;wNj&`x&K5G1l#~F=r(QkrO^WV3c)YK;CYuOA@V#y) zH{3WxYrb~V{lSY0u1efIBEDPNHy|ycfrpGnhO<;rRvCQI6JN)QW?(???Pa)kguc^w z_^SM4@aGLYwi0wS$1MkY`dx>2Gp=xuD%)Yu0mHD`MC=@?Dst>+{d>-}y};I>k%#OM zF;Gg=c{A#<4w}N}nm+=8jO8i>7QRLASoigxk-S3;UAu;AeAjSW4X1-_-y+J9iN!F* zibk}xhwAvWFTqFrDCflK?v_gX`a--KGx{%f>}$$hD>4uH;I_7==h?binmVe_Qq!h* z^$Nnu>cBNMBK&_9_MPEyebKu|?>)LO(Sm5vJHsfE5TZtn7NSQ&ln~t@TBIYo45B4O zH%b_Sh~7IfdWjbGzvuow-RHUG>zO(G?0xpyYrU(zhlQiAXw;@SQ+a*?|7~eV{7v}qdubVtvZOoa?Bd{ndDwe!0eQ!ch@8{y2L#knCEQ_T850aAfExCG-WWT~ z+(g!$3XPCeBS^iJcDiLhonQ^wo?s%8%1xPl2yyu~#L46lRtB7{KfM>jT7+J=0H zV7AeTEZZiMQ^fG7qIchpXV6)4)a6t-99VK#xE}9}6yH`fZ}7jFjcnkx^8zC;s&p3emI!it_H1c;GA3Lj=C|9ty1%gP zjBCXEt*&@6{3MkkMNWmG=LfL0NdCK~c6*M~#D+vf!^k8tEua)Y8=<$Kj0!)XLc-Tx z`(EdzRy?d;Vwz?}(jJP}n;26hctgWUE84~lh2W2{^p_KM_sHHq@Yu5eyM}t^HC>zr zx(SZ|OnQln!e}pr$S`c1N!WWxbVitt8-y}<; zqSr=h-B~z!={v2hZ@Ns%Ubp)c5Uxib079D)RV z$s&lUTB|S5iPBf5Qa5w3iE zIjFxzh?mbSsy4q#b$RT6d~wXPp_Qc7@uyc#(Hlk&8a$nhZfh{m0f3i4^}4Can}VY4 zefK-N^%atX1omTjSTnZLhnQqd0)zxAcw9;Lyh(24(eU6oTP!!N>ii&IZL8rsi>n58 zyXhh0_Y$vNV+lBubEKwD=ulePn!fS2kb?Hmp+j7a*08?3yjr_&A|DHM{8#o;nKMPe zV3gmJsme9GeaUH|$#)_6kAa$pyfxT8(wAx0A%EZQiVmoG#!yFm6R>FY+%P}RR3Ivz zXXZY3Oev>EH+&sxm; z0wE+?jpdZrX;(bvI-{5`_bG4A#%lPVtbVr450TM`Zocec9i!y@5|sPBK8Kqx-|#+w z|Ew@1%K8e20x#!{wGb6n&|Yi(Dl?O-)TTbp%qD=SIuAW((xu@~V<(psfeM=!G{mp0 ziDY?>T&Y0NBW-zOcJ~MGE}kT;zn5^*EgtCus`9wKy#*{~x3O-ET;n4pZJ#R5(tEEM z1MW2i<5d1w)zm3mwX@%!$21m{j9 zLtr*bZ6{o4AkWMot2Z3M4L2~L9VxYrk7c<2{r>sVuU{+y8!V+gA0k>ovTf^=vbSyB z5LP$$F~YbTLR> z2JB1S>^JQR54UHNdV20`%rvqG9c{HAMA~{6N@)q_RvOwjH{TF2^qKXujh zoYGEn7ii1`KCM$`(^&p=^2pDQRi(U-u-=4kx|L8v}joqoNh) zL0(k#k|WqAkW5}=YPR+9&nu){&qMj3q4Se#4&6-Y2ZvgK7%W#pq{Kt$4q_Tm5%^jr zCML3|JeRYwvg)yBRO4=Grec5K=2#`;5JH@Mve&(%>_d2nhet_^7?yIt$%+Zc$otyiZk_-)*WoonH$6EB z2-`3y6Fw`R661ix@XjDt<1efi2MJwVGWvL5@fTQSTfSI7~7u`w~-#dQ%Qt5Hd<4~PjH=i9KQCC5XJf+LHr6qyjM;06mHjV6= zV$AxrelTi_Io(EkeP01VHU_{0_M`)JF`d09k9lLQVu2An+hfP0feJF%~7!Fw*k!a&gP6 zfF}<|iXRsj*TcjCH4hFl`1$#5URX6kyB+KYc-%@HoHtCtzWBm{Ua@a!Y0+7QdIyBw zkS}&5XgqydIlcy1YQjn^s}~m9;|&Up!Qi!p;St#&#nXQME;pY9{fEhF9=8>JV$vK@ zqyu;f!*WW;FfC3+V)T0!IpD4IY)<+*z(Dv=hL7)0DJNYO{&$cxC@!X;rLu&n=iM_V z_&wD`wZHLbONhQ-**>0tu8OsSXkqEr($Q)JEA;C6o#q5k@~G+awYFFrafG9HnMeou ztc5>4Ew`a7czAW9FIyrW2hXd6Dd+>TIpjpICbSiF)VjTNOOBA}+WKPBW6$3(+^@Ke zpU40=1Cb<0r(Vw{r+x@F4*@o>)14zcd@g8-^vvD?2&DqqFTh&#?a6yNx+d+!EICo? z!jzQGlVbd(C?dKhoA+7>L+4Hw?8kbBAPK*20L$6SE|gC7^=J zq3*U@KpbYiGBPZ>|T|wp#rD>obwtk6v(N$q76)(%3n5U)9eFa_NmxRV{5^u zuWyZ7ROL+kXUGLBM4SAYaQ))E*NR7iv0ey?>aO5YDnJr|L*r zDrOEHC<~XTesyIGVUr~OM?x*d$_A+c#J^9Y`a|B!Yw5-1`T27)#8oCsAcx&wX(%JN zX;ib8_8*;#zPz3piTU}4ze+97Yb`a+IWho*48ZSEZ5t{K)9u0SX`yl>rcw@ z4Z)`nT+P>zuJl(1MJ88BsE}NZ2pW;&hwCe~w#kJ+2U6!uWBoW}Xl;&MGAaJ?cP5_6 z4nzx+C&pNWK@A^0upa~my=lKqO}Te#SH%BJNGAqmiAGs7B8EJMh)BW0aC#jaX2fU| zuy(}t;yz8s_|p0Lb#9oXn4^vay=Y>{;NW-CDqXle-lGeSv5$6r#2bxkzl>j12+j&aMaf?fBHny;`_#^Z3^0p zOBZz1J82OYQBYhn5r94Oi{3;TVt3!6o9$W&BSuY~oELwc96-%Q1hvI(#h~%D4VUh-X@d;?mq@>W+5+fjwnn?ecxFgklNg$^ z_S=(hN9(|32lixoRo=mEx0rcogBM!*xK`mN9e7PJfJXN%YG}_#OCow&;AJoQWtppI zgPEZRt7~x|2k!AkM!{1v%gjp82KWGKqex=BF<14FN@#Gvd$|H*5O~oLQX9{la(Xb@ zIaAA^LPDc%|ETct-*WfD-wjNn=IXz{H5K01B0sWK+|l%rh|^D3J0am}J|8xluktJD z-;TIx0)mdDRGRbiZNz9*O-$mo&CTkYJF}Nsea@e1S5^$VaYRnTU%6zd!QRHMD1Y+D zuYM~M@jVCs&FX5++#*5Ja(6%INoP7dJUZj>aN-L|lOl6MpA$pLosQm=WMTHrkPaic zab7_V&~GNJtf4U2lSvtHiE^quyDNwZgIOGLD_bpy2SEicNn+q#y-rso0b2~gJT@)H z64;`amb)Jxo%rf_xIb9grumS|6SufvU~NnY8bt%IJd<$`Jsrr`QxS7mH=P!H3J(od zgE+WCSnj#GUBPtZz!ccj^{57B0x5StFNW^Y*}L|=OkP(H#3v)&XZ!boeLuF{7qc2Zsi zXC#Lo=UMEWA3f&b#)k~ve27gGYmCg}yZt~lL@6Ek*$z6S?&oI~m3#9UFV1gMQjOTy zumtQ2d}(ah|LJl=C>bakPxKKd1OpbNUrd5tLR&lH=!;t|w)O$u3Hr3O1~SpRMJC$! zDItg9Is}36oUvRN80dX;+&dz%5GhsOjbvd1en&^Lb^QZLN2E;!P;`ia zSA4WmY`kSwWT(x|Zdd6cuJ;zu78M&l-{XDt z4p1rPYA?S2CMgOE`S)p5)Rr?8duJqp>Dl$iZcQhs6J(uIOs;1<`_bq6v)eG_ps4>; z;Z8b=f`H1jq_Vs^W^~ePl$o9oVEvbNL5Ij}JcyTxiKWuFc` zq@d8r)Vr;c68Dtu+I;W928W1w&8mRy1~etpQ*%$S2Du>20gkaOfc7{h z<(Mtd+Dd0A8K{kT(6ii)Jv~Be{8<{p{#{$JUji69EuMMtWeka^URrcL85!|*ehDfR z_@aTJ?F1ZPn$z9IwCANiTJb^PYau}I{)hg+K(BH9SgRRqaD9L7!NbTJ^obDf*AA** zK==gMC|#t!8@@Nr7N6kmUukDk$x;>f|KE__{5c_3RFJYRlJ_9)e{go!$&)V$evbwA8w- zmG<5Ew}f9T6(GVowBxNA)lC>nRZoS1NHz!j>3O(q8L&dV#m}pj z@tzb|DFO6Tvi9BG-!qLj-qKZ0@RwC@j1OYT-%weyQ2HherA$o7SeikAM@81Mz>d@~ zt)@2s=qp!Of>#Jp%;t;B`f)d4o@`!BA#T%DapDf%DeQ?)_1E^^E$O zrPu01S(mDss;7eK&OI(?x2*yBxO#YaySHuMTJrHPwV{f+ zmAYfOiM;@FA|U^a8u%slwZMQ_QIf&CK1e2P+u7l@gYKTI(&WDeKl1?L1j^fO;M-)X z;GiK99Hn~GZdgxEmKf21$o@^iRp8<}LiWFw#ZBOOxqZ1XvbP*+8V^j!OT4N&?}AgZpye1q&=$Khe-I|zw;0~CUjzpDwdFz&^RwIs~~Tw ziD@!t1bD{?1o0RNA+mQJgf_5DN)m>80kty{T{00Q@fgkPcjGVsHn37r0dWC-EOJF; zTr9VQkyFLJk_b_3I@*_)tg|n3A))mLYmR;x0n2J`_8COKYj`e?Q-R=svTs~ukF*1; z>lo^LdEuQQsjY;Td7<)C%+~Wz0iFxr`|7kH77$e}yP=gpuL|O+SCT~19yRsNR8gq= zR{7fuhK09H7n`+Hl~Hz$eI+uve;BM0j(C!_gQk90vM`igJ}NE z2FL6tu*-L3U&UEM>Fin6OEL;YMJSYCj7Ak$C!p&oMJ4h~iVb~Eq(aCj5hpQRaoa(q zR)wH{ z^n3uin$*Mu1lEZ-MwpGTi>Q$7STl6{Fz;ksr-nXgL@e1QN>a?~JcU;l8x){uaN|=aZsOKA!Xr=&M_~-3G|(=@>c$fuUlB0Nx#_L)dBV2K(LV8W_blN@@fVJ_p&b)x3flVFDI~)w`FB1 z$7>nP{`7mA$@uC<&uGJ-w&lji+FnSF(r3LgSdqoD=#%w(LUi-1&ZtpGAn ztD`_Kup2SDYuiG9eOVs;g833>)skAV!tA)$k z6K()EIg{BY)Tzt{f<{#@?^n;iMuZpj+}RDL$iK&7Rp|bk$Q~K|AgiY4RYiu<8;zK_ zqu1=LVlbmZ@uk$e-a*p}IP*3@!JGvw8ow_KInV)G!m$uMjq}tCN@{^Z7NrGdbn2S4L7i+}z$vohe#9SBJ;J zrw3ec-w4=ttFk~1yE-~K*&VD6Bi+mYqU3k3Ta$eAS=N1G7KXgTYg7mpzjdl|@5T+C zk}nq7T7P&_x+j&6b%aF{JiiQ&J2^RB6BO*48g^lFHo`_ +to refine and expand the structure of NeXus. As a project which aims at creating an infrastructure +for experimental data to be findable, accessible, interoperable, and reusable (FAIR) in the fields of condensed-matter physics +and the chemical physics of solids, FAIRmat has adopted NeXus as the common format. + +`NeXus `_ is a common data exchange format which has its origin in the community of +scientists performing neutron, x-ray, and muon experiments. The development of NeXus is coordinated by the +NeXus International Advisory Committee (NIAC). +The format is built on top of the Hierarchical Data Format (HDF5) data model and format to which NeXus adds +domain-specific rules for organizing data within HDF5 files (:ref:`application.definitions`) and defining a +dictionary of well-defined domain-specific field names (:ref:`base.class.definitions`). +The meta- and numerical data in a NeXus file represent a hierarchical graph which encodes a specifically +granularized representation of relevant pieces of information and results that should be stored with an experiment. + +Base classes and application definitions are two key components of the NeXus data model. +A base class represents a set of numerical data and metadata which specify details about +scientists, projects, instruments, and other physical devices, including the numerical data +and metadata which are deemed relevant for their description and the associated +computational analyses. Application definitions are constructed from combining such experiment- +and research-question-specifically customized base classes. + +In this combination, an application definition is a data contract between +a producer and a consumer of these scientific data. + + +This design has sufficient flexibility to cover any experimental technique and instrumentation, +while ensuring rigorous, application-specific structures that can be processed in an automated manner. + +In cases where base classes or application definitions have not yet been proposed advantage of NeXus can be taken +if the respective scientific community explicitly designs, implements, uses, and continuously evolves +these classes and definitions. + +The NeXus-FAIRmat proposal represents the results of this development for experiments and use cases which have not yet used NeXus. +Specifically, the proposal includes cases in the materials-science-branch of electron microscopy (EM), photo-emission spectroscopy, +ellipsometry, and the field of atom probe tomography and related field-ion, here jointly referred to as atom probe microscopy. + + +The documentation available here includes part of the contents of the NeXus User Manual +(also available `here `_), reported here for the +convenience of the user, but is restricted to the parts most pertinent to our proposal. + +For more extensive information, please visit the original manual. + +.. _OurScope: + +Our scope and perspective +######################### + +Thanks to a cooperative approach across a wide variety of experimental +techniques, the NeXus-FAIRmat proposal of the FAIRmat project has an opportunity +to expand the set of data/metadata accurately described via NeXus. + +With a closely-connected team of domain experts, we will develop such expansion while at the same time maintaining +a consistent structure across different techniques and methods, striving for the maximum simplicity of use. + +Achieving a standardized and FAIR data structure has a wide spectrum of advantages, ranging from radical +progress in scientific transparency to the development of new, far-reaching tools that can be shared across +the whole scientific community. The convenience of such tools can range from guaranteeing data reusability within a single lab, +to enabling open-source availability of ready-to-use advanced analysis software. Perhaps the greatest resource, however, +is the inclusion of experimental datasets in the `NOMAD Laboratory `_: +a data infrastructure that already hosts the largest computational material science repository in the world, +a homogeneous and machine-readable archive, a human-accessible encyclopedia of materials data +with tools for automated artificial intelligence analyses and data access. + +.. _Outreach: + +Outreach to the community +########################## + +A data infrastructure is not effective if it does not integrate seamlessly in the day-to-day workflow +of a laboratory. For this reason, we approach our newly developed NeXus proposal as a community-driven development. +We have drafted an accurate and consistent expansion of NeXus capabilities for a number of lab-based techniques, but need extensive +testing and tweaking of its characteristics by the community. + +If your data is generated with these techniques and you are interested in producing FAIR data and accessing the FAIRmat tools, +we invite you to try out our proposed structure. If you find any conflicts or inconsistencies, please raise them to us using the +comment section. Thereby, you will contribute to the creation of a more consistent and practical NeXus structure which, in our firm belief, +can serve your community and beyond. +If you do not find your specific experimental technique but would be interested in participating in the development +of a standard using NeXus, feel also very much invited to contact us directly at (?). + +.. _WhichData: + +Which data should I convert? +############################ + +You are free to choose at which point in the workflow you wish to convert the data to NeXus, as its flexibility allows to +describe raw data, pre-processed data and fully processed data. As an entry step, we suggest to use a test dataset +that is fully processed and already published (or, alternatively, of negligible scientific content). These datasets, indeed, require often the most +extensive metadata description, but are most easily converted to NeXus, with minimal to no impact on the data processing pipeline. + +In fact, a low barrier (but high yield!) way to participate to FAIRmat consists in converting only fully processed datasets that +are used for a publication, and publishing them via FAIRmat only when your manuscript is in press. This makes the task of +converting to NeXus much more sporadic than fairifying raw data, to the point that it may be even acceptable not to automate it. At the same time, +it guarantees full control on the data until publication. We are confident that if you take this approach, more appetite will come with eating, +and you will be naturally inclined to gradually integrate FAIRmat structures and tools further in your workflow. + +.. _WhatIsNew: + +What is New? +############## + +We have developed new data storage objects (in the form of new application definitions, new base classes as well as updated existing base classes) +for the following macro-areas of experimental physics + +:ref:`Multidimensional Photoemission Spectroscopy `: + Set of data storage objects to describe photoemission experiments, follow the link for a more extensive description. + New application definitions: + :ref:`NXmpes` + :ref:`NXmpes_ARPES` + New base classes: + :ref:`NXelectronanalyser` + :ref:`NXcollectioncolumn` + :ref:`NXenergydispersion` + :ref:`NXspindispersion` + :ref:`NXmanipulator` + :ref:`NXcalibration` + :ref:`NXdistortion` + :ref:`NXregistration` + :ref:`NXlens` + :ref:`NXdeflector` + Extended base classes: + :ref:`NXaperture` + :ref:`NXbeam` + :ref:`NXdetector` + :ref:`NXentry` + :ref:`NXprocess` + :ref:`NXsample` + :ref:`NXsource` + +:ref:`Ellipsometry `: + Set of data storage objects to describe .. Carola, Tamas. + New application definitions: + :ref:`NXellipsometry` + New base classes: + Extended base classes: + +:ref:`Electron Microscopy `: + Set of data storage objects to describe electron microscopy experiments, follow the link for a more extensive description. + New application definitions: + :ref:`NXem_nion` + New base classes: + :ref:`NXcorrector_cs` + :ref:`NXfib` + :ref:`NXlens_em` + :ref:`NXscanbox_em` + :ref:`NXstage_lab` + Extended base classes: + +:ref:`Atom Probe Microscopy `: + Set of data storage objects to describe atom probe tomography and field-ion microscopy experiments, follow the link for a more extensive description. + New application definitions: + :ref:`NXapm` + New base classes: + :ref:`NXion` + :ref:`NXlens_apm` + :ref:`NXpeak` + :ref:`NXpulser_apm` + :ref:`NXstage_lab` + Extended base classes: + + diff --git a/manual/source/img/FAIRmat.png b/manual/source/img/FAIRmat.png new file mode 100644 index 0000000000000000000000000000000000000000..034aa452deb2c7695940d513cf0efe94291a1d69 GIT binary patch literal 114746 zcmeFZhd-77|37}AXc&1VWs8bRD0_8OMzSLzvqH$;`?QdiO0p??6S6rnLu7}HjAUi+ z^?O|Bc)i}=f8lq#eY(|+bI$X+uIKYH?vMLpoL;IZ$x8mT=`z_rr233@kQ~vt`%f?wl^zRFm122UC{T=a( zJ4W{J3rT94k$-=}p9NCXJf6 z{TfReQeJEk>>I^M8m{DlrIiyOg{j<_l9 zS^f{k@f#C++oN}C_S{ahAezsGtU65QSrqH2>$5wCV6o)c^C*vzydw}n?Gs;#3D}E| z^;%S6Mt)nkag20*E!^8$J4s#7{#F}S#XTk5+01OkchKK=ceirS3ghMHysK`E@V2)8 z%1f_QHr`3^0mBSL=1uZ;{fSyQJ9 z_Y5hI7tb;kqZ^S9!_%ib-_2wh8Izv&-}sh9-P)Jbf#BB6_}M*+Zy6Q(L2m>mIcika>^IXZ7!XvE44-nYmG8y}X`{@-=s%<0vCz z^(p=5o|Tm+)wkFJ_6nUQT7)^iOX=W>OPC^ii!ytVtnEPr!Jg&AbFt9OjzHm3zdv)W zPEVUZ`20oYAMNaHcw}lzc$7EUT0Qbp8VwNb8XA3W0c5Rms@Vs6&mc{${D(w zPmJt64qjMVd}ZP-(@_8`u_Bl8g82PGLwQ;?J)d}Xql4dr6j?9T5IfPHHnQ$ev+?q9 zHmsbF##_j++sf)~x-5^OivAw~fu+SskMt`4(Kr_rwPzE5om zLwrcEy3MzZ!Wl;}DecTTI#_yzpzXi$9f7CF?=BfGgYaURI*gFGHig>NJN9-=Hv9qW z&f}tB&NvJ&ULw14=}b1Or!#Nrc75e?dOM343@`<0tho(6k|`5?>AWO(->#_uG6<{{ zVSPnXo5Jy5pPd>v!aaA--@oE$L8PhNFP5sJ;kS0u^#0GsQ+?>&S@6jPj-_jgy8I+{ zd3jg#p|wkIZ7$Rj;Y3Rqlh2!<4d1uZEFReTc3q=7{3z;}l!?-nUS4auSS_8fk{z8j zO^(}~q-unh+n;GYFzEqc(SetC}OD>tcvx3;DiST}x)j%)<2m?0Ujv?WFcikd%d z=>tOWkWuSr={mu}?$E<%f|8M~EpcDi&w0twBPs1Mf5$CNMDrwB^$I6EZK=6*!F8t@ zR?VNpdt^?`<}=^H!Og2&p51~Hq}W9ZOX(;N&DK~C!9Y+?RBQ~WC=xO^Z0+H-sx6`DC$^Py^{q81pA~OgnkOUgnF>s$zs(o4AF!Bn7N(T! z71fP(@RA@Ah zsCbuVYluZhddJ%b!Sk`icyq>0m0onv+S_n$?E{gIBRI3ti_Qzy@Q@Ao`|@ip+%tn8 zpJQs=OJ=xyD&oLW`MFWwSg$uENct?m+wV}uiu!L3HEp~jqwlz2xu%>(5*F+A_AQ{ZZ0O>wd9MVTF;?zCpJc zk&7uBubhQ6-snF^jWbFh4c*5fyeKp&3S6ZCksL2pU#gSgGa^UQlh&@&S*kjgPHv9} zz(SlK-sG`U)Ak)Vegr0Q(OL)wI(G{mB*k{MJxcmQ>+fU-(v(sd1L%@;z+;i5LqQ+4 z)u0SxP{^;)M2%O%ry7Z{T{gmRsy>0e_0D|jSC>M)X@AF4rrV!O>%?FJ*SF;; z5%qpuml$z8f}cafr^4Gs}R#p3+~wTE_*ifZToZmZM6 ze$}7i%|^X?RmnAFVCb%Q`cny9H*ktlGjDb4-ImF(mjV@odSNH!G^0F^P4O`h@%*>q%uT>De_*bN~>8EyG*rj(^1qQbNC5H=ksuv}@6I^NG zCaP%h2t1mJ>m@VTI3|)8T9V$NLvqAh=%(W}lzX;pqx^zl)jXjnBmQ$BA+%bxMn;W! z+SslBh8YqX-?0*&7bF-lnX&QPLaJKpI4I61_sR+Qv1QKB4zM?n#nnCV%|S}`8WHv& z1fDb6<8FVuQ(BTf!HtLY34+*JCZn#@IbZ$yF+aPj8*J6al_%ua`mEj$e`g`bRdl5u z-W-NwE#{;c$t8k+&k;nXjf7P~IFB37zUt*C>`Hgp#tYrB1KuR&9e@&o3zdngdXG+< zt?-K+11`rKLbT^8V<8+5qMdglEHo)_jW}c?aA9p_+cct^7+Lymmi*=T&-#UF-=*Wn z%|U1DEO=jE*R|rwz>h;+Aj}Nsiw;^2DLw|(zwSAn>24h?FH-54dL5|nQ^h)GK*dGFFR6kBQxfl z$N7n+@qX&eX*Epcsjnmk?i~OJO=rxmLA=BD~EiJ zr@cn_xCN~BOGG)9N*dVy8r#Q8o};1WSCkTkk)l^kHW4ESo32F4M8(Q5Mk;{2tFT>E zgG+7|l*g0HGG{tUC0`^%c6F_k>4L`7yE;UAU4R?K-NYkUVo8}Vig06XED1i}koijm zuA608#&e_gdQd2h6UHw(E9QEhWbwzNq<7`8g6zh)>7t0|C6xYL$Fuy9$5(=!tric4 zFR!uFcMlWIp8#7a?Y{Ho>z2R05_+Hghlw#uHz(P$zN%6oMYad3K9Dy&5LBFa01Dhc zUkOhS^+YnPn2q+;xJQYsKaQhsQSR6{1<$%KQEVY#RSSz%ihxhdT)1DodFu*FJvY=u zkYR=EdO|(aOhyW@w4I8K9+0b)ONa#5KV)23xP@}${dLidc;Mo_f$aLH!!EOGrFJF7xy3oM$482J>M`7mgOb`Up{e4^*fA*r{pg){4 zNX844UJ36|w4ilht|xdHnl=*-CUV)w08O&;la1EGbKs>p>Ufn-n_W@zV)faTyha>n zA80J)rB5k5{r`MClbA~P@HY4u`8cBT>B*W)lpUCq=2gN;R>wt0w$&-ea{B{+{Cq))<32zq}rK74fk1vodLhK;It~rIpqA8pdUa|_Pe;W*ZOG>37 z6A5EIpb|3}b2x5{kABk#2pm>mZR~Sb*$J>Q#Adas+I$ht>Rd7UOF;54B#BO=%R*fJ z6Ux-Bv5l}TgKv0!OWH2qCLPOd3;0tWOd@$0_2eit_B7nWW647Z(avX4ElKl7*dm%n zfyS;FAI7VCiAyN6F;~W~8VdBjf(BH@6T}7%OhFGNne$TZ(9ieqnHX-aLPwUdGL*yx zD84ojpNx+h{cge=QL#z*RnPGZ&C9{_P10jY${i2T^v4gA)(>s%qFeBZ3W|#GT{CSWP^M(;Bn_U9-RhE|dh6R8%JTsKaFBJrM~fnu6?wF^;ok9IMZsMSa!|(;xrQER>3-_S+S70&Q53jdScKie zr+ip1-Q<;~zxBjH6GZm^tTeSC^CKX+A68tSlU@8rjJ2qb}72``j=U zeT9my65l2n-VO4`A9~dK3<)+0q7Z1?v?kXM9)he9^u6;f$yAhV49W(N=NgDueUyam z+sRXo*@!R7qeSIr|9^)TZ}@-QGJhP&Q9wDH%_f8UDhOD`h7cXCtDk`1$J4br?GbU^ znR{`Cu_YSrlR=KR3ua5aTMowDC&hgNin8M>e-E=|;kaZS*3#ubqSYR;f@TO}z7- z{!8cJ>U4st>o@*Y(5y^;ADDOoAd#Ca>~>o;S_nL0_z6DMaW32U%bYJ%2D#qsbiwr~ z`(i`;OU(PXLK!TjEd(;uM7ge8@!(DL6va+Eh#7gc`k#9ajT7<&%?dnOWsV?e2JJ6c zM(uhVZS8|Ikb_5r&@F?p$7sbhJ? zC)y?(KllN9UwEg+n9bw?SD{#LG3*X?^V2B{|{88#dQTiAz{QiA)z7Gg1^H9YBeRw4RZ#6 z9By5ecdlFa|x$d5mUt$ADAWQc&f&6>2!K`ZH$moqG@Q;1MTk zcE1S_Q@g%z!H)_QIqoF^3&=}X&$vA4U!T&|v12Eqw069yZPGRSOze_cr8p=AcU}Bn zR)D+SIhA@Q??23upf$6*I5KQq@gjo7D|k9>bER@=OB;^TbnU|3Q9k%P0 zu!iC54jI0Wg&aQ8U^m|JzIjwh^0}un9kt_KdHEfzRZ$k*P`_~uFzn!M6fzBRA#})L zf^T@mDdhPo3bwfnLhE= zbhOZIp-ZlW$0h1tFZZN}>Ma^UxH|tsB`%%JnC`*wn>Q%omMDwqYKe~(WRlBr*Rva;Rvk*H0fkQ6KAvTBLBYSzcAW##$tuIaF9C;b z(#?C1kL*6WqI7)p+=HH9_Y}-(O;9dnzJHxLfwpuUQQ6IE3vhP$XW@6|q-sWzhS)%5 zwQ5Q1M(M639pwZDF6kyTzMBN-B8P8WEtfC~$E0B|b$RZCTTM2iOlS&ARB2^2L%95(x}q+yBl2yan3c zV8R~)hW6j39>qbz7%=M@#}3z82ZuuKMeC66hU=+<8N|Co=AO|*OAXWO4x($QasKl^ zv}o^|GF5z#$$d1`3M~~RuWW`heB)=bD!ey4w^YyaGZxi_#@3b?1}$SXCrvx(a@RLz zk6n(G5jW2sG6%I{XZF+mUj7ruS$#CbGRbvM?p&+kx!c84UBw2aQR>pdLOo306~^KK z??!9b^g}|$$R*lCbMB7gSRUnDbEt?>dZ*v|0$UV z5K6@b4;o`a^o>||(icCy%FESfRG&WanVw7TQBDr-X|4KTehZDx3pY^ZMud!G%Y5QCv{MOq5Dr2l8%s|w#0wGK^cpY z7WXRA9ck1=YXY0~7 z)U5b7sqB#YdO^^T|Jy8E;E%r*iI(cY+By zzhH#a*nRg5Dx?cH@PT(qWIs=C~b*% zPX!}B8El{_yF7PTeqZW=!oRhlEMC@onQ8iarGuC~NXTr1Zw)kUXSfSxb#H38Yk(M!0IhLtj3i9a=#P{zF}px zApLfib>w|I)KplyS30gFH zVSf)8Rd_K5v9(;~vRoWB;51ouF%?Clbl3h>9zYIuukWWy5ko!wKX0Y0>PIIOWJvbz zu18okF9-~oCEvd^X1$Nz^LxFeZpoiNKi2;dpKf_!TxBZcxeAkxG*39AW{dTSnPazt zE=A=v2(f)W@+B}$!T3^oi|MUco|(L9bWu`rJAmysQaiezQ6I{+}HXY;roRf`Nt&7sb4#k zo5bGoDH>@%{nr#~k)!ea^xL`i3TKrIg{VujJK-X1V)6}CthKKlI{y)yR<>tSC0$FJ_QkZtZ;HUN*QJYxvIRwU3YP1M(;D z?`;{6EfzAJpQecB_^Ld2M#2mBC3$UowAFQ186{b9Di^vs1LcvI;y(wa+<(0K^N{+U z;!0S7*Nz&6-_+2a>NBnBSn1^w>WODGq0givp=in99t#($93w^*K-1BpS92|iGRN$| zh@U(wrADhN$H?M!CisYxh8-;gaVG6*O?4hba5I74U(l#P^F|UcO9%G^0PUskVygIq z$l(t%LQlb-MK%RIPX6x6NfET~aO5W8h||Vq@b<+HIjQV))cI*b3HNan5^O(;7-(#o zOm0B*K#trZ+-W*C$r92N@u3|}CzKl;Q6{_}sT81e5OGd@(5i;sB^G~|^k0i?_xaVy z5bOjLxbZtcB!3-7Ehb0Ql>?qU&sZ-DKM>rlV|f1M5a3OH_v93OKy&vbb)gXa_TOg( zAh3>?(2f+Zv;W5?DiuB8MS`ZfY=wgU#KJqc2SrdUf`$S${&p+N%ItsZ(cAH@asLA! z9u0=#41!D>x8ygD+nM%e{`+{dsF{6gPV z+<&(}(l`C61AL&d$2DS^fr>BV%o9{98vQo3m!nfi5J@Rl?kR^ZI576zSv+Ahi&VOO zk_JK8O2Y9?`wV`<75do>Hdb7x5EWZ+koR?8;dD8D1grJQh$lrPiRS1mS|o z^_vvX8tNvP-Yr?YVc7m_dKpRS{>x>k&d##q9oPlGM~zm{<%|e;G}iVXRA+Hzf9qsk z5+UiyUZK}fXHdCLIN80u&L@|_ZvNI&muI0(X%%h42mSWlb-Ea^@ zQ)1-dSvVe!>JaLPxK?nhwYt|ti2TUvxsi5Fw2Qk=P1y50)ben)!stfe-NXCuw(-Kj z#wJ~d!_iWb=QaGpnMZHF7e-iR;mJa3=!Vx1;+H!I{A+#g%dPE8XznzxMmV}=x#d&~ zF_Lq0ZPa%+6;%?Bov^6~iX7)@$l#Of8|eB+g!ME#dA|J&;BmAM(76B=^eN5+k8@7L z`zUR^(?^uF&L1FLp$?-iE0Q4Gjgpd^t*Ck9;_>){v$IEC>@#&BUZO)0?b{4U;*|$-u%8Ed8q^Nb>~Ug8@ENlHy%^s_2fKpWYG}VdbMgfrMpe8c)&mVEq5Y z$|!J{p&!1A!;=nijnd-_E}Z0K2$xJ^MBS%YDmLvHGy@&JOz@YxQ-QushN8h)>abDG zi~{W%L!rRinL_x}cwQ&?+r#ou${392Ei$M(xTFcS+sSpGXb0QCvJfO#nXb-G`H7$T z&PiItpto#LsrCG9kTyI8H$<@WLTxW5-np67gGf#paJQBn+f%t+>gc$`x<6j5QVB}d z6Z&kFfvhCRk%yVI3tOi2i6yzIXooB$2ESzd^WS51h$a!$uia+~MF2(E+jtv{i@MO| z>&Ou(D_~5HXr2&rtE&V}?89J)vborZ`>{69Y+3|2m8!0mT-0PZ#faMVS-ee1x^yy_ z@=qBG-Oo&7hB1SC>4_$>uVUN7oMFj+_|OP;qVHcf<1xP zH_pu5iEa0kRN0`$QGn)F={Ysttnp&N0BqNOIP5c%(V^_9%2wh;5IN99eXLiT$Vpi6 z?hI-%IJ4d#3h}C5m_W_+R5ApY9TVOy!3QRtBf9$vAJP8-xiLGKC|`m?r+Ip~XzfZX z+h#H_g$UTF$|IDYrq^aVVr~0+{ny25yus{(ZV3d2V_2l}KX;MDWeh>sxQHrLlVZBS zHzV@PvFkR-xT=+u4kbI~mB=+P-U1DO;h7}WG=|72B9)|qmAz8At@Q40n1@)ek6r1D zZ3N1rkw~AL7b{9E@wgjE%-moa1@6MVz3H6KgDOWg1^&mtbIh{1*@E~Us1s=n)GO=v z^mNG4#}7=W9Ys_$(aqL&^(l?&^v&%}e5-Z6AxUg-2b^G5Y3k5a9y4N4p=Xsmk>x0R z3DLM?zU7sb%~JPBU)zZUsZ9jCRuN~2gqAsGD7ctKHvjPtBqOBTQHq1F;-E$}r470y z~0O>U}X)_Y0DhI_4_a&M^u>n zxI}@2+KPTs8SyhI552mlZwBj(Br{O0@YhEOxn zlOi^7umkLf->+?XZJ*X#b7ww!nFR>Ks6_zGsD;*-)n$V7EMGvHl5Yn#l+gUywlG^gv+_thv=RtC4P^m56wMyWv5w9PGy*Wl&o+svd>k|}5 zDgVTZuxX;92&LPFMNLNw5KY>5W=FEV*)d(EPYSZBdqjeWv_qcX(CUin#`jh1Zw7Dw zn|oVgTV|9wiK($4Rm*otieuk*QH9gALSNWQhS{+ zYH08QJqm4lLA0PAEfZ|wTA5?LITBnyF?S720L>a3Cs!P6Sf16|a}W=EiOu}ZWBKmM zVsrK8))%y_3TB*hYDET$i#2t|yI${|tk`94WFN+{&CG}_ABd5`=aiJr8F)K(`9O>K z=X3?E@9^(c);~IB<4$AaHYxxUqiDVomc62VnsyQmhu&@J&MyL>Q|VqUhowq6EH9MR4xo0USFIa&!!fd}&&~e`GPZ+HF4By-}}> z=3Co3<2z{!seC`75F|C*D)q;N*KIck=jeoxt{Hc44UAi`lzllmjZh~{SqbrOd$F+pnSBWw@~1UWuPKn!PR z@i-~BQ+nz9rOt;CzYn61*Gn3Z(|zK1%G=-f&qKW%*ktW&>4yXMZud@6B3PFcp?1$3 z)Fli=T=CDU@9&m7t+r3>wZ!xsL!1SH8V$RAjxY_7+w#a2N-B)_!iXrh{gv9j%xQUy z9=J4h0ODNI?U=hJ&T{UJ4(03sG17YfA!(r7VM!Na9kbnwGO`lf?z&#V1%jxE&jFU%CAV6yE#f`c?tKhPT0<*N3{zsiV2>r)yPs zZT(FLiaSRX7X?n6Va|Ucn1`S!R2f5b$@S7emSY~hCMmH^Ev(^smhSJXcbAu#GZt7CL*)2&p)v>c z4j(GOy(=)8bW^+EwE1RuwKes5^4oPS&XUDDUf&iiBS;{3ZvD*diWqhDaj%tB+*aJ` zn;=0i^ZgEI09!DA@@*s=va?Go$Svb?T2OY`XB+Y{1%ksi^mj?u*d&P^Q{jGRR`N$D zHLdnp8}CP_`+%DvVc;+-8ff%oSXg+=`*SFB=fn{r&bN>`bjv-6x3U7(g&lz!f}?)o zgqERj++)Yp7r%D125)W+Y6;CgBS8}50XISv!QkZ_S09ILH{1WSaF6ex6w;Vdz|{8D z{Vw94ysyc=9bt#(rOYV@Rg|U+I+=o4p#B1BZF!b9BKZ>a8>3HM0m3W^)TzXjn7gS{ z|B!|Bk4x7?%Ftg10@?IXRIW9(R1r4uQ#71@`&MGaYBi6KsTU){c@PXCj$BZXosu$8 z#v{nds^iZI?3H`jiHeR4^*FXa_|QY-Z|(59Wc$w_%8-F-O_dm9{s7^tensV~M-fd! zNCk2l0imC9jjVju7Vmi!23#cJ+iC^_uYz z@lqQd&jbx>+#yigwc9H)Qt}i;Y-~(dKhp~a5FwgTlV?U!;-87(3LRIU|I(XUaqPnk z^{T;>uR+MgrL~ottbzth6@O7-t?s0qcefZl6(+Ec6y2_1C~DI-*vjmB3{^*LbKQtl65J8giZyB>_KYSkvy%(mGcWLs_HaNT=Y1nuTWIGnh-XHRB9lNicPBA|)t`<{oT%Ro*G9Gj%D>j8sdwyd zZJcxp2Zo29Q+U+oHc30ScX8dw=f(MXq#LcF>q_b=J2aqowb;RM`4R zrS@MFR^RxI4Xuejd3 z6gm*;y}*sM-m#K`FJh>6B17#2we4E+2mFanzz{i?0C`&CnaY{T;=cW-U+*%)g_fB# zX=T2iXvGsOQKam7+c0kEFhoX4#`$5-sHa3SUx~^BC?D1?@Y0ugMeM>P{za&M8qhr! zU~eI#o?Rm*lD=*ABbeAZwaI5ei^GfvQL%>vIji5|NHtNJx_STLgV*Y5re1sQ!Fpl{ z>s_#M$rwSwjv`?OhFS+q&?A=}#Q1(Wt<8^>@62ZD!qUP&~5l`=!3lwms zfqvFGfk|FMSjo_vFoTO`Fxc$Ye(-9`>|*Oh+{XejYB4w3s&s&p(cPru1xQ$8bop}mq}cIBX#!$4 z7SjGTh7i=;2afgXNx^)YhskOyo2xG9?;z@Nw26bhKwk2P`kOTc-kG5lVa**GE_-fkk$@j&X+ZL@pgdkHG|XnTr5NRGT?q6eGFZjKmPhP$ zIs!~pO)*fg2Z^H3moKLVR2E&odJxe=%f`PGZ|{gQzk>=S`(XJUGOSCVSyEOM2nu`W zEI=HwO->1bh!#ht8&McUnaS&?#^-ru97F-(!Y-o@AxbOSPLM2Gme# zzx20&_eus00j4xB-934p+{EK(PT0yU@UgeH?SUr{<6D3hVJ}v+Yvz)vSulsI-wkMA zx^JS-gwPs_%0<@B4fX*>g}rOzy}x$HwdEgg63u{U4|p`By-P13?R6nR=Gjn;lm~;# z`?#ZbY28fp<$5NajgZDsthAYhY`&Q3aXLvGB++5Kfp%3uEQNTft77ciU7E+_~$xz3tZbYLV-Sf;x3L`#*ZWCgbm zwYh-9uuT>j^?*V!d`+pUK^<9tcT3>luiaCJsu%bfBDMQS#w_?1evQQ|(UXxPD#qZ0 z-0f|QtX^VnU#!KyY4Am><%>=JBqmU$;k!qhpEcJVXcdZm>JPMC<*yL*b#K1qn<&M+dd&dT9h}l$T3qvn$OMmYMEP z<5@^Xfl%Xj)b%$(aOI12bG6}J3MBN~qf-!xvTRBcVUla)!$nK^yE@oJd+QX^=E3P% zUkvGF6bS+~B5VrE8Uf1sI{Ajy!n;?Hrc|#`Q5QYk6etPNw+ig=L9!=vPtompvvOiY ziwL*RWH~8v))<)bc!8e0Zs}vm9L}{-`x`9S@q*lN%W1c(*lj{6y6%am_LohOroT{D z(oiF#U30fa6Qp=rBm_n9kdAAib@8Gz#;>7RC+0SV2>6C+x~jyMbbJM- zMw;y3#HeWpF8?IP*`}-OhMdK$c$ZTkXk!3tD+;B>MJPZ}zCdVhWHSI)8=1O(2~u}! z2kM2S*D-1cr}wkwvs#O99Xg>%4;AsaD482VDPLPbe1VD%2&Z4EO`o{unxMoDs6`v{ z2mJ7O7b9=)Lc|#aP)l}Qua#=`3c~rpYg;ROCzTutX$KU|d%-F~N1>KOj2$txNT&XQ zVwTH#52hR@!7!u9NGZI!afLO(uUBN8+(vR zo12$SiAXyN1%Ynr42A|%$dLIfg+i0XBh?kWjFN4$Ge@gm$6B5vCzDKtA}J0S>!TF7 z(uBw1Br(1XGH{o=KAge?8J>g`Ctk@lCP$V?#eKRUe~!$hsQj`e6TTOM^#vHF4}Nt^ z;NyTQOsKYD7kqIQTHFy+l2^0HR@o3%D6|e=WcWUox}!&dXnY$G z1`@PvhtZ%ySc~_5)BS4UBgQp~2&#l`Ef%xWW5Qqo6)nY4qrj68|Q^$CMDOP{hPY+L-I&Q z7Fs8kAN}-XZtH(Gz*1at(@=O?0^6lG=fRwWF>J##;#PY2x*CcVb3uFptStMOlksWt z4BNESOhr2#Dbi@buQ0TwRZk>E*{Qk>R@LyZIvY_HFi z9~UYnGB}~YG3i#`bmCJRl$|03=P-L`Nyw|Y= z)xF*>>CLNihozB_Tjhp4uiRrXG9|}}aYJC?3;B0Q*P}4eJmCOR&g3S;8f`@;%`!k;#T)f5FsO-&$HZT*u;eS$2=ALHGa-$S z_ye5R1V>UHs4*a+z4mV^vWHMO;Y^Q~Fce-H^Z-vWln zYSr^>x%}rekiZb#Qg-l0P#J=aMe$ajjw0~tX^fZ~^|UAramXMTU9~6uS4Y(9H1qo- zmnF6hF&;c5DwYh9rbCo4NKwL1hE$>*zgIR1@+U<^XVQp}uaClHJ~En=v?Dk+R0mFL z@0x58cL%`tF;rE^@JZCTF9Trg@cj=k*3-N~>k3@1LKG`RxVkm?W_zybwQ}Iw+?DgM zFw+H?cSH#DhueYc;tF10J`TK6lVydk&aP-rotu*MzO#_+m3B>aXA5J7Gdo40mh2p_ zO0*vHKRvuyaR?y8>Z5g#m`^`ujKR|Y*e&ASh}MHjZNQ$WSyt7s^oVoJmd)l>k2Q@` zl-N0Qr{}*Kl(R2Faqv|Fh*i96<2{P71`9ut1H+g5qJ5(!bS=*B6C1y>?y1zOf8Zit&m>MRQL%`{V*UiC;;2rvRHd3AcnLS>iPfZRU=!xm&dR~iL|2a z7oINYbT4*%1(beYTy~RPQ@jJoxnRC5L_yX7#X$~vcD2*lCiKW~FKVobz!okt%#J-w zr$aFu;aTE6vJ3gRYaBB|V`s6O^tz(e{_4Tu#HqmiIZ~IRE8(Pw9$IBJuJRUh5e1lr zmZl}+f*}Ug$5yT@WI=!HC*7t2)FnufJcG)>GI1SEC@P|@OK4m&wqanuxw&+0eHvs? z>EsW1Bmj+(4_-)U2k0YNn}SIl3CjecZ1qfhx%K%rkpby{`UrsLOt;w-ZbXs8R6O`Q zF_Nc&X4SxA%&P8hPsf_6sPFB*qR%;X_vH0{q}gg`$t7&}xpXOu?2MqqC^R$COgzs% z3hc=F&_x87Az?q<>yb!8g>2AMbgZd%+o+J^fYyM?$_}$2#%P1x7&_i@VcRn^(izh# zhj38!!snyXzEO&%}u(I+h(L=4V>bPc*8SYo#s9lOw0 zG_zDbJunHO9wL-Dcnsy!Q~DBxVYbZ1z7`WB%^_f~&3&_q=*&igZ24er6k2IL<+;1myxjadN{FXs8vt)($+_q34XM8x7W0rkhl3LupaR-ts383hn zGp@nhi+=)$HDlktf7Wb%%QK1v!Tp2=Do#AmTc$iXwx=H|nNuqEz{@sHW}j6N2fw1) zGF={+4Rl53yJi(PJ%Ke<@IV2_1T!+qF}-{zCpUbxm6fUm8Wvfoeg=bnF0#pz`GDO( zVmzd5@rk5X2z9kvtx_d>NJu|Ay^%O~kPIjJT0%#!LpS5cOyp~h2~wDi2Oi981&;GrEgCe;Sz($UYhs`;M@wGKT#0|7-2>T=5?Qh&$~s8GfmZvMoy zWcWYnQcq1%vUz`lD4k8D0c@4h((ztDn^)t@4^tgazi;AsN6*(^Cutb6~Oy9ZugPz4r}T^?j!biH^>9+5hv} zfep&UCg%{pg6;v2cUS8jwhyeQ-3}C!R)6;J!vX$JZ{4Ax zL$m>*s~CFHyr}jbIgRquk}u}unyS}-gx)P#c>ge>4DCgLH&+hs;|NzIIQ`W*L3ZxI zQc~x9uwF0nfZ667O=AaaJ2CPT#0c&SShpni(P1?vWuSe~wBQ8B66*t<)R^R+K(y>| z)|x1X21=@S#XTo9Nzs-L{TvWx+cG~h^eBZHaangvD4^s(cnbg5?7pllwv{>Fb|WLb*%g9)?_4BYL`L6%hZ^F{8iZ`H1s zW}jWtGuIp)CnDS|8BH`|Z|EK|`E9sdH(>}#l?3v87N1mU9WkIb?}kWKjQG#Hip^d; zH7jxtio6Z23$N)BNhR=ER%PJG@17mB1%AMym$Z^&IQ#iB?z%)koL7f0FbgtVMo*d* zy^K2%mo^mXPjdULJ~sX^Xl?U)8!G0nmk>#A^e$HQ;UuJsZzum*drZZyNEyga)X+s> zg^5!+M8if9!nDUk*3Mt& zp*VVTeL=0J4gi45A75CiQLQ&3!A@kzzsmE~VE2e2&S9Ji?0mP&YDYJhs@=b8(V)E7 zTtb7`qS3o4u18U5;WX83kYZPTin>}RVUB_-W_55ujMU!_>P6ed*2ui@4qt3!&ZB7o z-Ad<(=yI9>yVQk+>3JwBjg5Lnt!@!vbKMY1Y1M4J?-U7QvDR9>taDOUNDn*aiBba( z!9mDexo(+@9sJcd*Y)(h%a8Q+9rfg@Ij!u;1X-w923#WB7c5*nSA;ZR-$o1h$l+z6Ca*wYeu<_PD@{8N)JoS{H=dle&GAA z&yDyCU)xk+*v>!>4Hj35%b}{2O0t3Ws?2&N0=o9bi@PSsc zSVtFae*Zaq822Tkr(HViRjf|_{ffT1j;k_FS7kaGJck;b%3YHA;A?b8fuv~)mS?q` z9h+diI9KTbQwtkC>-0otX+PXnoGV;HZ=JB8C0@y5*7S%sqz{a6VEq2&dhC+eByoVh z2G^p86DO7~d{{^%i%(Y^CZo|29NO0TF6~PeKi_|Ky<~A}&og3oC%ArYpt`CSObYk$ z=U_r`gU^ny+i7ZpT5$J_*@bHFzc?l{PB;0q1O)r^N9M;;AzbJPsHR4^BBSkXZ^at0!sq?H zORjnDFs-td{LNi6%7?PNQh+_{z)kE^pg(1%e^iM5^)My__PMpv7eg0zdOc%HXe|Zq zZVkBx7i-FR;-@o1gMkTgrMG>5#IU&J>LwtxGz~*p9|CWO4uKTLtyieH4Z?p0b|fBP zCw;=U;do#hy(#`{7(NVJ5DsL34W16v@Ti1@ycb}f3;-Q(U0$G;DNx8yzwKmGFz$+($w1j(>9$n{1p;ktb3sM2?xEtr zn?kEprJ|;}C6({ft*wcq?eL{0nN-wab2QgRmp7LFW-6V@xtVEk^0uah`H=lp9Ujez zYDd{ZnZ=Ijk|_8-73#Ns!;4?4E<$$3Q}g59LCQPmTQExYAj_h;Fx?Ia&E#n#pfKaBwCz1V0>%1-rY+EsxY_lO8KwrXEusU za#l&OPtl44+oUn2R6}dkuf=U$LBYx(KOMdc|Ljix8vgRf;9r28@XTPwEy2J;kmzLI z*s6?#fvR@DK94q$zDMcWrwS=I9?!d9o9sW@@gOw5;1e`o2YzUBFXrWj%b1L%!i-Vq zdgv7{e^+)UoreSCqD9y{z+Lm{O`iwJljC5PcGB)aA)SrO2j-kVCcmq*{59tJ?tSZ& zu%W99`TTj7>@^I#_QjGRN6<;$BZc!oh@K)4mk~^2-8A|BrFmYo-kKzOM z>;w0(`b8za>zUzKg$|e+UIqb=_+~ZE^UtoOM&7@e>=6#t!?!L#6Y<{?;5-HP#z~*q z`&A7(Y6AZ1=xAL>UAiQd_|n>H_A`Ir$T+sxUYN)Fo8BoxIef2B$duo#yUp|fZR&vB zNg18|rxRM~iCKOw2W~m7&K`XoI|?2bXMifsmz#$%<4tUId2N7!PIe+i_p8`|>?c~9 z>C)St5uVA=)F7c9KfP?***1RireQC;p_XP*W|F@KuRImIPu}1Ap2@KLwUg*KW^|}v z68;F9>G`F>81dMIb&&3ni)b?*W+*F2jkD3t@u#9^M_G%@e1BLZnFv3i{!nIK1mhwu z2v=R5@sZhW|mnyaU0^S$`yOo?R@-z1}R$yj0-ZpD5?XWO@#FGShfzHxPJ4T79oW_v#&g>R4i)t`E6xFC=^Ki5N6?Y8&a~{Um4(*(G zd@iC*xyiL{U@~r0T;Bc~Xc=Ov4j9T*i||F@zVcU@x%r8Z7t4EjPK8Pq*}Axt_rih; zyltn>T%dHgeQoLwx%!uc2rS3C;2&c@u4bCM#{xx*7@v(DvL|(4q+-mCa9Wxv?^is% zF+N>lY!(}CV)5qZbVZNPQ^@bu61GPa7{h|zHBNKLXDa>qM6^Y7{#ugC_Dmd~e^k#yc& zZloltoD*ql9i})3yfJ2={TdKcpzwsp%cNe4l+%)OB{#TDCUwU-U!kf4jWz7VxmX<4zHY1ukUf|uRjB5l{O4}Umi1f*nj%?rWE-yFJ zh`(>!uT?S$agM$eu+J5k?vD{AOS1FFd6`a5Rxt&-P(;ol-_qYm?G?g?lnk^uR9p! zUT)Q>{q3Yqi`|PNJhwnR{c^`#{$@c{N{ir&M%^m+lM*t!n#gy(+k9!a8B{;seiAa! zqm};ajz#gru;o{+mcKFn!`@tX4czwc8J~qfMq0nZ5eN8UE!LW(EcU z%$&*PG1a$yCW+bU>D1pfQMPL%OAW`xC&Ek}k@h~k*k=7`rJuh_2*#(Uu}{I1{fnU3=(j6t@Y5%#EJg ziiqz;02`E?y6Rb=h3G;uU$cyV;n?U;Kf!G*9b2=PKQ0;X_FFE|SM$oXn-S$qhADDA z$DR2|0|rKQiHOJ`ir;Rvg(EZ7ddcU!R(4D;>SdHL1{^&!AZwvaI5coa;RN3~FH6xQ z_g~qxy?gn}p2#eNT4b4AItQTN@*ga!DSkfZs8{(=#N!~#j1tQ{dE2v3GmZ$kSh=(1 zj&Q_M2gKSF45J@1bDHEm+r}wSaqDkpq&m)Len=9D?PmsO>htDRZuXZ*wY|+HqoT88 zC#y)EdENVE-72-~gud&xo;sW6lMmS4ef7MK!!Mm6V0*Qii8Si|le!9H=ALkZ<0Qz- zmZr{3TvBF_yUu_5r3U+|f5NJMqKEH6e#x0{6iT(9tMFaLr!I3+7m%c!loCt{&;;lU z{5AH4Nd)EG7^YgLQFI(a`gJAjSsKr z5a3J(U#*l4(l*D;-{WO?s84C3xDW z*3>`Gc^VO23MD`t-+(%Xy|`hU-f zr~*69M`Z1Cg!xfJm=*6e_&v;SlV%G~#7LY2denf3Z`oSXr_%|BaiSi*i$; zeS@zX_5IF(tG!KU3qRh`Mv|Tn?)hI5w}th!;t`}^(jj0Z z;mOEmuJ^Z}Slw~8DiYp}k(A<4Ghyw9NII`A_)ypb40*!bMyiN`m~YeOqrS_+L-qby z%0p21YfQ|vpG(IEyc_>M$Z3(cquJ8zXtYHIYIvuzZ4gGFV0Inb!!~2T37HxU?i(nL zvML}AGzG-za+KIPIPf(Dg0u#8T8`YZCeB6Oy+oC2UopfwZ(<`)xdnnc2>H~&oh|*) zHASbplP|aZME@p|Y))Q`)$um5H1uCDKoQT8cP}+!T)6mU6^^mmdM?g?vpD?qUy#_2 zh}&zGUk%X+rCO)zUTr%xK4B8PTlzXf+CW|r4Rw@nzb4V{%uv0XO;EQ{Khd&vd&|@} zN<{_xB*FYF$gE)b{JW#jlYBIIG#Abkg+0O4*Qz|@QUfVW-Q=O-3=my!ZY;W7`(vbX z6gLNa(mS2!;GJo#D$)d2a66k`#}hc#`L_EDCxmeqFa>keyZ#nNG@FFT@e)GY*=)ML za>Qt|tEx6t>tv|3eqyTDNxxP3o@&=Yf_KN(j?mx~iYUel6VS$usG*|yRA!7kNcf{R z_OeW+?@rbCri&(&ewNqjE4@F!nQ*mfe~9Z-9()F7yO`OM3{HmQtO4c z09Hs9`qA!hH_&a4M^>u0yRr%sE zEBV-uXn0}D7sMQ`wF5Mzfnf`+D?0HL6ts$Dyp^TnU$7>14N9)Qu=C(KNADvVkCcxO zcuE-8FK#3qu=f@%fTM)iU+as*E&|a#?W#ji#O6a9X>Y2p1P3H?)!p81|LO@6Zl11e+lZj@W!v4gNDT7f-JeJ^E&yTzWnE8x4(xpC9ch)siIl; z`(Z2lmy%ZF?hh6h4zR8=5IdUUW;UTdJJ2Y!{%asGa066-z=-Uzk^)5iYN1k^`LL4U zsn0y@+>Ix zAHN6?y=lA_n%qO{ID$-L6;7lKFdz;NZZi&cZ#dHW=h5C%6aM`W%k2{sNMhG3%4n#R zLXx7h6Jq~b@%b~OM_XCkjkcjFUMx)ObDt?0a;Q(@@FlJAbX|ju=uxftwPpLR6c@B0 z*VqLI<1iJ#P+zP{IQkn+vGcaZwdh6ir!$bk_0rGfcIsGHEr`!XzFm#J+Virc7e=j$}7=TKxUW;XpMd3Corv zSeQx(CCQG@>xwo`fLJ#}!_ZfAWv@w-_XIRWs610u%?$)z^T#}w9&1c6h&gsugDH$g;vmbuT4Y6 zb&Rf#f_RhRB@@F6sL$lWuzs9NYrV52oG$6=s6ShX#gf!sSnf2x6_rNdMLVmj<}r}2 z>m?7J$^)ZN#)Bk{ln*zv>uJ4WB3r?ZV)B6=67&Vc`1w>}bR^4IUv*4*RO5sq*i$bB zbhfuuGog?D17edg4A8NO<Hi{%Sn|CD3ks{ zd7+;S#FY!f(VVWW^|gS1)^F|1{?Z>*ghBJ)Pv=#^(Mo9yi*DdAfA0lRc+_>_Kzo+= z$}_7DL>dJsvzxK+vUEfd|AG^yb{$A{9pnEa3SE27cciUGE4TdK#Ez77=|Z{H%_Wm;GX6iXq20|(U#V7 z4bWp#y+*AL-9uYlGz4?PU!e>DU zBz0n3s&2!AB-Iif&JFHs{~!t{gZH%ha`{jGdXO7=MN65y&VX(?deb_3a zoPo6?e{|;|hEvs^|By%0%4IGsn2DGTh76|OwA)re2nf}3x=&6Vz+bN}998~42mfQL zmK+^2@CSDyuFp>R(`?TTk~ct)fKq$-FMkHoS&V@J3Crxrw7t_KBXoJ;KzjoNxfILg zH+wnbYP;R2;dTGMS1nvDD1JMp^}zRD6YhOTvgCwSk#b(MlmQE=L+g+V;N@1cI#E!S zz??q_bRVM{r&-R(Q${qRG`Np-aIDLifxLB1U7F@B9@S7j2yclFCcUZHRJ?Yp4QLp z>LbkdV=i+u#y8C_fmU9&wo&n#@F;|_t~}|8cvPBA zu&IQ@d7Q#Pnx<=BJ4jJGUq0bE6It+3=(F4o%9+s3*I4+2 zTQ6i}EUq*zfgo)>e931SLkVfR*_;{G&v&ga>YYoCnTN*EO#HN43~VjQd-BB&CRA^p z5NY*O*G7pIl|EKJ3}>G7x;TtV+9DcUvtl9Fo98m3HLCvYCoRS? ztcb)-x3fjf`y+0K5E1DhfTbP45S%ez;RZ60D|FnC$-3C!@`wV~RJU?i?B9-?VU9=B zg##2;u;DOpdrduI7n(X~_MkHCIJ9ijZOr-!dRk-rGeWU96CyQz3HnG95-reN6I0e8 z;W}3Zoyl~kt+y*pDcaT1JID{L!U1J=Zs+^6=;B5Aq~v2-)s4dgDdF3+5vsuP*Mh6n zct`g7^u-K$I8q!0v>1q4pMt8a^;j41f;6p@yyEOyHuj4LEgZxmv3@8NzFdRBDweAo z@-^CzCszjZfm*~BU~y1s^HnEyw8D;`HBugLNP}A_gc~cF$pc@2{+!^%E}C?goj^EV zMvIE}t${Mu?oT$NfL6%%c!0QY4SAL&!?r{WlcO~)b`3Eh?2?6bSsrL__gcf!C@Ft9 z)T?k|1%I`aM_N~!O-h#mwH(*&=&_`(o&=!CLARvg^C;rb{k&KEx4MdH)FzjC$hIf=t0iOai^p8G21kEIwWM77JZ%@ZR zIl=mKY#|TU3dtah0PnWjVreFI6kK_@uyEjDXGVG;oKs)`N@V@eIpN4@`{oM@}P=$`LXj;0u@7L z1SEM9Q=n8N)N$Ll`Pdo*aK8rn8T;IOpW@H?*yTX86|b7w1|)e9KSIWYaI z;Nvb?8&|BXL}kn)om}18R_SM!pcd{+w{INVktKE_h2y$BUhUxNn-E)#mNY?%!;$`B z2&rS*=M6LF8L?`l=x|c|8MSYvhOT5RuZXkW1;bvEK2b`sgAf6kVqY&}*X)G;V5`h_ zShpbXm+NwJbW30PylUkJBr>)F3X)vP)6GB>#&T%Et0p3AJKo8HL?ZoIiBG@!axMMB z1`yk44xpO%dP<28iV((}5KnZ-7+qRXYd?+1x$@qH+IrmV#B%GaLQTH65<;&5q_ikR zc~1_1H8eYpBDUaHwgtfyGd-{lFm6d%=>Y!`l6zK41UDj@PW*h)!-_O9dIjX_)H~}3 zF|k7eBBuc|t@RLv<}P*S{n`WOk7DDOZe98ga*11T(jy>CxAyTW1d)4TFhY*qf11NkFl~g-e#c0Rdk@?T|diaIX z&a`3AGYQFXkB%^Q5LE-D^+4QB62|%&0Y3QXIUmqtQuSw`T?NF>h_o4-z`^{>jd{9$ z;_Ps+A@D7B)ZohxeS4*7%ck}7+n{qrCwb_%Q4l+lbiop;uXPwmdTYiK(1&b%IF!~u zu;K?)2gK_zZUMP9t{i@|-*2(X(uNFN`8jZAMw& zsUJR`QDF@MlDuKi%T`EKhb4a??@YavCy8MWZ7nN^jC%3cwg3 zkfW7waIfGv{?w6y{DUx~wgsH^ z71ns)06A$0MTxB&@V-oBK3UwJwJbjg?iEIekE3J9Y9fpv>kiDy$>+yueKY-Ze-=)g zyk~LmDZPSPUK;@l6Raj7B(cTH_FXwf-_F?qfX9?>tBW$4oeo8m(!7}$6hwgkW`$cg2~*|E&K z!ecuz8H6WrscGb^jDaB#ub%Em9_GU`@zErK$9_%dVC9RdP4Fv_aEod2k|-Pv0IwhC zJw@t(6PL@%ffK;XtEDZLhkNd{YvW+y)hAA%Xi51aH={s^-x$#r{8Ir^eCKi_|D=}j zZ$Wa%)f$k0?ObwnT-0Qle`BN@jIcXhP==Gv%7ot#{BFSnOzK}d64IBj>aTKM5<;;n zhg7841nCmBP==B7qymsy@<{Nie~4*0llfy7(g#cvi{eq`uc@%=XnvSKGnjRyHZK@_ zOP+uFd~L4MX!hTmD6sTL7pYRl1zh&dqFhMw04Bchjv*H)kyYhw*n>z%JKv7*e5%w^ z558wopbMkbb9OgzD#4CNlX$1|Bj;Cn`WT2QSbWpmeyHR=(g4wA1V>0xond>uHO~3* zX6K1>VZmHA=ouH7pvo&CNoV{!ZQtjPxu1s0&V^Xu{=FKXb0vw>cZXeCq|>oLLSmlZ zcRom;6`A5-A>!KgaE_8Ze<)}G0y)IA5U%6=IL;)d1|A1rq;Hmb!JP{=;4+S6{eyea z#HswqmaXs)MYhH6kEJ+R*It-;TMknz_k-51RoO^Tp2q3Uh@prZcs2Zl-$J0op<}Bt zz=bKRc~^H^LMO#>|I|3a>bH*jZyg5Icaq;XcCSKdh#B+AZxpm-f zv=pt>d~6q?SMB60!^YVU@Nu*ji+|Mpax61){2Mz@34u9$^*;8(K$8{c)1{!vZprF$ z3M%cVL3z%_vUXQ8k@ay1L9_h&VonR%+R0y_xaj_Q!;RfWv8~4}I1q7^mezgJ{m64z z$Dc=ky@Ud+!J6k!a5u@v+`Jq%dfndmZ+1yVJ*B<5oWKfB+)P@+DuJb^7jnZ5M}bCJ zA`o=rdc)Or_=#6MYMV2nc5J;5LF&)8AssM^v1ZQd$0@~F;KgtfIm;Z1fKkrgASfts zXz3Wmo!bnO);w&-C>};Y5+r6EJ6j$`l}E%I7 zFM{D`rdPYFZ*OnL=~yNGiwh8pf0;FjZ9fG$b@#fQo?;$pe1*dAh$( z`y6b(XES&Ln#zZF>opQG8ED~VI`&(Uq~0%By-ThHh4H_tPV0~6+1JUCZYApSFT3-% zq@lnNvx)MjKpxeW+fS(3-6vrS+E?&aI}8lg__%!!!6KE$qJiu)&`)I=>r9sorDB5cj4|#vLlkbWBxoS`DDp7Jy=grV;kAbPZ)jc=!eKz?3g%N=| zqDz0|*`)oZ5do{~+7XJ5%Ch?}#;}8wr73j~N6F2>mzuBw^wFa_h3+}QvEos9)>y`0 z#sWIVj~>`Eq=N}=Kdcj{>t6m0HsOoixP?5B;p4vab!N(5!nNsr@Uy%9#xGJuQC|W6 z{fd)gxt^&lY;Y*U*3;eR*yb$@2C*g%`@ts|)+weq` zLR+9UKxra24*5{m@KUFu3FGDp6g4_-uh5qpSM&$nG$B8Wgc2++IcqvIz$eMyX40B0 zVnb|;0pbZ!K)XH@kXt4fEVpEblJW+}=IR&P=)ZkUTDhNwp!sjSj&NRF_VVvODf|+S zj8gN%sqtDZ=ME}jT4fN%D@zFM^4g;8s1)N--z>2H*}&^P(?6a;Ky@3?7xZf#vWYBo zTByW2e`%lvCjtJ1VtNcZI`8=-r|`H~Z2vxr?5riODkHpT8E82ubu_VoFoz#6WtxXg z5Yp=N((KhRn!T{Rfu{CGoQv#4OS8g%xeHoanm!_{(hp!tPvX_OWnF;bXb7~7k{jt> z&Jf`e+iF>t1E(}j=x+1H5{mvyoAWbKd4LD?2`_A_aL%Vckgh~5U^Ji(IUBUBhjkbKQbfcHpyPfZon>6wX#}hJAkdKr+t_Ob&{h$_ z4>(2sZ4f>DZG~;~TSX@yB|xVDj3JV72;K zSh15G0wYWe(-sW>K|i9$4sAe&wm{Ky-A?;Sg%iW`FGZm$RydOul>tI~Tm^5d3xsph zkuIEZMIfB#fY0cXL3AyAJDjRBX$68xOagn3OnU*iEJuELhv3-P0Xt$LRF<7jkWbuy z2t%pQIbB*$tGu`CCoCVMV?%IrV*UB!1I>x7XzJu28I`~?N_PC-J3K!^w+##Pgz@?HFeS3vRD{xpS~XJY|?n@f3H~J zJT-XP@?K2PIg0(BddEAAY^3(_T$<->XXQyGmL6r>Q-TR5OHUNqv1=tTkgxEhU$K*> z5rDX~w6Ioll;sqgaU~pZ#u4*8Yd4rEzzX%qVlF6QY-3sU%>0KbJ_76FN{{z%5jMp7 zzrEA57+KmGM;xQqv3`?ZjYf}5u7pbap!-yvlDrlEHqr(ZI6R;V3>M?V3?A6SCJ68; zsG=eSC1mK2$#Cu5aug-KFmvwYn6z3fgS=5em*EJ2A7(;7W-eFz-wN%^UT$V(>|n~5 zOIG$ObW(bqk*N^nR3~MU3bkV}P_%`irmOgOMCiX$GNJU1J0b0lC$NPKg{B-C7r!PfdF7jdIL0W88Rb*&~iT~*153_wK%n`c96UBI~c+D!(S%U zKrO*s;re#0Ls0E#bE#6k#)pz_Bt-UBBE@O235GM~3X`G?Xh9q=+IIkZh{6M!7rBMu z`Tp$PNcHbQ#jPmb9EyDBk53BOd4i#uQpMyj9Dx3$o%%RZ;2Q~DHa1I)}8J;QYiHzlIfI}Y$R*+;rp6i(Yel`&lZojmiF_Ije)H$5OKy=8E zpz%)+sDcOl5$9#d`yqfzH?8``8xsT7VF-kSQe=?o2W9CBGf446U9s#&sznQw!8c&0 zM7&-u@n@d|&F2XA292_pBXBXH-b^GZz`x7^fNSIi4OIy3#PL!5rvHTo8JE!RH_+1- zBX1A?v*hAa!H5Qr@(q;{%XsVo#31*BQBmVLX8B`?&I-#p+0pLs{{+uoBvdF8_a)f_ z5-*e0^M<2YUF*=AgR6c{RTbjFyluCOGt~0^PcH^9y;E-1>HRCA7P(l z+waMVxb$#j7B&wV7u6t4YaK~!Wp#GD;+?oX46KdGT&w#zFMl!G=lZGz=4IU?te z9#ryFpB6?><{j*8oDhm&0YP>v%A55nWC*bL<;F(4*{6!Web@YaTIrUM6NktvJ)Yf5 zEs)Hy-)`R%^wuu$aP{!4-dYbhu)w5)z@(~sa<}{T5Bh`PCScZ?zWWK=$9xYdz|4sQ;kLh)$+x7E^BsnmUz`zHK%oeVfK>Xdt~N z!TUh<*v7v5_V_VGw6v_n{h+pU?b*8-0bR%@3M4Pot%5UREkFbCVhZO3c*N@kLOi_Rw#N~64 zfKb*twB_OMOR+7`oG_toHb#V&iMtsdN&Lt7gOZYY(bU(Q7!W7hp$Ua408Z$@3Fe(p zts&KFFUoc<(F&qpAXpnASTf2$iUjtl!LVY0iH&9U7?j7Ouhphr5sQLUXBbTApZrcV(t}- zBeX@mDtpg4VT;-vw;<(~-figIIenv%RUL4sG@iE}R69*?tEvJmjo+P+-A-?#B51>a zm-U)97cP$XzM?o^<`w^9wqnot{RK_l)|Jy6NG2{_^~>+Hj!#lZ#xrTk$7$g>O(SU! zs}VWTFKbKPZ5{knBl`cN^1mcksU ze>g)mv?Rn1i)~T71EQc&nl~GrKQ(>vam~g6`~MdZ!djGDtBlvWO~qO3cvxs97aS4= zDFgFk!X}JaRZtW!$tx9L3aEb%9Xw|?gZIoJiGwdm`KY`&gEMNi+c{0JXO<(Weoze6 zf9eQ%6MJGjP3#|z7lc6HdU0#m(e}cz;ai0!p7DFqAB37MmP1P7L~(DiLk07FDvv-##6Mffs(7Q; zot;hDok2<3ikBgo8pfuJ!m3OgtI|xML!2d&(o6VEXv|Ty(PjgQz#jpLI4i@uJzgf! z;l%d{`qpc74kTtb{{_i)=+)#FJYs-hqQ4VI{GT^N3GOd8GVjJgR67L^-+|HO4(bgt3c4UhC zinpAAIS-5RUliS6lsoJBNbFVrzBlh%Q}g*0pF)cvIo_T)Accs{X3v<02vg)Q*cm%Y%F6N_`dW{ zLl>!jzZmEq1!;>_p6QWmP31Ug03C?*!q?D?E3wREK5z-h1N$v{J!PfUpKZj=uMm0{ z91&*FenNZwP@6{U9itU^#p_&7J3#s1x(BgRaZ|DQWDLppPe--B6)q6c&kJaa$$2gk zHG8=LqVKitLSp`5ECnyL4pDs*D7~C3s)s4>j?~VB6ZpkOVlrH}vDA){t|o*@yS6GO z(tQk_)vA3^b!_YUdk-h|KkxDI8|bht)kzjvcyTR(B~m;{LbEZ4O>ZVmXFWP1aub>0 z@lz#QDrfgEC{}1ZrzeG9+3y2Qz=4if27n9yG=R%8fQx;Y)m4e6Dn`;`i@EML*^Bgk zBd_@BUZvRT%+R_m9t;tepk1w7x2iP}G~z^xdy;~!)mupFK@duu2K|ftw?<8*=|2y2 zjuHC0#*HH~TI-CIuJfA@>8un~hOM)qhH!}Zc%3^>Y*T#du9X^76qZauV%X&o3;uZK z@p^_{&W8K$Kd8llkOx?Wp!;4-S@d0{X=N+fih084PdRQGdCueiGDHYKD)y37Zrr@G z;u-23^wwlJ3ZaWQms)R<`0OUxS@BFZJ(Zd9{_`v=nIJ>py7y}0r^#Q@dBHPcUPcUA zZlKm7*!S$(5dROjo~ec>-bILPCGWu6?*JL@n`)^sH$U7lcIqr*8(g{qIpI~>fT95CvNU z&Sj#|Zj$WnZ#(Xt*G(T9Y=E*Q5T>-syjl`9q(F1@2XD)c-AE~xLk|~dcn-p-a1iGB zt4;R(*X1=8P2f{R> z$IqOo-Yb&CC@GY-u(Imtl)87?%xI8pMob|XMX1bI`p?VhR1}qQz;TDpb{65Lf6>&w zZBYF@99GUNUvB+dhI3?Kyf~=mDL}fxtg<0t%F$|^Fm*u3I2vBc?UUl86uLjy7o-{ zm1$^pv&H8mZ%m&nO)M_kPh1R!#tcC2OFvd+rMcl$(8D#2N5i^ReuE8phGkHvTu|bH zYT?ln1+)(zpKljw>UK?)`Qr!)Ph?#tZ-!Jps z8;GYeSahJ>Kj$|l}d?9X#z(A+W<>eHGoC3Ixt5%VWzyI_hf3TTt7E3U6D0%RHsA}~$5 zI-ZqxiqfPUPbsHPT-hFQjDPrbVZkCh!CcvUR$j zca;CMZfkR_WoFFTna2@0cGuLgt9`F~o78FFq@%~g{r0+ZT|GcK_4Ax{*->wSfZQ*S z3U?1xvh$ijvfTnIFX311hD_AnM2#nsjDHsw^$gDFixF*4x2r4`mCLM8Qc4~kP`y}k zyqB9B2F;9yM{lLxeW25rGqULEc;o272V^OI_IDhRcc)GKgp=m{JZJ0;%bIe2`rTv~ zfO+cp7X;HXR8~4%UqJaMSn!mMMD)v_8B6YGTE^Gh1Z!`3Z05ANan#t+Y|Y20KCd)- zaY0nV3g^5i_ZAy-bZr{ns#5yz5Lib#X7|z3Dj(MdYus8}$Os93Y#qu#;(h~TzXDX< z^gLxZdMAp4J?o0n&vg5ILTO9gkWWNh_q-g3tHR<>!&!q*$K=z?7GG>2yilI)aNp(L z_Eo$+P1Mw*N&Q&xGqd+ABRVC#3X~iYHK!=XJ&d*&aVmq*a@y2ZZHov9r1?XrWbk`w zk7>KxbImPnJQeLja|xot8vnYyS*h^Lt9_j=Z*-|H&aCn8kTIY3_UEH9)gBeos|P7} zcX;Oq`zTNtW0QJ5`SDJk5?*Iie2+y&Dx@EjI40xP?to)O-xm|$u<{XpNvkGx2OCO9 z?c}sOB7pYb$TDVGxL;>?1RNJ-6A)pmyb8kHGdYwv+C4SuThVJU%}lXK)_VLgs+PGiZq+M- zVJ5BPi)EDHhu=<}Ghz`1go}=cIL#);E9cu{AuqJ`Go)N{ZY76lo;vMQm%LZ;=n>)Z zzaN7mDak)fwMpl&Z}sh|nD01mh~7)(cIK45vQOM&-$`NR8NZwiCB=TXd|KLlrI5-O zvEygfo|&Clq@|^g(5O1(;8tFaH%5YUC6Jzt_=~>ykROzL(Wd(zJ}_1lzF1~MSXbIU z)i^w4{G0h;k$k(;&IN;zQLCJh)^WQ=Md3@AO%69^YRZ}Bx?fwXk=k4OInJn;s>9>d zXF^L;h+K3({(>VQTR-rJ)A4qXSzYJ>`)CfruajRC!+pZ4P3O#wUk{43Zn;)I7j;u_ zzqg|AyhS@^cE?WjKG!C@oMU$^Zyc2{SFd<(X0V_0W!_0o_qNpbw%y0&%??s>%Gb=? z+iu-YAg~$=Q;KOFcR$ReX~_*x%4xi)K@#9!ZsCk_vpG@ZfD2T;N6XNPtD4@=B00(65jcJNJpcb@=FTPrx(q4jMC5+$042*sBDisE;%Su2Xxr(c;)!H0)F} z-@{Pj!rg`OcX}IhPIZqC>sXERD;$;YZgS#j8Pb_@D@#~eQ5B-xO^MqxU&3+Gl7=)k z0uSP?wIXFF5?WnqH!JN4cDVb#jaMSG|GNIH(3<&3?o$i(H5s`R?*ERCauN>M7KL$3 z2`CiB->K0ypyXXwqUwZ%>Pc=ZIN4(J_QjBn9q)|TLMvh1=H?PWUhN0t5tsY|q&SMX z@Xm5#*lkYQDl1;H;AGL`p;h&aI~#mf_7p|kp?m^;zC`2+v#gdX5))G{9Ur>4nOkb= zH>G7iMc0ChM*04|xvK6rA3ux|tLfH=Wj3kHi9e(}(U7Cn+RG6C2sByog?Ouj>T=Dc zBZ@EoxxVV3r<@@=eTa9)@%HD~M$rIns{5S{Em=jY??RIPAhcdue-SN>z2=2kna8Tb zdh~E4MWUtA!gS)hFy-!gQ;uq?-vHf~Eoyvt029!~fya{UV?m{9qfWFd%p%H}QR5em zP^#~aosz4iyszHs%Vuh_w7K>8i=Me1W)&?Gi}NmLm?WaiVti@|;|ES#DP@}7pKP4r z1c$+^KBq|?6zZLRJU-LV&g_F(J=IH-=5y^w)Mvy(vY(hSNZ8Cg z8KsfApl4GE>l**gg*L;-&PEmiES$q0Pt@#LCj6IQx=B|2@>?t`FFCr*o!mR_qAzk( zesV6Z->bcem4_-9;S)Q{$DMd-wFm`E^D9N~4X5_b&k0jvCS8YgJ^@k}V5F9wLz1o- zPD^!~U{~mu35$iEH9b`@StE{USpa!$FAnGgL z&c9w1mT*+u#C!kk*7Yzm_aSoWuufUR%!rQ02;YS9laT(jEEZDHYk<>~C*R|I9{zAT zFt71^TI5xGqx8WxsblO%D759GpW95#YJ>wNdFzj(L<{${9;{ z-WBnK>3;YlmwIzY&CrfrNjH+YvWsZ6^==1ofn#1PzX?`*?u5^lSmmE^C0sT37%>T$ z?UtmxDd82i{ENcq(+G}AY78~MMtyQ4x}XFm?W*{+Z+or%)Di8MG9kwEcZ^RSuve&Q zjOL~uQGXHJIN^6)EFZgWw7-}%$_eAY>nq*c92%EyCQ%*OD2na(2$^*`z+!ftYH8H3Ut~pxE&^qqjF+5dckm);JSw@7alWJb zQ=X`#c*r%)n7I|B=RT8JgJ%OqEhdJU8!2sv8Hd-?;^vN1#v<5io`cbAdYl?+rgQ!w zfi=bA*wbZ-&*^iF=#U!zDi@cdS81S*NE<{G=`Usd27**LSSCteClBO)nEte6ob;yW z_8F#Y*;nfc^_>4CC8lU5!{Bi}J1pcN5Rr@9U*?(Z+=8}q04Yf8zgNdHOu|oSMC63% zPu>g?Qu?uXc)m-ix}w*^U?&d)Y0+8!c2Crh4*%JGl)H<+y~VqjHlRK^{BA|Tmj>yS z^!)42Sc2P=t;?pLMTgtBQdlEX)VD0k`RzRl*8~2JcHFlygfN~JLM6I$ft6-w4J>-r zlfM)7v4El>c5rnI7p1Mr=xAy@oh=sGvgL|G-xXLetnY|dPzWIIK&gY}5tDi9#bnbgzWSfM|Xlf_kozZo> zTblZBQhz{;j5AoM>N~xTF3+qy0qzFOZ0)Kb4V38^ubgRApVM=~A(DUPaiHTO6Q@N{ znDl6H+)V!o=mN$5$4YtYEZ@am%RpvwS`q(Hb#6#*g1r>^_$!Rn0`~{N=|n=_=@QQt;P5&^J06n=ytX1$dANAAH^~`Ffcysuz zNfBf0`fvxok&&}!*n*z7&ywAzk~5Y#pu@;0ihrv{DGa##eNp{^o;DPz`kFDDD1T=& z#zQ+)5r6Bg9BNB88%$bAu4Fpu#uifh-WS@>wvp@g=6=9rTtiGfs!6mwxgLTu>$2Jr z@sPu@3i<6!P;;sq2EFl_@%r_^y{D)9_UR37qO5^%0JkmVIu7j!ym-kpJ?)0`_T2ZP z`B=!bLIGtyud?Tk{fiE4s&HWL!mVS?kHYQcKhfsz)QBL8rH%YRu0V4qv{}+)5MkAhyk_>85)*7y*a5j0o{w_%#tyPYMq*Oa&vA@L%q9qRkA(t%A;DT@`5138>Xr8 zFt~Tf_C#d|^njIO=Sk6C*Rx}HLH-dg1lI|WXx3nunYP9YorXKOZqmz z!7SjGJy-cgJv)G|Bvz)Cm{8NI>U{ziy7-_0>mR@f$-S9|RJRrO8rdTPB>$ev8Aio2 z+<`jwZu{UWQtMNadu>glV}@jVmUKzKy(e7HPjDlVSom#XF*s01Dq80*Y=4^po_+jm zvGB!)f%cIUsCbjDNB0hQs+-ohJ%`C7CscnirC5O_x+%8_NqS?Jj{?`S7vF%x;yjHM zQa-l-uNNR?&}Vmc$|YUJ^@*UoSXI$*IavJrYB>j?`-M#{&<1luYC<} z5=^>;w;%_}f#q(#H!f(!MR? zczs@4zt75Zb~xy1>W_)wlAb}0Sk=-KBhAp|7p$e4zeobM(Yv6>w3v;(Dn8AuR$Y$9 zu=CZOcd%=V+i@)U@cH8y_9eR@ouTU~>*5QMjpE`Xl|L%$@QP*F+5Q*fP81QFTAuSy zM|aOH!zrH{p*``@ZRMwlJ>R*YD=`T|TvP`}dAeUlWvaqMoL|xXd(Y7D0oqH~{lGjY zCplwDiHs%wdNd68D@6M|{5CnlWD50G9J-2xpPwE!P?=_i$tLWA;L*XY#9EUg1Gdnv z!fDkZWP;+Ou`Uni7TFLKP>cPy>;X9I)U+x&@KYP~8NlY;A92J%8Qs}Mb-?6<)dpK( zDh1-a0rDuv0Vn@+jj<=Pjq}{fJyyWdRM|MW%Jhu-|!7Ww|9DbqlGv$ z1Hi4&_BRaV5cAuU@5+mN8$AxgHBoq{BQToR>Z+biCO3ndJKbCuYE42V)=dXMfv#2` z;4Zk$n5iok6DBvmcNS|y3vR}eY#uWtGW28RtkBdu-HEh>jFbdMM8m#=B&3rZOV>xa zC3qR!Wc^r-;a1a%X_4!>OyrB&7RvftXKrMx@xpm1jIRv^*E1czulo)94?}Hjsub>S z0DOm|0ET7L313B@PK!wF zYI;n|WayKHtX{yL%rOQM^|k`s6jP_i;MP-`*ZTMyFt=`a?&AypvCh_e=+eu-*kV(9 zKDA4s=QXR6*D3nZaBiG((@}1~Km`tuzVWQs3HZ!{VkL}h^5h2?MWW!|^R0cG(^Q#J ziW#_Uy^Rk>JpLxY{ckxT)`c74s;2QfrZD?j1!lk<{ZykD*^fv8&9K3%?YHX8-lU3b zAh$SoVp25r-`Nc}#DUbiW2wK#fDU2EAdh)eQO{(+opd$D{6iA(pF%=#VHxn6-|WWG z@hA{*csmqJ*}eg*_vRAqo3KeD)yRI<--ZYu+&JyO(I2*%>2rmHXy`2dXoX&il9x>gIp_g7R`kuA{?Iwj}^v_J^Ho0)xR7s)6OXBHqy6s&E4 zn>q!s6`nc{uqyfsJn%snuz#dU2rM|T`P=Ni0Ss;{-#b03EEHblnI$m8^ayMP7Oq{) z)Bk&FS~KGSBKh(0`$G#%*1dcnUe@)@9R8x-#-;tRmPEW3*H&IQ``S9kvy&und>Srs z|I~55s#}8(EqKxexoVVK?=Tz{3jq}&)mZ+YB+nOP7iq1_jk9??fC>3#wl)yWN? zgGV3rOw|QVXgl75Wh5SNCA~~PFdl8xkaw;0&)Er$A}OOTAh}nYJBRN4ge=h?lS!5m z^DYqVZ?&36Z=V^S9Ox;QLT?|z_4KS(EewYedp;HS`kWN_#E3LR@IqQ(03U#_Tl-}` zrnk>3AHyb1*1jujXCkF&XDB%pcWk|G=MN3>&oLV#m_bxe-@u}p(w8DYr`?p}&JA-NZPc_cHTk~?P&vuGl) z_l`^(uZXuF@>+Rr1)(v%-7uUAf2EE6+)u}R+F0v&TCcZElLvhL_}^F~(^5`41X-p| zIE#`?PyHPFy&LYsrN=ShBJVXxl0s zb(St;YDmzM8+S?_gQk}pRrs>v9!Pim^mN}M84fAO0O(K`fUtwR?G;l)D0q{`PuQ>9 zIKXG!@n`FXTF2prRq#ty#M-Nvh=wqP2G;!w+c=tWQCMCf{A1Wx{3ON^#XXR|So=wh z+?aWVp>ERSNd;VWUqYBSJ4GgF(_QA-xB1d=oAYC=U++K=q__R&hlrFgX+p&J6_+t! zm_nWH{|RgSYYaEfyRV2FS45@qmTEJLWR~2h>UaoK26SR#hT^E`xhBBr(g6_JPx#hn zyz&vHvZreHF&VG+D(cJ@%fc8Dk?`f0qqmXCf8v^l-E2fpg1~V3)bXOWmnO6Pilaci z?#J-y4!$KCZ@d#1SB}q|`}XWF;9!$vUtz{$^5@P89^w3rE>H&uFeIE0#ft$EufxO> zk&wLFdtYGI1&a8azK)J(q3kHp3A=QC6dM$)SN7ET9RR5aGa??rYWVgp-HER%d2B2| zPJ>?9=ZuhqgG$KyQUx%(O}t(3RJZkm)RS-si`Ybe<5}Z`K1+5H)bVmm|0EC#;~7ZD zRu{`ADR!h6ZT|yRI3gN=K~+Qg52*Hi*htiZbYRxcyKsfeXzO_Nso(uFZ?-c?dLM2~ z^Ua&HRz>LTZmc-h@~+miM!_)PZ%FlGSwB2KQhVWe)OS4_-+U(3`gygwiqm|^n5GdB(`4(xZmeMSeO?&uw?WZK%J zGN@??MZsB}g$wxW>l3Zx{|{SV9#3`l|Nlm+X)}hj*cxWgO3IdNX(CgTtt1taLRmxh z;x#hB@uXw}!#85{ZX2TYqGVz)3jVQYceyAvJMm|8`e z{f3#bwZegD!AEO`RVRpg6+Esok$9sf!vQ5!bC&R6a@mC{oR5U`eLrmnyr1UL*!>I~v{#nxc2}!MkF&e_7IYeV<%dqX?FZ4U8s4D<5 zMW3T{&nEjrC|!MQhfvycaSf||U?RtWskyycrb{B%QyP4S`{Gp-z)|r&VPMSC!zNcx z^mSbb|{Q3&9FT%k||#nit}? zrtoK`*|=?mj@J_y8T2Kwvy#iG)20=jXD3_YA!`Z+2t#cjM{nTRBfudJkS&*ms{ta( zykfg6zDNk)y}0tug%W=~CD)C;cOm1Y2)%gv-dG$_g@cqkxomfxC;>Xj<#Ar-a~8_k zKz|fZu!RQF?nTI;-Rc_$UM$SYm0Fs==>!rW2d9f0tpx1OT|acvI`3hcO%VmXmhdJ@ z*6z`*6^d{rCv%nGYkj$R^?K0EL3pMfOdB^HyIs{kd4Uf%zOWQe%RTH zHie;V7Hkf1SWdh`js3Y*iVYGLeOr)nOdzlM1jkD`adfk=yT)M-hHnjuq(JNQ?Oth7 zXYYtKB|@f@AY0t8*3Rz-9>(^(Yb8=t`)Et6mIy>CidVy;;e&TC{j!^~P)BU`OEwhR zCluU6{vS{4w$5jkPSk6ZP|<~dDO1#g?%H1a4YQ{r?G|wbAcj{SJ)H=B(!!UHwpD-1 zc%`iQ=9b;T-tnFQFguVhxY^?Yw1FO(({!3B*L%(le#$sx4YoA>vFEey7 z$uEG5aqgnBXV727h|CpPp;)-Dx;H^>y$?l65u@`4#J~n->A^(pR8=V_m;}&-^ewH{ zL5exJJ$1i_QkNv)@5j@ep#T7Y>8Bx`2A(|s)viKGU*A+nA-jv4zh z1PjL8Ms})8dDc5$ONtw zOc$80zxD0jw}G{LD{7r{Bg+Dc;WG$a@i6G7HT$5{Fb`#5N#kq=;Ff{eDfuRv%Rzc8 zc-G(GLP`BUl{yO((oOI(a1$l&E?H_rE6NR?ifX}exXmiY|gD!hx%Jm8KLcP(VGsVYm zD;Zt7v2dL&(NxHqs9X0i`@~xLVE`OFCpDxOXKKQr&!EM+R&1~Rg8k6MhtjW& z0C02qVAxX7h2K_J`DV{w#N-Cx6W>)K9wbS}aOL!k>m}7OBoqaQ>sAIojpn2ub(4o) zxSasL#?6O79p#D5OG|jzEzd3WmZ(f$7tq3|+gy*>$wGtMckbM{hZ64RhMQO%5Fku~ z@a{dOu>D>Kz4I1;V$1jNPh(Z-3-JWYH1{LXVBH{icZC$sj$aYkZ*_h51Xs;`M8vS> zkhf0O&dv_g4Xj0A_DlY0tk{Kv8*%oGdHpz)*tuunerNaVBQYrgP~ zUgC=92E4eJdBdPH)NeDtQ^LbPhh(Hn@*Lj%NTJ+|AjaS@T&6j~d(guj0D+3GiWcN1(6l}Xxpx0i_CTC{;yY{_1VLfyfyXsrnUOx6KPSu-dX3}5-)5P zO~|fVkAS+m*ZapOBT~{uUY{0ooIo3DpbbwF&zj-60YzXJ%den(nhq*nhPy= zu0gM*qTwp&m_~!|oyC2Do`t!f-XFwb7O1@8!QXl#VUT_*`c58dpIA{Nzv6@R6)~#t zG1UMQJ1x_Z5}wBvwDc9g@3sG$>m9YvU$rH2_mav2IxV3t++Gxa_~E~qa2OYJT{a_Q z_43E=Umg0w(c)Y4$s99HIW{hBRN}HR_IlExJ4-aRr)m8HwpTRKoc5nqds&}d&jaYt zYPvH&_~7XlK1uJENC{q}9Tk~BY#8_F?Few zcKDAxe{}Yd6f#(jkXv6+vmmnvIHW(U@f!s<`zI1aRw&xOKb~alWJ%Os07z2)Mz8Vd zpWb}h7WdnJ(@33MhvR1#!3L*=HeXJU-$rG3$rqACXw2E;rl&b`O5}+VD(T=~rClL< z3iH`*o*^TTG6LfdVB383eGfpqesC_UzM$nAWcp*RS@wlAEGHmlu(L9 z-D>_zqEKV0F(rcdV{CZM^@x|q2y*_$)>b!{r;rYnMXN?rwrnyg|2x{vT>|QW)?Wls zB!;#74$Io!k-uf9qS6Vq^l#u0=Y`<$hqs1gdJj1XE5aP4?c;y`mpYJyp1U%h7zE65 zjoJL(4@Sqkk377Xla!W-oHMkNVO=LgW%TAl?dRJEQVdo>9xtpXo_Ff8)u)^v$||IO z!S+W|`fF96F6E+Ff6|Xv!3i4-zv1HVCW)_-^l?z=&FU9GUxkK-m5=Y#S8aROl?Cx{ z^zy%y+ap5Uh4JtVK%;4H^#@V7Y?Pfau19QxnyCR!_i34)xPGqup^}Sj_VRKnc1b>2HVX` z{7v1cB(9!+;A_HJFqqiEi`4{r%bpxwnO)=d_2T192z|^}`FUBG6LP1nPJX8dnesV`I5|fV=^0A}B)F*Egu*o&n*Top zk;|m5O6q~zCa1oxRQAmWL})KfnV$izB@zprZ^8y$rU zE}L~drX~Q)zFoob54!AZur{JeW$oUeWt#jmBl??}(sEE-SWDnx&^?cniCu7qd{X;E zVKeiwVGIu?vy@1r6ihq2kY1#x2TcU)!7)bpwwAhx_$FweHwZ>n-km&JJQ?NR66l|E z$CEr$7@wI}mfbQL72k=6_R$Yrp9>w;p_MqCmspjL<9zENwbE7b?;q)3>KJC!-}{;k z8pg7E)4LNHkQ1P;eZ)~}(Fo%mQ5s~a?II7bu7WAFHMP9-7RM7DzrP^ncOzxN`^)nR zL-K*J#bj*E_TolwxZ%N#V1@k|4pC{4`Ynp}b_u-^&c_Z$uV0=d1fvX)77d%s=-kV) zQ+4oy<1|yNgP$%NOD91-xEKB;tV`y3pDsj)7J9!!vm(FtFaYijoS3h*mAI-F6a94X zI{5l|_u{$;|K4*nWHk4i@jcb^e4VZaK1MR|;NQ!;XL{+BGa_7An%T0pFlc@#Rb&+SlCjazcWl z^l4}2BdH{n`ds!r@(r=~-v1gYDGEveV(1giwS6rRAmJJPql3pfuc18;Jh*?idU}yP z1=EjgreUA^4#Dc~P1Pg=s5tn1I!BVC_@Lfx>x>DS!!;2|RTWYjdeBG6;gYS=41nGDs*y-*V?$WCAxK4I%cJvzuTTbSXLS~~ zUw$E}eS$fz-oP!j9P`ubVf zvOpLj{)aASpJU}eQ^CW*1wCm6e{nH&Fxpq$_ooFUEG&KUgvI>wkF(Q9Hd8YHjI4=$ zezWUy=6`g3O=myz&yM~)2I?cA!d^q(E{ko7RPb@wo^l0JN#gaZuUq3B?i!URpIhae zLShOAR%+Z%c~Z9=odev}UV5J#c==%?W#LFLgIxpvPSZ}fD{(KN0YmfojwFw+VsbK5 zcxP@~*~R=O;Ulzf8aTw+);Dg3cM3UCqHT)9 zdy{(hZNg0+98Z=6@e_m^sc#81MH!-j1TdUA92TG1*pfVqV8*2uKc(eWk^z1mpoc$6 z3L=eC;L%Sv;X){bpU4X?4~GeE`?h$72)wRaEoL~iJ2Ji1AIyg)h2ddB3R~zPbyMPm zu_?HS-5&MHvl&V%+5^*idbOZr@m0Z3^(H|GhY^}3R1>D#cBJwk+4c@8yU1m#Vup;m z{Ti`7BSFO|;JwtcG{rF|=RNi?C!tbGdZe(0T2O#8K{n?w0WoV(K2;NGCd{3YM3YSX@?t?IJ)14lmak-5GAb#KAS zwj7v_pZywS&x=_>blkeG%gg*O4V~&QK`!zQ$g;15bkduA2MrpP4giJAgV~9P9sh)j zQ8L8K&ssT$#vSEXG-Y1F(Q@gSGsQAZoM;m>R91cUb$q69T#WhC#Hq+}d4sD^d!HY6 z+H)4o01<4d@xrb;{>P_lr?gmCIKfJciu3zYyXw5L+!Da zh4K*%I@VDcquNp#d(P4{(xxTT<9MUow*Xl60LeLfu>63*->@V|60UFY<1|?+1o1<~ zy|zW!S@w;bpNnYP4MPYr=XUs03UizEcZMr_Y6rhawtn(6!eyFyFr2ctq<&96UF<(6)0oI&Jguw*(7 z*~^^N9$?_N4grFX)cVBM0Tb-v5Q&aT9P%-Lz+)hGBTYxtE_kfxam+q$FfD0HCip^0 zWvT4^@E9Cp^3avmmO&u#*hX@UBU{9@Mcm^v|GbL;2@LbGZ(4Bqd*3iV8FwWY`IS?# z2oMHa>+#KFJ~er4k_;6t}a$X@0W z2-VL)!S$z=j1P`sH9Q_ljBGBJX-{BfeVf}J=Svcg_VG{!Bq%?4>;{B?>-Hy#87ay6 z#NitPx4zy~k6V=J_;l_u56O-~TQlmzK%xE~#c-tGkyHFke%mjlW6=Z5=~kZZxS&FH z$)B|DNpmNnY=AmnI_@M96=cxG17n zfjWo(T!!qDnKaFOX>#iQvrUqVY;*$352VAt?T*em2AdM{DoJx?42==9ifR(HqaHGF zbc6k)JJu&!tnLXkz4NqfWUmO*B}&vo$;Gn1#egBx3c5N*YXn_SlEcPlKZV9Gpi06R z+!`lrHX-;-0PyfOvPDcC6cRH3l=v1T+c$3kYmZH7kzVnkBFRP8-IGHJ13J`hB=g5F zIGue^oI-J9wA&y-W=-N4Vy;8_;nbVdjzs~f|4v3olj3FmwE5bVgKnd4mhby7LTe4F z=<%*waL8d_=N;g3T~V9jQ}tz((Vt`&e>Mq|b09{KP-b29Z%Q;dSKKA!Tsbq^b4XI! zcg&oZwE>P^y;F_BCY)2t7P%@_PK@>MtgGN+W)VG_-SEvhckKR;f+wFY>MC+BzP?|E z3MqzU(GoK>kh*bMoJbYgG5s~?payY7v1H)r3KdUPdyLp5{h3;#XZ`WBOeHB)5=Kn) zZtIVHNK|5!|8UsOc%k9&Kxa^?CKY0UDCA#y^{2gL{weXQtFA_BIK}=KjuWP2Z2Igp zd^#};_~YuLAe%#v$e!~ydt#xE{HBm1koL$NY4uL;}pH!i)u-s801xteqH)^30B;!bdl zz`kSKSN-eMihaeRQ4yinFMdrU<$69>miK>%^mw&L-J;V$BlvifZ`2QslNt4p0Yj&y z9`^3}adD5e;FG4xzDqO03s@W0)mE;!*y$hmz+2N$EWe^|>3$4PB2G-J(XAzQ@+I>x z97@oRH1Be{kKqR)MV-HN9Fx}g(%klF!Ijy>w*%U_c5Fp0L|<&l`k=EuC(+}N(eIFoUq=>-t(_`UEf?VMu~YJwB5YAbSQ8dX=I z-!sTwF3GWU-0(q@Gf3`j+9@7}f*)UPS&(c?QaLcJD{qE^d{@NsoYZUwHdkda9)P&>{@vN6iP`kue8 zjW#92FC5QW$=9YRC)U?A#-*8M?`YNfrvKfaeA?lL<>G5+V zm)B$7(UuNN!8huHOCbF+I?;43E35oR6dYQIG_9PJp6TPFPawA9p8u`wnlhC|zi?*G z_f^hfY6iJd^P-v`qFa>o1~som>s=Cw(T-OZ<<{KAm|$_czCYPnI-Rs8!Aj&`};&AwlR8?CpZLjQ=2x36!Eh2V`d1L1<8X+R~I*c&`?hCNYK(Sx%l-b}8 z-6N|5TY`RGBy*mIc$3I<1Q;i%`j7um^`x-{zGO~}P|vk(F`4osycquUKUA%xD{AlK z{@338$q|WG1=k!&Dx_rh#*VQKTSE4)S|rGJk8E4I1gzl-Q4eLG&4GfDvj$Dhj0x$i zqqYyP&EMU3^m>yhUpnXSbyNrvO1#P^6E{v8e9W+_Wy{e(fddAq zb;k2ERDEp0rJJwLh}<3gyzt7X`PdtupMgy&(nrqSt$Hx7c62n*;XO4-N{9+wJtMV5 z`kLlZ+K7&B%HMhBW4Oh976VP9vW8A*DDCFDa&jzHWlD=&WbD$Z9l~SpYg+}x^Q5^8 z2Z*Ira7=NUQ(Rm1yBbR-F3rC)#lI#FdA;CCjOrk9-I=1{ye+<}7rNTiD66M?E1J8; zHn^^2tyH=<)%uzyYv1#LR!0Yo}6Q<8W>~vu)}Oi!44Q)q~c*JKDM^2B?xf%yUw_{MCR_`c}R2MP}WtLtxQTKWY+gWA+}kS=R%-iD zj)TEP8K&Q8s>1NFDS^Un1y1;tr0{z1CeiMkuF{}8i>NVDEz+*@g%I`K??nBSns zLe!MT*U{&%ms3`tX)oQ3(D9{&rVI9c(TABcgFrM!3n|@mk_}V4f!(`HcW`7ZYgR3z zc7O1;=oA>_^bfdnmcH?I42357uDN{bK}%Vmb74h&X{T=i+}zj6N7n00CkB0u zf)TE3`Bz<4ML@{2zr=`M;z^^}r9~c1uLb~C=I}!$d2ts7YLRb7Usq0Fn#W=4)+OBN zt)fxs#67=lcRqA@)#?7vk07g@w@kSDKTnaAs~*V05Wp+<3-)6VucC7o1}H|bN3XRg zrN{6j3zFY|Cnl|D`pgay$2rm-cg+@qs)Ptq3RPFhbePqE$?XNd@Bff>1;EB{hITh-x_BiDX^yMy0d_x24GEz(E ztre?mN{uButp64(beW#+T`j@G`YZb4=A69BdrVA$8*jPqcNaW}WW1Mug8oxrv-gL9 zxBXgY#I)_V9p=)!Y|1xt#(kcN@u)|ZDCdMmh84HwK}c?~+Wrq;mD{_(u9r;{$;I3Y zZmXHa(33Cp079m{xwL6IX-&2qX#UJC3DlZc+#=Bq~70q2k7Hc!&W7+ zK1Ioks~ObHo1$MbPKenHtMkxyYeKeK{Swyiq22lQl))mPSlAKZXYV_Va*}^F%gcO< zYR?Dve5+F=3zKsF#O=G?bz_rpB~=NPPZ~wjn0FawUmDIH130n>fsS*OFDo|^co-8h z&sz2B_(sag*)J4AT+eYEcYFQP1zA=p^cCm;_tYy*EAI2i%$%J%(S~EV5?=tPlc=Tq z&Rh0^i`j1M__EG#y#f(mi3_Cu;WGcwk{gOGu=W_|S7aJnnHq#e82Z+Kih1{LSz$92 z`@%D0GsVjduI^T--gRcP+G5RJ4GR~vJ8eLUw6`Q@(}5pZCi**;*Mr#GYvK27cWVg( zcdmckSZ-CG*19J4vw;Bb~y%Payl3`OIhh2N!;msM% zpZ^xLQ6DW-3xv4}7n9gzML5AjN%uCb=Ac@hfW1y1e(>kZ^ItB#hP>GB_t0pIhH73p zW2wvwNEYF01uV{c9V=uJ!W95T1gD@-9f z;}C_&zI)*4U37IopQlqIP>+$w05A+-S2j5-t@<(W@O_Tcp5Xk=T!WL~ErUMRHU2ZZ zv?{(V6GWAnz6z}hcafi>s;%$e%4z}youVlyuWY#lB`S zUBkY`v;G1M-b_#>pY6M$N* zCEXeV{d>1-6|5MNGelT*g(cbYAGRLD8~(IbroZF59@?2}(eC|fh^dpFJj~GK@9Y>w zO!%rktiFrjzQ|(nG$vb(uAw;#3;;`F_+u3wIsC{f$n!gKRwLezsQyDE$yN^z!1$raam;!8^E$OgvzK0qgdrMj>zp6SVr9@7| zY}@~6XDZ(okJFdAsrJyRJBX8NoJPbp3M?Lpg8%Cov-a(33DHQ_C> z%NjnVqz(?bpJo#`#81#Xmd zdF9VmJ|G+6i$wL&7=J>7zwEK9Q)HW(LqL<5W*SZW=0ItDX99>ew34Vlcy-oQ3o~Giq4cujQFKhMJoRQ4yei>qr)F@nC4bgW$ZUh z$pCz4l$FL-t{7@f8ZhZFambEIIpNMj^UrWmbCpD1mhC%aElVyFh#@r+=AM#%k_0iu zs9TL7RkViQt>|_`~P5x#iw`J?uJ-*>FR|ikoAcrR5iz9SYR>eJ51`$ zl1&wF^A|Z|8$Z(9*pRqe!S(eOL-t)fK$4A;MQFO@Co&l#h^$*hyEnSN`DRj4LUirr z6B=i|#L`*~KvUR{3MolGA_>{Lg<@VHZa5QDRiB2187Z-}fWbIaU`YgxB^yW@bzui> z^foWC`G=o;q5TLx*;iC)XjX@vUj<5AIRD#6V{AJI)Jy$ptFQ)#Kom?D;-I4~P7@j) zo||skItJv7-B#H^X_i4KLAeK}_WfJy#79t>ceq;QD~!m46!SVkl8_xlsiYMu$2oSU z$**|ZYiC-EGiG$i@RH+BHJ#WwCzn=`oiOWP6Tx)roE2(X2&Z7zkFFm-5dVQ@G@kpR z&%j}kK5`K^=lY57S75gu@wWADMfNZDz`(}!g!y5z`pR}3y(>i(HYek_VX}RCi7oYW znHO?xiWv~0^7RQu2=j$4CI=ojppB8f9nX;c5283|^ffS5L>J{-A@1=$TpCm5pDN5^G(K-o)Qm`!e=V%G{uZd>}7nW&#Wv=+VkC+Qsg%XX; z(R_TC^%04mwyRzfm`$g&H-JilJ*muc8k@ zAd=k1!CbiAeP-|2Jf~5ZSz!E#{U8%&^?DwPaf7gCPocOpMsRl4{W%n#LN_~+r}?Y2 zksM3&CEqLLR|Xy#rSSK2ekZBsSOwPi!flM2MC*0H`G~7$%uTpzj`Wcci&Z#aCvJVr zw1QGZES3lwje(OFreWn0(~c}p^|{-BP2avo7rA|3lmEJXN;V165(gyCOHAbXU%Gr7 zWgjm=G3}+Ps#y=rzimXju{mIjQ68DScR%Xlod}Z6nCJ0t7SVyYLbe`OZV<@7=ZazR z&V9JrSvrhU|G$EnN^-gn9qv}c2+jXyiK~RB)q$MrEU?E&qR^txQW3uMKQH8axc)C z_@ywB9=E^YinnBavERq8Mua7?2nx?zi*$(Yehcu zlsHPh-@TTW{Z`IZ+ngIso#29mQiMh>_$mjT5cj?_w++AgIkI=5Otyj^Ev_*V&SJfe2ebi|C=kMw#)2_y_nn->>p=~Ap>dpJ9u zqAzS(Kk8!0YOi;2)P{MNs;c6@j0z#pkcs;ylg%q>By1n0*)8yrzIzsN6=*hq;p!y~ zXYAcaQv~JdxSqJvP*e{eIklUBEkyf2P6YB(gHL+`{jVhPw?x}*oJ&byEje`fzxcjE zYL%19*_?YAmC=pgC}jBDW=vWPFCi~e=KG07baiF+2h>B8yuQkNwIu5B-{Q6~*W{6v zuOH|huIB^vCmtEOwoHUN(>o`hu`mbScNYv~4|7wlWS5m!Xy;o!xGz~<$^X84TK&sS z$K5~1-QRYj|IRX9SKBP;F{I$?2NQ`XD1*C=?YzXicDh)7&joOE{exDl!0O@?x__Li zLWO;xXV}9ZD8Wj=*K=u~UUBy|Yg#>{Otgfn821{9{YH-#z=0cP0Ic zLS}Q~{{t6GhWvS<{`!A{t0lh6IjZ9B-oUZf6$A5VG*~p^ydd)Lj9OkH}hH1X5z_hD!|6(p$B_(}QuXRaa< zAdkNqjMON)MwS`6HDc#!RWvJyPBtfpsfr%V_l5rpLqA}oP=mh_^m!wj6>N@aWLOp_ zD^z zXEsDOIV(ON@tF@8S&)sUG4@DgM=|bu`^D0lDP`aue4}z2o@rGSJSvmZH9~2`Hr3tt z%;`~@tEwLG$7J&->}1bSg>l5w&9PJ-OIM$UGnp*bhE3I5+6oZNqQZFaBNoxv_q2Jw za@*B8!A7xbYk0%-%~n`Y7D2?T==DVo_I|MPyCBafp54%= ze79DPl*C{qIVc8xj5+Q&P`;R|B;BkG=7)BB?HnPVT(Vdv>d#kxnnVnYsX{#I<(7(7 zy3TN_xz5Rx!KaR;UaQlZoXdEr-9$wTshT#+KSRu2y>EMrZlZ&D9M2s+l)*ZJPw@bF z!cMK(Vx!gck1#^#Y;t7-IGjk(-C$w`$DHJ3rLAzKpBS@Jx>wmWsdoP3Tpf)CKOkWi zhcr~I_E?OY%J;?OAvr@nN=5}ANd6tZn15!T2n>C^54#L&=3c{A&X*RYi&b0}=Lo3C zWUJ4Lk`vP4xn#}u4>PLoEra8hT1-si4UZeP-fgQ`F%fYMS`Jnr!i*gKmdZC=-7VGxzI6%HSLk;?o|NcMKnX2bLX|ZoA&FPkQpt2oLf$8gHo={N-DHK- z1H>mZwhYkM{42?ldU-O-STf^9_$`{)SbJ#uo87D=2|W0f+~gS2-l7fj#2(U|o8k<3 zqf}(on*nGSbkmb2_`bK3Oaqm(ylDMowjR;*ys0toc{&pw_ zC5ty3bnb9m&*79XHMW5Kkoc(F<&TH7Y1XgF)juE~tln6CW;NV@Jpuky6OL6BN-wC*qD-~!$L$r080 zoDV0h=}IojoY)-gU21zImZhVGwxpOet^g}}kC=2gpSZmaiI7u+cL~5tvQ}xQuI8T> zsPQ9@P*)rks~Db$j>=J*T=WCIqr+EwNbHd;p*QHDNU*=!+sVz3byuixTtEXhIQpb81j zhxrvf%SfC2M(~5Hfda941O+S-35Jv(#i>W-Pi;n{dn|*iP0sA6G1;3?!B5<|Py?}z zXYMoKK|lDDm^7xCgqNtlwB%wA)20^UjCZZp&6$h`!QFxAN1S%zs_1%pRx|G3Z1y|g zebL33Q|GI{kz)QsC_bbOIM}E4Ilrt5ZVarcOl%>pCFlyO1L&Mkq0(tH0tNu1Q)>=d zGp}gw>RL-kpAw>BI@Eks;!q$2+R2^dGfYsjwQn|(AC`e7n-G!CEU6`_6gy29pC(UG z5)zz$JgO@7mkMHRHBqz?7?I*{aaup?^i8O4h@H%-+?5kmsf*fc64|v-X%5=*dHmhx z5gJ?@f*ZEFz5#zl-VzNilTDb7(*!O*C(M{7hz&4K6BciAl2F{OIg0!7^f!vLc+z|| zf9d>D(@Gfi#3^Cn1#CyR_z+BUoV)d|ugYb)hyif)!Ncg(^f~sruRiq`atZ_Wl#}cT zaMvjK3y8v2c%y>DkUWJD3i-39%1gLwW-j2{%mFpsz4;2eXfv~NbExdM@F25b7y|U& ztF~|8WsZZLDK}Ps9-h$yyk`Q*y9KVQK_?U>CZr!A5uX^#TOzFW8f>+iiB$gPm;pay z-1An$X|Y%)5TepVh=Q5<$skph@3yXFc9cIdKu5*lMp3vU0x|mAd6$W#Sz~a(!RQj# zZF$#w4H65Krf*CgfrUl-DKTT*{6g<|*sX`-4>~!$`N1<{(pgI#KUyLmw%SF0In{mu zb2W0RB40=9&e@$~YJf^$jxKRD(YbJi1IQ!T%Yim?NRwv%Q+Fc_*;l8dxlF<9Xy=p4 z|Iua&gOSBzig>pxFv|A|*-Q6n)gVlf9eQ#sfc74aRa@6o@_V!$Ph3b9rqJH0pFsO? zna_Mu7l|A|5xD0u5!*!6EZ%fc0pxdN52Q21mL5G4S^<9k$sRggk2d|%o{8|nQ zqS()%WY_wCj0sy!fXI|b5=p(Cf_yh{U_ap}VbZXHz}LQ!yG5%RpL}&MQZOhBJwgCs zN)RZH()#O(gP-h!UDc<|$#InCF!1je#H%J33zcy}r+=NXR*t}vz58fDd+G+?Xr8Zh z`aKs+iw5uwxq)vyc8=28)4u4-$JW5hB3BP?KG?gic8W{ZNwKP|2AAo3_-3_B8Kpz3wC{1e2i$15F-}cA)`epyojsh#J3QLEmxrvblyUa$s;;7 zB<%s>3GdfbE0{*d&7oyt1*fve zy?o1(BZiV;@q>ZiDTW5*3hl)?eB_Km1CKT&%$!(_C(sx?5S_Rw)zpmn+xJ9*KXy>L zq%%iuZrX^c$JsNtdXvsse(~{QzxO6Mk5@i;|0}Bj2&rk9KWm)YahRWyC4J6H8s?%$ zZ}|kRh~$-UZwot3Kwy!D!$_n5sxk8}^100F|Dt3_q%@#j9o@pU>BK7+zZK5OqGayo zH@)OmDNywZP_>L{`T29#-M@6(&djh+CMG-Ev-j1Y58Nq0Bb9Nu)c#)0f&4! zDtYB47(#|BcrH0{#S9k*cNo_OA(wV(WpoHakon?wuPy%!#x4YNyCLU2tx>$_OrxR_*YAs1?SIu8SW)8Y#$E>uXR{q6BO zXxwI+&ecK4gdi@Ixv=BZ!AA(lckS*&t_|}p2A9F2o6Eh!4EL-jO(~m~k!DllN+Ua} zFRw=?px^bZIxr`L52z)o$2?dwOn-pE#2ohv_ih`J=S7wn;Z{F7+5bhcv}ot0M5AbR z5Ty~fx9UYl&HBSiTr!~%Z!);5qbn8|gzW!gDO3)yiZDM_pE`#fZy-@I^vtq@XzjF9 zR=skIU&6)_L<0Ks@?D)Ka(>Xf+}vj6=$0CzB4qGdbu`1Klw<^E4rZO84ev&EwA2mki(ryK$dvr1c7AEg;|2o{_1@?nHqS9T~ z1`C?_`Q&9}_T=2C4vNUnK|=-rRHgu~RksM2OO`F)6rE4l$g%skY`77XFpl!!5;D!Z z7FaltlOBh(J%~Tugp2EW4gLK&HA~lowvd& zLy5cQVYYl4oL_n6J1vlI3Qc_vG<8C_=^YLHOkOyVnI$P0AD2A-PB=a^GCrCXru3znQ(Ni8Ox;wujK zg@*2g_U4~${;LCcPP;N5nN#H>pT|y1S=WZIWc|_;*xWO8$L5c1NLG)qc1&%$nz;(! z82_v+(rplCqeBUi;>TOvzYcs^cej^^OVFC=!V;}ND00b!2eLCZ{sBZUoH~?X#WV0N z*km9E%D)224oQ#>N%pU|hpM6?P?S6bVtU4%RBa(TLP&JSm zqtj5hn9e~MH^{i*#c$A@(i!?>{WgrY1n=DNX>t3}MBdRMDgav6oPIH}g6X2B>ie-v z{3lwdJ8#&_P4!W1Gbk4WDBlx8u+PO#8SFdAHb0xTsNnGRJf8{m^rGi z*tdn!Moy~J>r2rB2dI!gW`A*IAu*Qq(x&uE()i~S{ulyH?B{6nWo;gLBEK2ZX2cRL z-T6EQQW1x}9wfI6eO{QGyIVonSwG4C(L9zZB7zXv@|0cTi!WzxXv{-CW{Y5Z!3K%BljM+ zrWS~eIXm7lmM^?nBqINk1hFjxn^)V|u0*ZG=Cgdc%s}h>8|i!wcjqCWIFT#Wl!y6S zTDpr#MT#UfMXFE`9<&95gLhv=bq1r_bu~$|U@>T?s8`+V1q<5`BqVgJejGZOe*9oaiu#luxK*`o=m>b+Dvsl%^K-O7D}*pqml1W z?E@F|qjirAJf%3Z<4JW;OEhqbHr(6c&*yYn+x-EB0`qV{&pMO*-+^()T_osiBn;_S z=J|GWxm!a}@!9a*ZMWvRaMEMA!MVl**@HApb@o5b@@@XGe2Pw1uTryHIkNg>`LWS8 z`hPgfs0FHSi!J;l^26RgBUj%LtC4>2Vs|-HFk6$~b5!4f9hhc-7PbY+7FuNOwB%cz1@CfgGFmrXPlA?pruRjM&Cg}vURDe zZdR#oSa8HHt)vKP6?9ghSjv&wf4RgN6+~w~brxYtpr+A1=D6Amwr|*xe$RI|RJjY) z2*OPIhPf}3cy$r;2+`N#s!oHTNBqjgn$KKHi_D7~bb?nKNF}(dTe~kS=4N(eMjdbI zDoOFLjw$A0m&h%r7$o>H_+ycg`>uJz^o zclYuWIw(QN8Mj+4)^%pg@vflIdm?wQV5d z1CGUwTiF>M=wBFjJnz=hq}YKJE+HzQ!+YgWZn&F}@c7Z0tj^o#)>59tOl{w6pHZOh z$jx!ya@jL0CYAvg1ed1s>1FaB_DFjRh~Hb~ROnG;@5#%&J2thpcdhJbN!rvkbs%;2g< ziq2W-L}*#hcGc-_k}c+DhpR@Pt!#etBQM2R2cXIg1h*7L2b+b3BKfOC%^~dce3nUi zlb8FGnwzT6y_+>{WX=rRVdhGRExBbc|wSs&mLQ#&sH4YhMcbU_Bg}sJ0^!`#9ng1zUaa~t{Jd}Uf~@Qx7gGVGNNO@H)}8UN zaLV4Et<)5!G`@5JrR_YU*egyz#*PBeyMm}>;@Y=Z^;X!+CAMZH^9PPR?KR5L-}5_< z!G@;3q%6rn&wfRpn6s%3!c0pPfVK{0+w6e4a31q0>5UqmZ0zjD~iu zr;u}VU}ls*ijWK*S@(OY48P+JK58RdP(|k55oFiOZLZ!{+O3a1O8m*1pg+d~N@*6LB9@6(LBhIxKItC#|CEz;TVQwg-T{TVmcBaI z{7vYX7z;;?CpYx^H2>uVU2*=jf4460aVh{cCV}&Ad$w1{`_-6cvnLlbxwEqUJsV$o z&tC)VlAyOx(C1#9b2QOx6yR{~EM7?Qc2!DFMeiQzg%Xj?C4&|Uy+V13x}$Q{%|pr3 zxJ+(>-P+@?`$e=Omr5RTK>HP%D`<(V-^62(jHgyOe|;mlbn5rGsNnD@o+n@;j?xEX zJ%JQLg=bc(b2EPg=NnQo0o5^2X9is~die{dTuS*Q!FL6T(qeL%@5_1rKg2)E9YE)*IDTNtHXuz` zkj`|oivhaH#3j`RDGRfeZY;e_36|Ke2AaG(Yx##-r7GA&IWA9TD+n}sU0wdc_xa`m zd|{!S3`9VBe#7vpAf#)&FhA1&(sou%qo+ILCw##y>iym*E}`qHtM5|Gn?yt!4|Pr# z$#f)lcZ#x!0TV->g-Qz z__Q{p1Xd-rso3SaQZoOFyTSii?$i zXe~3h!R)e{{yO{hjg&nVV1?|pv)A3Yg}aXWW*tkC1y)}t=w$U)QXJtU)-|~ zP&NKCpQVYUBT-o$v0#&Bn9jHn#To=j`+n)@@~z`l_xlO=hCYR*4sNF?8PfXRz!NOk+lP0Kpj#^k{0IyxNn4sV z4jDv{2j&t%E-bx|l991l?`40pr(WQI;vsya)6lnjG<&>-uTt8B@fml>oF%@1!TtAd z+kL41w*cqQ(U&kEb@4$#(64w-JM!$8kHtl{X`Ia|u4}$QATy%sROdCqjdY5(QH4t2 zj?}DOf{^pu>e^x92=F_X8O7>{(FN$15pe9-7S4+UPQzOKQ;z_G4Z#!X#^Ac=Z@^7o z+y%G*4NSPfpqT?X>(_k|TyEh=hb2;v-W6e5HrV<$^wi!|9rmfSYcM#uW&!hVmKb|< zlI7H?`Vwa#In%x^0N5}T73Evp?wuX`{6uVXcyEU z>F*v@l`Ci-D*7GJn<9X3uQz%;p6T_dopMDJ3WzA*l2jE+yIeGQA}j3<3MOX`#ECj9 zRyr*a=H-$JK(r@Q_{n6kv4@EfJ~6nMK%l^;FXHBxUIoGzzi^gR)LtNJ%*al5U|xRn zwb>~(fX4{|#{f>oxS8*#91+5ko|2&4R5&8=HR50GPcsQ4_m+CYCBy1-k1qLqx+}

SJ*?a9hBJNeIH;OFPd;(P~M}Ih{ zalSkB(|5fUKn)$DI(Rao&Yx)}${V{Y(cdrLpHK4~lDt&SgBTZ=*S<1mwkN^RDY zFz*-MbY8nFsHx`#RoF>{9RvA*9WVbDuWadR2@gdxJC<^tt=FbcU(Ob1yY9MR;B;KF z^JumE2_U&*)j${UdBlK0C^A0GZxNaitswH*%Z-2Y$8Im3c4w3hbT6d>F#Ro%zuSou zW0fAgDQ4u*viz0aTr7X{{wrJrqnBHQD&>we_4%XgwO+m88svwvmvj$5GTIV4+n$RU zTEV|m#lDjJZzgbNC+!XV_+2E!A6c5!c~rLJ^F5tZZM*MOOHCc>Kat5xnUFR=g&px{ z58m{fP}hHqE)%2n_SUUqJ-X4RmcD3^`#Ynj3F#;_Q4*g8vm|Hz^)G_E5J|Y4zz*GL zWtP=>>~NA5&t0g|6uE2?+@@}ox=;3Y!jnGrd-odGQgBkSL#SpN&pE2NhMWGH4C%U5 z=<>*jJmq4L$8bn5+= zDmS&B^xZZPA*oQRlP9?O@zKL^+PU60n${~SmUJFIT;*S3sJN{0?*(%J+e`q~(eSSF zQq=(`i8?!UXDA%46;?5L)9X_>sTgd2Lx+dntucw-vNF?eXFVt&3Mul69Wn~oK~~3V z(ALpK2mU_7QA+B+i6uZkAGv9z6^347qe$F6(AvQ1MSCca?p!{lEpl~(CbC|%eUJdU zJT87dW9UP4Uu|YB5}HrbHXt;I{~+M8 zAu-;=eP=2^i;TI=oBL=hZngi>-azOD3(8M+&MxN(I7+Ju#h!vg6UrSNX(SQ1tG1~` zc**y8uY5D0-Mr`4Xn`G^g`R(Jf~%wX+VW|2&NA)GfjXAd=-{_rKKu_D*io@ve%=}Onf zwHWq$zO7z5bfsJrLwQql|O|ZuqMR~oGtPnISIc9Hu!w)Zm2De z$9={J*8#!R>mmVjEaa!ET!E%1Ty*1p?_q-%_z-PpUISPS?{NY&x+>6lpDtNaZ)>{f zy>0NDq`!9S{FVWOVVJvD60lj~wZv;u!3zKoFT;v(%7YbKvkK?EV_mcAW#BFM$tLC? zA11GjMorNcy1S*RxQ|vYsOH{z3maZ&c7C&OB=nFnkT)?Ai`TjI)707yR=A#wIGe5^ z>RP_>)^r49a-@vs5TqBw;D-K9{taAxrOdIkC~*IRD%{Vl=?3Zawq^IP$GM$8G+eb? z&bh||ycrHGyAh5hFX<3&>B-J;lNoHN_f6;EM=RblE5?lTtJmMxLO%;QQA`j*Ch0Kw z9r=*(fvWpbjj5@bp9nfKl5&uMTPW943^ zi^Mx;h;E?41iW|IC*7a3r;(Y{^a~K35VzMJNWJ4JHoz=kFMDBnjwD+x#`j0iDVe z&)}u;Kl={_@PLw_)a+|Ia;V2ZHn`YX0;DDr1YGVvJ);0Zie3vkM|TW_t_ey&1{p_@ ziOGOtZj?uYg7?50zZPQ1nHNacFf6%BPvoo*XWlet49)3kGrbzDD zx>IOuaYX>SD-Mimf_-TMnaMCqiKhEcG||+t`PBtM2IL!`8zUX1Ld1iZ>W!WPO~q9MP0gZ=!dRiSSc91{ zRz46k-muC(K562q*dXeR(vYT%lnRdsXK|nloctl)fPUnx?bQjdH2HlejT0Q%;@sXq z`zZzRDbGYOw{T-OO3NA0?%9VRbWpGpzK3BJMo$4PZK?;M7Ii8J_c)j0a1UBJm~TlJ z`G!sUHbq8dnMZe_2P-1I#u28RAHbD72eQ@KAYhywYmtB>m>^TYpuGPWVxCER!EU(3 zd=O?*4F216y?2rF$Il8W(C(ep7;0(G4d2RifetCTn%F7``0zITZ6IMke=rzm!EB5> zlg@8#3W*Rsaa}=@P2n?lrsOtp+C63t?hFv0pswoHfGj$HcFzSY=xaoq9Mq}6Zt(q= zkWOJj`uN&uANUZ{S4mb-CcgK}qItsKAo@O!RP#ym-#K>3@7nExdNSdm zKrdSL5TxP=p8@u=ds4r64nJv zo|X&H4EHLn+Ntb{@_l>weW4?kO|&!YWW_Jym4l&LDn-tZ+7wyQ#nlKcMeT(i0|k>z zUJxmaV`WRl?2e)gd-xk%t;Y^;)1mZ_uyN^ z0_kwn!4|7g=2BYsCJQpI#8=`%kKfG~2Rm(wc;q4B3=-qx;D&8N>}j79@G$|1hEhxE zgm8=_O+)DX1r6tp!B_BE<}Z! zzZv3~KA9n207Lw>1DgEX@kvL|4{5*0!NT+`INT+kX8BSz5YLCOaX{Mq{}|%cZ-(H4 zXt*y+rZSy5N}tWDe3MxT(sL8bph08E-mCDsJr{%UvVmlaW(YKM2X_h>g7ENv46zHa zB~t%s=bCWHDs2|Vj&1cU2`3K(7smwbd~zn86YA13+ClCT6-2p4G^Hq+)#)Y+II_gF zcBAdd-_{epDK`!f=T5B?&u0EURg8n0qm-jI$H7?GDE_=lx!1-Ekxjpth7`33n|F`Bk3{1PP1*-CPoa*1}7;@wtzbL6* zskb`EZ(@oC`O205GV$R0KD1)5mii8SV_*N30DO8?V?Vfy&bzM=@7ykcnyfMCe;xqQ z`=O=WGsiH0d(+#AgP!pQ>+UyCME?$so=ZCcLLrKo;R<`nAN!#^3P4n$W#DIuRi9zi zc&)wcE{VIk{&vHRM1ETaBj=47KN?9iH9fk*?#>03j|);hvF?K-e`_hSlD(Xa^)5y_ zM52(2p;;cebsWh;i@TOludO3Y>XEXgoncz(fnfU__Zj1K<+0;6A(*W;PjY-8AQ0Cb zPaT}80kMiAvC{n|!hTDYzWN8WM1{axXGJd;EaeA|I=e;sSo-<4-+W~*H}fB#OAgSRQR^l%6=#wv^n)y#;OP2E571E@L?bQeq>q$@v@K(`PrTu}IP#{W zVN*6AcC!GBbb<23Qt5F}AfP7Nz=?7O#isQqW+yH0CFO(xsi~OLey57LMq@JH2CCdZ zL^Eel6Mp|y6RtfQ;Ovj$&*58Dbe#IXN}`X<6GStS*wMj1)5CrDl75t>*G)~qVWPjW z5+j;Gb#mw$@8jnJ=54Z71?xvz9KmFf0voXs$u98-;FunGRHpNgN&4(hqO%V?az}|6>XM!c6moX=o34=Ql(6PLUZR zY{F$fgoNGZRYf_VgUs`03Z(cATSQ4+c6?kGNj9*$wx#kIi!$IUH{S@3bHz{W&%A;F z2PB*NDFCaC)5Sy+AVz~_ZXH_CG@6nT0sT=SN6E1f(%E7zWm((r=s`%idVeBire9Mp zh*=Edft_vG%72Q3dp{g&;+ptfS||*3wa@5c8iyFF#`##D_v zv`qWlk|L$7Uzz`48rK5?aeqmvFbf2O=J`#QFLXHL<1yNe#jMdh6(5E_H0;SmTmwx} z*Nx$dSYedP!9MYqKgC`mr#r6*%!oKbroWmJF7xMiKP@X#3XEE)r-xrI@umV_e5hmh zS)=>^=cQZnK5M1%6SXe9MsKM$y)sJjUhGHwIo)FHo4O%38`N6=z>y0jbT`6y5OM^_ z$eWx*Oqdoqx>um51zH>)vfl8bKtZG654(%9ZxSNw;Ydp%bm&Bhgvo8`qr(=9O72g5 zrs6dMXBx7$y#+O3zo^Z8p8Q%#D^OHc`UsOv1)9V;0AMmyn`VQDm^SQRd(pS*L+$&HpSWVjY-#mv;&!So%>0fnn-D3b8;) zXn}|^cG#cW19FtHbL@(?kVlEVs3aJ#I7bEZg(aG(pFvqcHGvVE(N=KJ(0Z7t1VWZmY zNwy6r%0c6e;cSm-A!DK^_7w+Ue%*)!mr}WWq4aLtQV6z|j04`J;bQCk(qKI(x&tUM z{)Rmm`Xj$)eF6!+zGSnZMAu@+{l}%AN!~wXVfxXo<^l7B=d5)6v5-Jh#Ru*{k12QM z9^~i;k3dw_5%SVW<#xQQT8l&461yo;FU)1dfnByUFdD7=L!!Sgo|`dPgoVQ3vY!4q zS^H7*BlKd(5)2^saw@d-X`-Hs07R{ly zvbd+R?~WhmV3{2+h!0z!+`%aFYwO4)!^8=XZhUQN>Z|}W-rJ4>4Y)eH(&Y#-p{jT0 zcHq5|$5&L^J3OWri()n*%$3Red^8`5T8CkZ$PfreYGBf89IYI{8zm24Mk|J$)!DH$ zvY$}zwuKdtd98OUg`#_(x6{HbX0_rlAm1zTaj+C0@>0@!>N{DxiP7IQgY#JeaaWC6*>#Rg(p+@Qzj?G^vpHs&U zojE3+f&a{iS%&i7xJnqt88o?(S;tCLvMk^^-4{^sObZk&B*%`OrIaOYKuYQ&%V_QLx%KXWP2QCw!5lf|)1!eHlP zJ*%kQn7XRiW_7z599zi&F#*pE0&xfiy)f8)YMB)TDF%i)P`L?I-jMyOQ^ln#Yl@Vl zJL_P^Y&)Jlh-geV4MAiIl;Ojr4Wd9#$hhMhF0O3JodvH@5vFvNv8%}{Ta7i*s zza+jGJ@13w^!*Db7|MKeaf!+fFF+=BO@i~Q2K}6 zC&}kDImhWdxuBQ}d|~h_Y6wOLAwws}45};$$6XW|a0&tIA>JWE&T$C|p2GMWl*Fg` z`OLX99H&ViF<#^j=m#~hl&)a|CZ`d25ExIhn(;X4_-Wbw_!7VuF5&|hXw-uRYM5B! ziu(a*{vOLUf%O06J(1?sbWUh$4y%5hnd;L)nE?lA@+r)%zj2KdOgG#_hm`j_H~+Jg z_cB2f7nV*0!Sknkj0l>YO-CkOg%U4GX(9(CU&aCs(C7{T^@smn8lf#D(6jB{Xv(Musn3H(eVQED#-5!!vSvdw8oIZrm z9&Dx{R z=CB?XiqTQPcy^*g3y@&{_!1`iLiCwj0lZC-8hL>QNSAujNK_89n9UQj3I z0Wp`#;dM-Q@26JR0ZS#Q=ibmAaI$#t{mp5CENpv;aWQb^>gF=*c;wBK9-WiPZ3n4| zr`8M2-O|k=JII2sPgblg0eM+hFttj7;N21a~DwVAOy(wX=0#JN1Ef3nLuE}F3J{e3J%Aw#ljZ50C2AscTq8UtmrqW@KUO*u!Fq6b<+F{4XUgghN}M)0RNI%AA(d#pDHBb#*Vd< z#nK=%zPyzfT_rx`4MEI=OVGmPAoQP`Y|fyZJK$PfTIc5s@nLe%a~WsLA)}m{zXLqZ zY90|-ggy}cG_ZEn=mPh@$!Ov%IqvNGAEG=E1yBDgjEEc*#5#bEmCwMiYM8+VL2_Kx zK`J8Oa)lj)k!4{dq`w@zdrLSh$Bc972+|3_xND;=1LB-glNA%9*GXvj`pyjp+k8&zB1Iep$=vVj!RFV^z68!kS6<5ik zDA=v!5X4pJ(G1KD>~iUc+1!U^JWK8|p_$>uv~2NDy5j24cO9=9K)SGR$a|;q5Zt8V zDPfCT9ajzE7cAgeLtb<6{nNcDN$lUrQfN*EC*qce6h-2yoY@W%{X4BZbEptkU9g2; z33Ah#ERb!oZIE900{|YdAd(eqJ3-=(Xq>qe;=13=hu&u zt#D23r5K3=a~sT9IF4c2FIyfDW9gqs!4FI`Q=u_@od}oGlzgDn3>!BU(!_;1Mg_lb zAHt;`FwQ_WbV=vjm?F%ysDmyCx|W1N5j}(N&LMBH^Kt^;Y0l}a85*hPk7({gDZWlF z!xwCh{Ih6~p($1S%Dt~2njGOtT$!WpHGCCHP_^gjNgV%*B{XVU#+jRYj1D}4*b5z6 zh7j7tC@}TgAU}vhrSa!DT=UPHdN2^(rLjy`+#-;yAnAmql3aBiOgF<<8D#N))hBV) zvilQs)l-CqqJZaUSnYvgEEqse!rH)1+gCun-C*(Lp2Z?&**$_e9-MLDh#A!%FP#|OE)qVtvUcO z$eyoLnO_A^&IYD}2B^)JntAr;j-d4ZfED2&sVU3U<9YvD0w}m3-=Zt|1IQx-1xPRZ zNhL)Cyb2V7q;AmWf3N_9@0UR6zrs6=?1a>tB@Y(6#3AU%P+JUH;h^!CLR64}mi}h2 zF?-*3fRaS>FW~2kErB?KgTGqx!&fEV(XR2*-fzDK(1)iX`)aP)uPjkOl3DY*-L*G* z3!iIm8|?&P;n64i;zu56(p%)^54$|x`GmP8FNq@OHRxZp0hMx(;qNyXeqwnS+4wD- zMWAd+XLKWNmZ#(U28jkHo+NnoHmwOF(ta!#1o~~*=1ZAdt)h8%d^AgEC5J`7GUaBR z)~An#AVzoB!`spoB~KvzLA7jrE8>v4AXyj!>Io=o4=!@n%J`3xhGshCRE@>iuxAY` z)&L)ZpwFEjzxLh`h}D!~|MvZnA}-hjf7>(LAA)lNI00ZJLXM|1RM;_Hgn`FoL`}p+ zi3SX>XT zHYO`mQInopd1O>SJ*AW(Gg~PPnXjAnr+fwgokiSsk!0K~wcuw%(YPZ5$?G>OMLMsd zs$1&~B}a7?n8=!fXd?9^_-%Qg?U<(|gNM=N@zsFiiFvndteCYC&sb)X$FqM0BHzoA8WXL0q3<44Kury=oZj zM54r&p=`$gOa-onW`pGMhv@(sbhh#xR1oI%0 zFQ&WRma!}DY)d0JQz;7}=N zUsgCoeQ;}#xpgpr+`nK02xr_@A9dzUPem2jTq7XO^MJ!wSQUpJQ3|sVMk7JN;r{{g z{7%dcc7hMMYq`|o6#b}KMdX-=&9OmO9DBwIMeo^-iy7F0LYfW6Eggf2xObY0NloHr zzxxtzRpBEDwS@noQeA1SDUkxULRTumK6cpOYIW-^ zAv%nlnMe~l*x|mb$2Lsd$D$(Ary17R+MMt_z`l=`^BxQ9=^=v870&O=p6MsKgoVJF zsk!9<30smY`KbHb^^Knk0fG{6dB>!F^k|T(7qu3v;x6t)n)2I|L1)j6Rvl9I`@;=T z{TrbQ_Ywz|Fa#>!Zu84w=u)tZsdan8Zpo|VhkG<&fv@NsPY|UakngauiIk*U@@qN_ zk=!1;sCD+?p65KVk7GJ#ixLLxg(V@*2l%e+9+2y3I|>BG;oo+!?8?RkStElPwO=+p zT{Usgeazxe!@5>mKH=$3+-p3q1}c0kww#5EqDaXcTu*0x7Co9iF$Cw|D+>SQryLEj zisbeW)3SnCUN-m zCrT{LN=9tVJW%TDYK(Yp=HSZvtMAh%hD&pv^M|X}ZBzYfz8fM%tQ3f+{uL2FFE_s} z2h4WlgPZnZ-*aR?{?u|>K2H)ryMNe5G(| z^7(U~$OfI0RohnvEaZ@zmn*x6Yho8f!;a$Y^vChVwBGZdCr48$2ItAHz3kPATl5V- zdg`7n9klJ5x-0i6Pilbu&*B~v2QytE#;;^Zr?>THpKAwp>;n%3uXA;G8#Zm*`i1ht zB=$*yzuW+iu#l_xT+}+mITUx3cLLlHT9!I&)DIP8M@E_xwAA-5DQ_j{7r=L(DfkOC zyZszq{0S+`6Cc`=q6f5nBYIcdpO^!qme?(P6T|+ySxQFf2DU{{bGZkYIsOPS89V0}s&&-5 zAcH-w(lB#6B&X4iH>Rq>&D>fDW#D!*Ij`;b42yz$y96nm0IhMiwB(gh`Z2DI$g;X; zH|>K~wVb*Ztv}#`&g|Lw^%f>dt;*SqVWF^>RXyWt13rb~WqJG+6n25S+o_HpJ~5;N zOz!lbY3Z#8aFpF^rq~)nI~jN~WRBGgm%c9TbvxlJnZKeae%;r~`C9m_#xrB$u3TK6 z)R_J3z)zE4fX$M1OCDx!T21iFfXb2J+wQj{EuGFN=t9zRhWJM5EP6i4A#Qd0h5 zqxpg-(!z7Tjh+H=FTUi`Gy*^zh%pA0dl9`)E?woaKHfegyOQT&$5*oR$8)c;8j|_3 z=)_55J1ej8OgrDokRt-ZQ71?a)qS7B^+HcUBeY6~Usn(CH#R`kSa+N9=siTbhy{MS z5jjg3`%O0VomWQZ!WWDY1~hz9T+kdGQ(MNzp`WE;i?g2Y;bG#1ETrMJjbpLu09#cq zs&hz;_~siIh0{5K43+rX zwK~AoLiI3rrF_TFwT30F>-H;7ABP^Qgn9OVVWM>FRWPjU<2daxC0f&YHtmsi-1M(I zw96Ttd8>7w7`zJF8`sV<6rO%}{9XgAJT;NrM@C63c2xOMB(-{U`fqv4eK7f(k8M%Z zWNxa{VCP>o(lgCt3U%;uE#C+mv5NBO0iV%HQ%4I&y09&J&*ho6j>?lXZj5Q=F#O|- z<+W=irT-iLaUpEt!1X#BGew%dQ%b$9CCUFhFHG|H8D!#-H_ncyruX#tx+QOEDLHoD znszj9ORm;*ZJUlhIJD!(7Vlhx>n(*A9yS{9B;mBW5p z)c1$C^QSt)mZG~U7fok#IzF5QF&|o{FQSZ{zvjpU7qc!;Y-QvVB~yzsXsAd z*4^NbaK<3VMboAgW691iXv1*)%9JYTH~oQR034-OKUuMM))Bol?z|%Bm|2t6<(oTF$C3@VF74CbtEEv?-D^5+JDQN*C`c`+ z5tFbKGCvcjtfX?NivRS3K!MN5hVCg?-mk)7lc^ozn!V1U}2Bdp_aZFSM4wID7BqC64Q2p-WGad7|aV zIMvJhwcoqwTi7A~-MgVI%Qmg9`&CNXb!u`m=mq^6u_rZBg4S&84A}<3N84KEo>k0L zma+)XHn(v1x95uvWt6avy6#N<);_6s^RkmZ^}{-T=>k6KgEUS)QIjpMOWnsmK)abE zpfOTM?mP-~Nc?)dHi^ICgml)}qGX_`xHzw(62Xef{q!iB z0`{Q(rpMUsuVo2~^#@eu7a+)DW0v-ypwvwEHkBfjnZ~qjfsVKV*3^Ut!CAh*$(ZXP@`Wr zUay8GdbKPbFj`QKFBv!56UG^v# zm9y|@ZW-O)5AXf>W9_&Mt9MsZv)^K6n%Ku^%hhF_OR(0&o7syMcCK5!2luli#u{gt zElcp&Vejw&H(W69H<#!r(b~&ra-U@eWN!vIn<^Lyh6oy~M2Xw>eT#m4)oh!4v*?G3 zqIN=EwI&ni$YEu3@wRsNHLN-Dxt9g+*OFS;Mk(I}O0oD;KRNc`FXwf+Pwz2atO z^L&+4B8NR;7En8nhl27isp7v^i?&QvJ0H_gsn$=-Z@9j|Qii|UbGa}weh+g~lkoPs zFNQ}*>;s+V3ot04q<#JRB!6>9Xt*3wts6N!lq^I?-&vjb6&NpO z?Df?}y-nR&RaI!(x~7~^Ev9P%Z6U_TJc>R40UJa%0xv0a=Bms4@%X@KRz0p==Y9QhfNv;`Df;-$<+j|)evk{jKi;U`8Y8(n2c`DffsUI}Il#O)u>JTZA=NViD%1h{>{-&S|)~ zXyO4CC~IXgT?RwQdN{)y^#s>y?}bJPQU$NODu~Iuatl(M&?v5Ev^zbt%6|b9QAz}R zy;D9MLR@%@%dXw8lCL_&ASElCb8$a;o~_fJC-A4K>F(t{!|YqrD)({6hyEBX)sN2w z9nljFCxrvUZ0tZx(sIp9%M-a;&|38fo(a<2a>uu8IsnsBB##)~X@*P6w~_j_J|2Bv zzRS$MtIn<4B`pg@@foqt_gq0Aq5a2VV#~mS?5^l?(BGyN?ErSH;l&Li#7e!ai}XGz z0z@~U@T@vACqd_n31&zBAVI3dVURl8_qv{{>l_L6M^E}*O65UcCrysse;2cE>BSD{ z#8T$C;RR{g`Ac7`b>rpN%ztWnsw1Qx8ByK+`uI{%YVcdHjm^S=mG#Rfwv=Tlh4*ww za##LZjC*vw*cA@U2eFf2vQw#aTekKx~e^se1exC4o*!4>3ByR772 z`YV(R&(^5Bxgi>$1wsww&tBKfYsql$su|RC9S@uWRWDd=zPX8r+C@4Ii+tC2CrPCw zN1s&^L5&hX6^*GNUy5zM-0`JiOvw$W4sU|oAgq_};omW4lGRfNypGmh>lq+l2PZFx z#aUK}dYZvpo({DH6a5EEE7bevA zjsj5#xq3%(E|+qO#4!sB5u%};uuG84YQmTX>3hg&`l|M5h;{J5;dhIaen0h@CMdsr ze=D>u--7zp0yr$g=9aq$VsQ-3OW4)&T-`1hrpved??zq=qeyFC6y;=-67>5FJQMu6#^~oj&rA0i=02qXQAi+Y4Fs%wZE+GxDqb3O zkxTacr<;IY;Io>T zv1L4Sg-*942{B?$tbyiuAuYeyZ=6y8r&gKw9p(!ZoZjYwS_YO+GmugdiEs?(7yfZx2Bka!O)Jxk0vz$c^L z%HdS#0G5LF#hjyl=70f{B7MiElV<2WvXnV@Yh+a*r0O5Nj~z9GF46Im=C&CpMx3NS z#ZV$;=uVyRtJ3x(1!D=9?d?=V`i@0lIgDtdYd|DmkWVOHzG4g6|vC&JqonF8( z>F}vu1OTX4`gr<+ShLCg%G75~4QAh9@0t8k&iDf?*|EmbDio9?u^X@5n_U*8%uK7$18SyFN{UuHbF#q(L7p-fHPM=)2=0^H6G&n@&|Zn`n|WnLc%X+4!aj zUxd?IjXW3f9%-MHbzKL_`bMlTW8Lbd?E6Ydm^%f`<5sy|HW5bqKZ!H_+(qv%6Z=;!8GMMVQ{(QhqQ7*_s1DW(s%uzJZuG1<~D}(BvIJr z;A&R(9a9QM(@ZX~XT_E|NsyApjLytx3`*L5aYTQwTA1kD=EY0l9u|*<2!r;|)*1LV z1NFne}=DRLK9a>s++)8pg!VSh}%G@)auM5TEsP}m&TK7^JQdugF(OF?$F(+GS(o@ zHYaJfUeP`1yL8`}J)GYAydeMzpTefSy0Wee!}i_<9|Exs_=8SY-OnPoFR06VadJmf zYyQ`l7Y6^4E#>5-Aq*ZPTP-}#09=CjS%KeS5~5Dfi44K9m zWp!od&8ZzXU$KQ;EOC}$2nh)|Iy`^|FGOmB30p5dkX9}55MZZPcOiEZoeB!|_=e~s zK$8m@YaBOo_2FZs8@P_5UCBZqRRJN@7%(-6mXV21<>G8kUsbK0695}?LZ0k z)_g6Sg)X>2iUv$L#AvH=%;VG5V>D>kp=&=S(Q)lAKNU1Q#|m&VW-lDM7~Z#%wgHw{ zLyJWLH?wOfQSG;%T`U)gj%AfWQVIvC5sUwer?T`L8z)<+2`E|$|0Dv6iT-CX6CF#c zg2!Fn6O8uD7c9!`K@aP!PS(AY&`kvlu4*)1^M(H!$EC=qx0JJ<4MlKIupr))lEgsA z5ZYXXqOrM%BIbTLhn|rd|E>ik5#?Zm3LYfZgRMM!5(yiCz-CYIYH5b&9zMmdbp*}& zl`bC{4T0K0a}_&@-4e%NZ-QZ{ef1NqplT@gCq+!|KQ5kRTPAV^(V zf`l!tm%xXXHO$a}Z4ds9&#e55j$E>2!0j2C910@$-LED{{hzb?;2jS^8!bcG2^BHM zUKpnF7ykN~j=`$*XQTS_fVnug%s*t#PluFBSx1+dQFQrl#VL~oiW3d8;#bQ80t@0( z!&f;kLb3VGEVo)!0LX|q@A_F`==|HR!&_4zlX?v*u)^`%)4IOapDWJf1bLP0{PnR2 z#CEotKUkq?zoih_FdH^wIzS&`mfR$umB8w zp;9nRGA(|<0vVM;^o+v^+s40LC*eGu21iP2&ZkeI>t9+OgXCF9m?{@*?43v;PNZw( zU)QsLG!}~xzQq7gEG~Qz-#FM{#$_)ZOsI!zWQ~Wj6GQ5BVCYw_LX6NA@DswYaMIBK zXL1qqR=-F*rccUv_=bvjM<;!ZrQN)NaW6752APML+H~ZG{yEgz>ngkhB9_tt#p3`O zj9F@4@T5ggu8=)8n)?J|4M=XJC6H~f&B2*-3y>C1I>7M&s-r>%P#!2XelE@{Oe+&w z6XXcv`wo5%GrnXt2*el%nJ;e-8b$unDS{mmPq81|T_nTM5cC%qXngR_Xdhh}X)dEa zNa#iHzH~y+8q)smN2}Trt0pRGQNGDNo*`?6s(M*h=*?j?`}M5U{*MsNS@KdkZsK->Iy!!|k+610e^|F)h- zOYvP|u6E{#YXN!XOzoe2^E=IkKNHACJc>T~^hb-@&ex0tVnBJu>PC|pE$Nbg!b+sz zY9s{;4_tr^?YodHi-gbOP3EWMGB|#QA3!cuqBO&@P_F~YcD(EvRVcNkKvlT~5!QcW z7DVO`fG3kSG_4_sodjAG&AB#hmSosg>=0p*&g(OPR16LwE6(Fw!x5C2 z68)3j^v>0awG|~W=+*7W3Re27K7|4jHU^POthaio{Ae0#poC>KtxNnwhB*0CE{Y39 zT&cw0FmG5JFE2g{P=NR3*PCk0yCw}mWZYO+#$7wVfQL!3r1H`vM0vo`y(qrtr6+F? zXf`Z(S+ZdR8h8VB zc5CIR$_E%1bsxXn@>%ATMo!iN8bsRG$s94eTsE9XQa{~u#20MX4m!~sI zor+;|cP}X)rl=BT%k}zn^)Af1dAy`i7O}GrgaSU(6?xJIGPS5!9Nfb;zwV0SLHuDXI$HX`73i&DN$gW68&HB(}THw#awtd3$Snwf8@=)>u<;GCAPtQ)_7&!`k?umur9b_ z^{?A_p!faB%qA2uS%gQMfj~RMH}t)X8_bupK+i_~67#mPZirZt z|K@R&cw&|I*jurTjys9YpIUPnVDycwfS@5HbKcG@5l-y*;a=Hq(``*4ap2H!zTLlRfu5I?Fe!5>Br!^yv;v7E?|ai@ zBm98ge2!NccAH<8ny8Jb-@N@_T2{FYWrt3VkGCfh<@?RgcqlGgJ>zM;ubyzHGt-xDvOPL0fQU_bh3 z$e|R7QQ~6WZ9G4FHKFD}sm|MB@KozxQSJhhFAtOQp;ib^qQ+ftXTp1wqhhH!qrec` z=wl>$r8d!VkZ;<^~?b3vW4Wg6+$sbNF#>$miY}C2MOm z45q)^&9GwDpq;^!<}CAtOpe~T^!(u!Y?O1hvh!EM=t6vJW?ceBGURV~civ?1jAc0F za!i+2RgDmt(D-ccMxVUzI zz$03~2y~>~Ise;HQ~zh=(8)Fh@A_X8Z~%f)zN&vsx*YjMx(+#U&&4b*N5OFX zC9r%Ud%!o457Uy=@dc`XNnO4tlm6DmgMe7ldW=K8djZuYvc`}wZO+naH&S-%3lt#@ z|NODkVzO#hvjBb(=8ezFwyi~ELYW8mZskkp?Jq}WNmBZBr;g3!yy(FvUZ5Ga@-^&s zVcsJy6iud;WB-P&ySsoN)Y9stxt1WkYIM!RLZNowAzX($d>vfJWgZB{gwW0-;%6>qH8t|@642x?k$VyZT(2Jp@2-n@%Od*P3 zkvI(a;MheUs_tJL@b4ooEc3>aby5a~fz*uCwKBU9>935AQ^&IUL~N;0El%b?B%7#Y zwSX^bq`1~^Mnj#ZR18*pY%;~uFH#GpDPn07rIo1^=had;db|k1$t~t{wBZcRlcovB z%0wI*LZlTa0e2e^4FneeiwN1eg^Ptk+yCaKkdc=lwRB`|-{<=@AEzJ;Q&W*S;<*RT zAP++tf?;)Tyl_Etj8Cl!Pi%i}`89$swx~LwT9dc>Le~9mN72URU)6S%b@=Zo$HZrQ zQokV50kArVbvo%_8|CYlgg_6DVQ9$TigR)*KbzlEnzxgaFw5GmDsUv0)_i~#*%E@z z%y6xP_Mq_8q<1VwtGEie?T%K#tIW5@wu3+;W8-=yzF#}EL>fbNkU^H`lgWkz zk)WJM>kZQ$-qa6Opj7av^52?}iy*=enDMa{g^Z*X(g8Ed4vZW=@U4_HP&j9Ny#YGZ z>dOu3nSh(wlJtoNaVg=OslDCUPMq4i(LZvyEc{U6ln}JbD7gB(-CzH2O*FRyAC7cs zd`9glsH-IUtA#nmyLkvOk%oUZd*5A`f;cOBj9<%uU;CJL;&x*Q?J-0$VR!ae`_eJ7 z+pT}=j)t2vrf#BADy-H(6;@mRW#n+g5S?y!C9nf@-)w9Z2SL<%bBIvh*yL*;w0RU> zarO32WQu*#T5=MpMMP2}9cJ-PZwYqZqwR|$?k3Q~CLq+n zAIncGG|Y?lg=(P)Gd-|nH?F}$2k`rNzbPv*LtQasz1Fh&KIiV{Z{E~*3G&o!nB51e z6|!)9CJ*WmNarveULZ4TpwwMU8YG+#`Q?P3o+l3}R9l*atIi&BSu6vgKjp4<+u8Io zHN<@2^+BK5L)vi!ny4+pW|*(vvc#dts`t|=Lv#83w}YVQr-k6{ipE%khqL$F)kQBDD+L)j=ug3T$v$P#W%v0Kk@ljFi|FIsh% zWmjoC>-CU#CvZ{b_;xf$3OpY~7T5rlF}0H~u=OLLR9mr1Z#u|3Qtj4I6vn3N?9h~o!qATL9)qI~)J!QbII{x)T86=)PO z1j#IT)XArN`dm4%>ZPAM5&vKBToM04AO&^a6cNcoE+Hl01w3h8c~)_G*cy^Kq7QEu zE$F)5I|@V{;UN9t&*dw&KxXRPKxRn~1=qSY`|x4Ri&RoUlI7CZ>PSop#l3X-Ir{T3 z@aZw|5r4iNUrz=*uEjl7+lhj+Tz{FW{tSoe1li6_{j4;$0s$LpbP>k|8sAZQij6As zf!Uk}uN+iZj!JoVf*CC0D^A`_^H~X#$57IjEtOr!NLi1L`xg}sVVa*Xu~bq8!(z-O z`hvrLc_{H}3S%$?!S7PHwI4(U#3T=@y*-T@_i}<7>G;{qT{u}n=p5MrWoN90lyh!T zz8eNVl6RxI0mwu8rxwALV@aNWn@pQZLWuNXRXda*1}m~u3tL=w2Zln3LHl-rehY;& zG8)Bnr%k?YR!4kRB$HB(?;bDvK7ZRaSOO@P>%G6&In{x4AZf0B+stP-61{}C>)UX~ zK!>Ar2Nb~s%!{L8*LzO~+Ua2o2y{h!BmOBwd>?8&4YwnF#lxbu7kFuQt9gZuc%f`u zMa*io;)WZTM2lP3qV!O-4BUv3f#jUMwZt6oPRY1Rc{;lxrTP;)zU8Q~{f`JlX(x{i z5(gT6g3Yd*lGQfzm1OD^UI)5}PFODsC}aTGMqDw+E$-g5LJ$(s*YQgkB$jDoJ>kSb z^Klfyv-}NPckD&08fdbC4V+{exzj5y15pT%Vbd>}rNBoLL=Oz&z0|U{GfBh4f}v+A zU?vEi<}ESaz*Kf$`wVrG@1YL8(dmjBKkMe*S8^0K(6I_?rZ8D4RD{SwkLf^8BLP3@XnzzpT@xb4-1aS)BZ z{kH|WF`d@@;8L>bbdm!v0|%%TOIgj=-JUu@d98B%UwGXL%dXmPOPXU>P!eL^JhXe2 z6JGnv@7G7OV&QOO- zk5^+j8E@w44%&g}SX|ZMtdtVjzK#S!8_sxdD-<}}5>Rb^)y9|Rtl`pD2n%8Bb)~}J z)J{(i5+2UKS%n5Mbxt_W2tneN0_7wi#H$SFIOi&<97{kg!fZADc0m1#pIdh#x0$Vl z%+P$WhH?CW3$i0oO#UbRp*U!^kItzgr|4KWfoND(`Eei+sIv@=>9Wm{ms+|YW9H7| z<)%%>TVA4vj-Jc>Ac!WRC^9zK`&>$7)geqI;p=63hs3N(3_z=4bw*lzSle5kIk7>3 zzVEE*(E)Y;oB;1|S#bTX_op}#C|}G^gcBrMU}Fq4jBro;tSuWzkl^ueA7qBDky{`p z*YF;clOsr7LU+4}QHOwpurOx{YdBMwz5T^S3j&^yY8uJ`8(H}?-E{O}xL5w9;Q!apt49#NK>C1o+NdkbFwO{Ku ze;+b%7o`rGM|(C@H1%3jp!|t%F}WZ(h5x{3Szk7eg=PNumSEXiajViw3U#_D-zjD9 zuDq%pMC~3!u4l(7ekVG?wT_Oh#`d9r6jq+t22@=A>Aj)m90sIp{?@;5W0MN;V@^xb zf*=cc#S%Zt+dAB-iI3S28dS8`Gop*xB|^|(6RS5=1Av%}4)~vsz#a$J|JCuNsbbdA z+0K6Rtptb)fI}OEj-KQh@nBMozucYIZx{y9z*5& zj?SB_Wy{8rKGYDvf34vh2(dSEC{Y`E^=+jx2`6 z*n!{w`%bK&5iU|~Q&JeRJ(=7S4!!pJ)WA@EU$VmyMIRpnir9fe_q=J(KhvYs(Qg68 z>^xwJ`9Lc9t8xG(Nh7mkVS@!3QQ%XKfK$Vjw@9fBMy%N=*;F~!(<7fdza_={%MFvq9A&rT>A%0kx#!2VsKLM%L(Kv!6w(qQo8=*yytrU3So zel%DECMXz6MN4ZJ;ptt?5d@+LzLAHWRwp56Lx+Sf0LY9s>uSS{10uOWf~Roc97o|@ z!=1zny6Iyjrw}O`-*@fg=6%TD9EndHkt%94{eM)wcOaGR|2Tegl1lM-9$8t@P-ZB5 zG*FpQ_DUpK$=;__JVq3uvPwu+va(OvyPWKq8M62Oy{@C@{rUd>I(3};y07bXz4pw4 zsN3XPF9rUBm^PR`Byy60@F=+W;SRsP*HqC@X2!UGyceF-kI^MFF$Ke50eKw}69BIx zv900w~v-S3?&KZ~#s?AzRpt=J1eR%p zlJsWpQ}R!enec)g^(4KwF3TERxV`-&Gt0}bH(4n$qb4_D7`2SZI1*w4vcT#f>4sYW z<-su_R_u23(v9t>J{^tyPT=Q^7RO-%C`a1$W!_z=8G1H-tpc(}EP9x+hT>iBIkVyd zOr?3GhY52fBQegi`m{o|M?(&>);ON}+><%W%Y1I>!Gh1eAvKUy&SU^_j>r=e>eRY_!ouM;tdlnNCAd?C4| z&&IyP;z%;N7OqeN=Lvzd(MzAzrhdZ$ym`RCZBMpSGI)XATz!x2&~A`%z_M+EHWjsc zkcFCrJ2@nj{0_rA3z!r@Jm!8S-FY1NQ4C<}?K4D7A*5_MK%q@!6!=>GK=C1zB=83- z!zl2wZv9OQmKa_UVUko|n=NFWiD87y=(v&9Y=oFtY?1{l4C&3uc|JyjosxD9u6_S> zR@jQq5hrKM$=?uVCA=s8){nVOHV_Gs!)Vxn0BHwAYs)J%7!4`CO5wMS0ut|-Ae(5p zf$?vfQFk1683M(cu*1i|hX-aL%s_%2ZD&d1|KVm-Q2qG~QJGw)Hx&415K+zCi>>0& zo%e&U6b&aOCEs%uqTo*eWaIw9PEO7~c7G7aiU{Xqt=@me;la%6_~gt}9R)twaWKA) zcH7-IB*y}OL&8Qrta=EoIs;MI^gJ=_<7Z?CBLtmi!lLp(4~g{b2>$%y9SwmTT6J&2 zAsNsi%kpz4)xo3QDqS~cCOuReFIdlGIxs^iRV6QrME;8nNk}D|gHVq5A?Q7ic4Mq> z^zWT%xS7DQw{id8>wQXfoBRG0gheaPEArm%Jb!ZM>EA=~j4Lh$MsC_6Vvz)R<=tt0 z4^U_jPOhF!&>+(hp-~L&Wjw$4F=Q!$uhxf@9u-AtwY2GRPQOs);x%M1bM=wws5fPS zj)HD@Gr#o})fJ31CpOu+V);m94WuMhg;bm}{C7;lL3XDU;`=22h#W`td|2SE^w_aZ zXzhe(X1jX>S`C<-fkY(NAAlTqsKS8!q58R368??(SI_P=#g!Gjd&CKOOF=%eU^UWT zEaKXW5qwCmPEL`%L{5ea(p47j^;Pa%9Um3=ieS>D4sy#t7I53kcQ9ejua6^+CY}*8`KCk* zhsXuTCY2vEU~-74-ZS%~webwlcOU23~H=fY4Vi}9YFyqxFF)nj&R#aN}7 zbd%F}q#q0Vqf%wnqgdm8}-F>d6R9J>`F> z9==iZn{GvG%m5qxhQN%WEkBD?=jSDhVgNrAO%ZZ%BEN!sXV<^07Jp@x9;KJ+U00Bi zE!4VbZ~LUcsH?kS=^s$eA%R=ZkOedOg5>U}BM_M_1fD|Tp^!QcQ#47Lc5|iaF{*FkVG=Nc%Ef1n~rx%Sh8zHkrF*5vyi9!s#6lnn$I zE%4ak3)fJ7f=|6q+DWG5M9Sv2PZm@Mh*QIitqa0gn8|W`SYrfm6mldcAtrM6`96Fn zAix>pDXphl-DOCg_E$*?%;9e~23kmdrUTiiFy-8#{(iwULz9FLNjJU}i!`BBsT zc-`HC05h@3T=i(krQ<&JA^x(yeBAC~U$us~|egJ3&=MyflVJ1gOk1kC(RTNSk z$8M{ya96u61uZ=M3aG1E3c+5w>w>H=AT|RbmJ^RSkyCd^)?;Oc*cP!Iyy5*WKNqG$ z1qdYaxH!JUJ6?LIiN=S;s<11wQq|!!ewhY*PH-4`Zg+k|?_0MIp|~<2?q_t^@N9Ws z_i`!!DdxsIB4G}0C!iH`?{33j9Q$U$#PXf&h|QVYOZ>`2cuVBP(K8r=sn2QaPC}h z5X=gcV(nZqF=H5p^oBcmoZG(>bGaIZVn>^e)}tr%_N}=xDwrv>;Xax`jigPO2K2;5 z4_iY_AVHZG)PCrAZb_fD(xjwaLtIv^Fc)yr_)EmJZ{=KL`J&s>^MB@rem5VP{R=CENpU$Am%aglUur+_JMz&{Oh)v$H%W})PTNBarf?!Mt4ol>KB@(+9tq#!;qTN}NzU#BgUXnW4ikmlJ z_nuU=W)iLayR+*`+~jQ~J`Mqza(^{SOFkE$WHziJSu1HTrv5iN0sYbw2FP%ao8u1d z?6Q3~eNRpXdQlW^{W$*R@&1TwiLYe(d%f3-acI!Za^Lte6=8GQ*RgUhUgIyo$xnCK zK7eU6GAa?=K9SQ(KL1HiiR-v*oMIXy!=?RcKU&7N>b1E(aj0oCSjM{d=eds54~kJGzAiJDrQv0!)+6H!KH=j5`(S93M)Kzs2{N3Z zVp|*0O&t691Fp`b6QopQgaoEuTz#`5+1EdWopXBT2X6jTQQSkhqK&&`r8J>semC`Y zyf#DId_hCj8hyS8;}w4Zo(1P3%Bq`W>S<6$?m(XfiO>Mo8YO5_x@M@zyIORmx+3H0 zzoDtn_PXd<+vCDLIQ2#MZ^!RrI(GqN9~(eQH(qptTm#W|S|4i#$1Wq!3$a#&<}q61 z(jE?t5S+^x7+t6RcecCYw)>5d8vUDG=`U7|FpfN_7d*FS`rAfh3B`XE}okAef? z>=mBJKZ|=FZCcN4?pypteK504O1VE_iWTs%r$5nY=nBu^_u~h!`+!QIakkI`)Xkk7 z)AnM+sSXiU#!kUy4|{$bu^b+<*SFw_f^r70IQ}vZ@dIuXMvA{}l9q;D-?3rCCyB?Y zv504K;A=^kit*2Na>6*+^GoO+P3Dvk9u=pxwFJHvFn;W8LJv2z!ef;@b41Vs_O7-K zGXjPlQefgRZ1(qbDufo95d6v8!&xoq; z{X@k3rr)$_YU-4CX})3d4sBg6L;!{$PTa|>?FV>mh( zr&{U<_dRnwG-TRI&&Rpx2YEzedtoFSj*wc&aSK~9G*n!^~0aj_tM?^`=Q6g z&8RAF@K@B|{H7*wT2+`;fyx)QtKRbI)X6R|bY zS0uu=HnUMr{AcNnm}2!^=$dwc1Fl5AAT50OkY>ku|#uk?;#SF#oTT*}-127kfM3d&v z#;Fz0v-#0#kL_&t3&WcAuHmJb-G{iWIMkqfU_QHj__!2BU_7u{wxpSKs;i-K=VjA1 zodlj#b{oqi*C))JlmEnk!;{!ky@`vgX<`yJT>{a2`{)S3ll+_@w45W;x@lF@c$aUm zzJ0N}kea@^E^KD@!;IiCv;a-l&*c9>KI-PPRy|t3969uC=4@rgq%+MA=)M+>P_Xc7 zt3O)+@Z%;sfu&iqJ>Yi{H0~cSaiM)lTOGQgH~o5A<0IWf@S<0n?w)yJwnSSEexom& zQv$NympAJDw4=8iyPATyo2E;ZsIiX&h#tSYeZTOmPh$H=)R8Ef5X36S%`3NJ+~th& zTr}<_xxJ_VXzjd0T=DQw1YQ~zs2xZB=uZ5vt&uA{UhMtM8jS|zNgVudaD=b_AW5B< z$CfohK}Ate5ZgDkQ5*I8wUyIjsbIxZ9fkidvymSBJY|aG%?7G#7ATv<_PZ5MB?fB8 z2s32Hzuz)H$nL)1%aJDw9j|fp7L%FWMBLB03B2mL;_CzcJtO(RcaH=d_q*cf#*rML;6XX@R2llx{A%H*R;*_hM8EK!o(R z3%xCGV+NyR={9y`k%O-J4AcIlaSn>B4>sE@``2mpt2oF7a&rFx#wM+Z_mnDeJ#L08 zTNaCs+cN(?rV*~s0~VkT2Lj&Zi9-T9r==Gw$CH^HRrJ9E#bG_ zYKAxi1I#E@L#6qdt*o>*-t*wP<(6kl%MB*)ys{qKhUV>0?`tUpJ6FcZsWGaHXoFWk zTjH)Vd)FYf9n&Yu^5nv$1L>u9?|dlcv-Fe_s7c~F4yRmul}}o`)H7H|AGoIyQdus; zO=qk`PBk?94Vu}2*rqs&ZpGB2`jAKf(Xx3)WzFvG!pvK zb1My9OK-;Oq7FJ`$z#FOVF+tJmPPMujg+h3doh^y1Kj~oG#()}40nK>QObZhF@vC| znqg-|FPsk_FB0GHD}&S-B+>5~J;Y)qKNiOt6}#uOB^}$S4`HXb@NsjRF1lj>iZAjo z`1U~-5I8%e1)l^Cno-eLiJW_GF3OhJJ=-L_S?$$TsG~D-p=eSEgy7ucdl*w+^H9D;u zNUr*MwwuN^bNvBTybdUOQtR_)rQ`6PpIsksjckq^NiMuW^4=6e9|-6AK;FlTouu;a zp8Hu_Lz5t)V;1&|psQqYpr(GfZ71IwIIugmkl1&*`6O2nhb+Gl?9E5Q!aJ63tixO$ zi?RUZ5NrnIFgc|<#!FEb@x`n`WlR~A#Cb90FF*dL{FE$k-Fd4dAUO8QZ`>`nBmu6Y zwlYkdty0ypZSDITble;&mm2@A? zn2hn7+6f0gAe+Bt_wLN2Y8%!_eC4&2q_MVfZynVOBTtH=)v8`y!m~*FNSE(=E z7&jntlqOm=GtY&ytqrIwCwoL%nI)t}C$z++sz)%+HiK)s!|^?h8zcssP0>C1=L8vj zYnQwGQ!g2{=Cd5^uv6}hdh;d0pwES~*-4B%xguX7WkV7z8Uo6(7D$t!?F<&ylhK0%L+c4@7vl4t%bTViu}-)*;*NONhTsSFrNken5b zG&VPf9xYq|^byR-zTZ9o3dFyjo1wPLRFmmeOShq7R^DgXKz+NCG%*ocPR zyD{Uow!{C-_uNwBH|kyf;oCVau+x!K7R25E12=X?~miIel`Z&%>Xj1jvmI@GSIL2e@LeiLM{u_cWS0R_kz85Eno+NclHT9@iH-X>a(N-6+#d#GVi|DY=qa9-ik zx;r6vCa85a7sTochy&M{+CPRD@bywp6`!H$X)npX0Gv!FgWIJy|~L0n@<(6C{{F_eE|&huq`HQhS^fH~NN6i9b? zo1U&{J@p>ukr$|v2^dXJd}UO|yFp`U1Md(q+aeQe7Up&qeso$hOjf~j1}lzp_Bodq zG+G^6zpH3}?p%5z7HgW_Y;d;pV2sKv=@epl`csFE>x63X2+0>Q%L z(c;B>qaK3^QEzlG{Q^T$K85`R>1eorz% zfr((cfch>=J1RnbuR(I4W8unJf(NU;Pco>nZg(2@U=+xBy>RXeUwX@_rtyE7hb_OU zz4;ub#q3K?SZG%wN&E$}hD31q$$Bj3V*=7#9UhVV-32_+MTb8Dm%|55TBKpCsd5&FHF&HxB}X-A6SG#aJQ_XX@Mi4-c7P^mSMH1{d7i zpJb+|QWA`t$RO3>NE6xUc}Y!NK$v(W1zrmIV`B4MdiErU#pE@aEew8XyocX`X?ZN> zmQo*_{wA10BS#SD45fvhM=-ipMaS2>?~ywnNSM^A+Wph0HqJKP;@O7-|-Y<}ZkyQ^tV(N%jg zhd53ptS-@Ff(}3gp?=`#TTo}^u8N=GaHdtJHtQGNEXI!*{o^GQvO0g()W%R6t20TA zh}{6X=*MA71#z;09o@`umw@dw`h7V`P~ z_mGFK78oYHBD<5)zMTL8$cvHvxpK*jL)VzgPATWEo?sQ(8Vm5f&un zmP;eu2XkGLSr;7q6j_*#lQU8k24mvI2WUvK`zor`T*o4+fP3A6jEk*MNaGQ(%V}vp2NiNM<_f4x2YR6fk3Jk{nKvXLeQtwISDemwV-ouxV(Y4%RL%`^^YT` z=pu8S*eOhwmG$Ed13jrP@vG(0trm;2(p#qB+AEs;N)UYxBd`M><;PZxK4xJ zP9Ulh8RGZxdDuW<8WKNAV5q-%C82)M&l%F3?(zkvZOpeyP~uHNM?he|Vl_EIMsNgP z?|CRd9U8zR$))@+z)#ts{O%(vd8S3K!uAP_u-JaCf4%ApPS6;{YyC`N1i7FWINlE6 zz+8#qPb9Q~vHT}Tw?w6*l0=cC z?LEm|f?yYLP0{ugXu(C#OF(XKmL^54T^wCTeBOfq6f)y z`3-ce2}U+Sz-o4KHy>7?t+>;sR@Uz*NimSi_JlSDI6I@&q{3Gm;Rph~{{JIsuvv+2 zNm}5Tqi+akB9L3uL;G&>eyq5qwIJ|4-RB6}X-a%P+GD=$RqY_tHyjFyTv`Iut32T`M~t|w0;pr;6XdIveZ?5rm6-&k4)DGM_*o0FfP6#&lw!m zoz1vep{AeQEy%$)a2RlQ;4CQm;a~+mew~6z`82jnDT>gPtWx6r*@vpBx%fS3yO)uH=t?r%M_3^d6PT`1g4=uWF-Zmd`h0jFp-d+|@%ugFQiU|eOmb}JqlOYI*mf#h zH^>HDx^yKXeL2mVe8~n9(d!a{>DRmkre7|KdBf-kvAP!5>ywAERTpp#fwKQrSM&xH zb>ECiIwwb~b=PuO5^8LK?q~mg@gewRrJLjIUV`24>12+c=~6w6pky=ku0LUU6Wgq7 zb(4tmeY?E*b>q(yZ&k(~WZj}WxnQ~%9~b4ACtk<$6i3hp$8Te~e}-x*wprmCo+K)F zZ89ABwczh58qp`86r<8-W*c36eB)Qxf|#5%P!)6C3%Kt3 z)V-X_B7i6!=*sv3htVQLk~Xv=<4`NwIK`M>lu3`hqqY}q2gx=O?062U3?hIErTp}@ z>0ng*X9;ae{HIjWmX5q3XJ)8_83rpoW)LK1e?9csw~T0-ir?25F`bLe3ZP^4ThCld zOHajB-m#!=$Li8Ff@``?9UL2x#OUm7q_>Q=J=wBOzoS;y1GnZMo?C&G8G;?MbY}o& z>B=D6Albitl>*;#H?PGtk1s(TGnuxwPUWU&t4IBg3>qS4+#9cIn8kd zqt`8YcEMh^d!H~~=*-B2UBS5d2!Ob$T=Mg=2)Hu+5$NTZ0G-ZQ6}FHQ<~tzTmu(Tm zB&Q1=?FA|BuU&=Tr(k#sLO|h{)A#6x?HTQzGN`e77+v~nS<~Y4)f;fhog|!E-0((M z9$}aqlO!WYtM?Mdd#xUUt6nVvu6sB^h1Kfj(6u%E@aY%3{y>cZu;n@i~P-%V{rQ!%enP*DJ|At`9b)=!Iv5q_4Bh!JQPnPSu zO!p_$OChNHm|HW+BWxoGb^XV5| zH1QWDVLr<7p?KT=y_oA;4Hbs@!mS)5Xsvy4y=j$Owd5uw{K+DGr~sQz9cHr)ifB^e z&B3uV^bP3!fd`~70*x$vjm%VtCgTnJ$8eBaJqc2&F2O@`pR&eB>5%^zI4-?D%A=9r z>?AtTLy?R7P_^q)M8+qqe&8nKcX9C6XK4t(V#Sc(`FR4MNY#+w+o3i#!q@JOpwGYM zfkV|mX~8bPeYk{C%}n%A=o~Q6+}DXiP972c@iscTFYmA8EA#SVtD?PR@*(lC4~7Sd z*(w@%x7V_npwTB&fYP?o-$e=;@b^I!$MQng5u>Vnv@ZbkyL-}D zcqn?PRq8s)B6sYXfYLH8D@(J^$V>urZ1EBC#q1~2Z?cCwR`tkyl@~jmPLduAwY-!I2*{@Qoc1FDS$lAN@(IqMC;K zDEDYKC1DeWv;q&ZHOzj=Q)boaEJl?SoAxqWb%DOckW+@j`j5 zQ^4dhah(#scJI}G-ZRo6<%=>yLw<|iP`tknF$ev;+-Lvg0u*!`K}y-g#K^se`FAa3 z6tM+}eULbHBJ@I_=gH04UIR`&Ap~>rsx?;o$vNZ0>VZ*k8}u8qtR{tlH?k_ai}+(RYDxn z07$2=$UiJXUt6l#M!?G!tLg7r_fhmsXFLQAHW+}n*-H-27hRjjhOsCEPH-xu^3!6&)9(`ZZW@j8 zmLSGRffXZ~FRp@?^_I!O?~mwiHncv@Tf*GBd)0@50lH*2-a5PH(&qO6!G)N^v z_#Ddc;AE`(=3LWH;sdI7Y<4d)P7VPCoVf-?99$n<e=9h^|tnsJtQpx zIox#h8I16{MTLS7-u;&KnE^-i2e>nnt`njK%Y6m4Hxy!o&%%RKF?5ft*gjBTa%_1g zCNm@Sum+7$aeWD2Z}$+B`Gc5p47{+R4%**U)6m9I_e}EyzP37g8L#`&kz2g&%^r-y z1^hmt-=>nCm@uN~FGWDFHwVG=E%{PSGYDlK*!>5=m-mVm4;3;nY^VeSl@ zBl(^v7@Ze9vYs7TM{ z^&H%!s9DVbj8(TGp(1!>{vkledulq_q$iK+Ag1ZyWZP0B1kSPzeA);kcMo5N*9Y|M ziOXTJ<@E(M1e`oJ(!u@fAev$JrQi-A-jFkBq(8)|@%c<4L8^v(AlYM_&*s_1m7C2C)qJq~3Pf6hxm>>*^V1vAOW3=xK>~NkV8@RD|%W=DAv#3mI zY(0*;MO+qB7Xvbj68#TJ1Fd7>J}mYS>LIGmoi1R^r4NlJ(ZddJSBD*D%OyLT($+h{!h>$sY`fB&rO@FxObW zHw!=AMmE{7(N_rLghd-hi3z^kcm|R&h&U^h<&ZpAkY1q&g*c$YhnUG6TtBtX;wyLy z&ce%d_CPWy_-#BT?ya7o5u#kdnt>=m|GD+)^bL>?9O+cA{b+l4qZ*sgtzRWIUI%VU z1_J#PJ(PbIIYz?OOJfaF*>4Z77cP-)z9uFAh|pUh?F(B?K5V6cx0p1N4CAc>O>8Lt z$hapPrn3(a{i8oP6C$?25jgMsR+5DvaN~pJW^0^uuM89t#9q<W2E($Ih#u-XhnF(okk`%^t9YNVYz)jC@vY#fAU! z7|C}P+0?Icmkj@S@juVY$2|}i){cGgO0VIoYq%{=0wY_6u~v@w8 z_Bx6`K4ymoE2S^=^envBn6oAZ*$F$aZ#t?Z|?X3Q|!g||N7)>WAxul@y0;!Nk$&?+tQo@*s_T7Q2w}e|;AK$@rm=P3%fK~ww zKc{R+F1e->|2d2K`*(B%{aPmaUl%w=hSex72!c1tum-;O2ZHRI*yfLk^O3kbHV#wa zkdxQ^+%Lu7B}$aXZ1YQ+Yy?_q;~TVmg3=JlYQuzWBrEAo5^Y(GB!H#Sw6*Pc=-z5IKNMe~s&{u*Bg|ob zIu}gL=SWrf#7N2vIwaa3o9d8cD5Gu!R@y$2l?Dk-By|rOvcU*x^>Z{A8RFxtzNw83 zo=CyuED@XP1flw$rto`734;Eq4o+Ad%$`CvgqQ$5l)G7gUuyweQ4Con32bs}j$PzN zWeclAyx{y}h$D+P14bX8W(($c@DGZ{H?^|j%H(yob0ex$z2MSJ7wKTijv2V6dQ`1C zk=|5yOX})a)Mhq+vaZC=IX()KN{H2E5LKrJ?J`YY>`=<%TRDUY>q zcyG8`n}+Xs*%&(uJ`1Rw0CJy&(r_eTPNvWIoh~k*Kd`4Rd1GifM-Hm01M6I+;v4pE z`F9(M?{u>JA;c(H-im1^$Nr)PWFa&I=UhIgDfm`7e;oA23-s|pCz=T>!SifyaoESG zplY1|9SaDjv4*s)E%hZi9K;6L(I(?w@8R0!{{G-=t9(WIw`Ml(d`eMB`qTNVYKUyp zN!B=`X$G=wdJ2ilo0OP0ia@NEeA>gs=2uuwCUw@W!1a~50gSNSUY-Rn;3lzk?f%Tq znVFVsS*wDMgS#g9tW=muMeXyxLYcxJeL!Q~aRj=|d!cf)aD#1nrg;qua+A9q}Z=lj_ zbdp2AIP^@a;`aaGv5HLeVaL%PngT$t69vOrW6> zs48)NL#aB|ymgL~IYJU#LQEqNs^PKrkx#jrO^VNQMi6&C-8>)r{H{Ld_c3a9JXqN>IOda*ayi;5u~| z*=RtfaqK*4~h5;rP^Xs{+i zLEKK%j8}<5lQduN17Dd!C`03jVS_u=fJL64iOUP{gep8y(=4@z3-U7iarjM0k~r9Q zrCv!5YHJ}^aseO0{=1%R-q}aHM}FkItn@~9#F#7=iaY}xKJpY?Ct@ZrZiN*IC){{+ z3Mg&5L5e9ydYo^0D=d?RU+aqzXZIW5Tp6Nl_5sBVh(pePo?0PCIObod?cIN}%S4j=?>h}7M~W$TeWB|}N*HZ){R1`X#u z&@-D|(X-_NtReHfkGn-8++%gG$Jpj!7_^0m-}4nblq5Ks6O(e1z!}BzuGu{Z9AHET z2Udu6Fo#eQOvPSah!kV!hW7rX*FfeE2OYN{9;{o2a0{2eZBRv z&G|NL@$x+`W#?+n{Q}>i$VpGsHV_?dXL`nnA;^^!KxQYrg{-J7{TN}t-(bI*N?nb4 zEaUyHmBHkhQ>U0{y+|_N;<;aLLmAZxi<|wn?-q0+tp$0lcq3}hH?qGjqd~~|i!5SlZKn<4Wif~~ zik}8jI30fQ>qt~*_89D}tkGZ};P5*7x*dcs*$B`Jn%Jtm+IvR)>hTGlr9l@I7MuP_PJmn1QGZ&+gexm~|?INAc|2A;8I@f(OC~ z>>J3@44s6ps;Iy?JbP&Q@6JhpV_>pxAm9RC=Bq0bC>7@@(FqFkyFi0_1s;-ro}l%O zcV7e2tA+6sBmwFOVR%jh!*_GFI%E@wc!;#Xn9et~mzNtZJHs=s zD0&ULZUkJlC|q>|j0^7tOP_fDKx;pw`@-Lp9{^8)kM7pTkzLTi(POoYWZc1yPW?^V zm?gL%--|+m=xPb1B6=vY!p}_tNN+Xif^*`fIm`nIOoN4(2Jm<-qP+m?7c@ zK{99u0)fo*lV~l`KWmXvvg`I~k%~k;FZG$Rj5#>`IU| zoi|+ot)soWPJV~9KWV>$tY4Sm`&pE%3?F(Br-h^jIFOZ#Y&s|}(2@`FLAWj<0Cm)h zp*&{zlE6bENrDxO1qD|L1Ym8`A>SC?UNQ1$!bcU#3c|8qjQ@>xD1anAY9dzhPgWjy z*9q1TjwAsE4vDf|-~*-Zpv;xwgwCsz2w?|w|DcjHO>y{MY@TF=!VdudcF)}mJ;?wd zI4m@iZ>S3)U%~DZ1rVkM=fu!29R$|@P*NNsHI!KV``j9op$w-e+eP=W8b_FsdB8b5 z1;K8UiiAU}qD33DJZAwE0l6B1ck%!qp!EaFfP{}^jio`TVq=G&q&{4SZ)TBLgAYkX z-2;`-{SJ523;w&xx4YDf-JmDvko9ej5Y`UtCq3hOHLWq@BurDoMyb0M&hvtM9%SetH!tOBe>08syf&8?DSO4G~@(M`9eqiYSfPpinOp z?wSNrlAjj1U(cU12rQy}+FK7oxEQIV2iUGHL{zc*QAl}*FG)^z@IlB)s|>l+56rps5VTduDgvZ~ib4bye^IvysEA zj-N!U5ayxvAc<1A^C8G|gJBOmq+|O>q$Th^2B`tjzE-HI!0?H?kKEVS59#Q-Mv3A5 zbND|XRtA3}Q6S;IB#KYslVAA(fj|w%-~Jmuzk8*XUt4yc7_jQIX`eoyVaaXimg@L! zpCiYYa1PDtcbx}_Hohs<%ymrf>>0R?BqX%k=!-lla?Ra6UiY5R@2M5_x$=a)JKt+V z?AY+L=T`p8`=#=Ax}!IG!-d^9M1*NFVVIaK?B?U!-Q83#+d|4L zyfpUKE#a61SS21ifap0Kb+XMJ0YdpZ-C05n9w9u}B&~mNLy>I|Ds{oXLOKWlIC=NF z^fTo}`s?9nXP0S+1qWc2h$txN2CZTy2kaJX>@@sa9W7!~3w25GX~6^EXvOaSDBUJt zKZaj83|}21?SVIQt9%zENtOT-UHHStN2Go0s3PP&4%e)EC$Gf~(RD=7?keN&rjGKh zMdyRvdmpK;f<+k#ocm3M@;H_*RU=LEq~nwsnB zN=tRC`RS_j)Ej=|J)mM>O1rQgakzgPH$R@^vom9R(lnXYo)|_o>mFu*y31B{+u)(3 za3a+hKm6SFH0jbJ>R+e(yI-Up{$AqGxMhB0!i?p+tvpNd*~?BsqI zR0;59ff)EUx~AiANN~I_Zds3)Ix*y*8dtV8NwZ>E^3yLNXZo*!Q+v0rzqiRREqhqd zo%NP!42d;Y^4-@dg5IhXhI4c5QsYVJ=~ZB{PPDvV$3w^m+xYa4p_1$Gw@!x5wI^49 zkxFZA5kClzM&NfLcC&;&%ZHnC-t}|H=V|G!6`xZXo1b5_agcA0uitwXklo%~EMs6O zlP*P>{n3Zi!`e*aFM)T85Z3)zudJ_$GVd|itp+c?Qnr;;KAK4t3qthY?k z7HcKmMV(AR-6bJyrMBIr;_eqXx1L2Kz_J?(g$J6B9IJYsTw z7d1X3=B-aXJSP_PdEL#~XZsH0+)wWGYo4DYMZ*WDmluxJG+ApOGv2bM5MF~wY&3cw z)#crD<@yZYw>hc!^54EidGn(EPGg{(bSJl6Rw-wbN;sDbym4L^FLT3HpJS zCG_7t1t{kk7stw)7AJ&MUKAFF%kqZRiXGMiM{U;`wf2&=otW9m?VA#rhzuW+$lT=#9-au=o$%TH*8=-+P&&l}0fo z?NyQ3hGOqit36FN@Rr$^yT>r!5rm`=>S24Qf~dsjwkOlgMJNu;M+Iq~aVny z>%SA_V#AYa19Pc8w1InJya!3BOHb-MQTsrO%`e3@?>*qXGf%oD%VLSKpnzz}^~;9C zlNT>lv^Hz;hN-2-G$G~$Jz)?p)nRFj@Jksc8a)>pE%(xEU;TM`jp8;Wk;+<4wcStS zGR%3=oCXuAO?NJn-nVD>edX?a=}M1T_HK>5E_8M|V*l|)n;8E^UCIbZC>~6EQFpK2 z)ll&KbAwkiL^t%D5Q*Ni( z&Oc9H(ce2fXZ}?W2;Sc}-*PbK?1$NAwrS00i{;Bz55%Hv<%Kv~AOz9rH7rp*lK9QQdwrYk2@{#{QMkbe{NWc*tA zcvAA}TIC&Ja8O0lheR(lf7KvKp;93CB+IjALQIMVTfBY(3US(3yv43s9lzNLfiFrs zt}edR2RrY(pHZ$w=a|EJ2nM7Z5;WdWq_sLL9;%p}PB(wnCEqgLY~_LsZ*uj`)6Q%& z@=`tZLzyRrT8$2?7+Ia&VMNUR&nvy#tY|m#@MM%o@~~$WIfIsa9-BSE>EA9tN(R# zQ`0f&`)>KKn|$G2g11O=x1qW=K>o28ORVm-LLUK9;pjwDb_P1JN3zaQe=?L_+NJZQy(C zH&9=IH-}q>HSOLx97PA*WrW#~Af3|%fI*p`&G(}s0JT!2`jmKX+-#e+)uhenKJ(_@ zs|@eF11~*6bCLm#2hX(23iFmjq!y3GE#&>($P0b|N;~5E)ioiikn-!roA=DV4)N+7 zS5dXf{r^4V4ENBuLb?Z)NK@wwkGNzP-Ljf+<*JmL!rsfWAnS@j&-G)FRo&uCimWNcHsQn~nb338$GJ9yb ziooDcBkBba=A@;FY7fia<5I2haRK+VSjK9%lTL!@%^pdEM!W=N61@l>u_6Af8LqFB z2dO|TR2n(4T|2~nHJs~so%Lqgb0XXhdV>V%4M}#udDBl&&i`@_m!yBN6zN%S7OmxE ztDjvYIO7+mdB3wGsH5)%x+~2@5}`PfD!y52hV0*WWL+**p6s@KS8IQdsMJqmsCkLu zYW}U(Giy0rC|_Ywcg~4yk2iF=r=gYsP{|*pYW3S4&%!6q zl@`1z+*J@;QhrQAcOppui3_vZS~^Nv+Kj5G(I>tN(wv(!;Ti1OC>CjI240-3bqbCp z$V$2z<~QTf$3_0o~} z&YU&wnrzKO4l36dw|P|jeOb1veL_}^cQmQ%r+><}n4O7$ZUl9_y!ksTKE!Gt4=$?F zObr!^m7S?lI4Gh1CFwFI)7m+`3(j77BE>dMtW&{~>W8)OpIHMX7_Yq^iEaRvS7Le! z!-&kFFLN6MfcaHZBz!-6fpqR-gA&>~TWyfMF0ZvjAXC}5)QWfQH@kwhHAzupAkoOc z$g3H1IhmL|n4LG?5Y8_oA^rjwAttbUz4g{JN&D?XFRpN!iiG0`yunY#-KhXfh=0JZ z2-#b+DMlN|kcJSOs1dxnbPiCCYIFuN20tD?!&Fah!nU#*vbA_Xe0r^Wn+*M~`4;IS zoAZ6%9aNO*eJaF4C|0i0x*pc7$M@FK3F)rQyL@T^K=5j2M2-z&_fBfidE2o!(Did9 z&h0n*D|JK_*(9o%l}gV$Sd;8=6o+R)*UttiH~%i2gmu(*bx~sLfBddQ1O_gxfv4Ds z@xE*Rk*us!2rFZEb(>^KIJ%p170fAN!R}8uw=6M6Uj$g_n2_Kp)wunpmSxxhq&9OM z8AtMWLBo)ve#jk0Qd%|>*kxL+;woT0f(sB5`^Na;(J6bztlm%@;cfJO?~-7h)Y^wq z77u;-!VbW)tNi~UF}-Th7$L+0+Mzk*xutzPk({envHc8jidB9R9hcgbM6@MdpavlH zrn6x5wN3(taYy|?BFcajg0~~tO#>UMDi4k(0JFzF%aqSRI#>z9z|vjK+75DNDTnV7 zNzfy30>^K+tohlSA&j)|{>AcS_o*=S^VJWN-W9K2TsISBQv5B_!h;1uPn^{bwM;=f zniXK5VD*7VHHw6v?PvAt?hO;CxXa0S3v0y&Cp4&sv$B}7N_Y@Rx2vGt5_~jOFx+=% zQLxtc-TP5QIs7=oKj!G@2X>EM6qW}^&(Rlx&H!UJNKXC7D7JU6L>Byxt`=K#z$nIX z_z`=T$u1R{#ueJh6LcUtXC+Ah+WtL!eebZtZ3!0qq^Oi;Dj#BL+hHUuD+BTKUKB(f zh@0=A-qha_fwD&sN5!4@p8)sg?KDLnlq-FR&(mitKS3Oz$F<nM{0&1b`OFxF($bKhdiY^yEIq{rwK(_mWVY z+yBV-<6H05>zQ7VUW*Y9K(BC_Wg<@lv^W?v;ZgY)N6^LHwr}gOt$`DpP>{IN#}6P; z<4?rdDl$>WJ8InuBLdBW4S}8~X-+!wlezw*9-z_1v)lKE;RvTcPbW^w41e_b#g2!q zrE#Du!{2c1dPcV9C}4&S6w+iv7qRFZgj*j?caN`9@=S)q??~7~OsgqAE@LOOyr>rn zv=DI9LjOl*A1@%*d{$i0C(OP=m8*pOqaMiavK~F-D~Myv#iIMtdITM}Ff7$A1-aat zkqy@`_w#?ZCijIToi2iOVgbV;6MB&W^Q-oDf9&S*8Dub`Mf?TQ)v13XNsB^Ob1|&c zR!DVaf6dMRSzM2WkX(+x4wq+at75bZ0VgwT6BlM(TX_tet$5QvtN3{UofaL3jSJ`) z_?9AkJ3vw&)IWR|9CQ^JEWh@ujbcIQmq*P(yvN?a@i`g`GvZJ9S%8^2@EgJhs3Tsc zNmn;tc4kfq-H)kd83nGsr>hQ90nV#h(VEDMmbBQtl3&i8-aP@I$7>%ldB+(7ubGuf zc=P=4Y$vCe2R2HPg|78*_gdcf`QIr8PQ@2y@7`g(#fUZENJ%tg_zPeUb(_}TBc3rX*YT2F8T<|l?6*&kR!NYqp8>X;z_3B$i2Nh-nz@HQ@o zv{Z<>roct`=HJH#oV>SOkbBJaWvy7c{FJj9+}_8p%E)%mae@up`AqcxT=arcz=3qd zYBgg?kxkjaEr52_NGg!oqF<{9&C2}1xUIY8ApxwoEj}~8d7;eW=?W(p7u~R+|2`f~ z_*jjY>h;%>Ouzov?qv{{chA+wSJB)ry$XT+CJxX3Awd=2qUl;-9(dU^q@^>9wu_x7 zCN$_hyIT{5STN#QW(l8JFW`W_eCS+QY27Y!?sVrH%=zbqyV~1pb16AJ2rMar%dSo$d*l$w50*d~>e+@kzu=KD`@&|qOBLl_5`Nxd8Yp5m zz`pzA1@OKD!*Zue1;d*riOeLzd%f{d*Nt;b$^YKdNec^=Q zHF|IKbLf{3g@wvvDx?j^ULhSU63*Y1jtpNt#?+ytNUca1cX4R_z-sDh?2HI!Q@2(& zynmKcD+v}CWVOrVRP6!=p&M>3q)L+_9lzJa2<*BLuhcH36*1+Vj<2#g0F8kcqfO-+<9r*sWR$&gP!~h;AHF|h`!>%iH0eYDJW=AenQ>H1AmSI_} z22z#>+kNV9c7pn%9Z9P#`+6UcKA}PPDYq8Z2PiQc~Wa!y@annk? zA+L=pLiER3-XBCiXCaY?92=C@75xKV!%EKAL7M-5$5~_a5H_33vOB!-7V#BXC98J8 zOp~XiVD+`SNcFWm&a zlseNsXJ)qluf1yxYU+r>*P=s3M;kDxm62&WQ)o>a3(g2KJjMa762-O@vDgq43WFM| z0SY8yMvIMT(5eUolqe8X5Qj_57;}o zv)MiOobP<+?76%9tx6}sUpP_~1K5SrioZhKr1lt^HU! zW3S_C{0Cg|ob1nI;GqKryfWog z;2HoXWz_Mgr030;L(nro)0CMa@H@Zf#V+|CnGt&-$+OTSRo!`zaTgSQNW3V?N_~8!yU%^FIaaI zbR`KuA28e(#lE0Cvq^yw(7iFOb8d`dpgefo=O+ggm4U~tB#ZMdbK$K$#^b3iSnD^E zdX@zvExZWHaQkkZ+bOrdww?vr+&zs1plI;Aun6#E#aXC7`p8;fYn;g5a^uKEfpZl0 zF)3vFE)GI-rxD?=RX2q~h+3ufgwF|B2uL3cBsEE-k^iC0tvg~&^IfIp3%E3754$UD!y zku#4tNNxY_l#hbK5kYBKF=WM69Z*{CYuHoX6t*)1x|SUWwJ-z?4Ue$$bs~5|;5|s_ z77D>W)`d_;<5hDTpi=4+cS3e{IC;u0EG7vnPM z6Cqil9mtGsD?!hEe92p%L6)rS1tmS&Jyavf1(s5pnmjF+-J5~8kUCB%w23h=)}E!9 zp!I}+Ash47eO)}?LnLf_G-Fd6{bPwApUzHw5$*ta&4c<|`l~S9F{;THO_5(0p7UAB z+jTT8Cu3&cZKM?Ja)>3970rOU;L`@|uuV;VfiqBIU7jJCHRA zoUm1sE9!`UET7Tw6#+}z<_WsNmhR_HCdFNQg7ORuOy7wTU?pxN`El1z4konvt|U

SJ*?a9hBJNeIH;OFPd;(P~M}Ih{ zalSkB(|5fUKn)$DI(Rao&Yx)}${V{Y(cdrLpHK4~lDt&SgBTZ=*S<1mwkN^RDY zFz*-MbY8nFsHx`#RoF>{9RvA*9WVbDuWadR2@gdxJC<^tt=FbcU(Ob1yY9MR;B;KF z^JumE2_U&*)j${UdBlK0C^A0GZxNaitswH*%Z-2Y$8Im3c4w3hbT6d>F#Ro%zuSou zW0fAgDQ4u*viz0aTr7X{{wrJrqnBHQD&>we_4%XgwO+m88svwvmvj$5GTIV4+n$RU zTEV|m#lDjJZzgbNC+!XV_+2E!A6c5!c~rLJ^F5tZZM*MOOHCc>Kat5xnUFR=g&px{ z58m{fP}hHqE)%2n_SUUqJ-X4RmcD3^`#Ynj3F#;_Q4*g8vm|Hz^)G_E5J|Y4zz*GL zWtP=>>~NA5&t0g|6uE2?+@@}ox=;3Y!jnGrd-odGQgBkSL#SpN&pE2NhMWGH4C%U5 z=<>*jJmq4L$8bn5+= zDmS&B^xZZPA*oQRlP9?O@zKL^+PU60n${~SmUJFIT;*S3sJN{0?*(%J+e`q~(eSSF zQq=(`i8?!UXDA%46;?5L)9X_>sTgd2Lx+dntucw-vNF?eXFVt&3Mul69Wn~oK~~3V z(ALpK2mU_7QA+B+i6uZkAGv9z6^347qe$F6(AvQ1MSCca?p!{lEpl~(CbC|%eUJdU zJT87dW9UP4Uu|YB5}HrbHXt;I{~+M8 zAu-;=eP=2^i;TI=oBL=hZngi>-azOD3(8M+&MxN(I7+Ju#h!vg6UrSNX(SQ1tG1~` zc**y8uY5D0-Mr`4Xn`G^g`R(Jf~%wX+VW|2&NA)GfjXAd=-{_rKKu_D*io@ve%=}Onf zwHWq$zO7z5bfsJrLwQql|O|ZuqMR~oGtPnISIc9Hu!w)Zm2De z$9={J*8#!R>mmVjEaa!ET!E%1Ty*1p?_q-%_z-PpUISPS?{NY&x+>6lpDtNaZ)>{f zy>0NDq`!9S{FVWOVVJvD60lj~wZv;u!3zKoFT;v(%7YbKvkK?EV_mcAW#BFM$tLC? zA11GjMorNcy1S*RxQ|vYsOH{z3maZ&c7C&OB=nFnkT)?Ai`TjI)707yR=A#wIGe5^ z>RP_>)^r49a-@vs5TqBw;D-K9{taAxrOdIkC~*IRD%{Vl=?3Zawq^IP$GM$8G+eb? z&bh||ycrHGyAh5hFX<3&>B-J;lNoHN_f6;EM=RblE5?lTtJmMxLO%;QQA`j*Ch0Kw z9r=*(fvWpbjj5@bp9nfKl5&uMTPW943^ zi^Mx;h;E?41iW|IC*7a3r;(Y{^a~K35VzMJNWJ4JHoz=kFMDBnjwD+x#`j0iDVe z&)}u;Kl={_@PLw_)a+|Ia;V2ZHn`YX0;DDr1YGVvJ);0Zie3vkM|TW_t_ey&1{p_@ ziOGOtZj?uYg7?50zZPQ1nHNacFf6%BPvoo*XWlet49)3kGrbzDD zx>IOuaYX>SD-Mimf_-TMnaMCqiKhEcG||+t`PBtM2IL!`8zUX1Ld1iZ>W!WPO~q9MP0gZ=!dRiSSc91{ zRz46k-muC(K562q*dXeR(vYT%lnRdsXK|nloctl)fPUnx?bQjdH2HlejT0Q%;@sXq z`zZzRDbGYOw{T-OO3NA0?%9VRbWpGpzK3BJMo$4PZK?;M7Ii8J_c)j0a1UBJm~TlJ z`G!sUHbq8dnMZe_2P-1I#u28RAHbD72eQ@KAYhywYmtB>m>^TYpuGPWVxCER!EU(3 zd=O?*4F216y?2rF$Il8W(C(ep7;0(G4d2RifetCTn%F7``0zITZ6IMke=rzm!EB5> zlg@8#3W*Rsaa}=@P2n?lrsOtp+C63t?hFv0pswoHfGj$HcFzSY=xaoq9Mq}6Zt(q= zkWOJj`uN&uANUZ{S4mb-CcgK}qItsKAo@O!RP#ym-#K>3@7nExdNSdm zKrdSL5TxP=p8@u=ds4r64nJv zo|X&H4EHLn+Ntb{@_l>weW4?kO|&!YWW_Jym4l&LDn-tZ+7wyQ#nlKcMeT(i0|k>z zUJxmaV`WRl?2e)gd-xk%t;Y^;)1mZ_uyN^ z0_kwn!4|7g=2BYsCJQpI#8=`%kKfG~2Rm(wc;q4B3=-qx;D&8N>}j79@G$|1hEhxE zgm8=_O+)DX1r6tp!B_BE<}Z! zzZv3~KA9n207Lw>1DgEX@kvL|4{5*0!NT+`INT+kX8BSz5YLCOaX{Mq{}|%cZ-(H4 zXt*y+rZSy5N}tWDe3MxT(sL8bph08E-mCDsJr{%UvVmlaW(YKM2X_h>g7ENv46zHa zB~t%s=bCWHDs2|Vj&1cU2`3K(7smwbd~zn86YA13+ClCT6-2p4G^Hq+)#)Y+II_gF zcBAdd-_{epDK`!f=T5B?&u0EURg8n0qm-jI$H7?GDE_=lx!1-Ekxjpth7`33n|F`Bk3{1PP1*-CPoa*1}7;@wtzbL6* zskb`EZ(@oC`O205GV$R0KD1)5mii8SV_*N30DO8?V?Vfy&bzM=@7ykcnyfMCe;xqQ z`=O=WGsiH0d(+#AgP!pQ>+UyCME?$so=ZCcLLrKo;R<`nAN!#^3P4n$W#DIuRi9zi zc&)wcE{VIk{&vHRM1ETaBj=47KN?9iH9fk*?#>03j|);hvF?K-e`_hSlD(Xa^)5y_ zM52(2p;;cebsWh;i@TOludO3Y>XEXgoncz(fnfU__Zj1K<+0;6A(*W;PjY-8AQ0Cb zPaT}80kMiAvC{n|!hTDYzWN8WM1{axXGJd;EaeA|I=e;sSo-<4-+W~*H}fB#OAgSRQR^l%6=#wv^n)y#;OP2E571E@L?bQeq>q$@v@K(`PrTu}IP#{W zVN*6AcC!GBbb<23Qt5F}AfP7Nz=?7O#isQqW+yH0CFO(xsi~OLey57LMq@JH2CCdZ zL^Eel6Mp|y6RtfQ;Ovj$&*58Dbe#IXN}`X<6GStS*wMj1)5CrDl75t>*G)~qVWPjW z5+j;Gb#mw$@8jnJ=54Z71?xvz9KmFf0voXs$u98-;FunGRHpNgN&4(hqO%V?az}|6>XM!c6moX=o34=Ql(6PLUZR zY{F$fgoNGZRYf_VgUs`03Z(cATSQ4+c6?kGNj9*$wx#kIi!$IUH{S@3bHz{W&%A;F z2PB*NDFCaC)5Sy+AVz~_ZXH_CG@6nT0sT=SN6E1f(%E7zWm((r=s`%idVeBire9Mp zh*=Edft_vG%72Q3dp{g&;+ptfS||*3wa@5c8iyFF#`##D_v zv`qWlk|L$7Uzz`48rK5?aeqmvFbf2O=J`#QFLXHL<1yNe#jMdh6(5E_H0;SmTmwx} z*Nx$dSYedP!9MYqKgC`mr#r6*%!oKbroWmJF7xMiKP@X#3XEE)r-xrI@umV_e5hmh zS)=>^=cQZnK5M1%6SXe9MsKM$y)sJjUhGHwIo)FHo4O%38`N6=z>y0jbT`6y5OM^_ z$eWx*Oqdoqx>um51zH>)vfl8bKtZG654(%9ZxSNw;Ydp%bm&Bhgvo8`qr(=9O72g5 zrs6dMXBx7$y#+O3zo^Z8p8Q%#D^OHc`UsOv1)9V;0AMmyn`VQDm^SQRd(pS*L+$&HpSWVjY-#mv;&!So%>0fnn-D3b8;) zXn}|^cG#cW19FtHbL@(?kVlEVs3aJ#I7bEZg(aG(pFvqcHGvVE(N=KJ(0Z7t1VWZmY zNwy6r%0c6e;cSm-A!DK^_7w+Ue%*)!mr}WWq4aLtQV6z|j04`J;bQCk(qKI(x&tUM z{)Rmm`Xj$)eF6!+zGSnZMAu@+{l}%AN!~wXVfxXo<^l7B=d5)6v5-Jh#Ru*{k12QM z9^~i;k3dw_5%SVW<#xQQT8l&461yo;FU)1dfnByUFdD7=L!!Sgo|`dPgoVQ3vY!4q zS^H7*BlKd(5)2^saw@d-X`-Hs07R{ly zvbd+R?~WhmV3{2+h!0z!+`%aFYwO4)!^8=XZhUQN>Z|}W-rJ4>4Y)eH(&Y#-p{jT0 zcHq5|$5&L^J3OWri()n*%$3Red^8`5T8CkZ$PfreYGBf89IYI{8zm24Mk|J$)!DH$ zvY$}zwuKdtd98OUg`#_(x6{HbX0_rlAm1zTaj+C0@>0@!>N{DxiP7IQgY#JeaaWC6*>#Rg(p+@Qzj?G^vpHs&U zojE3+f&a{iS%&i7xJnqt88o?(S;tCLvMk^^-4{^sObZk&B*%`OrIaOYKuYQ&%V_QLx%KXWP2QCw!5lf|)1!eHlP zJ*%kQn7XRiW_7z599zi&F#*pE0&xfiy)f8)YMB)TDF%i)P`L?I-jMyOQ^ln#Yl@Vl zJL_P^Y&)Jlh-geV4MAiIl;Ojr4Wd9#$hhMhF0O3JodvH@5vFvNv8%}{Ta7i*s zza+jGJ@13w^!*Db7|MKeaf!+fFF+=BO@i~Q2K}6 zC&}kDImhWdxuBQ}d|~h_Y6wOLAwws}45};$$6XW|a0&tIA>JWE&T$C|p2GMWl*Fg` z`OLX99H&ViF<#^j=m#~hl&)a|CZ`d25ExIhn(;X4_-Wbw_!7VuF5&|hXw-uRYM5B! ziu(a*{vOLUf%O06J(1?sbWUh$4y%5hnd;L)nE?lA@+r)%zj2KdOgG#_hm`j_H~+Jg z_cB2f7nV*0!Sknkj0l>YO-CkOg%U4GX(9(CU&aCs(C7{T^@smn8lf#D(6jB{Xv(Musn3H(eVQED#-5!!vSvdw8oIZrm z9&Dx{R z=CB?XiqTQPcy^*g3y@&{_!1`iLiCwj0lZC-8hL>QNSAujNK_89n9UQj3I z0Wp`#;dM-Q@26JR0ZS#Q=ibmAaI$#t{mp5CENpv;aWQb^>gF=*c;wBK9-WiPZ3n4| zr`8M2-O|k=JII2sPgblg0eM+hFttj7;N21a~DwVAOy(wX=0#JN1Ef3nLuE}F3J{e3J%Aw#ljZ50C2AscTq8UtmrqW@KUO*u!Fq6b<+F{4XUgghN}M)0RNI%AA(d#pDHBb#*Vd< z#nK=%zPyzfT_rx`4MEI=OVGmPAoQP`Y|fyZJK$PfTIc5s@nLe%a~WsLA)}m{zXLqZ zY90|-ggy}cG_ZEn=mPh@$!Ov%IqvNGAEG=E1yBDgjEEc*#5#bEmCwMiYM8+VL2_Kx zK`J8Oa)lj)k!4{dq`w@zdrLSh$Bc972+|3_xND;=1LB-glNA%9*GXvj`pyjp+k8&zB1Iep$=vVj!RFV^z68!kS6<5ik zDA=v!5X4pJ(G1KD>~iUc+1!U^JWK8|p_$>uv~2NDy5j24cO9=9K)SGR$a|;q5Zt8V zDPfCT9ajzE7cAgeLtb<6{nNcDN$lUrQfN*EC*qce6h-2yoY@W%{X4BZbEptkU9g2; z33Ah#ERb!oZIE900{|YdAd(eqJ3-=(Xq>qe;=13=hu&u zt#D23r5K3=a~sT9IF4c2FIyfDW9gqs!4FI`Q=u_@od}oGlzgDn3>!BU(!_;1Mg_lb zAHt;`FwQ_WbV=vjm?F%ysDmyCx|W1N5j}(N&LMBH^Kt^;Y0l}a85*hPk7({gDZWlF z!xwCh{Ih6~p($1S%Dt~2njGOtT$!WpHGCCHP_^gjNgV%*B{XVU#+jRYj1D}4*b5z6 zh7j7tC@}TgAU}vhrSa!DT=UPHdN2^(rLjy`+#-;yAnAmql3aBiOgF<<8D#N))hBV) zvilQs)l-CqqJZaUSnYvgEEqse!rH)1+gCun-C*(Lp2Z?&**$_e9-MLDh#A!%FP#|OE)qVtvUcO z$eyoLnO_A^&IYD}2B^)JntAr;j-d4ZfED2&sVU3U<9YvD0w}m3-=Zt|1IQx-1xPRZ zNhL)Cyb2V7q;AmWf3N_9@0UR6zrs6=?1a>tB@Y(6#3AU%P+JUH;h^!CLR64}mi}h2 zF?-*3fRaS>FW~2kErB?KgTGqx!&fEV(XR2*-fzDK(1)iX`)aP)uPjkOl3DY*-L*G* z3!iIm8|?&P;n64i;zu56(p%)^54$|x`GmP8FNq@OHRxZp0hMx(;qNyXeqwnS+4wD- zMWAd+XLKWNmZ#(U28jkHo+NnoHmwOF(ta!#1o~~*=1ZAdt)h8%d^AgEC5J`7GUaBR z)~An#AVzoB!`spoB~KvzLA7jrE8>v4AXyj!>Io=o4=!@n%J`3xhGshCRE@>iuxAY` z)&L)ZpwFEjzxLh`h}D!~|MvZnA}-hjf7>(LAA)lNI00ZJLXM|1RM;_Hgn`FoL`}p+ zi3SX>XT zHYO`mQInopd1O>SJ*AW(Gg~PPnXjAnr+fwgokiSsk!0K~wcuw%(YPZ5$?G>OMLMsd zs$1&~B}a7?n8=!fXd?9^_-%Qg?U<(|gNM=N@zsFiiFvndteCYC&sb)X$FqM0BHzoA8WXL0q3<44Kury=oZj zM54r&p=`$gOa-onW`pGMhv@(sbhh#xR1oI%0 zFQ&WRma!}DY)d0JQz;7}=N zUsgCoeQ;}#xpgpr+`nK02xr_@A9dzUPem2jTq7XO^MJ!wSQUpJQ3|sVMk7JN;r{{g z{7%dcc7hMMYq`|o6#b}KMdX-=&9OmO9DBwIMeo^-iy7F0LYfW6Eggf2xObY0NloHr zzxxtzRpBEDwS@noQeA1SDUkxULRTumK6cpOYIW-^ zAv%nlnMe~l*x|mb$2Lsd$D$(Ary17R+MMt_z`l=`^BxQ9=^=v870&O=p6MsKgoVJF zsk!9<30smY`KbHb^^Knk0fG{6dB>!F^k|T(7qu3v;x6t)n)2I|L1)j6Rvl9I`@;=T z{TrbQ_Ywz|Fa#>!Zu84w=u)tZsdan8Zpo|VhkG<&fv@NsPY|UakngauiIk*U@@qN_ zk=!1;sCD+?p65KVk7GJ#ixLLxg(V@*2l%e+9+2y3I|>BG;oo+!?8?RkStElPwO=+p zT{Usgeazxe!@5>mKH=$3+-p3q1}c0kww#5EqDaXcTu*0x7Co9iF$Cw|D+>SQryLEj zisbeW)3SnCUN-m zCrT{LN=9tVJW%TDYK(Yp=HSZvtMAh%hD&pv^M|X}ZBzYfz8fM%tQ3f+{uL2FFE_s} z2h4WlgPZnZ-*aR?{?u|>K2H)ryMNe5G(| z^7(U~$OfI0RohnvEaZ@zmn*x6Yho8f!;a$Y^vChVwBGZdCr48$2ItAHz3kPATl5V- zdg`7n9klJ5x-0i6Pilbu&*B~v2QytE#;;^Zr?>THpKAwp>;n%3uXA;G8#Zm*`i1ht zB=$*yzuW+iu#l_xT+}+mITUx3cLLlHT9!I&)DIP8M@E_xwAA-5DQ_j{7r=L(DfkOC zyZszq{0S+`6Cc`=q6f5nBYIcdpO^!qme?(P6T|+ySxQFf2DU{{bGZkYIsOPS89V0}s&&-5 zAcH-w(lB#6B&X4iH>Rq>&D>fDW#D!*Ij`;b42yz$y96nm0IhMiwB(gh`Z2DI$g;X; zH|>K~wVb*Ztv}#`&g|Lw^%f>dt;*SqVWF^>RXyWt13rb~WqJG+6n25S+o_HpJ~5;N zOz!lbY3Z#8aFpF^rq~)nI~jN~WRBGgm%c9TbvxlJnZKeae%;r~`C9m_#xrB$u3TK6 z)R_J3z)zE4fX$M1OCDx!T21iFfXb2J+wQj{EuGFN=t9zRhWJM5EP6i4A#Qd0h5 zqxpg-(!z7Tjh+H=FTUi`Gy*^zh%pA0dl9`)E?woaKHfegyOQT&$5*oR$8)c;8j|_3 z=)_55J1ej8OgrDokRt-ZQ71?a)qS7B^+HcUBeY6~Usn(CH#R`kSa+N9=siTbhy{MS z5jjg3`%O0VomWQZ!WWDY1~hz9T+kdGQ(MNzp`WE;i?g2Y;bG#1ETrMJjbpLu09#cq zs&hz;_~siIh0{5K43+rX zwK~AoLiI3rrF_TFwT30F>-H;7ABP^Qgn9OVVWM>FRWPjU<2daxC0f&YHtmsi-1M(I zw96Ttd8>7w7`zJF8`sV<6rO%}{9XgAJT;NrM@C63c2xOMB(-{U`fqv4eK7f(k8M%Z zWNxa{VCP>o(lgCt3U%;uE#C+mv5NBO0iV%HQ%4I&y09&J&*ho6j>?lXZj5Q=F#O|- z<+W=irT-iLaUpEt!1X#BGew%dQ%b$9CCUFhFHG|H8D!#-H_ncyruX#tx+QOEDLHoD znszj9ORm;*ZJUlhIJD!(7Vlhx>n(*A9yS{9B;mBW5p z)c1$C^QSt)mZG~U7fok#IzF5QF&|o{FQSZ{zvjpU7qc!;Y-QvVB~yzsXsAd z*4^NbaK<3VMboAgW691iXv1*)%9JYTH~oQR034-OKUuMM))Bol?z|%Bm|2t6<(oTF$C3@VF74CbtEEv?-D^5+JDQN*C`c`+ z5tFbKGCvcjtfX?NivRS3K!MN5hVCg?-mk)7lc^ozn!V1U}2Bdp_aZFSM4wID7BqC64Q2p-WGad7|aV zIMvJhwcoqwTi7A~-MgVI%Qmg9`&CNXb!u`m=mq^6u_rZBg4S&84A}<3N84KEo>k0L zma+)XHn(v1x95uvWt6avy6#N<);_6s^RkmZ^}{-T=>k6KgEUS)QIjpMOWnsmK)abE zpfOTM?mP-~Nc?)dHi^ICgml)}qGX_`xHzw(62Xef{q!iB z0`{Q(rpMUsuVo2~^#@eu7a+)DW0v-ypwvwEHkBfjnZ~qjfsVKV*3^Ut!CAh*$(ZXP@`Wr zUay8GdbKPbFj`QKFBv!56UG^v# zm9y|@ZW-O)5AXf>W9_&Mt9MsZv)^K6n%Ku^%hhF_OR(0&o7syMcCK5!2luli#u{gt zElcp&Vejw&H(W69H<#!r(b~&ra-U@eWN!vIn<^Lyh6oy~M2Xw>eT#m4)oh!4v*?G3 zqIN=EwI&ni$YEu3@wRsNHLN-Dxt9g+*OFS;Mk(I}O0oD;KRNc`FXwf+Pwz2atO z^L&+4B8NR;7En8nhl27isp7v^i?&QvJ0H_gsn$=-Z@9j|Qii|UbGa}weh+g~lkoPs zFNQ}*>;s+V3ot04q<#JRB!6>9Xt*3wts6N!lq^I?-&vjb6&NpO z?Df?}y-nR&RaI!(x~7~^Ev9P%Z6U_TJc>R40UJa%0xv0a=Bms4@%X@KRz0p==Y9QhfNv;`Df;-$<+j|)evk{jKi;U`8Y8(n2c`DffsUI}Il#O)u>JTZA=NViD%1h{>{-&S|)~ zXyO4CC~IXgT?RwQdN{)y^#s>y?}bJPQU$NODu~Iuatl(M&?v5Ev^zbt%6|b9QAz}R zy;D9MLR@%@%dXw8lCL_&ASElCb8$a;o~_fJC-A4K>F(t{!|YqrD)({6hyEBX)sN2w z9nljFCxrvUZ0tZx(sIp9%M-a;&|38fo(a<2a>uu8IsnsBB##)~X@*P6w~_j_J|2Bv zzRS$MtIn<4B`pg@@foqt_gq0Aq5a2VV#~mS?5^l?(BGyN?ErSH;l&Li#7e!ai}XGz z0z@~U@T@vACqd_n31&zBAVI3dVURl8_qv{{>l_L6M^E}*O65UcCrysse;2cE>BSD{ z#8T$C;RR{g`Ac7`b>rpN%ztWnsw1Qx8ByK+`uI{%YVcdHjm^S=mG#Rfwv=Tlh4*ww za##LZjC*vw*cA@U2eFf2vQw#aTekKx~e^se1exC4o*!4>3ByR772 z`YV(R&(^5Bxgi>$1wsww&tBKfYsql$su|RC9S@uWRWDd=zPX8r+C@4Ii+tC2CrPCw zN1s&^L5&hX6^*GNUy5zM-0`JiOvw$W4sU|oAgq_};omW4lGRfNypGmh>lq+l2PZFx z#aUK}dYZvpo({DH6a5EEE7bevA zjsj5#xq3%(E|+qO#4!sB5u%};uuG84YQmTX>3hg&`l|M5h;{J5;dhIaen0h@CMdsr ze=D>u--7zp0yr$g=9aq$VsQ-3OW4)&T-`1hrpved??zq=qeyFC6y;=-67>5FJQMu6#^~oj&rA0i=02qXQAi+Y4Fs%wZE+GxDqb3O zkxTacr<;IY;Io>T zv1L4Sg-*942{B?$tbyiuAuYeyZ=6y8r&gKw9p(!ZoZjYwS_YO+GmugdiEs?(7yfZx2Bka!O)Jxk0vz$c^L z%HdS#0G5LF#hjyl=70f{B7MiElV<2WvXnV@Yh+a*r0O5Nj~z9GF46Im=C&CpMx3NS z#ZV$;=uVyRtJ3x(1!D=9?d?=V`i@0lIgDtdYd|DmkWVOHzG4g6|vC&JqonF8( z>F}vu1OTX4`gr<+ShLCg%G75~4QAh9@0t8k&iDf?*|EmbDio9?u^X@5n_U*8%uK7$18SyFN{UuHbF#q(L7p-fHPM=)2=0^H6G&n@&|Zn`n|WnLc%X+4!aj zUxd?IjXW3f9%-MHbzKL_`bMlTW8Lbd?E6Ydm^%f`<5sy|HW5bqKZ!H_+(qv%6Z=;!8GMMVQ{(QhqQ7*_s1DW(s%uzJZuG1<~D}(BvIJr z;A&R(9a9QM(@ZX~XT_E|NsyApjLytx3`*L5aYTQwTA1kD=EY0l9u|*<2!r;|)*1LV z1NFne}=DRLK9a>s++)8pg!VSh}%G@)auM5TEsP}m&TK7^JQdugF(OF?$F(+GS(o@ zHYaJfUeP`1yL8`}J)GYAydeMzpTefSy0Wee!}i_<9|Exs_=8SY-OnPoFR06VadJmf zYyQ`l7Y6^4E#>5-Aq*ZPTP-}#09=CjS%KeS5~5Dfi44K9m zWp!od&8ZzXU$KQ;EOC}$2nh)|Iy`^|FGOmB30p5dkX9}55MZZPcOiEZoeB!|_=e~s zK$8m@YaBOo_2FZs8@P_5UCBZqRRJN@7%(-6mXV21<>G8kUsbK0695}?LZ0k z)_g6Sg)X>2iUv$L#AvH=%;VG5V>D>kp=&=S(Q)lAKNU1Q#|m&VW-lDM7~Z#%wgHw{ zLyJWLH?wOfQSG;%T`U)gj%AfWQVIvC5sUwer?T`L8z)<+2`E|$|0Dv6iT-CX6CF#c zg2!Fn6O8uD7c9!`K@aP!PS(AY&`kvlu4*)1^M(H!$EC=qx0JJ<4MlKIupr))lEgsA z5ZYXXqOrM%BIbTLhn|rd|E>ik5#?Zm3LYfZgRMM!5(yiCz-CYIYH5b&9zMmdbp*}& zl`bC{4T0K0a}_&@-4e%NZ-QZ{ef1NqplT@gCq+!|KQ5kRTPAV^(V zf`l!tm%xXXHO$a}Z4ds9&#e55j$E>2!0j2C910@$-LED{{hzb?;2jS^8!bcG2^BHM zUKpnF7ykN~j=`$*XQTS_fVnug%s*t#PluFBSx1+dQFQrl#VL~oiW3d8;#bQ80t@0( z!&f;kLb3VGEVo)!0LX|q@A_F`==|HR!&_4zlX?v*u)^`%)4IOapDWJf1bLP0{PnR2 z#CEotKUkq?zoih_FdH^wIzS&`mfR$umB8w zp;9nRGA(|<0vVM;^o+v^+s40LC*eGu21iP2&ZkeI>t9+OgXCF9m?{@*?43v;PNZw( zU)QsLG!}~xzQq7gEG~Qz-#FM{#$_)ZOsI!zWQ~Wj6GQ5BVCYw_LX6NA@DswYaMIBK zXL1qqR=-F*rccUv_=bvjM<;!ZrQN)NaW6752APML+H~ZG{yEgz>ngkhB9_tt#p3`O zj9F@4@T5ggu8=)8n)?J|4M=XJC6H~f&B2*-3y>C1I>7M&s-r>%P#!2XelE@{Oe+&w z6XXcv`wo5%GrnXt2*el%nJ;e-8b$unDS{mmPq81|T_nTM5cC%qXngR_Xdhh}X)dEa zNa#iHzH~y+8q)smN2}Trt0pRGQNGDNo*`?6s(M*h=*?j?`}M5U{*MsNS@KdkZsK->Iy!!|k+610e^|F)h- zOYvP|u6E{#YXN!XOzoe2^E=IkKNHACJc>T~^hb-@&ex0tVnBJu>PC|pE$Nbg!b+sz zY9s{;4_tr^?YodHi-gbOP3EWMGB|#QA3!cuqBO&@P_F~YcD(EvRVcNkKvlT~5!QcW z7DVO`fG3kSG_4_sodjAG&AB#hmSosg>=0p*&g(OPR16LwE6(Fw!x5C2 z68)3j^v>0awG|~W=+*7W3Re27K7|4jHU^POthaio{Ae0#poC>KtxNnwhB*0CE{Y39 zT&cw0FmG5JFE2g{P=NR3*PCk0yCw}mWZYO+#$7wVfQL!3r1H`vM0vo`y(qrtr6+F? zXf`Z(S+ZdR8h8VB zc5CIR$_E%1bsxXn@>%ATMo!iN8bsRG$s94eTsE9XQa{~u#20MX4m!~sI zor+;|cP}X)rl=BT%k}zn^)Af1dAy`i7O}GrgaSU(6?xJIGPS5!9Nfb;zwV0SLHuDXI$HX`73i&DN$gW68&HB(}THw#awtd3$Snwf8@=)>u<;GCAPtQ)_7&!`k?umur9b_ z^{?A_p!faB%qA2uS%gQMfj~RMH}t)X8_bupK+i_~67#mPZirZt z|K@R&cw&|I*jurTjys9YpIUPnVDycwfS@5HbKcG@5l-y*;a=Hq(``*4ap2H!zTLlRfu5I?Fe!5>Br!^yv;v7E?|ai@ zBm98ge2!NccAH<8ny8Jb-@N@_T2{FYWrt3VkGCfh<@?RgcqlGgJ>zM;ubyzHGt-xDvOPL0fQU_bh3 z$e|R7QQ~6WZ9G4FHKFD}sm|MB@KozxQSJhhFAtOQp;ib^qQ+ftXTp1wqhhH!qrec` z=wl>$r8d!VkZ;<^~?b3vW4Wg6+$sbNF#>$miY}C2MOm z45q)^&9GwDpq;^!<}CAtOpe~T^!(u!Y?O1hvh!EM=t6vJW?ceBGURV~civ?1jAc0F za!i+2RgDmt(D-ccMxVUzI zz$03~2y~>~Ise;HQ~zh=(8)Fh@A_X8Z~%f)zN&vsx*YjMx(+#U&&4b*N5OFX zC9r%Ud%!o457Uy=@dc`XNnO4tlm6DmgMe7ldW=K8djZuYvc`}wZO+naH&S-%3lt#@ z|NODkVzO#hvjBb(=8ezFwyi~ELYW8mZskkp?Jq}WNmBZBr;g3!yy(FvUZ5Ga@-^&s zVcsJy6iud;WB-P&ySsoN)Y9stxt1WkYIM!RLZNowAzX($d>vfJWgZB{gwW0-;%6>qH8t|@642x?k$VyZT(2Jp@2-n@%Od*P3 zkvI(a;MheUs_tJL@b4ooEc3>aby5a~fz*uCwKBU9>935AQ^&IUL~N;0El%b?B%7#Y zwSX^bq`1~^Mnj#ZR18*pY%;~uFH#GpDPn07rIo1^=had;db|k1$t~t{wBZcRlcovB z%0wI*LZlTa0e2e^4FneeiwN1eg^Ptk+yCaKkdc=lwRB`|-{<=@AEzJ;Q&W*S;<*RT zAP++tf?;)Tyl_Etj8Cl!Pi%i}`89$swx~LwT9dc>Le~9mN72URU)6S%b@=Zo$HZrQ zQokV50kArVbvo%_8|CYlgg_6DVQ9$TigR)*KbzlEnzxgaFw5GmDsUv0)_i~#*%E@z z%y6xP_Mq_8q<1VwtGEie?T%K#tIW5@wu3+;W8-=yzF#}EL>fbNkU^H`lgWkz zk)WJM>kZQ$-qa6Opj7av^52?}iy*=enDMa{g^Z*X(g8Ed4vZW=@U4_HP&j9Ny#YGZ z>dOu3nSh(wlJtoNaVg=OslDCUPMq4i(LZvyEc{U6ln}JbD7gB(-CzH2O*FRyAC7cs zd`9glsH-IUtA#nmyLkvOk%oUZd*5A`f;cOBj9<%uU;CJL;&x*Q?J-0$VR!ae`_eJ7 z+pT}=j)t2vrf#BADy-H(6;@mRW#n+g5S?y!C9nf@-)w9Z2SL<%bBIvh*yL*;w0RU> zarO32WQu*#T5=MpMMP2}9cJ-PZwYqZqwR|$?k3Q~CLq+n zAIncGG|Y?lg=(P)Gd-|nH?F}$2k`rNzbPv*LtQasz1Fh&KIiV{Z{E~*3G&o!nB51e z6|!)9CJ*WmNarveULZ4TpwwMU8YG+#`Q?P3o+l3}R9l*atIi&BSu6vgKjp4<+u8Io zHN<@2^+BK5L)vi!ny4+pW|*(vvc#dts`t|=Lv#83w}YVQr-k6{ipE%khqL$F)kQBDD+L)j=ug3T$v$P#W%v0Kk@ljFi|FIsh% zWmjoC>-CU#CvZ{b_;xf$3OpY~7T5rlF}0H~u=OLLR9mr1Z#u|3Qtj4I6vn3N?9h~o!qATL9)qI~)J!QbII{x)T86=)PO z1j#IT)XArN`dm4%>ZPAM5&vKBToM04AO&^a6cNcoE+Hl01w3h8c~)_G*cy^Kq7QEu zE$F)5I|@V{;UN9t&*dw&KxXRPKxRn~1=qSY`|x4Ri&RoUlI7CZ>PSop#l3X-Ir{T3 z@aZw|5r4iNUrz=*uEjl7+lhj+Tz{FW{tSoe1li6_{j4;$0s$LpbP>k|8sAZQij6As zf!Uk}uN+iZj!JoVf*CC0D^A`_^H~X#$57IjEtOr!NLi1L`xg}sVVa*Xu~bq8!(z-O z`hvrLc_{H}3S%$?!S7PHwI4(U#3T=@y*-T@_i}<7>G;{qT{u}n=p5MrWoN90lyh!T zz8eNVl6RxI0mwu8rxwALV@aNWn@pQZLWuNXRXda*1}m~u3tL=w2Zln3LHl-rehY;& zG8)Bnr%k?YR!4kRB$HB(?;bDvK7ZRaSOO@P>%G6&In{x4AZf0B+stP-61{}C>)UX~ zK!>Ar2Nb~s%!{L8*LzO~+Ua2o2y{h!BmOBwd>?8&4YwnF#lxbu7kFuQt9gZuc%f`u zMa*io;)WZTM2lP3qV!O-4BUv3f#jUMwZt6oPRY1Rc{;lxrTP;)zU8Q~{f`JlX(x{i z5(gT6g3Yd*lGQfzm1OD^UI)5}PFODsC}aTGMqDw+E$-g5LJ$(s*YQgkB$jDoJ>kSb z^Klfyv-}NPckD&08fdbC4V+{exzj5y15pT%Vbd>}rNBoLL=Oz&z0|U{GfBh4f}v+A zU?vEi<}ESaz*Kf$`wVrG@1YL8(dmjBKkMe*S8^0K(6I_?rZ8D4RD{SwkLf^8BLP3@XnzzpT@xb4-1aS)BZ z{kH|WF`d@@;8L>bbdm!v0|%%TOIgj=-JUu@d98B%UwGXL%dXmPOPXU>P!eL^JhXe2 z6JGnv@7G7OV&QOO- zk5^+j8E@w44%&g}SX|ZMtdtVjzK#S!8_sxdD-<}}5>Rb^)y9|Rtl`pD2n%8Bb)~}J z)J{(i5+2UKS%n5Mbxt_W2tneN0_7wi#H$SFIOi&<97{kg!fZADc0m1#pIdh#x0$Vl z%+P$WhH?CW3$i0oO#UbRp*U!^kItzgr|4KWfoND(`Eei+sIv@=>9Wm{ms+|YW9H7| z<)%%>TVA4vj-Jc>Ac!WRC^9zK`&>$7)geqI;p=63hs3N(3_z=4bw*lzSle5kIk7>3 zzVEE*(E)Y;oB;1|S#bTX_op}#C|}G^gcBrMU}Fq4jBro;tSuWzkl^ueA7qBDky{`p z*YF;clOsr7LU+4}QHOwpurOx{YdBMwz5T^S3j&^yY8uJ`8(H}?-E{O}xL5w9;Q!apt49#NK>C1o+NdkbFwO{Ku ze;+b%7o`rGM|(C@H1%3jp!|t%F}WZ(h5x{3Szk7eg=PNumSEXiajViw3U#_D-zjD9 zuDq%pMC~3!u4l(7ekVG?wT_Oh#`d9r6jq+t22@=A>Aj)m90sIp{?@;5W0MN;V@^xb zf*=cc#S%Zt+dAB-iI3S28dS8`Gop*xB|^|(6RS5=1Av%}4)~vsz#a$J|JCuNsbbdA z+0K6Rtptb)fI}OEj-KQh@nBMozucYIZx{y9z*5& zj?SB_Wy{8rKGYDvf34vh2(dSEC{Y`E^=+jx2`6 z*n!{w`%bK&5iU|~Q&JeRJ(=7S4!!pJ)WA@EU$VmyMIRpnir9fe_q=J(KhvYs(Qg68 z>^xwJ`9Lc9t8xG(Nh7mkVS@!3QQ%XKfK$Vjw@9fBMy%N=*;F~!(<7fdza_={%MFvq9A&rT>A%0kx#!2VsKLM%L(Kv!6w(qQo8=*yytrU3So zel%DECMXz6MN4ZJ;ptt?5d@+LzLAHWRwp56Lx+Sf0LY9s>uSS{10uOWf~Roc97o|@ z!=1zny6Iyjrw}O`-*@fg=6%TD9EndHkt%94{eM)wcOaGR|2Tegl1lM-9$8t@P-ZB5 zG*FpQ_DUpK$=;__JVq3uvPwu+va(OvyPWKq8M62Oy{@C@{rUd>I(3};y07bXz4pw4 zsN3XPF9rUBm^PR`Byy60@F=+W;SRsP*HqC@X2!UGyceF-kI^MFF$Ke50eKw}69BIx zv900w~v-S3?&KZ~#s?AzRpt=J1eR%p zlJsWpQ}R!enec)g^(4KwF3TERxV`-&Gt0}bH(4n$qb4_D7`2SZI1*w4vcT#f>4sYW z<-su_R_u23(v9t>J{^tyPT=Q^7RO-%C`a1$W!_z=8G1H-tpc(}EP9x+hT>iBIkVyd zOr?3GhY52fBQegi`m{o|M?(&>);ON}+><%W%Y1I>!Gh1eAvKUy&SU^_j>r=e>eRY_!ouM;tdlnNCAd?C4| z&&IyP;z%;N7OqeN=Lvzd(MzAzrhdZ$ym`RCZBMpSGI)XATz!x2&~A`%z_M+EHWjsc zkcFCrJ2@nj{0_rA3z!r@Jm!8S-FY1NQ4C<}?K4D7A*5_MK%q@!6!=>GK=C1zB=83- z!zl2wZv9OQmKa_UVUko|n=NFWiD87y=(v&9Y=oFtY?1{l4C&3uc|JyjosxD9u6_S> zR@jQq5hrKM$=?uVCA=s8){nVOHV_Gs!)Vxn0BHwAYs)J%7!4`CO5wMS0ut|-Ae(5p zf$?vfQFk1683M(cu*1i|hX-aL%s_%2ZD&d1|KVm-Q2qG~QJGw)Hx&415K+zCi>>0& zo%e&U6b&aOCEs%uqTo*eWaIw9PEO7~c7G7aiU{Xqt=@me;la%6_~gt}9R)twaWKA) zcH7-IB*y}OL&8Qrta=EoIs;MI^gJ=_<7Z?CBLtmi!lLp(4~g{b2>$%y9SwmTT6J&2 zAsNsi%kpz4)xo3QDqS~cCOuReFIdlGIxs^iRV6QrME;8nNk}D|gHVq5A?Q7ic4Mq> z^zWT%xS7DQw{id8>wQXfoBRG0gheaPEArm%Jb!ZM>EA=~j4Lh$MsC_6Vvz)R<=tt0 z4^U_jPOhF!&>+(hp-~L&Wjw$4F=Q!$uhxf@9u-AtwY2GRPQOs);x%M1bM=wws5fPS zj)HD@Gr#o})fJ31CpOu+V);m94WuMhg;bm}{C7;lL3XDU;`=22h#W`td|2SE^w_aZ zXzhe(X1jX>S`C<-fkY(NAAlTqsKS8!q58R368??(SI_P=#g!Gjd&CKOOF=%eU^UWT zEaKXW5qwCmPEL`%L{5ea(p47j^;Pa%9Um3=ieS>D4sy#t7I53kcQ9ejua6^+CY}*8`KCk* zhsXuTCY2vEU~-74-ZS%~webwlcOU23~H=fY4Vi}9YFyqxFF)nj&R#aN}7 zbd%F}q#q0Vqf%wnqgdm8}-F>d6R9J>`F> z9==iZn{GvG%m5qxhQN%WEkBD?=jSDhVgNrAO%ZZ%BEN!sXV<^07Jp@x9;KJ+U00Bi zE!4VbZ~LUcsH?kS=^s$eA%R=ZkOedOg5>U}BM_M_1fD|Tp^!QcQ#47Lc5|iaF{*FkVG=Nc%Ef1n~rx%Sh8zHkrF*5vyi9!s#6lnn$I zE%4ak3)fJ7f=|6q+DWG5M9Sv2PZm@Mh*QIitqa0gn8|W`SYrfm6mldcAtrM6`96Fn zAix>pDXphl-DOCg_E$*?%;9e~23kmdrUTiiFy-8#{(iwULz9FLNjJU}i!`BBsT zc-`HC05h@3T=i(krQ<&JA^x(yeBAC~U$us~|egJ3&=MyflVJ1gOk1kC(RTNSk z$8M{ya96u61uZ=M3aG1E3c+5w>w>H=AT|RbmJ^RSkyCd^)?;Oc*cP!Iyy5*WKNqG$ z1qdYaxH!JUJ6?LIiN=S;s<11wQq|!!ewhY*PH-4`Zg+k|?_0MIp|~<2?q_t^@N9Ws z_i`!!DdxsIB4G}0C!iH`?{33j9Q$U$#PXf&h|QVYOZ>`2cuVBP(K8r=sn2QaPC}h z5X=gcV(nZqF=H5p^oBcmoZG(>bGaIZVn>^e)}tr%_N}=xDwrv>;Xax`jigPO2K2;5 z4_iY_AVHZG)PCrAZb_fD(xjwaLtIv^Fc)yr_)EmJZ{=KL`J&s>^MB@rem5VP{R=CENpU$Am%aglUur+_JMz&{Oh)v$H%W})PTNBarf?!Mt4ol>KB@(+9tq#!;qTN}NzU#BgUXnW4ikmlJ z_nuU=W)iLayR+*`+~jQ~J`Mqza(^{SOFkE$WHziJSu1HTrv5iN0sYbw2FP%ao8u1d z?6Q3~eNRpXdQlW^{W$*R@&1TwiLYe(d%f3-acI!Za^Lte6=8GQ*RgUhUgIyo$xnCK zK7eU6GAa?=K9SQ(KL1HiiR-v*oMIXy!=?RcKU&7N>b1E(aj0oCSjM{d=eds54~kJGzAiJDrQv0!)+6H!KH=j5`(S93M)Kzs2{N3Z zVp|*0O&t691Fp`b6QopQgaoEuTz#`5+1EdWopXBT2X6jTQQSkhqK&&`r8J>semC`Y zyf#DId_hCj8hyS8;}w4Zo(1P3%Bq`W>S<6$?m(XfiO>Mo8YO5_x@M@zyIORmx+3H0 zzoDtn_PXd<+vCDLIQ2#MZ^!RrI(GqN9~(eQH(qptTm#W|S|4i#$1Wq!3$a#&<}q61 z(jE?t5S+^x7+t6RcecCYw)>5d8vUDG=`U7|FpfN_7d*FS`rAfh3B`XE}okAef? z>=mBJKZ|=FZCcN4?pypteK504O1VE_iWTs%r$5nY=nBu^_u~h!`+!QIakkI`)Xkk7 z)AnM+sSXiU#!kUy4|{$bu^b+<*SFw_f^r70IQ}vZ@dIuXMvA{}l9q;D-?3rCCyB?Y zv504K;A=^kit*2Na>6*+^GoO+P3Dvk9u=pxwFJHvFn;W8LJv2z!ef;@b41Vs_O7-K zGXjPlQefgRZ1(qbDufo95d6v8!&xoq; z{X@k3rr)$_YU-4CX})3d4sBg6L;!{$PTa|>?FV>mh( zr&{U<_dRnwG-TRI&&Rpx2YEzedtoFSj*wc&aSK~9G*n!^~0aj_tM?^`=Q6g z&8RAF@K@B|{H7*wT2+`;fyx)QtKRbI)X6R|bY zS0uu=HnUMr{AcNnm}2!^=$dwc1Fl5AAT50OkY>ku|#uk?;#SF#oTT*}-127kfM3d&v z#;Fz0v-#0#kL_&t3&WcAuHmJb-G{iWIMkqfU_QHj__!2BU_7u{wxpSKs;i-K=VjA1 zodlj#b{oqi*C))JlmEnk!;{!ky@`vgX<`yJT>{a2`{)S3ll+_@w45W;x@lF@c$aUm zzJ0N}kea@^E^KD@!;IiCv;a-l&*c9>KI-PPRy|t3969uC=4@rgq%+MA=)M+>P_Xc7 zt3O)+@Z%;sfu&iqJ>Yi{H0~cSaiM)lTOGQgH~o5A<0IWf@S<0n?w)yJwnSSEexom& zQv$NympAJDw4=8iyPATyo2E;ZsIiX&h#tSYeZTOmPh$H=)R8Ef5X36S%`3NJ+~th& zTr}<_xxJ_VXzjd0T=DQw1YQ~zs2xZB=uZ5vt&uA{UhMtM8jS|zNgVudaD=b_AW5B< z$CfohK}Ate5ZgDkQ5*I8wUyIjsbIxZ9fkidvymSBJY|aG%?7G#7ATv<_PZ5MB?fB8 z2s32Hzuz)H$nL)1%aJDw9j|fp7L%FWMBLB03B2mL;_CzcJtO(RcaH=d_q*cf#*rML;6XX@R2llx{A%H*R;*_hM8EK!o(R z3%xCGV+NyR={9y`k%O-J4AcIlaSn>B4>sE@``2mpt2oF7a&rFx#wM+Z_mnDeJ#L08 zTNaCs+cN(?rV*~s0~VkT2Lj&Zi9-T9r==Gw$CH^HRrJ9E#bG_ zYKAxi1I#E@L#6qdt*o>*-t*wP<(6kl%MB*)ys{qKhUV>0?`tUpJ6FcZsWGaHXoFWk zTjH)Vd)FYf9n&Yu^5nv$1L>u9?|dlcv-Fe_s7c~F4yRmul}}o`)H7H|AGoIyQdus; zO=qk`PBk?94Vu}2*rqs&ZpGB2`jAKf(Xx3)WzFvG!pvK zb1My9OK-;Oq7FJ`$z#FOVF+tJmPPMujg+h3doh^y1Kj~oG#()}40nK>QObZhF@vC| znqg-|FPsk_FB0GHD}&S-B+>5~J;Y)qKNiOt6}#uOB^}$S4`HXb@NsjRF1lj>iZAjo z`1U~-5I8%e1)l^Cno-eLiJW_GF3OhJJ=-L_S?$$TsG~D-p=eSEgy7ucdl*w+^H9D;u zNUr*MwwuN^bNvBTybdUOQtR_)rQ`6PpIsksjckq^NiMuW^4=6e9|-6AK;FlTouu;a zp8Hu_Lz5t)V;1&|psQqYpr(GfZ71IwIIugmkl1&*`6O2nhb+Gl?9E5Q!aJ63tixO$ zi?RUZ5NrnIFgc|<#!FEb@x`n`WlR~A#Cb90FF*dL{FE$k-Fd4dAUO8QZ`>`nBmu6Y zwlYkdty0ypZSDITble;&mm2@A? zn2hn7+6f0gAe+Bt_wLN2Y8%!_eC4&2q_MVfZynVOBTtH=)v8`y!m~*FNSE(=E z7&jntlqOm=GtY&ytqrIwCwoL%nI)t}C$z++sz)%+HiK)s!|^?h8zcssP0>C1=L8vj zYnQwGQ!g2{=Cd5^uv6}hdh;d0pwES~*-4B%xguX7WkV7z8Uo6(7D$t!?F<&ylhK0%L+c4@7vl4t%bTViu}-)*;*NONhTsSFrNken5b zG&VPf9xYq|^byR-zTZ9o3dFyjo1wPLRFmmeOShq7R^DgXKz+NCG%*ocPR zyD{Uow!{C-_uNwBH|kyf;oCVau+x!K7R25E12=X?~miIel`Z&%>Xj1jvmI@GSIL2e@LeiLM{u_cWS0R_kz85Eno+NclHT9@iH-X>a(N-6+#d#GVi|DY=qa9-ik zx;r6vCa85a7sTochy&M{+CPRD@bywp6`!H$X)npX0Gv!FgWIJy|~L0n@<(6C{{F_eE|&huq`HQhS^fH~NN6i9b? zo1U&{J@p>ukr$|v2^dXJd}UO|yFp`U1Md(q+aeQe7Up&qeso$hOjf~j1}lzp_Bodq zG+G^6zpH3}?p%5z7HgW_Y;d;pV2sKv=@epl`csFE>x63X2+0>Q%L z(c;B>qaK3^QEzlG{Q^T$K85`R>1eorz% zfr((cfch>=J1RnbuR(I4W8unJf(NU;Pco>nZg(2@U=+xBy>RXeUwX@_rtyE7hb_OU zz4;ub#q3K?SZG%wN&E$}hD31q$$Bj3V*=7#9UhVV-32_+MTb8Dm%|55TBKpCsd5&FHF&HxB}X-A6SG#aJQ_XX@Mi4-c7P^mSMH1{d7i zpJb+|QWA`t$RO3>NE6xUc}Y!NK$v(W1zrmIV`B4MdiErU#pE@aEew8XyocX`X?ZN> zmQo*_{wA10BS#SD45fvhM=-ipMaS2>?~ywnNSM^A+Wph0HqJKP;@O7-|-Y<}ZkyQ^tV(N%jg zhd53ptS-@Ff(}3gp?=`#TTo}^u8N=GaHdtJHtQGNEXI!*{o^GQvO0g()W%R6t20TA zh}{6X=*MA71#z;09o@`umw@dw`h7V`P~ z_mGFK78oYHBD<5)zMTL8$cvHvxpK*jL)VzgPATWEo?sQ(8Vm5f&un zmP;eu2XkGLSr;7q6j_*#lQU8k24mvI2WUvK`zor`T*o4+fP3A6jEk*MNaGQ(%V}vp2NiNM<_f4x2YR6fk3Jk{nKvXLeQtwISDemwV-ouxV(Y4%RL%`^^YT` z=pu8S*eOhwmG$Ed13jrP@vG(0trm;2(p#qB+AEs;N)UYxBd`M><;PZxK4xJ zP9Ulh8RGZxdDuW<8WKNAV5q-%C82)M&l%F3?(zkvZOpeyP~uHNM?he|Vl_EIMsNgP z?|CRd9U8zR$))@+z)#ts{O%(vd8S3K!uAP_u-JaCf4%ApPS6;{YyC`N1i7FWINlE6 zz+8#qPb9Q~vHT}Tw?w6*l0=cC z?LEm|f?yYLP0{ugXu(C#OF(XKmL^54T^wCTeBOfq6f)y z`3-ce2}U+Sz-o4KHy>7?t+>;sR@Uz*NimSi_JlSDI6I@&q{3Gm;Rph~{{JIsuvv+2 zNm}5Tqi+akB9L3uL;G&>eyq5qwIJ|4-RB6}X-a%P+GD=$RqY_tHyjFyTv`Iut32T`M~t|w0;pr;6XdIveZ?5rm6-&k4)DGM_*o0FfP6#&lw!m zoz1vep{AeQEy%$)a2RlQ;4CQm;a~+mew~6z`82jnDT>gPtWx6r*@vpBx%fS3yO)uH=t?r%M_3^d6PT`1g4=uWF-Zmd`h0jFp-d+|@%ugFQiU|eOmb}JqlOYI*mf#h zH^>HDx^yKXeL2mVe8~n9(d!a{>DRmkre7|KdBf-kvAP!5>ywAERTpp#fwKQrSM&xH zb>ECiIwwb~b=PuO5^8LK?q~mg@gewRrJLjIUV`24>12+c=~6w6pky=ku0LUU6Wgq7 zb(4tmeY?E*b>q(yZ&k(~WZj}WxnQ~%9~b4ACtk<$6i3hp$8Te~e}-x*wprmCo+K)F zZ89ABwczh58qp`86r<8-W*c36eB)Qxf|#5%P!)6C3%Kt3 z)V-X_B7i6!=*sv3htVQLk~Xv=<4`NwIK`M>lu3`hqqY}q2gx=O?062U3?hIErTp}@ z>0ng*X9;ae{HIjWmX5q3XJ)8_83rpoW)LK1e?9csw~T0-ir?25F`bLe3ZP^4ThCld zOHajB-m#!=$Li8Ff@``?9UL2x#OUm7q_>Q=J=wBOzoS;y1GnZMo?C&G8G;?MbY}o& z>B=D6Albitl>*;#H?PGtk1s(TGnuxwPUWU&t4IBg3>qS4+#9cIn8kd zqt`8YcEMh^d!H~~=*-B2UBS5d2!Ob$T=Mg=2)Hu+5$NTZ0G-ZQ6}FHQ<~tzTmu(Tm zB&Q1=?FA|BuU&=Tr(k#sLO|h{)A#6x?HTQzGN`e77+v~nS<~Y4)f;fhog|!E-0((M z9$}aqlO!WYtM?Mdd#xUUt6nVvu6sB^h1Kfj(6u%E@aY%3{y>cZu;n@i~P-%V{rQ!%enP*DJ|At`9b)=!Iv5q_4Bh!JQPnPSu zO!p_$OChNHm|HW+BWxoGb^XV5| zH1QWDVLr<7p?KT=y_oA;4Hbs@!mS)5Xsvy4y=j$Owd5uw{K+DGr~sQz9cHr)ifB^e z&B3uV^bP3!fd`~70*x$vjm%VtCgTnJ$8eBaJqc2&F2O@`pR&eB>5%^zI4-?D%A=9r z>?AtTLy?R7P_^q)M8+qqe&8nKcX9C6XK4t(V#Sc(`FR4MNY#+w+o3i#!q@JOpwGYM zfkV|mX~8bPeYk{C%}n%A=o~Q6+}DXiP972c@iscTFYmA8EA#SVtD?PR@*(lC4~7Sd z*(w@%x7V_npwTB&fYP?o-$e=;@b^I!$MQng5u>Vnv@ZbkyL-}D zcqn?PRq8s)B6sYXfYLH8D@(J^$V>urZ1EBC#q1~2Z?cCwR`tkyl@~jmPLduAwY-!I2*{@Qoc1FDS$lAN@(IqMC;K zDEDYKC1DeWv;q&ZHOzj=Q)boaEJl?SoAxqWb%DOckW+@j`j5 zQ^4dhah(#scJI}G-ZRo6<%=>yLw<|iP`tknF$ev;+-Lvg0u*!`K}y-g#K^se`FAa3 z6tM+}eULbHBJ@I_=gH04UIR`&Ap~>rsx?;o$vNZ0>VZ*k8}u8qtR{tlH?k_ai}+(RYDxn z07$2=$UiJXUt6l#M!?G!tLg7r_fhmsXFLQAHW+}n*-H-27hRjjhOsCEPH-xu^3!6&)9(`ZZW@j8 zmLSGRffXZ~FRp@?^_I!O?~mwiHncv@Tf*GBd)0@50lH*2-a5PH(&qO6!G)N^v z_#Ddc;AE`(=3LWH;sdI7Y<4d)P7VPCoVf-?99$n<e=9h^|tnsJtQpx zIox#h8I16{MTLS7-u;&KnE^-i2e>nnt`njK%Y6m4Hxy!o&%%RKF?5ft*gjBTa%_1g zCNm@Sum+7$aeWD2Z}$+B`Gc5p47{+R4%**U)6m9I_e}EyzP37g8L#`&kz2g&%^r-y z1^hmt-=>nCm@uN~FGWDFHwVG=E%{PSGYDlK*!>5=m-mVm4;3;nY^VeSl@ zBl(^v7@Ze9vYs7TM{ z^&H%!s9DVbj8(TGp(1!>{vkledulq_q$iK+Ag1ZyWZP0B1kSPzeA);kcMo5N*9Y|M ziOXTJ<@E(M1e`oJ(!u@fAev$JrQi-A-jFkBq(8)|@%c<4L8^v(AlYM_&*s_1m7C2C)qJq~3Pf6hxm>>*^V1vAOW3=xK>~NkV8@RD|%W=DAv#3mI zY(0*;MO+qB7Xvbj68#TJ1Fd7>J}mYS>LIGmoi1R^r4NlJ(ZddJSBD*D%OyLT($+h{!h>$sY`fB&rO@FxObW zHw!=AMmE{7(N_rLghd-hi3z^kcm|R&h&U^h<&ZpAkY1q&g*c$YhnUG6TtBtX;wyLy z&ce%d_CPWy_-#BT?ya7o5u#kdnt>=m|GD+)^bL>?9O+cA{b+l4qZ*sgtzRWIUI%VU z1_J#PJ(PbIIYz?OOJfaF*>4Z77cP-)z9uFAh|pUh?F(B?K5V6cx0p1N4CAc>O>8Lt z$hapPrn3(a{i8oP6C$?25jgMsR+5DvaN~pJW^0^uuM89t#9q<W2E($Ih#u-XhnF(okk`%^t9YNVYz)jC@vY#fAU! z7|C}P+0?Icmkj@S@juVY$2|}i){cGgO0VIoYq%{=0wY_6u~v@w8 z_Bx6`K4ymoE2S^=^envBn6oAZ*$F$aZ#t?Z|?X3Q|!g||N7)>WAxul@y0;!Nk$&?+tQo@*s_T7Q2w}e|;AK$@rm=P3%fK~ww zKc{R+F1e->|2d2K`*(B%{aPmaUl%w=hSex72!c1tum-;O2ZHRI*yfLk^O3kbHV#wa zkdxQ^+%Lu7B}$aXZ1YQ+Yy?_q;~TVmg3=JlYQuzWBrEAo5^Y(GB!H#Sw6*Pc=-z5IKNMe~s&{u*Bg|ob zIu}gL=SWrf#7N2vIwaa3o9d8cD5Gu!R@y$2l?Dk-By|rOvcU*x^>Z{A8RFxtzNw83 zo=CyuED@XP1flw$rto`734;Eq4o+Ad%$`CvgqQ$5l)G7gUuyweQ4Con32bs}j$PzN zWeclAyx{y}h$D+P14bX8W(($c@DGZ{H?^|j%H(yob0ex$z2MSJ7wKTijv2V6dQ`1C zk=|5yOX})a)Mhq+vaZC=IX()KN{H2E5LKrJ?J`YY>`=<%TRDUY>q zcyG8`n}+Xs*%&(uJ`1Rw0CJy&(r_eTPNvWIoh~k*Kd`4Rd1GifM-Hm01M6I+;v4pE z`F9(M?{u>JA;c(H-im1^$Nr)PWFa&I=UhIgDfm`7e;oA23-s|pCz=T>!SifyaoESG zplY1|9SaDjv4*s)E%hZi9K;6L(I(?w@8R0!{{G-=t9(WIw`Ml(d`eMB`qTNVYKUyp zN!B=`X$G=wdJ2ilo0OP0ia@NEeA>gs=2uuwCUw@W!1a~50gSNSUY-Rn;3lzk?f%Tq znVFVsS*wDMgS#g9tW=muMeXyxLYcxJeL!Q~aRj=|d!cf)aD#1nrg;qua+A9q}Z=lj_ zbdp2AIP^@a;`aaGv5HLeVaL%PngT$t69vOrW6> zs48)NL#aB|ymgL~IYJU#LQEqNs^PKrkx#jrO^VNQMi6&C-8>)r{H{Ld_c3a9JXqN>IOda*ayi;5u~| z*=RtfaqK*4~h5;rP^Xs{+i zLEKK%j8}<5lQduN17Dd!C`03jVS_u=fJL64iOUP{gep8y(=4@z3-U7iarjM0k~r9Q zrCv!5YHJ}^aseO0{=1%R-q}aHM}FkItn@~9#F#7=iaY}xKJpY?Ct@ZrZiN*IC){{+ z3Mg&5L5e9ydYo^0D=d?RU+aqzXZIW5Tp6Nl_5sBVh(pePo?0PCIObod?cIN}%S4j=?>h}7M~W$TeWB|}N*HZ){R1`X#u z&@-D|(X-_NtReHfkGn-8++%gG$Jpj!7_^0m-}4nblq5Ks6O(e1z!}BzuGu{Z9AHET z2Udu6Fo#eQOvPSah!kV!hW7rX*FfeE2OYN{9;{o2a0{2eZBRv z&G|NL@$x+`W#?+n{Q}>i$VpGsHV_?dXL`nnA;^^!KxQYrg{-J7{TN}t-(bI*N?nb4 zEaUyHmBHkhQ>U0{y+|_N;<;aLLmAZxi<|wn?-q0+tp$0lcq3}hH?qGjqd~~|i!5SlZKn<4Wif~~ zik}8jI30fQ>qt~*_89D}tkGZ};P5*7x*dcs*$B`Jn%Jtm+IvR)>hTGlr9l@I7MuP_PJmn1QGZ&+gexm~|?INAc|2A;8I@f(OC~ z>>J3@44s6ps;Iy?JbP&Q@6JhpV_>pxAm9RC=Bq0bC>7@@(FqFkyFi0_1s;-ro}l%O zcV7e2tA+6sBmwFOVR%jh!*_GFI%E@wc!;#Xn9et~mzNtZJHs=s zD0&ULZUkJlC|q>|j0^7tOP_fDKx;pw`@-Lp9{^8)kM7pTkzLTi(POoYWZc1yPW?^V zm?gL%--|+m=xPb1B6=vY!p}_tNN+Xif^*`fIm`nIOoN4(2Jm<-qP+m?7c@ zK{99u0)fo*lV~l`KWmXvvg`I~k%~k;FZG$Rj5#>`IU| zoi|+ot)soWPJV~9KWV>$tY4Sm`&pE%3?F(Br-h^jIFOZ#Y&s|}(2@`FLAWj<0Cm)h zp*&{zlE6bENrDxO1qD|L1Ym8`A>SC?UNQ1$!bcU#3c|8qjQ@>xD1anAY9dzhPgWjy z*9q1TjwAsE4vDf|-~*-Zpv;xwgwCsz2w?|w|DcjHO>y{MY@TF=!VdudcF)}mJ;?wd zI4m@iZ>S3)U%~DZ1rVkM=fu!29R$|@P*NNsHI!KV``j9op$w-e+eP=W8b_FsdB8b5 z1;K8UiiAU}qD33DJZAwE0l6B1ck%!qp!EaFfP{}^jio`TVq=G&q&{4SZ)TBLgAYkX z-2;`-{SJ523;w&xx4YDf-JmDvko9ej5Y`UtCq3hOHLWq@BurDoMyb0M&hvtM9%SetH!tOBe>08syf&8?DSO4G~@(M`9eqiYSfPpinOp z?wSNrlAjj1U(cU12rQy}+FK7oxEQIV2iUGHL{zc*QAl}*FG)^z@IlB)s|>l+56rps5VTduDgvZ~ib4bye^IvysEA zj-N!U5ayxvAc<1A^C8G|gJBOmq+|O>q$Th^2B`tjzE-HI!0?H?kKEVS59#Q-Mv3A5 zbND|XRtA3}Q6S;IB#KYslVAA(fj|w%-~Jmuzk8*XUt4yc7_jQIX`eoyVaaXimg@L! zpCiYYa1PDtcbx}_Hohs<%ymrf>>0R?BqX%k=!-lla?Ra6UiY5R@2M5_x$=a)JKt+V z?AY+L=T`p8`=#=Ax}!IG!-d^9M1*NFVVIaK?B?U!-Q83#+d|4L zyfpUKE#a61SS21ifap0Kb+XMJ0YdpZ-C05n9w9u}B&~mNLy>I|Ds{oXLOKWlIC=NF z^fTo}`s?9nXP0S+1qWc2h$txN2CZTy2kaJX>@@sa9W7!~3w25GX~6^EXvOaSDBUJt zKZaj83|}21?SVIQt9%zENtOT-UHHStN2Go0s3PP&4%e)EC$Gf~(RD=7?keN&rjGKh zMdyRvdmpK;f<+k#ocm3M@;H_*RU=LEq~nwsnB zN=tRC`RS_j)Ej=|J)mM>O1rQgakzgPH$R@^vom9R(lnXYo)|_o>mFu*y31B{+u)(3 za3a+hKm6SFH0jbJ>R+e(yI-Up{$AqGxMhB0!i?p+tvpNd*~?BsqI zR0;59ff)EUx~AiANN~I_Zds3)Ix*y*8dtV8NwZ>E^3yLNXZo*!Q+v0rzqiRREqhqd zo%NP!42d;Y^4-@dg5IhXhI4c5QsYVJ=~ZB{PPDvV$3w^m+xYa4p_1$Gw@!x5wI^49 zkxFZA5kClzM&NfLcC&;&%ZHnC-t}|H=V|G!6`xZXo1b5_agcA0uitwXklo%~EMs6O zlP*P>{n3Zi!`e*aFM)T85Z3)zudJ_$GVd|itp+c?Qnr;;KAK4t3qthY?k z7HcKmMV(AR-6bJyrMBIr;_eqXx1L2Kz_J?(g$J6B9IJYsTw z7d1X3=B-aXJSP_PdEL#~XZsH0+)wWGYo4DYMZ*WDmluxJG+ApOGv2bM5MF~wY&3cw z)#crD<@yZYw>hc!^54EidGn(EPGg{(bSJl6Rw-wbN;sDbym4L^FLT3HpJS zCG_7t1t{kk7stw)7AJ&MUKAFF%kqZRiXGMiM{U;`wf2&=otW9m?VA#rhzuW+$lT=#9-au=o$%TH*8=-+P&&l}0fo z?NyQ3hGOqit36FN@Rr$^yT>r!5rm`=>S24Qf~dsjwkOlgMJNu;M+Iq~aVny z>%SA_V#AYa19Pc8w1InJya!3BOHb-MQTsrO%`e3@?>*qXGf%oD%VLSKpnzz}^~;9C zlNT>lv^Hz;hN-2-G$G~$Jz)?p)nRFj@Jksc8a)>pE%(xEU;TM`jp8;Wk;+<4wcStS zGR%3=oCXuAO?NJn-nVD>edX?a=}M1T_HK>5E_8M|V*l|)n;8E^UCIbZC>~6EQFpK2 z)ll&KbAwkiL^t%D5Q*Ni( z&Oc9H(ce2fXZ}?W2;Sc}-*PbK?1$NAwrS00i{;Bz55%Hv<%Kv~AOz9rH7rp*lK9QQdwrYk2@{#{QMkbe{NWc*tA zcvAA}TIC&Ja8O0lheR(lf7KvKp;93CB+IjALQIMVTfBY(3US(3yv43s9lzNLfiFrs zt}edR2RrY(pHZ$w=a|EJ2nM7Z5;WdWq_sLL9;%p}PB(wnCEqgLY~_LsZ*uj`)6Q%& z@=`tZLzyRrT8$2?7+Ia&VMNUR&nvy#tY|m#@MM%o@~~$WIfIsa9-BSE>EA9tN(R# zQ`0f&`)>KKn|$G2g11O=x1qW=K>o28ORVm-LLUK9;pjwDb_P1JN3zaQe=?L_+NJZQy(C zH&9=IH-}q>HSOLx97PA*WrW#~Af3|%fI*p`&G(}s0JT!2`jmKX+-#e+)uhenKJ(_@ zs|@eF11~*6bCLm#2hX(23iFmjq!y3GE#&>($P0b|N;~5E)ioiikn-!roA=DV4)N+7 zS5dXf{r^4V4ENBuLb?Z)NK@wwkGNzP-Ljf+<*JmL!rsfWAnS@j&-G)FRo&uCimWNcHsQn~nb338$GJ9yb ziooDcBkBba=A@;FY7fia<5I2haRK+VSjK9%lTL!@%^pdEM!W=N61@l>u_6Af8LqFB z2dO|TR2n(4T|2~nHJs~so%Lqgb0XXhdV>V%4M}#udDBl&&i`@_m!yBN6zN%S7OmxE ztDjvYIO7+mdB3wGsH5)%x+~2@5}`PfD!y52hV0*WWL+**p6s@KS8IQdsMJqmsCkLu zYW}U(Giy0rC|_Ywcg~4yk2iF=r=gYsP{|*pYW3S4&%!6q zl@`1z+*J@;QhrQAcOppui3_vZS~^Nv+Kj5G(I>tN(wv(!;Ti1OC>CjI240-3bqbCp z$V$2z<~QTf$3_0o~} z&YU&wnrzKO4l36dw|P|jeOb1veL_}^cQmQ%r+><}n4O7$ZUl9_y!ksTKE!Gt4=$?F zObr!^m7S?lI4Gh1CFwFI)7m+`3(j77BE>dMtW&{~>W8)OpIHMX7_Yq^iEaRvS7Le! z!-&kFFLN6MfcaHZBz!-6fpqR-gA&>~TWyfMF0ZvjAXC}5)QWfQH@kwhHAzupAkoOc z$g3H1IhmL|n4LG?5Y8_oA^rjwAttbUz4g{JN&D?XFRpN!iiG0`yunY#-KhXfh=0JZ z2-#b+DMlN|kcJSOs1dxnbPiCCYIFuN20tD?!&Fah!nU#*vbA_Xe0r^Wn+*M~`4;IS zoAZ6%9aNO*eJaF4C|0i0x*pc7$M@FK3F)rQyL@T^K=5j2M2-z&_fBfidE2o!(Did9 z&h0n*D|JK_*(9o%l}gV$Sd;8=6o+R)*UttiH~%i2gmu(*bx~sLfBddQ1O_gxfv4Ds z@xE*Rk*us!2rFZEb(>^KIJ%p170fAN!R}8uw=6M6Uj$g_n2_Kp)wunpmSxxhq&9OM z8AtMWLBo)ve#jk0Qd%|>*kxL+;woT0f(sB5`^Na;(J6bztlm%@;cfJO?~-7h)Y^wq z77u;-!VbW)tNi~UF}-Th7$L+0+Mzk*xutzPk({envHc8jidB9R9hcgbM6@MdpavlH zrn6x5wN3(taYy|?BFcajg0~~tO#>UMDi4k(0JFzF%aqSRI#>z9z|vjK+75DNDTnV7 zNzfy30>^K+tohlSA&j)|{>AcS_o*=S^VJWN-W9K2TsISBQv5B_!h;1uPn^{bwM;=f zniXK5VD*7VHHw6v?PvAt?hO;CxXa0S3v0y&Cp4&sv$B}7N_Y@Rx2vGt5_~jOFx+=% zQLxtc-TP5QIs7=oKj!G@2X>EM6qW}^&(Rlx&H!UJNKXC7D7JU6L>Byxt`=K#z$nIX z_z`=T$u1R{#ueJh6LcUtXC+Ah+WtL!eebZtZ3!0qq^Oi;Dj#BL+hHUuD+BTKUKB(f zh@0=A-qha_fwD&sN5!4@p8)sg?KDLnlq-FR&(mitKS3Oz$F<nM{0&1b`OFxF($bKhdiY^yEIq{rwK(_mWVY z+yBV-<6H05>zQ7VUW*Y9K(BC_Wg<@lv^W?v;ZgY)N6^LHwr}gOt$`DpP>{IN#}6P; z<4?rdDl$>WJ8InuBLdBW4S}8~X-+!wlezw*9-z_1v)lKE;RvTcPbW^w41e_b#g2!q zrE#Du!{2c1dPcV9C}4&S6w+iv7qRFZgj*j?caN`9@=S)q??~7~OsgqAE@LOOyr>rn zv=DI9LjOl*A1@%*d{$i0C(OP=m8*pOqaMiavK~F-D~Myv#iIMtdITM}Ff7$A1-aat zkqy@`_w#?ZCijIToi2iOVgbV;6MB&W^Q-oDf9&S*8Dub`Mf?TQ)v13XNsB^Ob1|&c zR!DVaf6dMRSzM2WkX(+x4wq+at75bZ0VgwT6BlM(TX_tet$5QvtN3{UofaL3jSJ`) z_?9AkJ3vw&)IWR|9CQ^JEWh@ujbcIQmq*P(yvN?a@i`g`GvZJ9S%8^2@EgJhs3Tsc zNmn;tc4kfq-H)kd83nGsr>hQ90nV#h(VEDMmbBQtl3&i8-aP@I$7>%ldB+(7ubGuf zc=P=4Y$vCe2R2HPg|78*_gdcf`QIr8PQ@2y@7`g(#fUZENJ%tg_zPeUb(_}TBc3rX*YT2F8T<|l?6*&kR!NYqp8>X;z_3B$i2Nh-nz@HQ@o zv{Z<>roct`=HJH#oV>SOkbBJaWvy7c{FJj9+}_8p%E)%mae@up`AqcxT=arcz=3qd zYBgg?kxkjaEr52_NGg!oqF<{9&C2}1xUIY8ApxwoEj}~8d7;eW=?W(p7u~R+|2`f~ z_*jjY>h;%>Ouzov?qv{{chA+wSJB)ry$XT+CJxX3Awd=2qUl;-9(dU^q@^>9wu_x7 zCN$_hyIT{5STN#QW(l8JFW`W_eCS+QY27Y!?sVrH%=zbqyV~1pb16AJ2rMar%dSo$d*l$w50*d~>e+@kzu=KD`@&|qOBLl_5`Nxd8Yp5m zz`pzA1@OKD!*Zue1;d*riOeLzd%f{d*Nt;b$^YKdNec^=Q zHF|IKbLf{3g@wvvDx?j^ULhSU63*Y1jtpNt#?+ytNUca1cX4R_z-sDh?2HI!Q@2(& zynmKcD+v}CWVOrVRP6!=p&M>3q)L+_9lzJa2<*BLuhcH36*1+Vj<2#g0F8kcqfO-+<9r*sWR$&gP!~h;AHF|h`!>%iH0eYDJW=AenQ>H1AmSI_} z22z#>+kNV9c7pn%9Z9P#`+6UcKA}PPDYq8Z2PiQc~Wa!y@annk? zA+L=pLiER3-XBCiXCaY?92=C@75xKV!%EKAL7M-5$5~_a5H_33vOB!-7V#BXC98J8 zOp~XiVD+`SNcFWm&a zlseNsXJ)qluf1yxYU+r>*P=s3M;kDxm62&WQ)o>a3(g2KJjMa762-O@vDgq43WFM| z0SY8yMvIMT(5eUolqe8X5Qj_57;}o zv)MiOobP<+?76%9tx6}sUpP_~1K5SrioZhKr1lt^HU! zW3S_C{0Cg|ob1nI;GqKryfWog z;2HoXWz_Mgr030;L(nro)0CMa@H@Zf#V+|CnGt&-$+OTSRo!`zaTgSQNW3V?N_~8!yU%^FIaaI zbR`KuA28e(#lE0Cvq^yw(7iFOb8d`dpgefo=O+ggm4U~tB#ZMdbK$K$#^b3iSnD^E zdX@zvExZWHaQkkZ+bOrdww?vr+&zs1plI;Aun6#E#aXC7`p8;fYn;g5a^uKEfpZl0 zF)3vFE)GI-rxD?=RX2q~h+3ufgwF|B2uL3cBsEE-k^iC0tvg~&^IfIp3%E3754$UD!y zku#4tNNxY_l#hbK5kYBKF=WM69Z*{CYuHoX6t*)1x|SUWwJ-z?4Ue$$bs~5|;5|s_ z77D>W)`d_;<5hDTpi=4+cS3e{IC;u0EG7vnPM z6Cqil9mtGsD?!hEe92p%L6)rS1tmS&Jyavf1(s5pnmjF+-J5~8kUCB%w23h=)}E!9 zp!I}+Ash47eO)}?LnLf_G-Fd6{bPwApUzHw5$*ta&4c<|`l~S9F{;THO_5(0p7UAB z+jTT8Cu3&cZKM?Ja)>3970rOU;L`@|uuV;VfiqBIU7jJCHRA zoUm1sE9!`UET7Tw6#+}z<_WsNmhR_HCdFNQg7ORuOy7wTU?pxN`El1z4konvt|U

yZj4a z+&Sp*Aa2!ph6crB)@h1>vb*{8)k7m%G`F~$i&PBD)HnyI}%JeO1C57J8z zf%F1G^LT$~hhee=afXy$sk0e_`V&n+rBL9L58F)-RKkI5ye^aL;O3lNaD*=`{MTa1 z1urur5Wm4nuY>57V5$;lhLnc!r3MaG;ouK3!!L~jjyckxN#)?Uy%`Q%({eOMJr8(h zZWm`(H;Nwh>n1FN;Bd5RNxgAoQXlG_unHUo9K$Y!0_#wdQ6E}Wd1^488HuL1AOg#R zev@GrwWMqA@CWK`NVk6O1q_NbMFD>AEkem1_GJu#gz65BERwn<5I0 OdyC(8-{OtzqyGX}z-~YQ diff --git a/manual/source/laboratory-structure.rst b/manual/source/laboratory-structure.rst deleted file mode 100644 index 05523bcbfe..0000000000 --- a/manual/source/laboratory-structure.rst +++ /dev/null @@ -1,25 +0,0 @@ -.. _Lab-Structure: - -================== -Sample preparation -================== - -.. index:: - Draft classes - -.. _LaboratorySteps: - -Virtually all experiments require a preparation of the sample. As most techniques -are surface-sensitive or probe exclusively the surface, the use of careful preparation -techniques is the key to successful experiments. Unfortunately, the quality of -such processes is often difficult to reproduce. Nevertheless, documenting how samples -are prepared is relevant. The classes here provide minimal examples how descriptions -of the sample preparation steps can be interfaced to NeXus. -Currently, we consider these drafts to work towards harmonization with the -specific examples developed by the team of area A of FAIRmat. - - :ref:`NXlab_sample_mounting`: - An application definition to document how a sample was mounted. - - :ref:`NXlab_electro_chemo_mechanical_preparation`: - An application definition to document how a sample was prepared. diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst deleted file mode 100644 index 9755e8b2c5..0000000000 --- a/manual/source/mpes-structure.rst +++ /dev/null @@ -1,111 +0,0 @@ -.. _Mpes-Structure: - -============================================== -B2/B3: Photoemission & core-level spectroscopy -============================================== - -.. index:: - IntroductionMpes - MpesAppDef - MpesBC - MpesCommonBC - MpesExtendedBC - - -.. _IntroductionMpes: - -Introduction -############ - -Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), -hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) -and photoemission electron microscopy (PEEM). We also included descriptors for advanced specializations, such as spin-resolution, time resolution, -near-ambient pressure conditions, dichroism etc. - -.. _MpesAppDef: - -Application Definitions -####################### - -We created two new application definitions: - - :ref:`NXmpes`: - A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. - -.. _MpesBC: - -Base Classes -############ - -We developed entirely new base classes: - - :ref:`NXelectronanalyser`: - A base class to describe electron kinetic energy analizers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following subclasses: - - :ref:`NXcollectioncolumn`: - Base class to describe the set of electronic lenses in the electron collection column (standard, PEEM, momentum-microscope, etc.). - - :ref:`NXenergydispersion`: - Base class to describe the energy dispersion sytem (hemispherical, time-of-flight, etc.). - - :ref:`NXspindispersion`: - Base class to describe the set of electronic lenses in the electron collection column. - - :ref:`NXmanipulator`: - A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, - cryogenic cooling and other advanced features. - -We developed three base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: - - :ref:`NXcalibration`: - A base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. - - :ref:`NXdistortion`: - A base class to describe the 2D distortion correction of an axis, with a matrix mapping a raw data image to a undistorted image. - - :ref:`NXregistration`: - A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. - -.. _MpesCommonBC: - -Common Base Classes -################### - -We developed two classes that are common to other techniques: - - :ref:`NXlens_em`: - A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. - - :ref:`NXdeflector` - A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. - -.. _MpesExtendedBC: - -Base Classes Extended in Application Definitions -################################################ - -We use existent base classes in application definitions and add descriptors: - - :ref:`NXaperture` - Added fileds to describe analyser apertures and slits. - - :ref:`NXbeam` - Adedd fields to describe utrafast laser beams. - - :ref:`NXdetector` - Added fields to describe electron detectors (MCP+Phospor screen, delay lines etc.). - - :ref:`NXentry` - Added fields to describe an experiment. - - :ref:`NXprocess` - Added subclasses and collective processing descriptors. - - :ref:`NXsample` - Added descriptors specific to photoemission experiments. - - :ref:`NXsource` - Added descriptors for laboratory sources (X-ray, UV lamps) but mostly for ultrafast lasers with complex time structures. - - :ref:`NXinstrument` - Added descriptors for the overall resolutions of the experiment (energy, momentum, angular, spatial, temporal). diff --git a/manual/source/nexus-index.rst b/manual/source/nexus-index.rst deleted file mode 100644 index 1e9bf529ac..0000000000 --- a/manual/source/nexus-index.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _NexusIndex: - -======================================= -NeXus Documentation -======================================= - -Welcome to the user manual of the NeXus. - -https://www.nexusformat.org/ - -.. toctree:: - :maxdepth: 2 - - user_manual - examples/index - ref_doc - community - installation - utilities - docs_about \ No newline at end of file diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst deleted file mode 100644 index 6f21499139..0000000000 --- a/manual/source/north-structure.rst +++ /dev/null @@ -1,264 +0,0 @@ -.. _North-Structure: - -====================== -Nomad Remote Tools Hub -====================== - - -.. index:: - IntroductionApmParaprobe - WhatHasBeenAchieved - ApmParaprobeAppDef - ApmParaprobeNewBC - NextStep - - -.. _IntroductionApmParaprobe: - -Introduction -############## - -NORTH (the NOMAD Oasis Remote Tools Hub) is a NOMAD Oasis service which makes -preconfigured scientific software of different communities available and coupled -to Oasis and accessible via the webbrowser. This part of the proposal documents -examples for specific NeXus-related work to some of the tools and containers -available in NORTH. - - -apmtools -######## - -One tool is the paraprobe-toolbox software package in the the apmtools container. -The software is developed by `M. Kühbach et al. `_. - -Here we show how NeXus is used to consistently define application definitions -for scientific software in the field of atom probe. In this community the paraprobe-toolbox is an example of an open-source parallelized -software for analyzing point cloud data, for assessing meshes in 3D continuum -space, and analyzing the effects of parameterization on descriptors -about the microstructure of materials which were studied with atom probe microscopy. - -The need for a thorough documentation of the tools in not only the paraprobe-toolbox was motivated by several needs: - -First, users of software would like to better understand and also be able to -study themselves which individual parameter and settings for each tool exist -and how configuring these affects their analyses quantitatively. - -Second, scientific software like the tools in the paraprobe-toolbox implement a -numerical/algorithmical (computational) workflow whereby data from multiple input sources -(like previous analysis results) are processed and carried through more involved analysis -within several steps inside the tool. The tool then creates output as files. - -Individual tools are developed in C/C++ and/or Python. Here, having a possibility -for provenance tracking is useful as it is one component and requirement for -making workflows exactly numerically reproducible and thus to empower scientists -to fullfill better the "R", i.e. reproducibility of daily FAIR research practices. - -The paraprobe-toolbox is one example of a software which implements a workflow -via a sequence of operations executed within a jupyter notebook -(or Python script respectively). Specifically, individual tools are chained. -Convenience functions are available to create well-defined input/configuration -files for each tool. These config files instruct the tool upon processing. - -In this design, each workflow step (with a tool) is in fact a pair (or triple) of -at least two sub-steps: i) the creation of a configuration file, -ii) the actual analysis using the Python/or C/C++ tools, -iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 -files generated from each tool run using other software. - - -.. _WhatHasBeenAchieved: - -What has been achieved so far? -############################## - -This proposal summarizes both of the steps which we worked on between Q3/2022-Q1/2023 to change the interface and -file interaction in all tools of the paraprobe-toolbox to accept exclusively -well-defined configuration files and yield exclusively specific output. - -Data and metadata between the tools are exchanged with NeXus/HDF5 files. -Specifically, we created for each tool an application definition (see below) -which details all possible settings and options for the configuration as to -guide users. The config(uration) files are HDF5 files, whose content matches -to the naming conventions of the respective `config` application definition for each tool. -As an example NXapm_paraprobe_config_surfacer specifies how a configuration file -for the paraprobe-surfacer tool should be formatted and which parameter it contains. - -That is each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. -This implements a full provenance tracking on the input files along the -processing chain/workflow. - -As an example, a user may first range their reconstruction and then compute -correlation functions. The config file for the ranging tool stores the files -which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the ion type labels stored. -This results file is formatted according to the tool-specific `results` -application definition. This results file and the reconstruction is -imported by the spatial statistics tool which again keeps track of all files. - -This design makes it possible to rigorously trace which numerical results -were achieved with a specific chain of input and -settings using specifically-versioned tools. - -We understand that this additional handling of metadata and provenance tracking -may not be at first glance super relevant for scientists or appears to be an -unnecessarily complex feature. There is indeed an additional layer of work which -came with the development and maintenance of this functionality. - -However, we are convinced that this is the preferred way of performing software -development and data analyses as it enables users to take advantage of a completely -automated provenance tracking which happens silently in the background. - -.. _ApmParaprobeAppDef: - -Application Definitions -####################### - -Firstly, we define application definitions for the input side (configuration) of each tool. - - :ref:`NXapm_paraprobe_config_transcoder`: - Configuration of paraprobe-transcoder - Load POS, ePOS, APSuite APT, RRNG, RNG, and NXapm HDF5 files. - - :ref:`NXapm_paraprobe_config_ranger`: - Configuration of paraprobe-ranger - Apply ranging definitions and explore possible molecular ions. - - :ref:`NXapm_paraprobe_config_selector`: - Configuration of paraprobe-selector - Defining complex spatial regions-of-interest to filter reconstructed datasets. - - :ref:`NXapm_paraprobe_config_surfacer`: - Configuration of paraprobe-surfacer - Create a model for the edge of a point cloud via convex hulls, alpha shapes. - - :ref:`NXapm_paraprobe_config_distancer`: - Configuration of paraprobe-distancer - Compute analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_config_tessellator`: - Configuration of paraprobe-tessellator - Compute Voronoi cells for if desired all ions in a dataset. - - :ref:`NXapm_paraprobe_config_nanochem`: - Configuration of paraprobe-nanochem - Compute delocalization, iso-surfaces, analyze 3D objects, and composition profiles. - - :ref:`NXapm_paraprobe_config_intersector`: - Configuration of paraprobe-intersector - Assess intersections and proximity of 3D triangulated surface meshes in - continuum space to study the effect the parameterization of surface - extraction algorithms on the resulting shape, spatial arrangement, - and colocation of 3D objects via graph-based techniques. - - :ref:`NXapm_paraprobe_config_spatstat`: - Configuration of paraprobe-spatstat - Spatial statistics on the entire or selected regions of the reconstructed dataset. - - :ref:`NXapm_paraprobe_config_clusterer`: - Configuration of paraprobe-clusterer - Import cluster analysis results of IVAS/APSuite and perform clustering - analyses in a Python ecosystem. - -Secondly, we define application definitions for the output side (results) of each tool. - - :ref:`NXapm_paraprobe_results_transcoder`: - Results of paraprobe-transcoder - Store reconstructed positions, ions, and charge states. - - :ref:`NXapm_paraprobe_results_ranger`: - Results of paraprobe-ranger - Store applied ranging definitions and combinatorial analyses of all possible iontypes. - - :ref:`NXapm_paraprobe_results_selector`: - Results of paraprobe-selector - Store which points are inside or on the boundary of complex spatial regions-of-interest. - - :ref:`NXapm_paraprobe_results_surfacer`: - Results of paraprobe-surfacer - Store triangulated surface meshes of models for the edge of a dataset. - - :ref:`NXapm_paraprobe_results_distancer`: - Results of paraprobe-distancer - Store analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_results_tessellator`: - Results of paraprobe-tessellator - Store volume of all Voronoi cells about each ion in the dataset. - - :ref:`NXapm_paraprobe_results_nanochem`: - Results of paraprobe-nanochem - Store all results of delocalization, isosurface, and interface detection algorithms, - store all extracted triangulated surface meshes of found microstructural features, - store composition profiles and corresponding geometric primitives (ROIs). - - :ref:`NXapm_paraprobe_results_intersector`: - Results of paraprobe-intersector - Store graph of microstructural features and relations/link identified between them. - - :ref:`NXapm_paraprobe_results_spatstat`: - Results of paraprobe-spatstat - Store spatial correlation functions. - - :ref:`NXapm_paraprobe_results_clusterer`: - Results of paraprobe-clusterer - Store results of cluster analyses. - -.. _ApmParaprobeNewBC: - -Base Classes -############ - -We envision that the above-mentioned definitions can be useful not only to take -inspiration for other software tools in the field of atom probe but also to support -a discussion towards a stronger standardization of the vocabulary used. -Therefore, we are happy for your comments and suggestions on this and the related -pages via the hypothesis web annotation service or as your issues posted on GitHub. - -We are convinced that the majority of data analyses in atom probe use -an in fact common set of operations and conditions on the input data -even though this might not be immediately evident. In particular this is not -the case for some community built tools with a very specific scope where oftentimes -the algorithms are hardcoded for specific material systems. A typical example is a -reseacher who implements a ranging tool and uses that all the examples are on a -specific material. We are convinced it is better to follow a much more generalized approach. - -In this spirit, we propose the following base classes and the above application -definitions as examples how very flexible constraints can be implemented which -restrict which ions in the dataset should be processed or not. We see that these -suggestions complement the proposal on computational geometry base classes: - - :ref:`NXapm_input_reconstruction`: - A description from which file the reconstructed ion positions are imported. - - :ref:`NXapm_input_ranging`: - A description from which file the ranging definitions are imported. - The design of the ranging definitions is, thanks to :ref:`NXion` so - general that all possible nuclids can be considered, be they observationally stable, - be they radioactive or transuranium nuclids. - -A detailed inspection of spatial and other type of filters used in atom probe microscopy -data analysis revealed that it is better to define atom probe agnostic, i.e. more -general filters: - - :ref:`NXspatial_filter`: - A proposal how a point cloud can be spatial filtered in a very specific, - flexible, yet general manner. This base class takes advantage of - :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, and :ref:`NXcg_hexahedron_set` - to cater for all of the most commonly used geometric primitives in - atom probe. - - :ref:`NXsubsampling_filter`: - A proposal for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. - - :ref:`NXmatch_filter`: - A proposal for a filter that can also be used for specifying how entries - like ions can be filtered based on their type (ion species) - or hit multiplicity. - -In summary, we report with this proposal our experience made in an experimental -project that is about using NeXus for standardizing a set of non-trivial scientific software tools. -During the implementation we learned that for handling computational geometry -and microstructure-related terms many subtilities have to be considered which -makes a controlled vocabulary valuable not only to avoid a reimplementing of the wheel. diff --git a/manual/source/sed/entry-page.html b/manual/source/sed/entry-page.html deleted file mode 100644 index b7c84946c2..0000000000 --- a/manual/source/sed/entry-page.html +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - \ No newline at end of file diff --git a/manual/source/stm-structure.rst b/manual/source/stm-structure.rst deleted file mode 100644 index 944c262033..0000000000 --- a/manual/source/stm-structure.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _Stm-Structure: - -============================= -Scanning Tunneling Microscopy -============================= - - -.. index:: - IntroductionStm - StmAppDef - StmNewBC - - -.. _IntroductionStm: - -Introduction -############## -TBD - - -.. _StmAppDef: - -Application Definitions -####################### -TBD - - -.. _StmNewBC: - -Base Classes -############ -TBD diff --git a/manual/source/transport-structure.rst b/manual/source/transport-structure.rst deleted file mode 100644 index 8238b52196..0000000000 --- a/manual/source/transport-structure.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _Transport-Structure: - -=================== -Transport Phenomena -=================== - -.. index:: - IntroductionTransport - TransportAppDef - - -.. _IntroductionTransport: - -Introduction -############## - - -.. _TransportAppDef: - -Application Definitions -####################### - -Work on handshaking between EPICS-controlled experiments and NeXus resulted in one application definition for temperature dependent IV curve measurements. - - :ref:`NXiv_temp`: - Application definition for temperature dependent IV curve measurements. From efc0568810a325c1bfee9dfed97bd43a58411fc6 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Jun 2023 14:10:40 +0200 Subject: [PATCH 174/203] NXopt: Set PARAMETERS/values to NX_FLOAT --- contributed_definitions/NXopt.nxdl.xml | 2 +- contributed_definitions/nyaml/NXopt.yaml | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 98f9b496a8..04d22e2110 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -415,7 +415,7 @@ optical spectroscopy experiments--> temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - + Vector containing the values of the varied parameter. Its length is equal to N_measurements. The order of the values diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 244c75c928..9ef1f4e000 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -304,7 +304,8 @@ NXopt: was performed. For example, if the measurement was performed at temperatures of 4, 77 and 300 K, then number_of_parameters = 3. unit: NX_COUNT - values: + values(NX_FLOAT): + unit: NX_ANY doc: | Vector containing the values of the varied parameter. Its length is equal to N_measurements. The order of the values From fdbf2bc15932986352427594b829ab941ed29c55 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Jun 2023 14:43:57 +0200 Subject: [PATCH 175/203] NXellipsometry: change units of number_of_params to unitless --- contributed_definitions/NXopt.nxdl.xml | 2 +- contributed_definitions/nyaml/NXopt.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 04d22e2110..254b4a21d6 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -408,7 +408,7 @@ optical spectroscopy experiments--> If the parameter_type is `other` a name should be specified here. - + Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 9ef1f4e000..447373da39 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -303,7 +303,7 @@ NXopt: Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - unit: NX_COUNT + unit: NX_UNITLESS values(NX_FLOAT): unit: NX_ANY doc: | From 878a53e7c6c942580b6e381615b7dbb0866eff7f Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Jun 2023 14:51:09 +0200 Subject: [PATCH 176/203] Sync ellips changes from fairmat_2023 --- contributed_definitions/NXopt.nxdl.xml | 24 ++++++++++++++++-------- contributed_definitions/nyaml/NXopt.yaml | 24 ++++++++++++++++-------- 2 files changed, 32 insertions(+), 16 deletions(-) diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 7f6d7e5b76..254b4a21d6 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -379,35 +379,43 @@ optical spectroscopy experiments--> below. The specified variable has to be N_measurements long, providing the parameters for each data set. If you vary more than one parameter simultaneously. + If the measured parameter is not contained in the list `other` + should be specified and the `parameter_type_name` should be provided. - + - - - + + + - + - + + - + + + If the parameter_type is `other` a name should be specified here. + + + Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - + Vector containing the values of the varied parameter. Its length is equal to N_measurements. The order of the values diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 67c1fb078b..447373da39 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -271,33 +271,41 @@ NXopt: below. The specified variable has to be N_measurements long, providing the parameters for each data set. If you vary more than one parameter simultaneously. + If the measured parameter is not contained in the list `other` + should be specified and the `parameter_type_name` should be provided. enumeration: [ conductivity, detection_angle, - electric field, + electric_field, flow, - incident angle, - magnetic field, - optical excitation, + incident_angle, + magnetic_field, + optical_excitation, pH, pressure, resistance, shear, - stage positions, + stage_positions, strain, stress, - surface pressure, + surface_pressure, temperature, voltage, + other, ] + parameter_type_name: + doc: | + If the parameter_type is `other` a name should be specified here. + exists: optional number_of_parameters(NX_UINT): doc: | Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - unit: NX_COUNT - values: + unit: NX_UNITLESS + values(NX_FLOAT): + unit: NX_ANY doc: | Vector containing the values of the varied parameter. Its length is equal to N_measurements. The order of the values From e929b71fe1952a04443c3753ccc9d950752451b8 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 14 Jun 2023 14:55:38 +0200 Subject: [PATCH 177/203] revert FAIRmat changes, but kept code for first reference --- .github/workflows/ci.yaml | 4 +- Makefile | 7 +- manual/source/conf.py | 80 ++--------- manual/source/index.rst | 54 +++---- nxdl.xsd | 290 +++++++++++++++++++------------------- 5 files changed, 185 insertions(+), 250 deletions(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 229211149d..34dc020d45 100644 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -4,11 +4,9 @@ on: push: branches: - main # push commit to the main branch - - fairmat pull_request: branches: - main # pull request to the main branch - - fairmat workflow_dispatch: # allow manual triggering inputs: deploy: @@ -81,8 +79,10 @@ jobs: - name: Build User Manual run: | + make pdf make html ls -lAFgh build/manual/build/html/index.html + ls -lAFgh build/manual/build/latex/nexus.pdf - name: Build and Commit the User Manual if: ${{ github.event.inputs.deploy && env.python_version == '3.7' }} diff --git a/Makefile b/Makefile index e8a0ae2b59..44c076c341 100644 --- a/Makefile +++ b/Makefile @@ -60,7 +60,7 @@ pdf :: cp $(BUILD_DIR)/manual/build/latex/nexus.pdf $(BUILD_DIR)/manual/source/_static/NeXusManual.pdf html :: - $(SPHINX) -b html $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html + $(SPHINX) -b html -W $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html impatient-guide :: $(SPHINX) -b html -W $(BUILD_DIR)/impatient-guide/ $(BUILD_DIR)/impatient-guide/build/html @@ -84,11 +84,6 @@ all :: @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/manual/build/html/index.html`" @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus.pdf`" -nexus-fairmat-proposal :: - $(MAKE) test - $(MAKE) clean - $(MAKE) prepare - $(SPHINX) -b html $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html # NeXus - Neutron and X-ray Common Data Format # diff --git a/manual/source/conf.py b/manual/source/conf.py index 936ce323ae..51b35e4bb3 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -19,10 +19,10 @@ # -- Project information ----------------------------------------------------- -project = 'NeXus-FAIRmat' -author = 'The FAIRmat collaboration' -copyright = u'2022-{}, {}'.format(datetime.datetime.now().year, author) -description = u'Proposal of NeXus expansion for FAIRmat data' +project = 'nexus' +author = 'NIAC, https://www.nexusformat.org' +copyright = u'1996-{}, {}'.format(datetime.datetime.now().year, author) +description = u'NeXus: A Common Data Format for Neutron, X-ray, and Muon Science' # The full version, including alpha/beta/rc tags version = u'unknown NXDL version' @@ -46,7 +46,6 @@ 'sphinx.ext.ifconfig', 'sphinx.ext.viewcode', 'sphinx.ext.githubpages', - 'sphinx_comments', 'sphinx.ext.todo', 'sphinx_tabs.tabs' ] @@ -68,9 +67,8 @@ # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. # -html_theme = 'alabaster' -# html_theme = 'sphinxdoc' -# html_theme = 'sphinx_rtd_theme' +# html_theme = 'alabaster' +html_theme = 'sphinxdoc' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, @@ -79,70 +77,20 @@ # Add extra files html_extra_path = ['CNAME'] -html_logo = 'img/FAIRmat.png' - -if html_theme== 'sphinx_rtd_theme': - html_theme_options = { - 'logo_only': False, - 'collapse_navigation': True, - 'sticky_navigation': True, - 'navigation_depth': 4, - 'includehidden': True, - 'titles_only': False - } - def setup(app): - app.add_css_file('to_rtd.css') -elif html_theme== 'alabaster': # Alabaster allows a very high degree of control form Sphinx conf.py - html_sidebars = { - '**': [ - 'about.html', - 'navigation.html', - 'relations.html', - 'searchbox.html', - 'google_search.html' - ], - } - html_theme_options = { - 'body_text_align': 'justify', - 'logo_name': True, - 'github_button': True, - 'github_type': 'watch', - 'github_repo': 'nexus_definitions/tree/fairmat', - 'github_user': 'FAIRmat-Experimental', - 'github_count': 'false', # We don't get the cute counter baloon if we want to point to the branch - 'sidebar_width': '235px', - 'page_width': '1000px', - 'font_size': '12pt', - 'font_family': 'Arial', - 'description': 'Proposal of NeXus expansion for FAIRmat data.', - 'show_powered_by': True, - 'sidebar_header': '#ffffff', - 'sidebar_hr': '#ffffff', - 'sidebar_link': '#ffffff', - 'sidebar_list': '#ffffff', - 'sidebar_link_underscore': '#ffffff', - 'sidebar_text': '#ffffff' - } - def setup(app): - app.add_css_file('to_alabaster.css') -else: - html_sidebars = { + +html_sidebars = { '**': [ - 'localtoc.html', - 'relations.html', - 'sourcelink.html', - 'searchbox.html', + 'localtoc.html', + 'relations.html', + 'sourcelink.html', + 'searchbox.html', 'google_search.html' - ], - } + ], +} # Output file base name for HTML help builder. htmlhelp_basename = 'NeXusManualdoc' -comments_config = { - "hypothesis": True - } - # -- Options for Latex output ------------------------------------------------- latex_elements = { 'maxlistdepth':7, # some application definitions are deeply nested diff --git a/manual/source/index.rst b/manual/source/index.rst index 25f293f57f..bb47170555 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -1,40 +1,35 @@ +.. image:: img/NeXus.png + :width: 40% + ======================================= User Manual and Reference Documentation ======================================= -Welcome to the user manual of the NeXus for FAIRmat project. - https://www.nexusformat.org/ .. toctree:: :maxdepth: 2 - - fairmat-cover - nexus-index - em-structure - mpes-structure - ellipsometry-structure - apm-structure - transport-structure - stm-structure - cgms-structure - laboratory-structure - north-structure - - + :numbered: 4 + + user_manual + examples/index + ref_doc + napi + community + installation + utilities + history + docs_about ----------- .. rubric:: Publishing Information -| This commit time code <>. -| This commit identifier <>. -| This manual built |today|. - +This manual built |today|. .. seealso:: - The extended NeXus documentation: + This document is available in these formats online: :HTML: https://manual.nexusformat.org/ @@ -51,14 +46,11 @@ https://www.nexusformat.org/ :PDF: https://manual.nexusformat.org/_static/NXImpatient.pdf - FAIRmat website: - - ``_ - - NOMAD website: - - ``_ - - - +.. Suggestions for adding to this manual: + Look for some other "section" such as "introduction.rst" and act similarly. + Any examples go as text files in the examples/ subdirectory and are pulled into + Sphinx inside a :directive:`literalcode` directive. Look for the pattern + or wing it. If you are ambitious, add index entries. Many examples of the + constructs you might use are already in the manual. + diff --git a/nxdl.xsd b/nxdl.xsd index f5e733dd16..a2ef83e807 100755 --- a/nxdl.xsd +++ b/nxdl.xsd @@ -11,38 +11,38 @@ NeXus - Neutron and X-ray Common Data Format Copyright (C) 2008-2022 NeXus International Advisory Committee (NIAC) - + This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. - + This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. - + You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - + For further information, see http://www.nexusformat.org - + - + - Definitions of the basic data types and unit types + Definitions of the basic data types and unit types allowed in NXDL instance files. - + - + @@ -51,27 +51,27 @@ is the ``group`` at the root of every NXDL specification. It may *only* appear - at the root of an NXDL file and must only appear + at the root of an NXDL file and must only appear **once** for the NXDL to be *well-formed*. - + - + - Used for allowed names of elements and attributes. + Used for allowed names of elements and attributes. Note: No ``-`` characters (among others) are allowed and you cannot start or end with a period (``.``). - HDF4 had a 64 character limit on names - (possibly including NULL) and the NAPI enforces this - via the ``NX_MAXNAMELEN`` variable with + HDF4 had a 64 character limit on names + (possibly including NULL) and the NAPI enforces this + via the ``NX_MAXNAMELEN`` variable with a **64** character limit (which may be 63 on a practical basis if one considers a NULL terminating byte). - (This data type is used internally in the NXDL schema + (This data type is used internally in the NXDL schema to define a data type.) NOTE: In some languages, it may be necessary to add a ``^`` at the start and a ``$`` at the end of the regular @@ -83,49 +83,49 @@ - + Used for allowed names of NX class types (e.g. NXdetector). Note this is *not* the instance name (e.g. ``bank1``) which is covered by ``validItemName``. - (This data type is used internally in the NXDL schema + (This data type is used internally in the NXDL schema to define a data type.) - - + + - + This is a valid link target - currently it must be an absolute path made up of valid names with the ``/`` character delimiter. But we may want to consider allowing "``..``" (parent of directory) at some point. - If the ``name`` attribute is helpful, then use it in the path + If the ``name`` attribute is helpful, then use it in the path with the syntax of *name:type* as in these examples:: - + /NXentry/NXinstrument/analyzer:NXcrystal/ef /NXentry/NXinstrument/monochromator:NXcrystal/ei /NX_other - + Must also consider use of ``name`` attribute in resolving ``link`` targets. - (This data type is used internally in the NXDL schema + (This data type is used internally in the NXDL schema to define a data type.) - - + + From the HDF5 documentation: - - *Note that relative path names in HDF5 do not employ the ``../`` notation, + + *Note that relative path names in HDF5 do not employ the ``../`` notation, the UNIX notation indicating a parent directory, to indicate a parent group.* - - Thus, if we only consider the case of + + Thus, if we only consider the case of ``[name:]type``, the matching regular expression syntax is written: ``/[a-zA-Z_][\w_]*(:[a-zA-Z_][\w_]*)?)+``. Note that HDF5 also permits relative path names, such as: @@ -136,28 +136,28 @@ - + - + - The presence of the ``deprecated`` attribute + The presence of the ``deprecated`` attribute indicates to the data file validation process that an advisory message (specified as the content of the - ``deprecated`` attribute) will be reported. + ``deprecated`` attribute) will be reported. Future versions of the NXDL file might not define (or even re-use) the component marked with this attribute. - + The value of the attribute will be printed in the documentation. Make it descriptive (limited to no line breaks). For example:: - + deprecated="as of release MAJOR.MINOR" - - Note: because ``deprecated`` is an attribute, - the XML rules do not permit it to have any + + Note: because ``deprecated`` is an attribute, + the XML rules do not permit it to have any element content. @@ -173,25 +173,25 @@ A ``definition`` is the root element of every NXDL definition. - It may *only* appear at the root of an NXDL file and must only + It may *only* appear at the root of an NXDL file and must only appear **once** for the NXDL to be *well-formed*. - The ``definitionType`` defines the documentation, + The ``definitionType`` defines the documentation, attributes, fields, and groups that will be used as children of the ``definition`` element. Could contain these elements: - + * ``attribute`` * ``doc`` * ``field`` * ``group`` * ``link`` - Note that a ``definition`` element also includes the definitions of the + Note that a ``definition`` element also includes the definitions of the ``basicComponent`` data type. - (The ``definitionType`` data type is used internally in the NXDL schema + (The ``definitionType`` data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) - + Note that the first line of text in a ``doc`` element in a ``definition`` is used as a summary in the manual. Follow the pattern as shown in the base class NXDL files. @@ -201,7 +201,7 @@ - Use a ``symbols`` list + Use a ``symbols`` list to define each of the mnemonics that represent the length of each dimension in a vector or array. @@ -299,7 +299,7 @@ their definition in the NeXus base classes and application definitions. Any items found that do not match the definition in the NXDL will generate a warning message. - + The ``ignoreExtraGroups`` attribute should be used sparingly! @@ -315,7 +315,7 @@ their definition in the NeXus base classes and application definitions. Any items found that do not match the definition in the NXDL will generate a warning message. - + The ``ignoreExtraFields`` attribute should be used sparingly! @@ -331,14 +331,14 @@ against their definition in the NeXus base classes and application definitions. Any items found that do not match the definition in the NXDL will generate a warning message. - + The ``ignoreExtraAttributes`` attribute should be used sparingly! - + @@ -352,9 +352,9 @@ - + - + @@ -368,7 +368,7 @@ NeXus base class that could be used here. - The group will take the ``@name`` attribute + The group will take the ``@name`` attribute defined by the parent ``choice`` element so do not specify the ``@name`` attribute of the group here. @@ -380,32 +380,32 @@ - The name to be applied to the selected child group. - None of the child groups should define a + The name to be applied to the selected child group. + None of the child groups should define a ``@name`` attribute. - + - + - A group element refers to the definition of + A group element refers to the definition of an existing NX object or a locally-defined component. Could contain these elements: - + * ``attribute`` * ``doc`` * ``field`` * ``group`` * ``link`` - - Note that a ``group`` element also includes the definitions of the + + Note that a ``group`` element also includes the definitions of the ``basicComponent`` data type. - (The ``groupType`` data type is used internally in the NXDL schema + (The ``groupType`` data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) @@ -419,8 +419,8 @@ - The ``type`` attribute *must* - contain the name of a + The ``type`` attribute *must* + contain the name of a NeXus base class, application definition, or contributed definition. @@ -433,16 +433,16 @@ required to specify the ``name`` attribute in the NXDL file. It is suggested to always specify a ``name`` - to avoid ambiguity. It is also suggested to - derive the ``name`` from the + to avoid ambiguity. It is also suggested to + derive the ``name`` from the type, using an additional number suffix as necessary. - For example, consider a data file with only one - ``NXentry``. The suggested default + For example, consider a data file with only one + ``NXentry``. The suggested default ``name`` would be ``entry``. For a data file with two or more ``NXentry`` groups, the suggested names would be ``entry1``, ``entry2``, ... - Alternatively, a scientific application such as small-angle + Alternatively, a scientific application such as small-angle scattering might require a different naming procedure; two different ``NXaperture`` groups might be given the names ``beam_defining_slit`` @@ -491,7 +491,7 @@ - A ``groupGroup`` defines the allowed children of a + A ``groupGroup`` defines the allowed children of a ``group`` specification. @@ -499,12 +499,12 @@ - Describe the purpose of this ``group``. + Describe the purpose of this ``group``. This documentation will go into the manual. The first line should summarize as a complete sentence with no line break. (The automatic documentation will pick just the first line as a - summary.) Then a blank line should be added + summary.) Then a blank line should be added before any further documentation. Indentation should be consistent with rules for reStructured text. @@ -514,7 +514,7 @@ - Use an ``attribute`` if additional information + Use an ``attribute`` if additional information needs to be associated with a ``group``. @@ -544,7 +544,7 @@ - Use a ``link`` to refer locally to + Use a ``link`` to refer locally to information placed elsewhere else in the data storage hierarchy. The ``name`` attribute uniquely identifies the element in this ``group``. @@ -557,9 +557,9 @@ The value, as written in the NXDL file, will be a suggestion of the path to the source of the link. For example:: - + - + The value of ``target`` is written using the NeXus class names since this is a suggestion and does not actually use the element names from a particular data file. @@ -612,19 +612,19 @@ - + A ``field`` declares a new element in the component being defined. A ``field`` is synonymous with the HDF4 SDS (Scientific Data Set) and the HDF5 *dataset* terms. Could contain these elements: - + * ``attribute`` * ``dimensions`` * ``doc`` * ``enumeration`` - + Note that a ``field`` element also includes the definitions of the ``basicComponent`` data type. (The ``fieldType`` data type is used internally in the NXDL schema @@ -678,7 +678,7 @@ Presence of the ``signal`` attribute means this field is an ordinate. - + Integer marking this field as plottable data (ordinates). The value indicates the priority of selection or interest. Some facilities only use ``signal=1`` @@ -686,7 +686,7 @@ plottable data of secondary interest. Higher numbers are possible but not common and interpretation is not standard. - + A field with a ``signal`` attribute should not have an ``axis`` attribute. @@ -698,7 +698,7 @@ *field* is discouraged. It is for legacy support. You should use the ``axes`` group attribute (such as in NXdata) instead. - + This attribute contains a string array that defines the independent data fields used in the default plot for all of the dimensions @@ -722,28 +722,28 @@ NOTE: Use of this attribute is discouraged. It is for legacy support. You should use the ``axes`` group attribute (such as in NXdata) instead. - + Presence of the ``axis`` attribute means this field is an abscissa. - + The attribute value is an integer indicating this field as an axis that is part of the data set. The data set is a field with the attribute ``signal=1`` in the same group. The value can range from 1 up to the number of independent axes (abscissae) in the data set. - + A value of ``axis=1``" indicates that this field contains the data for the first independent axis. For example, the X axis in an XY data set. - + A value of ``axis=2`` indicates that this field contains the data for the second independent axis. For example, the Y axis in a 2-D data set. - + A value of ``axis=3`` indicates that this field contains the data for the third independent axis. For example, the Z axis in a 3-D data set. - + A field with an ``axis`` attribute should not have a ``signal`` attribute. @@ -754,7 +754,7 @@ Integer indicating the priority of selection of this field for plotting (or visualization) as an axis. - + Presence of the ``primary`` attribute means this field is an abscissa. @@ -807,11 +807,11 @@ The ``stride`` and ``data_offset`` attributes - are used together to index the array of data items in a + are used together to index the array of data items in a multi-dimensional array. They may be used as an alternative method to address a data array that is not stored in the standard NeXus method of "C" order. - + The ``stride`` list chooses array locations from the data array with each value in the ``stride`` list determining how many elements to move in each dimension. @@ -822,11 +822,11 @@ data array. A value in the ``stride`` list may be positive to move forward or negative to step backward. A value of zero will not step (and is of no particular use). - + See https://support.hdfgroup.org/HDF5/Tutor/phypereg.html or *4. Dataspace Selection Operations* in https://portal.hdfgroup.org/display/HDF5/Dataspaces - + The ``stride`` attribute contains a comma-separated list of integers. (In addition to the required comma delimiter, @@ -849,15 +849,15 @@ multi-dimensional array. They may be used as an alternative method to address a data array that is not stored in the standard NeXus method of "C" order. - + The ``data_offset`` attribute determines the starting coordinates of the data array for each dimension. - + See https://support.hdfgroup.org/HDF5/Tutor/phypereg.html or *4. Dataspace Selection Operations* in https://portal.hdfgroup.org/display/HDF5/Dataspaces - + The ``data_offset`` attribute contains a comma-separated list of integers. (In addition to the required comma delimiter, @@ -875,7 +875,7 @@ This instructs the consumer of the data what the last dimensions of the data are. It allows plotting software to work out the natural way of displaying the data. - + For example a single-element, energy-resolving, fluorescence detector with 512 bins should have ``interpretation="spectrum"``. If the detector is scanned over a 512 x 512 spatial grid, the data reported @@ -883,9 +883,9 @@ In this example, the initial plotting representation should default to data of the same dimensions of a 512 x 512 pixel ``image`` detector where the images where taken at 512 different pressure values. - + In simple terms, the allowed values mean: - + * ``scalar`` = 0-D data to be plotted * ``scaler`` = DEPRECATED, use ``scalar`` * ``spectrum`` = 1-D data to be plotted @@ -931,18 +931,18 @@ - + Any new group or field may expect or require some common attributes. - + .. Could contain these elements: - + * ``doc`` * ``enumeration`` - + (This data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) @@ -1030,7 +1030,7 @@ - + @@ -1046,24 +1046,24 @@ Declares the absolute HDF5 address of an existing field or group. - + The target attribute is added for NeXus to distinguish the HDF5 path to the original dataset. - + Could contain these elements: - + * ``doc`` - + Matching regular expression:: - + (/[a-zA-Z_][\w_]*(:[a-zA-Z_][\w_]*)?)+ - + For example, given a ``/entry/instrument/detector/polar_angle`` field, link it into the ``NXdata`` group (at ``/entry/data/polar_angle``). This would be the NeXus data file structure:: - + /: NeXus/HDF5 data file /entry:NXentry /data:NXdata @@ -1073,7 +1073,7 @@ /detector:NXdetector /polar_angle:NX_NUMBER @target="/entry/instrument/detector/polar_angle" - + @@ -1082,7 +1082,7 @@ Group attribute that provides a URL to a group in another file. More information is described in the *NeXus Programmers Reference*. - + http://manual.nexusformat.org/_static/NeXusIntern.pdf @@ -1090,7 +1090,7 @@ - + @@ -1103,17 +1103,17 @@ Descriptive name of sample - + This is suitable for basic descriptions that do not need extra formatting such as a bullet-list or a table. For more advanced control, use the rules of restructured text, such as in the :ref:`NXdetector` specification. Refer to examples in the NeXus base class NXDL files such as :ref:`NXdata`. Could contain these elements: - + * *any* - - (This data type is used internally in the NXDL schema + + (This data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) Note: @@ -1128,14 +1128,14 @@ - + Each ``symbol`` has a ``name`` and optional documentation. Please provide documentation that indicates what each symbol represents. For example:: - + number of reflecting surfaces number of wavelengths @@ -1183,7 +1183,7 @@ - + @@ -1191,15 +1191,15 @@ Each value is specified using an ``item`` element, such as: ``<item value="Synchrotron X-ray Source" />``. Could contain these elements: - + * ``doc`` * ``item`` - - (This data type is used internally in the NXDL schema + + (This data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) - + :: - + source operating mode @@ -1220,7 +1220,7 @@ Defines the value of one selection for an ``enumeration`` list. Each enumerated item must have a value (it cannot have an empty text node). - + @@ -1245,10 +1245,10 @@ - + - @@ -1275,10 +1275,10 @@ the ``rank`` of the array. For example, these terms describe a 2-D array with lengths (``nsurf``, ``nwl``): - + .. code-block:: xml :linenos: - + @@ -1314,9 +1314,9 @@ - Deprecated: 2016-11-23 telco + Deprecated: 2016-11-23 telco (https://github.com/nexusformat/definitions/issues/330) - + The dimension specification is the same as that in the ``ref`` field, specified either by a relative path, such as ``polar_angle`` or ``../Qvec`` or absolute path, such as @@ -1327,9 +1327,9 @@ - Deprecated: 2016-11-23 telco + Deprecated: 2016-11-23 telco (https://github.com/nexusformat/definitions/issues/330) - + The dimension specification is the same as the ``refindex`` axis within the ``ref`` field. Requires ``ref`` attribute to be present. @@ -1339,9 +1339,9 @@ - Deprecated: 2016-11-23 telco + Deprecated: 2016-11-23 telco (https://github.com/nexusformat/definitions/issues/330) - + The dimension specification is related to the ``refindex`` axis within the ``ref`` field by an offset of ``incr``. Requires ``ref`` and ``refindex`` @@ -1353,9 +1353,9 @@ This dimension is required (true: default) or not required (false). - + The default value is ``true``. - + When ``required="false"`` is specified, all subsequent ``<dim`` nodes (with higher ``index`` value) @@ -1370,10 +1370,10 @@ Rank (number of dimensions) of the data structure. - + Value could be either an unsigned integer or a symbol as defined in the *symbol* table of the NXDL file. - + For example: ``a[5]`` has ``rank="1"`` while ``b[8,5,6,4]`` has ``rank="4"``. See https://en.wikipedia.org/wiki/Rank_%28computer_programming%29 for more details. @@ -1381,5 +1381,5 @@ - + From af49e8ea284cb3189c8e621aef7038338e0fa641 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Jun 2023 17:23:17 +0200 Subject: [PATCH 178/203] NXellips: Use NX_POSINT instead of NX_UINT --- contributed_definitions/NXopt.nxdl.xml | 2 +- contributed_definitions/nyaml/NXopt.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 254b4a21d6..801de867e4 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -408,7 +408,7 @@ optical spectroscopy experiments--> If the parameter_type is `other` a name should be specified here. - + Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 447373da39..15289ceb79 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -298,7 +298,7 @@ NXopt: doc: | If the parameter_type is `other` a name should be specified here. exists: optional - number_of_parameters(NX_UINT): + number_of_parameters(NX_POSINT): doc: | Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at From f91c66d50d377d3bbda24c55e3f2c4bdfbc6075f Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Jun 2023 17:23:50 +0200 Subject: [PATCH 179/203] Use NX_POSINT --- contributed_definitions/NXopt.nxdl.xml | 2 +- contributed_definitions/nyaml/NXopt.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 254b4a21d6..801de867e4 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -408,7 +408,7 @@ optical spectroscopy experiments--> If the parameter_type is `other` a name should be specified here. - + Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 447373da39..15289ceb79 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -298,7 +298,7 @@ NXopt: doc: | If the parameter_type is `other` a name should be specified here. exists: optional - number_of_parameters(NX_UINT): + number_of_parameters(NX_POSINT): doc: | Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at From 4b064d9fae15e25146e3d8563c894b3e0e9ab839 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 10:28:59 +0200 Subject: [PATCH 180/203] revert base class modifications for now --- base_classes/NXbeam.nxdl.xml | 4 +- base_classes/NXdetector.nxdl.xml | 1903 +++++++++++++++--------------- base_classes/NXentry.nxdl.xml | 497 ++++---- base_classes/NXsample.nxdl.xml | 968 ++++++--------- base_classes/NXsensor.nxdl.xml | 3 +- base_classes/NXsource.nxdl.xml | 470 +++----- 6 files changed, 1706 insertions(+), 2139 deletions(-) mode change 100644 => 100755 base_classes/NXentry.nxdl.xml mode change 100644 => 100755 base_classes/NXsample.nxdl.xml diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 42aa076bae..232a75e46d 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -328,8 +328,8 @@ - Points to the path to a field defining the location on which this - depends or the string "." for origin. + Points to the path to a field defining the location on which this + depends or the string "." for origin. diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index 9237df09ea..a6bb0b8c68 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - These symbols will be used below to illustrate the coordination of the - rank and sizes of datasets and the preferred ordering of the - dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering - principle is slowest to fastest. The type of each dimension should - follow the order of scan points, detector output (e.g. pixels), then - time-of-flight (i.e. spectroscopy, spectrometry). Note that the output - of a detector is not limited to single values (0D), lists (1D) and - images (2), but three or higher dimensional arrays can be produced by - a detector at each trigger. - - - - number of scan points (only present in scanning measurements) - - - - - number of detector pixels in the first (slowest) direction - - - - - number of detector pixels in the second (faster) direction - - - - - number of detector pixels in the third (if necessary, fastest) - direction - - - - - number of bins in the time-of-flight histogram - - - - - A detector, detector bank, or multidetector. - - - - Total time of flight - - - - - - - - - - - - - - - - - Total time of flight - - - - - - In DAQ clock pulses - - - - - - - Clock frequency in Hz - - - - - - Identifier for detector (pixels) - Can be multidimensional, if needed - - - - - Data values from the detector. The rank and dimension ordering should follow a principle of - slowest to fastest measurement axes and may be explicitly specified in application definitions. - - Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be - the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions - of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single - scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. - Repetition of an experiment in a time series tends to be used similar to a slow scan axis - and so will often be in the first dimension of the data array. - - The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions - (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an - imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data - will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to - be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. - - Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift - detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. - - The type of each dimension should should follow the order of scan points, detector pixels, - then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) - shown here are merely illustrative of coordination between related datasets. - - - - - - - - - - Title of measurement - - - - - Integral of data as check of data integrity - - - - - - The best estimate of the uncertainty in the data value (array size should match the data field). Where - possible, this should be the standard deviation, which has the same units - as the data. The form data_error is deprecated. - - - - - - - - - - - Offset from the detector center in x-direction. - Can be multidimensional when needed. - - - - - - - - - - - - - - - - - - x-axis offset from detector center - - - - - - Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - This is the distance to the previous component in the - instrument; most often the sample. The usage depends on the - nature of the detector: Most often it is the distance of the - detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - This is the polar angle of the detector towards the previous - component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the polar_angle of the detector assembly. - But there are irregular detectors. - In this - case, the polar_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - This is the azimuthal angle angle of the detector towards - the previous component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the azimuthal_angle of the detector assembly. - But there are irregular detectors. - In this - case, the azimuthal_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - name/manufacturer/model/etc. information - - - - - Serial number for the detector - - - - - Local name for the detector - - - - - Position and orientation of detector - - - - - Solid angle subtended by the detector at the sample - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size. - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size - - - - - - - - - Detector dead time - - - - - - - - - - Detector gas pressure - - - - - - - - - maximum drift space dimension - - - - - Crate number of detector - - - - - - - - Equivalent local term - - - - - - Slot number of detector - - - - - - - - Equivalent local term - - - - - - Input number of detector - - - - - - - - Equivalent local term - - - - - - Description of type such as He3 gas cylinder, He3 PSD, scintillator, - fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ... - - - - - Spectral efficiency of detector with respect to e.g. wavelength - - - - - - - - - - - - - - - - - - - - - - - - - efficiency of the detector - - - - - - - - - - This field can be two things: - - #. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - #. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - - - - - - - - - - - - - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - - - - - - - - - - start time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - stop time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - date of last calibration (geometry and/or efficiency) measurements - - - - - summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations - - - - - How the detector is represented - - - - - - - - - - Elapsed actual counting time - - - - - - - - - Use this group to provide other data related to this NXdetector group. - + + + + + These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the + preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering principle is slowest to fastest. + The type of each dimension should follow the order of scan points, detector output (e.g. pixels), + then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited + to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced + by a detector at each trigger. + + + number of scan points (only present in scanning measurements) + number of detector pixels in the first (slowest) direction + number of detector pixels in the second (faster) direction + number of bins in the time-of-flight histogram + + + + A detector, detector bank, or multidetector. + + + + Total time of flight + + + + + + + + + + + + + + + + + + + Total time of flight + + + + + In DAQ clock pulses + + + + + + + Clock frequency in Hz + + + + + + Identifier for detector (pixels) + Can be multidimensional, if needed + + + + + + Data values from the detector. The rank and dimension ordering should follow a principle of + slowest to fastest measurement axes and may be explicitly specified in application definitions. + + Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be + the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions + of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single + scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. + Repetition of an experiment in a time series tends to be used similar to a slow scan axis + and so will often be in the first dimension of the data array. + + The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions + (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an + imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data + will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to + be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. + + Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift + detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. + + The type of each dimension should should follow the order of scan points, detector pixels, + then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) + shown here are merely illustrative of coordination between related datasets. + + + + + + + + + + + Title of measurement + + + + Integral of data as check of data integrity + + + + + + + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + + + + + + + + + + + + + + Offset from the detector center in x-direction. + Can be multidimensional when needed. + + + + + + + + + + + + + + + + + + + + + x-axis offset from detector center + + + + + + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + name/manufacturer/model/etc. information + + + + Serial number for the detector + + + + Local name for the detector + + + + Position and orientation of detector + + + + Solid angle subtended by the detector at the sample + + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size. + + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size + + + + + + + + + Detector dead time + + + + + + + + + + Detector gas pressure + + + + + + + + + maximum drift space dimension + + + + Crate number of detector + + + + + + + + Equivalent local term + + + + + Slot number of detector + + + + + + + + Equivalent local term + + + + + Input number of detector + + + + + + + + Equivalent local term + + + + + + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + + + + + Spectral efficiency of detector with respect to e.g. wavelength + + + + + + + + + + + + + + + + + + + + + + + + efficiency of the detector + + + + + + + + + + This field can be two things: + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + + + + + + + + + + + + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + + + + + + + + + + start time for each frame, with the ``start`` attribute as absolute reference + + + + + + + stop time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + date of last calibration (geometry and/or efficiency) measurements + + + + + + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + + + + + How the detector is represented + + + + + + + + + + Elapsed actual counting time + + + + + + + + + + + Use this group to provide other data related to this NXdetector group. + + + + + + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + + + + + + + + + + This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + + This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + + + + + The diameter of a cylindrical detector + + + + The acquisition mode of the detector. + + + + + + + + + + + + True when the angular calibration has been applied in the + electronics, false otherwise. + + + + Angular calibration data. + + + + + + + + True when the flat field correction has been applied in the + electronics, false otherwise. + + + + Flat field correction data. + + + + + + + + Errors of the flat field correction data. + The form flatfield_error is deprecated. + + + + + + + + + True when the pixel mask correction has been applied in the + electronics, false otherwise. + + + + + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + + + + + + + + + + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + + + + + + + + + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + + + + + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + + + + + + + + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + + + + + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + + + + + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + + + + + User-specified trigger delay. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + + + + + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + + + + + This is time for each frame. This is exposure_time + readout time. + + + + + + + + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + + + + + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. + + + + + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + + + + + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + + + + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + - - - In order to properly sort the order of the images taken in (for - example) a tomography experiment, a sequence number is stored with each - image. - - - - - - - - This is the x position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - This is the y position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - This is the start number of the first frame of a scan. In protein crystallography measurements one - often scans a couple of frames on a give sample, then does something else, - then returns to the same sample and scans some more frames. Each time with - a new data file. This number helps concatenating such measurements. - - - - - The diameter of a cylindrical detector - - - - - The acquisition mode of the detector. - - - - - - - - - - - - - True when the angular calibration has been applied in the - electronics, false otherwise. - - - - - Angular calibration data. - - - - - - - - - True when the flat field correction has been applied in the - electronics, false otherwise. - - - - - Flat field correction data. - - - - - - - - - Errors of the flat field correction data. - The form flatfield_error is deprecated. - - - - - - - - - True when the pixel mask correction has been applied in the - electronics, false otherwise. - - - - - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - - - - - - - - - This field allow to distinguish different types of exposure to the same detector "data" field. - Some techniques require frequent (re-)calibration inbetween measuremnts and this way of - recording the different measurements preserves the chronological order with is important for - correct processing. - - This is used for example in tomography (`:ref:`NXtomo`) sample projections, - dark and flat images, a magic number is recorded per frame. - - The key is as follows: - - * projection (sample) = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - * background (no sample, but buffer where applicable) = 4 - - In cases where the data is of type :ref:`NXlog` this can also be an NXlog. - - - - - - - - Counting detectors usually are not able to measure all incoming particles, - especially at higher count-rates. Count-rate correction is applied to - account for these errors. - - True when count-rate correction has been applied, false otherwise. - - - - - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - - - - - - - - True when virtual pixel interpolation has been applied, false otherwise. - - When virtual pixel interpolation is applied, values of some pixels may - contain interpolated values. For example, to account for space between - readout chips on a module, physical pixels on edges and corners between - chips may have larger sensor areas and counts may be distributed between - their logical pixels. - - - - - How many bits the electronics reads per pixel. - With CCD's and single photon counting detectors, - this must not align with traditional integer sizes. - This can be 4, 8, 12, 14, 16, ... - - - - - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set delay.. - This is important to know for time resolved experiments. - - - - - User-specified trigger delay. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector hardware after receiving the - trigger signal to when the detector starts to acquire the exposure. - It forms the lower boundary of the trigger_delay_time when the user - does not request an additional delay. - - - - - Time during which no new trigger signal can be accepted. - Typically this is the - trigger_delay_time + exposure_time + readout_time. - This is important to know for time resolved experiments. - - - - - This is time for each frame. This is exposure_time + readout time. - - - - - - - - The gain setting of the detector. This is a detector-specific value - meant to document the gain setting of the detector during data - collection, for detectors with multiple available gain settings. - - Examples of gain settings include: - - * ``standard`` - * ``fast`` - * ``auto`` - * ``high`` - * ``medium`` - * ``low`` - * ``mixed high to medium`` - * ``mixed medium to low`` - - Developers are encouraged to use one of these terms, or to submit - additional terms to add to the list. - - - - - The value at which the detector goes into saturation. - Especially common to CCD detectors, the data - is known to be invalid above this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - The lowest value at which pixels for this detector would be reasonably - measured. The data is known to be invalid below this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - CCD images are sometimes constructed by summing - together multiple short exposures in the - electronics. This reduces background etc. - This is the number of short exposures used to sum - images for an image. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the name of this converter material. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the thickness of this converter material. - - - - - Single photon counter detectors can be adjusted - for a certain energy range in which they - work optimally. This is the energy setting for this. - - - - - For use in special cases where the data in NXdetector - is represented in several parts, each with a separate geometry. - + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape. - - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders. - - - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape. - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders. - - - - - - .. 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. - - - - - Type of electron amplifier, MCP, channeltron, etc. - - - - - Description of the detector type, DLD, Phosphor+CCD, CMOS. - - - - - Voltage applied to detector. - - - - - Voltage applied to the amplifier. - - - - - The low voltage of the amplifier migh not be the ground. - - - - - Size of each imaging sensor chip on the detector. - - - - - Number of imaging sensor chips on the detector. - - - - - Physical size of the pixels of the imaging chip on the detector. - - - - - Number of raw active elements in each dimension. Important for swept scans. - - - - - raw data output from the detector - + + + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the detector is the center of the first pixel. - In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + + + + + .. 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. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml old mode 100644 new mode 100755 index d110e2bcfb..2bb4ca533e --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -1,10 +1,10 @@ - + - - - (**required**) :ref:`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. - - - - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXdata` group contains the data - to be shown by default. - It is used to resolve ambiguity when - one :ref:`NXdata` group exists. - The value :ref:`names <validItemName>` a child group. If that group - itself has a ``default`` attribute, continue this chain until an - :ref:`NXdata` group is reached. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` - section. - - - - - The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 - - - - - - ISIS Muon IDF_Version - - - - - Extended title for entry - - - - - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - - - - - Brief summary of the experiment, including key objectives. - - - - - Description of the full experiment (document in pdf, latex, ...) - - - - - User or Data Acquisition defined group of NeXus files or NXentry - - - - - Brief summary of the collection, including grouping criteria. - - - - - Unique identifier for the measurement, defined by the facility. - - - - - UUID identifier for the measurement. - - - - Version of UUID used - - - - - - Reserved for future use by NIAC. - - See https://github.com/nexusformat/definitions/issues/382 - - - - - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms which must be - the name of the NXDL file (case sensitive without the file extension) - that the NXDL schema is defined in. - - For example the ``definition`` field for a file that conformed to the - *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. - - This field is provided so that :ref:`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Local NXDL schema extended from the entry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the entry. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Starting time of measurement - - - - - Ending time of measurement - - - - - Duration of measurement - - - - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - - - - - Such as "2007-3". Some user facilities organize their beam time into run cycles. - - - - - Name of program used to generate this file - - - - Program version number - - - - - configuration of the program - - - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - - - - - City and country where the experiment took place - - - - - Start time of experimental run that includes the current - measurement, for example a beam time. - - - - - End time of experimental run that includes the current - measurement, for example a beam time. - - - - - Name of the institution hosting the facility - - - - - Name of the experimental facility - - - - - Name of the laboratory or beamline - - - - - Notes describing entry - - - - - A small image that is representative of the entry. An example of this is - a 640x480 jpeg image automatically produced by a low resolution plot - of the NXdata. - - - - The mime type should be an ``image/*`` - - - - - - - - - - - - - - - + + + + + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXdata` group contains the data + to be shown by default. + It is used to resolve ambiguity when + one :ref:`NXdata` group exists. + The value :ref:`names <validItemName>` a child group. If that group + itself has a ``default`` attribute, continue this chain until an + :ref:`NXdata` group is reached. + + For more information about how NeXus identifies the default + plottable data, see the + :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` + section. + + + + + (**required**) :ref:`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. + + + + The data group + + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 + + + + + + + ISIS Muon IDF_Version + + + Extended title for entry + + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + + + Brief summary of the experiment, including key objectives. + + + Description of the full experiment (document in pdf, latex, ...) + + + User or Data Acquisition defined group of NeXus files or NXentry + + + Brief summary of the collection, including grouping criteria. + + + unique identifier for the measurement, defined by the facility. + + + UUID identifier for the measurement. + Version of UUID used + + + + Reserved for future use by NIAC. + + See https://github.com/nexusformat/definitions/issues/382 + + + + + (alternate use: see same field in :ref:`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms which must be + the name of the NXDL file (case sensitive without the file extension) + that the NXDL schema is defined in. + + For example the ``definition`` field for a file that conformed to the + *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. + + This field is provided so that :ref:`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + + NXDL version number + URL of NXDL file + + + + Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry. + + NXDL version number + URL of NXDL file + + + Starting time of measurement + + + Ending time of measurement + + + Duration of measurement + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + Name of program used to generate this file + Program version number + configuration of the program + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + Notes describing entry + + + + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + + + The mime type should be an ``image/*`` + + + + + + + + + + + + + + diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml old mode 100644 new mode 100755 index 1834d3f4d0..43bb316334 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - symbolic array lengths to be coordinated between various fields - - - - number of compositions - - - - - number of temperatures - - - - - number of values in applied electric field - - - - - number of values in applied magnetic field - - - - - number of values in applied pressure field - - - - - number of values in applied stress field - - - - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - - - - Descriptive name of sample - - - - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * 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. - - * This is the *Hill* system used by Chemical Abstracts. - - - - - Sample temperature. This could be a scanned variable - - - - - - - - - Applied electric field - - - - - + + + + symbolic array lengths to be coordinated between various fields + number of compositions + number of temperatures + number of values in applied electric field + number of values in applied magnetic field + number of values in applied pressure field + number of values in applied stress field + + + + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + + + Descriptive name of sample + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * 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. + + * This is the *Hill* system used by Chemical Abstracts. + + + + Sample temperature. This could be a scanned variable + + + + + + Applied electric field + + + - - - - - + + + + + - - - - Applied magnetic field - - - - - + + + Applied magnetic field + + + - - - - - + + + + + - - - - Applied external stress field - - - - - + + + Applied external stress field + + + - - - - - + + + + + - - - - Applied pressure - - - - - - - - - Sample changer position - - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - Unit cell parameters (lengths and angles) - - - - - - - - - Volume of the unit cell - - - - - - - - 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. - - - - - - - - - - Mass of sample - - - - - - - - Density of sample - - - - - - - - Relative Molecular Mass of sample - - - - - - - - - - - - - - - - - - - - - - The atmosphere will be one of the components, which is where - its details will be stored; the relevant components will be - indicated by the entry in the sample_component member. - - - - - - - - - - - - - - Description of the sample - - - - - Date of preparation of the sample - - - - - The position and orientation of the center of mass of the sample - - - - - Details of beam incident on sample - used to calculate sample/beam interaction - point - - - - - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - - - - - Details of the component of the sample and/or can - - - - - - - - Type of component - - - - - - - - - - - - - - Concentration of each component - - - - - - - - Volume fraction of each component - - - - - - - - Scattering length density of each component - - - - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - - Crystallographic space group - - - - - - - - Crystallographic point group, deprecated if space_group present - - - + + + Applied pressure + + + + + + Sample changer position + + + Crystallography unit cell parameters a, b, and c + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + Unit cell parameters (lengths and angles) + + + + + + + Volume of the unit cell + + + + + + + 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. + + + + + + + + + Mass of sample + + + + + + Density of sample + + + + + + Relative Molecular Mass of sample + + + + + + + + + + + + + + + + + + + + + The atmosphere will be one of the components, which is where + its details will be stored; the relevant components will be + indicated by the entry in the sample_component member. + + + + + + + + + + + + + + Description of the sample + + + + Date of preparation of the sample + + + The position and orientation of the center of mass of the sample + + + Details of beam incident on sample - used to calculate sample/beam interaction point + + + + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + + + + Details of the component of the sample and/or can + + + + + + Type of component + + + + + + + + + + + + Concentration of each component + + + + + + Volume fraction of each component + + + + + + Scattering length density of each component + + + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + Crystallographic space group + + + + + + Crystallographic point group, deprecated if space_group present + + - - - - Path length through sample/can for simple case when - it does not vary with scattering direction - - - - - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - - - - - sample thickness - - - - - Identification number or signatures of the sample used. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (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 - - - - - Physical state of the sample - - - - - Chemical purity of the sample - - - - - Surface termination of the sample (if crystalline) - - - - - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - - - - - Full chemical name of the sample - - - - - CAS registry number of the sample chemical content. - - - - - Gases might be fluxed on the surface for various reasons. Chemical designation, - or residual. - - - - - In the case of a fixed pressure measurement this is the scalar pressure. In the - case of an experiment in which pressure changes, or anyway is recorded, this is - an array of length m of pressures. - - - - - Element of evaporated surface dopant such as alkali or other - - - - - Nominal thickness of the evaporated dopant - - - - - Voltage applied to sample and sample holder. - - - - - Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition - etc.) - - - - - Name of the sample vendor (company or research group) - - - - - Material of the substrate in direct contact with the sample. - - - - - Physical state of the substrate, similar options to sample_state - - - - - Current to neutralize the photoemission current. This field may also be found in - NXmanpulator if present. - - - - - Possible bias of the sample with respect to analyser ground. This field may also - be found as sample_bias in NXmanipulator if present. - - - - - Further notes. - - - - - As a function of Wavelength - - - - - temperature.value is a link to e.g. temperature_env.sensor1.value - - - - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - - - - - Additional sample temperature environment information - - - - - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - - - - - magnetic_field_log.value is a link to e.g. - magnetic_field_env.sensor1.value_log.value - - - - - Additional sample magnetic environment information - - - - - value sent to user's sample setup - - - - - logged value (or logic state) read from user's setup - - - - - 20 character fixed length sample description for legends - - - - - - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - - - - - Any positioner (motor, PZT, ...) used to locate the sample - - - - - This group describes the shape of the sample - - + + + + Path length through sample/can for simple case when + it does not vary with scattering direction + + + + + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + + + + sample thickness + + + As a function of Wavelength + + + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + + + Additional sample temperature environment information + + + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + + + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value + + + Additional sample magnetic environment information + + + value sent to user's sample setup + + + logged value (or logic state) read from user's setup + + + 20 character fixed length sample description for legends + + + + + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + + + + Any positioner (motor, PZT, ...) used to locate the sample + + + + This group describes the shape of the sample + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index 4eaf594e7b..cdfc11ab04 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -58,7 +58,6 @@ - @@ -73,7 +72,7 @@ Examples (suggestions but not restrictions): :Temperature: - J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe + J | K | T | E | R | S | Pt100 | Rh/Fe :pH: Hg/Hg2Cl2 | Ag/AgCl | ISFET :Ion selective electrode: diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 50f743ece4..85900d3f03 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -1,9 +1,9 @@ - + - - - The neutron or x-ray storage ring/facility. - - - - Effective distance from sample - Distance as seen by radiation from sample. This number should be negative - to signify that it is upstream of the sample. - - - - - Name of source - - - - short name for source, perhaps the acronym - - - - - - type of radiation source (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - - - - - - - - - - - type of radiation probe (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - - - Source power - - - - - Source emittance (nm-rad) in X (horizontal) direction. - - - - - Source emittance (nm-rad) in Y (horizontal) direction. - - - - - particle beam size in x - - - - - particle beam size in y - - - - - Source intensity/area (example: s-1 cm-2) - - - - - Source energy. - For storage rings, this would be the particle beam energy. - For X-ray tubes, this would be the excitation voltage. - - - - - Accelerator, X-ray tube, or storage ring current - - - - - Accelerator voltage - - - - - Frequency of pulsed source - - - - - Period of pulsed source - - - - - Pulsed source target material - - - - - - - - - - - - - - - - - - - any source/facility related messages/events that - occurred during the experiment - - - - - For storage rings, description of the bunch pattern. - This is useful to describe irregular bunch patterns. - - - - name of the bunch pattern + + The neutron or x-ray storage ring/facility. + + + Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample. + + + + Name of source + + short name for source, perhaps the acronym + + + + type of radiation source (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + + + + type of radiation probe (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + Source power + + + Source emittance (nm-rad) in X (horizontal) direction. + + + Source emittance (nm-rad) in Y (horizontal) direction. + + + particle beam size in x + + + particle beam size in y + + + Source intensity/area (example: s-1 cm-2) + + + + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. + + + + Accelerator, X-ray tube, or storage ring current + + + Accelerator voltage + + + Frequency of pulsed source + + + Period of pulsed source + + + Pulsed source target material + + + + + + + + + + + + + any source/facility related messages/events that + occurred during the experiment + + + + + For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns. + + name of the bunch pattern + + + For storage rings, the number of bunches in use. + + + For storage rings, temporal length of the bunch + + + For storage rings, time between bunches + + + temporal width of source pulse + + + source pulse shape + + + source operating mode + + for storage rings + for storage rings + + + + + Is the synchrotron operating in top_up mode? + + + For storage rings, the current at the end of the most recent injection. + date and time of the most recent injection. + + + + "Engineering" location of source. + + + + + This group describes the shape of the beam line component - - - - - For storage rings, the number of bunches in use. - - - - - For storage rings, temporal length of the bunch - - - - - For storage rings, time between bunches - - - - - temporal width of source pulse - - - - - - source pulse shape - - - - - - source operating mode - - - - - for storage rings - - - - - for storage rings - - - - - - - - - Is the synchrotron operating in top_up mode? - - - - - For storage rings, the current at the end of the most recent injection. - - - - date and time of the most recent injection. - - - - - - The center photon energy of the source, before it is - monochromatized or converted - - - - - The center wavelength of the source, before it is - monochromatized or converted - - - - - For pulsed sources, the energy of a single pulse - - - - - For pulsed sources, the pulse energy divided - by the pulse duration - - - - - Some facilities tag each bunch. - First bunch of the measurement - - - - - Last bunch of the measurement - - - - - "Engineering" location of source. - - - - - This group describes the shape of the beam line component - - - - - The wavelength or energy distribution of the source - - + + + The wavelength or energy distribution of the source + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. - - .. image:: source/source.png - :width: 40% + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image:: source/source.png + :width: 40% + - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. From ce57c7a1505f4717091a9bbdbde68ad061406994 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 10:50:06 +0200 Subject: [PATCH 181/203] reverting linking to first reference --- Makefile | 1 - dev_tools/docs/nxdl.py | 44 ++---------------------------------------- requirements.txt | 3 --- 3 files changed, 2 insertions(+), 46 deletions(-) diff --git a/Makefile b/Makefile index 44c076c341..ae556d7339 100644 --- a/Makefile +++ b/Makefile @@ -6,7 +6,6 @@ PYTHON = python3 SPHINX = sphinx-build BUILD_DIR = "build" -export NEXUS_DEF_PATH = $(shell pwd) .PHONY: help install style autoformat test clean prepare html pdf impatient-guide all local diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 9fee58a9c8..8da3ebbc05 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -7,7 +7,6 @@ from typing import Optional import lxml -from pynxtools.nexus import nexus as pynxtools_nxlib from ..globals.directories import get_nxdl_root from ..globals.errors import NXDLParseError @@ -507,7 +506,7 @@ def _print_attribute(self, ns, kind, node, optional, indent, parent_path): ) self._print(f"{indent}.. index:: {index_name} ({kind} attribute)\n") self._print( - f"{indent}**@{name}**: {optional}{self._format_type(node)}{self._format_units(node)} {self.get_first_parent_ref(f'{parent_path}/{name}', 'attribute')}\n" + f"{indent}**@{name}**: {optional}{self._format_type(node)}{self._format_units(node)}\n" ) self._print_doc(indent + self._INDENTATION_UNIT, ns, node) node_list = node.xpath("nx:enumeration", namespaces=ns) @@ -550,7 +549,6 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): f"{self._format_type(node)}" f"{dims}" f"{self._format_units(node)}" - f" {self.get_first_parent_ref(f'{parent_path}/{name}', 'field')}" "\n" ) @@ -587,9 +585,7 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): # target = hTarget.replace(".. _", "").replace(":\n", "") # TODO: https://github.com/nexusformat/definitions/issues/1057 self._print(f"{indent}{hTarget}") - self._print( - f"{indent}**{name}**: {optional_text}{typ} {self.get_first_parent_ref(f'{parent_path}/{name}', 'group')}\n" - ) + self._print(f"{indent}**{name}**: {optional_text}{typ}\n") self._print_if_deprecated(ns, node, indent + self._INDENTATION_UNIT) self._print_doc(indent + self._INDENTATION_UNIT, ns, node) @@ -628,39 +624,3 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): def _print(self, *args, end="\n"): # TODO: change instances of \t to proper indentation self._rst_lines.append(" ".join(args) + end) - - def get_first_parent_ref(self, path, tag): - nx_name = path[1 : path.find("/", 1)] - path = path[path.find("/", 1) :] - - parents = pynxtools_nxlib.get_inherited_nodes(path, nx_name)[2] - if len(parents) > 1: - parent = parents[1] - parent_path = parent_display_name = parent.attrib["nxdlpath"] - parent_path_segments = parent_path[1:].split("/") - parent_def_name = parent.attrib["nxdlbase"][ - parent.attrib["nxdlbase"] - .rfind("/") : parent.attrib["nxdlbase"] - .rfind(".nxdl") - ] - - # Case where the first parent is a base_class - if parent_path_segments[0] == "": - return f":ref:`<{parent_def_name[1:]}> <{parent_def_name[1:]}>`" - - parent_display_name = ( - f"{parent_def_name[1:]}/.../{parent_path_segments[-1]}" - if len(parent_path_segments) > 1 - else f"{parent_def_name[1:]}/{parent_path_segments[-1]}" - ) - if tag == "attribute": - pos_of_right_slash = parent_path.rfind("/") - parent_path = ( - parent_path[:pos_of_right_slash] - + "@" - + parent_path[pos_of_right_slash + 1 :] - ) - return ( - f":ref:`<{parent_display_name}> <{parent_def_name}{parent_path}-{tag}>`" - ) - return "" diff --git a/requirements.txt b/requirements.txt index 8b22819ff4..6d024bda3a 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5,7 +5,6 @@ pyyaml # Documentation building sphinx>=5 sphinx-tabs -sphinx-comments # Testing pytest @@ -14,5 +13,3 @@ pytest black>=22.3 flake8>=4 isort>=5.10 - -pynxtools>=0.0.3 \ No newline at end of file From c5f2796789dd83353a8a40b491b117ecef0f7640 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 15 Jun 2023 11:21:35 +0200 Subject: [PATCH 182/203] Fix bullet list in NXopt --- contributed_definitions/NXopt.nxdl.xml | 16 ++++++++-------- contributed_definitions/nyaml/NXopt.yaml | 16 ++++++++-------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 801de867e4..570d18555e 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -422,13 +422,13 @@ optical spectroscopy experiments--> should be as follows: * Order the sensors according to number_of_parameters starting - with the lowest number. If number_of_parameters is equal for - two sensors order them alphabetically (sensor/parameter name). + with the lowest number. If number_of_parameters is equal for + two sensors order them alphabetically (sensor/parameter name). * The first sensor's j parameters should be ordered in the - following way. The first N_measurements/number_of_parameters - entries of the vector contain the first parameter (a1), the - second N_measurements/number_of_parameters contain the second - parameter (a2) etc., so the vector looks like: + following way. The first N_measurements/number_of_parameters + entries of the vector contain the first parameter (a1), the + second N_measurements/number_of_parameters contain the second + parameter (a2) etc., so the vector looks like: [ a1,a1,...,a1, a2,a2,...,a2, @@ -436,7 +436,7 @@ optical spectroscopy experiments--> aj,aj,...aj ] * The kth sensor's m parameters should be ordered in the - following way: + following way: [ p1,...p1,p2,...,p2,...pm,...,pm, p1,...p1,p2,...,p2,...pm,...,pm, @@ -444,7 +444,7 @@ optical spectroscopy experiments--> p1,...p1,p2,...,p2,...pm,...,pm ] * The last sensor's n parameters should be ordered in the - following way: + following way: [ z1,z2,...,zn, z1,z2,...,zn, diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 15289ceb79..5073a3d5d6 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -312,13 +312,13 @@ NXopt: should be as follows: * Order the sensors according to number_of_parameters starting - with the lowest number. If number_of_parameters is equal for - two sensors order them alphabetically (sensor/parameter name). + with the lowest number. If number_of_parameters is equal for + two sensors order them alphabetically (sensor/parameter name). * The first sensor's j parameters should be ordered in the - following way. The first N_measurements/number_of_parameters - entries of the vector contain the first parameter (a1), the - second N_measurements/number_of_parameters contain the second - parameter (a2) etc., so the vector looks like: + following way. The first N_measurements/number_of_parameters + entries of the vector contain the first parameter (a1), the + second N_measurements/number_of_parameters contain the second + parameter (a2) etc., so the vector looks like: [ a1,a1,...,a1, a2,a2,...,a2, @@ -326,7 +326,7 @@ NXopt: aj,aj,...aj ] * The kth sensor's m parameters should be ordered in the - following way: + following way: [ p1,...p1,p2,...,p2,...pm,...,pm, p1,...p1,p2,...,p2,...pm,...,pm, @@ -334,7 +334,7 @@ NXopt: p1,...p1,p2,...,p2,...pm,...,pm ] * The last sensor's n parameters should be ordered in the - following way: + following way: [ z1,z2,...,zn, z1,z2,...,zn, From 3853d7622a65bc0d23743bbc3fee9ba3280fd624 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 15 Jun 2023 13:50:33 +0200 Subject: [PATCH 183/203] Fixed problem of insufficiently large preset to handle more than seven layer deep nested lists in latex, spotted than the issue that the plain amssymb-package command textnormal nor textrm gets properly compiled in latex even though writing :math: in yaml and xml causes this command to get correctly interpreted in rst and the html pages, fixed this for now by reverting the usage of the textnormal command, with this the pdf compiles in the make pdf build stage now, but the resulting pdf has some very long strings in each anchor lists of some (base) nx classes which run out of margin, a possible fix to this could be to use the seqlist package based on https://tex.stackexchange.com/questions/324042/linebreaks-in-long-character-strings --- .github/workflows/ci.yaml | 1 + .../NXapm_paraprobe_results_nanochem.nxdl.xml | 9 +++------ .../nyaml/NXapm_paraprobe_results_nanochem.yaml | 12 ++++++------ manual/source/conf.py | 6 ++++-- 4 files changed, 14 insertions(+), 14 deletions(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 34dc020d45..76d726fef6 100644 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -66,6 +66,7 @@ jobs: texlive-latex-recommended \ texlive-latex-extra \ texlive-fonts-recommended + tex --version - name: Generate build files run: | diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index 1e5015b5d1..2dd4f6bfff 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -1071,8 +1071,7 @@ details about specific features--> Details for features which are (closed) objects. - Identifier have to exist in feature_identifier - :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. + Identifier have to exist in feature_identifier. @@ -1333,8 +1332,7 @@ these would be polylines etc--> which have been reconstructed and combinatorially closed with processing their partial triangulated_surface_mesh (hole filling, refinement). - Identifier have to exist in feature_identifier - :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. + Identifier have to exist in feature_identifier. @@ -1353,8 +1351,7 @@ these would be polylines etc--> Details for those proxies close to edge, i.e. those which have at least one ion which lays closer to a modelled edge of the dataset than threshold. - Identifier have to exist in feature_identifier - :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. + Identifier have to exist in feature_identifier. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml index ab81db5353..b39b99d231 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml @@ -888,8 +888,8 @@ NXapm_paraprobe_results_nanochem: exists: optional doc: | Details for features which are (closed) objects. - Identifier have to exist in feature_identifier - :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. + Identifier have to exist in feature_identifier. + # :math:`\textrm{identifier} \in \textrm{feature_identifier}`. # ##MK::constraints! feature_identifier(NX_UINT): unit: NX_UNITLESS @@ -1128,8 +1128,8 @@ NXapm_paraprobe_results_nanochem: which have been reconstructed and combinatorially closed with processing their partial triangulated_surface_mesh (hole filling, refinement). - Identifier have to exist in feature_identifier - :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. + Identifier have to exist in feature_identifier. + # :math:`\textrm{identifier} \in \textrm{feature_identifier}`. # ##MK::constraints feature_identifier are a subset of the parent! feature_identifier(NX_UINT): unit: NX_UNITLESS @@ -1148,8 +1148,8 @@ NXapm_paraprobe_results_nanochem: Details for those proxies close to edge, i.e. those which have at least one ion which lays closer to a modelled edge of the dataset than threshold. - Identifier have to exist in feature_identifier - :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. + Identifier have to exist in feature_identifier. + # :math:`\textrm{identifier} \in \textrm{feature_identifier}`. # ##MK::constraints! feature_identifier(NX_UINT): unit: NX_UNITLESS diff --git a/manual/source/conf.py b/manual/source/conf.py index 51b35e4bb3..2e6dfb363d 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -93,6 +93,8 @@ # -- Options for Latex output ------------------------------------------------- latex_elements = { - 'maxlistdepth':7, # some application definitions are deeply nested - 'preamble': '\\usepackage{amsbsy}\n' + 'maxlistdepth':25, # some application definitions are deeply nested + 'preamble': r''' + \usepackage{amsbsy} + \listfiles''' } From 5734ba80e45ccb4f50f00cc011beedc88d874531 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 14:30:46 +0200 Subject: [PATCH 184/203] removing nyaml files --- applications/nyaml/NXarchive.yaml | 281 -- applications/nyaml/NXarpes.yaml | 226 -- applications/nyaml/NXcanSAS.yaml | 2422 ---------------- applications/nyaml/NXdirecttof.yaml | 102 - applications/nyaml/NXfluo.yaml | 165 -- applications/nyaml/NXindirecttof.yaml | 111 - applications/nyaml/NXiqproc.yaml | 201 -- applications/nyaml/NXlauetof.yaml | 244 -- applications/nyaml/NXmonopd.yaml | 223 -- applications/nyaml/NXmx.yaml | 1744 ----------- applications/nyaml/NXrefscan.yaml | 197 -- applications/nyaml/NXreftof.yaml | 214 -- applications/nyaml/NXsas.yaml | 369 --- applications/nyaml/NXsastof.yaml | 312 -- applications/nyaml/NXscan.yaml | 181 -- applications/nyaml/NXspe.yaml | 128 - applications/nyaml/NXsqom.yaml | 211 -- applications/nyaml/NXstxm.yaml | 366 --- applications/nyaml/NXtas.yaml | 350 --- applications/nyaml/NXtofnpd.yaml | 233 -- applications/nyaml/NXtofraw.yaml | 255 -- applications/nyaml/NXtofsingle.yaml | 244 -- applications/nyaml/NXtomo.yaml | 279 -- applications/nyaml/NXtomophase.yaml | 292 -- applications/nyaml/NXtomoproc.yaml | 217 -- applications/nyaml/NXxas.yaml | 212 -- applications/nyaml/NXxasproc.yaml | 147 - applications/nyaml/NXxbase.yaml | 308 -- applications/nyaml/NXxeuler.yaml | 173 -- applications/nyaml/NXxkappa.yaml | 174 -- applications/nyaml/NXxlaue.yaml | 109 - applications/nyaml/NXxlaueplate.yaml | 73 - applications/nyaml/NXxnb.yaml | 160 -- applications/nyaml/NXxrot.yaml | 155 - base_classes/nyaml/NXaperture.yaml | 168 -- base_classes/nyaml/NXattenuator.yaml | 206 -- base_classes/nyaml/NXbeam.yaml | 621 ---- base_classes/nyaml/NXbeam_stop.yaml | 207 -- base_classes/nyaml/NXbending_magnet.yaml | 210 -- base_classes/nyaml/NXcapillary.yaml | 163 -- base_classes/nyaml/NXcite.yaml | 112 - base_classes/nyaml/NXcollection.yaml | 102 - base_classes/nyaml/NXcollimator.yaml | 196 -- base_classes/nyaml/NXcrystal.yaml | 667 ----- .../nyaml/NXcylindrical_geometry.yaml | 169 -- base_classes/nyaml/NXdata.yaml | 807 ------ base_classes/nyaml/NXdetector.yaml | 1708 ----------- base_classes/nyaml/NXdetector_group.yaml | 182 -- base_classes/nyaml/NXdetector_module.yaml | 302 -- base_classes/nyaml/NXdisk_chopper.yaml | 322 --- base_classes/nyaml/NXentry.yaml | 444 --- base_classes/nyaml/NXenvironment.yaml | 120 - base_classes/nyaml/NXevent_data.yaml | 220 -- base_classes/nyaml/NXfermi_chopper.yaml | 210 -- base_classes/nyaml/NXfilter.yaml | 373 --- base_classes/nyaml/NXflipper.yaml | 159 -- base_classes/nyaml/NXfresnel_zone_plate.yaml | 178 -- base_classes/nyaml/NXgeometry.yaml | 128 - base_classes/nyaml/NXgrating.yaml | 202 -- base_classes/nyaml/NXguide.yaml | 416 --- base_classes/nyaml/NXinsertion_device.yaml | 203 -- base_classes/nyaml/NXinstrument.yaml | 144 - base_classes/nyaml/NXlog.yaml | 252 -- base_classes/nyaml/NXmirror.yaml | 346 --- base_classes/nyaml/NXmoderator.yaml | 193 -- base_classes/nyaml/NXmonitor.yaml | 293 -- base_classes/nyaml/NXmonochromator.yaml | 197 -- base_classes/nyaml/NXnote.yaml | 116 - base_classes/nyaml/NXobject.yaml | 44 - base_classes/nyaml/NXoff_geometry.yaml | 197 -- base_classes/nyaml/NXorientation.yaml | 111 - base_classes/nyaml/NXparameters.yaml | 75 - base_classes/nyaml/NXpdb.yaml | 329 --- base_classes/nyaml/NXpinhole.yaml | 125 - base_classes/nyaml/NXpolarizer.yaml | 135 - base_classes/nyaml/NXpositioner.yaml | 200 -- base_classes/nyaml/NXprocess.yaml | 111 - base_classes/nyaml/NXreflections.yaml | 1266 -------- base_classes/nyaml/NXroot.yaml | 180 -- base_classes/nyaml/NXsample.yaml | 844 ------ base_classes/nyaml/NXsample_component.yaml | 275 -- base_classes/nyaml/NXsensor.yaml | 324 --- base_classes/nyaml/NXshape.yaml | 143 - base_classes/nyaml/NXslit.yaml | 141 - base_classes/nyaml/NXsource.yaml | 422 --- base_classes/nyaml/NXsubentry.yaml | 344 --- base_classes/nyaml/NXtransformations.yaml | 406 --- base_classes/nyaml/NXtranslation.yaml | 102 - base_classes/nyaml/NXuser.yaml | 145 - base_classes/nyaml/NXvelocity_selector.yaml | 198 -- base_classes/nyaml/NXxraylens.yaml | 220 -- .../nyaml/NXaberration.yaml | 29 - .../nyaml/NXaberration_model.yaml | 66 - .../nyaml/NXaberration_model_ceos.yaml | 70 - .../nyaml/NXaberration_model_nion.yaml | 38 - contributed_definitions/nyaml/NXadc.yaml | 10 - .../nyaml/NXaperture_em.yaml | 27 - contributed_definitions/nyaml/NXapm.yaml | 1549 ---------- .../NXapm_composition_space_results.yaml | 398 --- .../nyaml/NXapm_input_ranging.yaml | 33 - .../nyaml/NXapm_input_reconstruction.yaml | 26 - .../NXapm_paraprobe_config_clusterer.yaml | 367 --- .../NXapm_paraprobe_config_distancer.yaml | 186 -- .../NXapm_paraprobe_config_intersector.yaml | 251 -- .../NXapm_paraprobe_config_nanochem.yaml | 892 ------ .../nyaml/NXapm_paraprobe_config_ranger.yaml | 225 -- .../NXapm_paraprobe_config_selector.yaml | 89 - .../NXapm_paraprobe_config_spatstat.yaml | 273 -- .../NXapm_paraprobe_config_surfacer.yaml | 205 -- .../NXapm_paraprobe_config_tessellator.yaml | 186 -- .../NXapm_paraprobe_config_transcoder.yaml | 69 - .../NXapm_paraprobe_results_clusterer.yaml | 437 --- .../NXapm_paraprobe_results_distancer.yaml | 330 --- .../NXapm_paraprobe_results_intersector.yaml | 326 --- .../NXapm_paraprobe_results_nanochem.yaml | 1732 ----------- .../nyaml/NXapm_paraprobe_results_ranger.yaml | 370 --- .../NXapm_paraprobe_results_selector.yaml | 233 -- .../NXapm_paraprobe_results_spatstat.yaml | 309 -- .../NXapm_paraprobe_results_surfacer.yaml | 413 --- .../NXapm_paraprobe_results_tessellator.yaml | 585 ---- .../NXapm_paraprobe_results_transcoder.yaml | 490 ---- .../nyaml/NXbeam_path.yaml | 315 -- .../nyaml/NXbeam_splitter.yaml | 311 -- .../nyaml/NXcalibration.yaml | 51 - .../nyaml/NXcg_alpha_complex.yaml | 83 - .../nyaml/NXcg_cylinder_set.yaml | 112 - .../nyaml/NXcg_ellipsoid_set.yaml | 87 - .../nyaml/NXcg_face_list_data_structure.yaml | 169 -- .../nyaml/NXcg_geodesic_mesh.yaml | 28 - contributed_definitions/nyaml/NXcg_grid.yaml | 114 - .../nyaml/NXcg_half_edge_data_structure.yaml | 115 - .../nyaml/NXcg_hexahedron_set.yaml | 178 -- .../nyaml/NXcg_marching_cubes.yaml | 39 - .../nyaml/NXcg_parallelogram_set.yaml | 132 - .../nyaml/NXcg_point_set.yaml | 55 - .../nyaml/NXcg_polygon_set.yaml | 171 -- .../nyaml/NXcg_polyhedron_set.yaml | 131 - .../nyaml/NXcg_polyline_set.yaml | 131 - .../nyaml/NXcg_roi_set.yaml | 13 - .../nyaml/NXcg_sphere_set.yaml | 76 - .../nyaml/NXcg_tetrahedron_set.yaml | 122 - .../nyaml/NXcg_triangle_set.yaml | 79 - .../nyaml/NXcg_triangulated_surface_mesh.yaml | 27 - .../nyaml/NXcg_unit_normal_set.yaml | 33 - contributed_definitions/nyaml/NXchamber.yaml | 11 - .../nyaml/NXchemical_composition.yaml | 34 - .../nyaml/NXcircuit_board.yaml | 17 - .../nyaml/NXclustering.yaml | 67 - .../nyaml/NXcollectioncolumn.yaml | 40 - .../nyaml/NXcontainer.yaml | 294 -- .../nyaml/NXcoordinate_system_set.yaml | 116 - .../nyaml/NXcorrector_cs.yaml | 54 - .../nyaml/NXcs_computer.yaml | 32 - contributed_definitions/nyaml/NXcs_cpu.yaml | 9 - .../nyaml/NXcs_filter_boolean_mask.yaml | 59 - contributed_definitions/nyaml/NXcs_gpu.yaml | 10 - .../nyaml/NXcs_io_obj.yaml | 17 - .../nyaml/NXcs_io_sys.yaml | 7 - .../nyaml/NXcs_mm_sys.yaml | 9 - contributed_definitions/nyaml/NXcs_prng.yaml | 44 - .../nyaml/NXcs_profiling.yaml | 106 - .../nyaml/NXcs_profiling_event.yaml | 52 - contributed_definitions/nyaml/NXcsg.yaml | 119 - .../nyaml/NXcxi_ptycho.yaml | 440 --- contributed_definitions/nyaml/NXdac.yaml | 10 - .../nyaml/NXdeflector.yaml | 27 - .../nyaml/NXdelocalization.yaml | 83 - .../nyaml/NXdispersion.yaml | 11 - .../nyaml/NXdispersion_function.yaml | 73 - .../NXdispersion_repeated_parameter.yaml | 30 - .../nyaml/NXdispersion_single_parameter.yaml | 14 - .../nyaml/NXdispersion_table.yaml | 48 - .../nyaml/NXdispersive_material.yaml | 177 -- .../nyaml/NXdistortion.yaml | 54 - .../nyaml/NXebeam_column.yaml | 55 - .../nyaml/NXelectronanalyser.yaml | 74 - .../nyaml/NXelectrostatic_kicker.yaml | 105 - .../nyaml/NXellipsometry.yaml | 265 -- contributed_definitions/nyaml/NXem.yaml | 2538 ----------------- contributed_definitions/nyaml/NXem_ebsd.yaml | 1700 ----------- .../nyaml/NXem_ebsd_conventions.yaml | 325 --- .../NXem_ebsd_crystal_structure_model.yaml | 150 - .../nyaml/NXenergydispersion.yaml | 37 - .../nyaml/NXevent_data_em.yaml | 195 -- .../nyaml/NXevent_data_em_set.yaml | 8 - .../nyaml/NXfabrication.yaml | 17 - contributed_definitions/nyaml/NXfiber.yaml | 160 -- .../nyaml/NXgraph_edge_set.yaml | 69 - .../nyaml/NXgraph_node_set.yaml | 48 - .../nyaml/NXgraph_root.yaml | 9 - .../nyaml/NXibeam_column.yaml | 93 - .../nyaml/NXimage_set.yaml | 60 - .../nyaml/NXimage_set_em_adf.yaml | 89 - .../nyaml/NXimage_set_em_kikuchi.yaml | 139 - .../nyaml/NXinteraction_vol_em.yaml | 75 - contributed_definitions/nyaml/NXion.yaml | 116 - .../nyaml/NXisocontour.yaml | 30 - contributed_definitions/nyaml/NXiv_temp.yaml | 40 - ..._electro_chemo_mechanical_preparation.yaml | 113 - .../nyaml/NXlab_sample_mounting.yaml | 51 - contributed_definitions/nyaml/NXlens_em.yaml | 50 - contributed_definitions/nyaml/NXlens_opt.yaml | 140 - .../nyaml/NXmagnetic_kicker.yaml | 102 - .../nyaml/NXmanipulator.yaml | 41 - .../nyaml/NXmatch_filter.yaml | 26 - contributed_definitions/nyaml/NXmpes.yaml | 234 -- contributed_definitions/nyaml/NXms.yaml | 450 --- .../nyaml/NXms_feature_set.yaml | 233 -- .../nyaml/NXms_score_config.yaml | 318 --- .../nyaml/NXms_score_results.yaml | 598 ---- .../nyaml/NXms_snapshot.yaml | 20 - .../nyaml/NXms_snapshot_set.yaml | 28 - contributed_definitions/nyaml/NXopt.yaml | 703 ----- .../nyaml/NXoptical_system_em.yaml | 50 - .../nyaml/NXorientation_set.yaml | 84 - contributed_definitions/nyaml/NXpeak.yaml | 43 - contributed_definitions/nyaml/NXpid.yaml | 46 - .../nyaml/NXpolarizer_opt.yaml | 201 -- contributed_definitions/nyaml/NXprogram.yaml | 20 - .../nyaml/NXpulser_apm.yaml | 103 - contributed_definitions/nyaml/NXpump.yaml | 11 - contributed_definitions/nyaml/NXquadric.yaml | 117 - .../nyaml/NXquadrupole_magnet.yaml | 84 - .../nyaml/NXreflectron.yaml | 25 - contributed_definitions/nyaml/NXregion.yaml | 340 --- .../nyaml/NXregistration.yaml | 15 - .../nyaml/NXscanbox_em.yaml | 29 - .../nyaml/NXsensor_scan.yaml | 131 - .../nyaml/NXseparator.yaml | 108 - .../nyaml/NXsimilarity_grouping.yaml | 100 - .../nyaml/NXslip_system_set.yaml | 38 - contributed_definitions/nyaml/NXsnsevent.yaml | 640 ----- contributed_definitions/nyaml/NXsnshisto.yaml | 670 ----- .../nyaml/NXsolenoid_magnet.yaml | 84 - .../nyaml/NXsolid_geometry.yaml | 76 - .../nyaml/NXspatial_filter.yaml | 39 - .../nyaml/NXspectrum_set.yaml | 91 - .../nyaml/NXspectrum_set_em_eels.yaml | 105 - .../nyaml/NXspectrum_set_em_xray.yaml | 196 -- .../nyaml/NXspin_rotator.yaml | 108 - .../nyaml/NXspindispersion.yaml | 38 - .../nyaml/NXstage_lab.yaml | 131 - .../nyaml/NXsubsampling_filter.yaml | 19 - .../nyaml/NXtransmission.yaml | 211 -- .../nyaml/NXwaveplate.yaml | 132 - contributed_definitions/nyaml/NXxpcs.yaml | 1085 ------- 246 files changed, 57275 deletions(-) delete mode 100644 applications/nyaml/NXarchive.yaml delete mode 100644 applications/nyaml/NXarpes.yaml delete mode 100644 applications/nyaml/NXcanSAS.yaml delete mode 100644 applications/nyaml/NXdirecttof.yaml delete mode 100644 applications/nyaml/NXfluo.yaml delete mode 100644 applications/nyaml/NXindirecttof.yaml delete mode 100644 applications/nyaml/NXiqproc.yaml delete mode 100644 applications/nyaml/NXlauetof.yaml delete mode 100644 applications/nyaml/NXmonopd.yaml delete mode 100644 applications/nyaml/NXmx.yaml delete mode 100644 applications/nyaml/NXrefscan.yaml delete mode 100644 applications/nyaml/NXreftof.yaml delete mode 100644 applications/nyaml/NXsas.yaml delete mode 100644 applications/nyaml/NXsastof.yaml delete mode 100644 applications/nyaml/NXscan.yaml delete mode 100644 applications/nyaml/NXspe.yaml delete mode 100644 applications/nyaml/NXsqom.yaml delete mode 100644 applications/nyaml/NXstxm.yaml delete mode 100644 applications/nyaml/NXtas.yaml delete mode 100644 applications/nyaml/NXtofnpd.yaml delete mode 100644 applications/nyaml/NXtofraw.yaml delete mode 100644 applications/nyaml/NXtofsingle.yaml delete mode 100644 applications/nyaml/NXtomo.yaml delete mode 100644 applications/nyaml/NXtomophase.yaml delete mode 100644 applications/nyaml/NXtomoproc.yaml delete mode 100644 applications/nyaml/NXxas.yaml delete mode 100644 applications/nyaml/NXxasproc.yaml delete mode 100644 applications/nyaml/NXxbase.yaml delete mode 100644 applications/nyaml/NXxeuler.yaml delete mode 100644 applications/nyaml/NXxkappa.yaml delete mode 100644 applications/nyaml/NXxlaue.yaml delete mode 100644 applications/nyaml/NXxlaueplate.yaml delete mode 100644 applications/nyaml/NXxnb.yaml delete mode 100644 applications/nyaml/NXxrot.yaml delete mode 100644 base_classes/nyaml/NXaperture.yaml delete mode 100644 base_classes/nyaml/NXattenuator.yaml delete mode 100644 base_classes/nyaml/NXbeam.yaml delete mode 100644 base_classes/nyaml/NXbeam_stop.yaml delete mode 100644 base_classes/nyaml/NXbending_magnet.yaml delete mode 100644 base_classes/nyaml/NXcapillary.yaml delete mode 100644 base_classes/nyaml/NXcite.yaml delete mode 100644 base_classes/nyaml/NXcollection.yaml delete mode 100644 base_classes/nyaml/NXcollimator.yaml delete mode 100644 base_classes/nyaml/NXcrystal.yaml delete mode 100644 base_classes/nyaml/NXcylindrical_geometry.yaml delete mode 100644 base_classes/nyaml/NXdata.yaml delete mode 100644 base_classes/nyaml/NXdetector.yaml delete mode 100644 base_classes/nyaml/NXdetector_group.yaml delete mode 100644 base_classes/nyaml/NXdetector_module.yaml delete mode 100644 base_classes/nyaml/NXdisk_chopper.yaml delete mode 100644 base_classes/nyaml/NXentry.yaml delete mode 100644 base_classes/nyaml/NXenvironment.yaml delete mode 100644 base_classes/nyaml/NXevent_data.yaml delete mode 100644 base_classes/nyaml/NXfermi_chopper.yaml delete mode 100644 base_classes/nyaml/NXfilter.yaml delete mode 100644 base_classes/nyaml/NXflipper.yaml delete mode 100644 base_classes/nyaml/NXfresnel_zone_plate.yaml delete mode 100644 base_classes/nyaml/NXgeometry.yaml delete mode 100644 base_classes/nyaml/NXgrating.yaml delete mode 100644 base_classes/nyaml/NXguide.yaml delete mode 100644 base_classes/nyaml/NXinsertion_device.yaml delete mode 100644 base_classes/nyaml/NXinstrument.yaml delete mode 100644 base_classes/nyaml/NXlog.yaml delete mode 100644 base_classes/nyaml/NXmirror.yaml delete mode 100644 base_classes/nyaml/NXmoderator.yaml delete mode 100644 base_classes/nyaml/NXmonitor.yaml delete mode 100644 base_classes/nyaml/NXmonochromator.yaml delete mode 100644 base_classes/nyaml/NXnote.yaml delete mode 100644 base_classes/nyaml/NXobject.yaml delete mode 100644 base_classes/nyaml/NXoff_geometry.yaml delete mode 100644 base_classes/nyaml/NXorientation.yaml delete mode 100644 base_classes/nyaml/NXparameters.yaml delete mode 100644 base_classes/nyaml/NXpdb.yaml delete mode 100644 base_classes/nyaml/NXpinhole.yaml delete mode 100644 base_classes/nyaml/NXpolarizer.yaml delete mode 100644 base_classes/nyaml/NXpositioner.yaml delete mode 100644 base_classes/nyaml/NXprocess.yaml delete mode 100644 base_classes/nyaml/NXreflections.yaml delete mode 100644 base_classes/nyaml/NXroot.yaml delete mode 100644 base_classes/nyaml/NXsample.yaml delete mode 100644 base_classes/nyaml/NXsample_component.yaml delete mode 100644 base_classes/nyaml/NXsensor.yaml delete mode 100644 base_classes/nyaml/NXshape.yaml delete mode 100644 base_classes/nyaml/NXslit.yaml delete mode 100644 base_classes/nyaml/NXsource.yaml delete mode 100644 base_classes/nyaml/NXsubentry.yaml delete mode 100644 base_classes/nyaml/NXtransformations.yaml delete mode 100644 base_classes/nyaml/NXtranslation.yaml delete mode 100644 base_classes/nyaml/NXuser.yaml delete mode 100644 base_classes/nyaml/NXvelocity_selector.yaml delete mode 100644 base_classes/nyaml/NXxraylens.yaml delete mode 100644 contributed_definitions/nyaml/NXaberration.yaml delete mode 100644 contributed_definitions/nyaml/NXaberration_model.yaml delete mode 100644 contributed_definitions/nyaml/NXaberration_model_ceos.yaml delete mode 100644 contributed_definitions/nyaml/NXaberration_model_nion.yaml delete mode 100644 contributed_definitions/nyaml/NXadc.yaml delete mode 100644 contributed_definitions/nyaml/NXaperture_em.yaml delete mode 100644 contributed_definitions/nyaml/NXapm.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_composition_space_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_input_ranging.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_input_reconstruction.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml delete mode 100644 contributed_definitions/nyaml/NXbeam_path.yaml delete mode 100644 contributed_definitions/nyaml/NXbeam_splitter.yaml delete mode 100644 contributed_definitions/nyaml/NXcalibration.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_alpha_complex.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_cylinder_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_grid.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_hexahedron_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_marching_cubes.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_parallelogram_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_point_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_polygon_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_polyhedron_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_polyline_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_roi_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_sphere_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_triangle_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_unit_normal_set.yaml delete mode 100644 contributed_definitions/nyaml/NXchamber.yaml delete mode 100644 contributed_definitions/nyaml/NXchemical_composition.yaml delete mode 100644 contributed_definitions/nyaml/NXcircuit_board.yaml delete mode 100644 contributed_definitions/nyaml/NXclustering.yaml delete mode 100644 contributed_definitions/nyaml/NXcollectioncolumn.yaml delete mode 100644 contributed_definitions/nyaml/NXcontainer.yaml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcorrector_cs.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_computer.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_cpu.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_gpu.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_io_obj.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_io_sys.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_mm_sys.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_prng.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_profiling.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_profiling_event.yaml delete mode 100644 contributed_definitions/nyaml/NXcsg.yaml delete mode 100644 contributed_definitions/nyaml/NXcxi_ptycho.yaml delete mode 100644 contributed_definitions/nyaml/NXdac.yaml delete mode 100644 contributed_definitions/nyaml/NXdeflector.yaml delete mode 100644 contributed_definitions/nyaml/NXdelocalization.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion_function.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion_single_parameter.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion_table.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersive_material.yaml delete mode 100644 contributed_definitions/nyaml/NXdistortion.yaml delete mode 100644 contributed_definitions/nyaml/NXebeam_column.yaml delete mode 100644 contributed_definitions/nyaml/NXelectronanalyser.yaml delete mode 100644 contributed_definitions/nyaml/NXelectrostatic_kicker.yaml delete mode 100644 contributed_definitions/nyaml/NXellipsometry.yaml delete mode 100644 contributed_definitions/nyaml/NXem.yaml delete mode 100644 contributed_definitions/nyaml/NXem_ebsd.yaml delete mode 100644 contributed_definitions/nyaml/NXem_ebsd_conventions.yaml delete mode 100644 contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml delete mode 100644 contributed_definitions/nyaml/NXenergydispersion.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_data_em.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_data_em_set.yaml delete mode 100644 contributed_definitions/nyaml/NXfabrication.yaml delete mode 100644 contributed_definitions/nyaml/NXfiber.yaml delete mode 100644 contributed_definitions/nyaml/NXgraph_edge_set.yaml delete mode 100644 contributed_definitions/nyaml/NXgraph_node_set.yaml delete mode 100644 contributed_definitions/nyaml/NXgraph_root.yaml delete mode 100644 contributed_definitions/nyaml/NXibeam_column.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_adf.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml delete mode 100644 contributed_definitions/nyaml/NXinteraction_vol_em.yaml delete mode 100644 contributed_definitions/nyaml/NXion.yaml delete mode 100644 contributed_definitions/nyaml/NXisocontour.yaml delete mode 100644 contributed_definitions/nyaml/NXiv_temp.yaml delete mode 100644 contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml delete mode 100644 contributed_definitions/nyaml/NXlab_sample_mounting.yaml delete mode 100644 contributed_definitions/nyaml/NXlens_em.yaml delete mode 100644 contributed_definitions/nyaml/NXlens_opt.yaml delete mode 100644 contributed_definitions/nyaml/NXmagnetic_kicker.yaml delete mode 100644 contributed_definitions/nyaml/NXmanipulator.yaml delete mode 100644 contributed_definitions/nyaml/NXmatch_filter.yaml delete mode 100644 contributed_definitions/nyaml/NXmpes.yaml delete mode 100644 contributed_definitions/nyaml/NXms.yaml delete mode 100644 contributed_definitions/nyaml/NXms_feature_set.yaml delete mode 100644 contributed_definitions/nyaml/NXms_score_config.yaml delete mode 100644 contributed_definitions/nyaml/NXms_score_results.yaml delete mode 100644 contributed_definitions/nyaml/NXms_snapshot.yaml delete mode 100644 contributed_definitions/nyaml/NXms_snapshot_set.yaml delete mode 100644 contributed_definitions/nyaml/NXopt.yaml delete mode 100644 contributed_definitions/nyaml/NXoptical_system_em.yaml delete mode 100644 contributed_definitions/nyaml/NXorientation_set.yaml delete mode 100644 contributed_definitions/nyaml/NXpeak.yaml delete mode 100644 contributed_definitions/nyaml/NXpid.yaml delete mode 100644 contributed_definitions/nyaml/NXpolarizer_opt.yaml delete mode 100644 contributed_definitions/nyaml/NXprogram.yaml delete mode 100644 contributed_definitions/nyaml/NXpulser_apm.yaml delete mode 100644 contributed_definitions/nyaml/NXpump.yaml delete mode 100644 contributed_definitions/nyaml/NXquadric.yaml delete mode 100644 contributed_definitions/nyaml/NXquadrupole_magnet.yaml delete mode 100644 contributed_definitions/nyaml/NXreflectron.yaml delete mode 100644 contributed_definitions/nyaml/NXregion.yaml delete mode 100644 contributed_definitions/nyaml/NXregistration.yaml delete mode 100644 contributed_definitions/nyaml/NXscanbox_em.yaml delete mode 100644 contributed_definitions/nyaml/NXsensor_scan.yaml delete mode 100644 contributed_definitions/nyaml/NXseparator.yaml delete mode 100644 contributed_definitions/nyaml/NXsimilarity_grouping.yaml delete mode 100644 contributed_definitions/nyaml/NXslip_system_set.yaml delete mode 100644 contributed_definitions/nyaml/NXsnsevent.yaml delete mode 100644 contributed_definitions/nyaml/NXsnshisto.yaml delete mode 100644 contributed_definitions/nyaml/NXsolenoid_magnet.yaml delete mode 100644 contributed_definitions/nyaml/NXsolid_geometry.yaml delete mode 100644 contributed_definitions/nyaml/NXspatial_filter.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml delete mode 100644 contributed_definitions/nyaml/NXspin_rotator.yaml delete mode 100644 contributed_definitions/nyaml/NXspindispersion.yaml delete mode 100644 contributed_definitions/nyaml/NXstage_lab.yaml delete mode 100644 contributed_definitions/nyaml/NXsubsampling_filter.yaml delete mode 100644 contributed_definitions/nyaml/NXtransmission.yaml delete mode 100644 contributed_definitions/nyaml/NXwaveplate.yaml delete mode 100644 contributed_definitions/nyaml/NXxpcs.yaml diff --git a/applications/nyaml/NXarchive.yaml b/applications/nyaml/NXarchive.yaml deleted file mode 100644 index 44246f4a25..0000000000 --- a/applications/nyaml/NXarchive.yaml +++ /dev/null @@ -1,281 +0,0 @@ -category: application -doc: | - This is a definition for data to be archived by ICAT (http://www.icatproject.org/). - - .. text from the icatproject.org site - - the database (with supporting software) that provides an - interface to all ISIS experimental data and will provide - a mechanism to link all aspects of ISIS research from - proposal through to publication. -type: group -NXarchive(NXobject): - (NXentry)entry: - \@index: - title: - experiment_identifier(NX_CHAR): - doc: | - unique identifier for the experiment - experiment_description(NX_CHAR): - doc: | - Brief description of the experiment and its objectives - collection_identifier(NX_CHAR): - doc: | - ID of user or DAQ define group of data files - collection_description(NX_CHAR): - doc: | - Brief summary of the collection, including grouping criteria - entry_identifier(NX_CHAR): - doc: | - unique identifier for this measurement as provided by the facility - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - duration(NX_FLOAT): - unit: NX_TIME - doc: | - TODO: needs documentation - collection_time(NX_FLOAT): - unit: NX_TIME - doc: | - TODO: needs documentation - run_cycle(NX_CHAR): - doc: | - TODO: needs documentation - revision(NX_CHAR): - doc: | - revision ID of this file, may be after recalibration, reprocessing etc. - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXarchive] - program(NX_CHAR): - doc: | - The program and version used for generating this file - \@version: - release_date(NX_CHAR): - unit: NX_TIME - doc: | - when this file is to be released into PD - (NXuser)user: - name(NX_CHAR): - role(NX_CHAR): - doc: | - role of the user - facility_user_id(NX_CHAR): - doc: | - ID of the user in the facility burocracy database - (NXinstrument)instrument: - (NXsource): - type(NX_CHAR): - - # TODO: suggest changing from enumeration to suggested list - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-Ray Source, Pulsed Muon Source, Rotating Anode X-Ray, Fixed Tube X-Ray] - name: - probe: - enumeration: [neutron, x-ray, electron] - name(NX_CHAR): - description(NX_CHAR): - doc: | - Brief description of the instrument - (NXsample)sample: - name: - doc: | - Descriptive name of sample - sample_id(NX_CHAR): - doc: | - Unique database id of the sample - description(NX_CHAR): - type(NX_CHAR): - enumeration: [sample, sample+can, calibration sample, normalisation sample, simulated data, none, sample_environment] - chemical_formula(NX_CHAR): - doc: | - Chemical formula formatted according to CIF conventions - preparation_date(NX_CHAR): - unit: NX_TIME - situation(NX_CHAR): - doc: | - Description of the environment the sample is in: - air, vacuum, oxidizing atmosphere, dehydrated, etc. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - magnetic_field(NX_FLOAT): - unit: NX_CURRENT - electric_field(NX_FLOAT): - unit: NX_VOLTAGE - stress_field(NX_FLOAT): - unit: NX_UNITLESS - pressure(NX_FLOAT): - unit: NX_PRESSURE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e5a85aff26bd71392bbe9cc8482e9067d971b4f1af39884f60db7dc0adfe811c -# -# -# -# -# -# This is a definition for data to be archived by ICAT (http://www.icatproject.org/). -# -# .. text from the icatproject.org site -# -# the database (with supporting software) that provides an -# interface to all ISIS experimental data and will provide -# a mechanism to link all aspects of ISIS research from -# proposal through to publication. -# -# -# -# -# -# unique identifier for the experiment -# -# -# Brief description of the experiment and its objectives -# -# -# ID of user or DAQ define group of data files -# -# -# Brief summary of the collection, including grouping criteria -# -# -# unique identifier for this measurement as provided by the facility -# -# -# -# -# TODO: needs documentation -# -# -# TODO: needs documentation -# -# -# TODO: needs documentation -# -# -# revision ID of this file, may be after recalibration, reprocessing etc. -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# The program and version used for generating this file -# -# -# when this file is to be released into PD -# -# -# -# role of the user -# -# ID of the user in the facility burocracy database -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Brief description of the instrument -# -# -# -# -# Descriptive name of sample -# -# -# Unique database id of the sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Chemical formula formatted according to CIF conventions -# -# -# -# -# Description of the environment the sample is in: -# air, vacuum, oxidizing atmosphere, dehydrated, etc. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXarpes.yaml b/applications/nyaml/NXarpes.yaml deleted file mode 100644 index 746d91696f..0000000000 --- a/applications/nyaml/NXarpes.yaml +++ /dev/null @@ -1,226 +0,0 @@ -category: application -doc: | - This is an application definition for angular resolved photo electron spectroscopy. - - It has been drawn up with hemispherical electron analysers in mind. -type: group -NXarpes(NXobject): - (NXentry): - \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... - for analysis software to locate each entry. - title(NX_CHAR): - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - enumeration: [NXarpes] - (NXinstrument): - (NXsource): - type(NX_CHAR): - name(NX_CHAR): - probe: - enumeration: [x-ray] - (NXmonochromator)monochromator: - energy(NX_NUMBER): - unit: NX_ENERGY - (NXdetector)analyser: - data(NX_NUMBER): - lens_mode(NX_CHAR): - doc: | - setting for the electron analyser lens - acquisition_mode: - enumeration: [swept, fixed] - entrance_slit_shape: - enumeration: [curved, straight] - entrance_slit_setting(NX_NUMBER): - unit: NX_ANY - doc: | - dial setting of the entrance slit - entrance_slit_size(NX_NUMBER): - unit: NX_LENGTH - doc: | - size of the entrance slit - pass_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - energy of the electrons on the mean path of the analyser - time_per_channel(NX_NUMBER): - unit: NX_TIME - doc: | - todo: define more clearly - angles(NX_NUMBER): - unit: NX_ANGLE - doc: | - Angular axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - energies(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - sensor_size(NX_INT): - doc: | - number of raw active elements in each dimension - dimensions: - rank: 1 - dim: [[1, 2]] - region_origin(NX_INT): - doc: | - origin of rectangular region selected for readout - dimensions: - rank: 1 - dim: [[1, 2]] - region_size(NX_INT): - doc: | - size of rectangular region selected for readout - dimensions: - rank: 1 - dim: [[1, 2]] - (NXsample): - name(NX_CHAR): - doc: | - Descriptive name of sample - temperature(NX_NUMBER): - unit: NX_TEMPERATURE - (NXdata): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 31232b8eac61f1e491926e74795efc8930591197ca40ea19d78788a866e7c6bf -# -# -# -# -# -# This is an application definition for angular resolved photo electron spectroscopy. -# -# It has been drawn up with hemispherical electron analysers in mind. -# -# -# -# -# NeXus convention is to use "entry1", "entry2", ... -# for analysis software to locate each entry. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# setting for the electron analyser lens -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# dial setting of the entrance slit -# -# -# size of the entrance slit -# -# -# energy of the electrons on the mean path of the analyser -# -# -# todo: define more clearly -# -# -# -# Angular axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# -# Energy axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# number of raw active elements in each dimension -# -# -# -# -# -# origin of rectangular region selected for readout -# -# -# -# -# -# size of rectangular region selected for readout -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# diff --git a/applications/nyaml/NXcanSAS.yaml b/applications/nyaml/NXcanSAS.yaml deleted file mode 100644 index 27192a0ea4..0000000000 --- a/applications/nyaml/NXcanSAS.yaml +++ /dev/null @@ -1,2422 +0,0 @@ -category: application -doc: | - Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. - - .. index:: canSAS - - For more details, see: - - * http://www.cansas.org/ - * http://www.cansas.org/formats/canSAS1d/1.1/doc/ - * http://cansas-org.github.io/canSAS2012/ - * https://github.com/canSAS-org/NXcanSAS_examples - - The minimum requirements for *reduced* small-angle scattering data - as described by canSAS are summarized in the following figure: - - .. _canSAS_2012_minimum: - - .. figure:: canSAS/2012-minimum.png - :width: 60% - - The minimum requirements for *reduced* small-angle scattering data. - (:download:`full image `) - See :ref:`below ` for the minimum required - information for a NeXus data file - written to the NXcanSAS specification. - - .. rubric:: Implementation of canSAS standard in NeXus - - This application definition is an implementation of the canSAS - standard for storing both one-dimensional and multi-dimensional - *reduced* small-angle scattering data. - - * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. - * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` - * External file links are not to be used for the reduced data. - * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. - * There is no need for NXcanSAS to refer to any raw data. - - The canSAS data format has a structure similar to NeXus, not identical. - To allow canSAS data to be expressed in NeXus, yet identifiable - by the canSAS standard, an additional group attribute ``canSAS_class`` - was introduced. Here is the mapping of some common groups. - - =============== ============ ========================== - group (*) NX_class canSAS_class - =============== ============ ========================== - sasentry NXentry SASentry - sasdata NXdata SASdata - sasdetector NXdetector SASdetector - sasinstrument NXinstrument SASinstrument - sasnote NXnote SASnote - sasprocess NXprocess SASprocess - sasprocessnote NXcollection SASprocessnote - sastransmission NXdata SAStransmission_spectrum - sassample NXsample SASsample - sassource NXsource SASsource - =============== ============ ========================== - - (*) The name of each group is a suggestion, - not a fixed requirement and is chosen as fits each data file. - See the section on defining - :ref:`NXDL group and field names `. - - Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) - for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. - - .. _NXcanSAS_minimum: - - .. rubric:: The minimum required information for a NeXus data file - written to the NXcanSAS specification. - - .. literalinclude:: canSAS/minimum-required.txt - :tab-width: 4 - :linenos: - :language: text - -# NOTE: -# This NXDL refers to several image files (.jpg, .png) in its documentation. -# All such related resources are stored in the related subdirectory: ./canSAS/ -# In general, for an NXDL file: NXsomenxdl.nxdl.xml -# all related resources should be stored in subdirectory: ./somenxdl/ -type: group -NXcanSAS(NXobject): - (NXentry): - \@default: - exists: optional - doc: | - .. index:: plotting - - Declares which :ref:`NXdata` group - contains the data to be shown by default. - It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. - The value is the name of the default :ref:`NXdata` group. - Usually, this will be the name of the first *SASdata* group. - doc: | - .. index:: NXcanSAS (applications); SASentry - - Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group - (when data from multiple techniques are being stored) - or as a replacement for the ``NXentry`` group. - - Note: It is required for all numerical objects to provide - a *units* attribute that describes the engineering units. - Use the Unidata UDunits [#]_ specification - as this is compatible with various community standards. - - .. [#] The UDunits specification also includes instructions for derived units. - \@canSAS_class: - doc: | - Official canSAS group: **SASentry** - enumeration: [SASentry] - \@version: - doc: | - Describes the version of the canSAS standard used to write this data. - This must be a text (not numerical) representation. Such as:: - - @version="1.1" - enumeration: [1.1] - definition: - doc: | - Official NeXus NXDL schema to which this subentry conforms. - enumeration: [NXcanSAS] - - # ============================ - # SASdata - # ============================ - (NXdata): - doc: | - A *SASData* group contains a single reduced small-angle scattering data set - that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. - - *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) - - The name of each *SASdata* group must be unique within a SASentry group. - Suggest using names such as ``sasdata01``. - - NOTE: For the first *SASdata* group, be sure to write the chosen name - into the `SASentry/@default` attribute, as in:: - - SASentry/@default="sasdata01" - - A *SASdata* group has several attributes: - - * I_axes - * Q_indices - * Mask_indices - - To indicate the dependency relationships of other varied parameters, - use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` - or ``@Pressure_indices``). - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASdata` - enumeration: [SASdata] - - # attributes, see: http://www.cansas.org/formats/canSAS2012/1.0/doc/framework.html#terms - \@signal: - type: NX_CHAR - doc: | - Name of the default data field. - enumeration: - I: - doc: | - For canSAS **SASdata**, this is always "I". - \@I_axes: - doc: | - String array that defines the independent data fields used in - the default plot for all of the dimensions of the *signal* field - (the *signal* field is the field in this group that is named by - the ``signal`` attribute of this group). - One entry is provided for every dimension of the ``I`` data object. - Such as:: - - @I_axes="Temperature", "Time", "Pressure", "Q", "Q" - - Since there are five items in the list, the intensity field of this example - ``I`` must be a five-dimensional array (rank=5). - \@Q_indices: - type: NX_INT - doc: | - Integer or integer array that describes which indices - (of the :math:`I` data object) are used to - reference the ``Q`` data object. The items in this array - use zero-based indexing. Such as:: - - @Q_indices=1,3,4 - - which indicates that ``Q`` requires three indices - from the :math:`I` data object: one for time and - two for Q position. Thus, in this example, the - ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. - \@mask: - type: NX_CHAR - doc: | - Name of the data mask field. - - .. see: https://github.com/nexusformat/definitions/issues/533 - - The data *mask* must have the same shape as the *data* field. - Positions in the mask correspond to positions in the *data* field. - The value of the mask field may be either a boolean array - where ``false`` means *no mask* and ``true`` means *mask* - or a more descriptive array as as defined in :ref:`NXdetector`. - \@Mask_indices: - exists: optional - doc: | - Integer or integer array that describes which indices - (of the :math:`I` data object) are used to - reference the ``Mask`` data object. The items in this - array use zero-based indexing. Such as:: - - @Mask_indices=3,4 - - which indicates that Q requires two indices - from the :math:`I` data object for Q position. - \@timestamp: - type: NX_DATE_TIME - exists: optional - doc: | - ISO-8601 time [#iso8601]_ - Q(NX_NUMBER): - unit: NX_PER_LENGTH - - # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of - doc: | - .. index:: NXcanSAS (applications); Q - - Array of :math:`Q` data to accompany :math:`I`. - - .. figure:: canSAS/Q-geometry.jpg - :width: 60% - - The :math:`\vec{Q}` geometry. - (:download:`full image `) - - :math:`Q` may be represented as either - the three-dimensional scattering vector :math:`\vec{Q}` - or the magnitude of the scattering vector, :math:`|\vec{Q}|`. - - .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) - - When we write :math:`Q`, we may refer to either or both of - :math:`|\vec{Q}|` - or :math:`\vec{Q}`, depending on the context. - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units will generate - a warning from validation software and may not - be processed by some analysis software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - \@uncertainties: - exists: optional - doc: | - (optional: for numerical arrays) - - Names the dataset (in this SASdata group) that provides the - uncertainty to be used for data analysis. - The name of the dataset containing the :math:`Q` uncertainty - is flexible. The name must be unique in the *SASdata* group. - - .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 - - Such as:: - - @uncertainties="Q_uncertainties" - - The *uncertainties* field will have the same *shape* (dimensions) - as the Q field. - - These values are the estimates of uncertainty of each Q. By default, - this will be interpreted to be the estimated standard deviation. - In special cases, when a standard deviation cannot possibly be used, - its value can specify another measure of distribution width. - - There may also be a subdirectory (optional) with constituent - components. - - .. note:: To report distribution in reported :math:`Q` values, - use the ``@resolutions`` attribute. It is possible for both - ``@resolutions`` and ``uncertainties`` to be reported. - \@resolutions: - type: NX_CHAR - exists: optional - doc: | - .. index:: NXcanSAS (applications); resolutions - - (optional: for numerical arrays) - - Names the dataset (in this SASdata group) containing the :math:`Q` resolution. - The name of the dataset containing the :math:`Q` resolution - is flexible. The name must be unique in the *SASdata* group. - - .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 - - The *resolutions* field will have the same *shape* (dimensions) - as the Q field. - - Generally, this is the principal resolution of each :math:`Q`. - Names the data object (in this SASdata group) that provides the - :math:`Q` resolution to be used for data analysis. Such as:: - - @resolutions="Qdev" - - To specify two-dimensional resolution for slit-smearing geometry, - such as (*dQw*, *dQl*), use a string array, such as:: - - @resolutions="dQw", "dQl" - - There may also be a subdirectory (optional) with constituent - components. - - This pattern will demonstrate how to introduce further as-yet - unanticipated terms related to the data. - - .. comment - see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 - - By default, the values of the resolutions data object are assumed to be - one standard deviation of any function used to approximate the - resolution function. This equates to the width of the gaussian - distribution if a Gaussian is chosen. See the ``@resolutions_description`` - attribute. - - .. note:: To report uncertainty in reported :math:`Q` values, - use the ``@uncertainties`` attribute. It is possible for both - ``@resolutions`` and ``uncertainties`` to be reported. - \@resolutions_description: - type: NX_CHAR - exists: optional - doc: | - (optional) - Generally, this describes the :math:`Q` ``@resolutions`` data object. - By default, the value is assumed to be "Gaussian". These are - suggestions: - - * Gaussian - * Lorentzian - * Square : - note that the full width of the square would be ~2.9 times - the standard deviation specified in the vector - * Triangular - * Sawtooth-outward : vertical edge pointing to larger Q - * Sawtooth-inward vertical edge pointing to smaller Q - * Bin : range of values contributing - (for example, when 2-D detector data have been reduced - to a 1-D :math:`I(|Q|)` dataset) - - For other meanings, it may be necessary to provide further details - such as the function used to assess the resolution. - In such cases, use additional datasets or a :ref:`NXnote` subgroup - to include that detail. - I(NX_NUMBER): - - # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of-intensity - doc: | - .. index:: NXcanSAS (applications); I - - Array of intensity (:math:`I`) data. - - The intensity may be represented in one of these forms: - - **absolute units**: :math:`d\Sigma/d\Omega(Q)` - differential cross-section - per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) - - **absolute units**: :math:`d\sigma/d\Omega(Q)` - differential cross-section - per unit atom per unit solid angle (such as: cm^2 or m^2) - - **arbitrary units**: :math:`I(Q)` - usually a ratio of two detectors - but units are meaningless (such as: a.u. or counts) - - This presents a few problems - for analysis software to sort out when reading the data. - Fortunately, it is possible to analyze the *units* to determine which type of - intensity is being reported and make choices at the time the file is read. But this is - an area for consideration and possible improvement. - - One problem arises with software that automatically converts data into some canonical - units used by that software. The software should not convert units between these different - types of intensity indiscriminately. - - A second problem is that when arbitrary units are used, then the set of possible - analytical results is restricted. With such units, no meaningful volume fraction - or number density can be determined directly from :math:`I(Q)`. - - In some cases, it is possible to apply a factor to convert the arbitrary - units to an absolute scale. This should be considered as a possibility - of the analysis process. - - Where this documentation says *typical units*, it is possible that small-angle - data may be presented in other units and still be consistent with NeXus. - See the :ref:`design-units` section. - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`I` and intensity-related terms. - - Data expressed in other units (or missing a ``@units`` attribute) - will be treated as ``arbitrary`` by some software packages. - - For software using the UDUNITS-2 library, ``arbitrary`` will be - changed to ``unknown`` for handling with that library. - enumeration: - 1/m: - doc: | - includes m2/m3 and 1/m/sr - 1/cm: - doc: | - includes cm2/cm3 and 1/cm/sr - m2/g: - cm2/g: - arbitrary: - \@uncertainties: - exists: optional - doc: | - (optional: for numerical arrays) - - Names the dataset (in this SASdata group) that provides the - uncertainty of :math:`I` to be used for data analysis. - The name of the dataset containing the :math:`I` uncertainty - is flexible. The name must be unique in the *SASdata* group. - - .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 - - Generally, this is the estimate of the uncertainty of each :math:`I`. - Typically the estimated standard deviation. - - *Idev* is the canonical name from the 1D standard. - The NXcanSAS standard allows for the name to be described using this attribute. - Such as:: - - @uncertainties="Idev" - \@scaling_factor: - exists: optional - doc: | - (optional) - Names the field (a.k.a. dataset) that contains a factor - to multiply ``I``. By default, this value is unity. - Should an uncertainty be associated with the scaling factor - field, the field containing that uncertainty would be - designated via the ``uncertainties`` attribute. - Such as:: - - I : NX_NUMBER - @uncertainties="Idev" : NX_CHAR - @scaling_factor="I_scaling" : NX_CHAR - Idev : NX_NUMBER - I_scaling : NX_NUMBER - @uncertainties="I_scaling_dev" : NX_CHAR - I_scaling_dev : NX_NUMBER - - The exact names for ``I_scaling`` and ``I_scaling_dev`` are not - defined by NXcanSAS. The user has the flexibility to use names - different than those shown in this example. - Idev(NX_NUMBER): - exists: ['min', '0'] - doc: | - .. index:: NXcanSAS (applications); Idev - - Estimated **uncertainty** (usually standard deviation) - in :math:`I`. Must have the same units as :math:`I`. - - When present, the name of this field is also - recorded in the *uncertainties* attribute of *I*, as in:: - - I/@uncertainties="Idev" - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`I` and intensity-related terms. - - Data expressed in other units (or missing a ``@units`` attribute) - will generate a warning from any validation process - and will be treated as ``arbitrary`` by some analysis software packages. - - For software using the UDUNITS-2 library, ``arbitrary`` will be - changed to ``unknown`` for handling with that library. - enumeration: - 1/m: - doc: | - includes m2/m3 and 1/m/sr - 1/cm: - doc: | - includes cm2/cm3 and 1/cm/sr - m2/g: - cm2/g: - arbitrary: - Qdev(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - .. index:: NXcanSAS (applications); Qdev - - Estimated :math:`Q` **resolution** (usually standard deviation). - Must have the same units as :math:`Q`. - - When present, the name of this field is also - recorded in the *resolutions* attribute of *Q*, - as in:: - - Q/@resolutions="Qdev" - - or:: - - Q/@resolutions="dQw", "dQl" - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units may not be processed by some - software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - dQw(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - .. index:: NXcanSAS (applications); dQw - - :math:`Q` **resolution** along the axis of scanning - (the high-resolution *slit width* direction). - Useful for defining resolution data from - slit-smearing instruments such as Bonse-Hart geometry. - Must have the same units as :math:`Q`. - - When present, the name of this field is also - recorded in the *resolutions* attribute of *Q*, - as in:: - - Q/@resolutions="dQw", "dQl" - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units may not be processed by some - software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - dQl(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - .. index:: NXcanSAS (applications); dQl - - :math:`Q` **resolution** perpendicular to the axis of scanning - (the low-resolution *slit length* direction). - Useful for defining resolution data from - slit-smearing instruments such as Bonse-Hart geometry. - Must have the same units as :math:`Q`. - - When present, the name of this field is also - recorded in the *resolutions* attribute of *Q*, - as in:: - - Q/@resolutions="dQw", "dQl" - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units may not be processed by some - software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - Qmean(NX_NUMBER): - exists: ['min', '0'] - unit: NX_PER_LENGTH - doc: | - Mean value of :math:`Q` for this data point. - Useful when describing data that has been - binned from higher-resolution data. - - It is expected that ``Q`` is provided - and that both ``Q`` and ``Qmean`` will have the same units. - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units may not be processed by some - software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - ShadowFactor: - exists: ['min', '0'] - unit: NX_DIMENSIONLESS - doc: | - A numerical factor applied to pixels affected by the beam stop penumbra. - Used in data files from NIST/NCNR instruments. - - See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. - - # optional items - title: - exists: ['min', '1', 'max', '1'] - doc: | - Title of this *SASentry*. - Make it so that you can recognize the data by its title. - Could be the name of the sample, - the name for the measured data, or something else representative. - run: - exists: ['min', '1', 'max', 'unbounded'] - nameType: any - doc: | - Run identification for this *SASentry*. - For many facilities, this is an integer, such as en experiment number. - Use multiple instances of ``run`` as needed, keeping - in mind that HDF5 requires unique names for all entities - in a group. - \@name: - exists: optional - doc: | - Optional string attribute to identify this particular *run*. - Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. - (NXinstrument): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` - enumeration: [SASinstrument] - doc: | - Description of the small-angle scattering instrument. - - Consider, carefully, the relevance to the SAS data analysis process - when adding subgroups in this **NXinstrument** group. Additional information - can be added but will likely be ignored by standardized data anlysis processes. - - The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** - group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any - point downstream from the source. - - # =========== - # SASaperture - # =========== - (NXaperture): - exists: ['min', '0'] - doc: | - :ref:`NXaperture` is generic and limits the variation in data files. - - Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASaperture` - enumeration: [SASaperture] - shape: - doc: | - describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) - x_gap(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - opening along the :math:`x` axis - y_gap(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - opening along the :math:`y` axis - - # ============== - # SAScollimation - # ============== - (NXcollimator): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` - enumeration: [SAScollimation] - doc: | - Description of a collimating element (defines the divergence of the beam) in the instrument. - - To document a slit, pinhole, or the beam, refer to the - documentation of the ``NXinstrument`` group above. - length(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Amount/length of collimation inserted (as on a SANS instrument) - distance(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Distance from this collimation element to the sample - - # SAScollimation - - # ============================ - # SASdetector - # ============================ - (NXdetector): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASdetector` - enumeration: [SASdetector] - doc: | - Description of a detector in the instrument. - name: - exists: ['max', '1'] - doc: | - Identifies the name of this detector - SDD(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Distance between sample and detector. - - Note: In NXdetector, the ``distance`` field records the - distance to the previous component ... most often the sample. - This use is the same as ``SDD`` for most SAS - instruments but not all. For example, Bonse-Hart cameras - have one or more crystals between the sample and detector. - - We define here the field ``SDD`` to document without - ambiguity the distance between sample and detector. - slit_length(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Slit length of the instrument for this detector, - expressed in the same units as :math:`Q`. - x_position(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Location of the detector in :math:`x` - y_position(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Location of the detector in :math:`y` - roll(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the detector about the :math:`z` axis (roll) - pitch(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the detector about the :math:`x` axis (roll) - yaw(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the detector about the :math:`y` axis (yaw) - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Position of the beam center on the detector. - - This is the x position where the direct beam would hit the detector plane. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. The value can be any - real number (positive, zero, or negative). - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Position of the beam center on the detector. - - This is the y position where the direct beam would hit the detector plane. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. The value can be any - real number (positive, zero, or negative). - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size - - # SASdetector - - # ============================ - # SASsource - # ============================ - (NXsource): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASsource` - enumeration: [SASsource] - doc: | - Description of the radiation source. - radiation: - exists: optional - deprecated: Use either (or both) ``probe`` or ``type`` fields from ``NXsource`` (issue #765) - doc: | - Name of the radiation used. - Note that this is **not** the name of the facility! - - This field contains a value from either the - ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, - it is redundant with existing NeXus structure. - - # enumeration values from NXsource/type and NXsource/probe - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] - beam_shape: - exists: ['min', '0', 'max', '1'] - doc: | - Text description of the shape of the beam (incident on the sample). - incident_wavelength(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_WAVELENGTH - doc: | - wavelength (:math:`\lambda`) of radiation incident on the sample - wavelength_min(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_WAVELENGTH - doc: | - Some facilities specify wavelength using a range. - This is the lowest wavelength in such a range. - wavelength_max(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_WAVELENGTH - doc: | - Some facilities specify wavelength using a range. - This is the highest wavelength in such a range. - incident_wavelength_spread(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_WAVELENGTH - doc: | - Some facilities specify wavelength using a range. - This is the width (FWHM) of such a range. - beam_size_x(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size of the incident beam along the x axis. - beam_size_y(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size of the incident beam along the y axis. - - # SASsource - - # SASinstrument - - # ============== - # SASsample - # ============== - (NXsample): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASsample` - enumeration: [SASsample] - doc: | - Description of the sample. - name: - exists: ['max', '1'] - doc: | - **ID**: Text string that identifies this sample. - thickness(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Thickness of this sample - transmission(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_DIMENSIONLESS - doc: | - Transmission (:math:`I/I_0`) of this sample. - There is no *units* attribute as this number is dimensionless. - - Note: the ability to store a transmission *spectrum*, - instead of a single value, is provided elsewhere in the structure, - in the *SAStransmission_spectrum* element. - temperature(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_TEMPERATURE - doc: | - Temperature of this sample. - details: - exists: ['min', '0', 'max', 'unbounded'] - nameType: any - doc: | - Any additional sample details. - x_position(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Location of the sample in :math:`x` - y_position(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Location of the sample in :math:`y` - roll(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the sample about the :math:`z` axis (roll) - pitch(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the sample about the :math:`x` axis (roll) - yaw(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the sample about the :math:`y` axis (yaw) - - # NXsample - - # ============== - # SASprocess - # ============== - (NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASprocess` - enumeration: [SASprocess] - doc: | - Description of a processing or analysis step. - - Add additional fields as needed to describe value(s) of any - variable, parameter, or term related to the *SASprocess* step. - Be sure to include *units* attributes for all numerical fields. - name: - exists: ['min', '0', 'max', '1'] - doc: | - Optional name for this data processing or analysis step - date(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - doc: | - Optional date for this data processing or analysis step. [#iso8601]_ - - - .. [#iso8601] ISO-8601 standard time representation. - - NeXus dates and times are reported in ISO-8601 - (e.g., ``yyyy-mm-ddThh:mm:ss``) - or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). - - See: http://www.w3.org/TR/NOTE-datetime - or http://en.wikipedia.org/wiki/ISO_8601 for more details. - description: - exists: ['min', '0', 'max', '1'] - doc: | - Optional description for this data processing or analysis step - term: - exists: ['min', '0', 'max', 'unbounded'] - nameType: any - doc: | - Specifies the value of a single variable, parameter, - or term (while defined here as a string, it could be a number) - related to the *SASprocess* step. - - Note: - The name *term* is not required, it could take any name, - as long as the name is unique within this group. - - # suggested at NIAC2014 - # Isn't this ALWAYS a possibility in any NeXus base class? - # Not needed to define this but it is a good suggestion for usage. - (NXnote): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Any additional notes or subprocessing steps will be documented here. - - An **NXnote** group can be added to any NeXus group at or below the - **NXentry** group. It is shown here as a suggestion of a good place - to *consider* its use. - (NXcollection): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Describes anything about *SASprocess* that is not already described. - - Any content not defined in the canSAS standard can be placed at this point. - - Note: - The name of this group is flexible, it could take any name, - as long as it is unique within the **NXprocess** group. - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` - enumeration: [SASprocessnote] - - # SASprocessnote - - # SASprocess - - # ============== - # SASnote - # ============== - (NXcollection): - exists: ['min', '0', 'max', 'unbounded'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASnote` - enumeration: [SASnote] - doc: | - Free form description of anything not covered by other elements. - - # ============================ - # SAStransmission_spectrum - # ============================ - TRANSMISSION_SPECTRUM(NXdata): - exists: ['min', '0'] - doc: | - The *SAStransmission_spectrum* element - - This describes certain data obtained from a variable-wavelength source - such as pulsed-neutron source. - - # requested to be in the 1D format by ISIS - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` - enumeration: [SAStransmission_spectrum] - \@signal: - type: NX_CHAR - doc: | - Name of the default data field. - enumeration: - T: - doc: | - For **SAStransmission_spectrum**, this is always "T". - \@T_axes: - enumeration: - T: - doc: | - the wavelengths field (as a dimension scale) corresponding to this transmission - \@name: - doc: | - Identify what type of spectrum is being described. - It is expected that this value will take either of these two values: - - ====== ============================================== - value meaning - ====== ============================================== - sample measurement with the sample and container - can measurement with just the container - ====== ============================================== - \@timestamp: - type: NX_DATE_TIME - exists: optional - doc: | - ISO-8601 time [#iso8601]_ - lambda(NX_NUMBER): - unit: NX_WAVELENGTH - doc: | - Wavelength of the radiation. - - This array is of the same shape as ``T`` and ``Tdev``. - T(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Transmission values (:math:`I/I_0`) - as a function of wavelength. - - This array is of the same shape as ``lambda`` and ``Tdev``. - \@uncertainties: - doc: | - Names the dataset (in this SASdata group) that provides the - uncertainty of each transmission :math:`T` to be used for data analysis. - The name of the dataset containing the :math:`T` uncertainty - is expected to be ``Tdev``. - - .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 - - Typically: - - @uncertainties="Tdev" - Tdev(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - .. index:: NXcanSAS (applications); Tdev - - Estimated uncertainty (usually standard deviation) - in :math:`T`. Must have the same units as :math:`T`. - - This is the field is named in the *uncertainties* attribute of *T*, as in:: - - T/@uncertainties="Tdev" - - This array is of the same shape as ``lambda`` and ``T``. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0138726f10e2c6809b373544080966e4d3f5a78d2311b780dcabd6ceeea535fa -# -# -# -# -# -# -# -# -# Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. -# -# .. index:: canSAS -# -# For more details, see: -# -# * http://www.cansas.org/ -# * http://www.cansas.org/formats/canSAS1d/1.1/doc/ -# * http://cansas-org.github.io/canSAS2012/ -# * https://github.com/canSAS-org/NXcanSAS_examples -# -# The minimum requirements for *reduced* small-angle scattering data -# as described by canSAS are summarized in the following figure: -# -# .. _canSAS_2012_minimum: -# -# .. figure:: canSAS/2012-minimum.png -# :width: 60% -# -# The minimum requirements for *reduced* small-angle scattering data. -# (:download:`full image <canSAS/2012-minimum.png>`) -# See :ref:`below <NXcanSAS_minimum>` for the minimum required -# information for a NeXus data file -# written to the NXcanSAS specification. -# -# .. rubric:: Implementation of canSAS standard in NeXus -# -# This application definition is an implementation of the canSAS -# standard for storing both one-dimensional and multi-dimensional -# *reduced* small-angle scattering data. -# -# * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. -# * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` -# * External file links are not to be used for the reduced data. -# * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. -# * There is no need for NXcanSAS to refer to any raw data. -# -# The canSAS data format has a structure similar to NeXus, not identical. -# To allow canSAS data to be expressed in NeXus, yet identifiable -# by the canSAS standard, an additional group attribute ``canSAS_class`` -# was introduced. Here is the mapping of some common groups. -# -# =============== ============ ========================== -# group (*) NX_class canSAS_class -# =============== ============ ========================== -# sasentry NXentry SASentry -# sasdata NXdata SASdata -# sasdetector NXdetector SASdetector -# sasinstrument NXinstrument SASinstrument -# sasnote NXnote SASnote -# sasprocess NXprocess SASprocess -# sasprocessnote NXcollection SASprocessnote -# sastransmission NXdata SAStransmission_spectrum -# sassample NXsample SASsample -# sassource NXsource SASsource -# =============== ============ ========================== -# -# (*) The name of each group is a suggestion, -# not a fixed requirement and is chosen as fits each data file. -# See the section on defining -# :ref:`NXDL group and field names <RegExpName>`. -# -# Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) -# for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. -# -# .. _NXcanSAS_minimum: -# -# .. rubric:: The minimum required information for a NeXus data file -# written to the NXcanSAS specification. -# -# .. literalinclude:: canSAS/minimum-required.txt -# :tab-width: 4 -# :linenos: -# :language: text -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which :ref:`NXdata` group -# contains the data to be shown by default. -# It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. -# The value is the name of the default :ref:`NXdata` group. -# Usually, this will be the name of the first *SASdata* group. -# -# -# -# .. index:: NXcanSAS (applications); SASentry -# -# Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group -# (when data from multiple techniques are being stored) -# or as a replacement for the ``NXentry`` group. -# -# Note: It is required for all numerical objects to provide -# a *units* attribute that describes the engineering units. -# Use the Unidata UDunits [#]_ specification -# as this is compatible with various community standards. -# -# .. [#] The UDunits specification also includes instructions for derived units. -# -# -# -# Official canSAS group: **SASentry** -# -# -# -# -# -# -# -# Describes the version of the canSAS standard used to write this data. -# This must be a text (not numerical) representation. Such as:: -# -# @version="1.1" -# -# -# -# -# -# -# -# -# Official NeXus NXDL schema to which this subentry conforms. -# -# -# -# -# -# -# -# -# -# A *SASData* group contains a single reduced small-angle scattering data set -# that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. -# -# *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) -# -# The name of each *SASdata* group must be unique within a SASentry group. -# Suggest using names such as ``sasdata01``. -# -# NOTE: For the first *SASdata* group, be sure to write the chosen name -# into the `SASentry/@default` attribute, as in:: -# -# SASentry/@default="sasdata01" -# -# A *SASdata* group has several attributes: -# -# * I_axes -# * Q_indices -# * Mask_indices -# -# To indicate the dependency relationships of other varied parameters, -# use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` -# or ``@Pressure_indices``). -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASdata` -# -# -# -# -# -# -# -# Name of the default data field. -# -# -# For canSAS **SASdata**, this is always "I". -# -# -# -# -# String array that defines the independent data fields used in -# the default plot for all of the dimensions of the *signal* field -# (the *signal* field is the field in this group that is named by -# the ``signal`` attribute of this group). -# One entry is provided for every dimension of the ``I`` data object. -# Such as:: -# -# @I_axes="Temperature", "Time", "Pressure", "Q", "Q" -# -# Since there are five items in the list, the intensity field of this example -# ``I`` must be a five-dimensional array (rank=5). -# -# -# -# -# -# Integer or integer array that describes which indices -# (of the :math:`I` data object) are used to -# reference the ``Q`` data object. The items in this array -# use zero-based indexing. Such as:: -# -# @Q_indices=1,3,4 -# -# which indicates that ``Q`` requires three indices -# from the :math:`I` data object: one for time and -# two for Q position. Thus, in this example, the -# ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. -# -# -# -# -# Name of the data mask field. -# -# .. see: https://github.com/nexusformat/definitions/issues/533 -# -# The data *mask* must have the same shape as the *data* field. -# Positions in the mask correspond to positions in the *data* field. -# The value of the mask field may be either a boolean array -# where ``false`` means *no mask* and ``true`` means *mask* -# or a more descriptive array as as defined in :ref:`NXdetector`. -# -# -# -# -# Integer or integer array that describes which indices -# (of the :math:`I` data object) are used to -# reference the ``Mask`` data object. The items in this -# array use zero-based indexing. Such as:: -# -# @Mask_indices=3,4 -# -# which indicates that Q requires two indices -# from the :math:`I` data object for Q position. -# -# -# -# -# ISO-8601 time [#iso8601]_ -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); Q -# -# Array of :math:`Q` data to accompany :math:`I`. -# -# .. figure:: canSAS/Q-geometry.jpg -# :width: 60% -# -# The :math:`\vec{Q}` geometry. -# (:download:`full image <canSAS/Q-geometry.jpg>`) -# -# :math:`Q` may be represented as either -# the three-dimensional scattering vector :math:`\vec{Q}` -# or the magnitude of the scattering vector, :math:`|\vec{Q}|`. -# -# .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) -# -# When we write :math:`Q`, we may refer to either or both of -# :math:`|\vec{Q}|` -# or :math:`\vec{Q}`, depending on the context. -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units will generate -# a warning from validation software and may not -# be processed by some analysis software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# (optional: for numerical arrays) -# -# Names the dataset (in this SASdata group) that provides the -# uncertainty to be used for data analysis. -# The name of the dataset containing the :math:`Q` uncertainty -# is flexible. The name must be unique in the *SASdata* group. -# -# .. comment -# see: https://github.com/canSAS-org/canSAS2012/issues/7 -# -# Such as:: -# -# @uncertainties="Q_uncertainties" -# -# The *uncertainties* field will have the same *shape* (dimensions) -# as the Q field. -# -# These values are the estimates of uncertainty of each Q. By default, -# this will be interpreted to be the estimated standard deviation. -# In special cases, when a standard deviation cannot possibly be used, -# its value can specify another measure of distribution width. -# -# There may also be a subdirectory (optional) with constituent -# components. -# -# .. note:: To report distribution in reported :math:`Q` values, -# use the ``@resolutions`` attribute. It is possible for both -# ``@resolutions`` and ``uncertainties`` to be reported. -# -# -# -# -# -# .. index:: NXcanSAS (applications); resolutions -# -# (optional: for numerical arrays) -# -# Names the dataset (in this SASdata group) containing the :math:`Q` resolution. -# The name of the dataset containing the :math:`Q` resolution -# is flexible. The name must be unique in the *SASdata* group. -# -# .. comment -# see: https://github.com/canSAS-org/canSAS2012/issues/7 -# -# The *resolutions* field will have the same *shape* (dimensions) -# as the Q field. -# -# Generally, this is the principal resolution of each :math:`Q`. -# Names the data object (in this SASdata group) that provides the -# :math:`Q` resolution to be used for data analysis. Such as:: -# -# @resolutions="Qdev" -# -# To specify two-dimensional resolution for slit-smearing geometry, -# such as (*dQw*, *dQl*), use a string array, such as:: -# -# @resolutions="dQw", "dQl" -# -# There may also be a subdirectory (optional) with constituent -# components. -# -# This pattern will demonstrate how to introduce further as-yet -# unanticipated terms related to the data. -# -# .. comment -# see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 -# -# By default, the values of the resolutions data object are assumed to be -# one standard deviation of any function used to approximate the -# resolution function. This equates to the width of the gaussian -# distribution if a Gaussian is chosen. See the ``@resolutions_description`` -# attribute. -# -# .. note:: To report uncertainty in reported :math:`Q` values, -# use the ``@uncertainties`` attribute. It is possible for both -# ``@resolutions`` and ``uncertainties`` to be reported. -# -# -# -# -# -# (optional) -# Generally, this describes the :math:`Q` ``@resolutions`` data object. -# By default, the value is assumed to be "Gaussian". These are -# suggestions: -# -# * Gaussian -# * Lorentzian -# * Square : -# note that the full width of the square would be ~2.9 times -# the standard deviation specified in the vector -# * Triangular -# * Sawtooth-outward : vertical edge pointing to larger Q -# * Sawtooth-inward vertical edge pointing to smaller Q -# * Bin : range of values contributing -# (for example, when 2-D detector data have been reduced -# to a 1-D :math:`I(|Q|)` dataset) -# -# For other meanings, it may be necessary to provide further details -# such as the function used to assess the resolution. -# In such cases, use additional datasets or a :ref:`NXnote` subgroup -# to include that detail. -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); I -# -# Array of intensity (:math:`I`) data. -# -# The intensity may be represented in one of these forms: -# -# **absolute units**: :math:`d\Sigma/d\Omega(Q)` -# differential cross-section -# per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) -# -# **absolute units**: :math:`d\sigma/d\Omega(Q)` -# differential cross-section -# per unit atom per unit solid angle (such as: cm^2 or m^2) -# -# **arbitrary units**: :math:`I(Q)` -# usually a ratio of two detectors -# but units are meaningless (such as: a.u. or counts) -# -# This presents a few problems -# for analysis software to sort out when reading the data. -# Fortunately, it is possible to analyze the *units* to determine which type of -# intensity is being reported and make choices at the time the file is read. But this is -# an area for consideration and possible improvement. -# -# One problem arises with software that automatically converts data into some canonical -# units used by that software. The software should not convert units between these different -# types of intensity indiscriminately. -# -# A second problem is that when arbitrary units are used, then the set of possible -# analytical results is restricted. With such units, no meaningful volume fraction -# or number density can be determined directly from :math:`I(Q)`. -# -# In some cases, it is possible to apply a factor to convert the arbitrary -# units to an absolute scale. This should be considered as a possibility -# of the analysis process. -# -# Where this documentation says *typical units*, it is possible that small-angle -# data may be presented in other units and still be consistent with NeXus. -# See the :ref:`design-units` section. -# -# -# -# Engineering units to use when expressing -# :math:`I` and intensity-related terms. -# -# Data expressed in other units (or missing a ``@units`` attribute) -# will be treated as ``arbitrary`` by some software packages. -# -# For software using the UDUNITS-2 library, ``arbitrary`` will be -# changed to ``unknown`` for handling with that library. -# -# -# -# includes m2/m3 and 1/m/sr -# -# -# includes cm2/cm3 and 1/cm/sr -# -# -# -# -# -# -# -# -# (optional: for numerical arrays) -# -# Names the dataset (in this SASdata group) that provides the -# uncertainty of :math:`I` to be used for data analysis. -# The name of the dataset containing the :math:`I` uncertainty -# is flexible. The name must be unique in the *SASdata* group. -# -# .. comment -# see: https://github.com/canSAS-org/canSAS2012/issues/7 -# -# Generally, this is the estimate of the uncertainty of each :math:`I`. -# Typically the estimated standard deviation. -# -# *Idev* is the canonical name from the 1D standard. -# The NXcanSAS standard allows for the name to be described using this attribute. -# Such as:: -# -# @uncertainties="Idev" -# -# -# -# -# -# (optional) -# Names the field (a.k.a. dataset) that contains a factor -# to multiply ``I``. By default, this value is unity. -# Should an uncertainty be associated with the scaling factor -# field, the field containing that uncertainty would be -# designated via the ``uncertainties`` attribute. -# Such as:: -# -# I : NX_NUMBER -# @uncertainties="Idev" : NX_CHAR -# @scaling_factor="I_scaling" : NX_CHAR -# Idev : NX_NUMBER -# I_scaling : NX_NUMBER -# @uncertainties="I_scaling_dev" : NX_CHAR -# I_scaling_dev : NX_NUMBER -# -# The exact names for ``I_scaling`` and ``I_scaling_dev`` are not -# defined by NXcanSAS. The user has the flexibility to use names -# different than those shown in this example. -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); Idev -# -# Estimated **uncertainty** (usually standard deviation) -# in :math:`I`. Must have the same units as :math:`I`. -# -# When present, the name of this field is also -# recorded in the *uncertainties* attribute of *I*, as in:: -# -# I/@uncertainties="Idev" -# -# -# -# -# Engineering units to use when expressing -# :math:`I` and intensity-related terms. -# -# Data expressed in other units (or missing a ``@units`` attribute) -# will generate a warning from any validation process -# and will be treated as ``arbitrary`` by some analysis software packages. -# -# For software using the UDUNITS-2 library, ``arbitrary`` will be -# changed to ``unknown`` for handling with that library. -# -# -# -# includes m2/m3 and 1/m/sr -# -# -# includes cm2/cm3 and 1/cm/sr -# -# -# -# -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); Qdev -# -# Estimated :math:`Q` **resolution** (usually standard deviation). -# Must have the same units as :math:`Q`. -# -# When present, the name of this field is also -# recorded in the *resolutions* attribute of *Q*, -# as in:: -# -# Q/@resolutions="Qdev" -# -# or:: -# -# Q/@resolutions="dQw", "dQl" -# -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units may not be processed by some -# software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); dQw -# -# :math:`Q` **resolution** along the axis of scanning -# (the high-resolution *slit width* direction). -# Useful for defining resolution data from -# slit-smearing instruments such as Bonse-Hart geometry. -# Must have the same units as :math:`Q`. -# -# When present, the name of this field is also -# recorded in the *resolutions* attribute of *Q*, -# as in:: -# -# Q/@resolutions="dQw", "dQl" -# -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units may not be processed by some -# software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); dQl -# -# :math:`Q` **resolution** perpendicular to the axis of scanning -# (the low-resolution *slit length* direction). -# Useful for defining resolution data from -# slit-smearing instruments such as Bonse-Hart geometry. -# Must have the same units as :math:`Q`. -# -# When present, the name of this field is also -# recorded in the *resolutions* attribute of *Q*, -# as in:: -# -# Q/@resolutions="dQw", "dQl" -# -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units may not be processed by some -# software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# -# -# Mean value of :math:`Q` for this data point. -# Useful when describing data that has been -# binned from higher-resolution data. -# -# It is expected that ``Q`` is provided -# and that both ``Q`` and ``Qmean`` will have the same units. -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units may not be processed by some -# software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# -# A numerical factor applied to pixels affected by the beam stop penumbra. -# Used in data files from NIST/NCNR instruments. -# -# See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. -# -# -# -# -# -# -# -# -# Title of this *SASentry*. -# Make it so that you can recognize the data by its title. -# Could be the name of the sample, -# the name for the measured data, or something else representative. -# -# -# -# -# Run identification for this *SASentry*. -# For many facilities, this is an integer, such as en experiment number. -# Use multiple instances of ``run`` as needed, keeping -# in mind that HDF5 requires unique names for all entities -# in a group. -# -# -# -# Optional string attribute to identify this particular *run*. -# Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` -# -# -# -# -# -# Description of the small-angle scattering instrument. -# -# Consider, carefully, the relevance to the SAS data analysis process -# when adding subgroups in this **NXinstrument** group. Additional information -# can be added but will likely be ignored by standardized data anlysis processes. -# -# The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** -# group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any -# point downstream from the source. -# -# -# -# -# -# -# :ref:`NXaperture` is generic and limits the variation in data files. -# -# Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASaperture` -# -# -# -# -# -# -# -# describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) -# -# -# -# opening along the :math:`x` axis -# -# -# opening along the :math:`y` axis -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` -# -# -# -# -# -# Description of a collimating element (defines the divergence of the beam) in the instrument. -# -# To document a slit, pinhole, or the beam, refer to the -# documentation of the ``NXinstrument`` group above. -# -# -# -# Amount/length of collimation inserted (as on a SANS instrument) -# -# -# -# Distance from this collimation element to the sample -# -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASdetector` -# -# -# -# -# -# Description of a detector in the instrument. -# -# -# -# Identifies the name of this detector -# -# -# -# Distance between sample and detector. -# -# Note: In NXdetector, the ``distance`` field records the -# distance to the previous component ... most often the sample. -# This use is the same as ``SDD`` for most SAS -# instruments but not all. For example, Bonse-Hart cameras -# have one or more crystals between the sample and detector. -# -# We define here the field ``SDD`` to document without -# ambiguity the distance between sample and detector. -# -# -# -# -# Slit length of the instrument for this detector, -# expressed in the same units as :math:`Q`. -# -# -# -# -# Location of the detector in :math:`x` -# -# -# Location of the detector in :math:`y` -# -# -# Rotation of the detector about the :math:`z` axis (roll) -# -# -# Rotation of the detector about the :math:`x` axis (roll) -# -# -# Rotation of the detector about the :math:`y` axis (yaw) -# -# -# -# -# Position of the beam center on the detector. -# -# This is the x position where the direct beam would hit the detector plane. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. The value can be any -# real number (positive, zero, or negative). -# -# -# -# -# -# Position of the beam center on the detector. -# -# This is the y position where the direct beam would hit the detector plane. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. The value can be any -# real number (positive, zero, or negative). -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASsource` -# -# -# -# -# -# Description of the radiation source. -# -# -# -# -# Name of the radiation used. -# Note that this is **not** the name of the facility! -# -# This field contains a value from either the -# ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, -# it is redundant with existing NeXus structure. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Text description of the shape of the beam (incident on the sample). -# -# -# wavelength (:math:`\lambda`) of radiation incident on the sample -# -# -# -# Some facilities specify wavelength using a range. -# This is the lowest wavelength in such a range. -# -# -# -# -# Some facilities specify wavelength using a range. -# This is the highest wavelength in such a range. -# -# -# -# -# Some facilities specify wavelength using a range. -# This is the width (FWHM) of such a range. -# -# -# -# Size of the incident beam along the x axis. -# -# -# Size of the incident beam along the y axis. -# -# -# -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASsample` -# -# -# -# -# -# Description of the sample. -# -# -# -# **ID**: Text string that identifies this sample. -# -# -# Thickness of this sample -# -# -# -# Transmission (:math:`I/I_0`) of this sample. -# There is no *units* attribute as this number is dimensionless. -# -# Note: the ability to store a transmission *spectrum*, -# instead of a single value, is provided elsewhere in the structure, -# in the *SAStransmission_spectrum* element. -# -# -# -# Temperature of this sample. -# -# -# Any additional sample details. -# -# -# -# Location of the sample in :math:`x` -# -# -# Location of the sample in :math:`y` -# -# -# Rotation of the sample about the :math:`z` axis (roll) -# -# -# Rotation of the sample about the :math:`x` axis (roll) -# -# -# Rotation of the sample about the :math:`y` axis (yaw) -# -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASprocess` -# -# -# -# -# -# Description of a processing or analysis step. -# -# Add additional fields as needed to describe value(s) of any -# variable, parameter, or term related to the *SASprocess* step. -# Be sure to include *units* attributes for all numerical fields. -# -# -# -# Optional name for this data processing or analysis step -# -# -# -# Optional date for this data processing or analysis step. [#iso8601]_ -# -# -# .. [#iso8601] ISO-8601 standard time representation. -# -# NeXus dates and times are reported in ISO-8601 -# (e.g., ``yyyy-mm-ddThh:mm:ss``) -# or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). -# -# See: http://www.w3.org/TR/NOTE-datetime -# or http://en.wikipedia.org/wiki/ISO_8601 for more details. -# -# -# -# Optional description for this data processing or analysis step -# -# -# -# Specifies the value of a single variable, parameter, -# or term (while defined here as a string, it could be a number) -# related to the *SASprocess* step. -# -# Note: -# The name *term* is not required, it could take any name, -# as long as the name is unique within this group. -# -# -# -# -# -# -# Any additional notes or subprocessing steps will be documented here. -# -# An **NXnote** group can be added to any NeXus group at or below the -# **NXentry** group. It is shown here as a suggestion of a good place -# to *consider* its use. -# -# -# -# -# -# Describes anything about *SASprocess* that is not already described. -# -# Any content not defined in the canSAS standard can be placed at this point. -# -# Note: -# The name of this group is flexible, it could take any name, -# as long as it is unique within the **NXprocess** group. -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASnote` -# -# -# -# -# -# -# Free form description of anything not covered by other elements. -# -# -# -# -# -# -# -# The *SAStransmission_spectrum* element -# -# This describes certain data obtained from a variable-wavelength source -# such as pulsed-neutron source. -# -# -# The name of each *SAStransmission_spectrum* group must be unique within a SASentry group. -# Suggest using names such as ``sastransmission_spectrum01``. -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` -# -# -# -# -# -# -# Name of the default data field. -# -# -# For **SAStransmission_spectrum**, this is always "T". -# -# -# -# -# -# the wavelengths field (as a dimension scale) corresponding to this transmission -# -# -# -# -# -# Identify what type of spectrum is being described. -# It is expected that this value will take either of these two values: -# -# ====== ============================================== -# value meaning -# ====== ============================================== -# sample measurement with the sample and container -# can measurement with just the container -# ====== ============================================== -# -# -# -# -# ISO-8601 time [#iso8601]_ -# -# -# -# -# -# Wavelength of the radiation. -# -# This array is of the same shape as ``T`` and ``Tdev``. -# -# -# -# -# Transmission values (:math:`I/I_0`) -# as a function of wavelength. -# -# This array is of the same shape as ``lambda`` and ``Tdev``. -# -# -# -# Names the dataset (in this SASdata group) that provides the -# uncertainty of each transmission :math:`T` to be used for data analysis. -# The name of the dataset containing the :math:`T` uncertainty -# is expected to be ``Tdev``. -# -# .. comment -# see: https://github.com/canSAS-org/canSAS2012/issues/7 -# -# Typically: -# -# @uncertainties="Tdev" -# -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); Tdev -# -# Estimated uncertainty (usually standard deviation) -# in :math:`T`. Must have the same units as :math:`T`. -# -# This is the field is named in the *uncertainties* attribute of *T*, as in:: -# -# T/@uncertainties="Tdev" -# -# This array is of the same shape as ``lambda`` and ``T``. -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXdirecttof.yaml b/applications/nyaml/NXdirecttof.yaml deleted file mode 100644 index 8ced0bc49d..0000000000 --- a/applications/nyaml/NXdirecttof.yaml +++ /dev/null @@ -1,102 +0,0 @@ -category: application -doc: | - This is a application definition for raw data from a direct geometry TOF spectrometer -type: group -NXdirecttof(NXtofraw): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXdirecttof] - (NXinstrument): - (NXfermi_chopper)fermi_chopper: - exists: ['min', '0'] - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - chopper rotation speed - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy selected - (NXdisk_chopper)disk_chopper: - exists: ['min', '0'] - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - chopper rotation speed - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy selected - doc: | - We definitly want the rotation_speed and energy of the chopper. Thus either - a fermi_chopper or a disk_chopper group is required. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1d47a6d74aba3fd326b8022400cf62c8d44aa409690508a10b91dce0f188c23c -# -# -# -# -# This is a application definition for raw data from a direct geometry TOF spectrometer -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# chopper rotation speed -# -# -# energy selected -# -# -# -# -# chopper rotation speed -# -# -# energy selected -# -# -# -# We definitly want the rotation_speed and energy of the chopper. Thus either -# a fermi_chopper or a disk_chopper group is required. -# -# -# -# diff --git a/applications/nyaml/NXfluo.yaml b/applications/nyaml/NXfluo.yaml deleted file mode 100644 index 34390473a8..0000000000 --- a/applications/nyaml/NXfluo.yaml +++ /dev/null @@ -1,165 +0,0 @@ -category: application -doc: | - This is an application definition for raw data from an X-ray fluorescence experiment -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nE: | - Number of energies -type: group -NXfluo(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - enumeration: [NXfluo] - (NXinstrument): - (NXsource): - type: - name: - probe: - enumeration: [x-ray] - (NXmonochromator)monochromator: - wavelength(NX_FLOAT): - (NXdetector)fluorescence: - data(NX_INT): - axes: energy - signal: 1 - dimensions: - rank: 1 - dim: [[1, nE]] - energy(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nE]] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_INT): - (NXdata)data: - energy(link): - target: /entry/instrument/fluorescence/energy - data(link): - target: /entry/instrument/fluorescence/data - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a29da208a1ae223c660dcd483b2d1f475272c28538ec79fc7f342883ca2cd321 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of energies -# -# -# -# This is an application definition for raw data from an X-ray fluorescence experiment -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXindirecttof.yaml b/applications/nyaml/NXindirecttof.yaml deleted file mode 100644 index ea4502b226..0000000000 --- a/applications/nyaml/NXindirecttof.yaml +++ /dev/null @@ -1,111 +0,0 @@ -category: application -doc: | - This is a application definition for raw data from a direct geometry TOF spectrometer -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: | - Number of detectors -type: group -NXindirecttof(NXtofraw): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXindirecttof] - (NXinstrument): - (NXmonochromator)analyser: - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - analyzed energy - dimensions: - rank: 1 - dim: [[1, nDet]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - polar angle towards sample - dimensions: - rank: 1 - dim: [[1, nDet]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance from sample - dimensions: - rank: 1 - dim: [[1, nDet]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a8938d31a14f39d6935cd347cc25df7c67207c21c5bd8aab84182f83d2681d6e -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of detectors -# -# -# This is a application definition for raw data from a direct geometry TOF spectrometer -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# analyzed energy -# -# -# -# -# polar angle towards sample -# -# -# -# -# distance from sample -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXiqproc.yaml b/applications/nyaml/NXiqproc.yaml deleted file mode 100644 index de29062cf5..0000000000 --- a/applications/nyaml/NXiqproc.yaml +++ /dev/null @@ -1,201 +0,0 @@ -category: application -doc: | - Application definition for any :math:`I(Q)` data. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nVars: | - The number of values taken by the varied variable - nQX: | - Number of values for the first dimension of Q - nQY: | - Number of values for the second dimension of Q -type: group -NXiqproc(NXobject): - (NXentry): - \@entry: - - # TODO documentation string needed here - title: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXiqproc] - (NXinstrument)instrument: - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - name(NX_CHAR): - doc: | - Name of the instrument from which this data was reduced. - (NXsample): - name: - doc: | - Descriptive name of sample - (NXprocess)reduction: - program(NX_CHAR): - version(NX_CHAR): - (NXparameters)input: - filenames(NX_CHAR): - doc: | - Raw data files used to generate this I(Q) - doc: | - Input parameters for the reduction program used - (NXparameters)output: - doc: | - Eventual output parameters from the data reduction program used - (NXdata): - data(NX_INT): - signal: 1 - doc: | - This is I(Q). The client has to analyse the dimensions - of I(Q). Often, multiple I(Q) for various environment - conditions are measured; that would be the first - dimension. Q can be multidimensional, this accounts for - the further dimensions in the data - dimensions: - rank: 3 - dim: [[1, nVars], [2, nQX], [3, nQY]] - variable(NX_NUMBER): - axis: 1 - dimensions: - rank: 1 - dim: [[1, nVars]] - \@varied_variable: - doc: | - The real name of the varied variable in the first dim of data, temperature, P, MF etc... - qx(NX_NUMBER): - axis: 2 - doc: | - Values for the first dimension of Q - dimensions: - rank: 1 - dim: [[1, nQX]] - qy(NX_NUMBER): - axis: 3 - doc: | - Values for the second dimension of Q - dimensions: - rank: 1 - dim: [[1, nQY]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 20d4c942462350f47af152e37e83f320e5814be2b399fc9a4897794d1ce4916e -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# The number of values taken by the varied variable -# -# -# Number of values for the first dimension of Q -# -# -# Number of values for the second dimension of Q -# -# -# Application definition for any :math:`I(Q)` data. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name of the instrument from which this data was reduced. -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# Raw data files used to generate this I(Q) -# Input parameters for the reduction program used -# -# Eventual output parameters from the data reduction program used -# -# -# -# This is I(Q). The client has to analyse the dimensions -# of I(Q). Often, multiple I(Q) for various environment -# conditions are measured; that would be the first -# dimension. Q can be multidimensional, this accounts for -# the further dimensions in the data -# -# -# -# -# -# -# -# -# -# -# -# -# The real name of the varied variable in the first dim of data, temperature, P, MF etc... -# -# Values for the first dimension of Q -# -# -# -# Values for the second dimension of Q -# -# -# -# -# diff --git a/applications/nyaml/NXlauetof.yaml b/applications/nyaml/NXlauetof.yaml deleted file mode 100644 index 60691e613e..0000000000 --- a/applications/nyaml/NXlauetof.yaml +++ /dev/null @@ -1,244 +0,0 @@ -category: application -doc: | - This is the application definition for a TOF laue diffractometer -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nXPixels: | - Number of X pixels - nYPixels: | - Number of Y pixels - nTOF: | - Time of flight -type: group -NXlauetof(NXobject): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXlauetof] - (NXinstrument)instrument: - (NXdetector)detector: - doc: | - This assumes a planar 2D detector. All angles and distances refer to the center of the - detector. - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - The polar_angle (two theta) where the detector is placed. - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - The azimuthal angle where the detector is placed. - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nXPixels], [2, nYPixels], [3, nTOF]] - \@signal: - type: NX_POSINT - enumeration: [1] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - distance(NX_FLOAT): - unit: NX_LENGTH - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, nTOF]] - (NXsample)sample: - name: - doc: | - Descriptive name of sample - orientation_matrix(NX_FLOAT): - doc: | - The orientation matrix according to Busing and - Levy conventions. This is not strictly necessary as - the UB can always be derived from the data. But - let us bow to common usage which includes thie - UB nearly always. - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - unit_cell(NX_FLOAT): - doc: | - The unit cell, a, b, c, alpha, beta, gamma. - Again, not strictly necessary, but normally written. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) or received monitor counts - (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_INT): - doc: | - use these attributes ``primary=1 signal=1`` - dimensions: - rank: 1 - dim: [[1, nTOF]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, nTOF]] - (NXdata)name: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9e664cc6cefa2508344073c6ddcac30bdfaa76a7950aaba871bf13b9f6f72be4 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of X pixels -# -# -# Number of Y pixels -# -# -# Time of flight -# -# -# -# This is the application definition for a TOF laue diffractometer -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# This assumes a planar 2D detector. All angles and distances refer to the center of the -# detector. -# -# -# The polar_angle (two theta) where the detector is placed. -# -# -# The azimuthal angle where the detector is placed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# The orientation matrix according to Busing and -# Levy conventions. This is not strictly necessary as -# the UB can always be derived from the data. But -# let us bow to common usage which includes thie -# UB nearly always. -# -# -# -# -# -# -# -# -# The unit cell, a, b, c, alpha, beta, gamma. -# Again, not strictly necessary, but normally written. -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) or received monitor counts -# (monitor). -# -# -# -# -# -# -# preset value for time or monitor -# -# -# use these attributes ``primary=1 signal=1`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXmonopd.yaml b/applications/nyaml/NXmonopd.yaml deleted file mode 100644 index f6381a17ce..0000000000 --- a/applications/nyaml/NXmonopd.yaml +++ /dev/null @@ -1,223 +0,0 @@ -category: application -doc: | - Monochromatic Neutron and X-Ray Powder diffractometer - - Instrument - definition for a powder diffractometer at a monochromatic neutron - or X-ray beam. This is both suited for a powder diffractometer - with a single detector or a powder diffractometer with a position - sensitive detector. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - i: | - i is the number of wavelengths - nDet: | - Number of detectors -type: group -NXmonopd(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXmonopd] - (NXinstrument): - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXcrystal): - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Optimum diffracted wavelength - dimensions: - rank: 1 - dim: [[1, i]] - (NXdetector): - polar_angle(NX_FLOAT): - axis: 1 - dimensions: - rank: 1 - dim: [[1, nDet]] - data(NX_INT): - signal: 1 - doc: | - detector signal (usually counts) are already - corrected for detector efficiency - dimensions: - rank: 1 - dim: [[1, nDet]] - (NXsample): - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder diagram - has been obtained through an omega-2theta scan like from a - traditional single detector powder diffractometer - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - integral(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts - (NXdata): - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - doc: | - Link to polar angle in /NXentry/NXinstrument/NXdetector - data(link): - target: /NXentry/NXinstrument/NXdetector/data - doc: | - Link to data in /NXentry/NXinstrument/NXdetector - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a85a64b0de4e045e8b6275a9ef6309437ba7aaad04f28e31d62f46d4744763c1 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# i is the number of wavelengths -# -# -# Number of detectors -# -# -# -# Monochromatic Neutron and X-Ray Powder diffractometer -# -# Instrument -# definition for a powder diffractometer at a monochromatic neutron -# or X-ray beam. This is both suited for a powder diffractometer -# with a single detector or a powder diffractometer with a position -# sensitive detector. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Optimum diffracted wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# detector signal (usually counts) are already -# corrected for detector efficiency -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# Optional rotation angle for the case when the powder diagram -# has been obtained through an omega-2theta scan like from a -# traditional single detector powder diffractometer -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Total integral monitor counts -# -# -# -# -# Link to polar angle in /NXentry/NXinstrument/NXdetector -# -# -# Link to data in /NXentry/NXinstrument/NXdetector -# -# -# -# diff --git a/applications/nyaml/NXmx.yaml b/applications/nyaml/NXmx.yaml deleted file mode 100644 index 4f3b28e858..0000000000 --- a/applications/nyaml/NXmx.yaml +++ /dev/null @@ -1,1744 +0,0 @@ -category: application -doc: | - functional application definition for macromolecular crystallography -symbols: - doc: | - These symbols will be used below to coordinate datasets - with the same shape. Most MX x-ray detectors will produce - two-dimensional images. Some will produce three-dimensional - images, using one of the indices to select a detector module. - dataRank: | - Rank of the ``data`` field - nP: | - Number of scan points - i: | - Number of detector pixels in the slowest direction - j: | - Number of detector pixels in the second slowest direction - k: | - Number of detector pixels in the third slowest direction - m: | - Number of channels in the incident beam spectrum, if known - groupIndex: | - An array of the hierarchical levels of the parents of detector - elements or groupings of detector elements. - A top-level element or grouping has parent level -1. -type: group -NXmx(NXobject): - (NXentry): - doc: | - Note, it is recommended that ``file_name`` and ``file_time`` are included - as attributes at the root of a file that includes :ref:`NXmx`. See - :ref:`NXroot`. - \@version: - exists: optional - doc: | - Describes the version of the NXmx definition used to write this data. - This must be a text (not numerical) representation. Such as:: - - @version="1.0" - enumeration: [1.0] - title(NX_CHAR): - exists: ['min', '0'] - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time/date of the first data point collected in UTC, - using the Z suffix to avoid confusion with local time. - Note that the time zone of the beamline should be provided in - NXentry/NXinstrument/time_zone. - end_time(NX_DATE_TIME): - exists: ['min', '0'] - doc: | - ISO 8601 time/date of the last data point collected in UTC, - using the Z suffix to avoid confusion with local time. - Note that the time zone of the beamline should be provided in - NXentry/NXinstrument/time_zone. This field should only be - filled when the value is accurately observed. If the data - collection aborts or otherwise prevents accurate recording of - the end_time, this field should be omitted. - end_time_estimated(NX_DATE_TIME): - doc: | - ISO 8601 time/date of the last data point collected in UTC, - using the Z suffix to avoid confusion with local time. - Note that the time zone of the beamline should be provided in - NXentry/NXinstrument/time_zone. This field may be filled - with a value estimated before an observed value is available. - definition: - doc: | - NeXus NXDL schema to which this file conforms - enumeration: [NXmx] - (NXdata): - data(NX_NUMBER): - exists: recommended - doc: | - For a dimension-2 detector, the rank of the data array will be 3. - For a dimension-3 detector, the rank of the data array will be 4. - This allows for the introduction of the frame number as the - first index. - dimensions: - rank: dataRank - dim: [[1, nP], [2, i], [3, j], [4, k]] - dim_parameters: - required: ['false'] - (NXsample): - name(NX_CHAR): - doc: | - Descriptive name of sample - depends_on(NX_CHAR): - - # better type for paths the need to resolve - doc: | - This is a requirement to describe for any scan experiment. - - The axis on which the sample position depends may be stored - anywhere, but is normally stored in the NXtransformations - group within the NXsample group. - - If there is no goniometer, e.g. with a jet, depends_on - should be set to "." - (NXtransformations): - exists: ['min', '0'] - doc: | - This is the recommended location for sample goniometer - and other related axes. - - This is a requirement to describe for any scan experiment. - The reason it is optional is mainly to accommodate XFEL - single shot exposures. - - Use of the depends_on field and the NXtransformations group is - strongly recommended. As noted above this should be an absolute - requirement to have for any scan experiment. - - The reason it is optional is mainly to accommodate XFEL - single shot exposures. - temperature(NX_NUMBER): - unit: NX_TEMPERATURE - exists: ['min', '0'] - (NXinstrument): - name(NX_CHAR): - exists: ['min', '1'] - - # CAUTION: keep URLs all on one line - doc: | - Name of instrument. Consistency with the controlled - vocabulary beamline naming in - https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html - and - https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html - is highly recommended. - \@short_name: - exists: optional - doc: | - Short name for instrument, perhaps the acronym. - time_zone(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time_zone offset from UTC. - (NXattenuator): - exists: ['min', '0'] - attenuator_transmission(NX_NUMBER): - unit: NX_UNITLESS - exists: ['min', '0'] - (NXdetector_group): - exists: recommended - doc: | - Optional logical grouping of detectors. - - Each detector is represented as an NXdetector - with its own detector data array. Each detector data array - may be further decomposed into array sections by use of - NXdetector_module groups. Detectors can be grouped logically - together using NXdetector_group. Groups can be further grouped - hierarchically in a single NXdetector_group (for example, if - there are multiple detectors at an endstation or multiple - endstations at a facility). Alternatively, multiple - NXdetector_groups can be provided. - - The groups are defined hierarchically, with names given - in the group_names field, unique identifying indices given - in the field group_index, and the level in the hierarchy - given in the group_parent field. For example if an x-ray - detector group, DET, consists of four detectors in a - rectangular array:: - - DTL DTR - DLL DLR - - We could have:: - - group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] - group_index: [1, 2, 3, 4, 5] - group_parent: [-1, 1, 1, 1, 1] - group_names(NX_CHAR): - doc: | - An array of the names of the detectors or the names of - hierarchical groupings of detectors. - group_index(NX_INT): - doc: | - An array of unique identifiers for detectors or groupings - of detectors. - - Each ID is a unique ID for the corresponding detector or group - named in the field group_names. The IDs are positive integers - starting with 1. - dimensions: - rank: 1 - dim: [[1, i]] - group_parent(NX_INT): - doc: | - An array of the hierarchical levels of the parents of detectors - or groupings of detectors. - - A top-level grouping has parent level -1. - dimensions: - rank: 1 - dim: [[1, groupIndex]] - (NXdetector): - doc: | - Normally the detector group will have the name ``detector``. - However, in the case of multiple detectors, each detector - needs a uniquely named NXdetector. - depends_on(NX_CHAR): - exists: ['min', '0'] - doc: | - NeXus path to the detector positioner axis that most directly - supports the detector. In the case of a single-module - detector, the detector axis chain may start here. - (NXtransformations): - exists: ['min', '0'] - doc: | - Location for axes (transformations) to do with the - detector. In the case of a single-module detector, the - axes of the detector axis chain may be stored here. - (NXcollection): - exists: ['min', '0'] - doc: | - Suggested container for detailed non-standard detector - information like corrections applied automatically or - performance settings. - data(NX_NUMBER): - exists: recommended - doc: | - For a dimension-2 detector, the rank of the data array will be 3. - For a dimension-3 detector, the rank of the data array will be 4. - This allows for the introduction of the frame number as the - first index. - dimensions: - rank: dataRank - dim: [[1, nP], [2, i], [3, j], [4, k]] - dim_parameters: - required: ['false'] - description: - exists: recommended - doc: | - name/manufacturer/model/etc. information. - time_per_channel: - unit: NX_TIME - exists: ['min', '0'] - doc: | - For a time-of-flight detector this is the scaling - factor to convert from the numeric value reported to - the flight time for a given measurement. - (NXdetector_module): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - Many detectors consist of multiple smaller modules that are - operated in sync and store their data in a common dataset. - To allow consistent parsing of the experimental geometry, - this application definiton requires all detectors to - define a detector module, even if there is only one. - - This group specifies the hyperslab of data in the data - array associated with the detector that contains the - data for this module. If the module is associated with - a full data array, rather than with a hyperslab within - a larger array, then a single module should be defined, - spanning the entire array. - - Note, the pixel size is given as values in the array - fast_pixel_direction and slow_pixel_direction. - data_origin(NX_INT): - doc: | - A dimension-2 or dimension-3 field which gives the indices - of the origin of the hyperslab of data for this module in the - main area detector image in the parent NXdetector module. - - The data_origin is 0-based. - - The frame number dimension (nP) is omitted. Thus the - data_origin field for a dimension-2 dataset with indices (nP, i, j) - will be an array with indices (i, j), and for a dimension-3 - dataset with indices (nP, i, j, k) will be an array with indices - (i, j, k). - - The :ref:`order ` of indices (i, j - or i, j, k) is slow to fast. - data_size(NX_INT): - doc: | - Two or three values for the size of the module in pixels in - each direction. Dimensionality and order of indices is the - same as for data_origin. - data_stride(NX_INT): - exists: ['min', '0'] - doc: | - Two or three values for the stride of the module in pixels in - each direction. By default the stride is [1,1] or [1,1,1], - and this is the most likely case. This optional field is - included for completeness. - module_offset(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0'] - doc: | - Offset of the module in regards to the origin of the detector in an - arbitrary direction. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - \@offset: - type: NX_NUMBER - \@depends_on: - fast_pixel_direction(NX_NUMBER): - unit: NX_LENGTH - doc: | - Values along the direction of :ref:`fastest varying ` - pixel direction. The direction itself is given through the vector - attribute. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - \@offset: - type: NX_NUMBER - \@depends_on: - slow_pixel_direction(NX_NUMBER): - unit: NX_LENGTH - doc: | - Values along the direction of :ref:`slowest varying ` - pixel direction. The direction itself is given through the vector - attribute. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - \@offset: - type: NX_NUMBER - \@depends_on: - distance(NX_FLOAT): - unit: NX_LENGTH - exists: recommended - doc: | - Distance from the sample to the beam center. - Normally this value is for guidance only, the proper - geometry can be found following the depends_on axis chain, - But in appropriate cases where the dectector distance - to the sample is observable independent of the axis - chain, that may take precedence over the axis chain - calculation. - distance_derived(NX_BOOLEAN): - exists: recommended - doc: | - Boolean to indicate if the distance is a derived, rather than - a primary observation. If distance_derived true or is not specified, - the distance is assumed to be derived from detector axis - specifications. - dead_time(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0'] - doc: | - Detector dead time. - count_time(NX_NUMBER): - unit: NX_TIME - exists: recommended - doc: | - Elapsed actual counting time. - beam_center_derived(NX_BOOLEAN): - exists: optional - doc: | - Boolean to indicate if the distance is a derived, rather than - a primary observation. If true or not provided, that value of - beam_center_derived is assumed to be true. - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - exists: recommended - doc: | - This is the x position where the direct beam would hit the - detector. This is a length and can be outside of the actual - detector. The length can be in physical units or pixels as - documented by the units attribute. Normally, this should - be derived from the axis chain, but the direct specification - may take precedence if it is not a derived quantity. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - exists: recommended - doc: | - This is the y position where the direct beam would hit the - detector. This is a length and can be outside of the actual - detector. The length can be in physical units or pixels as - documented by the units attribute. Normally, this should - be derived from the axis chain, but the direct specification - may take precedence if it is not a derived quantity. - angular_calibration_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - True when the angular calibration has been applied in the - electronics, false otherwise. - angular_calibration(NX_FLOAT): - exists: ['min', '0'] - doc: | - Angular calibration data. - dimensions: - rank: dataRank - dim: [[1, i], [2, j], [3, k]] - dim_parameters: - required: ['false'] - flatfield_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - True when the flat field correction has been applied in the - electronics, false otherwise. - flatfield(NX_NUMBER): - exists: ['min', '0'] - doc: | - Flat field correction data. If provided, it is recommended - that it be compressed. - dimensions: - rank: dataRank - dim: [[1, i], [2, j], [3, k]] - dim_parameters: - required: ['false'] - flatfield_error(NX_NUMBER): - exists: ['min', '0', 'max', '0'] - doc: | - *** Deprecated form. Use plural form *** - Errors of the flat field correction data. If provided, it is recommended - that it be compressed. - dimensions: - rank: dataRank - dim: [[1, i], [2, j], [3, k]] - dim_parameters: - required: ['false'] - flatfield_errors(NX_NUMBER): - exists: ['min', '0'] - doc: | - Errors of the flat field correction data. If provided, it is recommended - that it be compressed. - dimensions: - rank: dataRank - dim: [[1, i], [2, j], [3, k]] - dim_parameters: - required: ['false'] - pixel_mask_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - True when the pixel mask correction has been applied in the - electronics, false otherwise. - pixel_mask(NX_INT): - exists: recommended - doc: | - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices nP, i, j). - - Contains a bit field for each pixel to signal dead, - blind, high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under-responding - * bit 3: over-responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would not take pixels into account - when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper - two bytes would indicate special pixel properties that normally - would not be a sole reason to reject the intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - - If provided, it is recommended that it be compressed. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - countrate_correction_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - Counting detectors usually are not able to measure all incoming particles, - especially at higher count-rates. Count-rate correction is applied to - account for these errors. - - True when count-rate correction has been applied, false otherwise. - countrate_correction_lookup_table(NX_NUMBER): - doc: | - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - dimensions: - rank: 1 - dim: [[1, m]] - virtual_pixel_interpolation_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - True when virtual pixel interpolation has been applied, false otherwise. - - When virtual pixel interpolation is applied, values of some pixels may - contain interpolated values. For example, to account for space between - readout chips on a module, physical pixels on edges and corners between - chips may have larger sensor areas and counts may be distributed between - their logical pixels. - bit_depth_readout(NX_INT): - exists: recommended - doc: | - How many bits the electronics record per pixel. - detector_readout_time(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0'] - doc: | - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - frame_time(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0'] - doc: | - This is time for each frame. This is exposure_time + readout - time. - gain_setting(NX_CHAR): - exists: ['min', '0'] - doc: | - The gain setting of the detector. This influences - background. This is a detector-specific value meant - to document the gain setting of the detector during - data collection, for detectors with multiple - available gain settings. - - Examples of gain settings include: - - * ``standard`` - * ``fast`` - * ``auto`` - * ``high`` - * ``medium`` - * ``low`` - * ``mixed high to medium`` - * ``mixed medium to low`` - - Developers are encouraged to use one of these terms, or to submit - additional terms to add to the list. - saturation_value(NX_NUMBER): - exists: ['min', '0'] - doc: | - The value at which the detector goes into saturation. - Data above this value is known to be invalid. - - For example, given a saturation_value and an underload_value, - the valid pixels are those less than or equal to the - saturation_value and greater than or equal to the underload_value. - underload_value(NX_NUMBER): - exists: ['min', '0'] - doc: | - The lowest value at which pixels for this detector - would be reasonably be measured. - - For example, given a saturation_value and an underload_value, - the valid pixels are those less than or equal to the - saturation_value and greater than or equal to the underload_value. - sensor_material(NX_CHAR): - exists: ['min', '1'] - doc: | - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the name of this converter material. - sensor_thickness(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. This is the thickness of this - converter material. - threshold_energy(NX_FLOAT): - unit: NX_ENERGY - exists: ['min', '0'] - doc: | - Single photon counter detectors can be adjusted for a certain - energy range in which they work optimally. This is the energy - setting for this. If the detector supports multiple thresholds, - this is an array. - type: - exists: ['min', '0'] - doc: | - Description of type such as scintillator, - ccd, pixel, image - plate, CMOS, ... - (NXbeam): - exists: ['min', '1'] - \@flux: - exists: optional - doc: | - Which field contains the measured flux. One of ``flux``, - ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. - - Alternatively, the name being indicated could be a link - to a dataset in an NXmonitor group that records per shot beam data. - incident_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - exists: ['min', '1'] - doc: | - In the case of a monchromatic beam this is the scalar - wavelength. - - Several other use cases are permitted, depending on the - presence or absence of other incident_wavelength_X - fields. - - In the case of a polychromatic beam this is an array of - length **m** of wavelengths, with the relative weights - in ``incident_wavelength_weights``. - - In the case of a monochromatic beam that varies shot- - to-shot, this is an array of wavelengths, one for each - recorded shot. Here, ``incident_wavelength_weights`` and - incident_wavelength_spread are not set. - - In the case of a polychromatic beam that varies shot-to- - shot, this is an array of length **m** with the relative - weights in ``incident_wavelength_weights`` as a 2D array. - - In the case of a polychromatic beam that varies shot-to- - shot and where the channels also vary, this is a 2D array - of dimensions **nP** by **m** (slow to fast) with the - relative weights in ``incident_wavelength_weights`` as a 2D - array. - - Note, :ref:`variants ` are a good way - to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value wavelength value is - available along with the original spectrum from which it - was calibrated. - incident_wavelength_weight(NX_FLOAT): - exists: ['min', '0'] - deprecated: - use incident_wavelength_weights, see https://github.com/nexusformat/definitions/issues/837 - doc: | - In the case of a polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in incident_wavelength. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **nP** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in incident_wavelength. - incident_wavelength_weights(NX_FLOAT): - exists: ['min', '0'] - doc: | - In the case of a polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in ``incident_wavelength``. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **np** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in ``incident_wavelength``. - incident_wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - exists: ['min', '0'] - doc: | - The wavelength spread FWHM for the corresponding - wavelength(s) in incident_wavelength. - - In the case of shot-to-shot variation in the wavelength - spread, this is a 2D array of dimension **nP** by - **m** (slow to fast) of the spreads of the - corresponding wavelengths in incident_wavelength. - incident_wavelength_spectrum(NXdata): - exists: ['min', '0'] - flux(NX_FLOAT): - unit: NX_FLUX - exists: ['min', '0'] - doc: | - Flux density incident on beam plane area in photons - per second per unit area. - - In the case of a beam that varies in flux shot-to-shot, - this is an array of values, one for each recorded shot. - total_flux(NX_FLOAT): - unit: NX_FREQUENCY - exists: ['min', '0'] - doc: | - Flux incident on beam plane in photons per second. In other words - this is the :ref:`flux ` integrated - over area. - - Useful where spatial beam profiles are not known. - - In the case of a beam that varies in total flux shot-to-shot, - this is an array of values, one for each recorded shot. - flux_integrated(NX_FLOAT): - unit: NX_PER_AREA - exists: ['min', '0'] - doc: | - Flux density incident on beam plane area in photons - per unit area. In other words this is the :ref:`flux ` - integrated over time. - - Useful where temporal beam profiles of flux are not known. - - In the case of a beam that varies in flux shot-to-shot, - this is an array of values, one for each recorded shot. - total_flux_integrated(NX_FLOAT): - unit: NX_DIMENSIONLESS - exists: ['min', '0'] - doc: | - Flux incident on beam plane in photons. In other words this is the :ref:`flux ` - integrated over time and area. - - Useful where temporal beam profiles of flux are not known. - - In the case of a beam that varies in total flux shot-to-shot, - this is an array of values, one for each recorded shot. - incident_beam_size(NX_FLOAT): - unit: NX_LENGTH - exists: recommended - doc: | - Two-element array of FWHM (if Gaussian or Airy function) or - diameters (if top hat) or widths (if rectangular) of the beam - in the order x, y - dimensions: - rank: 1 - dim: [[1, 2]] - profile(NX_CHAR): - exists: recommended - doc: | - The beam profile, Gaussian, Airy function, top-hat or - rectangular. The profile is given in the plane of - incidence of the beam on the sample. - enumeration: [Gaussian, Airy, top-hat, rectangular] - incident_polarisation_stokes(NX_NUMBER): - exists: optional - deprecated: - use incident_polarization_stokes, see https://github.com/nexusformat/definitions/issues/708 - doc: | - Polarization vector on entering beamline - component using Stokes notation - dimensions: - rank: 2 - dim: [[1, nP], [2, 4]] - incident_polarization_stokes(NX_NUMBER): - exists: recommended - doc: | - Polarization vector on entering beamline - component using Stokes notation. See - incident_polarization_stokes in :ref:`NXbeam` - dimensions: - rank: 2 - dim: [[1, nP], [2, 4]] - (NXsource): - doc: | - The neutron or x-ray storage ring/facility. Note, the NXsource base class - has many more fields available, but at present we only require the name. - name: - exists: ['min', '1'] - doc: | - Name of source. Consistency with the naming in - https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html - controlled vocabulary is highly recommended. - \@short_name: - exists: optional - doc: | - short name for source, perhaps the acronym - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eedfcb0d8464a8b20e31394f68e8c6b271c72a38a05d429832c8a60420d8793f -# -# -# -# -# -# -# -# These symbols will be used below to coordinate datasets -# with the same shape. Most MX x-ray detectors will produce -# two-dimensional images. Some will produce three-dimensional -# images, using one of the indices to select a detector module. -# -# -# Rank of the ``data`` field -# -# -# Number of scan points -# -# -# Number of detector pixels in the slowest direction -# -# -# Number of detector pixels in the second slowest direction -# -# -# Number of detector pixels in the third slowest direction -# -# -# Number of channels in the incident beam spectrum, if known -# -# -# -# An array of the hierarchical levels of the parents of detector -# elements or groupings of detector elements. -# A top-level element or grouping has parent level -1. -# -# -# -# -# -# functional application definition for macromolecular crystallography -# -# -# -# -# -# Note, it is recommended that ``file_name`` and ``file_time`` are included -# as attributes at the root of a file that includes :ref:`NXmx`. See -# :ref:`NXroot`. -# -# -# -# -# Describes the version of the NXmx definition used to write this data. -# This must be a text (not numerical) representation. Such as:: -# -# @version="1.0" -# -# -# -# -# -# -# -# -# -# -# ISO 8601 time/date of the first data point collected in UTC, -# using the Z suffix to avoid confusion with local time. -# Note that the time zone of the beamline should be provided in -# NXentry/NXinstrument/time_zone. -# -# -# -# -# -# ISO 8601 time/date of the last data point collected in UTC, -# using the Z suffix to avoid confusion with local time. -# Note that the time zone of the beamline should be provided in -# NXentry/NXinstrument/time_zone. This field should only be -# filled when the value is accurately observed. If the data -# collection aborts or otherwise prevents accurate recording of -# the end_time, this field should be omitted. -# -# -# -# -# -# ISO 8601 time/date of the last data point collected in UTC, -# using the Z suffix to avoid confusion with local time. -# Note that the time zone of the beamline should be provided in -# NXentry/NXinstrument/time_zone. This field may be filled -# with a value estimated before an observed value is available. -# -# -# -# -# NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# For a dimension-2 detector, the rank of the data array will be 3. -# For a dimension-3 detector, the rank of the data array will be 4. -# This allows for the introduction of the frame number as the -# first index. -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# This is a requirement to describe for any scan experiment. -# -# The axis on which the sample position depends may be stored -# anywhere, but is normally stored in the NXtransformations -# group within the NXsample group. -# -# If there is no goniometer, e.g. with a jet, depends_on -# should be set to "." -# -# -# -# -# -# This is the recommended location for sample goniometer -# and other related axes. -# -# This is a requirement to describe for any scan experiment. -# The reason it is optional is mainly to accommodate XFEL -# single shot exposures. -# -# Use of the depends_on field and the NXtransformations group is -# strongly recommended. As noted above this should be an absolute -# requirement to have for any scan experiment. -# -# The reason it is optional is mainly to accommodate XFEL -# single shot exposures. -# -# -# -# -# -# -# -# -# -# -# -# -# Name of instrument. Consistency with the controlled -# vocabulary beamline naming in -# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html -# and -# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html -# is highly recommended. -# -# -# Short name for instrument, perhaps the acronym. -# -# -# -# -# -# ISO 8601 time_zone offset from UTC. -# -# -# -# -# -# -# -# -# -# Optional logical grouping of detectors. -# -# Each detector is represented as an NXdetector -# with its own detector data array. Each detector data array -# may be further decomposed into array sections by use of -# NXdetector_module groups. Detectors can be grouped logically -# together using NXdetector_group. Groups can be further grouped -# hierarchically in a single NXdetector_group (for example, if -# there are multiple detectors at an endstation or multiple -# endstations at a facility). Alternatively, multiple -# NXdetector_groups can be provided. -# -# The groups are defined hierarchically, with names given -# in the group_names field, unique identifying indices given -# in the field group_index, and the level in the hierarchy -# given in the group_parent field. For example if an x-ray -# detector group, DET, consists of four detectors in a -# rectangular array:: -# -# DTL DTR -# DLL DLR -# -# We could have:: -# -# group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] -# group_index: [1, 2, 3, 4, 5] -# group_parent: [-1, 1, 1, 1, 1] -# -# -# -# -# -# An array of the names of the detectors or the names of -# hierarchical groupings of detectors. -# -# -# -# -# -# An array of unique identifiers for detectors or groupings -# of detectors. -# -# Each ID is a unique ID for the corresponding detector or group -# named in the field group_names. The IDs are positive integers -# starting with 1. -# -# -# -# -# -# -# An array of the hierarchical levels of the parents of detectors -# or groupings of detectors. -# -# A top-level grouping has parent level -1. -# -# -# -# -# -# -# Normally the detector group will have the name ``detector``. -# However, in the case of multiple detectors, each detector -# needs a uniquely named NXdetector. -# -# -# -# -# NeXus path to the detector positioner axis that most directly -# supports the detector. In the case of a single-module -# detector, the detector axis chain may start here. -# -# -# -# -# -# Location for axes (transformations) to do with the -# detector. In the case of a single-module detector, the -# axes of the detector axis chain may be stored here. -# -# -# -# -# -# Suggested container for detailed non-standard detector -# information like corrections applied automatically or -# performance settings. -# -# -# -# -# -# For a dimension-2 detector, the rank of the data array will be 3. -# For a dimension-3 detector, the rank of the data array will be 4. -# This allows for the introduction of the frame number as the -# first index. -# -# -# -# -# -# -# -# -# -# -# -# name/manufacturer/model/etc. information. -# -# -# -# -# -# For a time-of-flight detector this is the scaling -# factor to convert from the numeric value reported to -# the flight time for a given measurement. -# -# -# -# -# -# Many detectors consist of multiple smaller modules that are -# operated in sync and store their data in a common dataset. -# To allow consistent parsing of the experimental geometry, -# this application definiton requires all detectors to -# define a detector module, even if there is only one. -# -# This group specifies the hyperslab of data in the data -# array associated with the detector that contains the -# data for this module. If the module is associated with -# a full data array, rather than with a hyperslab within -# a larger array, then a single module should be defined, -# spanning the entire array. -# -# Note, the pixel size is given as values in the array -# fast_pixel_direction and slow_pixel_direction. -# -# -# -# A dimension-2 or dimension-3 field which gives the indices -# of the origin of the hyperslab of data for this module in the -# main area detector image in the parent NXdetector module. -# -# The data_origin is 0-based. -# -# The frame number dimension (nP) is omitted. Thus the -# data_origin field for a dimension-2 dataset with indices (nP, i, j) -# will be an array with indices (i, j), and for a dimension-3 -# dataset with indices (nP, i, j, k) will be an array with indices -# (i, j, k). -# -# The :ref:`order <Design-ArrayStorageOrder>` of indices (i, j -# or i, j, k) is slow to fast. -# -# -# -# -# Two or three values for the size of the module in pixels in -# each direction. Dimensionality and order of indices is the -# same as for data_origin. -# -# -# -# -# Two or three values for the stride of the module in pixels in -# each direction. By default the stride is [1,1] or [1,1,1], -# and this is the most likely case. This optional field is -# included for completeness. -# -# -# -# -# -# Offset of the module in regards to the origin of the detector in an -# arbitrary direction. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Values along the direction of :ref:`fastest varying <Design-ArrayStorageOrder>` -# pixel direction. The direction itself is given through the vector -# attribute. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Values along the direction of :ref:`slowest varying <Design-ArrayStorageOrder>` -# pixel direction. The direction itself is given through the vector -# attribute. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance from the sample to the beam center. -# Normally this value is for guidance only, the proper -# geometry can be found following the depends_on axis chain, -# But in appropriate cases where the dectector distance -# to the sample is observable independent of the axis -# chain, that may take precedence over the axis chain -# calculation. -# -# -# -# -# -# Boolean to indicate if the distance is a derived, rather than -# a primary observation. If distance_derived true or is not specified, -# the distance is assumed to be derived from detector axis -# specifications. -# -# -# -# -# -# Detector dead time. -# -# -# -# -# -# Elapsed actual counting time. -# -# -# -# -# -# Boolean to indicate if the distance is a derived, rather than -# a primary observation. If true or not provided, that value of -# beam_center_derived is assumed to be true. -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the -# detector. This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels as -# documented by the units attribute. Normally, this should -# be derived from the axis chain, but the direct specification -# may take precedence if it is not a derived quantity. -# -# -# -# -# -# This is the y position where the direct beam would hit the -# detector. This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels as -# documented by the units attribute. Normally, this should -# be derived from the axis chain, but the direct specification -# may take precedence if it is not a derived quantity. -# -# -# -# -# -# True when the angular calibration has been applied in the -# electronics, false otherwise. -# -# -# -# -# Angular calibration data. -# -# -# -# -# -# -# -# -# -# True when the flat field correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# -# Flat field correction data. If provided, it is recommended -# that it be compressed. -# -# -# -# -# -# -# -# -# -# -# -# *** Deprecated form. Use plural form *** -# Errors of the flat field correction data. If provided, it is recommended -# that it be compressed. -# -# -# -# -# -# -# -# -# -# -# Errors of the flat field correction data. If provided, it is recommended -# that it be compressed. -# -# -# -# -# -# -# -# -# -# -# True when the pixel mask correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# -# The 32-bit pixel mask for the detector. Can be either one mask -# for the whole dataset (i.e. an array with indices i, j) or -# each frame can have its own mask (in which case it would be -# an array with indices nP, i, j). -# -# Contains a bit field for each pixel to signal dead, -# blind, high or otherwise unwanted or undesirable pixels. -# They have the following meaning: -# -# * bit 0: gap (pixel with no sensor) -# * bit 1: dead -# * bit 2: under-responding -# * bit 3: over-responding -# * bit 4: noisy -# * bit 5: -undefined- -# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) -# * bit 7: -undefined- -# * bit 8: user defined mask (e.g. around beamstop) -# * bits 9-30: -undefined- -# * bit 31: virtual pixel (corner pixel with interpolated value) -# -# Normal data analysis software would not take pixels into account -# when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper -# two bytes would indicate special pixel properties that normally -# would not be a sole reason to reject the intensity value (unless -# lower bits are set. -# -# If the full bit depths is not required, providing a -# mask with fewer bits is permissible. -# -# If needed, additional pixel masks can be specified by -# including additional entries named pixel_mask_N, where -# N is an integer. For example, a general bad pixel mask -# could be specified in pixel_mask that indicates noisy -# and dead pixels, and an additional pixel mask from -# experiment-specific shadowing could be specified in -# pixel_mask_2. The cumulative mask is the bitwise OR -# of pixel_mask and any pixel_mask_N entries. -# -# If provided, it is recommended that it be compressed. -# -# -# -# -# -# -# -# -# Counting detectors usually are not able to measure all incoming particles, -# especially at higher count-rates. Count-rate correction is applied to -# account for these errors. -# -# True when count-rate correction has been applied, false otherwise. -# -# -# -# -# The countrate_correction_lookup_table defines the LUT used for count-rate -# correction. It maps a measured count :math:`c` to its corrected value -# :math:`countrate\_correction\_lookup\_table[c]`. -# -# :math:`m` denotes the length of the table. -# -# -# -# -# -# -# -# True when virtual pixel interpolation has been applied, false otherwise. -# -# When virtual pixel interpolation is applied, values of some pixels may -# contain interpolated values. For example, to account for space between -# readout chips on a module, physical pixels on edges and corners between -# chips may have larger sensor areas and counts may be distributed between -# their logical pixels. -# -# -# -# -# -# How many bits the electronics record per pixel. -# -# -# -# -# -# Time it takes to read the detector (typically milliseconds). -# This is important to know for time resolved experiments. -# -# -# -# -# -# This is time for each frame. This is exposure_time + readout -# time. -# -# -# -# -# -# The gain setting of the detector. This influences -# background. This is a detector-specific value meant -# to document the gain setting of the detector during -# data collection, for detectors with multiple -# available gain settings. -# -# Examples of gain settings include: -# -# * ``standard`` -# * ``fast`` -# * ``auto`` -# * ``high`` -# * ``medium`` -# * ``low`` -# * ``mixed high to medium`` -# * ``mixed medium to low`` -# -# Developers are encouraged to use one of these terms, or to submit -# additional terms to add to the list. -# -# -# -# -# -# The value at which the detector goes into saturation. -# Data above this value is known to be invalid. -# -# For example, given a saturation_value and an underload_value, -# the valid pixels are those less than or equal to the -# saturation_value and greater than or equal to the underload_value. -# -# -# -# -# -# The lowest value at which pixels for this detector -# would be reasonably be measured. -# -# For example, given a saturation_value and an underload_value, -# the valid pixels are those less than or equal to the -# saturation_value and greater than or equal to the underload_value. -# -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the name of this converter material. -# -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. This is the thickness of this -# converter material. -# -# -# -# -# -# Single photon counter detectors can be adjusted for a certain -# energy range in which they work optimally. This is the energy -# setting for this. If the detector supports multiple thresholds, -# this is an array. -# -# -# -# -# -# Description of type such as scintillator, -# ccd, pixel, image -# plate, CMOS, ... -# -# -# -# -# -# -# Which field contains the measured flux. One of ``flux``, -# ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. -# -# Alternatively, the name being indicated could be a link -# to a dataset in an NXmonitor group that records per shot beam data. -# -# -# -# -# In the case of a monchromatic beam this is the scalar -# wavelength. -# -# Several other use cases are permitted, depending on the -# presence or absence of other incident_wavelength_X -# fields. -# -# In the case of a polychromatic beam this is an array of -# length **m** of wavelengths, with the relative weights -# in ``incident_wavelength_weights``. -# -# In the case of a monochromatic beam that varies shot- -# to-shot, this is an array of wavelengths, one for each -# recorded shot. Here, ``incident_wavelength_weights`` and -# incident_wavelength_spread are not set. -# -# In the case of a polychromatic beam that varies shot-to- -# shot, this is an array of length **m** with the relative -# weights in ``incident_wavelength_weights`` as a 2D array. -# -# In the case of a polychromatic beam that varies shot-to- -# shot and where the channels also vary, this is a 2D array -# of dimensions **nP** by **m** (slow to fast) with the -# relative weights in ``incident_wavelength_weights`` as a 2D -# array. -# -# Note, :ref:`variants <Design-Variants>` are a good way -# to represent several of these use cases in a single dataset, -# e.g. if a calibrated, single-value wavelength value is -# available along with the original spectrum from which it -# was calibrated. -# -# -# -# -# -# In the case of a polychromatic beam this is an array of -# length **m** of the relative weights of the corresponding -# wavelengths in incident_wavelength. -# -# In the case of a polychromatic beam that varies shot-to- -# shot, this is a 2D array of dimensions **nP** by **m** -# (slow to fast) of the relative weights of the -# corresponding wavelengths in incident_wavelength. -# -# -# -# -# In the case of a polychromatic beam this is an array of -# length **m** of the relative weights of the corresponding -# wavelengths in ``incident_wavelength``. -# -# In the case of a polychromatic beam that varies shot-to- -# shot, this is a 2D array of dimensions **np** by **m** -# (slow to fast) of the relative weights of the -# corresponding wavelengths in ``incident_wavelength``. -# -# -# -# -# -# The wavelength spread FWHM for the corresponding -# wavelength(s) in incident_wavelength. -# -# In the case of shot-to-shot variation in the wavelength -# spread, this is a 2D array of dimension **nP** by -# **m** (slow to fast) of the spreads of the -# corresponding wavelengths in incident_wavelength. -# -# -# -# -# -# -# -# Flux density incident on beam plane area in photons -# per second per unit area. -# -# In the case of a beam that varies in flux shot-to-shot, -# this is an array of values, one for each recorded shot. -# -# -# -# -# -# Flux incident on beam plane in photons per second. In other words -# this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` integrated -# over area. -# -# Useful where spatial beam profiles are not known. -# -# In the case of a beam that varies in total flux shot-to-shot, -# this is an array of values, one for each recorded shot. -# -# -# -# -# -# Flux density incident on beam plane area in photons -# per unit area. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` -# integrated over time. -# -# Useful where temporal beam profiles of flux are not known. -# -# In the case of a beam that varies in flux shot-to-shot, -# this is an array of values, one for each recorded shot. -# -# -# -# -# -# Flux incident on beam plane in photons. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` -# integrated over time and area. -# -# Useful where temporal beam profiles of flux are not known. -# -# In the case of a beam that varies in total flux shot-to-shot, -# this is an array of values, one for each recorded shot. -# -# -# -# -# -# Two-element array of FWHM (if Gaussian or Airy function) or -# diameters (if top hat) or widths (if rectangular) of the beam -# in the order x, y -# -# -# -# -# -# -# -# -# The beam profile, Gaussian, Airy function, top-hat or -# rectangular. The profile is given in the plane of -# incidence of the beam on the sample. -# -# -# -# -# -# -# -# -# -# -# Polarization vector on entering beamline -# component using Stokes notation -# -# -# -# -# -# -# -# -# Polarization vector on entering beamline -# component using Stokes notation. See -# incident_polarization_stokes in :ref:`NXbeam` -# -# -# -# -# -# -# -# -# -# -# The neutron or x-ray storage ring/facility. Note, the NXsource base class -# has many more fields available, but at present we only require the name. -# -# -# -# Name of source. Consistency with the naming in -# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html -# controlled vocabulary is highly recommended. -# -# -# short name for source, perhaps the acronym -# -# -# -# -# diff --git a/applications/nyaml/NXrefscan.yaml b/applications/nyaml/NXrefscan.yaml deleted file mode 100644 index 545d01fd6e..0000000000 --- a/applications/nyaml/NXrefscan.yaml +++ /dev/null @@ -1,197 +0,0 @@ -category: application -doc: | - This is an application definition for a monochromatic scanning reflectometer. - - It does not have the information to calculate the resolution - since it does not have any apertures. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXrefscan(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXrefscan] - (NXinstrument)instrument: - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXmonochromator)monochromator: - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - (NXdetector): - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample)sample: - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_FLOAT): - unit: NX_ANY - doc: | - Monitor counts for each step - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2292093a2a73147dd621497414bfff4f52e5a2103a0c4b1e5a119e15e005b78f -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# This is an application definition for a monochromatic scanning reflectometer. -# -# It does not have the information to calculate the resolution -# since it does not have any apertures. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Monitor counts for each step -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXreftof.yaml b/applications/nyaml/NXreftof.yaml deleted file mode 100644 index 760c7023fe..0000000000 --- a/applications/nyaml/NXreftof.yaml +++ /dev/null @@ -1,214 +0,0 @@ -category: application -doc: | - This is an application definition for raw data from a TOF reflectometer. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - xSize: | - xSize description - ySize: | - ySize description - nTOF: | - nTOF description -type: group -NXreftof(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXreftof] - (NXinstrument)instrument: - name(NX_CHAR): - (NXdisk_chopper)chopper: - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance between chopper and sample - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, xSize], [2, ySize], [3, nTOF]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 3 - doc: | - Array of time values for each bin in a time-of-flight - measurement - dimensions: - rank: 1 - dim: [[1, nTOF]] - distance(NX_FLOAT): - unit: NX_LENGTH - polar_angle(NX_FLOAT): - unit: NX_ANGLE - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - (NXsample)sample: - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - unit: NX_ANY - doc: | - preset value for time or monitor - integral(NX_INT): - doc: | - Total integral monitor counts - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - doc: | - Time channels - data(NX_INT): - signal: 1 - doc: | - Monitor counts in each time channel - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 11c65854a466d2dce2e11e31861b9d33736ed082b3571645b0c3f1feebd16bbd -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# xSize description -# -# -# ySize description -# -# -# nTOF description -# -# -# This is an application definition for raw data from a TOF reflectometer. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# Distance between chopper and sample -# -# -# -# -# -# -# -# -# -# -# -# -# Array of time values for each bin in a time-of-flight -# measurement -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Total integral monitor counts -# -# -# Time channels -# -# -# Monitor counts in each time channel -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXsas.yaml b/applications/nyaml/NXsas.yaml deleted file mode 100644 index 2e160f0bbc..0000000000 --- a/applications/nyaml/NXsas.yaml +++ /dev/null @@ -1,369 +0,0 @@ -category: application -doc: | - Raw, monochromatic 2-D SAS data with an area detector. - - This is an application definition for raw data (not processed or reduced data) - from a 2-D small angle scattering instrument collected with a monochromatic - beam and an area detector. It is meant to be suitable both for neutron SANS - and X-ray SAXS data. - - It covers all raw data from any monochromatic SAS techniques that - use an area detector: SAS, WSAS, grazing incidence, GISAS - - It covers all raw data from any SAS techniques that use an area detector and - a monochromatic beam. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate fields with the same shape. - nXPixel: | - Number of pixels in x direction. - nYPixel: | - Number of pixels in y direction. -type: group -NXsas(NXobject): - (NXentry): - title: - exists: ['min', '0'] - start_time(NX_DATE_TIME): - exists: ['min', '0'] - end_time(NX_DATE_TIME): - exists: ['min', '0'] - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - enumeration: [NXsas] - (NXinstrument): - (NXsource): - type: - doc: | - Type of radiation source. - name: - exists: ['min', '0'] - doc: | - Name of the radiation source. - probe: - doc: | - Name of radiation probe, necessary to compute the sample contrast. - enumeration: [neutron, x-ray] - (NXmonochromator): - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The wavelength (:math:`\lambda`) of the radiation. - wavelength_spread(NX_FLOAT): - exists: ['min', '0'] - doc: | - delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): - Important for resolution calculations. - (NXcollimator): - exists: ['min', '0'] - (NXgeometry): - (NXshape): - shape(NX_CHAR): - enumeration: [nxcylinder, nxbox] - size(NX_FLOAT): - unit: NX_LENGTH - doc: | - The collimation length. - (NXdetector): - data(NX_NUMBER): - doc: | - This is area detector data, number of x-pixel versus - number of y-pixels. - - Since the beam center is to be determined as a step of data - reduction, it is not necessary to document or assume the position of - the beam center in acquired data. - - It is necessary to define which are the x and y directions, to coordinate - with the pixel size and compute Q. - dimensions: - rank: 2 - dim: [[1, nXPixel], [2, nYPixel]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - The distance between detector and sample. - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of a pixel in x-direction. - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of a pixel in y-direction. - polar_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - aequatorial_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0'] - doc: | - This is the x position where the direct beam would hit the detector. - This is a length, not a pixel position, and can be outside of the - actual detector. - - It is expected that data reduction will determine beam center from - the raw data, thus it is not required here. The instrument can - provide an initial or nominal value to advise data reduction. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0'] - doc: | - This is the y position where the direct beam would hit the detector. - This is a length, not a pixel position, and can be outside of the - actual detector. - - It is expected that data reduction will determine beam center from - the raw data, thus it is not required here. The instrument can - provide an initial or nominal value to advise data reduction. - name(NX_CHAR): - doc: | - Name of the instrument actually used to perform the experiment. - (NXsample): - exists: ['min', '0'] - name: - doc: | - Descriptive name of sample. - aequatorial_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - (NXmonitor): - exists: ['min', '0'] - mode: - doc: | - Count to a preset value based on either clock time - (timer) or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - Preset value for time or monitor. - integral(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts. - (NXdata): - \@signal: - exists: optional - doc: | - Name the *plottable* field. The link here defines this name as - ``data``. - enumeration: [data] - data(link): - target: /NXentry/NXinstrument/NXdetector/data - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2aa6302899fe37644b84e8ae5fba65adf3e17563e6bf42afe1beee8007b93ff5 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate fields with the same shape. -# -# -# Number of pixels in x direction. -# -# -# Number of pixels in y direction. -# -# -# -# Raw, monochromatic 2-D SAS data with an area detector. -# -# This is an application definition for raw data (not processed or reduced data) -# from a 2-D small angle scattering instrument collected with a monochromatic -# beam and an area detector. It is meant to be suitable both for neutron SANS -# and X-ray SAXS data. -# -# It covers all raw data from any monochromatic SAS techniques that -# use an area detector: SAS, WSAS, grazing incidence, GISAS -# -# It covers all raw data from any SAS techniques that use an area detector and -# a monochromatic beam. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# Type of radiation source. -# -# -# Name of the radiation source. -# -# -# -# Name of radiation probe, necessary to compute the sample contrast. -# -# -# -# -# -# -# -# -# -# The wavelength (:math:`\lambda`) of the radiation. -# -# -# -# delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): -# Important for resolution calculations. -# -# -# -# -# -# -# -# -# -# -# -# -# -# The collimation length. -# -# -# -# -# -# -# -# This is area detector data, number of x-pixel versus -# number of y-pixels. -# -# Since the beam center is to be determined as a step of data -# reduction, it is not necessary to document or assume the position of -# the beam center in acquired data. -# -# It is necessary to define which are the x and y directions, to coordinate -# with the pixel size and compute Q. -# -# -# -# -# -# -# -# The distance between detector and sample. -# -# -# Physical size of a pixel in x-direction. -# -# -# Physical size of a pixel in y-direction. -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the detector. -# This is a length, not a pixel position, and can be outside of the -# actual detector. -# -# It is expected that data reduction will determine beam center from -# the raw data, thus it is not required here. The instrument can -# provide an initial or nominal value to advise data reduction. -# -# -# -# -# This is the y position where the direct beam would hit the detector. -# This is a length, not a pixel position, and can be outside of the -# actual detector. -# -# It is expected that data reduction will determine beam center from -# the raw data, thus it is not required here. The instrument can -# provide an initial or nominal value to advise data reduction. -# -# -# -# -# Name of the instrument actually used to perform the experiment. -# -# -# -# -# Descriptive name of sample. -# -# -# -# -# -# -# Count to a preset value based on either clock time -# (timer) or received monitor counts (monitor). -# -# -# -# -# -# -# -# Preset value for time or monitor. -# -# -# Total integral monitor counts. -# -# -# -# -# -# Name the *plottable* field. The link here defines this name as -# ``data``. -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXsastof.yaml b/applications/nyaml/NXsastof.yaml deleted file mode 100644 index 4a3530a29a..0000000000 --- a/applications/nyaml/NXsastof.yaml +++ /dev/null @@ -1,312 +0,0 @@ -category: application -doc: | - raw, 2-D SAS data with an area detector with a time-of-flight source - - It covers all raw data from any SAS techniques - that use an area detector - at a time-of-flight source. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nXPixel: | - nXPixel description - nYPixel: | - nYPixel description - nTOF: | - nTOF description -type: group -NXsastof(NXobject): - (NXentry): - \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXsastof] - (NXinstrument)instrument: - (NXsource)source: - type: - doc: | - type of radiation source - name: - doc: | - Name of the radiation source - probe: - enumeration: [neutron, x-ray] - (NXcollimator)collimator: - (NXgeometry)geometry: - (NXshape)shape: - shape(NX_CHAR): - enumeration: [nxcylinder, nxbox] - size(NX_FLOAT): - unit: NX_LENGTH - doc: | - The collimation length - (NXdetector)detector: - data(NX_NUMBER): - signal: 1 - doc: | - This is area detector data, of number of x-pixel versus - number of y-pixels. Since the beam center is to be - determined as a step of data reduction, it is not necessary - to document or assume the position of the beam center in - acquired data. - dimensions: - rank: 3 - dim: [[1, nXPixel], [2, nYPixel], [3, nTOF]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, nTOF]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - The distance between detector and sample - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of a pixel in x-direction - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of a pixel in y direction - polar_angle(NX_FLOAT): - unit: NX_ANGLE - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - aequatorial_angle(NX_FLOAT): - unit: NX_ANGLE - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the x position where the direct beam would hit the detector. This is a - length, not a pixel position, and can be outside of the actual detector. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the y position where the direct beam would hit the detector. This is a - length, not a pixel position, and can be outside of the actual detector. - name(NX_CHAR): - doc: | - Name of the instrument actually used to perform the experiment - (NXsample)sample: - name: - doc: | - Descriptive name of sample - aequatorial_angle(NX_FLOAT): - unit: NX_ANGLE - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_INT): - primary: 1 - signal: 1 - dimensions: - rank: 1 - dim: [[1, nTOF]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, nTOF]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 18b43c8a5ad4926ae6e06b953df9d44c87db9e7f47f4f7e99e072f3950620660 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# nXPixel description -# -# -# nYPixel description -# -# -# nTOF description -# -# -# -# raw, 2-D SAS data with an area detector with a time-of-flight source -# -# It covers all raw data from any SAS techniques -# that use an area detector -# at a time-of-flight source. -# -# -# -# NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# type of radiation source -# -# -# Name of the radiation source -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The collimation length -# -# -# -# -# -# -# -# This is area detector data, of number of x-pixel versus -# number of y-pixels. Since the beam center is to be -# determined as a step of data reduction, it is not necessary -# to document or assume the position of the beam center in -# acquired data. -# -# -# -# -# -# -# -# -# -# -# -# -# The distance between detector and sample -# -# -# Physical size of a pixel in x-direction -# -# -# Size of a pixel in y direction -# -# -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the detector. This is a -# length, not a pixel position, and can be outside of the actual detector. -# -# -# -# -# This is the y position where the direct beam would hit the detector. This is a -# length, not a pixel position, and can be outside of the actual detector. -# -# -# -# -# Name of the instrument actually used to perform the experiment -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) or received monitor counts (monitor). -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXscan.yaml b/applications/nyaml/NXscan.yaml deleted file mode 100644 index 38f6e0107c..0000000000 --- a/applications/nyaml/NXscan.yaml +++ /dev/null @@ -1,181 +0,0 @@ -category: application -doc: | - Application definition for a generic scan instrument. - - This definition is more an - example then a stringent definition as the content of a given NeXus scan file needs to - differ for different types of scans. This example definition shows a scan like done - on a rotation camera: the sample is rotated and a detector image, the rotation angle - and a monitor value is stored at each step in the scan. In the following, the symbol - ``NP`` is used to represent the number of scan points. These are the rules for - storing scan data in NeXus files which are implemented in this example: - - * Each value varied throughout a scan is stored as an array of - length ``NP`` at its respective location within the NeXus hierarchy. - * For area detectors, ``NP`` is the first dimension, - example for a detector of 256x256: ``data[NP,256,256]`` - * The NXdata group contains links to all variables varied in the scan and the data. - This to give an equivalent to the more familiar classical tabular representation of scans. - - These rules exist for a reason: HDF allows the first dimension of a data set to be - unlimited. This means the data can be appended too. Thus a NeXus file built according - to the rules given above can be used in the following way: - - * At the start of a scan, write all the static information. - * At each scan point, append new data from varied variables - and the detector to the file. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points - xDim: | - xDim description - yDim: | - yDim description -type: group -NXscan(NXobject): - (NXentry): - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition(NX_CHAR): - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXscan] - (NXinstrument): - (NXdetector): - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nP], [2, xDim], [3, yDim]] - (NXsample): - rotation_angle(NX_FLOAT): - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - (NXmonitor): - data(NX_INT): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata): - data(link): - target: /NXentry/NXinstrument/NXdetector/data - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0a6ad9072ad7a42beaa653d148ef9e0187624de64ae1a25be57d67eebe991360 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# xDim description -# -# -# yDim description -# -# -# -# Application definition for a generic scan instrument. -# -# This definition is more an -# example then a stringent definition as the content of a given NeXus scan file needs to -# differ for different types of scans. This example definition shows a scan like done -# on a rotation camera: the sample is rotated and a detector image, the rotation angle -# and a monitor value is stored at each step in the scan. In the following, the symbol -# ``NP`` is used to represent the number of scan points. These are the rules for -# storing scan data in NeXus files which are implemented in this example: -# -# * Each value varied throughout a scan is stored as an array of -# length ``NP`` at its respective location within the NeXus hierarchy. -# * For area detectors, ``NP`` is the first dimension, -# example for a detector of 256x256: ``data[NP,256,256]`` -# * The NXdata group contains links to all variables varied in the scan and the data. -# This to give an equivalent to the more familiar classical tabular representation of scans. -# -# These rules exist for a reason: HDF allows the first dimension of a data set to be -# unlimited. This means the data can be appended too. Thus a NeXus file built according -# to the rules given above can be used in the following way: -# -# * At the start of a scan, write all the static information. -# * At each scan point, append new data from varied variables -# and the detector to the file. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXspe.yaml b/applications/nyaml/NXspe.yaml deleted file mode 100644 index 7dfb5be0a6..0000000000 --- a/applications/nyaml/NXspe.yaml +++ /dev/null @@ -1,128 +0,0 @@ -category: application -doc: | - NXSPE Inelastic Format. Application definition for NXSPE file format. -type: group -NXspe(NXobject): - (NXentry): - program_name: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - \@version: - enumeration: [NXspe] - (NXcollection)NXSPE_info: - fixed_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - The fixed energy used for this file. - ki_over_kf_scaling(NX_BOOLEAN): - doc: | - Indicates whether ki/kf scaling has been applied or not. - psi(NX_FLOAT): - unit: NX_ANGLE - doc: | - Orientation angle as expected in DCS-MSlice - (NXdata)data: - azimuthal(NX_FLOAT): - unit: NX_ANGLE - azimuthal_width(NX_FLOAT): - unit: NX_ANGLE - polar(NX_FLOAT): - unit: NX_ANGLE - polar_width(NX_FLOAT): - unit: NX_ANGLE - distance(NX_FLOAT): - unit: NX_LENGTH - data(NX_NUMBER): - error(NX_NUMBER): - energy(NX_FLOAT): - unit: NX_ENERGY - (NXinstrument): - name(NX_CHAR): - (NXfermi_chopper): - energy(NX_NUMBER): - unit: NX_ENERGY - (NXsample): - rotation_angle(NX_NUMBER): - unit: NX_ANGLE - seblock(NX_CHAR): - temperature(NX_NUMBER): - unit: NX_TEMPERATURE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eec08fb3a92ba08c09d8ecb18e13c7703abf71c6e532786d2685d1c7979e52b3 -# -# -# -# -# NXSPE Inelastic Format. Application definition for NXSPE file format. -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# The fixed energy used for this file. -# -# -# Indicates whether ki/kf scaling has been applied or not. -# -# -# Orientation angle as expected in DCS-MSlice -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXsqom.yaml b/applications/nyaml/NXsqom.yaml deleted file mode 100644 index c29c5e622c..0000000000 --- a/applications/nyaml/NXsqom.yaml +++ /dev/null @@ -1,211 +0,0 @@ -category: application -doc: | - This is the application definition for S(Q,OM) processed data. - - As this kind of data is in - general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their - intensity, table like. It is the task of a possible visualisation program to regrid this data in - a sensible way. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXsqom(NXobject): - (NXentry): - \@entry: - title: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXsqom] - (NXinstrument)instrument: - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - name(NX_CHAR): - doc: | - Name of the instrument from which this data was reduced. - (NXsample): - name: - doc: | - Descriptive name of sample - (NXprocess)reduction: - program(NX_CHAR): - version(NX_CHAR): - (NXparameters)input: - filenames(NX_CHAR): - doc: | - Raw data files used to generate this I(Q) - doc: | - Input parameters for the reduction program used - (NXparameters)output: - doc: | - Eventual output parameters from the data reduction program used - (NXdata): - data(NX_INT): - signal: 1 - doc: | - This is the intensity for each point in QE - dimensions: - rank: 1 - dim: [[1, nP]] - qx(NX_NUMBER): - axis: 1 - unit: NX_WAVENUMBER - doc: | - Positions for the first dimension of Q - dimensions: - rank: 1 - dim: [[1, nP]] - qy(NX_NUMBER): - axis: 1 - unit: NX_WAVENUMBER - doc: | - Positions for the the second dimension of Q - dimensions: - rank: 1 - dim: [[1, nP]] - qz(NX_NUMBER): - axis: 1 - unit: NX_WAVENUMBER - doc: | - Positions for the the third dimension of Q - dimensions: - rank: 1 - dim: [[1, nP]] - en(NX_FLOAT): - axis: 1 - unit: NX_ENERGY - doc: | - Values for the energy transfer for each point - dimensions: - rank: 1 - dim: [[1, nP]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c4bc88346556a87d052d23ac72e3681fbbc83804dd30c5cf7656e54595f43e97 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# This is the application definition for S(Q,OM) processed data. -# -# As this kind of data is in -# general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their -# intensity, table like. It is the task of a possible visualisation program to regrid this data in -# a sensible way. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name of the instrument from which this data was reduced. -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# Raw data files used to generate this I(Q) -# -# Input parameters for the reduction program used -# -# -# Eventual output parameters from the data reduction program used -# -# -# -# -# This is the intensity for each point in QE -# -# -# -# -# -# Positions for the first dimension of Q -# -# -# -# -# -# Positions for the the second dimension of Q -# -# -# -# -# -# Positions for the the third dimension of Q -# -# -# -# -# -# Values for the energy transfer for each point -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXstxm.yaml b/applications/nyaml/NXstxm.yaml deleted file mode 100644 index a2a6c1fc8b..0000000000 --- a/applications/nyaml/NXstxm.yaml +++ /dev/null @@ -1,366 +0,0 @@ -category: application -doc: | - Application definition for a STXM instrument. - - The interferometer - position measurements, monochromator photon energy values and - detector measurements are all treated as NXdetectors and stored - within the NXinstrument group as lists of values stored in - chronological order. The NXdata group then holds another version - of the data in a regular 3D array (NumE by NumY by NumX, for a - total of nP points in a sample image stack type scan). The former - data values should be stored with a minimum loss of precision, while - the latter values can be simplified and/or approximated in order to - fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' - are just sample_image scan types with reduced dimensions in the same way - as single images have reduced E dimensions compared to image 'stacks'. -symbols: - doc: | - These symbols will be used below to coordinate the shapes of the datasets. - nP: | - Total number of scan points - nE: | - Number of photon energies scanned - nX: | - Number of pixels in X direction - nY: | - Number of pixels in Y direction - detectorRank: | - Rank of data array provided by the detector for a single measurement -type: group -NXstxm(NXobject): - (NXentry): - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition(NX_CHAR): - exists: ['min', '1', 'max', '1'] - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXstxm] - (NXinstrument): - exists: ['min', '1', 'max', '1'] - (NXsource): - exists: ['min', '1', 'max', '1'] - type: - exists: ['min', '1', 'max', '1'] - name: - exists: ['min', '1', 'max', '1'] - probe: - exists: ['min', '1', 'max', '1'] - (NXmonochromator)monochromator: - exists: ['min', '1', 'max', '1'] - energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector): - exists: ['min', '1'] - data(NX_NUMBER): - dimensions: - rank: 1+detectorRank - doc: | - Detector data should be presented with the first dimension corresponding to the - scan point and subsequent dimensions corresponding to the output of the detector. - Detectors that provide more than one value per scan point should have - a data array of rank 1+d, where d is the dimensions of the array provided per - scan point. For example, an area detector should have an NXdetector data array - of 3 dimensions, with the first being the set of scan points and the latter - two being the x- and y- extent of the detector. - NOTE: For each dimension > 1 there must exist a dim section such as: - dim: [[1, nP]] - (NXdetector)sample_x: - exists: ['min', '0', 'max', '1'] - doc: | - Measurements of the sample position from the x-axis interferometer. - data(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector)sample_y: - exists: ['min', '0', 'max', '1'] - doc: | - Measurements of the sample position from the y-axis interferometer. - data(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector)sample_z: - exists: ['min', '0', 'max', '1'] - doc: | - Measurements of the sample position from the z-axis interferometer. - data(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample): - rotation_angle(NX_FLOAT): - (NXdata): - stxm_scan_type: - exists: ['min', '1', 'max', '1'] - doc: | - Label for typical scan types as a convenience for humans. - Each label corresponds to a specific set of axes being scanned - to produce a data array of shape: - - * sample point spectrum: (photon_energy,) - * sample line spectrum: (photon_energy, sample_y/sample_x) - * sample image: (sample_y, sample_x) - * sample image stack: (photon_energy, sample_y, sample_x) - * sample focus: (zoneplate_z, sample_y/sample_x) - * osa image: (osa_y, osa_x) - * osa focus: (zoneplate_z, osa_y/osa_x) - * detector image: (detector_y, detector_x) - - The "generic scan" string is to be used when none of the - other choices are appropriate. - enumeration: [sample point spectrum, sample line spectrum, sample image, sample image stack, sample focus, osa image, osa focus, detector image, generic scan] - data(NX_NUMBER): - signal: 1 - doc: | - Detectors that provide more than one value per scan point should be summarised - to a single value per scan point for this array in order to simplify plotting. - - Note that 'Line scans' and focus type scans measure along one spatial dimension - but are not restricted to being parallel to the X or Y axes. Such scans - should therefore use a single dimension for the positions along the spatial - line. The 'sample_x' and 'sample_y' fields should then contain lists of the - x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. - energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - doc: | - List of photon energies of the X-ray beam. If scanned through multiple values, - then an 'axis' attribute will be required to link the field to the appropriate data array dimension. - dimensions: - rank: 1 - dim: [[1, nE]] - sample_y(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - doc: | - List of Y positions on the sample. If scanned through multiple values, - then an 'axis' attribute will be required to link the field to the appropriate data array dimension. - dimensions: - rank: 1 - dim: [[1, nY]] - sample_x(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - doc: | - List of X positions on the sample. If scanned through multiple values, - then an 'axis' attribute will be required to link the field to the appropriate data array dimension. - dimensions: - rank: 1 - dim: [[1, nX]] - (NXmonitor)control: - exists: ['min', '0', 'max', '1'] - data(NX_FLOAT): - doc: | - Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring - electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the - NXdata groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4a65935ad78db0a1652d7fceb67425791cfecf0a6a2f24683a5798f866c9d60c -# -# -# -# -# -# -# These symbols will be used below to coordinate the shapes of the datasets. -# -# -# Total number of scan points -# -# -# Number of photon energies scanned -# -# -# Number of pixels in X direction -# -# -# Number of pixels in Y direction -# -# -# Rank of data array provided by the detector for a single measurement -# -# -# -# Application definition for a STXM instrument. -# -# The interferometer -# position measurements, monochromator photon energy values and -# detector measurements are all treated as NXdetectors and stored -# within the NXinstrument group as lists of values stored in -# chronological order. The NXdata group then holds another version -# of the data in a regular 3D array (NumE by NumY by NumX, for a -# total of nP points in a sample image stack type scan). The former -# data values should be stored with a minimum loss of precision, while -# the latter values can be simplified and/or approximated in order to -# fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' -# are just sample_image scan types with reduced dimensions in the same way -# as single images have reduced E dimensions compared to image 'stacks'. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Detector data should be presented with the first dimension corresponding to the -# scan point and subsequent dimensions corresponding to the output of the detector. -# Detectors that provide more than one value per scan point should have -# a data array of rank 1+d, where d is the dimensions of the array provided per -# scan point. For example, an area detector should have an NXdetector data array -# of 3 dimensions, with the first being the set of scan points and the latter -# two being the x- and y- extent of the detector. -# NOTE: For each dimension > 1 there must exist a dim section such as: -# -# -# -# -# -# -# Measurements of the sample position from the x-axis interferometer. -# -# -# -# -# -# -# -# Measurements of the sample position from the y-axis interferometer. -# -# -# -# -# -# -# -# Measurements of the sample position from the z-axis interferometer. -# -# -# -# -# -# -# -# -# -# -# -# -# Label for typical scan types as a convenience for humans. -# Each label corresponds to a specific set of axes being scanned -# to produce a data array of shape: -# -# * sample point spectrum: (photon_energy,) -# * sample line spectrum: (photon_energy, sample_y/sample_x) -# * sample image: (sample_y, sample_x) -# * sample image stack: (photon_energy, sample_y, sample_x) -# * sample focus: (zoneplate_z, sample_y/sample_x) -# * osa image: (osa_y, osa_x) -# * osa focus: (zoneplate_z, osa_y/osa_x) -# * detector image: (detector_y, detector_x) -# -# The "generic scan" string is to be used when none of the -# other choices are appropriate. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Detectors that provide more than one value per scan point should be summarised -# to a single value per scan point for this array in order to simplify plotting. -# -# Note that 'Line scans' and focus type scans measure along one spatial dimension -# but are not restricted to being parallel to the X or Y axes. Such scans -# should therefore use a single dimension for the positions along the spatial -# line. The 'sample_x' and 'sample_y' fields should then contain lists of the -# x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. -# -# -# List of photon energies of the X-ray beam. If scanned through multiple values, -# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. -# -# -# -# -# -# List of Y positions on the sample. If scanned through multiple values, -# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. -# -# -# -# -# -# List of X positions on the sample. If scanned through multiple values, -# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. -# -# -# -# -# -# -# -# Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring -# electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the -# NXdata groups. -# -# -# -# diff --git a/applications/nyaml/NXtas.yaml b/applications/nyaml/NXtas.yaml deleted file mode 100644 index 8e734d65c4..0000000000 --- a/applications/nyaml/NXtas.yaml +++ /dev/null @@ -1,350 +0,0 @@ -category: application -doc: | - This is an application definition for a triple axis spectrometer. - - It is for the trademark scan of the TAS, the Q-E scan. - For your alignment scans use the rules in :ref:`NXscan`. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXtas(NXobject): - (NXentry)entry: - title(NX_CHAR): - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtas] - (NXinstrument): - (NXsource): - name: - probe: - enumeration: [neutron, x-ray] - (NXcrystal)monochromator: - ei(NX_FLOAT): - unit: NX_ENERGY - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - (NXcrystal)analyser: - ef(NX_FLOAT): - unit: NX_ENERGY - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector): - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample): - name: - doc: | - Descriptive name of sample - qh(NX_FLOAT): - unit: NX_DIMENSIONLESS - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - qk(NX_FLOAT): - unit: NX_DIMENSIONLESS - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - ql(NX_FLOAT): - unit: NX_DIMENSIONLESS - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - en(NX_FLOAT): - unit: NX_ENERGY - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - sgu(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - sgl(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - unit_cell(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 6]] - orientation_matrix(NX_FLOAT): - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, 9]] - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata): - doc: | - One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis - ei(link): - target: /NXentry/NXinstrument/monochromator:NXcrystal/ei - ef(link): - target: /NXentry/NXinstrument/analyser:NXcrystal/ef - en(link): - target: /NXentry/NXsample/en - qh(link): - target: /NXentry/NXsample/qh - qk(link): - target: /NXentry/NXsample/qk - ql(link): - target: /NXentry/NXsample/ql - data(link): - target: /NXentry/NXinstrument/NXdetector/data - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3e1396fcfde956ea2d5e48260644bed60a7bf6a088df0c0b5d9928c3fae99fa0 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# This is an application definition for a triple axis spectrometer. -# -# It is for the trademark scan of the TAS, the Q-E scan. -# For your alignment scans use the rules in :ref:`NXscan`. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Total integral monitor counts -# -# -# -# -# -# One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtofnpd.yaml b/applications/nyaml/NXtofnpd.yaml deleted file mode 100644 index 29927992f3..0000000000 --- a/applications/nyaml/NXtofnpd.yaml +++ /dev/null @@ -1,233 +0,0 @@ -category: application -doc: | - This is a application definition for raw data from a TOF neutron powder diffractometer -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: | - Number of detectors - nTimeChan: | - nTimeChan description -type: group -NXtofnpd(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtofnpd] - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flight path before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - (NXuser)user: - name(NX_CHAR): - (NXinstrument): - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 2 - dim: [[1, nDet], [2, nTimeChan]] - detector_number(NX_INT): - axis: 2 - dimensions: - rank: 1 - dim: [[1, nDet]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance to sample for each detector - dimensions: - rank: 1 - dim: [[1, nDet]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - polar angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - azimuthal angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - distance(NX_FLOAT): - unit: NX_LENGTH - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - detector_number(link): - target: /NXentry/NXinstrument/NXdetector/detector_number - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 76efa47955dd8ce499a361753ff2a4da1b9c9771c4cbfff8d5def96ed4ca69bd -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of detectors -# -# -# nTimeChan description -# -# -# This is a application definition for raw data from a TOF neutron powder diffractometer -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# This is the flight path before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# distance to sample for each detector -# -# -# -# -# -# -# -# polar angle for each detector element -# -# -# -# -# azimuthal angle for each detector element -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtofraw.yaml b/applications/nyaml/NXtofraw.yaml deleted file mode 100644 index 0f3547c556..0000000000 --- a/applications/nyaml/NXtofraw.yaml +++ /dev/null @@ -1,255 +0,0 @@ -category: application -doc: | - This is an application definition for raw data from a generic TOF instrument -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: | - Number of detectors - nTimeChan: | - nTimeChan description -type: group -NXtofraw(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtofraw] - duration(NX_FLOAT): - run_number(NX_INT): - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flight path before the sample position. This can be determined by a chopper, - by the moderator, or the source itself. In other words: it is the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - (NXuser)user: - name(NX_CHAR): - (NXinstrument)instrument: - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 2 - dim: [[1, nDet], [2, nTimeChan]] - detector_number(NX_INT): - axis: 2 - dimensions: - rank: 1 - dim: [[1, nDet]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance to sample for each detector - dimensions: - rank: 1 - dim: [[1, nDet]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - polar angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - azimuthal angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - (NXsample): - name: - doc: | - Descriptive name of sample - nature(NX_CHAR): - enumeration: [powder, liquid, single crystal] - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - distance(NX_FLOAT): - unit: NX_LENGTH - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - integral_counts(NX_INT): - unit: NX_UNITLESS - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - detector_number(link): - target: /NXentry/NXinstrument/NXdetector/detector_number - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cf876130ab5b69d23c8694bdbbcb43d81f4121e37e52467668853246ecdbecf4 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of detectors -# -# -# nTimeChan description -# -# -# This is an application definition for raw data from a generic TOF instrument -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# This is the flight path before the sample position. This can be determined by a chopper, -# by the moderator, or the source itself. In other words: it is the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# distance to sample for each detector -# -# -# -# -# -# -# -# -# -# -# polar angle for each detector element -# -# -# -# -# -# azimuthal angle for each detector element -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtofsingle.yaml b/applications/nyaml/NXtofsingle.yaml deleted file mode 100644 index 31eacdc3d2..0000000000 --- a/applications/nyaml/NXtofsingle.yaml +++ /dev/null @@ -1,244 +0,0 @@ -category: application -doc: | - This is a application definition for raw data from a generic TOF instrument -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - xSize: | - xSize description - ySize: | - ySize description - nDet: | - Number of detectors - nTimeChan: | - nTimeChan description -type: group -NXtofsingle(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtofsingle] - duration(NX_FLOAT): - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flight path before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - (NXuser)user: - name(NX_CHAR): - (NXinstrument): - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, xSize], [2, ySize], [3, nTimeChan]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance to sample for the center of the detector - dimensions: - rank: 1 - dim: [[1, 1]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - polar angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - azimuthal angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - (NXsample): - name: - doc: | - Descriptive name of sample - nature(NX_CHAR): - enumeration: [powder, liquid, single crystal] - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - distance(NX_FLOAT): - unit: NX_LENGTH - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 68f4d548d9d5116bbd6e38aa5ed5230e7ac8f1f0dcb70edc3aceb398ea4983d0 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# xSize description -# -# -# ySize description -# -# -# Number of detectors -# -# -# nTimeChan description -# -# -# This is a application definition for raw data from a generic TOF instrument -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# This is the flight path before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance to sample for the center of the detector -# -# -# -# -# -# -# -# polar angle for each detector element -# -# -# -# -# azimuthal angle for each detector element -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtomo.yaml b/applications/nyaml/NXtomo.yaml deleted file mode 100644 index 8ec340419e..0000000000 --- a/applications/nyaml/NXtomo.yaml +++ /dev/null @@ -1,279 +0,0 @@ -category: application -doc: | - This is the application definition for x-ray or neutron tomography raw data. - - In tomography - a number of dark field images are measured, some bright field images and, of course the sample. - In order to distinguish between them images carry a image_key. -symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. - nFrames: | - Number of frames - xSize: | - Number of pixels in X direction - ySize: | - Number of pixels in Y direction -type: group -NXtomo(NXobject): - (NXentry)entry: - title: - exists: ['min', '0', 'max', '1'] - start_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - end_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtomo] - (NXinstrument)instrument: - (NXsource): - exists: ['min', '0', 'max', '1'] - type: - exists: ['min', '0', 'max', '1'] - name: - exists: ['min', '0', 'max', '1'] - probe: - exists: ['min', '0', 'max', '1'] - enumeration: [neutron, x-ray, electron] - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nFrames], [2, xSize], [3, ySize]] - image_key(NX_INT): - doc: | - In order - to distinguish between sample projections, dark and flat - images, a magic number is recorded per frame. - The key is as follows: - - * projection = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - dimensions: - rank: 1 - dim: [[1, nFrames]] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Distance between detector and sample - x_rotation_axis_pixel_position(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - y_rotation_axis_pixel_position(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - (NXsample)sample: - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - In practice this axis is always aligned along one pixel direction on the detector and usually vertical. - There are experiments with horizontal rotation axes, so this would need to be indicated somehow. - For now the best way for that is an open question. - dimensions: - rank: 1 - dim: [[1, nFrames]] - x_translation(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - dimensions: - rank: 1 - dim: [[1, nFrames]] - y_translation(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - dimensions: - rank: 1 - dim: [[1, nFrames]] - z_translation(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - dimensions: - rank: 1 - dim: [[1, nFrames]] - (NXmonitor)control: - exists: ['min', '0', 'max', '1'] - data(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts for each measured frame. Allows a to correction for - fluctuations in the beam between frames. - dimensions: - rank: 1 - dim: [[1, nFrames]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/detector:NXdetector/data - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - image_key(link): - target: /NXentry/NXinstrument/detector:NXdetector/image_key - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2ddef81db80e94c71e2fd772d74cfdae6cf00b895087e66b9e346d23a86fbc72 -# -# -# -# -# -# -# These symbols will be used below to coordinate datasets with the same shape. -# -# -# Number of frames -# -# -# Number of pixels in X direction -# -# -# Number of pixels in Y direction -# -# -# -# This is the application definition for x-ray or neutron tomography raw data. -# -# In tomography -# a number of dark field images are measured, some bright field images and, of course the sample. -# In order to distinguish between them images carry a image_key. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# In order -# to distinguish between sample projections, dark and flat -# images, a magic number is recorded per frame. -# The key is as follows: -# -# * projection = 0 -# * flat field = 1 -# * dark field = 2 -# * invalid = 3 -# -# -# -# -# -# -# -# -# Distance between detector and sample -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# In practice this axis is always aligned along one pixel direction on the detector and usually vertical. -# There are experiments with horizontal rotation axes, so this would need to be indicated somehow. -# For now the best way for that is an open question. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total integral monitor counts for each measured frame. Allows a to correction for -# fluctuations in the beam between frames. -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtomophase.yaml b/applications/nyaml/NXtomophase.yaml deleted file mode 100644 index 7ef44c6a21..0000000000 --- a/applications/nyaml/NXtomophase.yaml +++ /dev/null @@ -1,292 +0,0 @@ -category: application -doc: | - This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. - - In tomography first - some dark field images are measured, some bright field images and, of course the sample. In order - to properly sort the order of the images taken, a sequence number is stored with each image. -symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. - nBrightFrames: | - Number of bright frames - nDarkFrames: | - Number of dark frames - nSampleFrames: | - Number of image (sample) frames - nPhase: | - Number of phase settings - xSize: | - Number of pixels in X direction - ySize: | - Number of pixels in Y direction -type: group -NXtomophase(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtomophase] - (NXinstrument)instrument: - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXdetector)bright_field: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nBrightFrames], [2, xSize], [3, ySize]] - sequence_number(NX_INT): - dimensions: - rank: 1 - dim: [[1, nBrightFrames]] - (NXdetector)dark_field: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nDarkFrames], [2, xSize], [3, ySize]] - sequence_number(NX_INT): - dimensions: - rank: 1 - dim: [[1, nDarkFrames]] - (NXdetector)sample: - data(NX_INT): - signal: 1 - dimensions: - rank: 4 - dim: [[1, nSampleFrames], [2, nPhase], [3, xSize], [4, ySize]] - sequence_number(NX_INT): - dimensions: - rank: 2 - dim: [[1, nSampleFrames], [2, nPhase]] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance between detector and sample - (NXsample)sample: - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - dimensions: - rank: 1 - dim: [[1, nSampleFrames]] - x_translation(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, nSampleFrames]] - y_translation(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, nSampleFrames]] - z_translation(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, nSampleFrames]] - (NXmonitor)control: - integral(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts for each measured frame. Allows a correction for - fluctuations in the beam between frames. - dimensions: - rank: 1 - - # TODO: nPhase? - dim: [[1, nDarkFrames + nBrightFrames + nSampleFrame]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/sample:NXdetector/data - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 61792a668d325a2c70187730d3457c9ee8aba24ca55e9405ee1dd4d29f7d2296 -# -# -# -# -# -# These symbols will be used below to coordinate datasets with the same shape. -# -# Number of bright frames -# -# -# Number of dark frames -# -# -# Number of image (sample) frames -# -# -# Number of phase settings -# -# -# Number of pixels in X direction -# -# -# Number of pixels in Y direction -# -# -# -# This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. -# -# In tomography first -# some dark field images are measured, some bright field images and, of course the sample. In order -# to properly sort the order of the images taken, a sequence number is stored with each image. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance between detector and sample -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total integral monitor counts for each measured frame. Allows a correction for -# fluctuations in the beam between frames. -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtomoproc.yaml b/applications/nyaml/NXtomoproc.yaml deleted file mode 100644 index 48ba4c9e04..0000000000 --- a/applications/nyaml/NXtomoproc.yaml +++ /dev/null @@ -1,217 +0,0 @@ -category: application -doc: | - This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. -symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. - nX: | - Number of voxels in X direction - nY: | - Number of voxels in Y direction - nZ: | - Number of voxels in Z direction -type: group -NXtomoproc(NXobject): - (NXentry)entry: - title: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtomoproc] - (NXinstrument): - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXprocess)reconstruction: - program(NX_CHAR): - doc: | - Name of the program used for reconstruction - version(NX_CHAR): - doc: | - Version of the program used - date(NX_DATE_TIME): - doc: | - Date and time of reconstruction processing. - (NXparameters)parameters: - raw_file(NX_CHAR): - doc: | - Original raw data file this data was derived from - (NXdata)data: - data(NX_INT): - signal: 1 - doc: | - This is the reconstructed volume. This can be different - things. Please indicate in the unit attribute what physical - quantity this really is. - dimensions: - rank: 3 - dim: [[1, nX], [2, nX], [3, nZ]] - \@transform: - \@offset: - \@scaling: - x(NX_FLOAT): - unit: NX_ANY - axis: 1 - doc: | - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nX]] - y(NX_FLOAT): - unit: NX_ANY - axis: 2 - doc: | - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nY]] - z(NX_FLOAT): - unit: NX_ANY - axis: 3 - doc: | - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nZ]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f0f55737027dae413b76cbb267a0d0021482dfdf9d398c0886e5d5b4e8c8bca1 -# -# -# -# -# -# These symbols will be used below to coordinate datasets with the same shape. -# -# Number of voxels in X direction -# -# -# Number of voxels in Y direction -# -# -# Number of voxels in Z direction -# -# -# This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# Name of the program used for reconstruction -# -# -# Version of the program used -# -# -# Date and time of reconstruction processing. -# -# -# -# Original raw data file this data was derived from -# -# -# -# -# -# -# This is the reconstructed volume. This can be different -# things. Please indicate in the unit attribute what physical -# quantity this really is. -# -# -# -# -# -# -# -# -# -# -# -# -# This is an array holding the values to use for the x-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the y-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the z-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxas.yaml b/applications/nyaml/NXxas.yaml deleted file mode 100644 index 865c953dce..0000000000 --- a/applications/nyaml/NXxas.yaml +++ /dev/null @@ -1,212 +0,0 @@ -category: application -doc: | - This is an application definition for raw data from an X-ray absorption spectroscopy experiment. - - This is essentially a scan on energy versus incoming/ - absorbed beam. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxas(NXobject): - (NXentry): - \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... - for analysis software to locate each entry. - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxas] - (NXinstrument): - (NXsource): - type: - name: - probe: - enumeration: [x-ray] - (NXmonochromator)monochromator: - energy(NX_FLOAT): - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector)incoming_beam: - data(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector)absorbed_beam: - data(NX_NUMBER): - doc: | - This data corresponds to the sample signal. - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_NUMBER): - doc: | - This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata): - energy(link): - target: /NXentry/NXinstrument/monochromator:NXmonochromator/energy - absorbed_beam(link): - target: /NXentry/NXinstrument/absorbed_beam:NXdetector/data - mode: - doc: | - Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) - enumeration: [Total Electron Yield, Partial Electron Yield, Auger Electron Yield, Fluorescence Yield, Transmission] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2d5aaca6043db70d6315aaf4b2fbd9cc9e75ce43f1f2103fd79fdb9c11e36f4d -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# This is an application definition for raw data from an X-ray absorption spectroscopy experiment. -# -# This is essentially a scan on energy versus incoming/ -# absorbed beam. -# -# -# -# -# NeXus convention is to use "entry1", "entry2", ... -# for analysis software to locate each entry. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# This data corresponds to the sample signal. -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` -# -# -# -# -# -# -# -# -# -# Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxasproc.yaml b/applications/nyaml/NXxasproc.yaml deleted file mode 100644 index 111d6699bc..0000000000 --- a/applications/nyaml/NXxasproc.yaml +++ /dev/null @@ -1,147 +0,0 @@ -category: application -doc: | - Processed data from XAS. This is energy versus I(incoming)/I(absorbed). -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxasproc(NXobject): - (NXentry): - \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... - for analysis software to locate each entry. - title: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxasproc] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXprocess)XAS_data_reduction: - program(NX_CHAR): - doc: | - Name of the program used for reconstruction - version(NX_CHAR): - doc: | - Version of the program used - date(NX_DATE_TIME): - doc: | - Date and time of reconstruction processing. - (NXparameters)parameters: - raw_file(NX_CHAR): - doc: | - Original raw data file this data was derived from - (NXdata): - energy: - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - data(NX_FLOAT): - doc: | - This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. - Expect attribute ``signal=1`` - dimensions: - rank: 1 - dim: [[1, nP]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 07a20126249a01bd8a1d5b7cf0796baf16f8dd148bcddc87d976c77baa89e00c -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# Processed data from XAS. This is energy versus I(incoming)/I(absorbed). -# -# -# -# -# NeXus convention is to use "entry1", "entry2", ... -# for analysis software to locate each entry. -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# Name of the program used for reconstruction -# -# -# Version of the program used -# -# -# Date and time of reconstruction processing. -# -# -# -# Original raw data file this data was derived from -# -# -# -# -# -# -# -# -# -# -# -# This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. -# Expect attribute ``signal=1`` -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxbase.yaml b/applications/nyaml/NXxbase.yaml deleted file mode 100644 index 46db086841..0000000000 --- a/applications/nyaml/NXxbase.yaml +++ /dev/null @@ -1,308 +0,0 @@ -category: application -doc: | - This definition covers the common parts of all monochromatic single crystal raw data application definitions. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points - nXPixels: | - Number of X pixels - nYPixels: | - Number of Y pixels -type: group -NXxbase(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxbase] - (NXinstrument)instrument: - (NXsource)source: - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXmonochromator)monochromator: - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - (NXdetector)detector: - exists: ['max', 'unbounded'] - data(NX_INT): - signal: 1 - doc: | - The area detector data, the first dimension is always the - number of scan points, the second and third are the number - of pixels in x and y. The origin is always assumed to be - in the center of the detector. maxOccurs is limited to the - the number of detectors on your instrument. - dimensions: - rank: 3 - dim: [[1, nP], [2, nXPixels], [3, nYPixels]] - \@signal: - type: NX_POSINT - enumeration: [1] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - The name of the group is detector if there is only one detector, - if there are several, names have to be detector1, - detector2, ...detectorn. - distance(NX_FLOAT): - unit: NX_LENGTH - frame_start_number(NX_INT): - doc: | - This is the start number of the first frame of a scan. In PX one often scans a couple - of frames on a give sample, then does something else, then returns to the same sample - and scans some more frames. Each time with a new data file. - This number helps concatenating such measurements. - (NXsample)sample: - name(NX_CHAR): - doc: | - Descriptive name of sample - orientation_matrix(NX_FLOAT): - doc: | - The orientation matrix according to Busing and - Levy conventions. This is not strictly necessary as - the UB can always be derived from the data. But - let us bow to common usage which includes the - UB nearly always. - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - unit_cell(NX_FLOAT): - doc: | - The unit cell, a, b, c, alpha, beta, gamma. - Again, not strictly necessary, but normally written. - dimensions: - rank: 1 - dim: [[1, 6]] - temperature(NX_FLOAT): - doc: | - The sample temperature or whatever sensor represents this value best - dimensions: - rank: 1 - dim: [[1, nP]] - x_translation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the X-direction of the laboratory coordinate system - y_translation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the Y-direction of the laboratory coordinate system - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the Z-direction of the laboratory coordinate system - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - integral(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts - (NXdata): - doc: | - The name of this group id data if there is only - one detector; if there are several the names will - be data1, data2, data3 and will point - to the corresponding detector groups in the - instrument hierarchy. - data(link): - target: /NXentry/NXinstrument/NXdetector/data - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 97c93a3c48735ce7430e1e80498bae3276fa68441c19151174bc943af9503be3 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# Number of X pixels -# -# -# Number of Y pixels -# -# -# -# This definition covers the common parts of all monochromatic single crystal raw data application definitions. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The area detector data, the first dimension is always the -# number of scan points, the second and third are the number -# of pixels in x and y. The origin is always assumed to be -# in the center of the detector. maxOccurs is limited to the -# the number of detectors on your instrument. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The name of the group is detector if there is only one detector, -# if there are several, names have to be detector1, -# detector2, ...detectorn. -# -# -# -# This is the start number of the first frame of a scan. In PX one often scans a couple -# of frames on a give sample, then does something else, then returns to the same sample -# and scans some more frames. Each time with a new data file. -# This number helps concatenating such measurements. -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# The orientation matrix according to Busing and -# Levy conventions. This is not strictly necessary as -# the UB can always be derived from the data. But -# let us bow to common usage which includes the -# UB nearly always. -# -# -# -# -# -# -# -# -# The unit cell, a, b, c, alpha, beta, gamma. -# Again, not strictly necessary, but normally written. -# -# -# -# -# -# -# -# The sample temperature or whatever sensor represents this value best -# -# -# -# -# -# -# Translation of the sample along the X-direction of the laboratory coordinate system -# -# -# Translation of the sample along the Y-direction of the laboratory coordinate system -# -# -# Translation of the sample along the Z-direction of the laboratory coordinate system -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Total integral monitor counts -# -# -# -# -# The name of this group id data if there is only -# one detector; if there are several the names will -# be data1, data2, data3 and will point -# to the corresponding detector groups in the -# instrument hierarchy. -# -# -# -# -# diff --git a/applications/nyaml/NXxeuler.yaml b/applications/nyaml/NXxeuler.yaml deleted file mode 100644 index 103128c2dc..0000000000 --- a/applications/nyaml/NXxeuler.yaml +++ /dev/null @@ -1,173 +0,0 @@ -category: application -doc: | - raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` - - It extends :ref:`NXxbase`, so the full definition is the content - of :ref:`NXxbase` plus the data defined here. All four angles are - logged in order to support arbitrary scans in reciprocal space. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxeuler(NXxbase): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxeuler] - (NXinstrument)instrument: - (NXdetector)detector: - polar_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - The polar_angle (two theta) where the detector is placed - at each scan point. - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample)sample: - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the sample rotation angle at each - scan point - dimensions: - rank: 1 - dim: [[1, nP]] - chi(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the chi angle of the eulerian - cradle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - phi(NX_FLOAT): - unit: NX_ANGLE - signal: 1 - doc: | - This is an array holding the phi rotation of the eulerian - cradle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata)name: - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - chi(link): - target: /NXentry/NXsample/chi - phi(link): - target: /NXentry/NXsample/phi - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 418ca04c5cb718b73b9fb0a9ba4d7834a39720336466afd0292a376c2e6db6f0 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` -# -# It extends :ref:`NXxbase`, so the full definition is the content -# of :ref:`NXxbase` plus the data defined here. All four angles are -# logged in order to support arbitrary scans in reciprocal space. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# The polar_angle (two theta) where the detector is placed -# at each scan point. -# -# -# -# -# -# -# -# -# -# -# This is an array holding the sample rotation angle at each -# scan point -# -# -# -# -# -# -# -# This is an array holding the chi angle of the eulerian -# cradle at each scan point -# -# -# -# -# -# -# -# This is an array holding the phi rotation of the eulerian -# cradle at each scan point -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxkappa.yaml b/applications/nyaml/NXxkappa.yaml deleted file mode 100644 index 11ee96ea7a..0000000000 --- a/applications/nyaml/NXxkappa.yaml +++ /dev/null @@ -1,174 +0,0 @@ -category: application -doc: | - raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` - - This is the application definition for raw data from a kappa geometry - (CAD4) single crystal - diffractometer. It extends :ref:`NXxbase`, so the full definition is - the content of :ref:`NXxbase` plus the - data defined here. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxkappa(NXxbase): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxkappa] - (NXinstrument)instrument: - (NXdetector)detector: - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - The polar_angle (two theta) at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample)sample: - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the sample rotation angle at each - scan point - dimensions: - rank: 1 - dim: [[1, nP]] - kappa(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the kappa angle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - phi(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the phi angle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - alpha(NX_FLOAT): - unit: NX_ANGLE - doc: | - This holds the inclination angle of the kappa arm. - (NXdata)name: - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - kappa(link): - target: /NXentry/NXsample/kappa - phi(link): - target: /NXentry/NXsample/phi - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ab0a0187da4ac644dd64a38cf2120fa6519200d0c8097d2e33373b66c4e3fab5 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` -# -# This is the application definition for raw data from a kappa geometry -# (CAD4) single crystal -# diffractometer. It extends :ref:`NXxbase`, so the full definition is -# the content of :ref:`NXxbase` plus the -# data defined here. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# The polar_angle (two theta) at each scan point -# -# -# -# -# -# -# -# -# -# This is an array holding the sample rotation angle at each -# scan point -# -# -# -# -# -# -# -# This is an array holding the kappa angle at each scan point -# -# -# -# -# -# -# -# This is an array holding the phi angle at each scan point -# -# -# -# -# -# -# This holds the inclination angle of the kappa arm. -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxlaue.yaml b/applications/nyaml/NXxlaue.yaml deleted file mode 100644 index 82e1d406ba..0000000000 --- a/applications/nyaml/NXxlaue.yaml +++ /dev/null @@ -1,109 +0,0 @@ -category: application -doc: | - raw data from a single crystal laue camera, extends :ref:`NXxrot` - - This is the application definition for raw data from a single crystal laue - camera. It extends :ref:`NXxrot`. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nE: | - Number of energies -type: group -NXxlaue(NXxrot): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxlaue] - (NXinstrument)instrument: - (NXsource)source: - (NXdata)distribution: - data: - doc: | - expect ``signal=1 axes="energy"`` - dimensions: - rank: 1 - dim: [[1, nE]] - wavelength: - unit: NX_WAVELENGTH - dimensions: - rank: 1 - dim: [[1, nE]] - doc: | - This is the wavelength distribution of the beam - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6bd59c0bb31baf46bbacaad01e38b03336b75f5d94468e0689b72386f201e77b -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of energies -# -# -# -# raw data from a single crystal laue camera, extends :ref:`NXxrot` -# -# This is the application definition for raw data from a single crystal laue -# camera. It extends :ref:`NXxrot`. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# expect ``signal=1 axes="energy"`` -# -# -# -# -# -# -# -# -# -# -# This is the wavelength distribution of the beam -# -# -# -# -# -# diff --git a/applications/nyaml/NXxlaueplate.yaml b/applications/nyaml/NXxlaueplate.yaml deleted file mode 100644 index bb23a1d29f..0000000000 --- a/applications/nyaml/NXxlaueplate.yaml +++ /dev/null @@ -1,73 +0,0 @@ -category: application -doc: | - raw data from a single crystal Laue camera, extends :ref:`NXxlaue` - - This is the application definition for raw data from a single crystal Laue - camera with an image plate as a detector. It extends :ref:`NXxlaue`. -type: group -NXxlaueplate(NXxlaue): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxlaueplate] - (NXinstrument)instrument: - (NXdetector)detector: - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - The diameter of a cylindrical detector - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7ad47196c57fedde1c91245a9edd7ff63d278eb1e2fbac3d8059e8f2744c3a80 -# -# -# -# -# -# raw data from a single crystal Laue camera, extends :ref:`NXxlaue` -# -# This is the application definition for raw data from a single crystal Laue -# camera with an image plate as a detector. It extends :ref:`NXxlaue`. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# The diameter of a cylindrical detector -# -# -# -# -# diff --git a/applications/nyaml/NXxnb.yaml b/applications/nyaml/NXxnb.yaml deleted file mode 100644 index c5f052d79a..0000000000 --- a/applications/nyaml/NXxnb.yaml +++ /dev/null @@ -1,160 +0,0 @@ -category: application -doc: | - raw data from a single crystal diffractometer, extends :ref:`NXxbase` - - This is the application definition for raw data from - a single crystal diffractometer - measuring in normal beam mode. It extends :ref:`NXxbase`, - so the full definition is the content of - :ref:`NXxbase` plus the data defined here. All angles are - logged in order to support arbitrary scans in - reciprocal space. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxnb(NXxbase): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxnb] - (NXinstrument)instrument: - (NXdetector)detector: - polar_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - The polar_angle (gamma) of the detector for each scan point. - dimensions: - rank: 1 - dim: [[1, nP]] - tilt_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - The angle by which the detector has been tilted out of the - scattering plane. - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample)sample: - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - primary: 1 - doc: | - This is an array holding the sample rotation angle at each - scan point - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata)name: - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - tilt(link): - target: /NXentry/NXinstrument/NXdetector/tilt - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 08abdab5fcf7054861bd5927b569a05e6d69a55b7ed9b80344a60ede01cc3516 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# raw data from a single crystal diffractometer, extends :ref:`NXxbase` -# -# This is the application definition for raw data from -# a single crystal diffractometer -# measuring in normal beam mode. It extends :ref:`NXxbase`, -# so the full definition is the content of -# :ref:`NXxbase` plus the data defined here. All angles are -# logged in order to support arbitrary scans in -# reciprocal space. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# The polar_angle (gamma) of the detector for each scan point. -# -# -# -# -# -# -# -# The angle by which the detector has been tilted out of the -# scattering plane. -# -# -# -# -# -# -# -# -# -# -# This is an array holding the sample rotation angle at each -# scan point -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxrot.yaml b/applications/nyaml/NXxrot.yaml deleted file mode 100644 index 5aa4e35558..0000000000 --- a/applications/nyaml/NXxrot.yaml +++ /dev/null @@ -1,155 +0,0 @@ -category: application -doc: | - raw data from a rotation camera, extends :ref:`NXxbase` - - This is the application definition for raw data from a rotation camera. - It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` - plus the data defined here. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxrot(NXxbase): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - enumeration: [NXxrot] - (NXinstrument)instrument: - (NXdetector)detector: - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - The polar_angle (two theta) where the detector is placed. - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the x position where the direct beam would hit the detector. This is a - length, not a pixel position, and can be outside of the actual detector. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the y position where the direct beam would hit the detector. This is a - length, not a pixel position, and can be outside of the actual detector. - (NXattenuator)attenuator: - attenuator_transmission(NX_FLOAT): - unit: NX_ANY - (NXsample)sample: - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the sample rotation start angle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - rotation_angle_step(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the step made for sample rotation angle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata)name: - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 996ce47ecffe4c4b4e0ffe4014ce8d5db9abb70f109b8508e5124256777ae344 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# raw data from a rotation camera, extends :ref:`NXxbase` -# -# This is the application definition for raw data from a rotation camera. -# It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` -# plus the data defined here. -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# The polar_angle (two theta) where the detector is placed. -# -# -# -# This is the x position where the direct beam would hit the detector. This is a -# length, not a pixel position, and can be outside of the actual detector. -# -# -# -# This is the y position where the direct beam would hit the detector. This is a -# length, not a pixel position, and can be outside of the actual detector. -# -# -# -# -# -# -# -# -# -# This is an array holding the sample rotation start angle at each scan point -# -# -# -# -# -# This is an array holding the step made for sample rotation angle at each scan point -# -# -# -# -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXaperture.yaml b/base_classes/nyaml/NXaperture.yaml deleted file mode 100644 index e728c15505..0000000000 --- a/base_classes/nyaml/NXaperture.yaml +++ /dev/null @@ -1,168 +0,0 @@ -category: base -doc: | - A beamline aperture. This group is deprecated, use NXslit instead. -type: group -NXaperture(NXobject): - - # TODO compare with "screens" in SHADOW - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the - surface of the aperture pointing towards the source. - - In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - - .. image:: aperture/aperture.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the aperture and :ref:`NXoff_geometry` to describe its shape - doc: | - location and shape of aperture - - .. TODO: documentation needs improvement, contributions welcome - - * description of terms is poor and leaves much to interpretation - * Describe what is meant by translation _here_ and ... - * Similar throughout base classes - * Some base classes do this much better - * Such as where is the gap written? - BLADE_GEOMETRY(NXgeometry): - deprecated: | - Use :ref:`NXoff_geometry` instead to describe the shape of the aperture - doc: | - location and shape of each blade - material: - - # TODO Uniformity problem, "type" is used elsewhere for same context - doc: | - Absorbing material of the aperture - description: - doc: | - Description of aperture - (NXnote): - doc: | - describe any additional information in a note* - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 106da0bc8d01d7fed9a85f73a915d0b6815b83cdaa4d84b76228767be1543c00 -# -# -# -# -# -# A beamline aperture. This group is deprecated, use NXslit instead. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the -# surface of the aperture pointing towards the source. -# -# In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. -# -# .. image:: aperture/aperture.png -# :width: 40% -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# location and shape of aperture -# -# .. TODO: documentation needs improvement, contributions welcome -# -# * description of terms is poor and leaves much to interpretation -# * Describe what is meant by translation _here_ and ... -# * Similar throughout base classes -# * Some base classes do this much better -# * Such as where is the gap written? -# -# -# -# -# location and shape of each blade -# -# -# Absorbing material of the aperture -# -# -# Description of aperture -# -# describe any additional information in a note* -# -# -# .. 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/nyaml/NXattenuator.yaml b/base_classes/nyaml/NXattenuator.yaml deleted file mode 100644 index 21fc404d16..0000000000 --- a/base_classes/nyaml/NXattenuator.yaml +++ /dev/null @@ -1,206 +0,0 @@ -category: base -doc: | - A device that reduces the intensity of a beam by attenuation. - - If uncertain whether to use :ref:`NXfilter` (band-pass filter) - or :ref:`NXattenuator` (reduces beam intensity), then choose - :ref:`NXattenuator`. -type: group -NXattenuator(NXobject): - - # TODO compare with SHADOW definition "screen" - # TODO SHADOW: https://github.com/oasys-kit/shadow3 - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance from sample. Note, it is recommended to use NXtransformations instead. - type: - doc: | - Type or composition of attenuator, e.g. polythene - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of attenuator along beam direction - scattering_cross_section(NX_FLOAT): - unit: NX_CROSS_SECTION - doc: | - Scattering cross section (coherent+incoherent) - absorption_cross_section(NX_FLOAT): - unit: NX_CROSS_SECTION - doc: | - Absorption cross section - attenuator_transmission(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - The nominal amount of the beam that gets through - (transmitted intensity)/(incident intensity) - status: - doc: | - In or out or moving of the beam - \@time: - type: NX_DATE_TIME - doc: | - time stamp for this observation - enumeration: [in, out, moving] - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the attenuator is its center in the x and y axis. The reference point on the z axis is the - surface of the attenuator pointing towards the source. - - In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - - .. image:: attenuator/attenuator.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - shape(NXoff_geometry): - doc: | - Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5cb6333d87df9b8f1b009346d2bf55434c7d4ef72f1ce1b62db27caf873c4f7f -# -# -# -# -# -# -# A device that reduces the intensity of a beam by attenuation. -# -# If uncertain whether to use :ref:`NXfilter` (band-pass filter) -# or :ref:`NXattenuator` (reduces beam intensity), then choose -# :ref:`NXattenuator`. -# -# -# -# -# Distance from sample. Note, it is recommended to use NXtransformations instead. -# -# -# Type or composition of attenuator, e.g. polythene -# -# -# Thickness of attenuator along beam direction -# -# -# Scattering cross section (coherent+incoherent) -# -# -# Absorption cross section -# -# -# -# The nominal amount of the beam that gets through -# (transmitted intensity)/(incident intensity) -# -# -# -# In or out or moving of the beam -# -# time stamp for this observation -# -# -# -# -# -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the attenuator is its center in the x and y axis. The reference point on the z axis is the -# surface of the attenuator pointing towards the source. -# -# In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. -# -# .. image:: attenuator/attenuator.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. -# -# -# diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml deleted file mode 100644 index 5aeef146ae..0000000000 --- a/base_classes/nyaml/NXbeam.yaml +++ /dev/null @@ -1,621 +0,0 @@ -category: base -doc: | - Properties of the neutron or X-ray beam at a given location. - - This group is intended to be referenced - by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. - To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred - by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. -symbols: - doc: | - These symbols coordinate datasets with the same shape. - nP: | - Number of scan points. - m: | - Number of channels in the incident beam spectrum, if known - c: | - Number of moments representing beam divergence (x, y, xy, etc.) -type: group -NXbeam(NXobject): - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance from sample. Note, it is recommended to use NXtransformations instead. - incident_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy carried by each particle of the beam on entering the beamline component - dimensions: - rank: 1 - dim: [[1, m]] - final_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy carried by each particle of the beam on leaving the beamline component - dimensions: - rank: 1 - dim: [[1, m]] - energy_transfer(NX_FLOAT): - unit: NX_ENERGY - doc: | - Change in particle energy caused by the beamline component - dimensions: - rank: 1 - dim: [[1, m]] - incident_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - In the case of a monochromatic beam this is the scalar - wavelength. - - Several other use cases are permitted, depending on the - presence or absence of other incident_wavelength_X - fields. - - In the case of a polychromatic beam this is an array of - length **m** of wavelengths, with the relative weights - in ``incident_wavelength_weights``. - - In the case of a monochromatic beam that varies shot- - to-shot, this is an array of wavelengths, one for each - recorded shot. Here, ``incident_wavelength_weights`` and - incident_wavelength_spread are not set. - - In the case of a polychromatic beam that varies shot-to- - shot, this is an array of length **m** with the relative - weights in ``incident_wavelength_weights`` as a 2D array. - - In the case of a polychromatic beam that varies shot-to- - shot and where the channels also vary, this is a 2D array - of dimensions **nP** by **m** (slow to fast) with the - relative weights in ``incident_wavelength_weights`` as a 2D - array. - - Note, :ref:`variants ` are a good way - to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value wavelength value is - available along with the original spectrum from which it - was calibrated. - Wavelength on entering beamline component - incident_wavelength_weights(NX_FLOAT): - doc: | - In the case of a polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in ``incident_wavelength``. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **nP** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in ``incident_wavelength``. - incident_wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The wavelength spread FWHM for the corresponding - wavelength(s) in incident_wavelength. - - In the case of shot-to-shot variation in the wavelength - spread, this is a 2D array of dimension **nP** by - **m** (slow to fast) of the spreads of the - corresponding wavelengths in incident_wavelength. - dimensions: - rank: 1 - dim: [[1, nP]] - incident_beam_divergence(NX_FLOAT): - unit: NX_ANGLE - doc: | - Beam crossfire in degrees parallel to the laboratory X axis - - The dimension **c** is a series of moments of that represent - the standard uncertainty (e.s.d.) of the directions of - of the beam. The first and second moments are in the XZ and YZ - planes around the mean source beam direction, respectively. - - Further moments in **c** characterize co-variance terms, so - the next moment is the product of the first two, and so on. - dimensions: - rank: 2 - dim: [[1, nP], [2, c]] - extent(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM - dimensions: - rank: 2 - dim: [[1, nP], [2, 2]] - final_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Wavelength on leaving beamline component - dimensions: - rank: 1 - dim: [[1, m]] - incident_polarization(NX_NUMBER): - unit: NX_ANY - doc: | - Polarization vector on entering beamline component - dimensions: - rank: 2 - dim: [[1, nP], [2, 2]] - final_polarization(NX_NUMBER): - unit: NX_ANY - doc: | - Polarization vector on leaving beamline component - dimensions: - rank: 2 - dim: [[1, nP], [2, 2]] - incident_polarization_stokes(NX_NUMBER): - unit: NX_ANY - doc: | - Polarization vector on entering beamline component using Stokes notation - - The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. - These are defined with the standard Nexus coordinate frame unless it is - overridden by an NXtransformations field pointed to by a depends_on attribute. - The last component, describing the circular polarization state, is positive - for a right-hand circular state - that is the electric field vector rotates - clockwise at the sample and over time when observed from the source. - - I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale - linearly with the total degree of polarization, and indicate the relative - magnitudes of the pure linear and circular orientation contributions. - - Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). - - U (S_2) is linearly polarized along the x==y axis (U > 0) or the - -x==y axis (U < 0). - - V (S_3) is circularly polarized. V > 0 when the electric field vector rotates - clockwise at the sample with respect to time when observed from the source; - V < 0 indicates the opposite rotation. - dimensions: - rank: 2 - dim: [[1, nP], [2, 4]] - final_polarization_stokes(NX_NUMBER): - unit: NX_ANY - doc: | - Polarization vector on leaving beamline component using Stokes notation - (see incident_polarization_stokes). - dimensions: - rank: 2 - dim: [[1, nP], [2, 4]] - final_wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Wavelength spread FWHM of beam leaving this component - dimensions: - rank: 1 - dim: [[1, m]] - final_beam_divergence(NX_FLOAT): - unit: NX_ANGLE - doc: | - Divergence FWHM of beam leaving this component - dimensions: - rank: 2 - dim: [[1, nP], [2, 2]] - flux(NX_FLOAT): - unit: NX_FLUX - doc: | - flux incident on beam plane area - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata): - doc: | - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly - useful for simulations which need to store plottable information at each beamline - component. - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - exists: ['min', '0'] - doc: | - The NeXus coordinate system defines the Z axis to be along the nominal beam - direction. This is the same as the McStas coordinate system (see :ref:Design-CoordinateSystem). - However, the additional transformations needed to represent an altered beam - direction can be provided using this depends_on field that contains the path - to a NXtransformations group. This could represent redirection of the beam, - or a refined beam direction. - (NXtransformations): - exists: ['min', '0'] - doc: | - Direction (and location) for the beam. The location of the beam can be given by - any point which it passes through as its offset attribute. - DIRECTION(NX_NUMBER): - nameType: any - unit: NX_TRANSFORMATION - doc: | - Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] - and passes through the origin - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the direction of beam vector - \@offset: - type: NX_NUMBER - doc: | - Three values that define the location of a point through which the beam passes - \@depends_on: - type: NX_CHAR - doc: | - Points to the path to a field defining the location on which this - depends or the string "." for origin. - reference_plane(NX_NUMBER): - nameType: any - unit: NX_TRANSFORMATION - doc: | - Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. - This also defines the parallel and perpendicular components of the beam's polarization. - If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the direction of reference plane normal - \@offset: - type: NX_NUMBER - doc: | - Not required as beam direction offset locates the plane - \@depends_on: - type: NX_CHAR - doc: | - Points to the path to a field defining the location on which this - depends or the string "." for origin. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 82a55b351e178e0a209ab7d8a7243527e49dafbfca75a4f2f597fe8bcf735e46 -# -# -# -# -# -# -# These symbols coordinate datasets with the same shape. -# -# -# Number of scan points. -# -# -# Number of channels in the incident beam spectrum, if known -# -# -# Number of moments representing beam divergence (x, y, xy, etc.) -# -# -# -# Properties of the neutron or X-ray beam at a given location. -# -# This group is intended to be referenced -# by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is -# especially valuable in storing the results of instrument simulations in which it is useful -# to specify the beam profile, time distribution etc. at each beamline component. Otherwise, -# its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron -# scattering by the sample, e.g., energy transfer, polarizations. -# -# Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. -# To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred -# by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. -# -# -# Distance from sample. Note, it is recommended to use NXtransformations instead. -# -# -# Energy carried by each particle of the beam on entering the beamline component -# -# -# -# -# -# Energy carried by each particle of the beam on leaving the beamline component -# -# -# -# -# -# Change in particle energy caused by the beamline component -# -# -# -# -# -# -# In the case of a monochromatic beam this is the scalar -# wavelength. -# -# Several other use cases are permitted, depending on the -# presence or absence of other incident_wavelength_X -# fields. -# -# In the case of a polychromatic beam this is an array of -# length **m** of wavelengths, with the relative weights -# in ``incident_wavelength_weights``. -# -# In the case of a monochromatic beam that varies shot- -# to-shot, this is an array of wavelengths, one for each -# recorded shot. Here, ``incident_wavelength_weights`` and -# incident_wavelength_spread are not set. -# -# In the case of a polychromatic beam that varies shot-to- -# shot, this is an array of length **m** with the relative -# weights in ``incident_wavelength_weights`` as a 2D array. -# -# In the case of a polychromatic beam that varies shot-to- -# shot and where the channels also vary, this is a 2D array -# of dimensions **nP** by **m** (slow to fast) with the -# relative weights in ``incident_wavelength_weights`` as a 2D -# array. -# -# Note, :ref:`variants <Design-Variants>` are a good way -# to represent several of these use cases in a single dataset, -# e.g. if a calibrated, single-value wavelength value is -# available along with the original spectrum from which it -# was calibrated. -# Wavelength on entering beamline component -# -# -# -# -# In the case of a polychromatic beam this is an array of -# length **m** of the relative weights of the corresponding -# wavelengths in ``incident_wavelength``. -# -# In the case of a polychromatic beam that varies shot-to- -# shot, this is a 2D array of dimensions **nP** by **m** -# (slow to fast) of the relative weights of the -# corresponding wavelengths in ``incident_wavelength``. -# -# -# -# -# The wavelength spread FWHM for the corresponding -# wavelength(s) in incident_wavelength. -# -# In the case of shot-to-shot variation in the wavelength -# spread, this is a 2D array of dimension **nP** by -# **m** (slow to fast) of the spreads of the -# corresponding wavelengths in incident_wavelength. -# -# -# -# -# -# -# -# Beam crossfire in degrees parallel to the laboratory X axis -# -# The dimension **c** is a series of moments of that represent -# the standard uncertainty (e.s.d.) of the directions of -# of the beam. The first and second moments are in the XZ and YZ -# planes around the mean source beam direction, respectively. -# -# Further moments in **c** characterize co-variance terms, so -# the next moment is the product of the first two, and so on. -# -# -# -# -# -# -# -# -# Size of the beam entering this component. Note this represents -# a rectangular beam aperture, and values represent FWHM -# -# -# -# -# -# -# -# Wavelength on leaving beamline component -# -# -# -# -# -# Polarization vector on entering beamline component -# -# -# -# -# -# -# Polarization vector on leaving beamline component -# -# -# -# -# -# -# -# Polarization vector on entering beamline component using Stokes notation -# -# The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. -# These are defined with the standard Nexus coordinate frame unless it is -# overridden by an NXtransformations field pointed to by a depends_on attribute. -# The last component, describing the circular polarization state, is positive -# for a right-hand circular state - that is the electric field vector rotates -# clockwise at the sample and over time when observed from the source. -# -# I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale -# linearly with the total degree of polarization, and indicate the relative -# magnitudes of the pure linear and circular orientation contributions. -# -# Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). -# -# U (S_2) is linearly polarized along the x==y axis (U > 0) or the -# -x==y axis (U < 0). -# -# V (S_3) is circularly polarized. V > 0 when the electric field vector rotates -# clockwise at the sample with respect to time when observed from the source; -# V < 0 indicates the opposite rotation. -# -# -# -# -# -# -# -# -# Polarization vector on leaving beamline component using Stokes notation -# (see incident_polarization_stokes). -# -# -# -# -# -# -# -# Wavelength spread FWHM of beam leaving this component -# -# -# -# -# -# Divergence FWHM of beam leaving this component -# -# -# -# -# -# -# flux incident on beam plane area -# -# -# -# -# -# -# Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly -# useful for simulations which need to store plottable information at each beamline -# component. -# -# -# -# .. 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. -# -# -# -# -# -# The NeXus coordinate system defines the Z axis to be along the nominal beam -# direction. This is the same as the McStas coordinate system (see :ref:Design-CoordinateSystem). -# However, the additional transformations needed to represent an altered beam -# direction can be provided using this depends_on field that contains the path -# to a NXtransformations group. This could represent redirection of the beam, -# or a refined beam direction. -# -# -# -# -# -# Direction (and location) for the beam. The location of the beam can be given by -# any point which it passes through as its offset attribute. -# -# -# -# Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] -# and passes through the origin -# -# -# -# -# -# -# -# -# Three values that define the direction of beam vector -# -# -# -# -# Three values that define the location of a point through which the beam passes -# -# -# -# -# Points to the path to a field defining the location on which this -# depends or the string "." for origin. -# -# -# -# -# -# Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. -# This also defines the parallel and perpendicular components of the beam's polarization. -# If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin -# -# -# -# -# -# -# -# -# Three values that define the direction of reference plane normal -# -# -# -# -# Not required as beam direction offset locates the plane -# -# -# -# -# Points to the path to a field defining the location on which this -# depends or the string "." for origin. -# -# -# -# -# diff --git a/base_classes/nyaml/NXbeam_stop.yaml b/base_classes/nyaml/NXbeam_stop.yaml deleted file mode 100644 index 66dce02e76..0000000000 --- a/base_classes/nyaml/NXbeam_stop.yaml +++ /dev/null @@ -1,207 +0,0 @@ -category: base -doc: | - A device that blocks the beam completely, usually to protect a detector. - - Beamstops and their positions are important for SANS - and SAXS experiments. -type: group -NXbeam_stop(NXobject): - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - engineering shape, orientation and position of the beam stop. - description: - doc: | - description of beamstop - enumeration: [circular, rectangular] - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - (NXcylindrical_geometry): - exists: ['min', '0'] - doc: | - This group is an alternative to NXoff_geometry for describing the shape - of the beam stop. - size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of beamstop. If this is not sufficient to describe the beam stop use - NXoff_geometry instead. - x(NX_FLOAT): - unit: NX_LENGTH - doc: | - x position of the beamstop in relation to the detector. - Note, it is recommended to use NXtransformations instead. - y(NX_FLOAT): - unit: NX_LENGTH - doc: | - y position of the beamstop in relation to the detector. - Note, it is recommended to use NXtransformations instead. - distance_to_detector(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance of the beamstop to the detector. - Note, it is recommended to use NXtransformations instead. - status: - enumeration: [in, out] - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the beam stop is its center in the x and y axis. The reference point on the z axis is the - surface of the beam stop pointing towards the source. - - .. image:: beam_stop/beam_stop.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 12ffb3bfff4f698d340f6bd19e4df67375c04a820ab060003e37688de3649898 -# -# -# -# -# -# -# A device that blocks the beam completely, usually to protect a detector. -# -# Beamstops and their positions are important for SANS -# and SAXS experiments. -# -# -# engineering shape, orientation and position of the beam stop. -# -# -# description of beamstop -# -# -# -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# This group is an alternative to NXoff_geometry for describing the shape -# of the beam stop. -# -# -# -# -# Size of beamstop. If this is not sufficient to describe the beam stop use -# NXoff_geometry instead. -# -# -# -# -# x position of the beamstop in relation to the detector. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# y position of the beamstop in relation to the detector. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# distance of the beamstop to the detector. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the beam stop is its center in the x and y axis. The reference point on the z axis is the -# surface of the beam stop pointing towards the source. -# -# .. image:: beam_stop/beam_stop.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXbending_magnet.yaml b/base_classes/nyaml/NXbending_magnet.yaml deleted file mode 100644 index 27f0ede6c1..0000000000 --- a/base_classes/nyaml/NXbending_magnet.yaml +++ /dev/null @@ -1,210 +0,0 @@ -category: base -doc: | - A bending magnet -type: group -NXbending_magnet(NXobject): - critical_energy(NX_FLOAT): - unit: NX_ENERGY - bending_radius(NX_FLOAT): - unit: NX_LENGTH - magnetic_field(NX_FLOAT): - unit: NX_CURRENT - doc: | - strength of magnetic field of dipole magnets - accepted_photon_beam_divergence(NX_FLOAT): - unit: NX_LENGTH - doc: | - An array of four numbers giving X+, X-, Y+ and Y- half divergence - source_distance_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance of source point from particle beam waist in X (horizontal) direction. - Note, it is recommended to use NXtransformations instead to place component. - source_distance_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance of source point from particle beam waist in Y (vertical) direction. - Note, it is recommended to use NXtransformations instead to place component. - divergence_x_plus(NX_FLOAT): - unit: NX_ANGLE - doc: | - Accepted photon beam divergence in X+ (horizontal outboard) direction. - Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. - divergence_x_minus(NX_FLOAT): - unit: NX_ANGLE - doc: | - Accepted photon beam divergence in X- (horizontal inboard) direction. - Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. - divergence_y_plus(NX_FLOAT): - unit: NX_ANGLE - doc: | - Accepted photon beam divergence in Y+ (vertical upward) direction. - Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. - divergence_y_minus(NX_FLOAT): - unit: NX_ANGLE - doc: | - Accepted photon beam divergence in Y- (vertical downward) direction. - Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. - spectrum(NXdata): - doc: | - bending magnet spectrum - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the bending magnet and NXoff_geometry to describe its shape instead - doc: | - "Engineering" position of bending magnet - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a bending magnet. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5b08a03dc9eadb728c7fcdf02c9c74bc20f04e7f6bfe6ed0f8bef2f20c5e1d83 -# -# -# -# -# -# A bending magnet -# -# -# -# strength of magnetic field of dipole magnets -# -# -# -# An array of four numbers giving X+, X-, Y+ and Y- half divergence -# -# -# -# -# Distance of source point from particle beam waist in X (horizontal) direction. -# Note, it is recommended to use NXtransformations instead to place component. -# -# -# -# -# Distance of source point from particle beam waist in Y (vertical) direction. -# Note, it is recommended to use NXtransformations instead to place component. -# -# -# -# -# Accepted photon beam divergence in X+ (horizontal outboard) direction. -# Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. -# -# -# -# -# Accepted photon beam divergence in X- (horizontal inboard) direction. -# Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. -# -# -# -# -# Accepted photon beam divergence in Y+ (vertical upward) direction. -# Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. -# -# -# -# -# Accepted photon beam divergence in Y- (vertical downward) direction. -# Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. -# -# -# bending magnet spectrum -# "Engineering" position of bending magnet -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a bending magnet. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXcapillary.yaml b/base_classes/nyaml/NXcapillary.yaml deleted file mode 100644 index aacb021fd6..0000000000 --- a/base_classes/nyaml/NXcapillary.yaml +++ /dev/null @@ -1,163 +0,0 @@ -category: base -doc: | - A capillary lens to focus the X-ray beam. - - Based on information provided by Gerd Wellenreuther (DESY). -type: group -NXcapillary(NXobject): - type(NX_CHAR): - doc: | - Type of the capillary - enumeration: [single_bounce, polycapillary, conical_capillary] - manufacturer(NX_CHAR): - doc: | - The manufacturer of the capillary. This is actually important as - it may have an impact on performance. - maximum_incident_angle(NX_FLOAT): - unit: NX_ANGLE - accepting_aperture(NX_FLOAT): - unit: NX_ANGLE - (NXdata)gain: - doc: | - The gain of the capillary as a function of energy - (NXdata)transmission: - doc: | - The transmission of the capillary as a function of energy - working_distance(NX_FLOAT): - unit: NX_LENGTH - focal_size(NX_FLOAT): - doc: | - The focal size in FWHM - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a capillary lens. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 532702bd23065d69a03c9e0b7aaf7136d411799faab901669a8be1f5d007b6c9 -# -# -# -# -# -# -# A capillary lens to focus the X-ray beam. -# -# Based on information provided by Gerd Wellenreuther (DESY). -# -# -# Type of the capillary -# -# -# -# -# -# -# -# -# The manufacturer of the capillary. This is actually important as -# it may have an impact on performance. -# -# -# -# -# -# -# The gain of the capillary as a function of energy -# -# -# -# -# The transmission of the capillary as a function of energy -# -# -# -# -# -# The focal size in FWHM -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a capillary lens. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXcite.yaml b/base_classes/nyaml/NXcite.yaml deleted file mode 100644 index d183f1fd89..0000000000 --- a/base_classes/nyaml/NXcite.yaml +++ /dev/null @@ -1,112 +0,0 @@ -category: base -doc: | - A literature reference - - Definition to include references for example for detectors, - manuals, instruments, acquisition or analysis software used. - - The idea would be to include this in the relevant NeXus object: - :ref:`NXdetector` for detectors, :ref:`NXinstrument` for instruments, etc. -type: group -NXcite(NXobject): - description(NX_CHAR): - doc: | - This should describe the reason for including this reference. - For example: The dataset in this group was normalised using the method - which is described in detail in this reference. - url(NX_CHAR): - doc: | - URL referencing the document or data. - doi(NX_CHAR): - doc: | - DOI referencing the document or data. - endnote(NX_CHAR): - doc: | - Bibliographic reference data in EndNote format. - bibtex(NX_CHAR): - doc: | - Bibliographic reference data in BibTeX format. - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 59929309fbee197465213bc3b923e04782d370b2058f5a970b41ecf71e85ba7a -# -# -# -# -# -# A literature reference -# -# Definition to include references for example for detectors, -# manuals, instruments, acquisition or analysis software used. -# -# The idea would be to include this in the relevant NeXus object: -# :ref:`NXdetector` for detectors, :ref:`NXinstrument` for instruments, etc. -# -# -# -# This should describe the reason for including this reference. -# For example: The dataset in this group was normalised using the method -# which is described in detail in this reference. -# -# -# -# URL referencing the document or data. -# -# -# DOI referencing the document or data. -# -# -# Bibliographic reference data in EndNote format. -# -# -# Bibliographic reference data in BibTeX format. -# -# -# -# .. 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/nyaml/NXcollection.yaml b/base_classes/nyaml/NXcollection.yaml deleted file mode 100644 index 5b3dd56a28..0000000000 --- a/base_classes/nyaml/NXcollection.yaml +++ /dev/null @@ -1,102 +0,0 @@ -category: base - -# The ignoreExtra* attributes are used in the definition to -# avoid warning messages that would be generated from -# unexpected groups, fields, and attributes. -# Since no groups or attributes are declared here, _every_ -# child of this class would generate a warning message without this -# attribute being set to "true". -doc: | - An unvalidated set of terms, such as the description of a beam line. - - Use :ref:`NXcollection` to gather together any set of terms. - The original suggestion is to use this as a container - class for the description of a beamline. - - For NeXus validation, :ref:`NXcollection` will always generate - a warning since it is always an optional group. - Anything (groups, fields, or attributes) placed in - an :ref:`NXcollection` group will not be validated. -type: group -ignoreExtraGroups: true -ignoreExtraFields: true -ignoreExtraAttributes: true -NXcollection(NXobject): - - # any content is purely optional - - # NOTE - # ===== - # NXcollection is an unvalidated class, do not add any subgroups. - # See: https://github.com/nexusformat/definitions/issues/259 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fdd5367211b59613e74b746761c655ba70f7ae36889538b8eec14fd904748fbf -# -# -# -# -# -# -# -# -# An unvalidated set of terms, such as the description of a beam line. -# -# Use :ref:`NXcollection` to gather together any set of terms. -# The original suggestion is to use this as a container -# class for the description of a beamline. -# -# For NeXus validation, :ref:`NXcollection` will always generate -# a warning since it is always an optional group. -# Anything (groups, fields, or attributes) placed in -# an :ref:`NXcollection` group will not be validated. -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXcollimator.yaml b/base_classes/nyaml/NXcollimator.yaml deleted file mode 100644 index acb4eeadfa..0000000000 --- a/base_classes/nyaml/NXcollimator.yaml +++ /dev/null @@ -1,196 +0,0 @@ -category: base -doc: | - A beamline collimator. -type: group -NXcollimator(NXobject): - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the collimator and NXoff_geometry to describe its shape instead - doc: | - position, shape and size - type: - enumeration: [Soller, radial, oscillating, honeycomb] - soller_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angular divergence of Soller collimator - divergence_x(NX_FLOAT): - unit: NX_ANGLE - doc: | - divergence of collimator in local x direction - divergence_y(NX_FLOAT): - unit: NX_ANGLE - doc: | - divergence of collimator in local y direction - frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency of oscillating collimator - (NXlog)frequency_log: - doc: | - Log of frequency - blade_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - blade thickness - blade_spacing(NX_FLOAT): - unit: NX_LENGTH - doc: | - blade spacing - absorbing_material: - doc: | - name of absorbing material - transmitting_material: - doc: | - name of transmitting material - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - Assuming a collimator with a "flat" entry surface, the reference plane is the plane which contains this surface. The reference - point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal - to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. - - .. image:: collimator/collimator.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 31140b43aa9a6a9240721e618335165197faeb7dfa4d21a1148482759ac5a53f -# -# -# -# -# -# A beamline collimator. -# -# position, shape and size -# -# -# -# -# -# -# -# -# -# -# Angular divergence of Soller collimator -# -# -# divergence of collimator in local x direction -# -# -# divergence of collimator in local y direction -# -# -# Frequency of oscillating collimator -# -# -# Log of frequency -# -# -# blade thickness -# -# -# blade spacing -# -# -# name of absorbing material -# -# -# name of transmitting material -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# Assuming a collimator with a "flat" entry surface, the reference plane is the plane which contains this surface. The reference -# point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal -# to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. -# -# .. image:: collimator/collimator.png -# :width: 40% -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXcrystal.yaml b/base_classes/nyaml/NXcrystal.yaml deleted file mode 100644 index 1da2f240db..0000000000 --- a/base_classes/nyaml/NXcrystal.yaml +++ /dev/null @@ -1,667 +0,0 @@ -category: base -doc: | - A crystal monochromator or analyzer. - - Permits double bent - monochromator comprised of multiple segments with anisotropic - Gaussian mosaic. - - If curvatures are set to zero or are absent, array - is considered to be flat. - - Scattering vector is perpendicular to surface. Crystal is oriented - parallel to beam incident on crystal before rotation, and lies in - vertical plane. -symbols: - doc: | - These symbols will be used below to coordinate dimensions with the same lengths. - n_comp: | - number of different unit cells to be described - i: | - number of wavelengths -type: group -NXcrystal(NXobject): - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the crystal and NXoff_geometry to describe its shape instead - doc: | - Position of crystal - usage(NX_CHAR): - doc: | - How this crystal is used. Choices are in the list. - enumeration: - Bragg: - doc: | - reflection geometry - Laue: - doc: | - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - * 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. - This is the *Hill* system used by Chemical Abstracts. - See, for example: - http://www.iucr.org/__data/iucr/cif/standard/cifstd15.html or - http://www.cas.org/training/stneasytips/subinforformula1.html. - type: - doc: | - Type or material of monochromating substance. - Chemical formula can be specified separately. - Use the "reflection" field to indicate the (hkl) orientation. - Use the "d_spacing" field to record the lattice plane spacing. - - This field was changed (2010-11-17) from an enumeration to - a string since common usage showed a wider variety of use - than a simple list. These are the items in the list at - the time of the change: PG (Highly Oriented Pyrolytic Graphite) | - Ge | Si | Cu | Fe3Si | CoFe | Cu2MnAl (Heusler) | Multilayer | - Diamond. - chemical_formula: - - # copied from NXsample - doc: | - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * 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. - * This is the *Hill* system used by Chemical Abstracts. - order_no(NX_INT): - doc: | - A number which describes if this is the first, second,.. - :math:`n^{th}` crystal in a multi crystal monochromator - cut_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Cut angle of reflecting Bragg plane and plane of crystal surface - space_group: - doc: | - Space group of crystal structure - unit_cell(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell parameters (lengths and angles) - dimensions: - rank: 2 - dim: [[1, n_comp], [2, 6]] - - # NXfilter defines each unit cell parameter separately. Let's be consistent. - unit_cell_a(NX_FLOAT): - unit: NX_LENGTH - - # as used in NXfilter - doc: | - Unit cell lattice parameter: length of side a - unit_cell_b(NX_FLOAT): - unit: NX_LENGTH - - # as used in NXfilter - doc: | - Unit cell lattice parameter: length of side b - unit_cell_c(NX_FLOAT): - unit: NX_LENGTH - - # as used in NXfilter - doc: | - Unit cell lattice parameter: length of side c - unit_cell_alpha(NX_FLOAT): - unit: NX_ANGLE - - # as used in NXfilter - doc: | - Unit cell lattice parameter: angle alpha - unit_cell_beta(NX_FLOAT): - unit: NX_ANGLE - - # as used in NXfilter - doc: | - Unit cell lattice parameter: angle beta - unit_cell_gamma(NX_FLOAT): - unit: NX_ANGLE - - # as used in NXfilter - doc: | - Unit cell lattice parameter: angle gamma - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 2 - - # 3,3 - dim: [[1, 3], [2, 3]] - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Optimum diffracted wavelength - dimensions: - dim: [[1, i]] - d_spacing(NX_FLOAT): - unit: NX_LENGTH - doc: | - spacing between crystal planes of the reflection - scattering_vector(NX_FLOAT): - unit: NX_WAVENUMBER - doc: | - Scattering vector, Q, of nominal reflection - reflection(NX_INT): - unit: NX_UNITLESS - doc: | - Miller indices (hkl) values of nominal reflection - dimensions: - dim: [[1, 3]] - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the crystal. (Required for Laue orientations - see "usage" field) - density(NX_NUMBER): - unit: NX_MASS_DENSITY - doc: | - mass density of the crystal - segment_width(NX_FLOAT): - unit: NX_LENGTH - doc: | - Horizontal width of individual segment - segment_height(NX_FLOAT): - unit: NX_LENGTH - doc: | - Vertical height of individual segment - segment_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of individual segment - segment_gap(NX_FLOAT): - unit: NX_LENGTH - doc: | - Typical gap between adjacent segments - segment_columns(NX_FLOAT): - unit: NX_LENGTH - doc: | - number of segment columns in horizontal direction - segment_rows(NX_FLOAT): - unit: NX_LENGTH - doc: | - number of segment rows in vertical direction - mosaic_horizontal(NX_FLOAT): - unit: NX_ANGLE - doc: | - horizontal mosaic Full Width Half Maximum - mosaic_vertical(NX_FLOAT): - unit: NX_ANGLE - doc: | - vertical mosaic Full Width Half Maximum - curvature_horizontal(NX_FLOAT): - unit: NX_ANGLE - doc: | - Horizontal curvature of focusing crystal - curvature_vertical(NX_FLOAT): - unit: NX_ANGLE - doc: | - Vertical curvature of focusing crystal - is_cylindrical(NX_BOOLEAN): - doc: | - Is this crystal bent cylindrically? - cylindrical_orientation_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - If cylindrical: cylinder orientation angle - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Polar (scattering) angle at which crystal assembly is positioned. - Note: some instrument geometries call this term 2theta. - Note: it is recommended to use NXtransformations instead. - dimensions: - dim: [[1, i]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Azimuthal angle at which crystal assembly is positioned. - Note: it is recommended to use NXtransformations instead. - dimensions: - dim: [[1, i]] - bragg_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bragg angle of nominal reflection - dimensions: - dim: [[1, i]] - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - average/nominal crystal temperature - temperature_coefficient(NX_FLOAT): - unit: NX_ANY - doc: | - how lattice parameter changes with temperature - (NXlog)temperature_log: - doc: | - log file of crystal temperature - (NXdata)reflectivity: - doc: | - crystal reflectivity versus wavelength - (NXdata)transmission: - doc: | - crystal transmission versus wavelength - (NXshape)shape: - deprecated: Use NXoff_geometry instead to describe the shape of the monochromator - doc: | - A NXshape group describing the shape of the crystal arrangement - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a crystal. - (NXtransformations): - doc: | - Transformations used by this component to define its position and orientation. - - # TODO need more parameters here, such as ... - # list from Rainer Gehrke, DESY (some items may already be present) - # Parameters for crystals - # + Field indicating whether it is Bragg or Laue see usage - # + The crystal structure (enumeration, e.g. Zincblende ..) see space_group - # + Lattice constant see unit_cell - # + Miller indices of reflection (h,k,l) see reflection - # + First (or only) element see order_no - # + Second element (if any) see order_no - # + Temperature factor (optional) see temperature_coefficient - # + Asymmetric angle (if applicable) see cut_angle - # + Mosaic angular spread (if applicable) see mosaic_horizontal and mosaic_vertical - # + Thickness (mandatory for Laue, else optional) see thickness - # Figure for crystals and mirrors (to describe curved surfaces) - # + Field indicating whether concave or convex see curvature_horizontal and curvature_vertical - # + Field indicating whether cylindrical or not see is_cylindrical - # + If cylindrical: cylinder orientation angle see cylindrical_orientation_angle - # Now come the different surface figures with the necessary parameters: - # 1. Flat - # 2. Spherical (spherical radius) - # 3. Elliptical and hyperbolical (semi-major axis, semi-minor axis, angle of major axis and pole) - # 4. Toroidal (major radius, minor radius) - # 5. Parabolical (parabolic parameter a) - # 6. Conical (cone half aperture) - # 7. Polynomial (degree of polynom, array with polynom coefficients) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2c8bcd2e0d1e3ecfb4be342deda56a44c3eb68d3f599c9ccd75b07761254f7b1 -# -# -# -# -# -# -# These symbols will be used below to coordinate dimensions with the same lengths. -# number of different unit cells to be described -# number of wavelengths -# -# -# -# A crystal monochromator or analyzer. -# -# Permits double bent -# monochromator comprised of multiple segments with anisotropic -# Gaussian mosaic. -# -# If curvatures are set to zero or are absent, array -# is considered to be flat. -# -# Scattering vector is perpendicular to surface. Crystal is oriented -# parallel to beam incident on crystal before rotation, and lies in -# vertical plane. -# -# -# -# Position of crystal -# -# -# How this crystal is used. Choices are in the list. -# -# reflection geometry -# -# -# The chemical formula specified using CIF conventions. -# Abbreviated version of CIF standard: -# * 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. -# This is the *Hill* system used by Chemical Abstracts. -# See, for example: -# http://www.iucr.org/__data/iucr/cif/standard/cifstd15.html or -# http://www.cas.org/training/stneasytips/subinforformula1.html. -# -# -# -# -# -# -# Type or material of monochromating substance. -# Chemical formula can be specified separately. -# Use the "reflection" field to indicate the (hkl) orientation. -# Use the "d_spacing" field to record the lattice plane spacing. -# -# This field was changed (2010-11-17) from an enumeration to -# a string since common usage showed a wider variety of use -# than a simple list. These are the items in the list at -# the time of the change: PG (Highly Oriented Pyrolytic Graphite) | -# Ge | Si | Cu | Fe3Si | CoFe | Cu2MnAl (Heusler) | Multilayer | -# Diamond. -# -# -# -# -# -# The chemical formula specified using CIF conventions. -# Abbreviated version of CIF standard: -# -# * 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. -# * This is the *Hill* system used by Chemical Abstracts. -# -# -# -# -# A number which describes if this is the first, second,.. -# :math:`n^{th}` crystal in a multi crystal monochromator -# -# -# -# Cut angle of reflecting Bragg plane and plane of crystal surface -# -# -# Space group of crystal structure -# -# -# Unit cell parameters (lengths and angles) -# -# -# -# -# -# -# -# Unit cell lattice parameter: length of side a -# -# -# Unit cell lattice parameter: length of side b -# -# -# Unit cell lattice parameter: length of side c -# -# -# Unit cell lattice parameter: angle alpha -# -# -# Unit cell lattice parameter: angle beta -# -# -# Unit cell lattice parameter: angle gamma -# -# -# Volume of the unit cell -# -# -# -# Orientation matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# Optimum diffracted wavelength -# -# -# -# spacing between crystal planes of the reflection -# -# -# Scattering vector, Q, of nominal reflection -# -# -# Miller indices (hkl) values of nominal reflection -# -# -# -# Thickness of the crystal. (Required for Laue orientations - see "usage" field) -# -# -# mass density of the crystal -# -# -# Horizontal width of individual segment -# -# -# Vertical height of individual segment -# -# -# Thickness of individual segment -# -# -# Typical gap between adjacent segments -# -# -# number of segment columns in horizontal direction -# -# -# number of segment rows in vertical direction -# -# -# horizontal mosaic Full Width Half Maximum -# -# -# vertical mosaic Full Width Half Maximum -# -# -# Horizontal curvature of focusing crystal -# -# -# Vertical curvature of focusing crystal -# -# -# Is this crystal bent cylindrically? -# -# -# If cylindrical: cylinder orientation angle -# -# -# -# Polar (scattering) angle at which crystal assembly is positioned. -# Note: some instrument geometries call this term 2theta. -# Note: it is recommended to use NXtransformations instead. -# -# -# -# -# -# Azimuthal angle at which crystal assembly is positioned. -# Note: it is recommended to use NXtransformations instead. -# -# -# -# -# Bragg angle of nominal reflection -# -# -# -# average/nominal crystal temperature -# -# -# how lattice parameter changes with temperature -# -# -# log file of crystal temperature -# -# -# crystal reflectivity versus wavelength -# -# -# crystal transmission versus wavelength -# -# -# A NXshape group describing the shape of the crystal arrangement -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a crystal. -# -# -# -# -# Transformations used by this component to define its position and orientation. -# -# -# -# diff --git a/base_classes/nyaml/NXcylindrical_geometry.yaml b/base_classes/nyaml/NXcylindrical_geometry.yaml deleted file mode 100644 index 189ede84aa..0000000000 --- a/base_classes/nyaml/NXcylindrical_geometry.yaml +++ /dev/null @@ -1,169 +0,0 @@ -category: base -doc: | - Geometry description for cylindrical shapes. - This class can be used in place of ``NXoff_geometry`` when an exact - representation for cylinders is preferred. - For example, for Helium-tube, neutron detectors. - It can be used to describe the shape of any beamline component, including detectors. - In the case of detectors it can be used to define the shape of a single pixel, or, - if the pixel shapes are non-uniform, to describe the shape of the whole detector. -symbols: - doc: | - These symbols will be used below. - i: | - number of vertices required to define all cylinders in the shape - j: | - number of cylinders in the shape - k: | - number cylinders which are detectors -type: group -NXcylindrical_geometry(NXobject): - vertices(NX_NUMBER): - unit: NX_LENGTH - doc: | - List of x,y,z coordinates for vertices. - The origin of the coordinates is the position of the parent component, for - example the NXdetector which the geometry describes. - If the shape describes a single pixel for a detector with uniform pixel shape - then the origin is the position of each pixel as described by the - ``x/y/z_pixel_offset`` datasets in ``NXdetector``. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - cylinders(NX_INT): - doc: | - List of indices of vertices in the ``vertices`` dataset to form each cylinder. - Each cylinder is described by three vertices A, B, C. - First vertex A lies on the cylinder axis and circular face, second point B - on edge of the same face as A, and third point C at the other face and on axis. - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - detector_number(NX_INT): - doc: | - Maps cylinders in ``cylinder``, by index, with a detector id. - dimensions: - rank: 1 - dim: [[1, k]] - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9bbcf1ff2b2841c8960f59949dfb345ca6966cd04ab611c7e9843c1c81d643e6 -# -# -# -# -# -# -# These symbols will be used below. -# -# -# number of vertices required to define all cylinders in the shape -# -# -# number of cylinders in the shape -# number cylinders which are detectors -# -# -# -# Geometry description for cylindrical shapes. -# This class can be used in place of ``NXoff_geometry`` when an exact -# representation for cylinders is preferred. -# For example, for Helium-tube, neutron detectors. -# It can be used to describe the shape of any beamline component, including detectors. -# In the case of detectors it can be used to define the shape of a single pixel, or, -# if the pixel shapes are non-uniform, to describe the shape of the whole detector. -# -# -# -# -# -# List of x,y,z coordinates for vertices. -# The origin of the coordinates is the position of the parent component, for -# example the NXdetector which the geometry describes. -# If the shape describes a single pixel for a detector with uniform pixel shape -# then the origin is the position of each pixel as described by the -# ``x/y/z_pixel_offset`` datasets in ``NXdetector``. -# -# -# -# -# -# -# -# -# -# -# -# -# List of indices of vertices in the ``vertices`` dataset to form each cylinder. -# Each cylinder is described by three vertices A, B, C. -# First vertex A lies on the cylinder axis and circular face, second point B -# on edge of the same face as A, and third point C at the other face and on axis. -# -# -# -# -# -# -# -# -# -# -# -# Maps cylinders in ``cylinder``, by index, with a detector id. -# -# -# -# -# -# -# -# -# .. 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/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml deleted file mode 100644 index cc56a0676b..0000000000 --- a/base_classes/nyaml/NXdata.yaml +++ /dev/null @@ -1,807 +0,0 @@ -category: base -doc: | - :ref:`NXdata` describes the plottable data and related dimension scales. - - .. index:: plotting - - It is strongly recommended that there is at least one :ref:`NXdata` - group in each :ref:`NXentry` group. - Note that the fields named ``AXISNAME`` and ``DATA`` - can be defined with different names. - (Upper case is used to indicate that the actual name is left to the user.) - The ``signal`` and ``axes`` attributes of the - ``data`` group define which items - are plottable data and which are *dimension scales*, respectively. - - :ref:`NXdata` is used to implement one of the basic motivations in NeXus, - to provide a default plot for the data of this :ref:`NXentry`. The actual data - might be stored in another group and (hard) linked to the :ref:`NXdata` group. - - * Each :ref:`NXdata` group will define one field as the default - plottable data. The value of the ``signal`` attribute names this field. - Additional fields may be used to describe the dimension scales and - uncertainities. - The ``auxiliary_signals`` attribute is a list of the other fields - to be plotted with the ``signal`` data. - * The plottable data may be of arbitrary rank up to a maximum - of ``NX_MAXRANK=32`` (for compatibility with backend file formats). - * The plottable data will be named as the value of - the group ``signal`` attribute, such as:: - - data:NXdata - @signal = "counts" - @axes = "mr" - @mr_indices = 0 - counts: float[100] --> the default dependent data - mr: float[100] --> the default independent data - - The field named in the ``signal`` attribute **must** exist, either - directly as a NeXus field or defined through a link. - - * The group ``axes`` attribute will name the - *dimension scale* associated with the plottable data. - - If available, the standard deviations of the data are to be - stored in a data set of the same rank and dimensions, with the name ``errors``. - - * For each data dimension, there should be a one-dimensional array - of the same length. - * These one-dimensional arrays are the *dimension scales* of the - data, *i.e*. the values of the independent variables at which the data - is measured, such as scattering angle or energy transfer. - - .. index:: link - .. index:: axes (attribute) - - The preferred method to associate each data dimension with - its respective dimension scale is to specify the field name - of each dimension scale in the group ``axes`` attribute as a string list. - Here is an example for a 2-D data set *data* plotted - against *time*, and *pressure*. (An additional *temperature* data set - is provided and could be selected as an alternate for the *pressure* axis.):: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @pressure_indices=1 - @temperature_indices=1 - @time_indices=0 - data: float[1000,20] - pressure: float[20] - temperature: float[20] - time: float[1000] - - .. rubric:: Old methods to identify the plottable data - - There are two older methods of associating - each data dimension to its respective dimension scale. - Both are now out of date and - should not be used when writing new data files. - However, client software should expect to see data files - written with any of these methods. - - * One method uses the ``axes`` - attribute to specify the names of each *dimension scale*. - - * The oldest method uses the ``axis`` attribute on each - *dimension scale* to identify - with an integer the axis whose value is the number of the dimension. - - .. index: !plot; axis label - plot, axis units - units - dimension scale - - Each axis of the plot may be labeled with information from the - dimension scale for that axis. The optional ``@long_name`` attribute - is provided as the axis label default. If ``@long_name`` is not - defined, then use the name of the dimension scale. A ``@units`` attribute, - if available, may be added to the axis label for further description. - See the section :ref:`Design-Units` for more information. - - .. index: !plot; axis title - - The optional ``title`` field, if available, provides a suggested - title for the plot. If no ``title`` field is found in the :ref:`NXdata` - group, look for a ``title`` field in the parent :ref:`NXentry` group, - with a fallback to displaying the path to the :ref:`NXdata` group. - - NeXus is about how to find and annotate the data to be plotted - but not to describe how the data is to be plotted. - (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) - -# The ignoreExtra* attributes are used in the definition to -# avoid warning messages that would be generated from unexpected fields or attributes. -# Since common use of NXdata indicates field names of any value, _many_ -# instances of this class would generate a warning message during validation -# without this attribute being set to "true". -symbols: - doc: | - These symbols will be used below to coordinate fields with the same shape. - dataRank: | - rank of the ``DATA`` field - n: | - length of the ``AXISNAME`` field - nx: | - length of the ``x`` field - ny: | - length of the ``y`` field - nz: | - length of the ``z`` field -type: group -ignoreExtraFields: true -ignoreExtraAttributes: true -NXdata(NXobject): - \@auxiliary_signals: - doc: | - .. index:: plotting - - Array of strings holding the :ref:`names ` of additional - signals to be plotted with the default :ref:`signal `. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html - \@signal: - doc: | - .. index:: find the default plottable data - .. index:: plotting - .. index:: signal attribute value - - Declares which NeXus field is the default. - The value is the :ref:`name ` of the data field to be plotted. - This field or link *must* exist and be a direct child of this NXdata group. - - It is recommended (as of NIAC2014) to use this attribute - rather than adding a signal attribute to the field. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - \@axes: - doc: | - .. index:: plotting - - Array of strings holding the :ref:`names ` of - the independent data fields used in the default plot for all of - the dimensions of the :ref:`signal ` - as well as any :ref:`auxiliary signals `. - - One name is provided for every dimension in the *signal* or *auxiliary signal* fields. - - The *axes* values are the names of fields or links that *must* exist and be direct - children of this NXdata group. - - An axis slice is specified using a field named ``AXISNAME_indices`` - as described below (where the text shown here as ``AXISNAME`` is to be - replaced by the actual field name). - - When no default axis is available for a particular dimension - of the plottable data, use a "." in that position. - Such as:: - - @axes=["time", ".", "."] - - Since there are three items in the list, the *signal* field - must be a three-dimensional array (rank=3). The first dimension - is described by the values of a one-dimensional array named ``time`` - while the other two dimensions have no fields to be used as dimension scales. - - See examples provided on the NeXus wiki: - https://www.nexusformat.org/2014_axes_and_uncertainties.html - - If there are no axes at all (such as with a stack of images), - the axes attribute can be omitted. - \@AXISNAME_indices: - type: NX_INT - - # nxdl.xsd rules do not allow us to show this as a variable name - # - we'll use ALL CAPS (see #562) - - # AXISNAME_indices documentation copied from datarules.rst - doc: | - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - AXISNAME(NX_NUMBER): - nameType: any - doc: | - Dimension scale defining an axis of the data. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - dimensions: - rank: 1 - doc: | - A *dimension scale* must have a rank of 1 and has length ``n``. - dim: [[1, n]] - \@long_name: - doc: | - Axis label - \@distribution: - type: NX_BOOLEAN - doc: | - ``0|false``: single value, - ``1|true``: multiple values - \@first_good: - type: NX_INT - doc: | - Index of first good value - \@last_good: - type: NX_INT - doc: | - Index of last good value - \@axis: - type: NX_POSINT - deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | - Index (positive integer) identifying this specific set of numbers. - - N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. - FIELDNAME_errors(NX_NUMBER): - nameType: any - doc: | - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. - DATA(NX_NUMBER): - nameType: any - doc: | - .. index:: plotting - - This field contains the data values to be used as the - NeXus *plottable data*. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - dimensions: - rank: dataRank - doc: | - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - dim: [] - \@signal: - type: NX_POSINT - deprecated: Use the group ``signal`` attribute (NIAC2014) - doc: | - .. index:: plotting - - Plottable (independent) axis, indicate index number. - Only one field in a :ref:`NXdata` group may have the - ``signal=1`` attribute. - Do not use the ``signal`` attribute with the ``axis`` attribute. - \@axes: - deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | - Defines the names of the dimension scales - (independent axes) for this data set - as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred - method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - \@long_name: - doc: | - data label - errors(NX_NUMBER): - deprecated: Use ``DATA_errors`` instead (NIAC2018) - doc: | - Standard deviations of data values - - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``DATA``. - Client is responsible for defining the dimensions of the data. - dimensions: - rank: dataRank - doc: | - The ``errors`` must have - the same rank (``dataRank``) - as the ``data``. - At least one ``dim`` must have length "n". - dim: [] - scaling_factor(NX_FLOAT): - doc: | - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. - offset(NX_FLOAT): - doc: | - An optional offset to apply to the values in data. - title: - doc: | - Title for the plot. - x(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nx]] - y(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, ny]] - z(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nz]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d6fe670cbf59475c1b29039a0baddf5bfef45444afa616430ef5d73b2465788c -# -# -# -# -# -# -# -# -# These symbols will be used below to coordinate fields with the same shape. -# rank of the ``DATA`` field -# length of the ``AXISNAME`` field -# length of the ``x`` field -# length of the ``y`` field -# length of the ``z`` field -# -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of additional -# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. -# These fields or links *must* exist and be direct children of this NXdata group. -# -# Each auxiliary signal needs to be of the same shape as the default signal. -# -# .. NIAC2018: -# https://www.nexusformat.org/NIAC2018Minutes.html -# -# -# -# -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: signal attribute value -# -# Declares which NeXus field is the default. -# The value is the :ref:`name <validItemName>` of the data field to be plotted. -# This field or link *must* exist and be a direct child of this NXdata group. -# -# It is recommended (as of NIAC2014) to use this attribute -# rather than adding a signal attribute to the field. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of -# the independent data fields used in the default plot for all of -# the dimensions of the :ref:`signal </NXdata@signal-attribute>` -# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. -# -# One name is provided for every dimension in the *signal* or *auxiliary signal* fields. -# -# The *axes* values are the names of fields or links that *must* exist and be direct -# children of this NXdata group. -# -# An axis slice is specified using a field named ``AXISNAME_indices`` -# as described below (where the text shown here as ``AXISNAME`` is to be -# replaced by the actual field name). -# -# When no default axis is available for a particular dimension -# of the plottable data, use a "." in that position. -# Such as:: -# -# @axes=["time", ".", "."] -# -# Since there are three items in the list, the *signal* field -# must be a three-dimensional array (rank=3). The first dimension -# is described by the values of a one-dimensional array named ``time`` -# while the other two dimensions have no fields to be used as dimension scales. -# -# See examples provided on the NeXus wiki: -# https://www.nexusformat.org/2014_axes_and_uncertainties.html -# -# If there are no axes at all (such as with a stack of images), -# the axes attribute can be omitted. -# -# -# -# -# -# -# Each ``AXISNAME_indices`` attribute indicates the dependency -# relationship of the ``AXISNAME`` field (where ``AXISNAME`` -# is the name of a field that exists in this ``NXdata`` group) -# with one or more dimensions of the plottable data. -# -# Integer array that defines the indices of the *signal* field -# (that field will be a multidimensional array) -# which need to be used in the *AXISNAME* field in -# order to reference the corresponding axis value. -# -# The first index of an array is ``0`` (zero). -# -# Here, *AXISNAME* is to be replaced by the name of each -# field described in the ``axes`` attribute. -# An example with 2-D data, :math:`d(t,P)`, will illustrate:: -# -# data_2d:NXdata -# @signal="data" -# @axes=["time", "pressure"] -# @time_indices=0 -# @pressure_indices=1 -# data: float[1000,20] -# time: float[1000] -# pressure: float[20] -# -# This attribute is to be provided in all situations. -# However, if the indices attributes are missing -# (such as for data files written before this specification), -# file readers are encouraged to make their best efforts -# to plot the data. -# Thus the implementation of the -# ``AXISNAME_indices`` attribute is based on the model of -# "strict writer, liberal reader". -# -# .. note:: Attributes potentially containing multiple values -# (axes and _indices) are to be written as string or integer arrays, -# to avoid string parsing in reading applications. -# -# -# -# -# :ref:`NXdata` describes the plottable data and related dimension scales. -# -# .. index:: plotting -# -# It is strongly recommended that there is at least one :ref:`NXdata` -# group in each :ref:`NXentry` group. -# Note that the fields named ``AXISNAME`` and ``DATA`` -# can be defined with different names. -# (Upper case is used to indicate that the actual name is left to the user.) -# The ``signal`` and ``axes`` attributes of the -# ``data`` group define which items -# are plottable data and which are *dimension scales*, respectively. -# -# :ref:`NXdata` is used to implement one of the basic motivations in NeXus, -# to provide a default plot for the data of this :ref:`NXentry`. The actual data -# might be stored in another group and (hard) linked to the :ref:`NXdata` group. -# -# * Each :ref:`NXdata` group will define one field as the default -# plottable data. The value of the ``signal`` attribute names this field. -# Additional fields may be used to describe the dimension scales and -# uncertainities. -# The ``auxiliary_signals`` attribute is a list of the other fields -# to be plotted with the ``signal`` data. -# * The plottable data may be of arbitrary rank up to a maximum -# of ``NX_MAXRANK=32`` (for compatibility with backend file formats). -# * The plottable data will be named as the value of -# the group ``signal`` attribute, such as:: -# -# data:NXdata -# @signal = "counts" -# @axes = "mr" -# @mr_indices = 0 -# counts: float[100] --> the default dependent data -# mr: float[100] --> the default independent data -# -# The field named in the ``signal`` attribute **must** exist, either -# directly as a NeXus field or defined through a link. -# -# * The group ``axes`` attribute will name the -# *dimension scale* associated with the plottable data. -# -# If available, the standard deviations of the data are to be -# stored in a data set of the same rank and dimensions, with the name ``errors``. -# -# * For each data dimension, there should be a one-dimensional array -# of the same length. -# * These one-dimensional arrays are the *dimension scales* of the -# data, *i.e*. the values of the independent variables at which the data -# is measured, such as scattering angle or energy transfer. -# -# .. index:: link -# .. index:: axes (attribute) -# -# The preferred method to associate each data dimension with -# its respective dimension scale is to specify the field name -# of each dimension scale in the group ``axes`` attribute as a string list. -# Here is an example for a 2-D data set *data* plotted -# against *time*, and *pressure*. (An additional *temperature* data set -# is provided and could be selected as an alternate for the *pressure* axis.):: -# -# data_2d:NXdata -# @signal="data" -# @axes=["time", "pressure"] -# @pressure_indices=1 -# @temperature_indices=1 -# @time_indices=0 -# data: float[1000,20] -# pressure: float[20] -# temperature: float[20] -# time: float[1000] -# -# .. rubric:: Old methods to identify the plottable data -# -# There are two older methods of associating -# each data dimension to its respective dimension scale. -# Both are now out of date and -# should not be used when writing new data files. -# However, client software should expect to see data files -# written with any of these methods. -# -# * One method uses the ``axes`` -# attribute to specify the names of each *dimension scale*. -# -# * The oldest method uses the ``axis`` attribute on each -# *dimension scale* to identify -# with an integer the axis whose value is the number of the dimension. -# -# .. index: !plot; axis label -# plot, axis units -# units -# dimension scale -# -# Each axis of the plot may be labeled with information from the -# dimension scale for that axis. The optional ``@long_name`` attribute -# is provided as the axis label default. If ``@long_name`` is not -# defined, then use the name of the dimension scale. A ``@units`` attribute, -# if available, may be added to the axis label for further description. -# See the section :ref:`Design-Units` for more information. -# -# .. index: !plot; axis title -# -# The optional ``title`` field, if available, provides a suggested -# title for the plot. If no ``title`` field is found in the :ref:`NXdata` -# group, look for a ``title`` field in the parent :ref:`NXentry` group, -# with a fallback to displaying the path to the :ref:`NXdata` group. -# -# NeXus is about how to find and annotate the data to be plotted -# but not to describe how the data is to be plotted. -# (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) -# -# -# -# Dimension scale defining an axis of the data. -# Client is responsible for defining the dimensions of the data. -# The name of this field may be changed to fit the circumstances. -# Standard NeXus client tools will use the attributes to determine -# how to use this field. -# -# -# -# A *dimension scale* must have a rank of 1 and has length ``n``. -# -# -# -# Axis label -# -# -# ``0|false``: single value, -# ``1|true``: multiple values -# -# -# Index of first good value -# Index of last good value -# -# -# Index (positive integer) identifying this specific set of numbers. -# -# N.B. The ``axis`` attribute is the old way of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# The ``axes`` *group* attribute is now preferred. -# -# -# -# -# -# "Errors" (meaning *uncertainties* or *standard deviations*) -# associated with any field named ``FIELDNAME`` in this ``NXdata`` -# group (e.g. an axis, signal or auxiliary signal). -# -# The dimensions of the ``FIELDNAME_errors`` field must match -# the dimensions of the ``FIELDNAME`` field. -# -# -# -# -# .. index:: plotting -# -# This field contains the data values to be used as the -# NeXus *plottable data*. -# Client is responsible for defining the dimensions of the data. -# The name of this field may be changed to fit the circumstances. -# Standard NeXus client tools will use the attributes to determine -# how to use this field. -# -# -# -# The rank (``dataRank``) of the ``data`` must satisfy -# ``1 <= dataRank <= NX_MAXRANK=32``. -# At least one ``dim`` must have length ``n``. -# -# -# -# -# .. index:: plotting -# -# Plottable (independent) axis, indicate index number. -# Only one field in a :ref:`NXdata` group may have the -# ``signal=1`` attribute. -# Do not use the ``signal`` attribute with the ``axis`` attribute. -# -# -# -# -# Defines the names of the dimension scales -# (independent axes) for this data set -# as a colon-delimited array. -# NOTE: The ``axes`` attribute is the preferred -# method of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# -# -# -# data label -# -# -# -# -# Standard deviations of data values - -# the data array is identified by the group attribute ``signal``. -# The ``errors`` array must have the same dimensions as ``DATA``. -# Client is responsible for defining the dimensions of the data. -# -# -# -# The ``errors`` must have -# the same rank (``dataRank``) -# as the ``data``. -# At least one ``dim`` must have length "n". -# -# -# -# -# -# The elements in data are usually float values really. For -# efficiency reasons these are usually stored as integers -# after scaling with a scale factor. This value is the scale -# factor. It is required to get the actual physical value, -# when necessary. -# -# -# -# -# An optional offset to apply to the values in data. -# -# -# -# -# Title for the plot. -# -# -# -# -# This is an array holding the values to use for the x-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the y-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the z-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml deleted file mode 100644 index 6e01f8adc6..0000000000 --- a/base_classes/nyaml/NXdetector.yaml +++ /dev/null @@ -1,1708 +0,0 @@ -category: base -doc: | - A detector, detector bank, or multidetector. -symbols: - doc: | - These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the - preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering principle is slowest to fastest. - The type of each dimension should follow the order of scan points, detector output (e.g. pixels), - then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited - to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced - by a detector at each trigger. - nP: | - number of scan points (only present in scanning measurements) - i: | - number of detector pixels in the first (slowest) direction - j: | - number of detector pixels in the second (faster) direction - k: | - number of detector pixels in the third (if necessary, fastest) - direction - tof: | - number of bins in the time-of-flight histogram -type: group -(NXobject)NXdetector: - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - doc: | - Total time of flight - dimensions: - rank: 1 - dim: [[1, tof+1]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [3] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - Total time of flight - raw_time_of_flight(NX_INT): - unit: NX_PULSES - doc: | - In DAQ clock pulses - dimensions: - rank: 1 - dim: [[1, tof+1]] - \@frequency: - type: NX_NUMBER - doc: | - Clock frequency in Hz - detector_number(NX_INT): - doc: | - Identifier for detector (pixels) - Can be multidimensional, if needed - data(NX_NUMBER): - unit: NX_ANY - doc: | - Data values from the detector. The rank and dimension ordering should follow a principle of - slowest to fastest measurement axes and may be explicitly specified in application definitions. - - Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be - the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions - of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single - scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. - Repetition of an experiment in a time series tends to be used similar to a slow scan axis - and so will often be in the first dimension of the data array. - - The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions - (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an - imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data - will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to - be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. - - Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift - detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. - - The type of each dimension should should follow the order of scan points, detector pixels, - then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) - shown here are merely illustrative of coordination between related datasets. - dimensions: - rank: 4 - dim: [[1, nP], [2, i], [3, j], [4, tof]] - \@long_name: - doc: | - Title of measurement - \@check_sum: - type: NX_INT - doc: | - Integral of data as check of data integrity - data_errors(NX_NUMBER): - unit: NX_ANY - doc: | - The best estimate of the uncertainty in the data value (array size should match the data field). Where - possible, this should be the standard deviation, which has the same units - as the data. The form data_error is deprecated. - dimensions: - rank: 4 - dim: [[1, nP], [2, i], [3, j], [4, tof]] - x_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in x-direction. - Can be multidimensional when needed. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - x-axis offset from detector center - y_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [2] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - y-axis offset from detector center - z_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [3] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - y-axis offset from detector center - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the distance to the previous component in the - instrument; most often the sample. The usage depends on the - nature of the detector: Most often it is the distance of the - detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - This is the polar angle of the detector towards the previous - component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the polar_angle of the detector assembly. - But there are irregular detectors. - In this - case, the polar_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - This is the azimuthal angle angle of the detector towards - the previous component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the azimuthal_angle of the detector assembly. - But there are irregular detectors. - In this - case, the azimuthal_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - description: - doc: | - name/manufacturer/model/etc. information - serial_number: - doc: | - Serial number for the detector - local_name: - doc: | - Local name for the detector - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead - doc: | - Position and orientation of detector - solid_angle(NX_FLOAT): - unit: NX_SOLID_ANGLE - doc: | - Solid angle subtended by the detector at the sample - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - dead_time(NX_FLOAT): - unit: NX_TIME - doc: | - Detector dead time - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Detector gas pressure - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - detection_gas_path(NX_FLOAT): - unit: NX_LENGTH - doc: | - maximum drift space dimension - crate(NX_INT): - doc: | - Crate number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - doc: | - Equivalent local term - slot(NX_INT): - doc: | - Slot number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - doc: | - Equivalent local term - input(NX_INT): - doc: | - Input number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - doc: | - Equivalent local term - type: - doc: | - Description of type such as He3 gas cylinder, He3 PSD, scintillator, - fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ... - efficiency(NXdata): - doc: | - Spectral efficiency of detector with respect to e.g. wavelength - \@signal: - enumeration: [efficiency] - \@axes: - - # TODO: clarify the various use cases - enumeration: [., . ., . . ., . . . ., wavelength] - \@wavelength_indices: - - # TODO: clarify the actual possibilities - enumeration: [0] - efficiency(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - efficiency of the detector - dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - This field can be two things: - - #. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - #. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] - real_time(NX_NUMBER): - unit: NX_TIME - doc: | - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - start_time(NX_FLOAT): - unit: NX_TIME - doc: | - start time for each frame, with the ``start`` attribute as absolute reference - dimensions: - rank: 1 - dim: [[1, nP]] - \@start: - type: NX_DATE_TIME - stop_time(NX_FLOAT): - unit: NX_TIME - doc: | - stop time for each frame, with the ``start`` attribute as absolute reference - dimensions: - rank: 1 - dim: [[1, nP]] - \@start: - type: NX_DATE_TIME - calibration_date(NX_DATE_TIME): - doc: | - date of last calibration (geometry and/or efficiency) measurements - calibration_method(NXnote): - doc: | - summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations - layout: - doc: | - How the detector is represented - enumeration: [point, linear, area] - count_time(NX_NUMBER): - unit: NX_TIME - doc: | - Elapsed actual counting time - dimensions: - rank: 1 - dim: [[1, nP]] - data_file(NXnote): - (NXcollection): - doc: | - Use this group to provide other data related to this NXdetector group. - sequence_number(NX_INT): - doc: | - In order to properly sort the order of the images taken in (for - example) a tomography experiment, a sequence number is stored with each - image. - dimensions: - rank: 1 - dim: [[1, nBrightFrames]] - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the x position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the y position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - frame_start_number(NX_INT): - doc: | - This is the start number of the first frame of a scan. In protein crystallography measurements one - often scans a couple of frames on a give sample, then does something else, - then returns to the same sample and scans some more frames. Each time with - a new data file. This number helps concatenating such measurements. - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - The diameter of a cylindrical detector - acquisition_mode(NX_CHAR): - doc: | - The acquisition mode of the detector. - enumeration: [gated, triggered, summed, event, histogrammed, decimated] - angular_calibration_applied(NX_BOOLEAN): - doc: | - True when the angular calibration has been applied in the - electronics, false otherwise. - angular_calibration(NX_FLOAT): - doc: | - Angular calibration data. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - flatfield_applied(NX_BOOLEAN): - doc: | - True when the flat field correction has been applied in the - electronics, false otherwise. - flatfield(NX_FLOAT): - doc: | - Flat field correction data. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - flatfield_errors(NX_FLOAT): - doc: | - Errors of the flat field correction data. - The form flatfield_error is deprecated. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - pixel_mask_applied(NX_BOOLEAN): - doc: | - True when the pixel mask correction has been applied in the - electronics, false otherwise. - pixel_mask(NX_INT): - doc: | - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - image_key(NX_INT): - doc: | - This field allow to distinguish different types of exposure to the same detector "data" field. - Some techniques require frequent (re-)calibration inbetween measuremnts and this way of - recording the different measurements preserves the chronological order with is important for - correct processing. - - This is used for example in tomography (`:ref:`NXtomo`) sample projections, - dark and flat images, a magic number is recorded per frame. - - The key is as follows: - - * projection (sample) = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - * background (no sample, but buffer where applicable) = 4 - - In cases where the data is of type :ref:`NXlog` this can also be an NXlog. - dimensions: - rank: 1 - dim: [[1, np]] - countrate_correction_applied(NX_BOOLEAN): - doc: | - Counting detectors usually are not able to measure all incoming particles, - especially at higher count-rates. Count-rate correction is applied to - account for these errors. - - True when count-rate correction has been applied, false otherwise. - countrate_correction_lookup_table(NX_NUMBER): - doc: | - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - dimensions: - rank: 1 - dim: [[1, m]] - virtual_pixel_interpolation_applied(NX_BOOLEAN): - doc: | - True when virtual pixel interpolation has been applied, false otherwise. - - When virtual pixel interpolation is applied, values of some pixels may - contain interpolated values. For example, to account for space between - readout chips on a module, physical pixels on edges and corners between - chips may have larger sensor areas and counts may be distributed between - their logical pixels. - bit_depth_readout(NX_INT): - doc: | - How many bits the electronics reads per pixel. - With CCD's and single photon counting detectors, - this must not align with traditional integer sizes. - This can be 4, 8, 12, 14, 16, ... - detector_readout_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - trigger_delay_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set delay.. - This is important to know for time resolved experiments. - trigger_delay_time_set(NX_FLOAT): - unit: NX_TIME - doc: | - User-specified trigger delay. - trigger_internal_delay_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector hardware after receiving the - trigger signal to when the detector starts to acquire the exposure. - It forms the lower boundary of the trigger_delay_time when the user - does not request an additional delay. - trigger_dead_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time during which no new trigger signal can be accepted. - Typically this is the - trigger_delay_time + exposure_time + readout_time. - This is important to know for time resolved experiments. - frame_time(NX_FLOAT): - unit: NX_TIME - doc: | - This is time for each frame. This is exposure_time + readout time. - dimensions: - rank: 1 - dim: [[1, nP]] - gain_setting(NX_CHAR): - doc: | - The gain setting of the detector. This is a detector-specific value - meant to document the gain setting of the detector during data - collection, for detectors with multiple available gain settings. - - Examples of gain settings include: - - * ``standard`` - * ``fast`` - * ``auto`` - * ``high`` - * ``medium`` - * ``low`` - * ``mixed high to medium`` - * ``mixed medium to low`` - - Developers are encouraged to use one of these terms, or to submit - additional terms to add to the list. - saturation_value(NX_NUMBER): - doc: | - The value at which the detector goes into saturation. - Especially common to CCD detectors, the data - is known to be invalid above this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - underload_value(NX_NUMBER): - doc: | - The lowest value at which pixels for this detector would be reasonably - measured. The data is known to be invalid below this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - number_of_cycles(NX_INT): - doc: | - CCD images are sometimes constructed by summing - together multiple short exposures in the - electronics. This reduces background etc. - This is the number of short exposures used to sum - images for an image. - sensor_material(NX_CHAR): - doc: | - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the name of this converter material. - sensor_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the thickness of this converter material. - threshold_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Single photon counter detectors can be adjusted - for a certain energy range in which they - work optimally. This is the energy setting for this. - (NXdetector_module): - doc: | - For use in special cases where the data in NXdetector - is represented in several parts, each with a separate geometry. - pixel_shape(choice): - (NXoff_geometry): - doc: | - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape. - (NXcylindrical_geometry): - doc: | - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders. - detector_shape(choice): - (NXoff_geometry): - doc: | - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape. - (NXcylindrical_geometry): - doc: | - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders. - \@default: - doc: | - .. 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. - amplifier_type(NX_CHAR): - doc: | - Type of electron amplifier, MCP, channeltron, etc. - detector_type(NX_CHAR): - doc: | - Description of the detector type, DLD, Phosphor+CCD, CMOS. - detector_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to detector. - amplifier_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to the amplifier. - amplifier_bias(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - The low voltage of the amplifier migh not be the ground. - sensor_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each imaging sensor chip on the detector. - sensor_count(NX_INT): - unit: NX_UNITLESS - doc: | - Number of imaging sensor chips on the detector. - sensor_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of the pixels of the imaging chip on the detector. - sensor_pixels(NX_INT): - unit: NX_UNITLESS - doc: | - Number of raw active elements in each dimension. Important for swept scans. - (NXdata): - doc: | - raw data output from the detector - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the detector is the center of the first pixel. - In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1f2e8ea7ab0f64a22ae7363f22f0399b4f6ea9274df5976a7d312d464371fc13 -# -# -# -# -# -# -# -# These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the -# preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets -# will vary according to the situation) and the general ordering principle is slowest to fastest. -# The type of each dimension should follow the order of scan points, detector output (e.g. pixels), -# then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited -# to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced -# by a detector at each trigger. -# -# -# number of scan points (only present in scanning measurements) -# number of detector pixels in the first (slowest) direction -# number of detector pixels in the second (faster) direction -# number of bins in the time-of-flight histogram -# -# -# -# A detector, detector bank, or multidetector. -# -# -# -# Total time of flight -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total time of flight -# -# -# -# -# In DAQ clock pulses -# -# -# -# -# -# -# Clock frequency in Hz -# -# -# -# -# -# Identifier for detector (pixels) -# Can be multidimensional, if needed -# -# -# -# -# -# Data values from the detector. The rank and dimension ordering should follow a principle of -# slowest to fastest measurement axes and may be explicitly specified in application definitions. -# -# Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be -# the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions -# of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single -# scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. -# Repetition of an experiment in a time series tends to be used similar to a slow scan axis -# and so will often be in the first dimension of the data array. -# -# The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions -# (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an -# imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data -# will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to -# be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. -# -# Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift -# detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. -# -# The type of each dimension should should follow the order of scan points, detector pixels, -# then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) -# shown here are merely illustrative of coordination between related datasets. -# -# -# -# -# -# -# -# -# -# -# Title of measurement -# -# -# -# Integral of data as check of data integrity -# -# -# -# -# -# -# The best estimate of the uncertainty in the data value (array size should match the data field). Where -# possible, this should be the standard deviation, which has the same units -# as the data. The form data_error is deprecated. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Offset from the detector center in x-direction. -# Can be multidimensional when needed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# x-axis offset from detector center -# -# -# -# -# -# Offset from the detector center in the y-direction. -# Can be multidimensional when different values are required for each pixel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# y-axis offset from detector center -# -# -# -# -# -# -# Offset from the detector center in the z-direction. -# Can be multidimensional when different values are required for each pixel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# y-axis offset from detector center -# -# -# -# -# -# This is the distance to the previous component in the -# instrument; most often the sample. The usage depends on the -# nature of the detector: Most often it is the distance of the -# detector assembly. But there are irregular detectors. In this -# case the distance must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# -# This is the polar angle of the detector towards the previous -# component in the instrument; most often the sample. -# The usage depends on the -# nature of the detector. -# Most often it is the polar_angle of the detector assembly. -# But there are irregular detectors. -# In this -# case, the polar_angle must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# -# This is the azimuthal angle angle of the detector towards -# the previous component in the instrument; most often the sample. -# The usage depends on the -# nature of the detector. -# Most often it is the azimuthal_angle of the detector assembly. -# But there are irregular detectors. -# In this -# case, the azimuthal_angle must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# name/manufacturer/model/etc. information -# -# -# -# Serial number for the detector -# -# -# -# Local name for the detector -# -# -# -# Position and orientation of detector -# -# -# -# Solid angle subtended by the detector at the sample -# -# -# -# -# -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size. -# -# -# -# -# -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size -# -# -# -# -# -# -# -# -# Detector dead time -# -# -# -# -# -# -# -# -# -# Detector gas pressure -# -# -# -# -# -# -# -# -# maximum drift space dimension -# -# -# -# Crate number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# Slot number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# Input number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# -# Description of type such as He3 gas cylinder, He3 PSD, scintillator, -# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, -# CMOS, ... -# -# -# -# -# Spectral efficiency of detector with respect to e.g. wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# efficiency of the detector -# -# -# -# -# -# -# -# -# -# This field can be two things: -# -# #. For a pixel detector it provides the nominal wavelength -# for which the detector has been calibrated. -# -# #. For other detectors this field has to be seen together with -# the efficiency field above. -# For some detectors, the efficiency is wavelength dependent. -# Thus this field provides the wavelength axis for the efficiency field. -# In this use case, the efficiency and wavelength arrays must -# have the same dimensionality. -# -# -# -# -# -# -# -# -# -# -# -# Real-time of the exposure (use this if exposure time varies for -# each array element, otherwise use ``count_time`` field). -# -# Most often there is a single real time value that is constant across -# an entire image frame. In such cases, only a 1-D array is needed. -# But there are detectors in which the real time -# changes per pixel. In that case, more than one dimension is needed. Therefore -# the rank of this field should be less than or equal to (detector rank + 1). -# -# -# -# -# -# -# -# -# -# start time for each frame, with the ``start`` attribute as absolute reference -# -# -# -# -# -# -# stop time for each frame, with the ``start`` attribute as absolute reference -# -# -# -# -# -# -# -# -# date of last calibration (geometry and/or efficiency) measurements -# -# -# -# -# -# summary of conversion of array data to pixels (e.g. polynomial -# approximations) and location of details of the calibrations -# -# -# -# -# How the detector is represented -# -# -# -# -# -# -# -# -# -# Elapsed actual counting time -# -# -# -# -# -# -# -# -# -# -# Use this group to provide other data related to this NXdetector group. -# -# -# -# -# -# In order to properly sort the order of the images taken in (for -# example) a tomography experiment, a sequence number is stored with each -# image. -# -# -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# -# This is the y position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# -# This is the start number of the first frame of a scan. In protein crystallography measurements one -# often scans a couple of frames on a give sample, then does something else, -# then returns to the same sample and scans some more frames. Each time with -# a new data file. This number helps concatenating such measurements. -# -# -# -# -# The diameter of a cylindrical detector -# -# -# -# The acquisition mode of the detector. -# -# -# -# -# -# -# -# -# -# -# -# True when the angular calibration has been applied in the -# electronics, false otherwise. -# -# -# -# Angular calibration data. -# -# -# -# -# -# -# -# True when the flat field correction has been applied in the -# electronics, false otherwise. -# -# -# -# Flat field correction data. -# -# -# -# -# -# -# -# Errors of the flat field correction data. -# The form flatfield_error is deprecated. -# -# -# -# -# -# -# -# -# True when the pixel mask correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# The 32-bit pixel mask for the detector. Can be either one mask -# for the whole dataset (i.e. an array with indices i, j) or -# each frame can have its own mask (in which case it would be -# an array with indices np, i, j). -# -# Contains a bit field for each pixel to signal dead, -# blind or high or otherwise unwanted or undesirable pixels. -# They have the following meaning: -# -# .. can't make a table here, a bullet list will have to do for now -# -# * bit 0: gap (pixel with no sensor) -# * bit 1: dead -# * bit 2: under responding -# * bit 3: over responding -# * bit 4: noisy -# * bit 5: -undefined- -# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) -# * bit 7: -undefined- -# * bit 8: user defined mask (e.g. around beamstop) -# * bits 9-30: -undefined- -# * bit 31: virtual pixel (corner pixel with interpolated value) -# -# Normal data analysis software would -# not take pixels into account -# when a bit in (mask & 0x0000FFFF) is -# set. Tag bit in the upper -# two bytes would indicate special pixel -# properties that normally -# would not be a sole reason to reject the -# intensity value (unless -# lower bits are set. -# -# If the full bit depths is not required, providing a -# mask with fewer bits is permissible. -# -# If needed, additional pixel masks can be specified by -# including additional entries named pixel_mask_N, where -# N is an integer. For example, a general bad pixel mask -# could be specified in pixel_mask that indicates noisy -# and dead pixels, and an additional pixel mask from -# experiment-specific shadowing could be specified in -# pixel_mask_2. The cumulative mask is the bitwise OR -# of pixel_mask and any pixel_mask_N entries. -# -# -# -# -# -# -# -# -# -# This field allow to distinguish different types of exposure to the same detector "data" field. -# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of -# recording the different measurements preserves the chronological order with is important for -# correct processing. -# -# This is used for example in tomography (`:ref:`NXtomo`) sample projections, -# dark and flat images, a magic number is recorded per frame. -# -# The key is as follows: -# -# * projection (sample) = 0 -# * flat field = 1 -# * dark field = 2 -# * invalid = 3 -# * background (no sample, but buffer where applicable) = 4 -# -# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. -# -# -# -# -# -# -# -# -# Counting detectors usually are not able to measure all incoming particles, -# especially at higher count-rates. Count-rate correction is applied to -# account for these errors. -# -# True when count-rate correction has been applied, false otherwise. -# -# -# -# -# The countrate_correction_lookup_table defines the LUT used for count-rate -# correction. It maps a measured count :math:`c` to its corrected value -# :math:`countrate\_correction\_lookup\_table[c]`. -# -# :math:`m` denotes the length of the table. -# -# -# -# -# -# -# -# True when virtual pixel interpolation has been applied, false otherwise. -# -# When virtual pixel interpolation is applied, values of some pixels may -# contain interpolated values. For example, to account for space between -# readout chips on a module, physical pixels on edges and corners between -# chips may have larger sensor areas and counts may be distributed between -# their logical pixels. -# -# -# -# -# How many bits the electronics reads per pixel. -# With CCD's and single photon counting detectors, -# this must not align with traditional integer sizes. -# This can be 4, 8, 12, 14, 16, ... -# -# -# -# -# Time it takes to read the detector (typically milliseconds). -# This is important to know for time resolved experiments. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector firmware after receiving the trigger signal -# to when the detector starts to acquire the exposure, including any user set delay.. -# This is important to know for time resolved experiments. -# -# -# -# -# User-specified trigger delay. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector hardware after receiving the -# trigger signal to when the detector starts to acquire the exposure. -# It forms the lower boundary of the trigger_delay_time when the user -# does not request an additional delay. -# -# -# -# -# Time during which no new trigger signal can be accepted. -# Typically this is the -# trigger_delay_time + exposure_time + readout_time. -# This is important to know for time resolved experiments. -# -# -# -# -# This is time for each frame. This is exposure_time + readout time. -# -# -# -# -# -# -# -# The gain setting of the detector. This is a detector-specific value -# meant to document the gain setting of the detector during data -# collection, for detectors with multiple available gain settings. -# -# Examples of gain settings include: -# -# * ``standard`` -# * ``fast`` -# * ``auto`` -# * ``high`` -# * ``medium`` -# * ``low`` -# * ``mixed high to medium`` -# * ``mixed medium to low`` -# -# Developers are encouraged to use one of these terms, or to submit -# additional terms to add to the list. -# -# -# -# -# The value at which the detector goes into saturation. -# Especially common to CCD detectors, the data -# is known to be invalid above this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# The lowest value at which pixels for this detector would be reasonably -# measured. The data is known to be invalid below this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# CCD images are sometimes constructed by summing -# together multiple short exposures in the -# electronics. This reduces background etc. -# This is the number of short exposures used to sum -# images for an image. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the name of this converter material. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the thickness of this converter material. -# -# -# -# -# Single photon counter detectors can be adjusted -# for a certain energy range in which they -# work optimally. This is the energy setting for this. -# -# -# -# -# For use in special cases where the data in NXdetector -# is represented in several parts, each with a separate geometry. -# -# -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape. -# -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape and require being described by cylinders. -# -# -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape. -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape and require being described by cylinders. -# -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the detector is the center of the first pixel. -# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# - diff --git a/base_classes/nyaml/NXdetector_group.yaml b/base_classes/nyaml/NXdetector_group.yaml deleted file mode 100644 index c087d3b193..0000000000 --- a/base_classes/nyaml/NXdetector_group.yaml +++ /dev/null @@ -1,182 +0,0 @@ -category: base -doc: | - Logical grouping of detectors. When used, describes a group of detectors. - - Each detector is represented as an NXdetector - with its own detector data array. Each detector data array - may be further decomposed into array sections by use of - NXdetector_module groups. Detectors can be grouped logically - together using NXdetector_group. Groups can be further grouped - hierarchically in a single NXdetector_group (for example, if - there are multiple detectors at an endstation or multiple - endstations at a facility). Alternatively, multiple - NXdetector_groups can be provided. - - The groups are defined hierarchically, with names given - in the group_names field, unique identifying indices given - in the field group_index, and the level in the hierarchy - given in the group_parent field. For example if an x-ray - detector group, DET, consists of four detectors in a - rectangular array:: - - DTL DTR - DLL DLR - - We could have:: - - group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] - group_index: [1, 2, 3, 4, 5] - group_parent: [-1, 1, 1, 1, 1] -type: group -NXdetector_group(NXobject): - group_names(NX_CHAR): - doc: | - An array of the names of the detectors given in NXdetector - groups or the names of hierarchical groupings of detectors - given as names of NXdetector_group groups or in - NXdetector_group group_names and group_parent fields as - having children. - group_index(NX_INT): - doc: | - An array of unique identifiers for detectors or groupings - of detectors. - - Each ID is a unique ID for the corresponding detector or group - named in the field group_names. The IDs are positive integers - starting with 1. - dimensions: - dim: [[1, i]] - group_parent(NX_INT): - doc: | - An array of the hierarchical levels of the parents of detectors - or groupings of detectors. - - A top-level grouping has parent level -1. - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['group_index'] - group_type(NX_INT): - doc: | - Code number for group type, e.g. bank=1, tube=2 etc. - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['group_index'] - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 691ea608a29ca9acf2ea185458c9dc75285438032148ac1529e5ebcf0d96b4b7 -# -# -# -# -# -# Logical grouping of detectors. When used, describes a group of detectors. -# -# Each detector is represented as an NXdetector -# with its own detector data array. Each detector data array -# may be further decomposed into array sections by use of -# NXdetector_module groups. Detectors can be grouped logically -# together using NXdetector_group. Groups can be further grouped -# hierarchically in a single NXdetector_group (for example, if -# there are multiple detectors at an endstation or multiple -# endstations at a facility). Alternatively, multiple -# NXdetector_groups can be provided. -# -# The groups are defined hierarchically, with names given -# in the group_names field, unique identifying indices given -# in the field group_index, and the level in the hierarchy -# given in the group_parent field. For example if an x-ray -# detector group, DET, consists of four detectors in a -# rectangular array:: -# -# DTL DTR -# DLL DLR -# -# We could have:: -# -# group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] -# group_index: [1, 2, 3, 4, 5] -# group_parent: [-1, 1, 1, 1, 1] -# -# -# -# An array of the names of the detectors given in NXdetector -# groups or the names of hierarchical groupings of detectors -# given as names of NXdetector_group groups or in -# NXdetector_group group_names and group_parent fields as -# having children. -# -# -# -# -# An array of unique identifiers for detectors or groupings -# of detectors. -# -# Each ID is a unique ID for the corresponding detector or group -# named in the field group_names. The IDs are positive integers -# starting with 1. -# -# -# -# -# -# An array of the hierarchical levels of the parents of detectors -# or groupings of detectors. -# -# A top-level grouping has parent level -1. -# -# -# -# Code number for group type, e.g. bank=1, tube=2 etc. -# -# -# -# -# .. 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/nyaml/NXdetector_module.yaml b/base_classes/nyaml/NXdetector_module.yaml deleted file mode 100644 index d7e1c35f76..0000000000 --- a/base_classes/nyaml/NXdetector_module.yaml +++ /dev/null @@ -1,302 +0,0 @@ -category: base -doc: | - Geometry and logical description of a detector module. When used, child group to NXdetector. - - Many detectors consist of multiple - smaller modules. Sometimes it is important to know the exact position of such - modules. - This is the purpose of this group. It is a child group to NXdetector. - - Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. -type: group -NXdetector_module(NXobject): - data_origin(NX_INT): - doc: | - A dimension-2 or dimension-3 field which gives the indices - of the origin of the hyperslab of data for this module in the - main area detector image in the parent NXdetector module. - - The data_origin is 0-based. - - The frame number dimension (np) is omitted. Thus the - data_origin field for a dimension-2 dataset with indices (np, i, j) - will be an array with indices (i, j), and for a dimension-3 - dataset with indices (np, i, j, k) will be an array with indices - (i, j, k). - - The :ref:`order ` of indices (i, j or i, j, k) is slow to fast. - data_size(NX_INT): - doc: | - Two or three values for the size of the module in pixels in - each direction. Dimensionality and order of indices is the - same as for data_origin. - module_offset(NX_NUMBER): - unit: NX_LENGTH - doc: | - Offset of the module in regards to the origin of the detector in an - arbitrary direction. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the axis for this transformation - \@offset: - type: NX_NUMBER - doc: | - A fixed offset applied before the transformation (three vector components). - \@offset_units: - type: NX_CHAR - doc: | - Units of the offset. - \@depends_on: - type: NX_CHAR - doc: | - Points to the path of the next element in the geometry chain. - fast_pixel_direction(NX_NUMBER): - unit: NX_LENGTH - doc: | - Values along the direction of :ref:`fastest varying ` :index:`pixel direction`. Each value in this - array is the size of a pixel in the units specified. Alternatively, if only one - value is given, all pixels in this direction have the same value. The direction - itself is given through the vector attribute. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the axis for this transformation - \@offset: - type: NX_NUMBER - doc: | - A fixed offset applied before the transformation (three vector components). - \@offset_units: - type: NX_CHAR - doc: | - Units of the offset. - \@depends_on: - type: NX_CHAR - doc: | - Points to the path of the next element in the geometry chain. - slow_pixel_direction(NX_NUMBER): - unit: NX_LENGTH - doc: | - Values along the direction of :ref:`slowest varying` :index:`pixel direction`. Each value in this - array is the size of a pixel in the units specified. Alternatively, if only one - value is given, all pixels in this direction have the same value. The direction - itself is given through the vector attribute. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the axis for this transformation - \@offset: - type: NX_NUMBER - doc: | - A fixed offset applied before the transformation (three vector components). - \@offset_units: - type: NX_CHAR - doc: | - Units of the offset. - \@depends_on: - type: NX_CHAR - doc: | - Points to the path of the next element in the geometry chain. - depends_on(NX_CHAR): - doc: | - Points to the start of the dependency chain for this module. - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 648bcf7b5b6f0a233d30dfbea9f75968750c251551912aa642fa2172e8d6413a -# -# -# -# -# -# Geometry and logical description of a detector module. When used, child group to NXdetector. -# -# Many detectors consist of multiple -# smaller modules. Sometimes it is important to know the exact position of such -# modules. -# This is the purpose of this group. It is a child group to NXdetector. -# -# Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. -# -# -# -# A dimension-2 or dimension-3 field which gives the indices -# of the origin of the hyperslab of data for this module in the -# main area detector image in the parent NXdetector module. -# -# The data_origin is 0-based. -# -# The frame number dimension (np) is omitted. Thus the -# data_origin field for a dimension-2 dataset with indices (np, i, j) -# will be an array with indices (i, j), and for a dimension-3 -# dataset with indices (np, i, j, k) will be an array with indices -# (i, j, k). -# -# The :ref:`order <Design-ArrayStorageOrder>` of indices (i, j or i, j, k) is slow to fast. -# -# -# -# -# Two or three values for the size of the module in pixels in -# each direction. Dimensionality and order of indices is the -# same as for data_origin. -# -# -# -# -# Offset of the module in regards to the origin of the detector in an -# arbitrary direction. -# -# -# -# -# -# -# -# -# Three values that define the axis for this transformation -# -# -# -# -# A fixed offset applied before the transformation (three vector components). -# -# -# -# -# Units of the offset. -# -# -# -# -# Points to the path of the next element in the geometry chain. -# -# -# -# -# -# Values along the direction of :ref:`fastest varying <Design-ArrayStorageOrder>` :index:`pixel direction<dimension; fastest varying>`. Each value in this -# array is the size of a pixel in the units specified. Alternatively, if only one -# value is given, all pixels in this direction have the same value. The direction -# itself is given through the vector attribute. -# -# -# -# -# -# -# -# -# Three values that define the axis for this transformation -# -# -# -# -# A fixed offset applied before the transformation (three vector components). -# -# -# -# -# Units of the offset. -# -# -# -# -# Points to the path of the next element in the geometry chain. -# -# -# -# -# -# Values along the direction of :ref:`slowest varying<Design-ArrayStorageOrder>` :index:`pixel direction<dimension; slowest varying>`. Each value in this -# array is the size of a pixel in the units specified. Alternatively, if only one -# value is given, all pixels in this direction have the same value. The direction -# itself is given through the vector attribute. -# -# -# -# -# -# -# -# -# Three values that define the axis for this transformation -# -# -# -# -# A fixed offset applied before the transformation (three vector components). -# -# -# -# -# Units of the offset. -# -# -# -# -# Points to the path of the next element in the geometry chain. -# -# -# -# -# -# Points to the start of the dependency chain for this module. -# -# -# -# -# .. 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/nyaml/NXdisk_chopper.yaml b/base_classes/nyaml/NXdisk_chopper.yaml deleted file mode 100644 index 983e75e2b0..0000000000 --- a/base_classes/nyaml/NXdisk_chopper.yaml +++ /dev/null @@ -1,322 +0,0 @@ -category: base -doc: | - A device blocking the beam in a temporal periodic pattern. - - A disk which blocks the beam but has one or more slits to periodically - let neutrons through as the disk rotates. Often used in pairs, one - NXdisk_chopper should be defined for each disk. - - The rotation of the disk is commonly monitored by recording a timestamp for - each full rotation of disk, by having a sensor in the stationary disk housing - sensing when it is aligned with a feature (such as a magnet) on the disk. - We refer to this below as the "top-dead-center signal". - - Angles and positive rotation speeds are measured in an anticlockwise - direction when facing away from the source. -symbols: - doc: | - This symbol will be used below to coordinate datasets with the same shape. - n: | - Number of slits in the disk -type: group -NXdisk_chopper(NXobject): - type: - doc: | - Type of the disk-chopper: only one from the enumerated list (match text exactly) - enumeration: [Chopper type single, contra_rotating_pair, synchro_pair] - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Chopper rotation speed. Positive for anticlockwise rotation when - facing away from the source, negative otherwise. - slits(NX_INT): - doc: | - Number of slits - slit_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angular opening - pair_separation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Disk spacing in direction of beam - slit_edges(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angle of each edge of every slit from the position of the - top-dead-center timestamp sensor, anticlockwise when facing - away from the source. - The first edge must be the opening edge of a slit, thus the last edge - may have an angle greater than 360 degrees. - dimensions: - dim: [[1, 2n]] - top_dead_center(NX_NUMBER): - unit: NX_TIME - doc: | - Timestamps of the top-dead-center signal. The times are relative - to the "start" attribute and in the units specified in the "units" - attribute. Please note that absolute - timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. - \@start: - type: NX_DATE_TIME - beam_position(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angular separation of the center of the beam and the - top-dead-center timestamp sensor, anticlockwise when facing - away from the source. - radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - Radius of the disk - slit_height(NX_FLOAT): - unit: NX_LENGTH - doc: | - Total slit height - phase(NX_FLOAT): - unit: NX_ANGLE - doc: | - Chopper phase angle - delay(NX_NUMBER): - unit: NX_TIME - doc: | - Time difference between timing system t0 and chopper driving clock signal - ratio(NX_INT): - doc: | - Pulse reduction factor of this chopper in relation to other - choppers/fastest pulse in the instrument - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Effective distance to the origin. - Note, it is recommended to use NXtransformations instead. - wavelength_range(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Low and high values of wavelength range transmitted - dimensions: - dim: [[1, 2]] - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference plane of the disk chopper includes the surface of the spinning disk which faces - the source. The reference point in the x and y axis is the point on this surface which is the - centre of the axle which the disk is spinning around. The reference plane is orthogonal to - the z axis and its position is the reference point on that axis. - - Note: This reference point in almost all practical cases is not where the beam passes though. - - .. image:: disk_chopper/disk_chopper.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e1666b3ec25ec80dd82906a832708fb1284d9fff6b0896e1bf720fb948b15fbe -# -# -# -# -# -# -# This symbol will be used below to coordinate datasets with the same shape. -# Number of slits in the disk -# -# -# -# A device blocking the beam in a temporal periodic pattern. -# -# A disk which blocks the beam but has one or more slits to periodically -# let neutrons through as the disk rotates. Often used in pairs, one -# NXdisk_chopper should be defined for each disk. -# -# The rotation of the disk is commonly monitored by recording a timestamp for -# each full rotation of disk, by having a sensor in the stationary disk housing -# sensing when it is aligned with a feature (such as a magnet) on the disk. -# We refer to this below as the "top-dead-center signal". -# -# Angles and positive rotation speeds are measured in an anticlockwise -# direction when facing away from the source. -# -# -# -# Type of the disk-chopper: only one from the enumerated list (match text exactly) -# -# -# -# -# -# -# -# -# Chopper rotation speed. Positive for anticlockwise rotation when -# facing away from the source, negative otherwise. -# -# -# -# Number of slits -# -# -# Angular opening -# -# -# Disk spacing in direction of beam -# -# -# -# Angle of each edge of every slit from the position of the -# top-dead-center timestamp sensor, anticlockwise when facing -# away from the source. -# The first edge must be the opening edge of a slit, thus the last edge -# may have an angle greater than 360 degrees. -# -# -# -# -# -# Timestamps of the top-dead-center signal. The times are relative -# to the "start" attribute and in the units specified in the "units" -# attribute. Please note that absolute -# timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. -# -# -# -# -# -# Angular separation of the center of the beam and the -# top-dead-center timestamp sensor, anticlockwise when facing -# away from the source. -# -# -# -# Radius of the disk -# -# -# Total slit height -# -# -# Chopper phase angle -# -# -# -# Time difference between timing system t0 and chopper driving clock signal -# -# -# -# -# Pulse reduction factor of this chopper in relation to other -# choppers/fastest pulse in the instrument -# -# -# -# -# Effective distance to the origin. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# Low and high values of wavelength range transmitted -# -# -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference plane of the disk chopper includes the surface of the spinning disk which faces -# the source. The reference point in the x and y axis is the point on this surface which is the -# centre of the axle which the disk is spinning around. The reference plane is orthogonal to -# the z axis and its position is the reference point on that axis. -# -# Note: This reference point in almost all practical cases is not where the beam passes though. -# -# .. image:: disk_chopper/disk_chopper.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXentry.yaml b/base_classes/nyaml/NXentry.yaml deleted file mode 100644 index 02ff63a813..0000000000 --- a/base_classes/nyaml/NXentry.yaml +++ /dev/null @@ -1,444 +0,0 @@ -category: base -doc: | - (**required**) :ref:`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. -type: group -NXentry(NXobject): - \@default: - doc: | - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXdata` group contains the data - to be shown by default. - It is used to resolve ambiguity when - one :ref:`NXdata` group exists. - The value :ref:`names ` a child group. If that group - itself has a ``default`` attribute, continue this chain until an - :ref:`NXdata` group is reached. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 ` - section. - (NXdata): - doc: | - The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 - \@IDF_Version: - - # as ratified at NIAC2010 - doc: | - ISIS Muon IDF_Version - title: - doc: | - Extended title for entry - experiment_identifier: - doc: | - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - experiment_description: - doc: | - Brief summary of the experiment, including key objectives. - (NXnote)experiment_documentation: - doc: | - Description of the full experiment (document in pdf, latex, ...) - collection_identifier: - doc: | - User or Data Acquisition defined group of NeXus files or NXentry - collection_description: - doc: | - Brief summary of the collection, including grouping criteria. - entry_identifier: - doc: | - Unique identifier for the measurement, defined by the facility. - entry_identifier_uuid: - doc: | - UUID identifier for the measurement. - \@version: - doc: | - Version of UUID used - features: - doc: | - Reserved for future use by NIAC. - - See https://github.com/nexusformat/definitions/issues/382 - definition: - doc: | - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms which must be - the name of the NXDL file (case sensitive without the file extension) - that the NXDL schema is defined in. - - For example the ``definition`` field for a file that conformed to the - *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. - - This field is provided so that :ref:`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. - \@version: - doc: | - NXDL version number - \@URL: - doc: | - URL of NXDL file - definition_local: - doc: | - Local NXDL schema extended from the entry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the entry. - \@version: - doc: | - NXDL version number - \@URL: - doc: | - URL of NXDL file - start_time(NX_DATE_TIME): - doc: | - Starting time of measurement - end_time(NX_DATE_TIME): - doc: | - Ending time of measurement - duration(NX_INT): - unit: NX_TIME - doc: | - Duration of measurement - collection_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - run_cycle: - doc: | - Such as "2007-3". Some user facilities organize their beam time into run cycles. - program_name: - doc: | - Name of program used to generate this file - \@version: - doc: | - Program version number - \@configuration: - doc: | - configuration of the program - revision: - doc: | - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - \@comment: - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - experiment_location: - doc: | - City and country where the experiment took place - experiment_start_date(NX_DATE_TIME): - doc: | - Start time of experimental run that includes the current - measurement, for example a beam time. - experiment_end_date(NX_DATE_TIME): - doc: | - End time of experimental run that includes the current - measurement, for example a beam time. - experiment_institution: - doc: | - Name of the institution hosting the facility - experiment_facility: - doc: | - Name of the experimental facility - experiment_laboratory: - doc: | - Name of the laboratory or beamline - notes(NXnote): - doc: | - Notes describing entry - thumbnail(NXnote): - doc: | - A small image that is representative of the entry. An example of this is - a 640x480 jpeg image automatically produced by a low resolution plot - of the NXdata. - \@type: - doc: | - The mime type should be an ``image/*`` - - # This is not perfect. - # How do we set a default value for the type attribute? - enumeration: [image/*] - (NXuser): - (NXsample): - (NXinstrument): - (NXcollection): - (NXmonitor): - (NXparameters): - (NXprocess): - (NXsubentry): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6f55039ff7886b759df0a35ec22f7e2727fe3778b1d55cba6c9c0ea1d4eaf7df -# -# -# -# -# -# -# -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXdata` group contains the data -# to be shown by default. -# It is used to resolve ambiguity when -# one :ref:`NXdata` group exists. -# The value :ref:`names <validItemName>` a child group. If that group -# itself has a ``default`` attribute, continue this chain until an -# :ref:`NXdata` group is reached. -# -# For more information about how NeXus identifies the default -# plottable data, see the -# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` -# section. -# -# -# -# -# (**required**) :ref:`NXentry` describes the measurement. -# -# The top-level NeXus group which contains all the data and associated -# information that comprise a single measurement. -# It is mandatory that there is at least one -# group of this type in the NeXus file. -# -# -# -# The data group -# -# .. note:: Before the NIAC2016 meeting [#]_, at least one -# :ref:`NXdata` group was required in each :ref:`NXentry` group. -# At the NIAC2016 meeting, it was decided to make :ref:`NXdata` -# an optional group in :ref:`NXentry` groups for data files that -# do not use an application definition. -# It is recommended strongly that all NeXus data files provide -# a NXdata group. -# It is permissable to omit the NXdata group only when -# defining the default plot is not practical or possible -# from the available data. -# -# For example, neutron event data may not have anything that -# makes a useful plot without extensive processing. -# -# Certain application definitions override this decision and -# require an :ref:`NXdata` group -# in the :ref:`NXentry` group. The ``minOccurs=0`` attribute -# in the application definition will indicate the -# :ref:`NXdata` group -# is optional, otherwise, it is required. -# -# .. [#] NIAC2016: -# https://www.nexusformat.org/NIAC2016.html, -# https://github.com/nexusformat/NIAC/issues/16 -# -# -# -# -# -# -# ISIS Muon IDF_Version -# -# -# Extended title for entry -# -# -# -# Unique identifier for the experiment, -# defined by the facility, -# possibly linked to the proposals -# -# -# -# Brief summary of the experiment, including key objectives. -# -# -# Description of the full experiment (document in pdf, latex, ...) -# -# -# User or Data Acquisition defined group of NeXus files or NXentry -# -# -# Brief summary of the collection, including grouping criteria. -# -# -# unique identifier for the measurement, defined by the facility. -# -# -# UUID identifier for the measurement. -# Version of UUID used -# -# -# -# Reserved for future use by NIAC. -# -# See https://github.com/nexusformat/definitions/issues/382 -# -# -# -# -# (alternate use: see same field in :ref:`NXsubentry` for preferred) -# -# Official NeXus NXDL schema to which this entry conforms which must be -# the name of the NXDL file (case sensitive without the file extension) -# that the NXDL schema is defined in. -# -# For example the ``definition`` field for a file that conformed to the -# *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. -# -# This field is provided so that :ref:`NXentry` can be the overlay position -# in a NeXus data file for an application definition and its -# set of groups, fields, and attributes. -# -# *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. -# -# NXDL version number -# URL of NXDL file -# -# -# -# Local NXDL schema extended from the entry -# specified in the ``definition`` field. -# This contains any locally-defined, -# additional fields in the entry. -# -# NXDL version number -# URL of NXDL file -# -# -# Starting time of measurement -# -# -# Ending time of measurement -# -# -# Duration of measurement -# -# -# -# Time transpired actually collecting data i.e. taking out time when collection was -# suspended due to e.g. temperature out of range -# -# -# -# Such as "2007-3". Some user facilities organize their beam time into run cycles. -# -# -# Name of program used to generate this file -# Program version number -# configuration of the program -# -# -# -# Revision id of the file due to re-calibration, reprocessing, new analysis, new -# instrument definition format, ... -# -# -# -# -# -# This is the flightpath before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# Notes describing entry -# -# -# -# A small image that is representative of the entry. An example of this is a 640x480 -# jpeg image automatically produced by a low resolution plot of the NXdata. -# -# -# The mime type should be an ``image/*`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml deleted file mode 100644 index 3ba6fd2baf..0000000000 --- a/base_classes/nyaml/NXenvironment.yaml +++ /dev/null @@ -1,120 +0,0 @@ -category: base -doc: | - Parameters for controlling external conditions -type: group -NXenvironment(NXobject): - name: - doc: | - Apparatus identification code/model number; e.g. OC100 011 - short_name: - doc: | - Alternative short name, perhaps for dashboard display like a present Seblock name - type: - doc: | - Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 - description: - doc: | - Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump - program: - doc: | - Program controlling the apparatus; e.g. LabView VI name - position(NXgeometry): - doc: | - The position and orientation of the apparatus. - Note, it is recommended to use NXtransformations instead. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - (NXtransformations): - exists: ['min', '0'] - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - (NXnote): - doc: | - Additional information, LabView logs, digital photographs, etc - (NXsensor): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8d95a3f1615f3146244d8f2a05eda98e75a2ca49ffefa97329db446c658f9def -# -# -# -# -# Parameters for controlling external conditions -# -# Apparatus identification code/model number; e.g. OC100 011 -# -# -# Alternative short name, perhaps for dashboard display like a present Seblock name -# -# -# Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 -# -# -# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump -# -# -# Program controlling the apparatus; e.g. LabView VI name -# -# -# -# The position and orientation of the apparatus. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# Additional information, LabView logs, digital photographs, etc -# -# -# -# diff --git a/base_classes/nyaml/NXevent_data.yaml b/base_classes/nyaml/NXevent_data.yaml deleted file mode 100644 index c75f0ee867..0000000000 --- a/base_classes/nyaml/NXevent_data.yaml +++ /dev/null @@ -1,220 +0,0 @@ -category: base -doc: | - NXevent_data is a special group for storing data from neutron - detectors in event mode. In this mode, the detector electronics - emits a stream of detectorID, timestamp pairs. With detectorID - describing the detector element in which the neutron was detected - and timestamp the timestamp at which the neutron event was - detected. In NeXus detectorID maps to event_id, event_time_offset - to the timestamp. - - As this kind of data is common at pulsed neutron - sources, the timestamp is almost always relative to the start of a - neutron pulse. Thus the pulse timestamp is recorded too together - with an index in the event_id, event_time_offset pair at which data for - that pulse starts. At reactor source the same pulsed data effect - may be achieved through the use of choppers or in stroboscopic - measurement setups. - - In order to make random access to timestamped data - faster there is an optional array pair of - cue_timestamp_zero and cue_index. The cue_timestamp_zero will - contain courser timestamps then in the time array, say - every five minutes. The cue_index will then contain the - index into the event_id,event_time_offset pair of arrays for that - courser cue_timestamp_zero. -type: group -NXevent_data(NXobject): - event_time_offset(NX_NUMBER): - unit: NX_TIME_OF_FLIGHT - doc: | - A list of timestamps for each event as it comes in. - dimensions: - rank: 1 - dim: [[1, i]] - event_id(NX_INT): - unit: NX_DIMENSIONLESS - doc: | - There will be extra information in the NXdetector to convert - event_id to detector_number. - dimensions: - rank: 1 - dim: [[1, i]] - event_time_zero(NX_NUMBER): - unit: NX_TIME - doc: | - The time that each pulse started with respect to the offset - dimensions: - rank: 1 - dim: [[1, j]] - \@offset: - type: NX_DATE_TIME - doc: | - ISO8601 - event_index(NX_INT): - unit: NX_DIMENSIONLESS - doc: | - The index into the event_time_offset, event_id pair for - the pulse occurring at the matching entry in event_time_zero. - dimensions: - rank: 1 - dim: [[1, j]] - pulse_height(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - If voltages from the ends of the detector are read out this - is where they go. This list is for all events with information - to attach to a particular pulse height. The information to - attach to a particular pulse is located in events_per_pulse. - dimensions: - rank: 2 - - # i,k? - dim: [[1, i], [2, k]] - cue_timestamp_zero(NX_DATE_TIME): - unit: NX_TIME - doc: | - Timestamps matching the corresponding cue_index into the - event_id, event_time_offset pair. - \@start: - type: NX_DATE_TIME - cue_index(NX_INT): - doc: | - Index into the event_id, event_time_offset pair matching the corresponding - cue_timestamp. - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8ed9dbd7316d38b106211e5be368886684addd89e347b28ec11e7e88d6ca88bb -# -# -# -# -# -# NXevent_data is a special group for storing data from neutron -# detectors in event mode. In this mode, the detector electronics -# emits a stream of detectorID, timestamp pairs. With detectorID -# describing the detector element in which the neutron was detected -# and timestamp the timestamp at which the neutron event was -# detected. In NeXus detectorID maps to event_id, event_time_offset -# to the timestamp. -# -# As this kind of data is common at pulsed neutron -# sources, the timestamp is almost always relative to the start of a -# neutron pulse. Thus the pulse timestamp is recorded too together -# with an index in the event_id, event_time_offset pair at which data for -# that pulse starts. At reactor source the same pulsed data effect -# may be achieved through the use of choppers or in stroboscopic -# measurement setups. -# -# In order to make random access to timestamped data -# faster there is an optional array pair of -# cue_timestamp_zero and cue_index. The cue_timestamp_zero will -# contain courser timestamps then in the time array, say -# every five minutes. The cue_index will then contain the -# index into the event_id,event_time_offset pair of arrays for that -# courser cue_timestamp_zero. -# -# -# -# A list of timestamps for each event as it comes in. -# -# -# -# -# -# There will be extra information in the NXdetector to convert -# event_id to detector_number. -# -# -# -# -# -# The time that each pulse started with respect to the offset -# -# -# -# ISO8601 -# -# -# -# -# The index into the event_time_offset, event_id pair for -# the pulse occurring at the matching entry in event_time_zero. -# -# -# -# -# -# If voltages from the ends of the detector are read out this -# is where they go. This list is for all events with information -# to attach to a particular pulse height. The information to -# attach to a particular pulse is located in events_per_pulse. -# -# -# -# -# -# -# -# -# Timestamps matching the corresponding cue_index into the -# event_id, event_time_offset pair. -# -# -# -# -# -# Index into the event_id, event_time_offset pair matching the corresponding -# cue_timestamp. -# -# -# -# -# .. 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/nyaml/NXfermi_chopper.yaml b/base_classes/nyaml/NXfermi_chopper.yaml deleted file mode 100644 index 90bf463bcd..0000000000 --- a/base_classes/nyaml/NXfermi_chopper.yaml +++ /dev/null @@ -1,210 +0,0 @@ -category: base -doc: | - A Fermi chopper, possibly with curved slits. -type: group -NXfermi_chopper(NXobject): - type: - doc: | - Fermi chopper type - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - chopper rotation speed - radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - radius of chopper - slit(NX_FLOAT): - unit: NX_LENGTH - doc: | - width of an individual slit - r_slit(NX_FLOAT): - unit: NX_LENGTH - doc: | - radius of curvature of slits - number(NX_INT): - unit: NX_UNITLESS - doc: | - number of slits - height(NX_FLOAT): - unit: NX_LENGTH - doc: | - input beam height - width(NX_FLOAT): - unit: NX_LENGTH - doc: | - input beam width - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance. Note, it is recommended to use NXtransformations instead. - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - - # should have units of angstroms or nm or pm - doc: | - Wavelength transmitted by chopper - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy selected - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead - doc: | - geometry of the fermi chopper - absorbing_material: - doc: | - absorbing material - transmitting_material: - doc: | - transmitting material - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a fermi chopper. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8abe047606006e4149eef1a11578301898263f4ca8c5fe2d952f4d95c0e89020 -# -# -# -# -# A Fermi chopper, possibly with curved slits. -# -# Fermi chopper type -# -# -# chopper rotation speed -# -# -# radius of chopper -# -# -# width of an individual slit -# -# -# radius of curvature of slits -# -# -# number of slits -# -# -# input beam height -# -# -# input beam width -# -# -# distance. Note, it is recommended to use NXtransformations instead. -# -# -# -# Wavelength transmitted by chopper -# -# -# energy selected -# -# -# geometry of the fermi chopper -# -# -# absorbing material -# -# -# transmitting material -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a fermi chopper. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXfilter.yaml b/base_classes/nyaml/NXfilter.yaml deleted file mode 100644 index 77783be27c..0000000000 --- a/base_classes/nyaml/NXfilter.yaml +++ /dev/null @@ -1,373 +0,0 @@ -category: base -doc: | - For band pass beam filters. - - If uncertain whether to use :ref:`NXfilter` (band-pass filter) - or :ref:`NXattenuator` (reduces beam intensity), then use - :ref:`NXattenuator`. -type: group -NXfilter(NXobject): - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to filter the beamstop and NXoff_geometry to describe its shape instead - doc: | - Geometry of the filter - description: - doc: | - Composition of the filter. Chemical formula can be specified separately. - - This field was changed (2010-11-17) from an enumeration to - a string since common usage showed a wider variety of use - than a simple list. These are the items in the list at - the time of the change: Beryllium | Pyrolytic Graphite | - Graphite | Sapphire | Silicon | Supermirror. - status: - doc: | - position with respect to in or out of the beam (choice of only "in" or "out") - enumeration: - in: - doc: | - in the beam - out: - doc: | - out of the beam - transmission(NXdata): - doc: | - Wavelength transmission profile of filter - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - average/nominal filter temperature - temperature_log(NXlog): - doc: | - Linked temperature_log for the filter - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the filter - density(NX_NUMBER): - unit: NX_MASS_DENSITY - doc: | - mass density of the filter - chemical_formula: - - # copied from NXsample - doc: | - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * 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. - - * This is the *Hill* system used by Chemical Abstracts. - sensor_type(NXsensor): - doc: | - Sensor(s)used to monitor the filter temperature - unit_cell_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell lattice parameter: length of side a - unit_cell_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell lattice parameter: length of side b - unit_cell_c(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell lattice parameter: length of side c - unit_cell_alpha(NX_FLOAT): - unit: NX_ANGLE - doc: | - Unit cell lattice parameter: angle alpha - unit_cell_beta(NX_FLOAT): - unit: NX_ANGLE - doc: | - Unit cell lattice parameter: angle beta - unit_cell_gamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Unit cell lattice parameter: angle gamma - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Unit cell - dimensions: - rank: 1 - dim: [[1, n_comp]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal filter using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 3 - - # n_comp,3,3 - - # TODO n_comp is number of different compositions? - dim: [[1, n_comp], [2, 3], [3, 3]] - m_value(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - m value of supermirror filter - substrate_material: - doc: | - substrate material of supermirror filter - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - substrate thickness of supermirror filter - coating_material: - doc: | - coating material of supermirror filter - substrate_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - substrate roughness (RMS) of supermirror filter - coating_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - coating roughness (RMS) of supermirror filter - dimensions: - rank: 1 - dim: [[1, nsurf]] - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a filter. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 785085298ea124d1b61ba6667be36d608a4416471c6e7909f4c53382b216ba88 -# -# -# -# -# -# For band pass beam filters. -# -# If uncertain whether to use :ref:`NXfilter` (band-pass filter) -# or :ref:`NXattenuator` (reduces beam intensity), then use -# :ref:`NXattenuator`. -# -# -# Geometry of the filter -# -# -# -# Composition of the filter. Chemical formula can be specified separately. -# -# This field was changed (2010-11-17) from an enumeration to -# a string since common usage showed a wider variety of use -# than a simple list. These are the items in the list at -# the time of the change: Beryllium | Pyrolytic Graphite | -# Graphite | Sapphire | Silicon | Supermirror. -# -# -# -# position with respect to in or out of the beam (choice of only "in" or "out") -# -# in the beam -# out of the beam -# -# -# -# Wavelength transmission profile of filter -# -# -# average/nominal filter temperature -# -# -# Linked temperature_log for the filter -# -# -# Thickness of the filter -# -# -# mass density of the filter -# -# -# -# -# The chemical formula specified using CIF conventions. -# Abbreviated version of CIF standard: -# -# * 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. -# -# * This is the *Hill* system used by Chemical Abstracts. -# -# -# -# Sensor(s)used to monitor the filter temperature -# -# -# Unit cell lattice parameter: length of side a -# -# -# Unit cell lattice parameter: length of side b -# -# -# Unit cell lattice parameter: length of side c -# -# -# Unit cell lattice parameter: angle alpha -# -# -# Unit cell lattice parameter: angle beta -# -# -# Unit cell lattice parameter: angle gamma -# -# -# Unit cell -# -# -# -# -# Orientation matrix of single crystal filter using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# -# m value of supermirror filter -# -# -# substrate material of supermirror filter -# -# -# substrate thickness of supermirror filter -# -# -# coating material of supermirror filter -# -# -# substrate roughness (RMS) of supermirror filter -# -# -# coating roughness (RMS) of supermirror filter -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a filter. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXflipper.yaml b/base_classes/nyaml/NXflipper.yaml deleted file mode 100644 index ea20d1a8d4..0000000000 --- a/base_classes/nyaml/NXflipper.yaml +++ /dev/null @@ -1,159 +0,0 @@ -category: base -doc: | - A spin flipper. -type: group -NXflipper(NXobject): - type: - enumeration: [coil, current-sheet] - flip_turns(NX_FLOAT): - unit: NX_PER_LENGTH - doc: | - Linear density of turns (such as number of turns/cm) in flipping field coils - comp_turns(NX_FLOAT): - unit: NX_PER_LENGTH - doc: | - Linear density of turns (such as number of turns/cm) in compensating field coils - guide_turns(NX_FLOAT): - unit: NX_PER_LENGTH - doc: | - Linear density of turns (such as number of turns/cm) in guide field coils - flip_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Flipping field coil current in "on" state" - comp_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Compensating field coil current in "on" state" - guide_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Guide field coil current in "on" state - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - thickness along path of neutron travel - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a spin flipper. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 62c4f526c364c8ede653c3a19e5aed1dae3a51685eb7137a46a3d906c1cc60bf -# -# -# -# -# A spin flipper. -# -# -# -# -# -# -# -# Linear density of turns (such as number of turns/cm) in flipping field coils -# -# -# Linear density of turns (such as number of turns/cm) in compensating field coils -# -# -# Linear density of turns (such as number of turns/cm) in guide field coils -# -# -# Flipping field coil current in "on" state" -# -# -# Compensating field coil current in "on" state" -# -# -# Guide field coil current in "on" state -# -# -# thickness along path of neutron travel -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a spin flipper. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXfresnel_zone_plate.yaml b/base_classes/nyaml/NXfresnel_zone_plate.yaml deleted file mode 100644 index eea7e942f1..0000000000 --- a/base_classes/nyaml/NXfresnel_zone_plate.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - A fresnel zone plate -type: group -NXfresnel_zone_plate(NXobject): - focus_parameters(NX_FLOAT): - doc: | - list of polynomial coefficients describing the focal length of the zone plate, in increasing powers of photon energy, - that describes the focal length of the zone plate (in microns) at an X-ray photon energy (in electron volts). - dimensions: - rank: 1 - dim: [] - outer_diameter(NX_FLOAT): - unit: NX_LENGTH - outermost_zone_width(NX_FLOAT): - unit: NX_LENGTH - central_stop_diameter(NX_FLOAT): - unit: NX_LENGTH - fabrication: - doc: | - how the zone plate was manufactured - enumeration: [etched, plated, zone doubled, other] - zone_height(NX_FLOAT): - unit: NX_LENGTH - zone_material: - doc: | - Material of the zones themselves - zone_support_material: - doc: | - Material present between the zones. This is usually only present for the "zone doubled" fabrication process - central_stop_material: - central_stop_thickness(NX_FLOAT): - unit: NX_LENGTH - mask_thickness(NX_FLOAT): - unit: NX_LENGTH - mask_material: - doc: | - If no mask is present, set mask_thickness to 0 and omit the mask_material field - support_membrane_material: - support_membrane_thickness(NX_FLOAT): - unit: NX_LENGTH - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a fresnel zone plate. - (NXtransformations): - doc: | - "Engineering" position of the fresnel zone plate - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 53901ea435d088aedb91b2f3fa70e315e6269a25bb0b871d938a2cfd0c5a82ec -# -# -# -# -# -# A fresnel zone plate -# -# -# list of polynomial coefficients describing the focal length of the zone plate, in increasing powers of photon energy, -# that describes the focal length of the zone plate (in microns) at an X-ray photon energy (in electron volts). -# -# -# -# -# -# -# -# -# how the zone plate was manufactured -# -# -# -# -# -# -# -# -# -# Material of the zones themselves -# -# -# Material present between the zones. This is usually only present for the "zone doubled" fabrication process -# -# -# -# -# -# If no mask is present, set mask_thickness to 0 and omit the mask_material 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a fresnel zone plate. -# -# -# -# -# -# "Engineering" position of the fresnel zone plate -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXgeometry.yaml b/base_classes/nyaml/NXgeometry.yaml deleted file mode 100644 index 5c1dfb277f..0000000000 --- a/base_classes/nyaml/NXgeometry.yaml +++ /dev/null @@ -1,128 +0,0 @@ -category: base -doc: | - legacy class - recommend to use :ref:`NXtransformations` now - - It is recommended that instances of :ref:`NXgeometry` be converted to - use :ref:`NXtransformations`. - - This is the description for a general position of a component. - It is recommended to name an instance of :ref:`NXgeometry` as "geometry" - to aid in the use of the definition in simulation codes such as McStas. - Also, in HDF, linked items must share the same name. - However, it might not be possible or practical in all situations. -type: group -deprecated: as decided at 2014 NIAC meeting, convert to use :ref:`NXtransformations` -NXgeometry(NXobject): - (NXshape): - doc: | - shape/size information of component - (NXtranslation): - doc: | - translation of component - (NXorientation): - doc: | - orientation of component - description: - doc: | - Optional description/label. Probably only present if we are - an additional reference point for components rather than the - location of a real component. - component_index(NX_INT): - doc: | - Position of the component along the beam path. The sample is at 0, components upstream - have negative component_index, components downstream have positive - component_index. - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d7d64aa78775fa8184154f30651e5def6856d4f76f490ba44df0f5a37463b670 -# -# -# -# -# -# legacy class - recommend to use :ref:`NXtransformations` now -# -# It is recommended that instances of :ref:`NXgeometry` be converted to -# use :ref:`NXtransformations`. -# -# This is the description for a general position of a component. -# It is recommended to name an instance of :ref:`NXgeometry` as "geometry" -# to aid in the use of the definition in simulation codes such as McStas. -# Also, in HDF, linked items must share the same name. -# However, it might not be possible or practical in all situations. -# -# -# shape/size information of component -# -# -# translation of component -# -# -# orientation of component -# -# -# -# Optional description/label. Probably only present if we are -# an additional reference point for components rather than the -# location of a real component. -# -# -# -# -# Position of the component along the beam path. The sample is at 0, components upstream -# have negative component_index, components downstream have positive -# component_index. -# -# -# -# -# .. 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/nyaml/NXgrating.yaml b/base_classes/nyaml/NXgrating.yaml deleted file mode 100644 index 9603971d7c..0000000000 --- a/base_classes/nyaml/NXgrating.yaml +++ /dev/null @@ -1,202 +0,0 @@ -category: base -doc: | - A diffraction grating, as could be used in a soft X-ray monochromator -type: group -NXgrating(NXobject): - angles(NX_FLOAT): - unit: NX_ANGLE - doc: | - Blaze or trapezoidal angles, with the angle of the upstream facing edge listed first. Blazed gratings can be identified by the low value of the first-listed angle. - dimensions: - rank: 1 - dim: [[1, 2]] - period(NX_FLOAT): - unit: NX_LENGTH - doc: | - List of polynomial coefficients describing the spatial separation of lines/grooves as a function of position along the grating, in increasing powers of position. Gratings which do not have variable line spacing will only have a single coefficient (constant). - dimensions: - rank: 1 - dim: [] - duty_cycle(NX_FLOAT): - unit: NX_UNITLESS - depth(NX_FLOAT): - unit: NX_LENGTH - diffraction_order(NX_INT): - unit: NX_UNITLESS - deflection_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angle between the incident beam and the utilised outgoing beam. - interior_atmosphere: - enumeration: [vacuum, helium, argon] - substrate_material: - doc: | - substrate_density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - coating_material: - substrate_roughness(NX_FLOAT): - unit: NX_LENGTH - coating_roughness(NX_FLOAT): - unit: NX_LENGTH - layer_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - An array describing the thickness of each layer - (NXshape)shape: - deprecated: Use NXoff_geometry to describe the shape of grating - doc: | - A NXshape group describing the shape of the mirror - figure_data(NXdata): - doc: | - Numerical description of the surface figure of the mirror. - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a bending grating. - (NXtransformations): - doc: | - "Engineering" position of the grating - Transformations used by this component to define its position and orientation. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e3c616b8b6027b862a3946ab63674969147bd291cefbad316bfb6fdb3477305e -# -# -# -# -# -# A diffraction grating, as could be used in a soft X-ray monochromator -# -# Blaze or trapezoidal angles, with the angle of the upstream facing edge listed first. Blazed gratings can be identified by the low value of the first-listed angle. -# -# -# -# -# -# List of polynomial coefficients describing the spatial separation of lines/grooves as a function of position along the grating, in increasing powers of position. Gratings which do not have variable line spacing will only have a single coefficient (constant). -# -# -# -# -# -# -# Angle between the incident beam and the utilised outgoing beam. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# An array describing the thickness of each layer -# -# -# A NXshape group describing the shape of the mirror -# -# -# Numerical description of the surface figure of the mirror. -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a bending grating. -# -# -# -# -# -# "Engineering" position of the grating -# Transformations used by this component to define its position and orientation. -# -# -# diff --git a/base_classes/nyaml/NXguide.yaml b/base_classes/nyaml/NXguide.yaml deleted file mode 100644 index 7ed8ef8f77..0000000000 --- a/base_classes/nyaml/NXguide.yaml +++ /dev/null @@ -1,416 +0,0 @@ -category: base -doc: | - A neutron optical element to direct the path of the beam. - - :ref:`NXguide` is used by neutron instruments to describe - a guide consists of several mirrors building a shape through which - neutrons can be guided or directed. The simplest such form is box shaped - although elliptical guides are gaining in popularity. - The individual parts of a guide usually have common characteristics - but there are cases where they are different. - For example, a neutron guide might consist of 2 or 4 coated walls or - a supermirror bender with multiple, coated vanes. - - To describe polarizing supermirrors such as used in neutron reflection, - it may be necessary to revise this definition of :ref:`NXguide` - to include :ref:`NXpolarizer` and/or :ref:`NXmirror`. - - When even greater complexity exists in the definition of what - constitutes a *guide*, it has been suggested that :ref:`NXguide` - be redefined as a :ref:`NXcollection` of :ref:`NXmirror` each - having their own :ref:`NXgeometry` describing their location(s). - - For the more general case when describing mirrors, consider using - :ref:`NXmirror`. - - NOTE: The NeXus International Advisory Committee welcomes - comments for revision and improvement of - this definition of :ref:`NXguide`. -symbols: - nsurf: | - number of reflecting surfaces - nwl: | - number of wavelengths -type: group -NXguide(NXobject): - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the guid and NXoff_geometry to describe its shape instead - doc: | - TODO: Explain what this NXgeometry group means. What is intended here? - description: - doc: | - A description of this particular instance of ``NXguide``. - incident_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - TODO: documentation needed - (NXdata)reflectivity: - doc: | - Reflectivity as function of reflecting surface and wavelength - \@signal: - enumeration: [data] - \@axes: - enumeration: [surface wavelength] - \@surface_indices: - enumeration: [0] - \@wavelength_indices: - enumeration: [1] - data(NX_NUMBER): - doc: | - reflectivity of each surface as a function of wavelength - dimensions: - rank: 2 - - # was [nsurf,i] - dim: [[1, nsurf], [2, nwl]] - surface(NX_NUMBER): - unit: NX_ANY - doc: | - List of surfaces. Probably best to use index - numbers but the specification is very loose. - dimensions: - rank: 1 - dim: [[1, nsurf]] - wavelength(NX_NUMBER): - unit: NX_WAVELENGTH - doc: | - wavelengths at which reflectivity was measured - dimensions: - rank: 1 - dim: [[1, nwl]] - bend_angle_x(NX_FLOAT): - unit: NX_ANGLE - doc: | - TODO: documentation needed - bend_angle_y(NX_FLOAT): - unit: NX_ANGLE - doc: | - TODO: documentation needed - interior_atmosphere: - doc: | - - # TODO - enumeration: [vacuum, helium, argon] - external_material: - doc: | - external material outside substrate - m_value(NX_FLOAT): - doc: | - The ``m`` value for a supermirror, which defines the supermirror - regime in multiples of the critical angle of Nickel. - dimensions: - rank: 1 - dim: [[1, nsurf]] - substrate_material(NX_FLOAT): - doc: | - TODO: documentation needed - - # Why is this field a "float"? - dimensions: - rank: 1 - dim: [[1, nsurf]] - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO: documentation needed - dimensions: - rank: 1 - dim: [[1, nsurf]] - coating_material(NX_FLOAT): - doc: | - TODO: documentation needed - - # Why is this field a "float"? - dimensions: - rank: 1 - dim: [[1, nsurf]] - substrate_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO: documentation needed - dimensions: - rank: 1 - dim: [[1, nsurf]] - coating_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO: documentation needed - dimensions: - rank: 1 - dim: [[1, nsurf]] - number_sections(NX_INT): - unit: NX_UNITLESS - doc: | - number of substrate sections (also called ``nsurf`` as an - index in the ``NXguide`` specification) - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The entry opening of the guide lies on the reference plane. The center of the opening on that plane is - the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the - reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends - in the positive direction of the z axis. - - .. image:: guide/guide.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 54953e1fdecb5ebcd9c9e2d1ba411b0f612566299eeaa35de397e38634ab8dfe -# -# -# -# -# -# -# number of reflecting surfaces -# number of wavelengths -# -# -# -# A neutron optical element to direct the path of the beam. -# -# :ref:`NXguide` is used by neutron instruments to describe -# a guide consists of several mirrors building a shape through which -# neutrons can be guided or directed. The simplest such form is box shaped -# although elliptical guides are gaining in popularity. -# The individual parts of a guide usually have common characteristics -# but there are cases where they are different. -# For example, a neutron guide might consist of 2 or 4 coated walls or -# a supermirror bender with multiple, coated vanes. -# -# To describe polarizing supermirrors such as used in neutron reflection, -# it may be necessary to revise this definition of :ref:`NXguide` -# to include :ref:`NXpolarizer` and/or :ref:`NXmirror`. -# -# When even greater complexity exists in the definition of what -# constitutes a *guide*, it has been suggested that :ref:`NXguide` -# be redefined as a :ref:`NXcollection` of :ref:`NXmirror` each -# having their own :ref:`NXgeometry` describing their location(s). -# -# For the more general case when describing mirrors, consider using -# :ref:`NXmirror`. -# -# NOTE: The NeXus International Advisory Committee welcomes -# comments for revision and improvement of -# this definition of :ref:`NXguide`. -# -# -# -# -# TODO: Explain what this NXgeometry group means. What is intended here? -# -# -# A description of this particular instance of ``NXguide``. -# -# -# TODO: documentation needed -# -# -# Reflectivity as function of reflecting surface and wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# reflectivity of each surface as a function of wavelength -# -# -# -# -# -# -# -# List of surfaces. Probably best to use index -# numbers but the specification is very loose. -# -# -# -# -# -# -# wavelengths at which reflectivity was measured -# -# -# -# -# -# -# TODO: documentation needed -# -# -# TODO: documentation needed -# -# -# -# -# -# -# -# -# -# -# external material outside substrate -# -# -# -# The ``m`` value for a supermirror, which defines the supermirror -# regime in multiples of the critical angle of Nickel. -# -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# -# number of substrate sections (also called ``nsurf`` as an -# index in the ``NXguide`` specification) -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The entry opening of the guide lies on the reference plane. The center of the opening on that plane is -# the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the -# reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends -# in the positive direction of the z axis. -# -# .. image:: guide/guide.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXinsertion_device.yaml b/base_classes/nyaml/NXinsertion_device.yaml deleted file mode 100644 index cae0fdc3e4..0000000000 --- a/base_classes/nyaml/NXinsertion_device.yaml +++ /dev/null @@ -1,203 +0,0 @@ -category: base -doc: | - An insertion device, as used in a synchrotron light source. -type: group -NXinsertion_device(NXobject): - type: - enumeration: [undulator, wiggler] - gap(NX_FLOAT): - unit: NX_LENGTH - doc: | - separation between opposing pairs of magnetic poles - taper(NX_FLOAT): - unit: NX_ANGLE - doc: | - angular of gap difference between upstream and downstream ends of the insertion device - phase(NX_FLOAT): - unit: NX_ANGLE - poles(NX_INT): - unit: NX_UNITLESS - doc: | - number of poles - magnetic_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - k(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - beam displacement parameter - length(NX_FLOAT): - unit: NX_LENGTH - doc: | - length of insertion device - power(NX_FLOAT): - unit: NX_POWER - doc: | - total power delivered by insertion device - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy of peak intensity in output spectrum - bandwidth(NX_FLOAT): - unit: NX_ENERGY - doc: | - bandwidth of peak energy - - # What are the best units here? - harmonic(NX_INT): - unit: NX_UNITLESS - doc: | - harmonic number of peak - (NXdata)spectrum: - doc: | - spectrum of insertion device - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the device and NXoff_geometry to describe its shape instead - doc: | - "Engineering" position of insertion device - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a insertion device. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5bf36d34ba4e5355cac4118269f029b8f11ecbfacb3f78c3e6947dd7b394c752 -# -# -# -# -# An insertion device, as used in a synchrotron light source. -# -# -# -# -# -# -# -# separation between opposing pairs of magnetic poles -# -# -# angular of gap difference between upstream and downstream ends of the insertion device -# -# -# -# number of poles -# -# -# -# beam displacement parameter -# -# -# length of insertion device -# -# -# total power delivered by insertion device -# -# -# energy of peak intensity in output spectrum -# -# -# bandwidth of peak energy -# -# -# harmonic number of peak -# -# -# spectrum of insertion device -# -# -# "Engineering" position of insertion device -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a insertion device. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml deleted file mode 100644 index 6e90347e75..0000000000 --- a/base_classes/nyaml/NXinstrument.yaml +++ /dev/null @@ -1,144 +0,0 @@ -category: base -doc: | - Collection of the components of the instrument or beamline. - - Template of instrument descriptions comprising various beamline components. - Each component will also be a NeXus group defined by its distance from the - sample. Negative distances represent beamline components that are before the - sample while positive distances represent components that are after the sample. - This device allows the unique identification of beamline components in a way - that is valid for both reactor and pulsed instrumentation. -type: group -NXinstrument(NXobject): - name: - doc: | - Name of instrument - \@short_name: - doc: | - short name for instrument, perhaps the acronym - (NXaperture): - (NXattenuator): - (NXbeam): - (NXbeam_stop): - (NXbending_magnet): - (NXcollimator): - (NXcollection): - (NXcapillary): - (NXcrystal): - (NXdetector): - (NXdetector_group): - (NXdisk_chopper): - (NXevent_data): - (NXfermi_chopper): - (NXfilter): - (NXflipper): - (NXguide): - (NXinsertion_device): - (NXmirror): - (NXmoderator): - (NXmonochromator): - (NXpolarizer): - (NXpositioner): - (NXsource): - (NXtransformations)DIFFRACTOMETER: - (NXvelocity_selector): - (NXxraylens): - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eda181557cab0a750b6b654cc75a341b10c991c5d8fadbd32c20639fa5c8cca2 -# -# -# -# -# -# Collection of the components of the instrument or beamline. -# -# Template of instrument descriptions comprising various beamline components. -# Each component will also be a NeXus group defined by its distance from the -# sample. Negative distances represent beamline components that are before the -# sample while positive distances represent components that are after the sample. -# This device allows the unique identification of beamline components in a way -# that is valid for both reactor and pulsed instrumentation. -# -# -# Name of instrument -# -# short name for instrument, perhaps the acronym -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# .. 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/nyaml/NXlog.yaml b/base_classes/nyaml/NXlog.yaml deleted file mode 100644 index edd2d7a50a..0000000000 --- a/base_classes/nyaml/NXlog.yaml +++ /dev/null @@ -1,252 +0,0 @@ -category: base -doc: | - Information recorded as a function of time. - - Description of information that is recorded against - time. There are two common use cases for this: - - - When logging data such as temperature during a run - - When data is taken in streaming mode data acquisition, - i.e. just timestamp, value pairs are stored and - correlated later in data reduction with other data, - - - In both cases, NXlog contains - the logged or streamed values and the times at which they were measured as elapsed time since a starting - time recorded in ISO8601 format. The time units are - specified in the units attribute. An optional scaling attribute - can be used to accomodate non standard clocks. - - - This method of storing logged data helps to distinguish - instances in which a variable is a dimension scale of the data, in which case it is stored - in an :ref:`NXdata` group, and instances in which it is logged during the - run, when it should be stored in an :ref:`NXlog` group. - - In order to make random access to timestamped data faster there is an optional array pair of - ``cue_timestamp_zero`` and ``cue_index``. The ``cue_timestamp_zero`` will - contain coarser timestamps than in the time array, say - every five minutes. The ``cue_index`` will then contain the - index into the time,value pair of arrays for that - coarser ``cue_timestamp_zero``. -type: group -NXlog(NXobject): - time(NX_NUMBER): - unit: NX_TIME - doc: | - Time of logged entry. The times are relative to the "start" attribute - and in the units specified in the "units" - attribute. Please note that absolute - timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. - - The scaling_factor, when present, has to be applied to the time values in order - to arrive at the units specified in the units attribute. The scaling_factor allows - for arbitrary time units such as ticks of some hardware clock. - \@start: - type: NX_DATE_TIME - \@scaling_factor: - type: NX_NUMBER - value(NX_NUMBER): - unit: NX_ANY - doc: | - Array of logged value, such as temperature. If this is - a single value the dimensionality is - nEntries. However, NXlog can also be used to store - multi dimensional time stamped data such as images. In - this example the dimensionality of values would be value[nEntries,xdim,ydim]. - raw_value(NX_NUMBER): - unit: NX_ANY - doc: | - Array of raw information, such as thermocouple voltage - description: - doc: | - Description of logged value - average_value(NX_FLOAT): - unit: NX_ANY - average_value_error(NX_FLOAT): - unit: NX_ANY - deprecated: - see: https://github.com/nexusformat/definitions/issues/639 - doc: | - estimated uncertainty (often used: standard deviation) of average_value - average_value_errors(NX_FLOAT): - unit: NX_ANY - doc: | - estimated uncertainty (often used: standard deviation) of average_value - minimum_value(NX_FLOAT): - unit: NX_ANY - maximum_value(NX_FLOAT): - unit: NX_ANY - duration(NX_FLOAT): - unit: NX_ANY - doc: | - Total time log was taken - cue_timestamp_zero(NX_NUMBER): - unit: NX_TIME - doc: | - Timestamps matching the corresponding cue_index into the - time, value pair. - \@start: - type: NX_DATE_TIME - doc: | - If missing start is assumed to be the same as for "time". - \@scaling_factor: - type: NX_NUMBER - doc: | - If missing start is assumed to be the same as for "time". - cue_index(NX_INT): - doc: | - Index into the time, value pair matching the corresponding - cue_timestamp_zero. - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cd1583ea481a281c985c4ad5d3993f01d8795c3f51242392bad25bb15319b3a7 -# -# -# -# -# -# Information recorded as a function of time. -# -# Description of information that is recorded against -# time. There are two common use cases for this: -# -# - When logging data such as temperature during a run -# - When data is taken in streaming mode data acquisition, -# i.e. just timestamp, value pairs are stored and -# correlated later in data reduction with other data, -# -# -# In both cases, NXlog contains -# the logged or streamed values and the times at which they were measured as elapsed time since a starting -# time recorded in ISO8601 format. The time units are -# specified in the units attribute. An optional scaling attribute -# can be used to accomodate non standard clocks. -# -# -# This method of storing logged data helps to distinguish -# instances in which a variable is a dimension scale of the data, in which case it is stored -# in an :ref:`NXdata` group, and instances in which it is logged during the -# run, when it should be stored in an :ref:`NXlog` group. -# -# In order to make random access to timestamped data faster there is an optional array pair of -# ``cue_timestamp_zero`` and ``cue_index``. The ``cue_timestamp_zero`` will -# contain coarser timestamps than in the time array, say -# every five minutes. The ``cue_index`` will then contain the -# index into the time,value pair of arrays for that -# coarser ``cue_timestamp_zero``. -# -# -# -# -# Time of logged entry. The times are relative to the "start" attribute -# and in the units specified in the "units" -# attribute. Please note that absolute -# timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. -# -# The scaling_factor, when present, has to be applied to the time values in order -# to arrive at the units specified in the units attribute. The scaling_factor allows -# for arbitrary time units such as ticks of some hardware clock. -# -# -# -# -# -# -# Array of logged value, such as temperature. If this is -# a single value the dimensionality is -# nEntries. However, NXlog can also be used to store -# multi dimensional time stamped data such as images. In -# this example the dimensionality of values would be value[nEntries,xdim,ydim]. -# -# -# -# Array of raw information, such as thermocouple voltage -# -# -# Description of logged value -# -# -# -# estimated uncertainty (often used: standard deviation) of average_value -# -# -# estimated uncertainty (often used: standard deviation) of average_value -# -# -# -# -# Total time log was taken -# -# -# -# Timestamps matching the corresponding cue_index into the -# time, value pair. -# -# -# If missing start is assumed to be the same as for "time". -# -# -# If missing start is assumed to be the same as for "time". -# -# -# -# -# Index into the time, value pair matching the corresponding -# cue_timestamp_zero. -# -# -# -# -# .. 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/nyaml/NXmirror.yaml b/base_classes/nyaml/NXmirror.yaml deleted file mode 100644 index d225a05670..0000000000 --- a/base_classes/nyaml/NXmirror.yaml +++ /dev/null @@ -1,346 +0,0 @@ -category: base -doc: | - A beamline mirror or supermirror. -type: group -NXmirror(NXobject): - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the mirror and NXoff_geometry to describe its shape instead - doc: | - - # TODO explain what this group means - type: - enumeration: - single: - doc: | - mirror with a single material as a reflecting surface - multi: - doc: | - mirror with stacked, multiple layers as a reflecting surface - description: - doc: | - description of this mirror - incident_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - (NXdata)reflectivity: - - # TODO Trac ticket #45 applies here. - # https://github.com/nexusformat/definitions/issues/45 - # TODO Solution of ticket #41 will apply here, as well. - # https://github.com/nexusformat/definitions/issues/41 - doc: | - Reflectivity as function of wavelength - - # TODO need more documentation throughout - bend_angle_x(NX_FLOAT): - unit: NX_ANGLE - doc: | - bend_angle_y(NX_FLOAT): - unit: NX_ANGLE - doc: | - interior_atmosphere: - enumeration: [vacuum, helium, argon] - external_material: - doc: | - external material outside substrate - m_value(NX_FLOAT): - unit: NX_UNITLESS - doc: | - The m value for a supermirror, which defines the supermirror - regime in multiples of the critical angle of Nickel. - substrate_material: - doc: | - substrate_density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - coating_material: - doc: | - substrate_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - coating_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - even_layer_material: - doc: | - even_layer_density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - odd_layer_material: - doc: | - odd_layer_density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - layer_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - An array describing the thickness of each layer - (NXshape)shape: - deprecated: Use NXoff_geometry instead - doc: | - A NXshape group describing the shape of the mirror - figure_data(NXdata): - doc: | - Numerical description of the surface figure of the mirror. - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - Given a flat mirror, the reference plane is the plane which contains the "entry" surface of the mirror. The reference - point of the mirror in the x and y axis is the centre of the mirror on that plane. The reference plane is orthogonal - to the z axis and the location of this plane is the reference point on the z axis. The mirror faces negative z values. - - .. image:: mirror/mirror.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - # TODO need more parameters here, such as ... - # list from Rainer Gehrke, DESY (some items may already be present) - # Parameters for mirrors - # Field indicating whether simple or multilayer - # Substrate element or compound - # Substrate density - # In case of multilayer: Even layer material (element or compound) - # Even layer density - # Odd layer material (element or compound) - # Odd layer density - # Number of layer pairs - # Layer thickness (array) - # Figure for crystals and mirrors (to describe curved surfaces) - # Field indicating whether concave or convex - # Field indicating whether cylindrical or not - # If cylindrical: cylinder orientation angle - # Now come the different surface figures with the necessary parameters: - # 1. Flat - # 2. Spherical (spherical radius) - # 3. Elliptical and hyperbolical (semi-major axis, semi-minor axis, angle of major axis and pole) - # 4. Toroidal (major radius, minor radius) - # 5. Parabolical (parabolic parameter a) - # 6. Conical (cone half aperture) - # 7. Polynomial (degree of polynom, array with polynom coefficients) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c83b5e3abca450466bb61a361babf63d4e730ab6116b2c76d404d217eee35a16 -# -# -# -# -# A beamline mirror or supermirror. -# -# -# -# -# -# -# mirror with a single material as a reflecting surface -# mirror with stacked, multiple layers as a reflecting surface -# -# -# -# description of this mirror -# -# -# -# -# -# -# Reflectivity as function of wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# external material outside substrate -# -# -# -# The m value for a supermirror, which defines the supermirror -# regime in multiples of the critical angle of Nickel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# An array describing the thickness of each layer -# -# -# A NXshape group describing the shape of the mirror -# -# -# Numerical description of the surface figure of the mirror. -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# Given a flat mirror, the reference plane is the plane which contains the "entry" surface of the mirror. The reference -# point of the mirror in the x and y axis is the centre of the mirror on that plane. The reference plane is orthogonal -# to the z axis and the location of this plane is the reference point on the z axis. The mirror faces negative z values. -# -# .. image:: mirror/mirror.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXmoderator.yaml b/base_classes/nyaml/NXmoderator.yaml deleted file mode 100644 index b31e964194..0000000000 --- a/base_classes/nyaml/NXmoderator.yaml +++ /dev/null @@ -1,193 +0,0 @@ -category: base -doc: | - A neutron moderator -type: group -NXmoderator(NXobject): - (NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the moderator and NXoff_geometry to describe its shape instead - doc: | - "Engineering" position of moderator - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Effective distance as seen by measuring radiation. - Note, it is recommended to use NXtransformations instead. - type: - enumeration: [H20, D20, Liquid H2, Liquid CH4, Liquid D2, Solid D2, C, Solid CH4, Solid H2] - poison_depth(NX_FLOAT): - unit: NX_LENGTH - coupled(NX_BOOLEAN): - doc: | - whether the moderator is coupled - coupling_material: - doc: | - The material used for coupling. Usually Cd. - poison_material: - enumeration: [Gd, Cd] - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - average/nominal moderator temperature - (NXlog)temperature_log: - doc: | - log file of moderator temperature - (NXdata)pulse_shape: - doc: | - moderator pulse shape - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the moderator - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the moderator is its center in the x and y axis. The reference point on the z axis is the - surface of the moderator pointing towards the source (the negative part of the z axis). - - .. image:: moderator/moderator.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f85a14caae0d07b3c5be162107a20cdcc3348974facbd9458418eb0d9af986b9 -# -# -# -# -# A neutron moderator -# -# "Engineering" position of moderator -# -# -# -# Effective distance as seen by measuring radiation. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# whether the moderator is coupled -# -# -# The material used for coupling. Usually Cd. -# -# -# -# -# -# -# -# -# average/nominal moderator temperature -# -# -# log file of moderator temperature -# -# -# moderator pulse shape -# -# -# -# This group describes the shape of the moderator -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the moderator is its center in the x and y axis. The reference point on the z axis is the -# surface of the moderator pointing towards the source (the negative part of the z axis). -# -# .. image:: moderator/moderator.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXmonitor.yaml b/base_classes/nyaml/NXmonitor.yaml deleted file mode 100644 index 7012e09735..0000000000 --- a/base_classes/nyaml/NXmonitor.yaml +++ /dev/null @@ -1,293 +0,0 @@ -category: base -doc: | - A monitor of incident beam data. - - It is similar to the :ref:`NXdata` groups containing - monitor data and its associated dimension scale, e.g. time_of_flight or - wavelength in pulsed neutron instruments. However, it may also include - integrals, or scalar monitor counts, which are often used in both in both - pulsed and steady-state instrumentation. -type: group -NXmonitor(NXobject): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - start_time(NX_DATE_TIME): - doc: | - Starting time of measurement - end_time(NX_DATE_TIME): - doc: | - Ending time of measurement - preset(NX_NUMBER): - unit: NX_ANY - doc: | - preset value for time or monitor - distance(NX_FLOAT): - unit: NX_LENGTH - deprecated: Use transformations/distance instead - doc: | - Distance of monitor from sample - range(NX_FLOAT): - unit: NX_ANY - doc: | - Range (X-axis, Time-of-flight, etc.) over which the integral was calculated - dimensions: - dim: [[1, 2]] - nominal(NX_NUMBER): - unit: NX_ANY - doc: | - Nominal reading to be used for normalisation purposes. - integral(NX_NUMBER): - unit: NX_ANY - doc: | - Total integral monitor counts - integral_log(NXlog): - doc: | - Time variation of monitor counts - type: - enumeration: [Fission Chamber, Scintillator] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - doc: | - Time-of-flight - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['efficiency'] - efficiency(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Monitor efficiency - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['i'] - data(NX_NUMBER): - unit: NX_ANY - doc: | - Monitor data - dimensions: - rank: dataRank - doc: | - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - dim: [] - sampled_fraction(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Proportion of incident beam sampled by the monitor (0 -# -# -# -# -# A monitor of incident beam data. -# -# It is similar to the :ref:`NXdata` groups containing -# monitor data and its associated dimension scale, e.g. time_of_flight or -# wavelength in pulsed neutron instruments. However, it may also include -# integrals, or scalar monitor counts, which are often used in both in both -# pulsed and steady-state instrumentation. -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# Starting time of measurement -# -# -# Ending time of measurement -# -# -# preset value for time or monitor -# -# -# Distance of monitor from sample -# -# -# Range (X-axis, Time-of-flight, etc.) over which the integral was calculated -# -# -# -# Nominal reading to be used for normalisation purposes. -# -# -# Total integral monitor counts -# -# -# Time variation of monitor counts -# -# -# -# -# -# -# -# -# Time-of-flight -# -# -# -# -# -# Monitor efficiency -# -# -# -# -# Monitor data -# -# -# -# The rank (``dataRank``) of the ``data`` must satisfy -# ``1 <= dataRank <= NX_MAXRANK=32``. -# At least one ``dim`` must have length ``n``. -# -# -# -# -# Proportion of incident beam sampled by the monitor (0<x<1) -# -# -# Geometry of the monitor -# -# -# -# Elapsed actual counting time, can be an array of size ``np`` -# when scanning. This is not the difference of the calendar time -# but the time the instrument was really counting, without -# pauses or times lost due beam unavailability -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference plane of the monitor contains the surface of the detector that faces the source -# and is the entry point of the beam. The reference point of the monitor in the x and y axis is -# its centre on this surface. The reference plane is orthogonal to the the z axis and the -# reference point on this z axis is where they intersect. -# -# .. image:: monitor/monitor.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXmonochromator.yaml b/base_classes/nyaml/NXmonochromator.yaml deleted file mode 100644 index 4a3015db69..0000000000 --- a/base_classes/nyaml/NXmonochromator.yaml +++ /dev/null @@ -1,197 +0,0 @@ -category: base -doc: | - A wavelength defining device. - - This is a base class for everything which - selects a wavelength or energy, be it a - monochromator crystal, a velocity selector, - an undulator or whatever. - - The expected units are: - - * wavelength: angstrom - * energy: eV -type: group -NXmonochromator(NXobject): - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - wavelength selected - wavelength_error(NX_FLOAT): - unit: NX_WAVELENGTH - deprecated: - see https://github.com/nexusformat/definitions/issues/820 - doc: | - wavelength standard deviation - wavelength_errors(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - wavelength standard deviation - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy selected - energy_error(NX_FLOAT): - unit: NX_ENERGY - deprecated: - see https://github.com/nexusformat/definitions/issues/820 - doc: | - energy standard deviation - energy_errors(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy standard deviation - (NXdata)distribution: - (NXgeometry)geometry: - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the monochromator and NXoff_geometry to describe its shape instead - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - (NXcrystal): - doc: | - Use as many crystals as necessary to describe - (NXvelocity_selector): - (NXgrating): - doc: | - For diffraction grating based monochromators - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a monochromator. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 91cfc4f0c4c8a300d58a88a2194cb4b98e229bb849f4904aa264c96fe6894e16 -# -# -# -# -# -# A wavelength defining device. -# -# This is a base class for everything which -# selects a wavelength or energy, be it a -# monochromator crystal, a velocity selector, -# an undulator or whatever. -# -# The expected units are: -# -# * wavelength: angstrom -# * energy: eV -# -# -# -# wavelength selected -# -# -# wavelength standard deviation -# -# -# wavelength standard deviation -# -# -# energy selected -# -# -# energy standard deviation -# -# -# energy standard deviation -# -# -# -# -# -# This group describes the shape of the beam line component -# -# -# Use as many crystals as necessary to describe -# -# For diffraction grating based monochromators -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a monochromator. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXnote.yaml b/base_classes/nyaml/NXnote.yaml deleted file mode 100644 index 229f0c82b0..0000000000 --- a/base_classes/nyaml/NXnote.yaml +++ /dev/null @@ -1,116 +0,0 @@ -category: base -doc: | - Any additional freeform information not covered by the other base classes. - - This class can be used to store additional information in a - NeXus file e.g. pictures, movies, audio, additional text logs -type: group -NXnote(NXobject): - author: - doc: | - Author or creator of note - date(NX_DATE_TIME): - doc: | - Date note created/added - type: - doc: | - Mime content type of note data field e.g. image/jpeg, text/plain, text/html - file_name: - doc: | - Name of original file name if note was read from an external source - description: - doc: | - Title of an image or other details of the note - sequence_index(NX_POSINT): - doc: | - Sequence index of note, for placing a sequence of - multiple **NXnote** groups in an order. Starts with 1. - data(NX_BINARY): - doc: | - Binary note data - if text, line terminator is [CR][LF]. - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cac46891aabdb595f69910c7ddb6a496bd16f4e98055ddc5570ef01fbeed1e73 -# -# -# -# -# -# Any additional freeform information not covered by the other base classes. -# -# This class can be used to store additional information in a -# NeXus file e.g. pictures, movies, audio, additional text logs -# -# -# Author or creator of note -# -# -# Date note created/added -# -# -# Mime content type of note data field e.g. image/jpeg, text/plain, text/html -# -# -# Name of original file name if note was read from an external source -# -# -# Title of an image or other details of the note -# -# -# -# Sequence index of note, for placing a sequence of -# multiple **NXnote** groups in an order. Starts with 1. -# -# -# -# Binary note data - if text, line terminator is [CR][LF]. -# -# -# -# .. 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/nyaml/NXobject.yaml b/base_classes/nyaml/NXobject.yaml deleted file mode 100644 index cbf07862fb..0000000000 --- a/base_classes/nyaml/NXobject.yaml +++ /dev/null @@ -1,44 +0,0 @@ -category: base -doc: | - This is the base object of NeXus -type: group -NXobject: - - # attribute name="name">name of instance -# -# -# -# -# This is the base object of NeXus -# -# -# -# diff --git a/base_classes/nyaml/NXoff_geometry.yaml b/base_classes/nyaml/NXoff_geometry.yaml deleted file mode 100644 index abc3de7ede..0000000000 --- a/base_classes/nyaml/NXoff_geometry.yaml +++ /dev/null @@ -1,197 +0,0 @@ -category: base -doc: | - Geometry (shape) description. - The format closely matches the Object File Format (OFF) which can be output - by most CAD software. - It can be used to describe the shape of any beamline component, including detectors. - In the case of detectors it can be used to define the shape of a single pixel, or, - if the pixel shapes are non-uniform, to describe the shape of the whole detector. -symbols: - doc: | - These symbols will be used below. - i: | - number of vertices in the shape - k: | - number of faces in the shape - l: | - number faces which are detecting surfaces or form the boundary of - detecting volumes -type: group -NXoff_geometry(NXobject): - vertices(NX_NUMBER): - unit: NX_LENGTH - doc: | - List of x,y,z coordinates for vertices. - The origin of the coordinates is the position of the parent component, for - example the NXdetector which the geometry describes. - If the shape describes a single pixel for a detector with uniform pixel - shape then the origin is the position of each pixel as described by the - ``x/y/z_pixel_offset`` datasets in ``NXdetector``. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - winding_order(NX_INT): - doc: | - List of indices of vertices in the ``vertices`` dataset to form each face, - right-hand rule for face normal. - dimensions: - rank: 1 - dim: [[1, j]] - faces(NX_INT): - doc: | - The start index in ``winding_order`` for each face. - dimensions: - rank: 1 - dim: [[1, k]] - detector_faces(NX_INT): - doc: | - List of pairs of index in the "faces" dataset and detector id. Face IDs in - the first column, and corresponding detector IDs in the second column. - This dataset should only be used only if the ``NXoff_geometry`` group is - describing a detector. - Note, the face indices must be in ascending order but need not be - consecutive as not every face in faces need be a detecting surface or - boundary of detecting volume. - Can use multiple entries with the same detector id to define detector volumes. - dimensions: - rank: 2 - dim: [[1, l], [2, 2]] - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 593884a075055d155060d7a8bb7a8d3b3164efcad905aed084064fc4ae052ead -# -# -# -# -# -# -# These symbols will be used below. -# number of vertices in the shape -# number of faces in the shape -# -# -# number faces which are detecting surfaces or form the boundary of -# detecting volumes -# -# -# -# -# -# Geometry (shape) description. -# The format closely matches the Object File Format (OFF) which can be output -# by most CAD software. -# It can be used to describe the shape of any beamline component, including detectors. -# In the case of detectors it can be used to define the shape of a single pixel, or, -# if the pixel shapes are non-uniform, to describe the shape of the whole detector. -# -# -# -# -# -# List of x,y,z coordinates for vertices. -# The origin of the coordinates is the position of the parent component, for -# example the NXdetector which the geometry describes. -# If the shape describes a single pixel for a detector with uniform pixel -# shape then the origin is the position of each pixel as described by the -# ``x/y/z_pixel_offset`` datasets in ``NXdetector``. -# -# -# -# -# -# -# -# -# -# -# -# -# List of indices of vertices in the ``vertices`` dataset to form each face, -# right-hand rule for face normal. -# -# -# -# -# -# -# -# -# -# -# The start index in ``winding_order`` for each face. -# -# -# -# -# -# -# -# -# -# -# List of pairs of index in the "faces" dataset and detector id. Face IDs in -# the first column, and corresponding detector IDs in the second column. -# This dataset should only be used only if the ``NXoff_geometry`` group is -# describing a detector. -# Note, the face indices must be in ascending order but need not be -# consecutive as not every face in faces need be a detecting surface or -# boundary of detecting volume. -# Can use multiple entries with the same detector id to define detector volumes. -# -# -# -# -# -# -# -# -# -# -# .. 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/nyaml/NXorientation.yaml b/base_classes/nyaml/NXorientation.yaml deleted file mode 100644 index 04a28a40cb..0000000000 --- a/base_classes/nyaml/NXorientation.yaml +++ /dev/null @@ -1,111 +0,0 @@ -category: base -doc: | - legacy class - recommend to use :ref:`NXtransformations` now - - Description for a general orientation of a component - used by :ref:`NXgeometry` -type: group -NXorientation(NXobject): - (NXgeometry): - doc: | - Link to another object if we are using relative positioning, else absent - value(NX_FLOAT): - unit: NX_UNITLESS - doc: | - The orientation information is stored as direction cosines. The direction cosines will - be between the local coordinate directions and the reference directions (to origin or - relative NXgeometry). Calling the local unit vectors (x',y',z') and the reference unit - vectors (x,y,z) the six numbers will be [x' dot x, x' dot y, x' dot z, y' dot x, y' dot - y, y' dot z] where "dot" is the scalar dot product (cosine of the angle between the unit - vectors). The unit vectors in both the local and reference coordinates are right-handed - and orthonormal. - - The pair of groups NXtranslation and NXorientation together - describe the position of a component. - dimensions: - - # numobj,6 - dim: [[1, numobj], [2, 6]] - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b837027cfb5d13fbee2db64988ee3af2d8ea788d712eaf5455b1eba597023f42 -# -# -# -# -# -# legacy class - recommend to use :ref:`NXtransformations` now -# -# Description for a general orientation of a component - used by :ref:`NXgeometry` -# -# -# Link to another object if we are using relative positioning, else absent -# -# -# -# The orientation information is stored as direction cosines. The direction cosines will -# be between the local coordinate directions and the reference directions (to origin or -# relative NXgeometry). Calling the local unit vectors (x',y',z') and the reference unit -# vectors (x,y,z) the six numbers will be [x' dot x, x' dot y, x' dot z, y' dot x, y' dot -# y, y' dot z] where "dot" is the scalar dot product (cosine of the angle between the unit -# vectors). The unit vectors in both the local and reference coordinates are right-handed -# and orthonormal. -# -# The pair of groups NXtranslation and NXorientation together -# describe the position of a component. -# -# -# -# -# -# -# -# -# .. 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/nyaml/NXparameters.yaml b/base_classes/nyaml/NXparameters.yaml deleted file mode 100644 index e81a3b034b..0000000000 --- a/base_classes/nyaml/NXparameters.yaml +++ /dev/null @@ -1,75 +0,0 @@ -category: base -doc: | - Container for parameters, usually used in processing or analysis. -type: group -NXparameters(NXobject): - term(NX_CHAR): - exists: ['min', '0', 'max', 'unbounded'] - - # maxOccurs="unbounded" is intended but is not allowed by current syntax - doc: | - A parameter (also known as a term) that is used in or results from processing. - \@units: - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4306876a0e67eaf3b38dfb0d8c2236908c7816908082629bdeb23948c1842a87 -# -# -# -# -# Container for parameters, usually used in processing or analysis. -# -# -# A parameter (also known as a term) that is used in or results from processing. -# -# -# -# -# .. 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/nyaml/NXpdb.yaml b/base_classes/nyaml/NXpdb.yaml deleted file mode 100644 index 24cfd73920..0000000000 --- a/base_classes/nyaml/NXpdb.yaml +++ /dev/null @@ -1,329 +0,0 @@ -category: base - -# The ignoreExtra* attributes are used in the definition to -# avoid warning messages that would be generated from -# unexpected groups, fields, and attributes. -# Since no groups or attributes are declared here, _every_ -# child of this class would generate a warning message without this -# attribute being set to "true". -doc: | - A NeXus transliteration of a PDB file, to be validated only as a PDB - rather than in NeXus. - - Use :ref:`NXpdb` to incorporate the information in an arbitrary - PDB into a NeXus file. - - The main suggestion is to use this as a container - class for a PDB entry to describe a sample in NXsample, - but it may be more appropriate to place this higher in the - hierarchy, say in NXentry. - - The structure has to follow the structure of a PDB - with each PDB data block mapped to a NeXus group of class NXpdb, - using a lowercase version of the data block name as the name - of the NeXus group, each PDB category in that data block - mapped to a NeXus group of class NXpdb and with each PDB column - mapped to a NeXus field. Each column in a looped PDB category - should always be presented as a 1-dimensional array. The columns - in an unlooped PDB category should be presented as scalar values. - If a PDB category specifies particular units for columns, the same - units should beused for the corresponding fields. - - A PDB entry is unambigous when all information is carried as text. - All text data should be presented as quoted strings, with the quote - marks except for the null values "." or "?" - - For clarity in NXpdb form, numeric data may be presented using the - numeric types specified in the mmCIF dictionary. In that case, - if a PDB null value, "." or "?", is contained in a numeric column, the - IEEE nan should be used for "?" and the IEEE inf should be used for ".". - - An arbitrary DDL2 CIF file can be represented in NeXus using NXpdb. - However, if save frames are required, an NXpdb_class attribute with the - value "CBF_cbfsf" is required for each NeXus group representing a save - frame. NXpdb attributes are not required for other CIF components, - but may be used to provide internal documentation. - - The nesting of NXpdb groups and datasets that correspond to a CIF with - two categories and one saveframe, including the NXpdb_class attribues is:: - - (datablock1):NXpdb - @NXpdb_class:CBF_cbfdb - (category1):NXpdb - @NXpdb_class:CBF_cbfcat - (column_name1):[...] - (column_name2):[...] - (column_name3):[...] - ... - (category2):NXpdb - @NXpdb_class:CBF_cbfcat - (column_name4):[...] - (column_name5):[...] - (column_name6):[...] - ... - (saveframe1):NXpdb - @NXpdb_class:CBF_cbfsf - (category3):NXpdb - @NXpdb_class:CBF_cbfcat - (column_name7):[...] - (column_name8):[...] - (column_name9):[...] - ... - ... - ... - - - - For example, a PDB entry that begins:: - - data_1YVA - # - _entry.id 1YVA - # - _audit_conform.dict_name mmcif_pdbx.dic - _audit_conform.dict_version 5.279 - _audit_conform.dict_location http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic - # - loop_ - _database_2.database_id - _database_2.database_code - PDB 1YVA - RCSB RCSB031959 - WWPDB D_1000031959 - # - - would produce:: - - sample:NXsample - 1yva:NXpdb - entry:NXpdb - id:"1YVA" - audit_conform:NXpdb - dict_name:"mmcif_pdbx.dic" - dict_version:"5.279" - dict_location:"http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic" - database_2:NXpdb - database_id:["PDB","RCSB","WWPDB"] - database_code:["1YVA","RCSB031959","D_1000031959"] - - another example is the following excerpt from pdb entry 9ins, giving the sequences - of the two chains:: - - loop_ - _entity_poly.entity_id - _entity_poly.nstd_linkage - _entity_poly.nstd_monomer - _entity_poly.pdbx_seq_one_letter_code - _entity_poly.pdbx_seq_one_letter_code_can - _entity_poly.type - 1 no no GIVEQCCTSICSLYQLENYCN GIVEQCCTSICSLYQLENYCN polypeptide(L) - 2 no no FVNQHLCGSHLVEALYLVCGERGFFYTPKA FVNQHLCGSHLVEALYLVCGERGFFYTPKA - polypeptide(L) - - which converts to:: - - entity_poly:NXpdb - @NXpdb_class:CBF_cbfcat - entity_id:["1", "2"] - nstd_linkage:["no", "no"] - nstd_monomer:["no", "no"] - pdbx_seq_one_letter_code:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] - pdbx_seq_one_letter_code_can:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] - type:["polypeptide(L)", "polypeptide(L)"] -type: group -ignoreExtraGroups: true -ignoreExtraFields: true -ignoreExtraAttributes: true -NXpdb(NXobject): - - # NOTE - # ===== - # NXpdb is a class not validated by the NXDL tools. - # Do not add any subgroups in this nxdl file. - # See: https://github.com/nexusformat/definitions/issues/259 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a7abffb938a9848149b6d1c2b7f0e7d0f47792f36c6dc44ad9f3831a9c3c0172 -# -# -# -# -# -# -# -# -# A NeXus transliteration of a PDB file, to be validated only as a PDB -# rather than in NeXus. -# -# Use :ref:`NXpdb` to incorporate the information in an arbitrary -# PDB into a NeXus file. -# -# The main suggestion is to use this as a container -# class for a PDB entry to describe a sample in NXsample, -# but it may be more appropriate to place this higher in the -# hierarchy, say in NXentry. -# -# The structure has to follow the structure of a PDB -# with each PDB data block mapped to a NeXus group of class NXpdb, -# using a lowercase version of the data block name as the name -# of the NeXus group, each PDB category in that data block -# mapped to a NeXus group of class NXpdb and with each PDB column -# mapped to a NeXus field. Each column in a looped PDB category -# should always be presented as a 1-dimensional array. The columns -# in an unlooped PDB category should be presented as scalar values. -# If a PDB category specifies particular units for columns, the same -# units should beused for the corresponding fields. -# -# A PDB entry is unambigous when all information is carried as text. -# All text data should be presented as quoted strings, with the quote -# marks except for the null values "." or "?" -# -# For clarity in NXpdb form, numeric data may be presented using the -# numeric types specified in the mmCIF dictionary. In that case, -# if a PDB null value, "." or "?", is contained in a numeric column, the -# IEEE nan should be used for "?" and the IEEE inf should be used for ".". -# -# An arbitrary DDL2 CIF file can be represented in NeXus using NXpdb. -# However, if save frames are required, an NXpdb_class attribute with the -# value "CBF_cbfsf" is required for each NeXus group representing a save -# frame. NXpdb attributes are not required for other CIF components, -# but may be used to provide internal documentation. -# -# The nesting of NXpdb groups and datasets that correspond to a CIF with -# two categories and one saveframe, including the NXpdb_class attribues is:: -# -# (datablock1):NXpdb -# @NXpdb_class:CBF_cbfdb -# (category1):NXpdb -# @NXpdb_class:CBF_cbfcat -# (column_name1):[...] -# (column_name2):[...] -# (column_name3):[...] -# ... -# (category2):NXpdb -# @NXpdb_class:CBF_cbfcat -# (column_name4):[...] -# (column_name5):[...] -# (column_name6):[...] -# ... -# (saveframe1):NXpdb -# @NXpdb_class:CBF_cbfsf -# (category3):NXpdb -# @NXpdb_class:CBF_cbfcat -# (column_name7):[...] -# (column_name8):[...] -# (column_name9):[...] -# ... -# ... -# ... -# -# -# -# For example, a PDB entry that begins:: -# -# data_1YVA -# # -# _entry.id 1YVA -# # -# _audit_conform.dict_name mmcif_pdbx.dic -# _audit_conform.dict_version 5.279 -# _audit_conform.dict_location http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic -# # -# loop_ -# _database_2.database_id -# _database_2.database_code -# PDB 1YVA -# RCSB RCSB031959 -# WWPDB D_1000031959 -# # -# -# would produce:: -# -# sample:NXsample -# 1yva:NXpdb -# entry:NXpdb -# id:"1YVA" -# audit_conform:NXpdb -# dict_name:"mmcif_pdbx.dic" -# dict_version:"5.279" -# dict_location:"http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic" -# database_2:NXpdb -# database_id:["PDB","RCSB","WWPDB"] -# database_code:["1YVA","RCSB031959","D_1000031959"] -# -# another example is the following excerpt from pdb entry 9ins, giving the sequences -# of the two chains:: -# -# loop_ -# _entity_poly.entity_id -# _entity_poly.nstd_linkage -# _entity_poly.nstd_monomer -# _entity_poly.pdbx_seq_one_letter_code -# _entity_poly.pdbx_seq_one_letter_code_can -# _entity_poly.type -# 1 no no GIVEQCCTSICSLYQLENYCN GIVEQCCTSICSLYQLENYCN polypeptide(L) -# 2 no no FVNQHLCGSHLVEALYLVCGERGFFYTPKA FVNQHLCGSHLVEALYLVCGERGFFYTPKA -# polypeptide(L) -# -# which converts to:: -# -# entity_poly:NXpdb -# @NXpdb_class:CBF_cbfcat -# entity_id:["1", "2"] -# nstd_linkage:["no", "no"] -# nstd_monomer:["no", "no"] -# pdbx_seq_one_letter_code:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] -# pdbx_seq_one_letter_code_can:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] -# type:["polypeptide(L)", "polypeptide(L)"] -# -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXpinhole.yaml b/base_classes/nyaml/NXpinhole.yaml deleted file mode 100644 index 69fd2fe2cb..0000000000 --- a/base_classes/nyaml/NXpinhole.yaml +++ /dev/null @@ -1,125 +0,0 @@ -category: base -doc: | - A simple pinhole. - - For more complex geometries, :ref:`NXaperture` should be used. -type: group -NXpinhole(NXobject): - depends_on(NX_CHAR): - doc: | - Points to the path of the last element in the geometry chain that places - this object in space. - When followed through that chain is supposed to end at an element depending - on "." i.e. the origin of the coordinate system. - If desired the location of the slit can also be described relative to - an NXbeam, which will allow a simple description of a non-centred pinhole. - - The reference direction of the pinhole is parallel with the z axis. The reference - point of the pinhole is its center in the x and y axis. The reference point on the z axis is the - plane which overlaps the side of the opening of the pin hole pointing towards the source (minus on the z axis). - - .. image:: pinhole/pinhole.png - :width: 40% - diameter(NX_NUMBER): - unit: NX_LENGTH - doc: | - Size of the circular hole defining the transmitted beam size. - (NXtransformations): - exists: ['min', '0'] - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c70638ef9748cfd94d36132613305136639cd062a10e8771d7e78ba4f865dd85 -# -# -# -# -# -# A simple pinhole. -# -# For more complex geometries, :ref:`NXaperture` should be used. -# -# -# -# Points to the path of the last element in the geometry chain that places -# this object in space. -# When followed through that chain is supposed to end at an element depending -# on "." i.e. the origin of the coordinate system. -# If desired the location of the slit can also be described relative to -# an NXbeam, which will allow a simple description of a non-centred pinhole. -# -# The reference direction of the pinhole is parallel with the z axis. The reference -# point of the pinhole is its center in the x and y axis. The reference point on the z axis is the -# plane which overlaps the side of the opening of the pin hole pointing towards the source (minus on the z axis). -# -# .. image:: pinhole/pinhole.png -# :width: 40% -# -# -# -# -# Size of the circular hole defining the transmitted beam size. -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# .. 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/nyaml/NXpolarizer.yaml b/base_classes/nyaml/NXpolarizer.yaml deleted file mode 100644 index 0380ddb99e..0000000000 --- a/base_classes/nyaml/NXpolarizer.yaml +++ /dev/null @@ -1,135 +0,0 @@ -category: base -doc: | - A spin polarizer. -type: group -NXpolarizer(NXobject): - type: - doc: | - one of these values: "crystal", "supermirror", "3He" - composition: - doc: | - description of the composition of the polarizing material - reflection(NX_INT): - unit: NX_UNITLESS - doc: | - [hkl] values of nominal reflection - dimensions: - dim: [[1, 3]] - efficiency(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - polarizing efficiency - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a polarizer. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 489a3377a505248d4d66e2c674c112f1eb6f8ca85c6f02fbedbe8b7ba40149d4 -# -# -# -# -# -# A spin polarizer. -# -# -# one of these values: "crystal", "supermirror", "3He" -# -# -# description of the composition of the polarizing material -# -# -# [hkl] values of nominal reflection -# -# -# -# -# -# polarizing efficiency -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a polarizer. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXpositioner.yaml b/base_classes/nyaml/NXpositioner.yaml deleted file mode 100644 index 36178fda4e..0000000000 --- a/base_classes/nyaml/NXpositioner.yaml +++ /dev/null @@ -1,200 +0,0 @@ -category: base -doc: | - A generic positioner such as a motor or piezo-electric transducer. -type: group -NXpositioner(NXobject): - name: - doc: | - symbolic or mnemonic name (one word) - description: - doc: | - description of positioner - value(NX_NUMBER): - unit: NX_ANY - doc: | - best known value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - raw_value(NX_NUMBER): - unit: NX_ANY - doc: | - raw value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - target_value(NX_NUMBER): - unit: NX_ANY - doc: | - targeted (commanded) value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - tolerance(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowable difference between target_value and value - dimensions: - rank: 1 - dim: [[1, n]] - soft_limit_min(NX_NUMBER): - unit: NX_ANY - doc: | - minimum allowed limit to set value - soft_limit_max(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowed limit to set value - velocity(NX_NUMBER): - unit: NX_ANY - doc: | - velocity of the positioner (distance moved per unit time) - acceleration_time(NX_NUMBER): - unit: NX_ANY - doc: | - time to ramp the velocity up to full speed - - # TODO other parameters: settling time, backlash, link to readback channel - controller_record: - doc: | - Hardware device record, e.g. EPICS process variable, taco/tango ... - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a positioner. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9e3dc1962303ddef4d403e479bfde3b47cdd8a9fa15c57bf2fadfb6e55ff541f -# -# -# -# -# -# A generic positioner such as a motor or piezo-electric transducer. -# -# -# symbolic or mnemonic name (one word) -# -# -# description of positioner -# -# -# best known value of positioner - need [n] as may be scanned -# -# -# -# raw value of positioner - need [n] as may be scanned -# -# -# -# targeted (commanded) value of positioner - need [n] as may be scanned -# -# -# -# maximum allowable difference between target_value and value -# -# -# -# minimum allowed limit to set value -# -# -# maximum allowed limit to set value -# -# -# velocity of the positioner (distance moved per unit time) -# -# -# time to ramp the velocity up to full speed -# -# -# -# Hardware device record, e.g. EPICS process variable, taco/tango ... -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a positioner. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXprocess.yaml b/base_classes/nyaml/NXprocess.yaml deleted file mode 100644 index d2650c0e4c..0000000000 --- a/base_classes/nyaml/NXprocess.yaml +++ /dev/null @@ -1,111 +0,0 @@ -category: base -doc: | - Document an event of data processing, reconstruction, or analysis for this data. -type: group -NXprocess(NXobject): - program(NX_CHAR): - doc: | - Name of the program used - sequence_index(NX_POSINT): - doc: | - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. - version(NX_CHAR): - doc: | - Version of the program used - date(NX_DATE_TIME): - doc: | - Date and time of processing. - (NXnote): - doc: | - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 58b609d04d449740f1f2dda2e29c406383a5c436f4f1e472a3d22fe95cfced49 -# -# -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# -# Name of the program used -# -# -# -# Sequence index of processing, -# for determining the order of multiple **NXprocess** steps. -# Starts with 1. -# -# -# -# Version of the program used -# -# -# Date and time of processing. -# -# -# -# The note will contain information about how the data was processed -# or anything about the data provenance. -# The contents of the note can be anything that the processing code -# can understand, or simple text. -# -# The name will be numbered to allow for ordering of steps. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/base_classes/nyaml/NXreflections.yaml b/base_classes/nyaml/NXreflections.yaml deleted file mode 100644 index 83523acc75..0000000000 --- a/base_classes/nyaml/NXreflections.yaml +++ /dev/null @@ -1,1266 +0,0 @@ -category: base -doc: | - Reflection data from diffraction experiments -symbols: - n: | - number of reflections - m: | - number of experiments -type: group -NXreflections(NXobject): - experiments: - exists: ['min', '1'] - doc: | - The experiments from which the reflection data derives - dimensions: - rank: 1 - dim: [[1, m]] - h(NX_NUMBER): - exists: ['min', '1'] - doc: | - The h component of the miller index - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - k(NX_NUMBER): - exists: ['min', '1'] - doc: | - The k component of the miller index - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - l(NX_NUMBER): - exists: ['min', '1'] - doc: | - The l component of the miller index - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - id(NX_INT): - exists: ['min', '1'] - doc: | - The id of the experiment which resulted in the reflection. If the value - is greater than 0, the experiments must link to a multi-experiment NXmx - group - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - reflection_id(NX_INT): - exists: ['min', '1'] - doc: | - The id of the reflection. Multiple partials from the same reflection - should all have the same id - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - entering(NX_BOOLEAN): - exists: ['min', '1'] - doc: | - Is the reflection entering or exiting the Ewald sphere - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - det_module(NX_INT): - exists: ['min', '1'] - doc: | - The detector module on which the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - flags(NX_INT): - exists: ['min', '1'] - doc: | - Status flags describing the reflection. - - This is a bit mask. The bits in the mask follow the convention - used by DIALS, and have the following names: - - === ========================================== - bit name - === ========================================== - 0 ``predicted`` - 1 ``observed`` - 2 ``indexed`` - 3 ``used_in_refinement`` - 4 ``strong`` - 5 ``reference_spot`` - 6 ``dont_integrate`` - 7 ``integrated_sum`` - 8 ``integrated_prf`` - 9 ``integrated`` - 10 ``overloaded`` - 11 ``overlapped`` - 12 ``overlapped_fg`` - 13 ``in_powder_ring`` - 14 ``foreground_includes_bad_pixels`` - 15 ``background_includes_bad_pixels`` - 16 ``includes_bad_pixels`` - 17 ``bad_shoebox`` - 18 ``bad_spot`` - 19 ``used_in_modelling`` - 20 ``centroid_outlier`` - 21 ``failed_during_background_modelling`` - 22 ``failed_during_summation`` - 23 ``failed_during_profile_fitting`` - 24 ``bad_reference`` - === ========================================== - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - d(NX_FLOAT): - exists: ['min', '1'] - doc: | - The resolution of the reflection - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - partiality(NX_FLOAT): - exists: ['min', '1'] - doc: | - The partiality of the reflection. - Dividing by this number will inflate the measured - intensity to the full reflection equivalent. - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_frame(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The frame on which the bragg peak of the reflection is predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The x position at which the bragg peak of the reflection - is predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The y position at which the bragg peak of the reflection - is predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_phi(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '1'] - doc: | - The phi angle at which the bragg peak of the reflection is predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_px_x(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The x pixel position at which the bragg peak of the reflection is - predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_px_y(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The y pixel position at which the bragg peak of the reflection is - predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_frame(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The estimate of the frame at which the central impact of the - reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_frame_var(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The variance on the estimate of the frame at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_frame_errors(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the frame at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_x(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The estimate of the pixel x position at which the central impact of - the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_x_var(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The variance on the estimate of the pixel x position at which the - central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_x_errors(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the pixel x position at which the - central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_y(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The estimate of the pixel y position at which the central impact of - the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_y_var(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The variance on the estimate of the pixel y position at which the - central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_y_errors(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the pixel y position at which the - central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_phi(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '1'] - doc: | - The estimate of the phi angle at which the central impact of the - reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_phi_var(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '1'] - doc: | - The variance on the estimate of the phi angle at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_phi_errors(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the phi angle at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The estimate of the x position at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_x_var(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The variance on the estimate of the x position at which - the central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_x_errors(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the x position at which - the central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The estimate of the y position at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_y_var(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The variance on the estimate of the y position at which - the central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_y_errors(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the y position at which - the central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - bounding_box(NX_INT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The bounding box around the recorded recorded reflection. - Should be an integer array of length 6, where the 6 values - are pixel positions or frame numbers, as follows: - - ===== =========================== - index meaning - ===== =========================== - 0 The lower pixel x position - 1 The upper pixel x position - 2 The lower pixel y position - 3 The upper pixel y position - 4 The lower frame number - 5 The upper frame number - ===== =========================== - dimensions: - rank: 2 - dim: [[1, n], [2, 6]] - \@description: - doc: | - Describes the dataset - background_mean(NX_FLOAT): - exists: ['min', '1'] - doc: | - The mean background under the reflection peak - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_prf(NX_FLOAT): - exists: ['min', '0'] - doc: | - The estimate of the reflection intensity by profile fitting - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_prf_var(NX_FLOAT): - exists: ['min', '0'] - doc: | - The variance on the estimate of the reflection intensity by profile - fitting - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_prf_errors(NX_FLOAT): - exists: ['min', '0'] - doc: | - The standard deviation of the estimate of the reflection intensity by profile - fitting - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_sum(NX_FLOAT): - exists: ['min', '1'] - doc: | - The estimate of the reflection intensity by summation - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_sum_var(NX_FLOAT): - exists: ['min', '1'] - doc: | - The variance on the estimate of the reflection intensity by - summation - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_sum_errors(NX_FLOAT): - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the reflection intensity by - summation - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - lp(NX_FLOAT): - exists: ['min', '1'] - doc: | - The LP correction factor to be applied to the reflection intensities - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - prf_cc(NX_FLOAT): - exists: ['min', '0'] - doc: | - The correlation of the reflection profile with the reference profile - used in profile fitting - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - overlaps(NX_INT): - exists: ['min', '0'] - doc: | - An adjacency list specifying the spatial overlaps of reflections. The - adjacency list is specified using an array data type where the elements - of the array are the indices of the adjacent overlapped reflection - \@description: - doc: | - Describes the dataset - polar_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - doc: | - Polar angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - doc: | - Azimuthal angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f0dd5d59e2726272e3befd4fd88df46f824c4023d04a1a1775153f79260f5b7e -# -# -# -# -# -# number of reflections -# number of experiments -# -# Reflection data from diffraction experiments -# -# The experiments from which the reflection data derives -# -# -# -# -# -# -# The h component of the miller index -# -# -# -# -# Describes the dataset -# -# -# -# -# The k component of the miller index -# -# -# -# -# Describes the dataset -# -# -# -# -# The l component of the miller index -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The id of the experiment which resulted in the reflection. If the value -# is greater than 0, the experiments must link to a multi-experiment NXmx -# group -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The id of the reflection. Multiple partials from the same reflection -# should all have the same id -# -# -# -# -# -# Describes the dataset -# -# -# -# Is the reflection entering or exiting the Ewald sphere -# -# -# -# -# Describes the dataset -# -# -# -# -# The detector module on which the reflection was recorded -# -# -# -# -# Describes the dataset -# -# -# -# -# -# Status flags describing the reflection. -# -# This is a bit mask. The bits in the mask follow the convention -# used by DIALS, and have the following names: -# -# === ========================================== -# bit name -# === ========================================== -# 0 ``predicted`` -# 1 ``observed`` -# 2 ``indexed`` -# 3 ``used_in_refinement`` -# 4 ``strong`` -# 5 ``reference_spot`` -# 6 ``dont_integrate`` -# 7 ``integrated_sum`` -# 8 ``integrated_prf`` -# 9 ``integrated`` -# 10 ``overloaded`` -# 11 ``overlapped`` -# 12 ``overlapped_fg`` -# 13 ``in_powder_ring`` -# 14 ``foreground_includes_bad_pixels`` -# 15 ``background_includes_bad_pixels`` -# 16 ``includes_bad_pixels`` -# 17 ``bad_shoebox`` -# 18 ``bad_spot`` -# 19 ``used_in_modelling`` -# 20 ``centroid_outlier`` -# 21 ``failed_during_background_modelling`` -# 22 ``failed_during_summation`` -# 23 ``failed_during_profile_fitting`` -# 24 ``bad_reference`` -# === ========================================== -# -# -# -# -# -# Describes the dataset -# -# -# -# -# The resolution of the reflection -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The partiality of the reflection. -# Dividing by this number will inflate the measured -# intensity to the full reflection equivalent. -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The frame on which the bragg peak of the reflection is predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The x position at which the bragg peak of the reflection -# is predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The y position at which the bragg peak of the reflection -# is predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The phi angle at which the bragg peak of the reflection is predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The x pixel position at which the bragg peak of the reflection is -# predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The y pixel position at which the bragg peak of the reflection is -# predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the frame at which the central impact of the -# reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the frame at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the frame at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the pixel x position at which the central impact of -# the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the pixel x position at which the -# central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the pixel x position at which the -# central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the pixel y position at which the central impact of -# the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the pixel y position at which the -# central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the pixel y position at which the -# central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the phi angle at which the central impact of the -# reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the phi angle at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the phi angle at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the x position at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the x position at which -# the central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the x position at which -# the central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the y position at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the y position at which -# the central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the y position at which -# the central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The bounding box around the recorded recorded reflection. -# Should be an integer array of length 6, where the 6 values -# are pixel positions or frame numbers, as follows: -# -# ===== =========================== -# index meaning -# ===== =========================== -# 0 The lower pixel x position -# 1 The upper pixel x position -# 2 The lower pixel y position -# 3 The upper pixel y position -# 4 The lower frame number -# 5 The upper frame number -# ===== =========================== -# -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The mean background under the reflection peak -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the reflection intensity by profile fitting -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the reflection intensity by profile -# fitting -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the reflection intensity by profile -# fitting -# -# -# -# -# -# Describes the dataset -# -# -# -# The estimate of the reflection intensity by summation -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the reflection intensity by -# summation -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the reflection intensity by -# summation -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The LP correction factor to be applied to the reflection intensities -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The correlation of the reflection profile with the reference profile -# used in profile fitting -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# An adjacency list specifying the spatial overlaps of reflections. The -# adjacency list is specified using an array data type where the elements -# of the array are the indices of the adjacent overlapped reflection -# -# -# Describes the dataset -# -# -# -# -# -# Polar angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# Azimuthal angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system -# -# -# -# -# -# -# Describes the dataset -# -# -# -# .. 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/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml deleted file mode 100644 index bcecfaa0a8..0000000000 --- a/base_classes/nyaml/NXroot.yaml +++ /dev/null @@ -1,180 +0,0 @@ -category: base -doc: | - Definition of the root NeXus group. -type: group -NXroot(NXobject): - \@NX_class: - doc: | - The root of any NeXus data file is an ``NXroot`` class - (no other choice is allowed for a valid NeXus data file). - This attribute cements that definition. - enumeration: [NXroot] - \@file_time: - type: NX_DATE_TIME - doc: | - Date and time file was originally created - \@file_name: - doc: | - File name of original NeXus file - \@file_update_time: - type: NX_DATE_TIME - doc: | - Date and time of last file change at close - \@NeXus_version: - doc: | - Version of NeXus API used in writing the file. - - Only used when the NAPI has written the file. - Note that this is different from the version of the - base class or application definition version number. - \@HDF_version: - doc: | - Version of HDF (version 4) library used in writing the file - \@HDF5_Version: - doc: | - Version of HDF5 library used in writing the file. - - Note this attribute is spelled with uppercase "V", - different than other version attributes. - \@XML_version: - doc: | - Version of XML support library used in writing the XML file - \@h5py_version: - doc: | - Version of h5py Python package used in writing the file - \@creator: - doc: | - facility or program where file originated - \@creator_version: - doc: | - Version of facility or program used in writing the file - (NXentry): - exists: ['min', '1'] - doc: | - entries - \@default: - doc: | - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXentry` group contains - the data to be shown by default. - It is used to resolve ambiguity when - more than one :ref:`NXentry` group exists. - The value :ref:`names ` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 00ad60c31b3087963764958288477d30afe61c6888f025264db3cfb53f1068c1 -# -# -# -# -# Definition of the root NeXus group. -# -# -# The root of any NeXus data file is an ``NXroot`` class -# (no other choice is allowed for a valid NeXus data file). -# This attribute cements that definition. -# -# -# -# -# -# -# Date and time file was originally created -# -# -# File name of original NeXus file -# -# -# Date and time of last file change at close -# -# -# -# Version of NeXus API used in writing the file. -# -# Only used when the NAPI has written the file. -# Note that this is different from the version of the -# base class or application definition version number. -# -# -# -# Version of HDF (version 4) library used in writing the file -# -# -# -# Version of HDF5 library used in writing the file. -# -# Note this attribute is spelled with uppercase "V", -# different than other version attributes. -# -# -# -# Version of XML support library used in writing the XML file -# -# -# Version of h5py Python package used in writing the file -# -# -# facility or program where file originated -# -# -# Version of facility or program used in writing the file -# -# -# entries -# -# -# -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXentry` group contains -# the data to be shown by default. -# It is used to resolve ambiguity when -# more than one :ref:`NXentry` group exists. -# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus 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/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml deleted file mode 100644 index b6601258c1..0000000000 --- a/base_classes/nyaml/NXsample.yaml +++ /dev/null @@ -1,844 +0,0 @@ -category: base -doc: | - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. -symbols: - doc: | - symbolic array lengths to be coordinated between various fields - n_comp: | - number of compositions - n_Temp: | - number of temperatures - n_eField: | - number of values in applied electric field - n_mField: | - number of values in applied magnetic field - n_pField: | - number of values in applied pressure field - n_sField: | - number of values in applied stress field -type: group -NXsample(NXobject): - name: - doc: | - Descriptive name of sample - chemical_formula: - doc: | - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * 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. - - * This is the *Hill* system used by Chemical Abstracts. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Sample temperature. This could be a scanned variable - dimensions: - rank: anyRank - - # could be any length - dim: [[1, n_Temp]] - electric_field(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Applied electric field - dimensions: - - # could be any length - dim: [[1, n_eField]] - \@direction: - enumeration: [x, y, z] - magnetic_field(NX_FLOAT): - unit: NX_ANY - doc: | - Applied magnetic field - dimensions: - - # could be any length - dim: [[1, n_mField]] - \@direction: - enumeration: [x, y, z] - stress_field(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external stress field - dimensions: - - # could be any length - dim: [[1, n_sField]] - \@direction: - enumeration: [x, y, z] - pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Applied pressure - dimensions: - - # could be any length - dim: [[1, n_pField]] - changer_position(NX_INT): - unit: NX_UNITLESS - doc: | - Sample changer position - unit_cell_abc(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dimensions: - dim: [[1, 3]] - unit_cell_alphabetagamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma - dimensions: - dim: [[1, 3]] - unit_cell(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell parameters (lengths and angles) - dimensions: - rank: 2 - dim: [[1, n_comp], [2, 6]] - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - dimensions: - rank: 1 - dim: [[1, n_comp]] - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 1 - dim: [[1, 3]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 3 - dim: [[1, n_comp], [2, 3], [3, 3]] - ub_matrix(NX_FLOAT): - doc: | - 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. - dimensions: - rank: 3 - dim: [[1, n_comp], [2, 3], [3, 3]] - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Mass of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative Molecular Mass of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - type: - enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] - situation: - doc: | - The atmosphere will be one of the components, which is where - its details will be stored; the relevant components will be - indicated by the entry in the sample_component member. - enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] - description: - doc: | - Description of the sample - preparation_date(NX_DATE_TIME): - doc: | - Date of preparation of the sample - geometry(NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead - doc: | - The position and orientation of the center of mass of the sample - (NXbeam): - doc: | - Details of beam incident on sample - used to calculate sample/beam interaction point - (NXsample_component): - doc: | - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - component: - doc: | - Details of the component of the sample and/or can - dimensions: - rank: 1 - dim: [[1, n_comp]] - sample_component: - doc: | - Type of component - dimensions: - rank: 1 - dim: [[1, n_comp]] - enumeration: [sample, can, atmosphere, kit] - concentration(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Concentration of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - volume_fraction(NX_FLOAT): - doc: | - Volume fraction of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - scattering_length_density(NX_FLOAT): - unit: NX_SCATTERING_LENGTH_DENSITY - doc: | - Scattering length density of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - unit_cell_class: - doc: | - In case it is all we know and we want to record/document it - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group: - doc: | - Crystallographic space group - dimensions: - dim: [[1, n_comp]] - point_group: - doc: | - Crystallographic point group, deprecated if space_group present - dimensions: - dim: [[1, n_comp]] - path_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Path length through sample/can for simple case when - it does not vary with scattering direction - path_length_window(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - sample thickness - sample_id(NX_CHAR): - doc: | - Identification number or signatures of the sample used. - sample_history(NXnote): - doc: | - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (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 - state(NX_CHAR): - doc: | - Physical state of the sample - purity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Chemical purity of the sample - orientation(NX_CHAR): - doc: | - Surface termination of the sample (if crystalline) - layer(NX_CHAR): - doc: | - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - chemical_name(NX_CHAR): - doc: | - Full chemical name of the sample - chem_id_cas(NX_CHAR): - doc: | - CAS registry number of the sample chemical content. - gas(NX_CHAR): - doc: | - Gases might be fluxed on the surface for various reasons. Chemical designation, - or residual. - gas_pressure(NX_NUMBER): - unit: NX_PRESSURE - doc: | - In the case of a fixed pressure measurement this is the scalar pressure. In the - case of an experiment in which pressure changes, or anyway is recorded, this is - an array of length m of pressures. - surface_dopant(NX_CHAR): - doc: | - Element of evaporated surface dopant such as alkali or other - surface_dopant_coverage(NX_FLOAT): - unit: NX_LENGTH - doc: | - Nominal thickness of the evaporated dopant - bias(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to sample and sample holder. - growth_method(NX_CHAR): - doc: | - Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition - etc.) - vendor(NX_CHAR): - doc: | - Name of the sample vendor (company or research group) - substrate_material(NX_CHAR): - doc: | - Material of the substrate in direct contact with the sample. - substrate_state(NX_CHAR): - doc: | - Physical state of the substrate, similar options to sample_state - drain_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Current to neutralize the photoemission current. This field may also be found in - NXmanpulator if present. - bias_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Possible bias of the sample with respect to analyser ground. This field may also - be found as sample_bias in NXmanipulator if present. - notes(NXnote): - doc: | - Further notes. - transmission(NXdata): - doc: | - As a function of Wavelength - temperature(NXlog): - doc: | - temperature.value is a link to e.g. temperature_env.sensor1.value - temperature_log(NXlog): - deprecated: | - use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 - doc: | - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - temperature_env(NXenvironment): - doc: | - Additional sample temperature environment information - magnetic_field(NXlog): - doc: | - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - magnetic_field_log(NXlog): - deprecated: | - use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 - doc: | - magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value - magnetic_field_env(NXenvironment): - doc: | - Additional sample magnetic environment information - external_DAC(NX_FLOAT): - unit: NX_ANY - doc: | - value sent to user's sample setup - external_ADC(NXlog): - doc: | - logged value (or logic state) read from user's setup - short_title: - doc: | - 20 character fixed length sample description for legends - - # How is the string length limitation imposed by the XSD? - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - x_translation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - (NXpositioner): - doc: | - Any positioner (motor, PZT, ...) used to locate the sample - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sample - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 297d53ed4ab613686ff86dc212b4a50ff9794932b6b43cb2ab2a6f9c7c7d44c8 -# -# -# -# -# -# -# symbolic array lengths to be coordinated between various fields -# number of compositions -# number of temperatures -# number of values in applied electric field -# number of values in applied magnetic field -# number of values in applied pressure field -# number of values in applied stress field -# -# -# -# Any information on the sample. -# -# This could include scanned variables that -# are associated with one of the data dimensions, e.g. the magnetic field, or -# logged data, e.g. monitored temperature vs elapsed time. -# -# -# Descriptive name of sample -# -# -# -# The chemical formula specified using CIF conventions. -# Abbreviated version of CIF standard: -# -# * 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. -# -# * This is the *Hill* system used by Chemical Abstracts. -# -# -# -# Sample temperature. This could be a scanned variable -# -# -# -# -# -# Applied electric field -# -# -# -# -# -# -# -# -# -# -# -# -# Applied magnetic field -# -# -# -# -# -# -# -# -# -# -# -# -# Applied external stress field -# -# -# -# -# -# -# -# -# -# -# -# -# Applied pressure -# -# -# -# -# -# Sample changer position -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# Unit cell parameters (lengths and angles) -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# Mass of sample -# -# -# -# -# -# Density of sample -# -# -# -# -# -# Relative Molecular Mass of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The atmosphere will be one of the components, which is where -# its details will be stored; the relevant components will be -# indicated by the entry in the sample_component member. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Description of the sample -# -# -# -# Date of preparation of the sample -# -# -# The position and orientation of the center of mass of the sample -# -# -# Details of beam incident on sample - used to calculate sample/beam interaction point -# -# -# -# One group per sample component -# This is the perferred way of recording per component information over the n_comp arrays -# -# -# -# Details of the component of the sample and/or can -# -# -# -# -# -# Type of component -# -# -# -# -# -# -# -# -# -# -# -# Concentration of each component -# -# -# -# -# -# Volume fraction of each component -# -# -# -# -# -# Scattering length density of each component -# -# -# -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# -# -# -# -# Path length through sample/can for simple case when -# it does not vary with scattering direction -# -# -# -# -# Thickness of a beam entry/exit window on the can (mm) -# - assumed same for entry and exit -# -# -# -# sample thickness -# -# -# As a function of Wavelength -# -# -# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value -# -# -# Additional sample temperature environment information -# -# -# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value -# -# -# magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value -# -# -# Additional sample magnetic environment information -# -# -# value sent to user's sample setup -# -# -# logged value (or logic state) read from user's setup -# -# -# 20 character fixed length sample description for legends -# -# -# -# -# Optional rotation angle for the case when the powder diagram has -# been obtained through an omega-2theta scan like from a traditional -# single detector powder diffractometer. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the X-direction of the laboratory coordinate system -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the Z-direction of the laboratory coordinate system. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# Any positioner (motor, PZT, ...) used to locate the sample -# -# -# -# This group describes the shape of the sample -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# - diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml deleted file mode 100644 index 79db66dec6..0000000000 --- a/base_classes/nyaml/NXsample_component.yaml +++ /dev/null @@ -1,275 +0,0 @@ -category: base -doc: | - One group like this per component can be recorded For a sample consisting of multiple components. -symbols: - doc: | - symbolic array lengths to be coordinated between various fields - n_Temp: | - number of temperatures - n_eField: | - number of values in applied electric field - n_mField: | - number of values in applied magnetic field - n_pField: | - number of values in applied pressure field - n_sField: | - number of values in applied stress field -type: group -NXsample_component(NXobject): - name: - doc: | - Descriptive name of sample component - chemical_formula: - doc: | - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * 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. - - * This is the *Hill* system used by Chemical Abstracts. - unit_cell_abc(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dimensions: - dim: [[1, 3]] - unit_cell_alphabetagamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma - dimensions: - dim: [[1, 3]] - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - dimensions: - rank: 1 - dim: [[1, 3]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample component. - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Mass of sample component - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of sample component - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative Molecular Mass of sample component - description: - doc: | - Description of the sample component - volume_fraction(NX_FLOAT): - doc: | - Volume fraction of component - scattering_length_density(NX_FLOAT): - unit: NX_SCATTERING_LENGTH_DENSITY - doc: | - Scattering length density of component - unit_cell_class: - doc: | - In case it is all we know and we want to record/document it - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group: - doc: | - Crystallographic space group - point_group: - doc: | - Crystallographic point group, deprecated if space_group present - transmission(NXdata): - doc: | - As a function of Wavelength - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ff01cd0073031e1be0af7ac769912f5e25a58642674c61264b226c807703a8fc -# -# -# -# -# -# -# symbolic array lengths to be coordinated between various fields -# number of temperatures -# number of values in applied electric field -# number of values in applied magnetic field -# number of values in applied pressure field -# number of values in applied stress field -# -# -# -# One group like this per component can be recorded For a sample consisting of multiple components. -# -# -# Descriptive name of sample component -# -# -# -# The chemical formula specified using CIF conventions. -# Abbreviated version of CIF standard: -# -# * 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. -# -# * This is the *Hill* system used by Chemical Abstracts. -# -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# Volume of the unit cell -# -# -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) -# -# -# -# -# -# -# Orientation matrix of single crystal sample component. -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) -# -# -# -# -# -# -# -# Mass of sample component -# -# -# Density of sample component -# -# -# Relative Molecular Mass of sample component -# -# -# -# Description of the sample component -# -# -# -# Volume fraction of component -# -# -# Scattering length density of component -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# As a function of Wavelength -# -# -# -# .. 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/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml deleted file mode 100644 index f290ddbe79..0000000000 --- a/base_classes/nyaml/NXsensor.yaml +++ /dev/null @@ -1,324 +0,0 @@ -category: base -doc: | - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. -type: group -NXsensor(NXobject): - model: - doc: | - Sensor identification code/model number - name: - doc: | - Name for the sensor - short_name: - doc: | - Short name of sensor used e.g. on monitor display program - attached_to: - doc: | - where sensor is attached to ("sample" | "can") - geometry(NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - Defines the axes for logged vector quantities if they are not the global instrument axes. - measurement: - doc: | - name for measured signal - enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, current, pressure, flow, stress, strain, shear, surface_pressure] - type: - doc: | - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - run_control(NX_BOOLEAN): - doc: | - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - high_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Upper control bound of sensor reading if using run_control - low_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Lower control bound of sensor reading if using run_control - value(NX_FLOAT): - unit: NX_ANY - doc: | - nominal setpoint or average value - - need [n] as may be a vector - dimensions: - dim: [[1, n]] - value_deriv1(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_deriv2(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_log(NXlog): - doc: | - Time history of sensor readings - value_deriv1_log(NXlog): - doc: | - Time history of first derivative of sensor readings - value_deriv2_log(NXlog): - doc: | - Time history of second derivative of sensor readings - external_field_brief: - enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] - external_field_full(NXorientation): - doc: | - For complex external fields not satisfied by External_field_brief - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sensor when necessary. - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e09b8ec8aaac9fdd491b083bd1ecdfc2d991f89e9fdb7aff06675009f14fcc69 -# -# -# -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# Sensor identification code/model number -# -# -# Name for the sensor -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# Defines the axes for logged vector quantities if they are not the global instrument axes. -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# Time history of sensor readings -# -# -# Time history of first derivative of sensor readings -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# This group describes the shape of the sensor when necessary. -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a sensor. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXshape.yaml b/base_classes/nyaml/NXshape.yaml deleted file mode 100644 index f5222b30de..0000000000 --- a/base_classes/nyaml/NXshape.yaml +++ /dev/null @@ -1,143 +0,0 @@ -category: base -doc: | - legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. - - This is the description of the general shape and size of a - component, which may be made up of ``numobj`` separate - elements - it is used by the :ref:`NXgeometry` class -type: group -NXshape(NXobject): - shape: - doc: | - general shape of a component - enumeration: [nxflat, nxcylinder, nxbox, nxsphere, nxcone, nxelliptical, nxtoroidal, nxparabolic, nxpolynomial] - size(NX_FLOAT): - unit: NX_LENGTH - doc: | - physical extent of the object along its local axes (after NXorientation) - with the center of mass at the local origin (after NXtranslation). - The meaning and location of these axes will vary according to the value - of the "shape" variable. - ``nshapepar`` defines how many parameters: - - - For "nxcylinder" type the parameters are (diameter,height) and a three value orientation vector of the cylinder. - - For the "nxbox" type the parameters are (length,width,height). - - For the "nxsphere" type the parameters are (diameter). - - For nxcone cone half aperture - - For nxelliptical, semi-major axis, semi-minor-axis, angle of major axis and pole - - For nxtoroidal, major radius, minor radius - - For nxparabolic, parabolic parameter a - - For nxpolynomial, an array of polynom coefficients, the dimension of the array - encodes the degree of the polynom - dimensions: - dim: [[1, numobj], [2, nshapepar]] - direction: - enumeration: [concave, convex] - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c273b2f18be61f791d2fc4da9ecefbb880d180a9f83536ad161f2f685127f209 -# -# -# -# -# -# legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. -# -# This is the description of the general shape and size of a -# component, which may be made up of ``numobj`` separate -# elements - it is used by the :ref:`NXgeometry` class -# -# -# general shape of a component -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# physical extent of the object along its local axes (after NXorientation) -# with the center of mass at the local origin (after NXtranslation). -# The meaning and location of these axes will vary according to the value -# of the "shape" variable. -# ``nshapepar`` defines how many parameters: -# -# - For "nxcylinder" type the parameters are (diameter,height) and a three value orientation vector of the cylinder. -# - For the "nxbox" type the parameters are (length,width,height). -# - For the "nxsphere" type the parameters are (diameter). -# - For nxcone cone half aperture -# - For nxelliptical, semi-major axis, semi-minor-axis, angle of major axis and pole -# - For nxtoroidal, major radius, minor radius -# - For nxparabolic, parabolic parameter a -# - For nxpolynomial, an array of polynom coefficients, the dimension of the array -# encodes the degree of the polynom -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# .. 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/nyaml/NXslit.yaml b/base_classes/nyaml/NXslit.yaml deleted file mode 100644 index 364a1c539c..0000000000 --- a/base_classes/nyaml/NXslit.yaml +++ /dev/null @@ -1,141 +0,0 @@ -category: base -doc: | - A simple slit. - - For more complex geometries, :ref:`NXaperture` should be used. -type: group -NXslit(NXobject): - depends_on(NX_CHAR): - doc: | - Points to the path of the last element in the geometry chain that places - this object in space. - When followed through that chain is supposed to end at an element depending - on "." i.e. the origin of the coordinate system. - If desired the location of the slit can also be described relative to - an NXbeam, which will allow a simple description of a non-centred slit. - - The reference plane of the slit is orthogonal to the z axis and includes the - surface that is the entry surface of the slit. The reference point of the slit - is the centre of the slit opening in the x and y axis on the reference plane. - The reference point on the z axis is the reference plane. - - .. image:: slit/slit.png - :width: 40% - x_gap(NX_NUMBER): - unit: NX_LENGTH - doc: | - Size of the gap opening in the first dimension of the local - coordinate system. - y_gap(NX_NUMBER): - unit: NX_LENGTH - doc: | - Size of the gap opening in the second dimension of the local - coordinate system. - \@default: - doc: | - .. 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. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 417ccad73271f355d1d59bfad75b0a0622636749a18b54e8d6f71ec54a968203 -# -# -# -# -# -# A simple slit. -# -# For more complex geometries, :ref:`NXaperture` should be used. -# -# -# -# Points to the path of the last element in the geometry chain that places -# this object in space. -# When followed through that chain is supposed to end at an element depending -# on "." i.e. the origin of the coordinate system. -# If desired the location of the slit can also be described relative to -# an NXbeam, which will allow a simple description of a non-centred slit. -# -# The reference plane of the slit is orthogonal to the z axis and includes the -# surface that is the entry surface of the slit. The reference point of the slit -# is the centre of the slit opening in the x and y axis on the reference plane. -# The reference point on the z axis is the reference plane. -# -# .. image:: slit/slit.png -# :width: 40% -# -# -# -# -# -# Size of the gap opening in the first dimension of the local -# coordinate system. -# -# -# -# -# Size of the gap opening in the second dimension of the local -# 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. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml deleted file mode 100644 index f6c2210879..0000000000 --- a/base_classes/nyaml/NXsource.yaml +++ /dev/null @@ -1,422 +0,0 @@ -category: base -doc: | - The neutron or x-ray storage ring/facility. -type: group -NXsource(NXobject): - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Effective distance from sample - Distance as seen by radiation from sample. This number should be negative - to signify that it is upstream of the sample. - name: - doc: | - Name of source - \@short_name: - doc: | - short name for source, perhaps the acronym - type: - doc: | - type of radiation source (pick one from the enumerated list and spell exactly) - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray, Arc Lamp, Halogen Lamp, LED] - probe: - doc: | - type of radiation probe (pick one from the enumerated list and spell exactly) - enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] - power(NX_FLOAT): - unit: NX_POWER - doc: | - Source power - emittance_x(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in X (horizontal) direction. - emittance_y(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in Y (horizontal) direction. - sigma_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - particle beam size in x - sigma_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - particle beam size in y - flux(NX_FLOAT): - unit: NX_FLUX - doc: | - Source intensity/area (example: s-1 cm-2) - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Source energy. - For storage rings, this would be the particle beam energy. - For X-ray tubes, this would be the excitation voltage. - current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Accelerator, X-ray tube, or storage ring current - voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Accelerator voltage - frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency of pulsed source - period(NX_FLOAT): - unit: NX_PERIOD - doc: | - Period of pulsed source - target_material: - doc: | - Pulsed source target material - enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C, Ar, He, Xe, Hg/Cd, H] - notes(NXnote): - doc: | - any source/facility related messages/events that - occurred during the experiment - bunch_pattern(NXdata): - doc: | - For storage rings, description of the bunch pattern. - This is useful to describe irregular bunch patterns. - title: - doc: | - name of the bunch pattern - number_of_bunches(NX_INT): - doc: | - For storage rings, the number of bunches in use. - bunch_length(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, temporal length of the bunch - bunch_distance(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, time between bunches - pulse_width(NX_FLOAT): - unit: NX_TIME - doc: | - temporal width of source pulse - - # pulsed sources or storage rings could use this - pulse_shape(NXdata): - doc: | - source pulse shape - - # pulsed sources or storage rings could use this - mode: - doc: | - source operating mode - enumeration: - Single Bunch: - doc: | - for storage rings - Multi Bunch: - doc: | - for storage rings - - # other sources could add to this - - # other sources could add to this - top_up(NX_BOOLEAN): - doc: | - Is the synchrotron operating in top_up mode? - last_fill(NX_NUMBER): - unit: NX_CURRENT - doc: | - For storage rings, the current at the end of the most recent injection. - \@time: - type: NX_DATE_TIME - doc: | - date and time of the most recent injection. - photon_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - The center photon energy of the source, before it is - monochromatized or converted - center_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The center wavelength of the source, before it is - monochromatized or converted - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - For pulsed sources, the energy of a single pulse - peak_power(NX_FLOAT): - unit: NX_POWER - doc: | - For pulsed sources, the pulse energy divided - by the pulse duration - bunch_number_start(NX_INT): - doc: | - Some facilities tag each bunch. - First bunch of the measurement - bunch_number_end(NX_INT): - doc: | - Last bunch of the measurement - geometry(NXgeometry): - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead - doc: | - "Engineering" location of source. - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - (NXdata)distribution: - doc: | - The wavelength or energy distribution of the source - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. - - .. image:: source/source.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 039c5318d84993a4f6151230f9a20ae19276d21bf2d8552e450f1a5eb0c810ad -# -# -# -# -# The neutron or x-ray storage ring/facility. -# -# -# Effective distance from sample -# Distance as seen by radiation from sample. This number should be negative -# to signify that it is upstream of the sample. -# -# -# -# Name of source -# -# short name for source, perhaps the acronym -# -# -# -# type of radiation source (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# type of radiation probe (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# Source power -# -# -# Source emittance (nm-rad) in X (horizontal) direction. -# -# -# Source emittance (nm-rad) in Y (horizontal) direction. -# -# -# particle beam size in x -# -# -# particle beam size in y -# -# -# Source intensity/area (example: s-1 cm-2) -# -# -# -# Source energy. -# For storage rings, this would be the particle beam energy. -# For X-ray tubes, this would be the excitation voltage. -# -# -# -# Accelerator, X-ray tube, or storage ring current -# -# -# Accelerator voltage -# -# -# Frequency of pulsed source -# -# -# Period of pulsed source -# -# -# Pulsed source target material -# -# -# -# -# -# -# -# -# -# -# -# -# any source/facility related messages/events that -# occurred during the experiment -# -# -# -# -# For storage rings, description of the bunch pattern. -# This is useful to describe irregular bunch patterns. -# -# name of the bunch pattern -# -# -# For storage rings, the number of bunches in use. -# -# -# For storage rings, temporal length of the bunch -# -# -# For storage rings, time between bunches -# -# -# temporal width of source pulse -# -# -# source pulse shape -# -# -# source operating mode -# -# for storage rings -# for storage rings -# -# -# -# -# Is the synchrotron operating in top_up mode? -# -# -# For storage rings, the current at the end of the most recent injection. -# date and time of the most recent injection. -# -# -# -# "Engineering" location of source. -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# The wavelength or energy distribution of the source -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the -# z axis. -# -# .. image:: source/source.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXsubentry.yaml b/base_classes/nyaml/NXsubentry.yaml deleted file mode 100644 index 248111e211..0000000000 --- a/base_classes/nyaml/NXsubentry.yaml +++ /dev/null @@ -1,344 +0,0 @@ -category: base -doc: | - Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. - - ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` - and is used as the (overlay) location for application definitions. - Use a separate ``NXsubentry`` for each application definition. - - To use ``NXsubentry`` with a hypothetical application definition - called ``NXmyappdef``: - - * Create a group with attribute ``NX_class="NXsubentry"`` - * Within that group, create a field called ``definition="NXmyappdef"``. - * There are two optional attributes of definition: ``version`` and ``URL`` - - The intended use is to define application definitions for a - multi-modal (a.k.a. multi-technique) :ref:`NXentry`. - Previously, an application definition - replaced :ref:`NXentry` with its own definition. - With the increasing popularity of instruments combining - multiple techniques for data collection (such as SAXS/WAXS instruments), - it was recognized the application definitions must be entered in the NeXus - data file tree as children of :ref:`NXentry`. -type: group -NXsubentry(NXobject): - \@default: - doc: | - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXdata` group contains the data - to be shown by default. - It is used to resolve ambiguity when - one :ref:`NXdata` group exists. - The value :ref:`names ` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 ` - section. - \@IDF_Version: - - # as ratified at NIAC2010 - doc: | - ISIS Muon IDF_Version - title: - doc: | - Extended title for entry - experiment_identifier: - doc: | - Unique identifier for the experiment, defined by - the facility, possibly linked to the proposals - experiment_description: - doc: | - Brief summary of the experiment, including key objectives. - (NXnote)experiment_documentation: - doc: | - Description of the full experiment (document in pdf, latex, ...) - collection_identifier: - doc: | - User or Data Acquisition defined group of NeXus files or :ref:`NXentry` - collection_description: - doc: | - Brief summary of the collection, including grouping criteria. - entry_identifier: - doc: | - unique identifier for the measurement, defined by the facility. - definition: - doc: | - Official NeXus NXDL schema to which this subentry conforms - \@version: - doc: | - NXDL version number - \@URL: - doc: | - URL of NXDL file - definition_local: - doc: | - Local NXDL schema extended from the subentry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the subentry. - \@version: - doc: | - NXDL version number - \@URL: - doc: | - URL of NXDL file - start_time(NX_DATE_TIME): - doc: | - Starting time of measurement - end_time(NX_DATE_TIME): - doc: | - Ending time of measurement - duration(NX_INT): - unit: NX_TIME - doc: | - Duration of measurement - collection_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - run_cycle: - doc: | - Such as "2007-3". Some user facilities organize their beam time into run cycles. - program_name: - doc: | - Name of program used to generate this file - \@version: - doc: | - Program version number - \@configuration: - doc: | - configuration of the program - revision: - doc: | - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - \@comment: - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - notes(NXnote): - doc: | - Notes describing entry - thumbnail(NXnote): - doc: | - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - \@mime_type: - doc: | - The value should be an ``image/*`` - - # This is not perfect. - # How do we set a default value for the mime_type attribute? - enumeration: [image/*] - (NXuser): - (NXsample): - (NXinstrument): - (NXcollection): - (NXmonitor): - (NXdata): - (NXparameters): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 73d58acb9360e8891346fefd2018fc630e5216eb27617d7dc5aec05808025224 -# -# -# -# -# -# -# -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXdata` group contains the data -# to be shown by default. -# It is used to resolve ambiguity when -# one :ref:`NXdata` group exists. -# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus group. -# -# For more information about how NeXus identifies the default -# plottable data, see the -# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` -# section. -# -# -# -# -# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. -# -# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` -# and is used as the (overlay) location for application definitions. -# Use a separate ``NXsubentry`` for each application definition. -# -# To use ``NXsubentry`` with a hypothetical application definition -# called ``NXmyappdef``: -# -# * Create a group with attribute ``NX_class="NXsubentry"`` -# * Within that group, create a field called ``definition="NXmyappdef"``. -# * There are two optional attributes of definition: ``version`` and ``URL`` -# -# The intended use is to define application definitions for a -# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. -# Previously, an application definition -# replaced :ref:`NXentry` with its own definition. -# With the increasing popularity of instruments combining -# multiple techniques for data collection (such as SAXS/WAXS instruments), -# it was recognized the application definitions must be entered in the NeXus -# data file tree as children of :ref:`NXentry`. -# -# -# -# -# ISIS Muon IDF_Version -# -# -# -# Extended title for entry -# -# -# -# Unique identifier for the experiment, defined by -# the facility, possibly linked to the proposals -# -# -# -# Brief summary of the experiment, including key objectives. -# -# -# Description of the full experiment (document in pdf, latex, ...) -# -# -# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` -# -# -# Brief summary of the collection, including grouping criteria. -# -# -# unique identifier for the measurement, defined by the facility. -# -# -# Official NeXus NXDL schema to which this subentry conforms -# NXDL version number -# URL of NXDL file -# -# -# -# Local NXDL schema extended from the subentry -# specified in the ``definition`` field. -# This contains any locally-defined, -# additional fields in the subentry. -# -# NXDL version number -# URL of NXDL file -# -# -# Starting time of measurement -# -# -# Ending time of measurement -# -# -# Duration of measurement -# -# -# -# Time transpired actually collecting data i.e. taking out time when collection was -# suspended due to e.g. temperature out of range -# -# -# -# Such as "2007-3". Some user facilities organize their beam time into run cycles. -# -# -# Name of program used to generate this file -# Program version number -# configuration of the program -# -# -# -# Revision id of the file due to re-calibration, reprocessing, new analysis, new -# instrument definition format, ... -# -# -# -# -# -# This is the flightpath before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# Notes describing entry -# -# -# -# A small image that is representative of the entry. An example of this is a 640x480 -# jpeg image automatically produced by a low resolution plot of the NXdata. -# -# -# The value should be an ``image/*`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml deleted file mode 100644 index 0a5efe9061..0000000000 --- a/base_classes/nyaml/NXtransformations.yaml +++ /dev/null @@ -1,406 +0,0 @@ -category: base -doc: | - Collection of axis-based translations and rotations to describe a geometry. - May also contain axes that do not move and therefore do not have a transformation - type specified, but are useful in understanding coordinate frames within which - transformations are done, or in documenting important directions, such as the - direction of gravity. - - A nested sequence of transformations lists the translation and rotation steps - needed to describe the position and orientation of any movable or fixed device. - - There will be one or more transformations (axes) defined by one or more fields - for each transformation. Transformations can also be described by NXlog groups when - the values change with time. The all-caps name ``AXISNAME`` designates the - particular axis generating a transformation (e.g. a rotation axis or a translation - axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the - units will be appropriate to the ``transformation_type`` attribute: - - * ``NX_LENGTH`` for ``translation`` - * ``NX_ANGLE`` for ``rotation`` - * ``NX_UNITLESS`` for axes for which no transformation type is specified - - This class will usually contain all axes of a sample stage or goniometer or - a detector. The NeXus default McSTAS coordinate frame is assumed, but additional - useful coordinate axes may be defined by using axes for which no transformation - type has been specified. - - The entry point (``depends_on``) will be outside of this class and point to a - field in here. Following the chain may also require following ``depends_on`` - links to transformations outside, for example to a common base table. If - a relative path is given, it is relative to the group enclosing the ``depends_on`` - specification. - - For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` - and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is - - .. math:: T_f = T_3 T_2 T_1 - - In explicit terms, the transformations are a subset of affine transformations - expressed as 4x4 matrices that act on homogeneous coordinates, :math:`w=(x,y,z,1)^T`. - - For rotation and translation, - - .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} - - where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, - :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and - :math:`t` is the translation vector. - - :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` - attribute multiplied by the field value, and :math:`R` is defined as a rotation - about an axis in the direction of ``vector``, of angle of the field value. - - NOTE - - One possible use of ``NXtransformations`` is to define the motors and - transformations for a diffractometer (goniometer). Such use is mentioned - in the ``NXinstrument`` base class. Use one ``NXtransformations`` group - for each diffractometer and name the group appropriate to the device. - Collecting the motors of a sample table or xyz-stage in an NXtransformations - group is equally possible. - - - Following the section on the general dscription of axis in NXtransformations is a section which - documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever - there is a need for positioning a beam line component please use the existing names. Use as many fields - as needed in order to position the component. Feel free to add more axis if required. In the description - given below, only those atttributes which are defined through the name are spcified. Add the other attributes - of the full set: - - * vector - * offset - * transformation_type - * depends_on - - as needed. -type: group -ignoreExtraGroups: true -ignoreExtraFields: true -ignoreExtraAttributes: true -NXtransformations(NXobject): - AXISNAME(NX_NUMBER): - nameType: any - unit: NX_TRANSFORMATION - exists: ['max', 'unbounded'] - doc: | - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - \@transformation_type: - exists: optional - doc: | - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - - # - enumeration: [translation, rotation] - \@vector: - exists: optional - type: NX_NUMBER - doc: | - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - dimensions: - rank: 1 - dim: [[1, 3]] - \@offset: - type: NX_NUMBER - doc: | - A fixed offset applied before the transformation (three vector components). - This is not intended to be a substitute for a fixed ``translation`` axis but, for example, - as the mechanical offset from mounting the axis to its dependency. - dimensions: - rank: 1 - dim: [[1, 3]] - \@offset_units: - type: NX_CHAR - doc: | - Units of the offset. Values should be consistent with NX_LENGTH. - \@depends_on: - type: NX_CHAR - doc: | - Points to the path to a field defining the axis on which this - depends or the string ".". - \@equipment_component: - type: NX_CHAR - doc: | - An arbitrary identifier of a component of the equipment to which - the transformation belongs, such as 'detector_arm' or 'detector_module'. - NXtransformations with the same equipment_component label form a logical - grouping which can be combined together into a single change-of-basis - operation. - AXISNAME_end(NX_NUMBER): - unit: NX_TRANSFORMATION - nameType: any - exists: ['min', '0'] - doc: | - ``AXISNAME_end`` is a placeholder for a name constructed from the actual - name of an axis to which ``_end`` has been appended. - - The values in this field are the end points of the motions that start - at the corresponding positions given in the ``AXISNAME`` field. - AXISNAME_increment_set(NX_NUMBER): - unit: NX_TRANSFORMATION - nameType: any - exists: ['min', '0'] - doc: | - ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual - name of an axis to which ``_increment_set`` has been appended. - - The value of this optional field is the intended average range through which - the corresponding axis moves during the exposure of a frame. Ideally, the - value of this field added to each value of ``AXISNAME`` would agree with the - corresponding values of ``AXISNAME_end``, but there is a possibility of significant - differences. Use of ``AXISNAME_end`` is recommended. - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f47cb808914aa3b75fb05b4c97d8f4ff4c1c08478e44a502c50e2ca5b50682c3 -# -# -# -# -# -# -# Collection of axis-based translations and rotations to describe a geometry. -# May also contain axes that do not move and therefore do not have a transformation -# type specified, but are useful in understanding coordinate frames within which -# transformations are done, or in documenting important directions, such as the -# direction of gravity. -# -# A nested sequence of transformations lists the translation and rotation steps -# needed to describe the position and orientation of any movable or fixed device. -# -# There will be one or more transformations (axes) defined by one or more fields -# for each transformation. Transformations can also be described by NXlog groups when -# the values change with time. The all-caps name ``AXISNAME`` designates the -# particular axis generating a transformation (e.g. a rotation axis or a translation -# axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the -# units will be appropriate to the ``transformation_type`` attribute: -# -# * ``NX_LENGTH`` for ``translation`` -# * ``NX_ANGLE`` for ``rotation`` -# * ``NX_UNITLESS`` for axes for which no transformation type is specified -# -# This class will usually contain all axes of a sample stage or goniometer or -# a detector. The NeXus default McSTAS coordinate frame is assumed, but additional -# useful coordinate axes may be defined by using axes for which no transformation -# type has been specified. -# -# The entry point (``depends_on``) will be outside of this class and point to a -# field in here. Following the chain may also require following ``depends_on`` -# links to transformations outside, for example to a common base table. If -# a relative path is given, it is relative to the group enclosing the ``depends_on`` -# specification. -# -# For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` -# and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is -# -# .. math:: T_f = T_3 T_2 T_1 -# -# In explicit terms, the transformations are a subset of affine transformations -# expressed as 4x4 matrices that act on homogeneous coordinates, :math:`w=(x,y,z,1)^T`. -# -# For rotation and translation, -# -# .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} -# -# where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, -# :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and -# :math:`t` is the translation vector. -# -# :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` -# attribute multiplied by the field value, and :math:`R` is defined as a rotation -# about an axis in the direction of ``vector``, of angle of the field value. -# -# NOTE -# -# One possible use of ``NXtransformations`` is to define the motors and -# transformations for a diffractometer (goniometer). Such use is mentioned -# in the ``NXinstrument`` base class. Use one ``NXtransformations`` group -# for each diffractometer and name the group appropriate to the device. -# Collecting the motors of a sample table or xyz-stage in an NXtransformations -# group is equally possible. -# -# -# Following the section on the general dscription of axis in NXtransformations is a section which -# documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever -# there is a need for positioning a beam line component please use the existing names. Use as many fields -# as needed in order to position the component. Feel free to add more axis if required. In the description -# given below, only those atttributes which are defined through the name are spcified. Add the other attributes -# of the full set: -# -# * vector -# * offset -# * transformation_type -# * depends_on -# -# as needed. -# -# -# -# Units need to be appropriate for translation or rotation -# -# The name of this field is not forced. The user is free to use any name -# that does not cause confusion. When using more than one ``AXISNAME`` field, -# make sure that each field name is unique in the same group, as required -# by HDF5. -# -# The values given should be the start points of exposures for the corresponding -# frames. The end points should be given in ``AXISNAME_end``. -# -# -# -# The transformation_type may be ``translation``, in which case the -# values are linear displacements along the axis, ``rotation``, -# in which case the values are angular rotations around the axis. -# -# If this attribute is omitted, this is an axis for which there -# is no motion to be specifies, such as the direction of gravity, -# or the direction to the source, or a basis vector of a -# coordinate frame. -# -# -# -# -# -# -# -# -# -# Three values that define the axis for this transformation. -# The axis should be normalized to unit length, making it -# dimensionless. For ``rotation`` axes, the direction should be -# chosen for a right-handed rotation with increasing angle. -# For ``translation`` axes the direction should be chosen for -# increasing displacement. For general axes, an appropriate direction -# should be chosen. -# -# -# -# -# -# -# -# A fixed offset applied before the transformation (three vector components). -# This is not intended to be a substitute for a fixed ``translation`` axis but, for example, -# as the mechanical offset from mounting the axis to its dependency. -# -# -# -# -# -# -# -# Units of the offset. Values should be consistent with NX_LENGTH. -# -# -# -# -# Points to the path to a field defining the axis on which this -# depends or the string ".". -# -# -# -# -# An arbitrary identifier of a component of the equipment to which -# the transformation belongs, such as 'detector_arm' or 'detector_module'. -# NXtransformations with the same equipment_component label form a logical -# grouping which can be combined together into a single change-of-basis -# operation. -# -# -# -# -# -# ``AXISNAME_end`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_end`` has been appended. -# -# The values in this field are the end points of the motions that start -# at the corresponding positions given in the ``AXISNAME`` field. -# -# -# -# -# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_increment_set`` has been appended. -# -# The value of this optional field is the intended average range through which -# the corresponding axis moves during the exposure of a frame. Ideally, the -# value of this field added to each value of ``AXISNAME`` would agree with the -# corresponding values of ``AXISNAME_end``, but there is a possibility of significant -# differences. Use of ``AXISNAME_end`` is recommended. -# -# -# -# -# .. 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/nyaml/NXtranslation.yaml b/base_classes/nyaml/NXtranslation.yaml deleted file mode 100644 index 99b08fc4fe..0000000000 --- a/base_classes/nyaml/NXtranslation.yaml +++ /dev/null @@ -1,102 +0,0 @@ -category: base -doc: | - legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. -type: group -NXtranslation(NXobject): - geometry(NXgeometry): - doc: | - Link to other object if we are relative, else absent - distances(NX_FLOAT): - unit: NX_LENGTH - doc: | - (x,y,z) - This field describes the lateral movement of a component. - The pair of groups NXtranslation and NXorientation together - describe the position of a component. - For absolute position, the origin is the scattering center (where a perfectly - aligned sample would be) with the z-axis pointing downstream and the y-axis - pointing gravitationally up. For a relative position the NXtranslation is - taken into account before the NXorientation. The axes are right-handed and - orthonormal. - dimensions: - dim: [[1, numobj], [2, 3]] - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3d64610ba1f1776cf277b5aca7e63bf3e504ed9a3f558bf28241565df29d6cc1 -# -# -# -# -# -# legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. -# -# -# Link to other object if we are relative, else absent -# -# -# -# (x,y,z) -# This field describes the lateral movement of a component. -# The pair of groups NXtranslation and NXorientation together -# describe the position of a component. -# For absolute position, the origin is the scattering center (where a perfectly -# aligned sample would be) with the z-axis pointing downstream and the y-axis -# pointing gravitationally up. For a relative position the NXtranslation is -# taken into account before the NXorientation. The axes are right-handed and -# orthonormal. -# -# -# -# -# -# -# -# -# .. 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/nyaml/NXuser.yaml b/base_classes/nyaml/NXuser.yaml deleted file mode 100644 index 383a8e9d17..0000000000 --- a/base_classes/nyaml/NXuser.yaml +++ /dev/null @@ -1,145 +0,0 @@ -category: base -doc: | - Contact information for a user. - - The format allows more - than one user with the same affiliation and contact information, - but a second :ref:`NXuser` group should be used if they have different - affiliations, etc. -type: group -NXuser(NXobject): - name: - doc: | - Name of user responsible for this entry - role: - doc: | - Role of user responsible for this entry. - Suggested roles are "local_contact", - "principal_investigator", and "proposer" - affiliation: - doc: | - Affiliation of user - address: - doc: | - Address of user - telephone_number: - doc: | - Telephone number of user - fax_number: - doc: | - Fax number of user - email: - doc: | - Email of user - facility_user_id: - doc: | - facility based unique identifier for this person - e.g. their identification code on the facility - address/contact database - ORCID: - doc: | - an author code, Open Researcher and Contributor ID, - defined by https://orcid.org and expressed as a URI - \@default: - doc: | - .. 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 095127b2420c5cc3523306d64ff34d05b413ff6c5aa8b3fcb470cba610d93e6a -# -# -# -# -# -# Contact information for a user. -# -# The format allows more -# than one user with the same affiliation and contact information, -# but a second :ref:`NXuser` group should be used if they have different -# affiliations, etc. -# -# -# Name of user responsible for this entry -# -# -# -# Role of user responsible for this entry. -# Suggested roles are "local_contact", -# "principal_investigator", and "proposer" -# -# -# -# Affiliation of user -# -# -# Address of user -# -# -# Telephone number of user -# -# -# Fax number of user -# -# -# Email of user -# -# -# -# facility based unique identifier for this person -# e.g. their identification code on the facility -# address/contact database -# -# -# -# -# an author code, Open Researcher and Contributor ID, -# defined by https://orcid.org and expressed as a URI -# -# -# -# -# .. 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/nyaml/NXvelocity_selector.yaml b/base_classes/nyaml/NXvelocity_selector.yaml deleted file mode 100644 index 824a94f9bd..0000000000 --- a/base_classes/nyaml/NXvelocity_selector.yaml +++ /dev/null @@ -1,198 +0,0 @@ -category: base -doc: | - A neutron velocity selector -type: group -NXvelocity_selector(NXobject): - type: - doc: | - velocity selector type - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - velocity selector rotation speed - radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - radius at beam centre - spwidth(NX_FLOAT): - unit: NX_LENGTH - doc: | - spoke width at beam centre - length(NX_FLOAT): - unit: NX_LENGTH - doc: | - rotor length - num(NX_INT): - unit: NX_UNITLESS - doc: | - number of spokes/lamella - twist(NX_FLOAT): - unit: NX_ANGLE - doc: | - twist angle along axis - table(NX_FLOAT): - unit: NX_ANGLE - doc: | - offset vertical angle - height(NX_FLOAT): - unit: NX_LENGTH - doc: | - input beam height - width(NX_FLOAT): - unit: NX_LENGTH - doc: | - input beam width - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - wavelength - wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - deviation FWHM /Wavelength - (NXgeometry)geometry: - deprecated: - Use the field `depends_on` and :ref:`NXtransformations` to position the velocity selector and NXoff_geometry to describe its shape instead - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a velocity selector. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a279cfc81cdbfe08cac7842689855bf0a197c1861b8872616295751eaab26e12 -# -# -# -# -# A neutron velocity selector -# -# velocity selector type -# -# -# velocity selector rotation speed -# -# -# radius at beam centre -# -# -# spoke width at beam centre -# -# -# rotor length -# -# -# number of spokes/lamella -# -# -# twist angle along axis -# -# -# offset vertical angle -# -# -# input beam height -# -# -# input beam width -# -# -# wavelength -# -# -# deviation FWHM /Wavelength -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a velocity selector. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXxraylens.yaml b/base_classes/nyaml/NXxraylens.yaml deleted file mode 100644 index f08f4867fc..0000000000 --- a/base_classes/nyaml/NXxraylens.yaml +++ /dev/null @@ -1,220 +0,0 @@ -category: base -doc: | - An X-ray lens, typically at a synchrotron X-ray beam line. - - Based on information provided by Gerd Wellenreuther (DESY). -type: group -NXxraylens(NXobject): - lens_geometry(NX_CHAR): - doc: | - Geometry of the lens - enumeration: [paraboloid, spherical, elliptical, hyperbolical] - symmetric(NX_BOOLEAN): - doc: | - Is the device symmetric? - cylindrical(NX_BOOLEAN): - doc: | - Is the device cylindrical? - cylinder_orientation(NXnote): - doc: | - Orientation of the cylinder axis. - focus_type(NX_CHAR): - doc: | - The type of focus of the lens - enumeration: [line, point] - lens_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the lens - lens_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Length of the lens - curvature(NX_FLOAT): - unit: NX_LENGTH - doc: | - Radius of the curvature as measured in the middle of the lens - aperture(NX_FLOAT): - unit: NX_LENGTH - doc: | - Diameter of the lens. - number_of_lenses(NX_INT): - doc: | - Number of lenses that make up the compound lens. - lens_material(NX_CHAR): - doc: | - Material used to make the lens. - gas(NX_CHAR): - doc: | - Gas used to fill the lens - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Gas pressure in the lens - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. 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. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a x-ray lens. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 289923b77926b2d3ad18298238dbafdbb5bb6f038e6d25947224cd1e39a0c04d -# -# -# -# -# -# -# An X-ray lens, typically at a synchrotron X-ray beam line. -# -# Based on information provided by Gerd Wellenreuther (DESY). -# -# -# Geometry of the lens -# -# -# -# -# -# -# -# -# -# Is the device symmetric? -# -# -# -# -# Is the device cylindrical? -# -# -# -# -# Orientation of the cylinder axis. -# -# -# -# -# The type of focus of the lens -# -# -# -# -# -# -# -# Thickness of the lens -# -# -# Length of the lens -# -# -# Radius of the curvature as measured in the middle of the lens -# -# -# Diameter of the lens. -# -# -# Number of lenses that make up the compound lens. -# -# -# Material used to make the lens. -# -# -# Gas used to fill the lens -# -# -# Gas pressure in the lens -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. 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. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a x-ray lens. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/contributed_definitions/nyaml/NXaberration.yaml b/contributed_definitions/nyaml/NXaberration.yaml deleted file mode 100644 index 69f2717ef9..0000000000 --- a/contributed_definitions/nyaml/NXaberration.yaml +++ /dev/null @@ -1,29 +0,0 @@ -category: base -doc: | - Quantified aberration coefficient in an aberration_model. - -type: group -(NXobject)NXaberration: - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - doc: | - Confidence - unit: NX_LENGTH - uncertainty_model: - doc: | - How was the uncertainty quantified e.g. via the 95% confidence interval. - delta_time(NX_FLOAT): - doc: | - Time elapsed since the last measurement. - unit: NX_TIME - angle(NX_FLOAT): - doc: | - For the CEOS definitions the C aberrations are radial-symmetric and have no - angle entry, while the A, B, D, S, or R aberrations are n-fold - symmetric and have an angle entry. - For the NION definitions the coordinate system differs to the one - used in CEOS and instead two aberration coefficients a and b are used. - unit: NX_ANGLE - name: - alias: \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXaberration_model.yaml b/contributed_definitions/nyaml/NXaberration_model.yaml deleted file mode 100644 index 3cbd599f2d..0000000000 --- a/contributed_definitions/nyaml/NXaberration_model.yaml +++ /dev/null @@ -1,66 +0,0 @@ -category: base -doc: | - Models for aberrations of electro-magnetic lenses in electron microscopy. - - See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the - CEOS definitions. -type: group -(NXobject)NXaberration_model: - model: - enumeration: [ceos, nion] - (NXaberration): - - c_1_0(NX_FLOAT): - unit: NX_LENGTH - doc: | - Defocus - c_1_2_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Two-fold astigmatism - c_1_2_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Two-fold astigmatism - c_2_1_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Second-order axial coma - c_2_1_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Second-order axial coma - c_2_3_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threefold astigmatism - c_2_3_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threefold astigmatism - c_3_0(NX_FLOAT): - unit: NX_LENGTH - doc: | - Spherical aberration - c_3_2_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Star aberration - c_3_2_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Star aberration - c_3_4_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Fourfold astigmatism - c_3_4_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Fourfold astigmatism - c_5_0(NX_FLOAT): - unit: NX_LENGTH - doc: | - Fifth-order spherical aberration diff --git a/contributed_definitions/nyaml/NXaberration_model_ceos.yaml b/contributed_definitions/nyaml/NXaberration_model_ceos.yaml deleted file mode 100644 index c89b0d0d7f..0000000000 --- a/contributed_definitions/nyaml/NXaberration_model_ceos.yaml +++ /dev/null @@ -1,70 +0,0 @@ -category: base -doc: | - CEOS definitions/model for aberrations of electro-magnetic lenses. - - See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the - CEOS definitions. - -type: group -(NXobject)NXaberration_model_ceos: - model: - enumeration: [ceos] - c_1(NXaberration): # Defocus - a_1(NXaberration): # Two-fold astigmatism - b_2(NXaberration): # Second-order axial coma - a_2(NXaberration): # Threefold astigmatism - c_3(NXaberration): # Spherical aberration - s_3(NXaberration): # Star aberration - a_3(NXaberration): # Fourfold astigmatism - # based on feedback from Thilo Remmele the following aberrations could be measured (enhanced mode, tilt angle > 30 mrad) but are not corrected - b_4(NXaberration): # Fourth-order axial coma - d_4(NXaberration): # Three-lobe aberration - a_4(NXaberration): # Fivefold astigmatism - c_5(NXaberration): # Fifth-order spherical aberration - s_5(NXaberration): # Fifth-order star aberration - r_5(NXaberration): # Rosette aberration - a_6(NXaberration): # Sixfold astigmatism - -# further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) -# ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes -# Aberration naming schema: C_order_multiplicity (similar to NXem, but with -# another coordinate system and in addition with a confidence entry. -# Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) -# contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space -# aberration function: -# Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] -# +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) -# +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] -# +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f - -# Thilo Remmele also mentions that there is a mapping of aberration coefficient names: -# C_2_0 -> C1 Defocus -# C_2_2 -> A1 2-fold astigmatism -# C_3_3 -> A2 3-fold astigmatism -# C_3_1 -> B2 axial coma -# C_4_0 -> C3 spherical aberration -# C_4_4 -> A3 4-fold astigmatism -# C_4_2 -> S3 star aberration -# C_5_5 -> A4 5-fold astigmatism - -# C_5_1 -> B4 axial coma -# C_5_3 -> D4 three lobe aberration -# C_6_0 -> C5 spherical aberration -# C_6_2 -> S5 star aberration -# C_6_4 -> R5 rosette aberration -# C_6_6 -> A5 6-fold astigmatism - -# In a session with HRTEM images the corrector is commonly aligned. -# The final measurement with the estimated residual aberrations -# should be saved in a corrector.html file (an example is appended -# at the end of this file. Unfortunately the datetime is not included -# in that html output, nor is the used outer tilt angle and exposure time. -# The datetime may be estimated from the file datetime and the Delta t entry, -# but caution if that datetime is not preserved on file transfers! -# More than one detector entry could occure but is not common. -# A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. -# It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. -# The corrector entry of the nexus em definition lacks the confidence information and the -# parameter settings for the estimation oft the aberrations. diff --git a/contributed_definitions/nyaml/NXaberration_model_nion.yaml b/contributed_definitions/nyaml/NXaberration_model_nion.yaml deleted file mode 100644 index 832ec9f875..0000000000 --- a/contributed_definitions/nyaml/NXaberration_model_nion.yaml +++ /dev/null @@ -1,38 +0,0 @@ -category: base -doc: | - NION definitions/model for aberrations of electro-magnetic lenses. - - See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the - CEOS definitions. - -type: group -(NXobject)NXaberration_model_nion: - model: - enumeration: [nion] - c_1_0(NXaberration): # Defocus - c_1_2_a(NXaberration): # Two-fold astigmatism - c_1_2_b(NXaberration): # Two-fold astigmatism - c_2_1_a(NXaberration): # Second-order axial coma - c_2_1_b(NXaberration): # Second-order axial coma - c_2_3_a(NXaberration): # Threefold astigmatism - c_2_3_b(NXaberration): # Threefold astigmatism - c_3_0(NXaberration): # Spherical aberration - c_3_2_a(NXaberration): # Star aberration - c_3_2_b(NXaberration): # Star aberration - c_3_4_a(NXaberration): # Fourfold astigmatism - c_3_4_b(NXaberration): # Fourfold astigmatism - c_4_1_a(NXaberration): # Fourth-order axial coma - c_4_1_b(NXaberration): # Fourth-order axial coma - c_4_3_a(NXaberration): # Three-lobe aberration - c_4_3_b(NXaberration): # Three-lobe aberration - c_4_5_a(NXaberration): # Fivefold astigmatism - c_4_5_b(NXaberration): # Fivefold astigmatism - c_5_0(NXaberration): # Fifth-order spherical aberration - c_5_2_a(NXaberration): # Fifth-order star aberration - c_5_2_b(NXaberration): # Fifth-order star aberration - c_5_4_a(NXaberration): # Rosette aberration - c_5_4_b(NXaberration): # Rosette aberration - c_5_6_a(NXaberration): # Sixfold astigmatism - c_5_6_b(NXaberration): # Sixfold astigmatism diff --git a/contributed_definitions/nyaml/NXadc.yaml b/contributed_definitions/nyaml/NXadc.yaml deleted file mode 100644 index 7d6e08bf3c..0000000000 --- a/contributed_definitions/nyaml/NXadc.yaml +++ /dev/null @@ -1,10 +0,0 @@ -category: base -doc: | - Analog-to-digital converter component/integrated circuit. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXadc: - value(NX_NUMBER): - doc: | - TBD. - unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXaperture_em.yaml b/contributed_definitions/nyaml/NXaperture_em.yaml deleted file mode 100644 index 203463f9e9..0000000000 --- a/contributed_definitions/nyaml/NXaperture_em.yaml +++ /dev/null @@ -1,27 +0,0 @@ -category: base -# extends: NXaperture -doc: | - Details of an individual aperture for beams in electron microscopy. -NXaperture_em: - name: - doc: Given name/alias of the aperture. - value(NX_NUMBER): - doc: | - Relevant value from the control software. - - This is not always just the diameter of (not even in the case) - of a circular aperture. Usually it is a mode setting value which - is selected in the control software. - Which settings are behind the value should be defined - for now in the description field, if these are known - in more detail. - unit: NX_ANY - description: - doc: | - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details. Alternatively a free-text field. - (NXfabrication): - (NXtransformations): - doc: | - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml deleted file mode 100644 index 42094b1d02..0000000000 --- a/contributed_definitions/nyaml/NXapm.yaml +++ /dev/null @@ -1,1549 +0,0 @@ -category: application -doc: | - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: Total number of ions collected. - n_dld_wires: Total number of independent wires in the delay-line detector. - n_support: Number of support points for e.g. modeling peaks. - n_ivec_max: | - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - n_ranges: | - Number of mass-to-charge-state-ratio intervals of this ion type. - n_x: Number of bins in the x direction. - n_y: Number of bins in the y direction. - n_z: Number of bins in the z direction. - n_bins: Number of bins. - n_topology: Total number of integers in the supplementary XDMF topology array. -# some consistence is not yet achieved with IFES_APT_TC APT HDF5 v1 format -# Language precision: Keywords such as “must” “required” “should”, etc are as per RFC-2119 [RFC2119]. https://tools.ietf.org/html/rfc2119 -# https://gitlab.com/apt_software_toolbox/apt-hdf5 an implementation for an -# IFES APT TC APT HDF5 v1 verifier -# NEW ISSUE: possible offspring application definitions: -# NXapm_opt/pl would be possible, as soon as NXluminescence by Carola Emminger and Florian Dobner is ready whereby -# then there would be two subentries one for an NXapm and one for NXphotoluminesence to capture the photonic atom probe of Rouen/GPM -# and finally if there were an NXapm_afm for atomic force microscopy the IMEC AFM/APT experiments could be stored with an NXapm_afm application definition -# with NXapm and NXafm being respective subentries of the appdef but as NXapm_afm is a step-by-step approach one would have to release the constraint -# that only a single measurement can be performed. -# NXasat which could just take two subentries NXem and NXapm -# NXasat should be a fuse of NXapm and NXem within an NXentry with NXsubentry, in this way we can combine the strength of both application definitions -# to describe also the upcoming technique of atomic scale analytical tomography https://doi.org/10.1017/9781316677292 - -NXapm: - (NXentry): - exists: [min, 1, max, infty] - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - # enumeration: [sha_256_hash] - definition: - doc: NeXus NXDL schema to which this file conforms. - enumeration: [NXapm] - experiment_identifier: - doc: | - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - experiment_description: - exists: optional - doc: | - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - # These computations can take advantage of individual time stamps - # in NXevent_em instances to provide additional pieces of information. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - # NEW ISSUE: fields like duration need a clearer description as to how these - # quantities should be defined. Most atom probers do not care for this other - # than getting an approximate hour-accurate estimate of the time how long it - # took to evaporate the specimen. - # several programs and libraries are usually coupled together for LEAP instruments, - # if it is possible to have a different root version with a different ivas/apsuite - # version that having a single program and version field is not enough but multiple - # are required LAS root version camecaroot version analysis software - - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - run_number: - exists: recommended - doc: | - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - experiment_documentation(NXnote): - exists: optional - doc: | - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - thumbnail(NXnote): - exists: optional - doc: | - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - \@type: - operation_mode: - doc: | - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - enumeration: [apt, fim, apt_fim, other] - # description: - # exists: optional - # doc: | - (NXuser): - exists: [min, 0, max, infty] - doc: | - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - name: - doc: Given (first) name and surname of the user. - affiliation: - exists: recommended - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. - address: - exists: recommended - doc: Postal address of the affiliation. - email: - exists: recommended - doc: | - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - orcid: - exists: recommended - doc: | - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - orcid_platform: - exists: recommended - doc: | - Name of the OrcID or ResearcherID where the account - under orcid is registered. - telephone_number: - exists: optional - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - role: - exists: recommended - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - social_media_name: - exists: optional - doc: | - Account name that is associated with the user - in social media platforms. - social_media_platform: - exists: optional - doc: | - Name of the social media platform where the account - under social_media_name is registered. - sample(NXsample): - exists: recommended - doc: | - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - grain_diameter(NX_FLOAT): - exists: optional - doc: | - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - unit: NX_LENGTH - grain_diameter_error(NX_FLOAT): - exists: optional - doc: | - Magnitude of the standard deviation of the grain_diameter. - unit: NX_LENGTH - heat_treatment_temperature(NX_FLOAT): - exists: optional - doc: | - The temperature of the last heat treatment step before quenching. - Knowledge about this value can give an idea how the sample - was heat treated, however if available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - unit: NX_TEMPERATURE - heat_treatment_temperature_error(NX_FLOAT): - exists: optional - doc: | - Magnitude of the standard deviation of the heat_treatment_temperature. - unit: NX_TEMPERATURE - heat_treatment_quenching_rate(NX_FLOAT): - exists: optional - doc: | - Rate of the last quenching step. - Knowledge about this value can give an idea how the specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - unit: NX_ANY - heat_treatment_quenching_rate_error(NX_FLOAT): - exists: optional - doc: | - Magnitude of the standard deviation of the heat_treatment_quenching_rate. - unit: NX_ANY - description: - exists: optional - (NXchemical_composition): - exists: recommended - doc: | - The chemical composition of the sample. Typically it is assumed that - this more macroscopic composition is representative for the material - so that the composition of the typically substantially less voluminous - specimen probes from the more voluminous sample. - normalization: - doc: | - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - enumeration: [atom_percent, weight_percent] - ION(NXion): - exists: [min, 1, max, 118] - name: - doc: | - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - composition(NX_FLOAT): - doc: | - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - unit: NX_DIMENSIONLESS - composition_error(NX_FLOAT): - exists: optional - doc: | - Magnitude of the standard deviation of the composition (value). - unit: NX_DIMENSIONLESS - specimen(NXsample): - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - # NEW ISSUE: addition of a NXfurnace in which one can define the atmosphere - # and partial pressures of the agents in that atmosphere with which the - # sample was annealed at which temperature see the work happening at PNNL - # NEW ISSUE: it would be good to have an application definition NXicp for chemical composition - name: - doc: | - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - sample_history: - exists: recommended - doc: | - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - preparation_date(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - alias: - exists: optional - doc: | - Short_name or abbreviation of the specimen name field. - atom_types: - doc: | - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - description: - exists: optional - doc: | - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - is_polycrystalline(NX_BOOLEAN): - exists: recommended - doc: | - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - # NEW ISSUE: error model - # NEW ISSUE: use Andrea and MarkusK groups for - # describing the geometry of the sample - (NXdata): - exists: optional - doc: | - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - (NXcoordinate_system_set): - exists: recommended - doc: | - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - # Spatial transformations are always active transformations; i.e. the location and direction of a vector in one coordinate system is expressed by the following transformation matrix, T Ptransformed = TPoriginal - # add a note about what is the tip space - #Conventions: right-handed, Cartesian, 3D Euclidean CS should be used Laboratory space to be set by This is the space that is set by the chassis of the instrument. The Z direction must be reasonably parallel to gravity (+ve defined to be gravity vector pointing towards lowest ground), but can be defined to be a direction that is nominally parallel to gravity during an experiment. The origin must be placed within a bounding box of the chassis. Tip space instead of specimen space, The space occupied by a tip in the neutral position when ready for analysis. Z+ should be located in the direction of the needle (apex is Z+ from needle centreline). i) If the specimen moves relative to the laboratory frame, and the electrode does not, or if no electrode is present, then the space should be defined such that when the tip is moved physically, it also moves through tip space. ii) If the electrode moves relative to the laboratory frame, then the space should be defined such that, in tip space, the electrode position does not change. - # iii) The transformation between laboratory space and Tip space must be describable by a fixed 3x3 transformation matrix. Detector space: This is a 2D space only, and contains X+ and Y+ directions. X+ and Y+ should indicate primary directions on the detector, and should be, for an equivalent straight-flight-path configuration, such that X+ and Y+ is matched to that of tip space. Laser space missing: Laser space: The coordinate frame describing the impinging wavefront on the sample. Z+ is the vector of the propagating wavefront. X+ is the orthogonal component of the tip direction within the tip-laser plane. The origin shall be placed at the best estimate for tip apex position at the start of the experiment. Reconstruction space : The space occupied by a correctly reconstructed dataset. X+ and Y+ should correspond to X+ and Y+ in the detector space. Z+ should be such that the needle centre line is normal to the detector position. The origin shall be placed at the tip apex. - TRANSFORMATIONS(NXtransformations): - exists: [min, 0, max, infty] - # NEW ISSUE: add Breen's Ultramicroscopy paper on atom probe crystallography - # in what follows each component of the instrument might be equipped with an NXmonitor - (NXmonitor): - exists: [min, 0, max, infty] - # NEW ISSUE ADD AS MANY MONITORS AS NEEDED, also for pressure etc. - # add a default plot V = f(time/evaporation_id), essentially for each quantity - atom_probe(NXinstrument): - doc: | - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - (NXcsg): - exists: optional - instrument_name: - doc: | - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - location: - exists: optional - doc: | - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - flight_path_length(NX_FLOAT): - doc: | - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - unit: NX_LENGTH - # NEW ISSUE: discussion depends on the type of instrument, - # straight flight path, curved, there were a few comments to made - # https://fairmat-experimental.github.io/nexus-fairmat-proposal/ - # 50433d9039b3f33299bab338998acb5335cd8951/classes/ - # contributed_definitions/NXapm.html - # where further details of the flight geometry should be recorded however - # in the majority of cases these data are not offered by APSuite and - # so far nobody has asked or seriously proceeded with how to use these - # pieces of information if they were to be stored - # MK::NEW ISSUE - field_of_view(NX_FLOAT): - exists: recommended - doc: | - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - unit: NX_LENGTH - (NXreflectron): - # check if doc string gets carried over doc: Device for reducing flight time differences of ions in ToF experiments. - applied(NX_BOOLEAN): - doc: | - Is a reflectron installed and was it used? - name: - exists: optional - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - description: - exists: recommended - (NXcsg): - exists: optional - # NEW ISSUE: flat_test_data(NXcollection): - # exists: recommended - # doc: NEED FOR FURTHER DISCUSSIONS WITH APM COLLEAGUES WHAT IS RELEVANT HERE. - # NEW ISSUE: have a place to be more specific about the geometry and - # usage of additional lenses: - # for the invizo 6000 instrument it makes sense to add at least groups for the two additional lenses whereby the field of view is brought from 50-60 to at most 100 the key invention - # add: decelerating_electrode(NXlens_em) accelerating_mesh maybe needs an own base class - # I suggest that this section should be reworked with the local_electrode being required and all other components and opposite counter_electrodes being optional WO2016171675A1 details the key specifications of the components and the setup - # see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 according to A. Breen (UNSW) - local_electrode(NXlens_em): - doc: | - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - name: - doc: | - Identifier of the local_electrode in an e.g. database. - (NXaperture_em): - exists: optional - name: - exists: recommended # ##MK::should become required - (NXfabrication): - exists: optional - identifier: - exists: recommended - capabilities: - exists: optional - value(NX_NUMBER): - exists: recommended # ##MK::should become required - (NXcsg): - exists: optional - # but the local_electrode does not really on purpose create a magnetic field, - # specific for an electro-magnetic lens is the symmetry of its field - # NEW ISSUE: for now keep that we have what is an NXlens_em - # NEW ISSUE: APEX MONITOR / LEAP distance monitoring - # NEW ISSUE: the definition of flat test data should be included and documented - # NEW ISSUE: local electrode, baking strategies, storage - ion_detector(NXdetector): - doc: | - Detector for taking raw time-of-flight and - ion/hit impact positions data. - type: - doc: | - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - # enumeration: [mcp_dld, phosphor_ccd, other] - name: - exists: recommended - doc: Given name/alias. - # NEW ISSUE: why not (NXfabrication) - model: - exists: recommended - doc: Given brand or model name by the manufacturer. - serial_number: - exists: recommended - doc: | - Given hardware name/serial number or hash identifier - issued by the manufacturer. - manufacturer_name: - exists: recommended - doc: Given name of the manufacturer. - signal_amplitude(NX_FLOAT): - exists: optional - doc: | - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - unit: NX_CURRENT - dimensions: - rank: 1 - dim: [[1, n_ions]] - (NXcsg): - exists: optional - pulser(NXpulser_apm): - # NEW ISSUE: other sources of pulsers are possible - # NEW ISSUE: see in WO2016171675A1 Invizo 6000 patent from AMETEK - pulse_mode: - pulse_frequency(NX_FLOAT): - pulse_fraction(NX_FLOAT): - pulsed_voltage(NX_FLOAT): - exists: recommended - standing_voltage(NX_FLOAT): - exists: recommended - (NXcsg): - exists: optional - SOURCE(NXsource): - exists: [min, 0, max, 2] - # INVIZO 6000 instrument have two symmetric lasers! so for these - # laser_gun and laser_beam exists: [min, 0, max, 2] - doc: | - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - name: - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - wavelength(NX_FLOAT): - exists: recommended - power(NX_FLOAT): - exists: recommended - pulse_energy(NX_FLOAT): - exists: recommended - (NXbeam): - exists: [min, 0, max, infty] - pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set - exists: recommended - spot_position(NXcollection): # NXsnapshot, NXcg_point_set - exists: recommended - - stage_lab(NXstage_lab): - # NEW ISSUE: consider more detailed opportunities for specifying holders like cryo-controller holder, type of holder, material for pucks make a difference for studies which hunt for hydrogen signal, equally dwell time in buffer and load lock chamber and environmental transfer, the application definition does not account for this at the moment, would need a class representing stage and specimen holder hierarchy of the entire sample loading and transfer system and the contributions or not these components make wrt to contamination. - base_temperature(NX_FLOAT): - doc: | - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - unit: NX_TEMPERATURE - temperature(NX_FLOAT): - exists: optional - doc: | - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - unit: NX_TEMPERATURE - dimensions: - rank: 1 - dim: [[1, n_ions]] - (NXcsg): - exists: optional - # evaporation control in which context is it used? - # NEW ISSUE: begin add and support I/O of further details - # NEW ISSUE: with Shyam Katnagallu fix that so far the application definition does not really cover fim as there is no place to store values for a gas injection system and a (partial) pressure sensor for the imaging gas it should be clarified in the docstring of the pressure field if this measured either a chamber total of a species partial pressure - # NEW ISSUE: add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM - analysis_chamber(NXchamber): - name: - exists: optional - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - description: - exists: optional - pressure(NX_FLOAT): - doc: | - Average pressure in the analysis chamber. - unit: NX_PRESSURE - (NXcsg): - exists: optional - buffer_chamber(NXchamber): - exists: optional - name: - exists: optional - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - description: - exists: optional - pressure(NX_FLOAT): - doc: | - Average pressure in the buffer chamber. - unit: NX_PRESSURE - (NXcsg): - exists: optional - load_lock_chamber(NXchamber): - exists: optional - name: - exists: optional - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - description: - exists: optional - pressure(NX_FLOAT): - doc: | - Average pressure in the load_lock_chamber. - unit: NX_PRESSURE - (NXcsg): - exists: optional - getter_pump(NXpump): - exists: optional - design: - exists: recommended - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - (NXcsg): - exists: optional - roughening_pump(NXpump): - exists: optional - design: - exists: recommended - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - (NXcsg): - exists: optional - turbomolecular_pump(NXpump): - exists: optional - design: - exists: recommended - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - (NXcsg): - exists: optional - # NEW ISSUE: end add and support I/O of further details - - instrument_calibration(NXcollection): - exists: recommended - doc: | - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group `_ - (see `P. Felfer et al. `_ ) - # gridded-counter-electrode shadow image polyline fits are exported as - # NXcg_spline_set see also https://www.youtube.com/watch?v=99hNEkqdj78t=2348s - # NEW ISSUE: dld_signal_amplitude monitoring - # arrival_time_pairs: (recommended) NX_NUMBER (Rank: 3, Dimensions: [n_ions, n_dld_wires, 2]) {units=NX_TIME} - # eventually one may wish to store values from an NXmonitoring tracking the DLD signal amplitude (mV) = f(t) - specimen_monitoring(NXcollection): - exists: recommended - # NEW ISSUE: should be promoted to recommended at some point in particular with closer integration of APM and EM instruments - doc: | - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. `_ - and `C. Fletcher `_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann `_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. `_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - # NEW ISSUE: consider the above comments into new fields when important progress has been made. - initial_radius(NX_FLOAT): - doc: | - Ideally measured or best elaborated guess of the - initial radius of the specimen. - unit: NX_LENGTH - shank_angle(NX_FLOAT): - doc: | - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - unit: NX_ANGLE - detection_rate(NX_FLOAT): - doc: | - Average detection rate over the course of the experiment. - unit: NX_DIMENSIONLESS - # NEW ISSUE: define e.g. radius(NX_FLOAT) and evaporation_id(NX_UINT) to store snapshots of the shape evolution of the specimen. - estimated_field_at_the_apex(NX_FLOAT): - exists: optional - doc: | - Estimated field at the apex along the evaporation sequence. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_ions]] - - control_software(NXcollection): - doc: | - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) `_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - # NEW ISSUE: With new development pull fields out of this collection into dedicated groups. - # might consider moving this to individual groups under (NXpump) or (NXchamber) groups. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - buffer_chamber(NXcollection): - exists: optional - doc: Track time-dependent details over the course of the measurement about the buffer_chamber. - load_lock_chamber(NXcollection): - exists: optional - doc: Track time-dependent details over the course of the measurement about the load_lock_chamber. - analysis_chamber(NXcollection): - exists: optional - doc: Track time-dependent details over the course of the measurement about the analysis_chamber. - # NEW ISSUE: pressure in the buffer and load lock chambers - # NEW ISSUE: atmosphere and partial pressures - - # so although strictly speaking the following steps are computational - # post-processing of detector raw data to be specific they are listed - # under the atom_lab group because for experiment with commercial instrument - # these steps are currently not fully separatable as all processing in - # most cases the processing is done in commercial software. - - status: - exists: recommended - doc: | - A statement whether the measurement was successful or failed prematurely. - enumeration: [success, failure, unknown] - - # NEW ISSUE: atomic volume, detection efficiency, electric field (assumptions), - # final specimen state, pre, post image analysis, a reference to three images - # taken as recommended by cameca, before or after, radius evolution model, field # factor, image compression - - # default statistics would be good to report as output e.g. - # total ions (single, multiple, partial) reconstructed ions (ranged, unranged) - # voltage and bowl calibration (peak) mass_calibration as an own field - - ion_impact_positions(NXprocess): - # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group - exists: recommended - doc: | - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - arrival_time_pairs(NX_NUMBER): - exists: recommended - doc: | - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - # NEW ISSUE: discuss with Oxcart developers which - # modifications might be necessary here. - unit: NX_TIME - dimensions: - rank: 3 - dim: [[1, n_ions], [2, n_dld_wires], [3, 2]] - hit_positions(NX_NUMBER): - doc: | - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_ions], [2, 2]] - # NEW ISSUE: follow the example of base_temperature_time_profile to monitor the temporal evolution of the detection_rate over the course of the evaporation sequence - # detection_rate_time_profile(NX_FLOAT): - # doc: Spatio-temporal profile of the detection rate since the start of the measurement. - # NEW ISSUE: discuss how to handle cases when we would like to store ideally an array where one dimensions is NX_TIME and the other one is e.g. NX_PERCENT - hit_quality_filtering(NXprocess): - exists: optional - doc: | - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - sequence_index(NX_POSINT): - exists: recommended - hit_multiplicity(NXprocess): - # NEW ISSUE: use symbols to monitor number of pulses - exists: recommended - doc: | - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - pulses_since_last_ion(NX_UINT): - exists: recommended - doc: | - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - dimensions: - rank: 1 - dim: [[1, n_ions]] - unit: NX_UNITLESS - pulse_id(NX_UINT): - # NEW ISSUE: I feel the name is misleading, the quantity is - # named like this de facto only because thats the jargon - # term with epos files. - exists: optional - doc: | - Number of pulses since the start of the atom probe - run/evaporation sequence. - dimensions: - rank: 1 - dim: [[1, n_ions]] - unit: NX_UNITLESS - hit_multiplicity(NX_UINT): - # NEW ISSUE: further discussions with members of the APM community - # is required to clarify this field and what it means - doc: | - Hit multiplicity. - dimensions: - rank: 1 - dim: [[1, n_ions]] - unit: NX_UNITLESS - ion_filtering(NXprocess): - exists: recommended - doc: | - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - evaporation_id_included(NX_BOOLEAN): # NXcs_filter_boolean_mask - doc: | - Bitmask which is set to true if the ion - is considered and false otherwise. - dimensions: - rank: 1 - dim: [[1, n_ions]] # then only a group - - voltage_and_bowl_correction(NXprocess): - # NEW ISSUE: add section for propagation_delay(NXprocess) ? - exists: recommended - doc: | - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - # NEW ISSUE: realistic is that currently scientists can pull always a calibrated time-of-flight - # but not necessarily unprocessed timing data from the detector (unless individuals built the instrument). - # Relevant for ranging are the calibrated data, thats why only these - # (as an intermediate/compromise solution) are required in this version of the application definition - raw_tof(NX_FLOAT): - exists: recommended - doc: | - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, n_ions]] - calibrated_tof(NX_FLOAT): - # NEW ISSUE: which type of calibrations are applied is usually a modified - # sqrt tof to m/q mapping the exact parameter of which are for LEAP instruments not immediately accessible. - doc: | - Calibrated time-of-flight. - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, n_ions]] - tof_calibration(NXcollection): - exists: recommended - doc: | - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - # NEW ISSUE: should be recommended as otherwise one cannot ensure that - # numerically the same voltage-and-bowl correction results are obtained - # (without knowning the parameters...) - - mass_to_charge_conversion(NXprocess): - exists: recommended - doc: | - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - parameter(NXcollection): - exists: recommended - doc: | - Store vendor-specific calibration models here (if available). - mass_to_charge(NX_FLOAT): - doc: | - Mass-to-charge-state ratio values. - unit: NX_ANY - # \@units: Da / a unitless quantity because it is the charge state and not the charge - dimensions: - rank: 1 - dim: [[1, n_ions]] - - # NEW ISSUE: make this rather an own subentry NXapm_reconstruction - reconstruction(NXprocess): - exists: recommended - doc: | - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - protocol_name: - doc: | - Qualitative statement about which reconstruction protocol was used. - enumeration: [bas, geiser, gault, cameca, other] - parameter: - # NEW ISSUE: the status here should be promoted to required but currently - # one needs to manually extract the reconstruction parameters - # NEW ISSUE: for instance from commercial software, here a better strategy - # is needed how to document the reconstruction parameter. - doc: | - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - # k(NX_FLOAT): - # doc: Field factor - # unit: ?? - # icf(NX_FLOAT): - # doc: Image compression factor. - # unit: ?? - # NEW ISSUE: for AMETEK, as well as for the Bas, Geiser, and - # Gault protocols we know the usual naming of the parameters - # they should be added as optional quantities. - # Therefore, it is difficult for now to generalize the meaning - # and idea behind all relevant reconstruction parameters. - # One could create a class for each reconstruction method, as - # these methods are de facto application definitions. - crystallographic_calibration: - doc: | - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - reconstructed_positions(NX_FLOAT): - doc: | - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_ions], [2, 3]] - visualization(NXprocess): - exists: recommended - xdmf_topology(NX_UINT): - doc: | - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_topology]] - # n_topology == 3*n_ions - xdmf_topology(NX_UINT): - doc: | - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 36]] - - naive_point_cloud_density_map(NXprocess): - doc: | - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - (NXdata): - doc: | - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - doc: Array of counts for each bin. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - axis_z(NX_FLOAT): - doc: Bin center of mass position along the z axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - axis_y(NX_FLOAT): - doc: Bin center of mass position along the y axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - axis_x(NX_FLOAT): - doc: Bin center of mass position along the x axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - - # NEW ISSUE: make this rather an own subentry NXapm_ranging - ranging(NXprocess): - exists: recommended - doc: | - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller `_ - * `D. Haley et al. `_ - * `M. Kühbach et al. `_ - - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - number_of_ion_types(NX_UINT): - doc: | - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - unit: NX_UNITLESS - maximum_number_of_atoms_per_molecular_ion(NX_UINT): - doc: | - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - unit: NX_UNITLESS - - mass_to_charge_distribution(NXprocess): - exists: recommended - doc: | - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - range_minmax(NX_FLOAT): - doc: | - Smallest and largest mass-to-charge-state ratio value. - unit: NX_ANY - # \@units: Da - # NEW ISSUE: NX_ATOMIC_MASS_UNIT use Tommasso scheme here Da - dimensions: - rank: 1 - dim: [[1, 2]] - range_increment(NX_FLOAT): - doc: | - Binning width of the mass-to-charge-state ratio values. - unit: NX_ANY - # \@units: Da - # NEW ISSUE: unit must match with range, is Da - mass_spectrum(NXdata): - doc: | - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - doc: Array of counts for each bin. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_bins]] - \@long_name: - axis_mass_to_charge(NX_FLOAT): - doc: | - Right boundary of each mass-to-charge-state ratio value bin. - unit: NX_ANY - # \@units: Da - dimensions: - rank: 1 - dim: [[1, n_bins]] - \@long_name: - - background_quantification(NXprocess): - exists: recommended - doc: | - Details of the background model which was used to - correct the total counts per bin into counts. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - # NEW ISSUE: add parameters of the background model in an e.g. - # NXcollection as these are specific to every background model - # NEW ISSUE: touching upon i.e. research activities by Andrew London et al. - # substantiating the need for a clearer description how peak/signals were - # eventually processed via deconvolution methods - - peak_search_and_deconvolution(NXprocess): - exists: recommended - doc: | - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - (NXpeak): - exists: [min, 0, max, infty] - label: - exists: recommended - peak_model: - doc: | - THIS DOCSTRING NEEDS CLARIFICATION. - - peak_identification(NXprocess): - exists: recommended - doc: | - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - (NXion): - exists: [min, 0, max, 256] - isotope_vector(NX_UINT): - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): - nuclid_list(NX_UINT): - exists: recommended - name: - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_composition_space_results.yaml b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml deleted file mode 100644 index 3b88c7b1fb..0000000000 --- a/contributed_definitions/nyaml/NXapm_composition_space_results.yaml +++ /dev/null @@ -1,398 +0,0 @@ -category: application -doc: | - Results of a run with Alaukik Saxena's composition space tool. - - This is an initial draft application definition for the common NFDI-MatWerk, - FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the same - time directly understandable for NOMAD. - - This draft does no contain yet the annotations for how to also store - in the HDF5 file a default visualization whereby the composition grid - could directly be explored using H5Web. I am happy to add this ones the - data have been mapped on this schema, i.e. more discussion needed. - - Also iso-surfaces can be described, for paraprobe, this is a solved problem, - check the respective group in the NXapm_paraprobe_results_nanochem data - schema/application definition. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_voxel: Number of voxel of discretized domain for analyzed part of the dataset. - d: The dimensionality of the grid. - c: The cardinality or total number of cells/grid points. - n_clst_dict: Number of terms in the composition clustering dictionary - n_spat_dict: Number of terms in the position clustering dictionary - -NXapm_composition_space_results: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_composition_space_results] - # can be used for the name of the tool and version but also - # for if desired all the dependencies and libraries - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - job_pyiron_identifier: # TBD, name of the field arguably for sure ... - exists: recommended - doc: | - TBD, maybe how to link between pyiron state tracking and app state tracking - description: - exists: optional - doc: | - Disencouraged place for free-text for e.g. comments. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. when composition space tool was started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and composition space tool exited as a process. - config_filename: - doc: | - The path and name of the config file for this analysis. - TBD, this can be e.g. Alaukik's YAML file for composition space. - # one could also wrap the entire triple of NXprocess (voxelization, gmm, real space) - # by a parent NXprocess whereby one could store the results of multiple analyses - # runs of the tool in the same individually documented way for as many parameter - # runs as desired... - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - dataset(NXapm_input_reconstruction): - filename: - doc: | - The path and name of the file (technology partner or community format) - from which reconstructed ion positions were loaded. - \@version: - iontypes(NXapm_input_ranging): - filename: - doc: | - The path and name of the file (technology partner or community format - from which ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes were loaded. - \@version: - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the executable managed to process the analysis - or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - exists: optional - doc: Details about the coordinate system conventions used. - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Some suggestions follow, e.g. that field names should be prefixed - with the following controlled terms indicating which individual - coordinate system is described: - - * world - * composition_space - * lab - * specimen - * laser - * leap - * detector - * recon - - - voxelization(NXprocess): - sequence_index(NX_POSINT): - enumeration: [1] - # specify the grid your using and for each ion in which cell i.e. voxel it is - # one could also have a more sophisticated data model where there is some - # fuzziness i.e. if an ML/AI model returns multiple values or a probability - # how likely an ion is in which voxel, for this - # inspect the example of the NXem_ebsd application definition - (NXcg_grid): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - origin(NX_NUMBER): - # default behaviour, if no coordinate system defined, unclear - # if one coordinate system is defined the origin is defined in this cs - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, d]] - symmetry: - enumeration: [cubic] - cell_dimensions(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, d]] - extent(NX_POSINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, d]] - (NXtransformations): - exists: recommended - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - identifier_offset(NX_INT): - doc: | - unit: NX_UNITLESS - position(NX_NUMBER): - doc: Position of each cell in Euclidean space. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - coordinate(NX_INT): - exists: optional - unit: NX_DIMENSIONLESS - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - # bounding box if needed - voxel_identifier(NX_UINT): - doc: | - For each ion, the identifier of the voxel in which the ion is located. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - (NXion): - exists: [min, 0, max, infty] - name: - composition(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, n_voxel]] - - clustering_composition_space(NXprocess): - doc: | - In Alaukik's tool the GMM step. - sequence_index(NX_POSINT): - enumeration: [2] - cluster_dict_keyword: - doc: | - The keywords of the dictionary of distinguished compositionally- - defined cluster, e.g. the phases. Examples for keywords could be - phase1, phase2, and so one and so forth. - dimensions: - rank: 1 - dim: [[1, n_clst_dict]] - cluster_dict_value(NX_UINT): - doc: | - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_clst_dict]] - # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd - cluster_identifier(NX_UINT): - doc: | - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of either phase1 - or phase2, the cluster_dict_keyword would be a list with two names - phase1 and phase2, respectively. The cluster_dict_value would be a - list of e.g. integers 1 and 2. These could be used to build an - array with as many entries as there are voxel and store in this array - the respective value to encode which phase is assumed for each voxel. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_voxel]] - # use the fact that with e.g. XDMF one can on-the-fly reinterpret - # a 1d array to represent an explicit 3d grid - # default plots would be nice could directly be integrated in the results file - - clustering_real_space(NXprocess): - doc: | - In Alaukik's tool the DBScan step after the GMM step. - sequence_index(NX_POSINT): - enumeration: [3] - cluster_dict_keyword: - doc: | - The keywords of the dictionary of distinguished spatially-contiguous - clusters. Examples for keywords could be precipitate1, precipitate2, - and so one and so forth. - dimensions: - rank: 1 - dim: [[1, n_spat_dict]] - cluster_dict_value(NX_UINT): - doc: | - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_spat_dict]] - # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd - cluster_identifier(NX_UINT): - doc: | - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of certain precipitates, - say we found ten precipitates and consider the rest as matrix. - We could make a list of say matrix, precipitate1, precipitate2, ..., - precipitate10. With cluster_dict_value then running from 0 to 10, - i.e. matrix is flagged special as 0 and the remaining particles - are indexed conveniently as 1, 2, ..., 10 like end users expect. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_voxel]] - # use the fact that with e.g. XDMF one can on-the-fly reinterpret - # a 1d array to represent an explicit 3d grid - # then the entire visualization just needs a smart XDMF file with - # one section with the coordinates of the voxel center of masses - # one section with the voxel identifier - # one section with the "phase" identifier referring to the clustering_composition_space NXprocess group - # one section with the "precipitate" identifier referring to the clustering_real_space NXprocess group - # technically one should get rid of the unnecessary chunks - # instead define an (nx, ny, nz) C-style array which whose data space - # is reserved by the h5py library upon first call and then (if desired) - # filled incrementally - # the array should be chunked not with an auto-chunking but with a nx, ny, >=1 chunking - # which will make visualization of nx, ny slices naturally fast, making the z-dimension - # chunking as fast as large as possible (needs compromise to remain within chunk cache size) - # will also make the orthogonal section a good compromise fast - # data should be gzip, level 1 compressed and all the redundant parts of the current - # output will collapse substantially - - performance(NXcs_profiling): - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - diff --git a/contributed_definitions/nyaml/NXapm_input_ranging.yaml b/contributed_definitions/nyaml/NXapm_input_ranging.yaml deleted file mode 100644 index 17e264bb2e..0000000000 --- a/contributed_definitions/nyaml/NXapm_input_ranging.yaml +++ /dev/null @@ -1,33 +0,0 @@ -category: base -doc: | - Metadata to ranging definitions made for a dataset in atom probe microscopy. - - Ranging is the process of labeling time-of-flight data with so-called iontypes - which ideally specify the most likely ion/molecular ion evaporated within a - given mass-to-charge-state-ratio value interval. - - The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE - iontype (or unranged ions) represents the default iontype. - The ID of this special iontype is always reserved as 0. Each ion - is assigned to the UNKNOWNTYPE by default. Iontypes are assigned - by checking if the mass-to-charge-state-ratio values of an ion matches - to any of the defined mass-to-charge-state-ratio intervals. -# symbols: -NXapm_input_ranging: - filename: - doc: | - Path and name of the NeXus/HDF5 file which stores ranging definitions. - \@version: - doc: | - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - group_name_iontypes: - doc: | - Name of the group (prefix to the individual ranging definitions) inside - the file referred to by filename which points to the specific ranging - definition to use. - An HDF5 file can store multiple ranging definitions. Using an ID is - the mechanism to distinguish which specific ranging (version) will - be processed. Reconstruction and ranging IDs can differ. - They specify different IDs. diff --git a/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml deleted file mode 100644 index 46e40116a8..0000000000 --- a/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml +++ /dev/null @@ -1,26 +0,0 @@ -category: base -doc: | - Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. -# symbols: -NXapm_input_reconstruction: - filename: - doc: | - Name of the (NeXus)/HDF5 file which stores reconstructed ion position - and mass-to-charge-state ratios. Such an HDF5 file can store multiple - reconstructions. Using the information within the dataset_name fields - is the mechanism whereby paraprobe decides which reconstruction to - process. With this design it is possible that the same HDF5 - file can store multiple versions of a reconstruction. - \@version: - doc: | - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - dataset_name_reconstruction: - doc: | - Name of the dataset inside the HDF5 file which refers to the - specific reconstructed ion positions to use for this analysis. - dataset_name_mass_to_charge: - doc: | - Name of the dataset inside the HDF5 file which refers to the - specific mass-to-charge-state-ratio values to use for this analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml deleted file mode 100644 index 6742c8f399..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml +++ /dev/null @@ -1,367 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-clusterer tool run in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - # n_positions: Number of position values. - # n_disjoint_clusters: Number of disjoint cluster. - n_ivecmax: Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - n_clust_algos: Number of clustering algorithms used. - n_ions: Number of different iontypes to distinguish during clustering. -NXapm_paraprobe_config_clusterer: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_clusterer] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - number_of_processes(NX_UINT): - doc: | - How many tasks to perform? - unit: NX_UNITLESS - - cameca_to_nexus(NXprocess): - exists: optional - doc: | - This process maps results from cluster analyses performed with IVAS/APSuite - into an interoperable representation. Specifically in this process - paraprobe-clusterer takes results from clustering methods from other tools - of the APM community, like IVAS/APSuite. These results are usually reported - in two ways. Either as an explicit list of reconstructed ion positions. - In the case of IVAS these positions are reported through a text file - with a cluster label for each position. - - Alternatively, the list of positions is reported, as it is the case for - AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly - only in the following way: The mass-to-charge-state ratio column of a - what is effectively a file formatted like POS is used to assign a hypothetical - mass-to-charge value which resolves a floating point representation - of the cluster ID. - - Another case can occur where all disjoint floating point values, - i.e. here cluster labels, are reported and then a dictionary is created - how each value matches to a cluster ID. - - In general the cluster ID zero is reserved for marking the dataset - as to not be assigned to any cluster. Therefore, indices of disjoint - clusters start at 1. - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - doc: | - AMETEK/Cameca results of cluster analyses, like with the maximum- - separation (MS) method clustering algorithm `J. Hyde et al. `_ - are stored as an improper POS file: This is a matrix of floating - point quadruplets, one for each ion and as many quadruplets as - ions were investigated. The first three values encode the position - of the ion. The fourth value is an improper mass-to-charge-state-ratio - value which encodes the integer identifier of the cluster as a floating - point number. - # mapping_method: - # doc: | - # How should cluster labels be created from the cluster_labels information - # especially when these areNcluste floating point values. - # enumeration: [take_as_is, use_dictionary] - # mapping_dictionary_keyword(NX_NUMBER): - # doc: | - # The list of all keywords of a dictionary which maps implicit cluster - # indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_disjoint_clusters]] - # mapping_dictionary_value(NX_UINT): - # doc: | - # The list of all values of a dictionary which maps implicit cluster - # indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - # The sequences of mapping_dictionary_keyword and mapping_dictionary_value - # have to match. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_disjoint_clusters]] - recover_evaporation_id(NX_BOOLEAN): - doc: | - Specifies if the tool should try to recover for each position the closest - matching position from dataset/dataset_name_reconstruction (within - floating point accuracy). This can be useful for instance when users - wish to recover the original evaporation ID, which IVAS/AP Suite drops - for instance when writing their *.indexed.* cluster results POS files. - # recover_bitmask(NX_BOOLEAN): - # doc: | - # Specifies if the tool should try to recover, after a recovery of the - # evaporation IDs a bitmask which identifies which of the positions - # in dataset/dataset/dataset_name_reconstruction where covered - # by the IVAS/APSuite cluster analysis. This can be useful to recover - # the region of interest. - - cluster_analysis(NXprocess): - exists: [min, 0, max, 1] - doc: | - This process performs a cluster analysis on a reconstructed dataset - or a portion of the reconstruction. - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - ion_to_edge_distances(NXprocess): - exists: optional - doc: | - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - filename: - doc: Name of an HDF5 file which contains the ion distances. - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - dataset_name: - doc: Absolute HDF5 path to the dataset with distance values for each ion. - - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - enumeration: [entire_dataset] # ##MK::nothing implemented so far - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - - # clustering_algorithm: - # doc: | - # Name of the clustering algorithm used. - # enumeration: [dbscan] # , optics, hpdbscan] - # dimensions: - # rank: 1 - # dim: [[1, n_clust_algos]] - ion_type_filter: - doc: | - How should iontypes be interpreted/considered during the cluster analysis. - Different options exist how iontypes are interpreted (if considered at all) - given an iontype represents in general a (molecular) ion with different isotopes - that have individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - - This is relevant as in atom probe we have the situation that a ion - of a molecular ion with more than one nuclid, say Ti O for example - is counted such that although there is a single TiO molecular ion - at a position that the cluster has two members. This multiplicity - affects the size of the feature and chemical composition. - # enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - enumeration: [resolve_element] # specify further details - ion_query_isotope_vector(NX_UINT): - doc: | - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_ions], [2, n_ivecmax]] - dbscan(NXprocess): - doc: | - Settings for DBScan clustering algorithm. For original details about the - algorithms and (performance-relevant) details consider: - - * `M. Ester et al. `_ - * `M. Götz et al. `_ - - For details about how the DBScan algorithms is the key behind the - specific modification known as the maximum-separation method in the - atom probe community consider `E. Jägle et al. `_ - high_throughput_method: - doc: | - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - As an example we may define eps with ten entries and min_pts with - three entries. If high_throughput_method is tuple the analysis is - invalid as we have an insufficient number of min_pts for the ten - eps values. - By contrast, for combinatorics paraprobe-clusterer will run three - individual min_pts runs for each eps value, resulting in a total - of 30 analyses. - As an example the DBScan analysis reported in `M. Kühbach et al. `_ - would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) - eps values, min_pts one, and high_throughput_method set to combinatorics. - enumeration: [tuple, combinatorics] - eps(NX_FLOAT): - doc: | - Array of epsilon (eps) parameter values. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, i]] - min_pts(NX_UINT): - doc: | - Array of minimum points (min_pts) parameter values. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] # ##MK::has to be i like for eps when high_throughput_method is tuple ! - # THE IDEA BEHIND paraprobe-clusterer is that users can run a number of - # cluster analyses on their dataset on exactly the same point cloud and under - # the same conditions - - optics(NXprocess): - doc: | - Settings for the OPTICS clustering algorithm. - - * `M. Ankerest et al. `_ - high_throughput_method: - doc: | - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - enumeration: [tuple, combinatorics] - min_pts(NX_UINT): - doc: | - Array of minimum points (min_pts) parameter values. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - max_eps(NX_FLOAT): - doc: | - Array of maximum epsilon (eps) parameter values. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, j]] - hdbscan(NXprocess): - doc: | - Settings for the HPDBScan clustering algorithm. - - * L. McInnes et al. `_ - * scikit-learn hdbscan library ``_ - - See also this documentation for details about the parameter. - Here we use the terminology of the hdbscan documentation. - high_throughput_method: - doc: | - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - enumeration: [tuple, combinatorics] - min_cluster_size(NX_NUMBER): # ##MK:? NX_FLOAT - doc: | - Array of min_cluster_size parameter values. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, i]] - min_samples(NX_NUMBER): # ##MK::NX_UINT - doc: | - Array of min_samples parameter values. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, j]] - cluster_selection_epsilon(NX_NUMBER): - doc: | - Array of cluster_selection parameter values. - unit: NX_ANY # ##MK::? but so None as an argument - dimensions: - rank: 1 - dim: [[1, k]] - alpha(NX_NUMBER): # ##MK:? NX_FLOAT - doc: | - Array of alpha parameter values. - unit: NX_ANY # ##MK::? - dimensions: - rank: 1 - dim: [[1, m]] - # ADD FURTHER ALGORITHMS, see L. Stephenson for further details - # e.g. https://doi.org/10.1017/S1431927607070900 diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml deleted file mode 100644 index 19229f8fcc..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml +++ /dev/null @@ -1,186 +0,0 @@ -category: application -doc: | - Configuration/settings of a paraprobe-distancer software tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXapm_paraprobe_config_distancer: - (NXentry): - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_distancer] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - number_of_processes(NX_UINT): - doc: How many individual analyses should the tool execute. - unit: NX_UNITLESS - (NXprocess): - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - - point_to_triangle(NXprocess): - doc: | - Compute for all filtered points, e.g. ions of the point set - the shortest Euclidean distance to the closest triangle of the - set of triangles. The triangles can formed a closed surface mesh. - Distances are not simple distances based on normal projections but - giving an exact solution. - triangle_soup(NXprocess): - # NEW ISSUE NXtriangle_soup - doc: | - Paraprobe-distancer enables the computation of the Euclidean shortest - distance for each member of a set of points against a set of triangles. - In contrast to comparable methods used in atom probe the here computed - distance is not simply the projected distance to one of the triangles - but the more costly but robust computation of the distance between - a point and a triangle. - - The triangles can represent for instance the facets of a triangulated - surface mesh of a model for the edge of the dataset. Such a model can - be computed with paraprobe-surfacer. Alternatively, the triangles can - be those from the set of all facets for a set of convex hulls, alpha-shapes, - or alpha wrappings about three-dimensional objects like precipitates - (computed with e.g. paraprobe-nanochem). - - Currently, the tool does not check if the respectively specified - triangle sets are consistent, what their topology is, or whether or - not they are consistently oriented. - Each dataset that is referred to in the list_of _dataset_names_vertices - should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred - to in the list_of_dataset_names_facet_indices should be an - (Nfacets, 3) array of NX_UINT. - Facet indices refer to vertex indices. These need to start at zero - and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and vertices are indexed thus implicitly. - Facet normal vectors have to be also an array - of shape (Nfacets, 3) of NX_FLOAT. - number_of_files(NX_UINT): - doc: How many triangle sets to consider. - unit: NX_UNITLESS - (NXprocess): # should better be an NXprocess - doc: | - List of triangle sets. This design allows users to combine - multiple triangle sets. - filename: - doc: | - Name of the HDF5 file(s) which contain(s) vertex coordinates - and facet indices to describe the desired set of triangles. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility. - dataset_name_vertices: - doc: | - Absolute HDF5 path to the dataset which - specifies the array of vertex positions. - dataset_name_facet_indices: - doc: | - Absolute HDF5 path to the dataset which - specifies the array of facet indices. - dataset_name_facet_normals: - exists: optional - doc: | - Absolute HDF5 path to the dataset which - specifies the array of facet normal vectors. - method: - doc: | - Specifies for which ions/points the tool will compute distances. - The purpose of this setting is to avoid unnecessary computations - when the user requests to only compute distances of ions within a - threshold distance to the triangle soup. - - By default the distances are computed for all ions; however - the setting skin enables to compute distances only for those - ions which are not farther away located to a triangle - than threshold_distance. - enumeration: [default, skin] - threshold_distance(NX_FLOAT): - # ##MK::only required when method is skin - doc: | - Maximum distance for which distances are computed when method is skin. - unit: NX_LENGTH - # \@units: nm - - # point_set_to_polyline_set(NXprocess): - # doc: | - # Compute the shortest Euclidean distance of all filtered points/ions - # of a point set to the closest point on the closest polyline. - # polyhedra_set_to_triangle_set(NXprocess): - # doc: | - # Compute the (shortest Euclidean) distance of all polyhedra of a set - - performance(NXcs_profiling): - current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml deleted file mode 100644 index 9283276f8f..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml +++ /dev/null @@ -1,251 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-intersector tool run in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXapm_paraprobe_config_intersector: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_intersector] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - number_of_processes(NX_UINT): - doc: | - For now a support field for the tool to identify how many individual - analyses the tool should execute as part of the analysis. - unit: NX_UNITLESS - VOLUME_VOLUME_SPATIAL_CORRELATION(NXprocess): - exists: [min, 1, max, infty] - doc: | - Tracking volume_volume_spatial_correlation is the process of building logical - relations between volumetric features based on meshes, their proximity and - eventual intersections. Volumetric overlap and proximity of volumetric - features is identified for members of sets of features to members of - other sets of volumetric features. - Specifically, for each time step k pairs of sets are compared: - Members of a so-called current_set to members of a so-called next_set. - Members can be different types of volumetric features. - In the analysis of M. Kuehbach et al. specifically features can be - so-called objects (closed non-degnerated polyhedra representing watertight - parts of an e.g. iso-surface) and/or proxies. Proxies are computed - doppelganger/replacement meshes for parts of an iso-surface which initially - were not resulting in watertight meshes because objects at the edge - of the dataset or incompletely measured or truncated objects. - intersection_detection_method: - doc: | - Specifies the method whereby to decide if two objects intersect volumetrically. - For reasons which are detailed in the supplementary material of - `M. Kühbach et al. `_, the tool by - default assumes that two objects intersect if they share at least one - ion with the same evaporation ID (shared_ion). - Alternatively, with specifying tetrahedra_intersections, - the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks - for at least one pair of intersecting tetrahedra to identify if two objects - intersect or not. - - However, we found that these geometrical analyses can result in corner - cases which the currently used library (TetGen) was not unable to - tetrahedralize successfully. These cases were virtually always - associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. - Finding more robust methods for computing intersections between - not necessarily convex polyhedra might improve the situation in the future. - enumeration: [shared_ion] # , tetrahedra_intersections] - analyze_intersection(NX_BOOLEAN): - doc: | - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) intersect volumetrically. - analyze_proximity(NX_BOOLEAN): - doc: | - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) lie closer to one another than the - threshold_proximity. - analyze_coprecipitation(NX_BOOLEAN): - doc: | - Specifies if the tool evaluates, ones all tracking tasks were - successfully completed, how intersecting or proximity related - objects build sub-graphs. This is the feature which enabled - M. Kühbach et al. 2022 the high-throughput analyses of how many - objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order. For these analyses to work - has_object_volume needs to be activated. - threshold_proximity(NX_FLOAT): - doc: | - The maximum Euclidean distance between two objects below which - both objects are still considered within proximity. - unit: NX_LENGTH - # \@units: nm - has_current_to_next_links(NX_BOOLEAN): - doc: | - Specifies if the tool stores the so-called forward relations between - nodes representing members of the current_set to nodes representing - members of the next_set. - has_next_to_current_links(NX_BOOLEAN): - doc: | - Specifies if the tool stores the so-called backward relations between - nodes representing members of the next_set to nodes representing - members of the current_set. - - current_set(NXprocess): - doc: | - Current set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the current_set. - The meshes were generated as a result of some other meshing process. - set_identifier(NX_UINT): - doc: | - This identifier can be used to label the current set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 `_, this identifier - takes the role of the time variable :math:`k`. - unit: NX_ANY - # number_of_objects(NX_UINT): - # doc: For now a support field to tell the tool how many objects to load. - # unit: NX_UNITLESS - number_of_feature_types(NX_UINT): - doc: | - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - current_set. - unit: NX_UNITLESS - FEATURE(NXcollection): - exists: [min, 1, max, 4] # restriction to two not needed, currently for objects and proxies - feature_type: - doc: | - Descriptive category explaining what these features are. - enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] - filename: - doc: | - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - # NEW ISSUE: make more robust checks wrt to the consistence of the datasets - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - groupname_geometry_prefix: - doc: | - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object/polyhedron. - feature_identifier(NX_UINT): - doc: | - Array of identifier whereby the path to the geometry data - can be interferred automatically. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - - next_set(NXcollection): - doc: | - Next set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the next_set. - The meshes were generated as a result of some other meshing process. - set_identifier(NX_UINT): - doc: | - This identifier can be used to label the next_set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 `_, this identifier - takes the role of the time variable :math:`k + 1`. - unit: NX_ANY - # number_of_objects(NX_UINT): - # doc: For now a support field to tell the tool how many objects to load. - # unit: NX_UNITLESS - number_of_feature_types(NX_UINT): - doc: | - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - next_set. - unit: NX_UNITLESS - FEATURE(NXcollection): - exists: [min, 1, max, 4] # restriction to two not needed, currently for objects and proxies - feature_type: - doc: | - Descriptive category explaining what these features are. - enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] - filename: - doc: | - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - # NEW ISSUE: make more robust checks wrt to the consistence of the datasets - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - groupname_geometry_prefix: - doc: | - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object/polyhedron. - feature_identifier(NX_UINT): - doc: | - Array of identifier whereby the path to the geometry data - can be interferred automatically. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - - # ##MK::tetrahedra volume intersection and tessellation, and Nef polyhedra intersection - # ##MK::are considered guru features and therefore currently supported via modifying the C/C++ source code - - performance(NXcs_profiling): - current_working_directory: \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml deleted file mode 100644 index 04b73691af..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml +++ /dev/null @@ -1,892 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-nanochem tool run in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ityp_deloc_cand: How many iontypes does the delocalization filter specify. - n_control_pts: How many disjoint control points are defined. - n_fct_filter_cand: How many iontypes does the interface meshing iontype filter specify. - n_fct_iterations: How many DCOM iterations. - n_ivec: Maximum number of atoms per molecular ion. -NXapm_paraprobe_config_nanochem: - (NXentry): - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_nanochem] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - number_of_processes(NX_UINT): - doc: | - How many individual analyses should the tool execute as part of the analysis. - unit: NX_UNITLESS - - (NXprocess): - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - - edge_of_the_dataset(NXprocess): - doc: | - The tool enables to inject a previously computed triangle soup or - triangulated surface mesh representing a model (of the surface) of - the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - # NEW ISSUE: exists: optional - filename: - doc: | - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the edge of the dataset. - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - dataset_name_vertices: - doc: | - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - dataset_name_facet_indices: - doc: | - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - - ion_to_edge_distances(NXprocess): - exists: optional - doc: | - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - # NEW ISSUE: is this optional? - filename: - doc: Name of an HDF5 file which contains the ion distances. - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - dataset_name: - doc: Absolute HDF5 path to the dataset with distance values for each ion. - - # number_of_delocalizations(NX_UINT): - # doc: | - # For now a support field for the tool to identify how many individual - # delocalization analyses for the above-mentioned dataset and supplementary - # files are executed as part of the high-throughput analysis. - # unit: NX_UNITLESS - delocalization(NXprocess): - # NEW ISSUE delocalization is all lower case meaning you cannot have right now multiple of these - # even though paraprobe-nanochem triggers a number of delocalizations for each of which triggering again isosurfaces - # currently the principal idea behind this design is that you normally focus iso-surface-based analyses - # on specific elements and for these you may have different discretization and isosurface computation demands - # for instance you might be super interested in analyzing in find details the iso-surfaces of carbon in a dataset - # but in addition you could be interested also to study chromium iso-surfaces but for completely different iso-contour values - # etc. this is what paraprobe-nanochem allows you to do - # you create one process for all your carbon related delocalizations, isosurfaces etc - # plus another process packing all your chromium delocalization and isosurfaces - exists: [min, 0, max, 1] - doc: Discretization of the ion point cloud on a three-dimensional grid. - input: - doc: | - Delocalization in the field of atom probe microscopy is the process - of discretizing a point cloud. By default the tool computes a full - kernel density estimation of decomposed ions to create one discretized - field for each element. - - Although, this uses an efficient multithreaded algorithm, - the computation is costly. Therefore, it can be advantageous for users - to load an already computed delocalization. This can be achieved with - the load_existent option. - When using this option the user is responsible to assure that the - settings which were used for computing this already existent delocalization - are specified in the same manner as they were. - # NEW ISSUE: improve UX experience - enumeration: [default, load_existent] - # NEW ISSUE: base class filter - isotope_whitelist(NX_UINT): - doc: | - Matrix of isotope vectors representing iontypes. - The filter specifies a matrix of isotope_vectors which is the most - general approach to define if and how many times an ion is counted. - Currently, paraprobe_nanochem performs a so-called atomic decomposition - of all iontypes. Specifically, the tool interprets of how many - elements/atoms a molecular ion is composed; and thus determines the - atoms multiplicity with respect to the iontype. - - Let's take the hydroxonium H3O+ molecular ion as an example: - It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen - is three whereas that of oxygen is one. Therefore in an atomic - decomposition computation of the iso-surface each H3O+ ion adds - three hydrogen counts. This is a practical solution which accepts - the situation that during an atom probe experiment not each bond - of each ion/a group of neighboring atoms is broken but molecular - ions get detected. The exact ab-initio details depend on the local - field conditions and thus also the detailed spatial arrangement - of the atoms and their own electronic state and that of the neighbors - before and upon launch. - Being able to measure the information for such sites only as - molecular ions causes an inherent information loss with respect to the - detailed spatial arrangement. This information loss is more relevant - for local electrode atom probe than for field ion microscopy setting - how precisely the atomic positions can be reconstructed. - Accounting for multiplicities assures that at least the - compositional information is analyzed. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_ityp_deloc_cand], [2, n_ivec]] - gridresolutions(NX_FLOAT): - doc: | - List of individual grid resolutions to analyse. - Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with - an edge length of values in gridresolutions. - unit: NX_LENGTH - # \@units: nm - kernel_size(NX_UINT): - doc: | - Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel - beyond which the Gaussian Ansatz function will be truncated. - Intensity beyond the kernel is refactored into the kernel via - a normalization procedure. - unit: NX_UNITLESS - kernel_variance(NX_FLOAT): - doc: | - Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`. - unit: NX_LENGTH - # \@units: nm - normalization: - doc: | - How should the results of the kernel-density estimation be computed - into quantities. By default the tool computes the total number - (intensity) of ions or elements. Alternatively the tool can compute - the total intensity, the composition, or the concentration of the - ions/elements specified by the white list of elements in each voxel. - enumeration: [total, candidates, composition, concentration] - has_scalar_fields(NX_BOOLEAN): - doc: | - Specifies if the tool should report the delocalization 3D field values. - # number_of_isosurfaces: - # doc: For now a support field for the tool to identify how many individual analyses the tool should execute during the analysis run. - # unit: NX_UNITLESS - - isosurfacing(NXprocess): - # NEW ISSUE: currently isosurface has to be a child of delocalization because otherwise - # you could construct the incorrect situation that you leave delocalization optional do not add sth there but fill isosurface - # and this does not work because without a delocalization/field quantity you cannot compute iso-surfaces - exists: [min, 0, max, 1] - doc: | - Optional computation of iso-surfaces after each computed delocalization - to identify for instance objects in the microstructure - (line features, interfaces, precipitates). - edge_handling_method: - doc: | - As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., - the handling of triangles at the edge of the dataset requires - special attention. Especially for composition-normalized - delocalization it is possible that the composition increases - towards the edge of the dataset because the quotient of two numbers - which are both smaller than one is larger instead of smaller than - the counter. By default, the tool uses a modified marching cubes - algorithm of Lewiner et al. which detects if voxels face such a - situation. In this case, no triangles are generated for such voxels. - Alternatively, (via setting keep_edge_triangles) the user can - instruct the tool to not remove these triangles at the cost of bias. - - Specifically, in this case the user should understand that all - objects/microstructural features in contact with the edge of the - dataset get usually artificial enlarged and their surface mesh - often closed during the marching. This closure however is artificial! - It can result in biased shape analyses for those objects. - The reason why this should in general be avoided is a similar - argument as when one analyzes grain shapes in orientation microscopy - via e.g. SEM/EBSD. Namely, these grains, here the objects at the - edge of the dataset, were not fully captured during e.g. limited - field of view. - Therefore, it is questionable if one would like to make - substantiated quantitative statements about them. - - Thanks to collaboration with the V. V. Rielli and S. Primig, though, - paraprobe-nanochem implements a complete pipeline to - process even these objects at the edge of the dataset. Specifically, - the objects are replaced by so-called proxies, i.e. replacement - objects whose holes on the surface mesh have been closed if possible - via iterative mesh and hole-filling procedures with fairing operations. - In the results of each paraprobe-nanochem run, these proxy objects - are listed separately to allow users to quantify and analyze in - detail the differences when accounting for these objects or not. - Especially this is relevant in atom probe microscopy as objects - can contain a few dozen atoms only. - Users should be aware that results from fairing operations should - be compared to results from analyses where all objects at the edge - of the dataset have been removed. - - Also users should be careful with overestimating the statistical - significance of their dataset especially when using atom probe - to compare multiple descriptors: Even though a dataset may give - statistically significant results for compositions, this does not - necessarily mean it will yield also statistically significant - and unbiased results for three-dimensional object analyses. - Being able to quantify these effects and making atom probers - aware of these subtleties was one of the main reasons why the - paraprobe-nanochem tool was implemented. - enumeration: [default, keep_edge_triangles] - edge_threshold(NX_FLOAT): - doc: | - The ion-to-edge-distance that is used in the analyses of objects - (and proxies) to identify whether these are inside the dataset or - close to the edge of the dataset. If an object has at least one ion - with an ion-to-edge-distance below this threshold, the object is - considered as one which lies close to the edge of the dataset. - This implements essentially a distance-based approach to solve - the in general complicated and involved treatment of computing - volumetric intersections between not-necessarily convex - closed 2-manifolds. In fact, such computational geometry analyses - can face numerical robustness issues as a consequence of which a - mesh can be detected as lying completely inside a dataset although - in reality it is epsilon-close only, i.e. almost touching only - the edge (e.g. from inside). - Practically, humans would state in such case that the object is - close to the edge of the dataset; however mathematically the object - is indeed completely inside. - In short, a distance-based approach is rigorous and more flexible. - unit: NX_LENGTH - # \@units: nm - phi(NX_FLOAT): - doc: | - Array of iso-contour values. For each value the tool computes - an iso-surface and performs subsequent analyses. - The unit depends on the choice for the normalization of the - accumulated ion intensity values per voxel: - - * total, total number of ions, irrespective their iontype - * candidates, total number of ions with type in the isotope_whitelist. - * composition, candidates but normalized by composition, i.e. at.-% - * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - - unit: NX_ANY - # NEW ISSUE: details what these options activate need to be described in more detail !!!!! - has_triangle_soup(NX_BOOLEAN): - doc: | - Specifies if the tool should report the triangle soup which represents - each triangle of the iso-surface complex. - Each triangle is reported with an ID specifying to which triangle - cluster (with IDs starting at zero) the triangle belongs. - The clustering is performed with a modified DBScan algorithm. - has_object(NX_BOOLEAN): - doc: | - Specifies if the tool should analyze for each cluster of triangles - how they can be combinatorially processed to describe a closed - polyhedron. Such a closed polyhedron (not-necessarily convex!) - can be used to describe objects with relevance in the microstructure. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In fact, inaccuracies in the - reconstructed positions cause inaccuracies in all downstream - processing operations. Especially the effect on one-dimensional - spatial statistics like nearest neighbor correlation functions these - effects were discussed in the literature - `B. Gault et al. `_ - In continuation of these thoughts this applies also to reconstructed - objects. A well-known example is the discussion of shape deviations - of Al3Sc precipitates in aluminium alloys which in reconstructions - can appear as ellipsoids although they should be almost spherical, - depending on their size. - has_object_geometry(NX_BOOLEAN): - doc: | - Specifies if the tool should report a triangulated surface mesh - for each identified closed polyhedron. It is common that a - marching cubes algorithm creates iso-surfaces with a fraction of very - small sub-complexes (e.g. small isolated tetrahedra). - - These can be for instance be small tetrahedra/polyhedra about the - center of a voxel of the support grid on which marching cubes operates. - When these objects are small, it is possible that they contain no ion; - especially when considering that delocalization procedures smoothen - the positions of the ions. Although these small objects are interesting - from a numerical point of view, scientists may argue they are not worth - to be reported: - Physically a microstructural feature should contain at least a few - atoms to become relevant. Therefore, paraprobe-nanochem by default - does not report closed objects which bound not at least one ion. - has_object_properties(NX_BOOLEAN): - doc: | - Specifies if the tool should report properties of each closed - polyhedron, such as volume and other details. - has_object_obb(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each closed polyhedron an - approximately optimal bounding box fitted to all triangles of the - surface mesh of the object and ion positions inside or on the - surface of the mesh. - This bounding box informs about the closed object's shape - (aspect ratios). - # NEW ISSUE: Addendum Alternatively it is possible to fit triaxial ellipsoids. - has_object_ions(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each closed polyhedron - all evaporation IDs of those ions which lie inside or on the - boundary of the polyhedron. This information can be used e.g. - in the paraprobe-intersector tool to infer if two objects share - common ions, which can be interpreted as an argument to assume - that the two objects intersect. - - Users should be aware that two arbitrarily closed polyhedra - in three-dimensional space can intersect but not share a common ion. - In fact, the volume bounded by the polyhedron has sharp edges. - When taking two objects, an edge of one object may for instance - pierce into the surface of another object. In this case the - objects partially overlap / intersect volumetrically; - however this piercing might be so small or happening in the volume - between two ion positions and thus sharing ions is a sufficient - but not a necessary condition for object intersections. - - Paraprobe-intersector implements a rigorous alternative to handle - such intersections using a tetrahedralization of closed objects. - However, in many practical cases, we found through examples that there - are polyhedra (especially when they are non-convex and have almost - point-like) connected channels, where tetrahedralization libraries - have challenges dealing with. In this case checking intersections - via shared_ions is a more practical alternative. - has_object_edge_contact(NX_BOOLEAN): - doc: | - Specifies if the tool should report if a (closed) object has - contact with the edge of the dataset. For this the tool currently - inspects if the shortest distance between the set of triangles of the - surface mesh and the triangles of the edge model is larger than the - edge_threshold. If this is the case, the object is assumed to be - deeply embedded in the interior of the dataset. Otherwise, the object - is considered to have an edge contact, i.e. it is likely affected - by the fact that the dataset is finite. - # the edge_threshold can be decided based on half the length of the diagonal of the delocalization kernel. - # as a consequence of which wider kernels result in larger threshold values causing more objects to become - # qualified as having edge contact. - has_proxy(NX_BOOLEAN): - doc: | - Specifies if the tool should analyze a doppelganger/proxy mesh for - each cluster of triangles whose combinatorial analysis according - to has_object showed that the object is not a closed polyhedron. - Such proxies are closed via iterative hole-filling, mesh refinement, - and fairing operations. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In most cases objects, - like precipitates in atom probe end up as open objects because - they have been clipped by the edge of the dataset. Using a proxy is - then a strategy to still be able to account for these objects. - Nevertheless users should make themselves familiar with the - potential consequences and biases which this can introduce - into the analysis. - has_proxy_geometry(NX_BOOLEAN): - doc: Like has_object_geometry but for the proxies. - has_proxy_properties(NX_BOOLEAN): - doc: Like has_object_properties but for the proxies. - has_proxy_obb(NX_BOOLEAN): - doc: Like has_object_obb but for the proxies. - has_proxy_ions(NX_BOOLEAN): - doc: Like has_object_ions but for the proxies. - has_proxy_edge_contact(NX_BOOLEAN): - doc: Like has_object_edge_contact but for the proxies. - has_object_auto_proxigram(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each closed object a - (cylindrical) region of interest placed, centered, and align - with the local normal for each triangle of the object. - has_object_auto_proxigram_edge_contact(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each ROI that was placed - at a triangle of each object if this ROI intersects the edge of - the dataset. Currently paraprobe-nanochem supports cylindrical - ROIs. A possible intersection of these with the edge of the - dataset, i.e. the triangulated surface mesh model for the edge - is performed. This test checks if the cylinder intersects with - a triangle of the surface mesh. If this is the case, the ROI is - assumed to make edge contact, else, the ROI is assumed to have - no edge contact. - - This approach does not work if the ROI would be completely - outside the dataset. Also in this case there would be - no intersection. For atom probe this case is practically - irrelevant because for such a ROI there would also be no ion - laying inside the ROI. Clearly it has thus to be assumed that - the edge model culls the entire dataset. Instead, if one would - cut a portion of the dataset, compute an edge model for this - point cloud, it might make sense to place a ROI but in this - case the edge contact detection is not expected to work properly. - # has_object_mesh_smoothing(NX_BOOLEAN): - # doc: Specifies if the tool should post-process each mesh to improve the mesh quality. - # mesh_smoothing(NXprocess): - # NEW ISSUE: here we need to specify how the meshes were smoothened - # ##MK::is this group not at the previous level of the hierarchy? - - interfacial_excess(NXprocess): - exists: optional - doc: Analyses of interfacial excess. - interface_model: - doc: | - Interfacial excess computations are performed for local regions-of-interests - (ROIs) at selected facets or interface patch. - For instance many scientist compute the interfacial excess for - selected triangle facets of a created iso-surface. In this case, - computed iso-surfaces of paraprobe could be used. An example are triangle - facet sets about closed polyhedra, for instance to compute interfacial - excess related to phase boundaries of second-phase precipitates. - - Another example are free-standing triangle patches of the iso- - surfaces which paraprobe creates. These could be characterized - for interfacial excess. The sub-routines during iso-surface - computations already include a procedure to automatically align - local triangle normals based on the gradients of e.g. composition - fields. In this case, these triangulated surface patches - could also be used as a source for computing interfacial - excess. - - Often scientists face situations, though, in which there is no - immediately evident composition gradient across the interface - (grain or phase boundary) and orientation information about the - adjoining crystal is neither available nor reliable enough. - - In this case `P. Felfer et al. `_ proposed a method - to manually place control points and run an automated tessellation-based - algorithm to create a triangulated surface patch, i.e. a model of the - location of the interface. In a post-processing step this triangle - set can then be used to compute again interfacial excess in an - automated manner by placing ROIs and aligning them with - consistently precomputed triangle normals. - - A similar use case is conceptually the one proposed by `X. Zhou et al. `_ - They used first a deep-learning method to locate planar triangulated - grain boundary patches. These are eventually processed further - with manual editing of the mesh via tools like Blender. - Once the user is satisfied with the mesh, the computations of interfacial - excess reduce again to an automated placing of ROIs, computations - of the distributing of ions to respective ROIs and - reporting the findings via plotting. - - Yet another approach for constructing an triangulated surface patch - of an interface is to use point cloud processing methods which have - been proposed in the laser-scanning, geoinformatics, and CAD community. - Different computational geometry methods are available for fitting - a parameterized surface to a set of points, using e.g. non-uniform - rational B-splines (NURBS) and triangulating these according - to prescribed mesh quality demands. - - The advantage of these methods is that they can be automated and - pick up curved interface segments. The disadvantage is their often - strong sensitivity to parameterization. As a result also such methods - can be post-processed to yield a triangulated surface patch, - and thus enable to run again automated ROI placement methods. - For example like these which were explored for the use case of - iso-surfaces with closed objects and free-standing - surface patches that delineate regions of the dataset with a - pronounced composition gradient normal to the interface. - - This summary of the situations which atom probers can face when - requesting for interfacial excess computations, substantiates there - exists a common set of settings which can describe all of these methods - and, specifically, as here exemplified, the automated placing - and alignment functionalities for ROIs that is an important - step all these workflows. - - Specifically, paraprobe-nanochem operates on an already existent - triangle set. - enumeration: [isosurface, external] - # NEW ISSUE: how to implement and also check consistently via NeXus that a - # NEW ISSUE: child group is required only when a field has a certain value? - external(NXprocess): - exists: optional - doc: | - The interface model is the result of a previous (set of) processing - steps as a result of which the user has created a triangulated - surface mesh (or a set of, eventually connected such meshes). - These interface models are useful, if not required, in cases when - there is no other independent approach to locate an interface. - - These are cases when insufficient crystallographic latent - information is available and also no consistent concentration - gradient detectable across the interface. It is then the users' - responsibility to deliver a triangle mesh of the interface model. - file_name: - doc: | - Filename to HDF5 file which contain vertex coordinates, facet indices, - facet unit normals. The user is responsible for the triangle - and winding order to be consistent. - Input is expected as a matrix of the coordinates for all disjoint - vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. - Input is expected to include also a matrix of facet indices - referring to these disjoint vertices. This matrix should be a - (Nfacets, 3)-shaped array of NX_UINT. Further required input - is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit - normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed - vertex unit normals. Vertex indices need to start at zero and - must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - dataset_name_vertices: - doc: | - Absolute HDF5 path to the dataset which specifies the - array of vertex positions. - dataset_name_facet_indices: - doc: | - Absolute HDF5 path to the dataset which specifies the - array of facet indices. - dataset_name_facet_normals: - doc: | - Absolute HDF5 path to the dataset which specifies the - array of facet signed unit normals. - dataset_name_facet_vertices: - doc: | - Absolute HDF5 path to the dataset which specifies the - array of vertex signed unit normals. - - Users should be aware that triangulated surface meshes are - only approximations to a given complex, eventually curved shape. - Consequently, computations of normals show differences between - the vertex and facet normals. Vertex normals have to be - interpolated from normals of neighboring facets. Consequently, - these normals are affected by the underlying parameterization - and curvature estimation algorithms, irrespective of how - contributions from neighboring facets are weighted. By contrast, - facet normals are clearly defined by the associated triangle. - Their disadvantage is that they the normal field has discontinuities - at the edges. In general the coarser an object is triangulated - the more significant the difference becomes between computations - based on facet or vertex normals. - Paraprobe-nanochem works with facet normals as it can use - parts of the numerical performance gained by using cutting - edge libraries to work rather with finer meshes. - - interface_meshing(NXprocess): - exists: [min, 0, max, 1] - doc: | - Create a simple principle component analysis (PCA) to mesh a - free-standing interface patch through a point cloud of decorating solutes. - These models can be useful for quantification of Gibbsian - interfacial excess for interfaces where iso-surface based methods - may fail or closed objects from iso-surfaces are not desired or - when e.g. there are no substantial or consistently oriented - concentration gradients across the interface patch. - - The interface_meshing functionality of paraprobe-nanochem can be useful - when there is also insufficient latent crystallographic information - available that could otherwise support modelling the interface, - via e.g. ion density traces in field-desorption maps, as were used and - discussed by `Y. Wei et al. `_ - or are discussed by `A. Breen et al. `_ - - It is noteworthy that the method here used is conceptually very similar - in implementation to the work by `Z. Peng et al. `_ - Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. - However, both of these previous works neither discuss in detail - nor implement inspection functionalities which enable a detection of - potential geometric inconsistencies or self-interactions of the - resulting DCOM mesh. This is what paraprobe-nanochem implements - via the Computational Geometry Algorithms Library. - initialization: - doc: | - Method how to initialize the PCA: - - * default, means based on segregated solutes in the ROI - * control_point_file, means based on reading an external list of - control points, currently coming from the Leoben APT_Analyzer. - - The control_point_file is currently expected with a specific format. - The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. `_ - to create a control_point_file which can be parsed by paraprobe-parmsetup - to match the here required formatting in control_points. - enumeration: [default, control_point_file] - filename: - doc: The name of the control point file to use. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - control_points(NX_FLOAT): - doc: | - X, Y, Z coordinates of disjoint control point read from - an HDF5 file named according to control_point_file. - unit: NX_LENGTH - # \@units: nm - dimensions: - rank: 2 - dim: [[1, N], [2, n_control_pts]] - method: - doc: | - Method used for identifying and refining the location of the - interface. Currently, paraprobe-nanochem implements a PCA followed - by an iterative loop of isotropic mesh refinement and DCOM step(s), - paired with self-intersection detection in a more robust - implementation. - enumeration: [pca_plus_dcom] - decorating_iontypes_filter(NXprocess): - doc: | - Specify the types of those ions which decorate the interface and - can thus be assumed as markers for locating the interface and - refining its local curvature. - candidates(NX_UINT): - doc: | - Array of iontypes to filter. The list is interpreted as a whitelist, - i.e. ions of these types are considered the decorating species (solutes). - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_fct_filter_cand]] - number_of_iterations(NX_UINT): - doc: How many times should the DCOM and mesh refinement be applied? - unit: NX_UNITLESS - target_edge_length(NX_FLOAT): - doc: | - Array of decreasing positive not smaller than one nanometer real values - which specify how the initial triangles of the mesh should be iteratively - refined by edge splitting and related mesh refinement operations. - unit: NX_LENGTH - # \@units: nm - dimensions: - rank: 1 - dim: [[1, n_fct_iterations]] - target_dcom_radius(NX_FLOAT): - doc: | - Array of decreasing positive not smaller than one nanometer real values - which specify the radius of the spherical region of interest within - which the DCOM algorithm decides for each vertex how the vertex will - be eventually relocated. The larger the DCOM radius is relative to - the target_edge_length the more likely it is that vertices will be - relocated so substantially that eventually triangle self-intersections - can occur. If the code detects these it warns and stops in a - controlled manner so that the user can repeat the analyses - with a smaller value. - unit: NX_LENGTH - # \@units: nm - dimensions: - rank: 1 - dim: [[1, n_fct_iterations]] - target_smoothing_step(NX_UINT): - doc: | - Array of integers which specify for each DCOM step how many times - the mesh should be iteratively smoothened. - - Users should be aware the three array target_edge_length, - target_dcom_radius, and target_smoothing_step are interpreted in the - same sequence, i.e. the zeroth entry of each array specifies the - values to be used in the first DCOM iteration. The first entry of - each array those for the second DCOM iteration and so on and so forth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_fct_iterations]] - - composition_profiling(NXprocess): - exists: [min, 0, max, 1] - doc: | - Functionalities for placing regions-of-interest (ROIs) in the dataset - or at specific microstructural features to characterize composition - profiles and cumulated profiles for quantification of interfacial excess. - Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed - across the triangulated surface of a user-defined mesh. - ROIs are placed at the barycenter of the triangular facet. - - The tool can be instructed to orient the profile for each ROIs with - the positive normal of the triangle facet normals. Profiles are - computed for each ROI and facet triangle. The code will test which - ROIs are completely embedded in the dataset. - Specifically, in this test the tool evaluates if the ROI cuts at least - one triangle of the triangulated surface mesh of the edge of the dataset. - If this is the case the ROI will be considered close to the edge - (of the dataset) and not analyzed further; else the ROI will be - processed further. - Users should be aware that the latter intersection analysis is strictly - speaking not a volumetric intersection analysis as such one is much - more involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder pierces - or is laying completely inside the polyhedron. For this the polyhedron has - to be tessellated into convex polyhedra as otherwise tests like the - Gilbert-Johnson-Keerthi algorithm would not be applicable. - - Specifically, the tool computes atomically decomposed profiles. - This means molecular ions are split into atoms/isotopes with respective - multiplicity. As an example an H3O+ molecular ion contains three - hydrogen and one oxygen atom respectively. The tool then evaluates - how many ions are located inside the ROI or on the surface of the - ROI respectively. All atom types and the unranged ions are distinguished. - As a result, the analyses yield for each ROI a set of sorted lists of - signed distance values. Currently, the distance is the projected - distance of the ion position to the barycenter of the triangle - and triangle plane. - - This will return a one-dimensional profile. Post-processing the set - of atom-type-specific profiles into cumulated profiles enable the - classical Krakauer/Seidman-style interfacial excess analyses. - Furthermore, the tool can be instructed to compute for each - (or a selected sub-set of facet) a set of differently oriented profiles. - # In the second case, these profiles will be probed in the direction of - # the outer unit surface normal vectors of a sphere. The sphere is - # discretized via a geodesic sphere (according to ideas of M. Kühbach - # et al. Journal of Applied Crystallography 2021) model with 40962 - # directions, some of which are duplicates (for now). This direction - # sampling enables substantially more detailed analyses of the effect - # of aligning the ROI because alignments of ROI based on triangle - # surface normals of the feature mesh can result in larger direction - # differences between neighboring ROIs when the mesh for rough - # surface meshes. - feature_mesh(NXprocess): - doc: | - The feature mesh enables the injection of previously computed triangle - soup or mesh data. Such a mesh can be the model for a grain- or phase - boundary patch (from e.g. interface_meshing) jobs. - filename: - doc: | - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the feature. - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - dataset_name_vertices: - doc: | - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - dataset_name_facet_indices: - doc: | - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - dataset_name_facet_normals: - doc: | - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details consistently oriented facet - normals of the facets. - # dataset_name_vertex_normals: - # doc: Absolute path to the HDF5 dataset in the respective specified - # HDF5 file under filename which details consistently oriented - # vertex normals of the facets. - # exists: optional - patch_identifier_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - ion_to_feature_distances(NXprocess): - exists: optional - doc: | - The tool enables to inject precomputed distance information for each - point which can be used for further post-processing and analysis. - # NEW ISSUE: is this optional? - filename: - doc: | - Name of an HDF5 file which contains ion distances. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically contains - these data. - dataset_name: - doc: | - Absolute HDF5 path to the dataset with distance values for each ion. - distancing_model: - doc: | - Which type of distance should be reported for the profile. - enumeration: [project_to_triangle_plane] - # NEW ISSUE:, ion_to_feature] - direction_model: - doc: In which directions should the tool probe for each ROI. - enumeration: [triangle_outer_unit_normal] - # NEW ISSUE:, angularly_geodesic_sphere] - roi_cylinder_height(NX_FLOAT): - doc: | - For each ROI, how high (projected on the cylinder axis) - should the cylindrical ROI be. - unit: NX_LENGTH - # \@units: nm - # all ROIs the same height - # dimensions: - # rank: 1 - # dim: [[1, 1]] - roi_cylinder_radius(NX_FLOAT): - doc: For each ROI, how wide (radius) should the cylindrical ROI be. - unit: NX_LENGTH - # \@units: nm - # all ROIs the same radius - # dimensions: - # rank: 1 - # dim: [[1, 1]] - - performance(NXcs_profiling): - current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml deleted file mode 100644 index 10d9ffab8f..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml +++ /dev/null @@ -1,225 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-ranger tool run in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_isotopes: The number of isotopes to consider as building blocks for searching molecular ions. - n_composition: The number of compositions to consider for molecular ion search tasks. -NXapm_paraprobe_config_ranger: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_ranger] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - number_of_processes(NX_UINT): - doc: How many task to perform? - unit: NX_UNITLESS - - (NXprocess): - exists: [min, 0, max, infty] - apply_existent_ranging(NXprocess): - exists: [min, 0, max, 1] - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - - molecular_ion_search(NXprocess): - exists: [min, 0, max, infty] - assumed_composition_isotopes(NX_UINT): - exists: optional - doc: | - A list of pairs of number of protons and either the value 0 (per row) - or the mass number for all those isotopes which are assumed present - in a virtual specimen. - The purpose of this field is to compute also composition-weighted - products to yield a simple estimation which could potentially help - scientists to judge if certain molecular ions are to be expected. - The corresponding setting store_composition_weighted_product should be - activated. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_composition], [2, 2]] - # assumed_composition_value(NX_FLOAT): - # doc: | - # A list of atomic (at.-%) ! percent values for the composition of each - # isotope in the virtual specimen following the sequence of - # assumed_composition_isotopes. - # unit: NX_DIMENSIONLESS - # dimensions: - # rank: 1 - # dim: [[1, n_compositions]] - isotope_whitelist(NX_UINT): - doc: | - A list of pairs of number of protons and mass number for all isotopes - to consider that can be composed into (molecular) ions, during the - recursive molecular_ion_search. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_isotopes], [2, 2]] - mass_to_charge_interval(NX_FLOAT): - doc: | - The mass-to-charge-state ratio interval in which - all molecular ions are searched. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, 2]] - maximum_charge(NX_UINT): - doc: The maximum charge that a molecular ion should have. - unit: NX_UNITLESS - maximum_number_of_isotopes(NX_UINT): - doc: | - The maximum number of isotopes of which the molecular ion - should be composed. Currently this must not be larger than 32. - - Users should be warned that the larger the maximum_charge and - especially the larger the maximum_number_of_isotopes is chosen, - the eventually orders of magnitude more costly the search becomes. - - This is because paraprobe-ranger computes really all (at least) - theoretically possible combinations that would have likely a - mass-to-charge-state ratio in the specified mass_to_charge_interval. - It is the challenge in atom probe to judge which of these (molecular) - ions are feasible and also practically possible. This tool does not - answer this question. - - Namely, which specific molecular ion will evaporate, remain stable - during flight and becomes detected is a complicated and in many cases - not yet in detail understood phenomenon. The ab-initio conditions - before and during launch, the local environment, arrangement and field - as well as the flight phase in an evacuated but not analysis chamber - with a complex electrical field, eventual laser pulsing in place, - temperature and remaining atoms or molecules all can have an effect - which iontypes are really physically evaporating and detected. - unit: NX_UNITLESS - store_atomic_mass_sum(NX_BOOLEAN): - doc: | - Report the accumulated atomic mass from each isotope building the ion. - Accounts for each identified ion. - Relatistic effects are not accounted for. - store_natural_abundance_product(NX_BOOLEAN): - doc: | - Report the product of the natural abundances from each isotope building - the ion. Accounts for each identified ion. - - The value zero indicates it is not possible to build such molecular ion - from nuclids which are all observationally stable. - Very small values can give an idea/about how likely such a molecular ion - is expected to form assuming equal probabilities. - - However in atom probe experiments this product has to be modified - by the (spatially-correlated) local composition in the region from - which the ions launch because the formation of a molecular ion depends - as summarized under maximum_number_of_isotopes on the specific - quantum-mechanical configuration and field state upon launch - or/and (early state) of flight respectively. - We are aware that this modified product can have a substantially - different value than the natural_abundance_product. - - Natural abundancies folded with the estimated compositions of the - specimen can differ by orders of magnitude. - # add assumed composition of the specimen - # store_composition_weighted_product(NX_BOOLEAN): - # doc: | - # Report the product of the composition from each isotope building the - # ion. This sets strong constraints on the molecular ions which are - # expected to have at all a noteworthy product value. - # It should not be forgotten though the computation relies on assumptions: - # - # * The composition is homogeneous within the virtual specimen. - # * It is a priori know which nuclids the specimen is build of. - # - store_charge_state(NX_BOOLEAN): - doc: | - Report the charge state of the ions. - store_disjoint_isotopes(NX_BOOLEAN): - doc: | - Report if identified ions should be characterized - wrt to their number of disjoint isotopes. - - check_existent_ranging(NXprocess): - exists: [min, 0, max, 1] - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - - performance(NXcs_profiling): - current_working_directory: \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml deleted file mode 100644 index b888a47393..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml +++ /dev/null @@ -1,89 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-selector tool run in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXapm_paraprobe_config_selector: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_selector] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - number_of_processes(NX_UINT): - doc: | - How many roi_selection processes should the tool execute. - unit: NX_UNITLESS - roi_selection(NXprocess): - exists: [min, 1, max, 1] # for now allow for only one process - doc: | - This process identifies which of the points/ions in the datasets are - inside or on the surface of geometric primitives and meet optionally - specific other filtering constraints. - A typical use case of a roi_selection is to restrict analyses to - specific regions of the dataset, eventually regions with a complicated - shape. - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - - spatial_filter(NXspatial_filter): - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - cardinality(NX_POSINT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - # orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - cardinality(NX_POSINT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - cardinality(NX_POSINT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_FLOAT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - linear_range_min_incr_max(NX_UINT): - iontype_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml deleted file mode 100644 index 641b964428..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml +++ /dev/null @@ -1,273 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-spatstat tool run in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ivecmax: Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - n_ion_source: Number of different sources iontypes to distinguish. - n_ion_target: Number of different target iontypes to distinguish. -NXapm_paraprobe_config_spatstat: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_spatstat] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - number_of_processes(NX_UINT): - doc: | - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - unit: NX_UNITLESS - (NXprocess): - exists: [min, 1, max, 1] - spatial_statistics(NXprocess): - exists: [min, 0, max, 1] - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - ion_to_edge_distances(NXprocess): - exists: optional - doc: | - The tool enables to inject precomputed distances of each ion to a - representation of the edge of the dataset which can be used to - control and substantially reduce edge effects when computing - spatial statistics. - filename: - doc: | - Name of an HDF5 file which contains ion-to-edge distances. - dataset_name_distances: - doc: | - Absolute HDF5 path to the dataset with the - ion-to-edge distance values for each ion. - The shape of the distance values has to match the length - of the ion positions array in dataset/dataset_name_reconstruction - and dataset_name_mass_to_charge respectively. - edge_distance(NX_FLOAT): - doc: | - Threshold to define how large an ion has to lay at least far away - from the edge of the dataset so that the ion can act as a source, - i.e. that an ROI is placed at the location of the ion and its - neighbors are analyzed how they contribute to the computed statistics. - - The ion_to_edge_distances threshold can be combined with a threshold - for the ion_to_feature_distances. - Specifically, if ion_to_feature_distances are loaded an ion only - acts as a source if both threshold criteria are met. - - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. - unit: NX_LENGTH - ion_to_feature_distances(NXprocess): - exists: optional # NEW ISSUE: is this optional? - doc: | - In addition to spatial filtering, and considering how far ions lie - to the edge of the dataset, it is possible to restrict the analyses - to a sub-set of ions within a distance not farther away to a feature than - a threshold value. - filename: - doc: | - Name of an HDF5 file which contains ion-to-feature distances. - dataset_name_distances: - doc: | - Absolute HDF5 path to the dataset with the - ion-to-feature distance values for each ion. - threshold(NX_FLOAT): - doc: | - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that the ion_to_feature_distances threshold is combined - with the ion_to_edge_distances threshold. - unit: NX_LENGTH - # ##MK::think about an inversion ruleset for the filter, i.e. - # like discussed in Haley/Stephenson's paper where ions only far enough - # from a feature AND deeply embedded enough in the dataset are chosen. - randomize_ion_types(NX_BOOLEAN): - doc: | - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - random_number_generator(NXcs_prng): - exists: recommended - type: - seed(NX_NUMBER): - warmup(NX_NUMBER): - ion_query_type_source: - doc: | - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis regardless - of which iontype it is. Each active ion is accounted for once. - - The value resolve_unknown will set an ion active when the ion is - of the UNKNOWNTYPE type. Each active ion is accounted for once. - - The value resolve_ion will set an ion active if it is of the specific - iontype, irregardless of its elemental or isotopic details. - Each active ion is counted once. - - The value resolve_element will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - - The value resolve_isotope will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - isotopes in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized, i.e. how - often it is accounted for. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - ion_query_isotope_vector_source(NX_UINT): - doc: | - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_ion_source], [2, n_ivecmax]] - ion_query_type_target: - doc: | - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - # NEW ISSUE: conditionally required only when resolve_isotope - ion_query_isotope_vector_target(NX_UINT): - doc: | - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_ion_target], [2, n_ivecmax]] - statistics(NXprocess): - doc: | - Specifies which spatial statistics to compute. - knn(NXprocess): - doc: | - Compute k-th nearest neighbour statistics. - exists: optional - nth(NX_UINT): - doc: | - Order k. - unit: NX_UNITLESS - histogram_min_incr_max(NX_FLOAT): - doc: | - Minimum value, increment, and maximum value of the histogram binning. - unit: NX_LENGTH - # \@units: nm - dimensions: - rank: 1 - dim: [[1, 3]] - rdf(NXprocess): - doc: | - Compute radial distribution function. - exists: optional - histogram_min_incr_max(NX_FLOAT): - doc: | - Minimum value, increment, and maximum value of the histogram binning. - unit: NX_LENGTH - # \@units: nm - dimensions: - rank: 1 - dim: [[1, 3]] - # NEW ISSUE: ripleyk(NXcollection): - # NEW ISSUE: two_point(NXcollection): - - performance(NXcs_profiling): - current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml deleted file mode 100644 index e7a7323c92..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml +++ /dev/null @@ -1,205 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-surfacer tool run in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_alpha_values: Number of alpha values (and offset values) to probe. - n_values: How many different match values does the filter specify. -NXapm_paraprobe_config_surfacer: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_surfacer] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - number_of_processes(NX_UINT): - doc: | - For now a support field for the tool to identify how many individual - analyses the tool should executed as part of the analysis. - unit: NX_UNITLESS - (NXprocess): - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - # ##MK::ion_id_filter(NXcs_filter_boolean_mask): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - linear_range_min_incr_max(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 3]] - iontype_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_values]] - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_values]] - surface_meshing(NXprocess): - preprocessing_method: - doc: | - Specifies the method that is used to preprocess the point cloud. - The main purpose of this setting is to specify whether the point - cloud should be segmented or not during the preprocessing - to identify which points are more likely lying close to the edge - of the point cloud. These points could be more relevant than the - interior points for certain alpha-shape constructions. - - By default no such filtering is used during pre-processing. - By contrast, the option kuehbach activates a preprocessing - during which a Hoshen-Kopelman percolation analysis is used - to identify which points are closer to the edge of the dataset. - This can reduce the number of points in the alpha-shape - computation and thus improve performance substantially. - Details about the methods are reported in - `M. Kühbach et al. `_. - enumeration: [default, kuehbach] - preprocessing_kernel_width(NX_UINT): - # the exists is dependant on the value for preprocessing_method - doc: | - When using the kuehbach preprocessing, this is the width of the - kernel for identifying which ions are in voxels close to the - edge of the point cloud. - unit: NX_UNITLESS - alpha_value_choice: - doc: | - Specifies which method to use to define the alpha value. - The value convex_hull_naive is the default. This instructs the tool - to use a fast specialized algorithm for computing only the convex - hull. The resulting triangles can be skinny. - - The value convex_hull_refine computes first also a convex_hull_naive - but refines the mesh by triangle flipping and splitting to improve - the quality of the mesh. - - The value smallest_solid instructs the CGAL library to choose a - value which realizes an alpha-shape that is the smallest solid. - - The value cgal_optimal instructs the library to choose a value - which the library considers as an optimal value. Details are - define in the respective section of the CGAL library on 3D alpha - shapes. - - The value set_of_values instructs to compute a list of - alpha-shapes for the specified alpha-values. - - The value set_of_alpha_wrappings instructs the library to generate - a set of so-called alpha wrappings. These are a method - which is similar to alpha shapes but provide additional guarantees - though such as watertightness and proximity constraints on the - resulting wrapping. - # NEW ISSUE: further details CGAL documentation - enumeration: [convex_hull_naive, convex_hull_refine, smallest_solid, cgal_optimal, set_of_values, set_of_alpha_wrappings] - alpha_values(NX_FLOAT): - doc: | - Array of alpha values to use when alpha_value_choice is set_of_values - or when alpha_value_choice is set_of_alpha_wrappings. - unit: NX_ANY - # \@units: nm^2 - dimensions: - rank: 1 - dim: [[1, n_alpha_values]] - offset_values(NX_FLOAT): - doc: | - Array of offset values to use when alpha_value_choice is - set_of_alpha_wrappings. The array of alpha_values and offset_values - define a sequence of (alpha and offset value). - unit: NX_LENGTH - # \@units: nm - dimensions: - rank: 1 - dim: [[1, n_alpha_values]] - has_exterior_facets(NX_BOOLEAN): - doc: | - Specifies if the tool should compute the set of exterior triangle - facets for each alpha complex (for convex hull, alpha shapes, and wrappings) - has_closure(NX_BOOLEAN): - doc: | - Specifies if the tool should check if the alpha complex of exterior - triangular facets is a closed polyhedron. - has_interior_tetrahedra(NX_BOOLEAN): - doc: | - Specifies if the tool should compute all interior tetrahedra - of the alpha complex (currently only for alpha shapes). - # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): - - performance(NXcs_profiling): - current_working_directory: \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml deleted file mode 100644 index 472e33115b..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml +++ /dev/null @@ -1,186 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-tessellator tool run in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - # n_control_points: The number of control points for tessellating regions instead of tessellating the volume about ion positions. -NXapm_paraprobe_config_tessellator: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_tessellator] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - number_of_processes(NX_UINT): - doc: | - How many individual analyses should the tool execute. - unit: NX_UNITLESS - (NXprocess): - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - # a perfect example for limited conditions in NeXus - # if windowing_method is entire_dataset: no constraint on existence of NXcg and NXcs instances - # if windowing_method is union_of_primitives: sum of cardinality of NXcg >= 0 - # if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardinality of NXcs_filter_boolean_mask == 1 - - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - - ion_to_edge_distances(NXprocess): - exists: optional - doc: | - The tool enables to inject precomputed distance information for - each point which can be used for further post-processing and analysis. - filename: - doc: | - Name of an HDF5 file which contains the ion distances. - Users are responsible this file and referred to dataset under - dataset_name have an ion_distance value for each ion. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional layer of - reproducibility. - dataset_name: - doc: | - Absolute HDF5 path to the dataset with distance values for each ion. - tessellating(NXprocess): - method: - doc: | - Specifies for which points the tool will compute the tessellation. - By default, a Voronoi tessellation is computed for all ions in the - filtered point cloud. - # The value control_points will compute the tessellation for the - # provided overlay_control_points irregardless of the ion point cloud. - # This enables for instance computations as proposed by P. Felfer and - # coworkers where, for the purpose of e.g. interfacial excess quantification, - # a tessellation of the dataset into regions about manually-specified - # control points is needed. - # For this option, the overlay_control points. - enumeration: [default] #, control_points] - # overlay_control_points(NXprocess): - # doc: | - # Overlaying an additional set of control points onto the reconstruction - # can be used as a first step to construct a tessellation of the dataset - # into regions to segment the dataset or construct a model for internal - # structural features in the dataset. Such an approach was suggested - # e.g. by P. Felfer et al. which use a control points to locate - # interfaces (grain/phase boundaries) in atom probe data to perform - # e.g. interfacial excess computations. The control points can be - # imported for example from some manual preprocessing of a dataset - # where the user figured these control points could be of relevance - # for the analysis. - # # NEW ISSUE: dislocation lines - # exists: optional - # filename: - # doc: | - # Name of an HDF5 file which contains control point coordinates. - # \@version: - # doc: | - # Version identifier of the file such as a secure hash which - # documents the binary state of the file to add an additional - # layer of reproducibility. - # dataset_name: - # doc: | - # Absolute HDF5 path to the dataset which contains the array of - # control points. This has to be an array of shape - # (n_control_points, 3). - has_cell_volume(NX_BOOLEAN): - doc: | - Specifies if the tool should report the volume of each cell. - has_cell_neighbors(NX_BOOLEAN): - doc: | - Specifies if the tool should report the first-order neighbors of each cell. - has_cell_geometry(NX_BOOLEAN): - doc: | - Specifies if the tool should report the facets and vertices of each cell. - has_cell_edge_detection(NX_BOOLEAN): - doc: | - Specifies if the tool should report if the cell makes contact with - the tight axis-aligned bounding box about the point cloud. - This can be used to identify if the shape of the cell is affected - by the edge of the dataset or if cells are deeply enough embedded - into the point cloud so that the shape of their cells are not affected - by the presence of the boundary. - # erosion_distance(NX_FLOAT): - # doc: | - # Maximum distance for which cells are eroded. - # unit: NX_LENGTH - # # \@units: nm - # # minValue: EPSILON - - performance(NXcs_profiling): - current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml deleted file mode 100644 index f9896fb6a8..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml +++ /dev/null @@ -1,69 +0,0 @@ -category: application -doc: | - Configurations of a paraprobe-transcoder tool run in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXapm_paraprobe_config_transcoder: - (NXentry): - exists: [min, 1, max, 1] - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_transcoder] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ideally an ever persistent resource where the source code of the - program and build instructions can be found so that the program can be - configured ideally in such a manner that the result of this computational - process is recreatable deterministically. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - (NXprocess): - # NXapm_input base classes are specialized here because - # paraprobe-transcoder is the entry point for community data - # which are not necessarily NeXus - dataset(NXapm_input_reconstruction): - filename: - doc: | - The path and name of the file (technology partner or community format) - from which to read the reconstructed ion positions. Currently, POS, - ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files - are supported. - \@version: - iontypes(NXapm_input_ranging): - filename: - doc: | - The path and name of the file (technology partner or community format - from which to read the ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. - NeXus/HDF5 files are supported. - \@version: - - performance(NXcs_profiling): - current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml deleted file mode 100644 index bdbf03a502..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml +++ /dev/null @@ -1,437 +0,0 @@ -category: application -doc: | - Results of a paraprobe-clusterer tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: The total number of ions in the reconstruction. - n_dict: The total number of entries in the restricted_identifier dictionary. - -NXapm_paraprobe_results_clusterer: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_clusterer] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: optional - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: | - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - # ##MK::define also reconstruction coordinate system and - # ##MK::map between the two - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - -# ##MK::begin of the tool-specific section - (NXprocess): - exists: [min, 0, max, 1] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. - number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - - cluster_analysis(NXprocess): - exists: optional - doc: | - The result of a cluster analyses. These include typically the label for - each ion/point documenting to which feature (if any) an ion is assigned. - Typically, each analysis/run yields only a single cluster. - In cases of fuzzy clustering it can be possible that an ion is assigned - to multiple cluster (eventually with different) weight/probability. - dbscanID(NXsimilarity_grouping): - exists: [min, 0, max, infty] - doc: | - Results of a DBScan clustering analysis. - eps(NX_FLOAT): - doc: The epsilon (eps) parameter. - unit: NX_LENGTH - min_pts(NX_UINT): - doc: The minimum points (min_pts) parameter. - unit: NX_UNITLESS - cardinality(NX_UINT): - doc: | - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset. Cardinality here is not the total number of ions in the - dataset. - unit: NX_UNITLESS - # number_of_numeric_labels(NX_UINT): - # doc: | - # How many numerical labels does each feature have. - # unit: NX_UNITLESS - # number_of_categorical_labels(NX_UINT): - # doc: | - # How many categorical labels does each feature have. - # unit: NX_UNITLESS - # features: - # doc: | - # Reference to a set of features investigated in a cluster analysis. - # Features need to have disjoint numeric identifier. - identifier_offset(NX_NUMBER): - doc: | - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. - unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_lbl_num]] - # reserved_identifier_keyword(NX_UINT): - # doc: | - # By default we assume that cluster identifier 0 is reserved to - # mark that ions are not assigned to a cluster and identifier 1 is - # noise. The reserved_identifier_keyword and reserved_identifier_value - # can be used as a dictionary though to define that users - # which to overwrite this default and define own specific categories. - # In every case though cluster_identifier have to be positive integer - # and be consecutive on $[0, maximum_value]$. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_dict]] - # reserved_identifier_value: - # doc: | - # The corresponding value of the reserved_identifier dictionary. - # This can give a free-text description what a specific reserved - # ID specifies e.g. ignored, noise. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_dict]] - targets(NX_UINT): - doc: | - The evaporation sequence identifier to figure out which ions - from the reconstruction were considered targets. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - # quantities for debugging purposes - model_labels(NX_INT): - doc: | - The raw labels from the DBScan clustering backend process. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - core_sample_indices(NX_INT): - doc: | - The raw array of core sample indices which specify which of the - targets are core points. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n]] - # quantities to which these debugging quantities should be transformed - numerical_label(NX_UINT): # the cluster_identifier ! - doc: | - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the cluster_identifier. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] # ], [2, n_lbl_num]] - # categorical_label: - # doc: | - # Matrix of categorical attribute data for each member in the set. - # dimensions: - # rank: 2 - # dim: [[1, c], [2, n_lbl_cat]] - weight(NX_NUMBER): - exists: optional - doc: | - The array of weight which specifies how surely/likely the - cluster is associated/assigned to a specific identifier as - is specified in the cluster_identifier array. - For the DBScan and atom probe tomography the multiplicity - of each ion with respect to the cluster. That is how many times - should the position of the ion be accounted for because the ion - is e.g. a molecular ion with several elements or isotope of - requested type. - unit: NX_UNITLESS # ##MK:NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, c]] - is_noise(NX_BOOLEAN): - exists: optional - doc: | - Optional bitmask encoding if members of the set are assigned to as noise or not. - dimensions: - rank: 1 - dim: [[1, c]] - is_core(NX_BOOLEAN): - exists: optional - doc: | - Optional bitmask encoding if member of the set are a core point. - For details to which feature/cluster an ion/point is a core point - consider numerical_label. - dimensions: - rank: 1 - dim: [[1, c]] - statistics(NXprocess): - doc: | - In addition to the detailed storage which members was grouped to - which feature/group summary statistics are stored under this group. - # at the level of the set - # number_of_unassigned_members(NX_UINT): - # doc: | - # Total number of members in the set which are categorized as unassigned. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_lbl_num]] - number_of_noise(NX_UINT): - doc: | - Total number of members in the set which are categorized as noise. - unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_lbl_num]] - number_of_core(NX_UINT): - doc: | - Total number of members in the set which are categorized as a core point. - unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_lbl_num]] - # at the level of the feature set - number_of_features(NX_UINT): - doc: | - Total number of clusters (excluding noise and unassigned). - unit: NX_UNITLESS - feature_identifier(NX_UINT): - doc: | - Array of numerical identifier of each feature (cluster). - unit: NX_UNITLESS - dimensions: - rank: 1 # 2 - dim: [[1, n_features]] # [2, n_lbl_num]] - feature_member_count(NX_UINT): - doc: | - Array of number of members for each feature. - unit: NX_UNITLESS - dimensions: - rank: 1 # 2 - dim: [[1, n_features]] #, [2, n_lbl_num]] - - # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN - -# ##MK::end of the tool-specific section - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml deleted file mode 100644 index 0e7724fcdc..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml +++ /dev/null @@ -1,330 +0,0 @@ -category: application -doc: | - Results of a paraprobe-distancer tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: The total number of ions in the reconstruction. - n_tris: The total number of triangles in the set. - -NXapm_paraprobe_results_distancer: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_distancer] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: Details about the coordinate system conventions used. - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - -# ##MK::begin of the tool-specific section - (NXprocess): - exists: [min, 0, max, 1] - point_to_triangle_set(NXprocess): - doc: | - The tool can be used to compute the analytical distance of each ion - to a set of triangles. - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed. - number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - window_triangles(NXcs_filter_boolean_mask): - exists: optional - doc: | - A bitmask which identifies which of the triangles in the set - were considered. Usually these are all but sometimes users may - wish to filter certain portions of the triangles out. - If window_triangles is not provided it means that - all triangles were taken. - number_of_triangles(NX_UINT): - doc: | - Number of triangles covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_triangles]] - distance(NX_FLOAT): - doc: | - The closest analytical distance of the ions to their respectively - closest triangle from the triangle set. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, i]] - sign_valid(NXcs_filter_boolean_mask): - exists: optional - doc: | - A bitmask which identifies which of the distance values - can be assumed to have a consistent sign because the closest - triangle had a consistent outer unit normal defined. - For points whose bit is set 0 the distance is correct but the - sign is not reliable. - number_of_points(NX_UINT): - doc: | - Number of triangles covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - triangle_identifier(NX_UINT): - exists: optional - doc: | - The identifier of the triangle that is closest for each ion. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - xdmf_ion_identifier(NX_UINT): - exists: optional - doc: | - A support field to visualize each ion and with this the distance - informations using XDMF and e.g. Paraview. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - -# ##MK::end of the tool-specific section - - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml deleted file mode 100644 index ac179c7df4..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml +++ /dev/null @@ -1,326 +0,0 @@ -category: application -doc: | - Results of a paraprobe-intersector tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_c2n: The total number of links pointing from current to next. - n_n2c: The total number of links pointing from next to current. - n_features_curr: The total number of members in the current_set. - n_features_next: The total number of members in the next_set. - n_cluster: The total number of cluster found for coprecipitation analysis. - n_total: The number of rows in the table/matrix for coprecipitation stats. - -NXapm_paraprobe_results_intersector: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_intersector] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - exists: optional - doc: Details about the coordinate system conventions used. - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - -# ##MK::begin of the tool-specific section - (NXprocess): - VOLUME_VOLUME_SPATIAL_CORRELATION(NXprocess): - exists: [min, 0, max, 1] - doc: | - The results of an overlap/intersection analysis. - current_to_next_link(NX_UINT): - doc: | - A matrix of feature_identifier which specifies which named features - from the current set have directed link(s) pointing to which named - feature(s) from the next set. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_c2n], [2, 2]] - current_to_next_link_type(NX_UINT): - doc: | - For each link/pair in current_to_next a characterization - whether the link is due to a volumetric overlap (0x00 == 0), - proximity (0x01 == 1), or something else unknown (0xFF == 255). - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_c2n]] - next_to_current_link(NX_UINT): - exists: optional # is an intersection analysis symmetrical ? - doc: | - A matrix of feature_identifier which specifies which named feature(s) - from the next set have directed link(s) pointing to which named - feature(s) from the current set. Only if the mapping whereby the - links is symmetric next_to_current maps the links in current_to_next - in the opposite direction. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n2c], [2, 2]] - next_to_current_link_type(NX_UINT): - exists: optional - doc: | - For each link/pair in next_to_current a characterization - whether the link is due to a volumetric overlap (0x00 == 0), - proximity (0x01 == 1), or something else unknown (0xFF == 255). - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_n2c]] - intersection_volume(NX_FLOAT): - exists: optional - doc: | - For each pair of links in current_to_next the volume of the - intersection, i.e. how much volume do the two features share. - If features do not intersect the volume is zero. - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, c2n]] - coprecipitation_analysis(NXprocess): - exists: optional - doc: | - During coprecipitation analysis the current and next set are analyzed - for links in a special way. Three set comparisons are made. Members - of the set in each comparison are analyzed for overlap and proximity: - - The first comparison is the current_set against the current_set. - The second comparison is the next_set against the next_set. - The third comparison is the current_set against the next_set. - - Once the (forward) links for these comparisons are ready the - pair relations are analyzed with respect to which feature identifier - cluster in identifier space. Thereby a logical connection (link) is - established between the features in the current_set and next_set. - Recall that these two set typically represent different features - within an observed system for otherwise the same parameterization. - Examples include two sets of e.g. precipitates with differing - chemical composition that were characterized in the same material - volume representing a snapshot of an e.g. microstructure at the same - point in time. Researchers may have performed two analyses, one to - characterize precipitates A and another one to characterize percipitates - B. Coprecipitation analysis now logically connects these independent - characterization results to establish spatial correlations of e.g. - precipitates spatial arrangement. - current_set_feature_to_cluster(NX_UINT): - doc: | - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the current_set. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_features_curr], [2, 2]] - next_set_feature_to_cluster(NX_UINT): - doc: | - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the next_set. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_features_next], [2, 2]] - cluster_identifier(NX_UINT): - doc: | - The identifier (names) of the cluster. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_cluster]] - cluster_composition(NX_UINT): - doc: | - Pivot table as a matrix. The first column encodes how many - members from the current_set are in each cluster, one row per cluster. - The second column encodes how many members from the next_set are - in each cluster, in the same row per cluster respectively. - The last column encodes the total number of members in the cluster. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_cluster], [2, 3]] - cluster_statistics(NX_UINT): - doc: | - Pivot table as a matrix. The first column encodes the different - types of clusters based on their number of members in the sub-graph. - The second column encodes how many clusters with as many members - exist. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_total], [2, 2]] - # ##MK::add results from NXapm_paraprobe_results_clusterer - -# ##MK::end of the tool-specific section - - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml deleted file mode 100644 index ab81db5353..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml +++ /dev/null @@ -1,1732 +0,0 @@ -category: application -doc: | - Results of a paraprobe-nanochem tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: The total number of ions in the reconstruction. - n_atomic: The total number of atoms in the atomic_decomposition match filter. - n_isotopic: The total number of isotopes in the isotopic_decomposition match filter. - d: The dimensionality of the delocalization grid. - c: | - The cardinality/total number of cells/grid points in the delocalization grid. - # c_tri_soup: | - # The cardinality/total number of triangles in the triangle soup. - n_f_tri_xdmf: The total number of XDMF values to represent all faces of triangles via XDMF. - n_feature_dict: The total number of entries in a feature dictionary. - n_speci: The total number of member distinguished when reporting composition. -NXapm_paraprobe_results_nanochem: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_nanochem] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: optional - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: | - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - # ##MK::define also reconstruction coordinate system and - # ##MK::map between the two - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - -# ##MK::begin of the tool-specific section - (NXprocess): - exists: [min, 0, max, 1] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. - number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - - iso_surface_analysis(NXprocess): - exists: [min, 0, max, infty] - DELOCALIZATION(NXdelocalization): - weighting_model: - doc: | - The weighting model specifies how mark data are mapped to a weight - per point/ion. For atom probe microscopy (APM) mark data are e.g. - which iontype an ion has. As an example, different models are used - which account differently for the multiplicity of a point/ion - during delocalization: - - * unity, all points/ions get the same weight 1. - * atomic_decomposition, points get as much weight as they - have atoms of a type in atomic_decomposition_rule, - * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotopic_decomposition_rule. - - enumeration: [unity, atomic_decomposition, isotopic_decomposition] - # if weighting_model == atomic_decomposition needs atomic_decomposition_rule - # if weighting_model == isotopic_decomposition needs isotopic_decomposition_rule - atomic_decomposition_rule(NXmatch_filter): - exists: optional # but required when weighting_model is atomic_decomposition - doc: | - A list of elements (via proton number) to consider for the - atomic_decomposition weighting model. - Elements must exist in the periodic table of elements and be - specified by their number of protons. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - In the case of elements this hashing rule has the advantage - that for elements the proton number is their hash value because - N is zero. - method: - doc: | - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - enumeration: [whitelist, blacklist] - match(NX_NUMBER): - doc: | - Array of values to filter according to method. For example, - if the filter specifies [1, 5, 6] and method is whitelist, - only entries with values matching 1, 5 or 6 will be processed. - All other entries will be filtered out/not considered. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_atomic]] - isotopic_decomposition_rule(NXmatch_filter): - exists: optional # but required when weighting model is isotopic_decomposition - doc: | - A list of isotopes (via proton and neutron number) to consider - for the isotopic_decomposition weighting model. - Isotopes must exist in the nuclid table. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - method: - doc: | - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - enumeration: [whitelist, blacklist] - match(NX_NUMBER): - doc: | - Array of values to filter according to method. For example, - if the filter specifies [1, 5, 6] and method is whitelist, - only entries with values matching 1, 5 or 6 will be processed. - All other entries will be filtered out/not considered. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_isotopic]] - normalization: - doc: | - How results of the kernel-density estimation were computed - into quantities. By default the tool computes the total number - (intensity) of ions or elements. Alternatively the tool can compute - the total intensity, the composition, or the concentration of the - ions/elements specified by the white list of elements in each voxel. - enumeration: [total, candidates, composition, concentration] - weight(NX_NUMBER): - exists: optional - doc: | - Weighting factor, in atom probe, often termed multiplicity. - The weighting factor is the multiplier with which the integrated - intensity contribution from the point/ion gets multiplied. - The delocalization computes the integrated intensity for each - grid cell. Effectively, this is an explicitly evaluated kernel - method where each specific position of an ion is replaced by a - smoothing kernel. For atom probe weights are positive and integer - specifically the multiplicity of the ion, in accordance with the - respective rulesets as defined by weighting_model. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - grid(NXcg_grid): - doc: | - The discretized domain/grid on which the delocalization is applied. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: The total number of cells/voxels of the grid. - unit: NX_UNITLESS - origin(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, d]] - symmetry: - doc: | - The symmetry of the lattice defining the shape of the unit cell. - enumeration: [cubic] - cell_dimensions(NX_NUMBER): - doc: | - The unit cell dimensions according to the coordinate system - defined under coordinate_system. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, d]] - extent(NX_POSINT): - doc: | - Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, d]] - # (NXtransformations): - coordinate_system: - exists: optional - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - If the coordinate system is not specified the paraprobe - coordinate system is used. - # should constraints on the grid be place here or not - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for - distinguishing identifiers for cells. Identifiers are defined - either implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS - bounding_box(NXcg_hexahedron_set): - doc: | - A tight axis-aligned bounding box about the grid. - is_axis_aligned(NX_BOOLEAN): - doc: | - For atom probe should be set to true. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS - hexahedron(NXcg_face_list_data_structure): - vertex_identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS - vertices(NX_NUMBER): - doc: | - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, 8], [2, 3]] - faces(NX_NUMBER): - doc: | - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, 6], [2, 4]] - xdmf_topology(NX_UINT): - doc: | - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 36]] - - number_of_boundaries(NX_POSINT): - exists: optional - doc: | - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - unit: NX_UNITLESS - boundaries: - exists: optional - doc: | - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - dimensions: - rank: 1 - dim: [[1, 6]] - boundary_conditions(NX_INT): - exists: optional - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 6]] - # ##MK::how to avoid storing it for once in NeXus for H5Web and - # for XDMF in ParaView ? - scalar_field_magnitude(NXdata): - doc: | - The result of the delocalization based on which subsequent - iso-surfaces will be computed. In commercial software so far - there is not a possibility to export such grid. - # ##MK::math notation - \@long_name: - exists: optional - \@signal: - \@axes: - \@xpos_indices: - \@ypos_indices: - \@zpos_indices: - intensity(NX_FLOAT): - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] # silent flip here? - xpos(NX_FLOAT): - doc: | - Cell center of mass positions along x. - dimensions: - rank: 1 - dim: [[1, n_x]] - # ##MK::how to relate back that this x is paraprobe x? - ypos(NX_FLOAT): - doc: | - Cell center of mass positions along y. - dimensions: - rank: 1 - dim: [[1, n_y]] - zpos(NX_FLOAT): - doc: | - Cell center of mass positions along z. - dimensions: - rank: 1 - dim: [[1, n_z]] - xdmf_intensity(NX_FLOAT): - exists: optional - doc: | - Intensity of the field at given point - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_xyz]] - xdmf_xyz(NX_FLOAT): - exists: optional - doc: | - Center of mass positions of each voxel for - rendering the scalar field via XDMF in e.g. - Paraview. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_xyz], [2, 3]] - xdmf_topology(NX_NUMBER): - exists: optional # but when xdmf_xyz exists also xdmf_topology has to exist - doc: | - XDMF topology for rendering in combination with - xdmf_xyz the scalar field via XDFM in e.g. Paraview. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 3*n_xyz]] # ##MK::better syntax needed - scalar_field_gradient(NXdata): - doc: | - The three-dimensional gradient nabla operator applied to - scalar_field_magnitude. - # ##MK::boundary conditions which type of accuracy - # ##MK::math notation - \@signal: - \@axes: - # ##MK::vector_indices, # ##MK: 3 - \@xpos_indices: # ##MK: 2 - \@ypos_indices: # ##MK: 1 - \@zpos_indices: # ##MK: 0 - \@long_name: - exists: optional - intensity(NX_FLOAT): - dimensions: - rank: 4 - dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] # silent flip here? - xpos(NX_FLOAT): - doc: | - Cell center of mass positions along x. - dimensions: - rank: 1 - dim: [[1, n_x]] - # ##MK::how to relate back that this x is paraprobe x? - ypos(NX_FLOAT): - doc: | - Cell center of mass positions along y. - dimensions: - rank: 1 - dim: [[1, n_y]] - zpos(NX_FLOAT): - doc: | - Cell center of mass positions along z. - dimensions: - rank: 1 - dim: [[1, n_z]] - xdmf_gradient(NX_FLOAT): - exists: optional - doc: | - The gradient vector. - unit: NX_ANY - dimensions: - rank: 2 - dim: [[1, n_xyz], [2, 3]] - xdmf_xyz(NX_FLOAT): - exists: optional - doc: | - Center of mass positions of each voxel for - rendering the scalar field via XDMF in e.g. - Paraview. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_xyz], [2, 3]] - xdmf_topology(NX_NUMBER): - exists: optional # but when xdmf_xyz exists also xdmf_topology has to exist - doc: | - XDMF topology for rendering in combination with - xdmf_xyz the scalar field via XDFM in e.g. Paraview. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 3*n_xyz]] # ##MK::better syntax needed - kernel_size(NX_POSINT): - doc: | - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. - unit: NX_DIMENSIONLESS - #\@units: pixel - dimensions: - rank: 1 - dim: [[1, 3]] - # kernel_type: - # doc: | - # Functional form of the kernel (Ansatz function). - kernel_sigma(NX_FLOAT): - doc: | - Sigma of the kernel in each dimension in the paraprobe - coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - kernel_mu(NX_FLOAT): ##MK - doc: | - Expectation value of the kernel in each dimension in the paraprobe - coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - # ##MK:: - iso_surface(NXisocontour): - exists: optional - doc: | - An iso-surface is the boundary between two regions across which - the magnitude of a scalar field falls below/exceeds a threshold - magnitude phi. - For applications in atom probe microscopy the location and shape - of such a boundary (set) is typically approximated by - discretization. - This yields a complex of not necessarily connected geometric - primitives. Paraprobe-nanochem approximates this complex with - a soup of triangles. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - isovalue(NX_NUMBER): - doc: The threshold or iso-contour value. - unit: NX_ANY - marching_cubes(NXcg_marching_cubes): - doc: | - Details about the specific marching cubes algorithm - which was taken to compute the iso-surface. - The grid is the delocalization grid. - implementation: - doc: | - Reference to the specific implementation of marching cubes used. - The value placed here should be a DOI. If there are no specific - DOI or details write not_further_specified, or give at least a - free-text description. The program and version used is the - specific paraprobe-nanochem. - triangle_soup(NXcg_triangle_set): - exists: optional - doc: | - The resulting triangle soup computed via marching cubes. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for - distinguishing triangles. Identifiers are defined either - implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. - unit: NX_UNITLESS - triangles(NXcg_face_list_data_structure): - number_of_vertices(NX_POSINT): - doc: Number of vertices. - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - doc: Number of faces. - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - unit: NX_UNITLESS - vertices(NX_NUMBER): - doc: | - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - faces(NX_INT): - doc: | - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - xdmf_topology(NX_UINT): - doc: | - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_f_tri_xdmf]] - vertex_normal(NXcg_unit_normal_set): - exists: optional - normals(NX_FLOAT): - doc: | - Direction of each normal. - unit: NX_DIMENSIONLESS - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - exists: optional - doc: | - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - # edge_normal(NXcg_unit_normal_set): - # exists: optional - face_normal(NXcg_unit_normal_set): - exists: optional - normals(NX_FLOAT): - doc: | - Direction of each normal. - unit: NX_DIMENSIONLESS - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - orientation(NX_UINT): - exists: optional - doc: | - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - gradient_guide_magnitude(NX_FLOAT): - doc: | - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, k]] - # gradient_guide_quality(NX_FLOAT): - # doc: | - # Triangle normals are oriented in the direction of the - # gradient vector of the local delocalized scalar field. - # Sum of squared values of cross product of triangle normal - # construction. - # unit: NX_ANY - # dimensions: - # rank: 1 - # dim: [[1, k]] - gradient_guide_projection(NX_FLOAT): - doc: | - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - The projection variable here describes the cosine of the - angle between the gradient direction and the normal - direction vector. - This is a descriptor of how parallel the projection is - that is especially useful to document those triangles - for whose projection is almost perpendicular. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, k]] - area(NX_NUMBER): - exists: optional - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, j]] - edge_length(NX_NUMBER): - exists: optional - doc: | - Array of edge length values. For each triangle the edge length - is reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - interior_angle(NX_NUMBER): - exists: optional - doc: | - Array of interior angle values. For each triangle the angle - is reported for the angle opposite to the edges which are - traversed according to the sequence in which vertices - are indexed in triangles. - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, j], [2, 4]] - center(NX_NUMBER): - exists: optional - doc: The center of mass of each triangle. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - volumetric_feature(NXprocess): - exists: optional - doc: | - Iso-surfaces of arbitrary scalar three-dimensional fields - can show a complicated topology. Paraprobe-nanochem can run - a DBScan-like clustering algorithm which performs a - connectivity analysis on the triangle soup. This yields a - set of connected features with their surfaces discretized - by triangles. Currently, the tool distinguishes at most - three types of features: - - 1. So-called objects, i.e. necessarily watertight features - represented polyhedra. - 2. So-called proxies, i.e. features that were replaced by a - proxy mesh and made watertight. - 3. Remaining triangle surface meshes of arbitrary shape and - cardinality. - - These features can be interpreted as microstructural features. - Some of them may be precipitates, some of them may be poles, - some of them may be segments of dislocation lines or other - crystal defects which are decorated (or not) with solutes. - - # Each type of feature needs to be registered in the feature_type - # dictionary. Type identifiers (keywords are integer), values - # are human-readable names like object, proxy, undefined - # NEW ISSUE: refactor using instances of NXms_feature_set - triangle_cluster_identifier(NX_UINT): - doc: | - The identifier which the triangle_soup connectivity analysis - returned, which constitutes the first step of the - volumetric_feature identification process. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - feature_type_dict_keyword(NX_UINT): - exists: optional - doc: | - The array of keywords of feature_type dictionary. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_feature_dict]] - feature_type_dict_value: - exists: optional - doc: | - The array of values for each keyword of the - feature_type dictionary. - dimensions: - rank: 1 - dim: [[1, n_feature_dict]] - feature_type(NX_UINT): - doc: | - The array of controlled keywords, need to be from - feature_type_dict_keyword, which specify which type - each feature triangle cluster belongs to. - Keep in mind that not each feature is an object or proxy. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, j]] - feature_identifier(NX_UINT): - doc: | - The explicit identifier of features. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - # ##MK::a nice example why we need group-overarching symbols - # a symbol for triangles would not work as the analysis can - # hold multiple instances of iso_surface each with a different - # number of triangles and/or features! - # details about specific features - objects(NXprocess): # (NXms_three_d_feature_set): - exists: optional - doc: | - Details for features which are (closed) objects. - Identifier have to exist in feature_identifier - :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. - # ##MK::constraints! - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - obb(NXcg_hexahedron_set): - exists: optional - doc: | - An oriented bounding box (OBB) to each object. - size(NX_FLOAT): - exists: optional - doc: | - Edge length of the oriented bounding box from largest - to smallest value. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - aspect(NX_FLOAT): - exists: optional - doc: | - Oriented bounding box aspect ratio. YX versus ZY. - # ##MK::which is which - unit: NX_DIMENSIONLESS - dimensions: - rank: 2 - dim: [[1, i], [2, 2]] - center(NX_NUMBER): - exists: optional - doc: | - Position of the geometric center, which often is but - not necessarily has to be the center_of_mass of the - hexahedrally-shaped sample/sample part. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - hexahedra(NXcg_face_list_data_structure): - # exists: [min, 0, max, 1] - doc: | - A simple approach to describe the entire set of hexahedra - when the main intention is to store the shape of the - hexahedra for visualization. - # ##MK::more details needed here - vertices(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - # ##MK::again we have no effective way to pinpoint the n_rows - # ##MK::namely k != i each OBB has eight vertices - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - objects_close_to_edge(NXprocess): # (NXms_three_d_feature_set): - exists: optional - doc: | - Details for all those objects close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - composition(NXchemical_composition): - exists: optional - total(NX_NUMBER): - doc: | - Total (count) relevant for normalization. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - ION(NXion): - exists: [min, 0, max, infty] # ##MK::should be n_speci or 0 ! - charge(NX_INT): - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - count(NX_NUMBER): - doc: | - Count or weight which, when divided by total, - yields the composition of this element, isotope, - molecule or ion. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - objectID(NXcg_polyhedron_set): - exists: [min, 0, max, infty] # ##MK::cannot be more than i - polyhedron(NXcg_face_list_data_structure): - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # vertex_identifier_offset(NX_UINT): - # face_identifier_offset(NX_UINT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - # face_normals(NXcg_unit_normal_set): - face_normals(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles - ion_identifier(NX_UINT): - exists: optional - doc: | - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - objects_far_from_edge(NXprocess): # (NXms_three_d_feature_set): - exists: optional - doc: | - Details for all those objects far from edge, i.e. those - whose ions lay all at least threshold distant from a - modelled edge of the dataset. - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - composition(NXchemical_composition): - exists: optional - total(NX_NUMBER): - doc: | - Total (count) relevant for normalization. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - ION(NXion): - exists: [min, 0, max, infty] # ##MK::should be n_speci or 0 ! - charge(NX_INT): - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - count(NX_NUMBER): - doc: | - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - objectID(NXcg_polyhedron_set): - exists: [min, 0, max, infty] # ##MK::cannot be more than i - polyhedron(NXcg_face_list_data_structure): - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # vertex_identifier_offset(NX_UINT): - # face_identifier_offset(NX_UINT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - # face_normals(NXcg_unit_normal_set): - face_normals(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles - ion_identifier(NX_UINT): - exists: optional - doc: | - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - # linear_feature_identification(NXprocess): - # these would be polylines etc - proxies(NXprocess): # (NXms_three_d_feature_set): - exists: optional - doc: | - Details for features which are so-called proxies, i.e. objects - which have been reconstructed and combinatorially closed with - processing their partial triangulated_surface_mesh - (hole filling, refinement). - Identifier have to exist in feature_identifier - :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. - # ##MK::constraints feature_identifier are a subset of the parent! - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - # obb ? - proxies_close_to_edge(NXprocess): # (NXms_three_d_feature_set): - exists: optional - doc: | - Details for those proxies close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - Identifier have to exist in feature_identifier - :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. - # ##MK::constraints! - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - composition(NXchemical_composition): - exists: optional - total(NX_NUMBER): - doc: | - Total (count) relevant for normalization. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - ION(NXion): - exists: [min, 0, max, infty] # ##MK::should be n_speci or 0 ! - # charge(NX_INT): - # isotope_vector(NX_UINT): - count(NX_NUMBER): - doc: | - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - objectID(NXcg_polyhedron_set): - exists: [min, 0, max, infty] - polyhedron(NXcg_face_list_data_structure): - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # vertex_identifier_offset(NX_UINT): - # face_identifier_offset(NX_UINT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - # face_normals(NXcg_unit_normal_set): - face_normals(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles - ion_identifier(NX_UINT): - exists: optional - doc: | - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - proxies_far_from_edge(NXprocess): # (NXms_three_d_feature_set): - exists: optional - doc: | - Details for those proxies far from edge, i.e. those whose - ions lay all at least threshold distant from a - modelled edge of the dataset. - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - composition(NXchemical_composition): - exists: optional - total(NX_NUMBER): - doc: | - Total (count) relevant for normalization. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - ION(NXion): - exists: [min, 0, max, infty] # ##MK::should be n_speci or 0 ! - # charge(NX_INT): - # isotope_vector(NX_UINT): - count(NX_NUMBER): - doc: | - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - objectID(NXcg_polyhedron_set): - exists: [min, 0, max, infty] - polyhedron(NXcg_face_list_data_structure): - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # vertex_identifier_offset(NX_UINT): - # face_identifier_offset(NX_UINT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - # face_normals(NXcg_unit_normal_set): - face_normals(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles - ion_identifier(NX_UINT): - exists: optional - doc: | - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - interface_modelling(NXprocess): - exists: optional - ion_multiplicity(NX_UINT): - exists: optional - doc: | - The multiplicity whereby the ion position is accounted for - irrespective whether the ion is considered as a decorator - of the interface or not. - As an example, with atom probe it is typically not possible - to resolve the positions of the atoms which arrive at the detector - as molecular ions. Therefore, an exemplar molecular ion of two carbon - atoms can be considered to have a multiplicity of two to account that - this molecular ion contributes two carbon atoms at the reconstructed - location considering that the spatial resolution of atom probe - experiments is limited. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - decorator_multiplicity(NX_UINT): - exists: optional - doc: | - The multiplicity whereby the ion position is accounted for when - the ion is considered one which is a decorator of the interface. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - initial_interface(NXprocess): # MK::(NXcg_plane_set): - exists: optional - doc: | - The equation of the plane that is fitted initially. - point_normal_form(NX_FLOAT): - doc: | - The four parameter :math:`ax + by + cz + d = 0` which define the plane. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 4]] - MESH_CURR_PRE_DCOM_STEP(NXcg_triangle_set): - exists: [min, 0, max, infty] - doc: | - The triangle surface mesh representing the interface model. - Exported at some iteration before the next DCOM step. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS - triangles(NXcg_face_list_data_structure): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - edge_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - vertices(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - # ##MK::vertex_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - doc: Direction of each normal - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - vertex_normal(NXcg_unit_normal_set): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - doc: Direction of each normal - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - edge_length(NX_NUMBER): - doc: | - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - interior_angle(NX_NUMBER): - doc: | - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - MESH_CURR_POST_DCOM_STEP(NXcg_triangle_set): - exists: [min, 0, max, infty] - doc: | - The triangle surface mesh representing the interface model. - Exported at some iteration after the next DCOM step. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS - triangles(NXcg_face_list_data_structure): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - vertices(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - # ##MK::vertex_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - doc: Direction of each normal - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - vertex_normal(NXcg_unit_normal_set): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - doc: Direction of each normal - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - - area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - edge_length(NX_NUMBER): - doc: | - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - interior_angle(NX_NUMBER): - doc: | - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - - composition_analysis(NXprocess): - exists: optional - xdmf_cylinder(NXcg_polyhedron_set): - doc: | - The ROIs are defined as cylinders for the computations. - To visualize these though we discretize them into regular n-gons. - Using for instance a 360-gon, i.e. a regular n-gon with 360 - edges resolves the lateral surface of each cylinder very finely - so that they are rendered smoothly in visualization software. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - center(NX_NUMBER): - doc: | - Position of the geometric center, which often is but not - necessarily has to be the center_of_mass of the polyhedra. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - roi_identifier(NX_UINT): - doc: | - Integer which specifies the first index to be used for distinguishing - ROI cylinder. Identifiers are defined explicitly. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - polyhedra(NXcg_face_list_data_structure): - exists: [min, 0, max, 1] - edge_contact(NX_UINT): - exists: optional - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - number_of_atoms(NX_UINT): - exists: optional - doc: | - The number of atoms in each ROI. - # ##MK::decomposed? - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - number_of_ions(NX_UINT): - exists: optional - doc: | - The number of ions in each ROI. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - orientation(NX_FLOAT): - exists: optional - doc: | - The orientation of the ROI defined via a vector which points along - the cylinder axis and whose length is the height of the cylinder. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - ROI(NXcollection): - exists: [min, 0, max, infty] - signed_distance(NX_FLOAT): - doc: In the direction of the ROI. - isotope(NX_UINT): - doc: Hashvalue - # ##MK::#define MYCHM_DATA_ISRF_TSKS_TSCL_OBJ_ROICYL_ROIID "RoiCylinderID" - # ##MK::#define MYCHM_DATA_ISRF_TSKS_TSCL_OBJ_ROICYL_OBJID "RoiCylinderObjectID" -# ##MK::end of the tool-specific section - - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml deleted file mode 100644 index 9af3ce2105..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml +++ /dev/null @@ -1,370 +0,0 @@ -category: application -doc: | - Results of a paraprobe-ranger tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: The total number of ions in the reconstruction. - n_ivec_max: | - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. -NXapm_paraprobe_results_ranger: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_ranger] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - exists: optional - doc: Details about the coordinate system conventions used. - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - -# ##MK::begin of the tool-specific section - (NXprocess): - exists: [min, 0, max, 1] - apply_existent_ranging(NXprocess): - exists: [min, 0, max, 1] - doc: | - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on none, the - ion is considered of the default unknown type with a 0 as its - respective value in the iontypes array. - # ##MK::number_of_ion_types(NX_POSINT): - maximum_number_of_atoms_per_molecular_ion(NX_POSINT): - doc: | - The length of the isotope_vector used to describe molecular ions. - unit: NX_UNITLESS - ION(NXion): - exists: [min, 1, max, 256] - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - exists: recommended - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): - iontypes(NX_UINT): - doc: | - The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the elements of which a (molecular) ion - is build are considered. By contrast, charged_iontypes takes - into account also the charge state. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies exactly all those ions ranged irrespective - the type they ended up with. - number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - molecular_ion_search(NXprocess): - exists: [min, 0, max, 1] - doc: | - Paraprobe-ranger performs a combinatorial search over - all possible or a reduced set of nuclids to identify - into which ions these can be composed. - isotope_vector_matrix(NX_UINT): - doc: | - The main result is the list of molecular ions, here formatted - according to the definitions of a set of isotope_vectors - as detailed in :ref:`NXion`. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, i], [2, 32]] - mass_to_charge_state_ratio(NX_FLOAT): - doc: | - The mass-to-charge-state ratio of each molecular ion - without considering relativistic or quantum effects. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, i]] - mass(NX_FLOAT): - exists: optional - doc: | - The mass of each molecular ion without - considering relativistic or quantum effects. - unit: NX_ANY - # \@units: amu - dimensions: - rank: 1 - dim: [[1, i]] - charge_state(NX_UINT): - doc: | - The charge_state of each molecular ion. - unit: NX_CHARGE - dimensions: - rank: 1 - dim: [[1, i]] - natural_abundance_product(NX_FLOAT): - exists: optional - doc: | - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, i]] - composition_product(NX_FLOAT): - exists: optional - doc: | - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, i]] - number_of_disjoint_nuclids(NX_POSINT): - exists: optional - doc: | - The number of disjoint nuclids for each molecular ion. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - number_of_nuclids(NX_POSINT): - exists: optional - doc: | - The number of nuclids for each molecular ion. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - - check_existent_ranging(NXprocess): - exists: [min, 0, max, 1] - doc: | - Paraprobe-ranger loads iontypes and evaluates for each ion on which - iontype it matches. If it matches on none, the ion is considered of - the default unknown type with a 0 as its respective value in the - iontypes array. In contrast to use_existent_ranging this process - does neither needs measured ion position nor mass-to-charge-state - ratio values. - # ##MK::number_of_ion_types(NX_POSINT): - maximum_number_of_atoms_per_molecular_ion(NX_POSINT): - doc: | - The length of the isotope_vector used to describe molecular ions. - unit: NX_UNITLESS - charged_ION(NXion): - exists: [min, 1, max, 256] - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - exists: recommended - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): -# ##MK::end of the tool-specific section - - performance(NXcs_profiling): - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml deleted file mode 100644 index a124718b91..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml +++ /dev/null @@ -1,233 +0,0 @@ -category: application -doc: | - Results of a paraprobe-selector tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: The total number of ions in the reconstruction. - -NXapm_paraprobe_results_selector: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_selector] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - exists: optional - doc: Details about the coordinate system conventions used. - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - -# ##MK::begin of the tool-specific section - (NXprocess): - exists: [min, 0, max, 1] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset - were selected to become included in the region-of-interest (ROI). - number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - -# ##MK::end of the tool-specific section - - performance(NXcs_profiling): - exists: recommended - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml deleted file mode 100644 index eb8cc2c843..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml +++ /dev/null @@ -1,309 +0,0 @@ -category: application -doc: | - Results of a paraprobe-spatstat tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: The total number of ions in the reconstruction. - -NXapm_paraprobe_results_spatstat: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_spatstat] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - exists: optional - doc: Details about the coordinate system conventions used. - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - -# ##MK::begin of the tool-specific section - (NXprocess): - exists: [min, 0, max, 1] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed. - number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - iontypes_randomized(NX_UINT): - doc: | - The iontype ID for each ion that was assigned to each ion during - the randomization of the ionlabels. Iontype labels are just permuted - but the total number of values for each iontype stay the same. - - The order matches the iontypes array from a given ranging results - as is specified in the configuration settings inside the specific - config_filename that was used for this spatstat analysis. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - - knn(NXprocess): - exists: optional - doc: | - K-nearest neighbor statistics. - distance(NX_FLOAT): - doc: Right boundary of the binning. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, i]] - probability_mass(NX_FLOAT): - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, i]] - cumulated(NX_FLOAT): - doc: Cumulated - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - cumulated_normalized(NX_FLOAT): - doc: Cumulated and normalized by total counts - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, i]] - - rdf(NXprocess): - exists: optional - doc: | - Radial distribution statistics. - distance(NX_FLOAT): - doc: Right boundary of the binning. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, i]] - probability_mass(NX_FLOAT): - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, i]] - cumulated(NX_FLOAT): - doc: Cumulated - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - cumulated_normalized(NX_FLOAT): - doc: Cumulated and normalized by total counts - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, i]] - -# ##MK::end of the tool-specific section - - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml deleted file mode 100644 index 0e6bac09aa..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml +++ /dev/null @@ -1,413 +0,0 @@ -category: application -doc: | - Results of a paraprobe-surfacer tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: The total number of ions in the reconstruction. - n_v_tri: The number of vertices of the alpha complex. - n_f_tri: The number of faces of the alpha complex. - n_f_tri_xdmf: | - The total number of XDMF values to represent all faces of triangles via XDMF. - n_f_tet_xdmf: | - The total number of XDMF values to represent all faces of tetrahedra via XDMF. -NXapm_paraprobe_results_surfacer: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_surfacer] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: Details about the coordinate system conventions used. - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - -# ##MK::begin of the tool-specific section - (NXprocess): - exists: [min, 0, max, 1] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed. Computations of alpha complexes may have filtered this - ion set further but this process is deterministic. - number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. The mask may be 0 for most. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - POINT_SET_WRAPPING(NXprocess): - exists: [min, 0, max, infty] - doc: | - Paraprobe-surfacer can be used to load a ROI that is the entire or a - sub-set of the ion point cloud. In the point_cloud_wrapping process - the tool computes a triangulated surface mesh which encloses the - ROI/point cloud. This mesh can be seen as a model for the edge of - the dataset. - Different algorithms can be used with paraprobe-surfacer to create - this mesh such as convex hulls, alpha-shapes as their generalization, - or alpha wrappings. - Ideally, the resulting mesh should be a watertight polyhedron. - This polyhedron is not necessarily convex. For some algorithms there - is no guarantee that the resulting mesh yields a watertight mesh. - # (NXcg_grid): currently we do not store the underlying grid - # for eventually performed preprocessing - alpha_complex(NXcg_alpha_complex): - exists: [min, 0, max, infty] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies exactly all those ions whose positions - were considered when defining the filtered point set from which - the alpha complex was then in fact computed. This window - can be different to the entire window as irrelevant ions might - have been filtered out to reduce the computational costs of the - alpha complex analysis. - # filtered in addition to the ROI or again the entire dataset - number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - dimensionality(NX_UINT): - unit: NX_UNITLESS - enumeration: [2, 3] - type: - enumeration: [convex_hull, alpha_shape, alpha_wrapping, other, undefined] - mode: - enumeration: [general, regularized] - alpha(NX_NUMBER): - unit: NX_LENGTH - offset(NX_NUMBER): - exists: optional # but is required when type is alpha_wrapping - unit: NX_LENGTH - triangle_set(NXcg_triangle_set): - exists: optional - doc: | - The set of triangles in the coordinate system paraprobe - which discretizes the exterior surface of the alpha complex. - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - unit: NX_UNITLESS - triangles(NXcg_face_list_data_structure): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - doc: Number of vertices. - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - doc: Number of faces. - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v_tri], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f_tri], [2, 3]] - xdmf_topology(NX_UINT): - doc: | - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_f_tri_xdmf]] - is_watertight(NX_BOOLEAN): - exists: optional - doc: | - Do the triangles define a triangulated surface mesh which - is watertight? - volume(NX_FLOAT): - exists: optional - doc: | - The volume which the triangulated surface mesh encloses - provided that the mesh is watertight. - unit: NX_VOLUME - interior_tetrahedra(NXcg_tetrahedron_set): - exists: optional - doc: | - The set of tetrahedra which represent the interior volume of the - complex if that is a closed 2-manifold. - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distin- - guishing tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined - on the interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS - volume(NX_FLOAT): - exists: optional - doc: | - The accumulated volume of all interior tetrahedra. - unit: NX_VOLUME - tetrahedra(NXcg_face_list_data_structure): - exists: optional - number_of_vertices(NX_POSINT): - doc: Number of vertices. - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - doc: Number of faces. - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v_tet], [2, 3]] - xdmf_topology(NX_UINT): - doc: | - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tet * (1+1+4). - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_f_tet_xdmf]] - - TRIANGLE_SET_WRAPPING(NXprocess): - exists: [min, 0, max, infty] - doc: | - In the future we may want to wrap other primitives - like triangles or polylines. -# ##MK::end of the tool-specific section - - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml deleted file mode 100644 index e1cd0f4357..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml +++ /dev/null @@ -1,585 +0,0 @@ -category: application -doc: | - Results of a paraprobe-tessellator tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: The total number of ions in the reconstruction. - n_f_xdmf: The total number of facets/polygons defining the tessellation. - -NXapm_paraprobe_results_tessellator: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_tessellator] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: Details about the coordinate system conventions used. - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - -# ##MK::begin of the tool-specific section - (NXprocess): - exists: [min, 0, max, 1] - voronoi_tessellation(NXprocess): - doc: | - The tool can be used to compute a Voronoi tessellation the entire - or a sub-set of the reconstruction. The point cloud in the ROI is - wrapped into a tight axis-aligned bounding box. The tool detects if - Voronoi cells make contact with the walls of this bounding box. - The tessellation is computed without periodic boundary conditions. - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed. - number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - wall_contact_global(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by the global axis-aligned bounding box, i.e. boundaries - of the threads are ignored. - number_of_ions(NX_UINT): - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - # ##MK::optional documenting of touching on thread-local boundaries - wall_contact_left(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative x axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - wall_contact_right(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The right wall has the positive x axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - wall_contact_front(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The front wall has the negative y axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - wall_contact_rear(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The rear wall has the positive y axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - - wall_contact_bottom(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative z axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - - wall_contact_top(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the positive z axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - # which does paraprobe use - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - - voronoi_cells(NXcg_polyhedron_set): - exists: optional - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - volume(NX_NUMBER): - doc: Interior volume - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - process_identifier(NX_POSINT): - exists: optional - doc: | - By which MPI process was the Voronoi cell computed. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - thread_identifier(NX_POSINT): - exists: optional - doc: | - By which OpenMP thread was the Voronoi cell computed. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - number_of_faces(NX_POSINT): - exists: optional - doc: | - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - # (NXtransformations): - # exists: optional - # doc: | - # Reference to or definition of a coordinate system with - # which the qualifiers and mesh data are interpretable. - # substantially more detailed descriptors of the shape, the mesh - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS - identifier(NX_INT): - exists: optional - doc: Integer used to distinguish polyhedra for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - polyhedra(NXcg_face_list_data_structure): - exists: [min, 0, max, 1] - doc: | - A simple approach to describe the entire set of polyhedra when - the main intention is to store the shape of the polyhedra for - visualization. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - doc: Number of vertices. - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - doc: Number of faces. - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - xdmf_topology(NX_UINT): - doc: | - A sequence of always first an XDMF topology type key, followed - by the XDMF number of vertices of the polygon, followed by - the vertex identifier which define the facet polygon. First - we store the polygon of the first facet of the first cell, then - the second facet of the first cell, until the last facet of the - first cell, followed by the first facet of the second cell, - and so on and so forth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - xdmf_cell_identifier(NX_UINT): - doc: | - A sequence of cell identifier so that each facet is associated - with its cell because of which it is then possible to segment - out cells three-dimensionally based on cell i.e. evaporation_id. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_f_xdmf]] -# ##MK::end of the tool-specific section - - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml deleted file mode 100644 index b06708b8d9..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml +++ /dev/null @@ -1,490 +0,0 @@ -category: application -doc: | - Results of a paraprobe-transcoder tool run. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: The total number of ions in the reconstruction. - n_ivec_max: | - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - n_ranges: Number of mass-to-charge-state-ratio intervals mapped on this ion type. - n_topology: Total number of integers in the supplementary XDMF topology array. - n_combinatorics: Number of ions probed in the combinatorial analysis of the charge states -# be careful n_comb can vary for every instance of (NXion) ! -NXapm_paraprobe_results_transcoder: - (NXentry): - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - exists: [min, 1, max, 1] - \@version: - doc: Version specifier of this application definition. - -# ##MK::begin of the tool-specific section - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_transcoder] -# ##MK::end of the tool-specific section - - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: Details about the coordinate system conventions used. - (NXtransformations): - exists: [min, 1, max, infty] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon -# ##MK::begin of the tool-specific section - visualization(NXprocess): - exists: recommended - xdmf_topology(NX_UINT): - doc: | - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_topology]] - # n_topology == 3*n_ions - # not in all cases a PARAPROBE.Transcoder.Results.SimID..h5 is required - # namely when an NXapm-compliant NeXus file is directly used for interacting - # with paraprobe tools in all other cases, the PARAPROBE.Transcoder.Results - # file will get an *.nxs file ending - # the original proposal - # results(NXprocess): - # exists: [min, 1, max, 1] - # doc: | - # Paraprobe-transcoder prepares the data in POS, ePOS, APT files from - # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can - # be used with the tools of the paraprobe-toolbox. - # reconstruction(NXcg_point_set): - # dimensionality(NX_POSINT): - # cardinality(NX_POSINT): - # identifier_offset(NX_INT): - # position(NX_NUMBER): - # # ##MK::number_of_ion_types(NX_POSINT): - # # ##MK::maximum_number_of_atoms_per_molecular_ion(NX_POSINT): - # ranging(NXcollection): - # exists: [min, 1, max, 256] - # doc: | - # This is the collection of iontypes distinguished. - # The default unknown iontype always has to map to 0. - # Its non-physical mass_to_charge_state_ratio is [0., 0.001] Da. - # ion_type(NX_UINT): - # exists: optional - # isotope_vector(NX_UINT): - # nuclid_list(NX_UINT): - # exists: recommended - # charge_state(NX_INT): - # name: - # exists: optional - # mass_to_charge_range(NX_FLOAT): - # the key problem still for apm is people use different formats - # when people would like to use paraprobe without nomad and pos, epos, apt - # rrng and rng files the data have to be transcoded, this is the main - # reason for having the transcoder however, when you already have an NXapm - # file (like) in nomad, why should we create yet another format here the - # transcoder is not needed - # namely take e.g. paraprobe-nanochem all it needs to know is the place of - # an HDF5 file where the nanochem tool knows there will be groups in this file - # with entry/atom_probe/reconstruction/reconstructed_positions - # and entry/atom_probe/ranging/peak_identification and a set of NXion - # this suggest the need for three fundamental changes: - # if transcoder config gets an nxs file as input it just checks if - # the above-mentioned groups are available, if yes it accepts and - # guides that no transcoding is needed any longer - # if transcoder config gets other files it creates the above-mentioned - # groups in different places than it does currently - # convenience functions of tools have to be changed in the following way: - # you hunt for PARAPROBE.Transcoder.Config.SimID..h5 - # if the references to dataset files there end with nxs you know - # data are in an NXapm so reconstruction will be in - # entry/atom_probe/reconstruction/reconstructed_positions - # ranging will be in - # entry/atom_probe/ranging/peak_identification - # however if the references to dataset files there end with != nxs - # you point the tool to in fact data inside PARAPROBE.Transcoder.Results - # because in this case transcoding was necessary but also then you - # will find the data in entry/atom_probe/.. respectively - # alternatively: - atom_probe(NXinstrument): - doc: | - On a mid term perspective we would like to evolve the paraprobe-toolbox - to an implementation stage where it works exclusively with completely - provenance-tracked formats for both the configuration of the workflow step - and/or analysis with each tool and also for the output of these analyses - in the form of so-called tool-specific results files. - Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. - - Different file formats can be used to inject reconstructed datasets and - ranging definitions into the toolbox. Traditionally, these are the POS, - ePOS, and APT files with the tomographic reconstruction and other metadata - and RNG and RRNG file formats for the ranging definitions how mass-to-charge - state-ratio values map on (molecular) ion types. Such input should be - injected via specific NeXus/HDF5 files which are documented - in compliance with the NXapm application definition. - - So far the paraprobe-toolbox was used as a standalone tool. Therefore, it - was not relevant during the development to focus on interoperability. - Essentially paraprobe-transcoder was used as a parser to transcode data - in the above-mentioned file formats into a paraprobe-specific - representation. This transcoding should become deprecated. - Here we describe steps we have taken into this direction. - - With the work in the FAIRmat project and the desire to make the paraprobe- - toolbox also accessible as a cloud-computing capable service in the Nomad - Remote Tools Hub (NORTH) the topic of interoperability became more important - and eventually the NXapm application definition was proposed. - NORTH is a GUI and related service in a NOMAD OASIS instance which allows - to spawn preconfigured docker containers via JupyterHub. - Currently, NORTH includes the so-called apm container. A container with - tools specific for analyzing data from atom probe microscopy as well as - processing of point cloud and mesh data. - - The NXapm application definition and related implementation work within - NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and - RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook - solutions directly into NOMAD OASIS via the uploads section. - The process is automated and yields an NXapm-compliant NeXus/HDF5 file - inside the uploads section in return. - - With these improvements made there is no longer a need for - at least the - users of a NOMAD OASIS and NORTH instance to use the deprecated - PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should - automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 - file and in response work with this file directly. - To remain compliant with users however who do not have or do not wish - to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is - as follows: - - Calling the configuration stage of paraprobe-transcoder is always mandatory. - It is always the first step of working with the toolbox. In this process - the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ - HDF5 file from e.g. the upload section, or such a file that was obtained from - a colleague with a NOMAD OASIS instance. - In all other cases, users can pass the reconstruction and ranging definitions - using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. - - Based on which input the user delivers, the parmsetup-transcoder tool then - creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and - informs the user whether the input was NeXus (and thus if all relevant - input is already available) or whether the paraprobe-transcoder tool needs - to be executed to convert the content of the vendor files first into a - format which paraprobe can provenance track and understand. - In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is - used to communicate to all subsequently used tools from which files - the tools can expect to find the reconstruction and ranging definitions. - - All subsequent analysis steps start also with a tool-specific configuration. - This configuration step reads in (among others) the - PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration - tool identifies automatically whether to read the reconstruction and ranging data - from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant - NeXus/HDF5 file that was created upon preparing the upload or the file shared - from a colleague. This design removes the need for unnecessary copies of the data. - Currently still though users should execute the transcoder step as it will - generate a supplementary XDMF topology field with which the data in either - the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. - Paraview. For this purpose XDMF is used. - - Of course ideally the APT community would at some point converge to use - a common data exchange file format. To this end, AMETEK/Cameca's APT file format - could be a good starting point but so far it is lacking a consistent way of - how to store generalized ranging definitions and post-processing results. - POS, ePOS, Rouen's ATO, as well as other so far used representations of data - like CSV or text files have, to the best of our current knowledge, no - concept of how to marry reconstruction and (optional) ranging data into - one self-descriptive format. - - This summarizes the rationale behind the current choices of the I/O for - paraprobe. Furthermore, this summarizes also why the fundamental design - of splitting an analysis always into steps of configuration (with parmsetup), - task execution (with the respective C/C++ or Python tool of the toolbox), - and post-processing (e.g. with autoreporter) is useful because it offers - a clear description of provenance tracking. This is a necessary step to make - atom probe microscopy data at all better aligned with the aims of the - FAIR principles. - - The internal organization of the data entries in the atom_probe group - in this application definition for paraprobe-transcoder results files - mirror the definitions of the NXapm for consistency reasons. - # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can - # be used with the tools of the paraprobe-toolbox. - mass_to_charge_conversion(NXprocess): - mass_to_charge(NX_FLOAT): - doc: | - Mass-to-charge-state ratio values. - unit: NX_ANY - # \@units: Da - dimensions: - rank: 1 - dim: [[1, n_ions]] - reconstruction(NXprocess): - # number_of_ions(NX_UINT): - # doc: | - # For now still a support field to store the total number of ions in the - # dataset. This field will become deprecated when the new HDF5 I/O routines - # come in place which detect the metadata to an entry automatically. - # For now has to be the same value as n_ions. - reconstructed_positions(NX_FLOAT): - doc: | - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_ions], [2, 3]] - ranging(NXprocess): - peak_identification(NXprocess): - doc: | - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - (NXion): - exists: [min, 1, max, 256] - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - exists: recommended - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): - charge_model(NXprocess): - doc: | - Details and results of the combinatorial analyses of this - range definition to identify the charge_state for an ion. - charge_vector(NX_UINT): - doc: | - Currently charge_state not charge! - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_combinatorics]] - isotope_matrix(NX_UINT): - doc: | - Specific isotopes building each candidate matching the range. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_combinatorics], [2, n_ivec_max]] - mass_vector(NX_FLOAT): - doc: | - Accumulated mass of the isotopes in each candidate. - Not corrected for quantum effects. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_combinatorics]] - # min_abundance(NX_FLOAT): - # doc: | - # Minimum natural abundance - # unit: NX_DIMENSIONLESS - natural_abundance_product_vector(NX_FLOAT): - doc: | - Product of natural abundance of the isotopes per candidate. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_combinatorics]] - min_abundance_product(NX_FLOAT): - doc: | - Filter criterion on the product of the natural abundances - computed from each isotope building the (molecular) ion. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - unit: NX_DIMENSIONLESS - min_half_life(NX_FLOAT): - doc: | - Filter criterion on the minimum half life which all isotopes - building the (molecular) ion need to have to consider the - candidate. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - unit: NX_TIME - # NEW ISSUE: value can be the string infinity! - # min_half_life_vector(NX_FLOAT): - # doc: | - # Needs to be documented - # unit: NX_TIME - sacrifice_isotopic_uniqueness(NX_BOOLEAN): - doc: | - If the value is zero/false it means that non-unique solutions - are accepted. These are solutions where multiple candidates - differ in their isotopes but have the same charge. - - # add further fields coming from using the charge state recovery - # workflow from the ifes_apt_tc_data_modeling library -# ##MK::end of the tool-specific section - - performance(NXcs_profiling): - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml deleted file mode 100644 index 81e27f6305..0000000000 --- a/contributed_definitions/nyaml/NXbeam_path.yaml +++ /dev/null @@ -1,315 +0,0 @@ -# 05/2023 -# A draft of a new base class to describe a beam path consisting of one or -# more optical elements (e.g. a beam path in a luminescence setup). - -# To do: -# [ ] Harmonize common fields/classes among base classes used in NXbeam_path, -# e.g. NXshape in NXbeam_splitter and NXpolarizer_opt, or NXsample used for -# describing substrates and coatings etc. -# [ ] How to describe a setup or beam path? Order/sequence defined by -# NXtransformations? => discussion needed - -category: base -doc: | - A beam path consisting of one or more optical elements. - - NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement - of optical elements between the excitation source and the sample, or between - the sample and the detector unit. - - To describe the order of the elements, use 'order(NXtransformations)', where - each element's position points to the preceding element via '@depends_on'. - Special case beam splitter: A beam splitter is a device which separates the - beam into two or more beams. If such a device is part of the beam path use - two or more NXbeam_paths to describe the beam paths after the beam splitter. - In this case, in the dependency chain of the new beam paths, the first - elements each point to the beam splitter, as this is the previous element. - - Describe the relevant optical elements in the beam path by using the - appropriate base classes. You may use as many elements as needed, also - several elements of the same type as long as each element has its own name. - -NXbeam_path: - depends_on: - doc: | - Entry point of the dependency chain defined by the NXtransformations - field, i.e. a link to the last element in the beam path. - Example: /entry/instrument/beam_path/detector. - - (NXtransformations): - # Possibilities: - # (1) Modify NXtransformations to include properties that modify the light beam - # (e.g. polarization state) instead (or in addition) to transformations like - # translation and rotation - # (2) Base class similar to NXtransformations but for changes of optical - # properties (e.g. polarization state). - doc: | - Specify the order of the optical elements by defining a dependency chain. - For each element, a '@depends_on' attribute should be used to state the - position of the element in the beam path by pointing to the previous - element. For the very first element, use the string "." instead. - AXISNAME(NX_NUMBER): - doc: | - For each element in the beam path, one such field must exist with a - '@depends_on' attribute defined to specify its position in the beam - path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows - ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and - 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the - dependency chain, i.e. may have an entry in this class even if they are - not described in the beam path. - ELEMENT is a place holder for the name of an optical beam path element. - Note that the name of this field must be exactly the same as the - element's field name. - unit: NX_TRANSFORMATION - \@depends_on: - doc: Add a link to the previous beam path element. - - (NXsource): - doc: | - Excitation source. One or more may be needed (e.g. two for a pump-probe - setup with one pump and one probe beam). - Depending on the source type, different properties are relevant, which - are provided through the respective base class (e.g. use NXopt_source for - lamps or lasers, NXchem_source for chemical reaction etc.). - Some base classes are incomplete (NXchem_source, NXbio_source); the - expertise of the respective communities is needed. - depends_on: - doc: Use this field to point to the previous optical element. - type: - doc: Type of excitation source. - enumeration: - # Spallation Neutron Source - # Pulsed Reactor Neutron Source - # Reactor Neutron Source - # Synchrotron X-ray Source - # Pulsed Muon Source - # Rotating Anode X-ray - # Fixed Tube X-ray - # UV Laser - # Free-Electron Laser - # Optical Laser - # Ion Source - # UV Plasma Source - # Metal Jet X-ray - [ - semiconductor laser, # NXopt_source - gas laser, # NXopt_source - other laser, # NXopt_source - lamp, # NXopt_source - X-rays, # NXsource ??? - silicon carbide globar, # NXopt_source - super continuum, # NXopt_source - chemical reaction, # NXchem_source - ultrasound, # NXacoustic_source - sound, # NXacoustic_source - living organism, # NXbio_source - power supply, # NXpower_supply - electron source, # from NXem ??? - other - ] - # separate base classes for different sources: - # (NXacoustic_source): # needs to be developed - # doc: | - # Acoustic source, e.g. an ultrasonic transducero or a imploding gas - # bubble (sonoluminescence). - # (NXpower_supply): # needs to be developed - # (NXchem_source): # input for experts from that field needed - # (NXbio_source): # input for experts from that field needed - # # is NXsource sufficient for x-rays? - # (NXopt_source): - # doc: Specify the properties of the optical source. - lifespan(NX_NUMBER): - doc: Lifespan of the excitation (typically provided in hours). - unit: NX_TIME - measure_time(NX_NUMBER): - doc: How many hours has the lamp been used? - unit: NX_TIME - excitation_wavelength(NX_FLOAT): - doc: | - Wavelengths or energy vector of the excitation source. This can be a - single value or a spectrum, depending on the type of experiment. - unit: NX_ANY - \@units: - doc: Unit of wavelength or energy. - beam_profile: - # ??? What's the best way to enter this ??? - doc: Two- or three-dimensional beam profile. - dimensions: - rank: 2 - dim: - [ - [1, N_beam_profile_dim], - [2, N_beam_profile_points] - ] - peak_power(NX_FLOAT): - doc: Power of one light pulse if the source is a pulsed source. - unit: NX_POWER - cw(NX_BOOLEAN): - doc: Is the excitation source continuous wave (CW)? - cw_power(NX_FLOAT): - doc: Power of CW beam. - bandwidth(NX_FLOAT): - doc: FWHM bandwidth of the excitation source. - unit: NX_WAVELENGTH - coherence_length(NX_FLOAT): - doc: Coherence length. - unit: NX_LENGTH - divergence(NX_FLOAT): - doc: Divergence of the excitation beam. - unit: NX_ANGLE - (NXpinhole): - doc: | - Use this field to describe a simple pinhole (round geometry). Define its - dimension using 'diameter'. For more complex geometries, 'NXaperture' - should be used. - (NXslit): - doc: | - Use this field to describe a simple slit (rectangular geometry). Define - its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, - 'NXaperture' should be used. - aperture_NUMBER(NXaperture): - doc: | - Use this field to describe an aperture. To specify a window, use the - field 'window_NUMBER(NXaperture)'. - window_NUMBER(NXaperture): - doc: | - A window, e.g. an entry or exit window of a cryostat. - depends_on: - doc: Use this field to point to the previous optical element. - material(NX_CHAR): - doc: The material of the window. - enumeration: - [ - quartz, - diamond, - calcium fluoride, - zinc selenide, - thallium bromoiodide, - alkali halide compound, - Mylar, - other, - ] - other_material(NX_CHAR): - doc: | - If you specified 'other' as material, decsribe here what it is. - thickness(NX_FLOAT): - doc: Thickness of the window - unit: NX_LENGTH - orientation_angle(NX_FLOAT): - doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - unit: NX_ANGLE - reference_data_link: - doc: | - If reference data were measured add a link to the NeXus file where they - are described. - (NXmirror): - filter_NUMBER(NXfilter): - (NXattenuator): - doc: A device that reduces the intensity of a beam by attenuation. - attenuator_transmission(NX_FLOAT): - doc: The transmitted intensity divided by the incident intensity. - unit: NX_DIMENSIONLESS - attenuation(NX_FLOAT): - doc: Attenuation of the attenuator in dB. - unit: NX_ANY - \@units: - doc: | - Unit of the measured data is not covered by NXDL units state - here which unit was used. - (NXaperture): - doc: Input and output aperture of the attenuator. - (NXgeometry): - doc: Geometry (shape, size etc.) of the attenuator. - (NXgrating): - doc: | - A diffraction grating. Define relevant parameters in the corresponding - fields, e.g. order of diffration (diffraction_order) or angular - dispersion (angular_dispersion). - type: - doc: Define the type of the grating. - angular_dispersion(NX_FLOAT): - doc: Dispersion of the grating in nm/mm (or e.g. nm/mrad). - unit: NX_UNITLESS - grooves(NX_FLOAT): - doc: Number of grooves per mm. - unit: NX_PER_LENGTH - blaze_wavelength(NX_FLOAT): - doc: Blaze wavelength of the grating. - unit: NX_WAVELENGTH - efficiency(NX_FLOAT): - doc: Efficiency curve versus wavelength or energy. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: - [[1, N_spectrum]] - spectrum(NX_FLOAT): - doc: | - Spectral values, e.g. wavelength or energy. Vector of length - N_spectrum. - unit: NX_ANY - \@units: - doc: Unit of wavelength array (e.g. nanometer or Angstrom) - (NXdisk_chopper): - doc: | - A device blocking the beam in a temporal periodic pattern, e.g. a optical - chopper wheel. Specify the frequency range using 'min_frequency' and - 'max_frequency'. - min_frequency(NX_FLOAT): - doc: Minimum frequency in Hertz. - unit: NX_FREQUENCY - max_frequency(NX_FLOAT): - doc: Maximum frequency in Hertz. - unit: NX_FREQUENCY - frequency_resolution(NX_FLOAT): - doc: Frequency resolution in Hertz. - unit: NX_FREQUENCY - (NXmonochromator): - doc: | - A monochromator or spectrometer. - spectrum(NX_FLOAT): - doc: | - Spectral values of the monochromator, e.g. wavelength or energy values - used for the measurement. - unit: NX_ANY - \@units: - doc: Unit of wavelength array (e.g. nanometer or Angstrom) - (NXgrating): - doc: | - Diffraction grating. If two or more gratings were used, define the - angular dispersion and the wavelength range (min/max wavelength) for - each grating and make sure that the wavelength ranges do not overlap. - The dispersion should be defined for the entire wavelength range of the - experiment. - angular_dispersion(NX_FLOAT): - doc: Dispersion of the grating in nm/mm. - unit: NX_DIMENSIONLESS - grating_wavelength_min(NX_FLOAT): - doc: Minimum wavelength of the grating. - unit: NX_WAVELENGTH - grating_wavelength_max(NX_FLOAT): - doc: Maximum wavelength of the grating. - unit: NX_WAVELENGTH - spectral_resolution(NX_FLOAT): - doc: Spectral resolution of the instrument. - unit: NX_WAVENUMBER - (NXslit): - doc: Define the width of the monochromator slit in the subfield x_gap. - fixed_slit(NX_BOOLEAN): - doc: Was the slit width fixed? - max_gap(NX_FLOAT): - doc: If slit width was not fixed, define the maximum slit width. - unit: NX_LENGTH - - # x-ray optics: - (NXxraylens): - # what else? - - # ====== New base classes: ====== - (NXpolarizer_opt): - (NXbeam_splitter): - (NXwaveplate): - (NXlens_opt): - (NXfiber): diff --git a/contributed_definitions/nyaml/NXbeam_splitter.yaml b/contributed_definitions/nyaml/NXbeam_splitter.yaml deleted file mode 100644 index 0699f53184..0000000000 --- a/contributed_definitions/nyaml/NXbeam_splitter.yaml +++ /dev/null @@ -1,311 +0,0 @@ -# A draft of a new base class to describe a beam splitting device. - -category: base -symbols: - N_spectrum: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the beam splitter material and/or coating is defined. - N_spectrum_RT: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - reflectance or transmission of the beam splitter is given. - N_shapepar: | - Number of parameters needed do descripe the shape of the beam splitter. - N_objects: | - Number of objects the beam splitter is made up of. - N_outputs: | - Number of outputs, i.e. number of paths the beam takes after being split by - the beam splitter. - -doc: | - A beam splitter, i.e. a device splitting the light into two or more beams. - - Information about types and properties of beam splitters is provided e.g. - [here](https://www.rp-photonics.com/beam_splitters.html). - - Use two or more NXbeam_paths to describe the beam paths after the beam - splitter. In the dependency chain of the new beam paths, the first elements - each point to this beam splitter, as this is the previous element. - -NXbeam_splitter: - type: - doc: | - Specify the beam splitter type (e.g. dielectric mirror, pellicle, - dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension - should be described in 'geometry'. Define if the beam splitter is - polarizing or not in the field 'polarizing(NX_BOOLEAN)'. - enumeration: - [ - "dichroic mirror", - "dielectric mirror", - "metal-coated mirror", - "Nicol prism", - "Glan-Thompson prism", - "pellicle mirror", - "Polka dot beam splitter", - "fiber optic splitter", - "other" - ] - # ??? Are there any other common types of beam splitters ??? - other_type: - doc: | - If you selected 'other' in 'type' use this field to specify which type of - beam splitter was used. - - polarizing(NX_BOOLEAN): - doc: Is the beam splitter polarizing? - - multiple_outputs(NX_BOOLEAN): - # ??? Redundant because number of outputs is defined by N_outputs ??? - doc: | - Does the beam splitter have multiple outputs (diffractive optical - element), i.e. more than two outputs? - - (NXshape): - exists: recommended - doc: | - Describe the geometry (shape, dimension etc.) of the beam splitter. - Specify the dimensions in 'SHAPE/size'. A sketch of the device should be - provided in the 'sketch(NXdata)' field to clarify (i) the shape and - dimensions of the device, and (ii) the input and outputs (i.e. the - direction of the incoming and outcoming (split) beams). - # Specify the length and height if the surface facing the incident - # beam is a square or rectangle. Otherwise, if the device has a round - # geometry (disc), sepcify the diameter instead. - # The thickness or depth of the device should be defined in 'depth', - # while the thickness of the substrate and coating should be specified - # in 'substrate/substrate_thickness' and 'coating/coating_thickness'. - shape: - doc: Describe the shape (plate, cube, wedged, prism etc.). - enumeration: - [ - cube, - cylinder, - plate, - prism, - wedged, - other - ] - other_shape: - doc: If you chose 'other' in 'shape' describe what it is. - sketch(NXdata): - doc: | - Sketch of the beam splitter showing its geometry. The paths of the - incoming and split beam should be illustrated and labelled (0 for the - incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split - beam paths)). - size: - doc: | - Physical extent of the beam splitter device. The beam splitter might be - made up of one or more objects (NX_objects). The meaning and location - of the axes used will vary according to the value of the 'shape' - variable. 'N_shapepar' defines how many parameters: - - * For 'cube' the parameters are (width, length). - * For 'cylinder' the parameters are (diameter, length). - * For 'plate' the parameters are (width, height, length). - * For 'prism' the parameters are (width, height, length). - * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. - * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. - dimensions: - rank: 2 - dim: - [ - [1, N_objects], - [2, N_shapepar] - ] - wedge_angle(NX_FLOAT): - doc: Wedge angle if 'shape' is 'wedged'. - unit: NX_ANGLE - # width, height, diameter, depth: Should we use 'size' in NXshape instead? - # width(NX_FLOAT): - # doc: | - # Width of the device's surface facing the incident beam if the surface - # is square or rectangular (e.g. is shape is a cube). - # unit: NX_LENGTH - # height(NX_FLOAT): - # doc: | - # Height of the device's surface facing the incident beam if the surface - # is square or rectangular (e.g. is shape is a cube). - # unit: NX_LENGTH - # diameter(NX_FLOAT): - # doc: | - # Diameter of the device's surface facing the incident beam if the - # surface has circular geometry (e.g. is shape is a cylinder). - # unit: NX_LENGTH - # length(NX_FLOAT): - # doc: | - # Specify the length of the beam splitter. If the device has a wedged - # shape provide the minimum and maximum length of the device. - # Otherwise, if the beam splitter has a homogeneous thickness, the two - # values are equal. - # dimensions: - # rank: 1 - # dim: [[1,2]] - - splitting_ratio(NX_NUMBER): - doc: | - Beam splitting ratio(s) for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, N_outputs]] - - clear_aperture(NX_FLOAT): - doc: | - Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of - length and height for square geometry). - unit: NX_UNITLESS - # ??? Would it be better to provide the clear aperture as length ??? - - substrate(NXsample): - doc: | - Substrate of the beam splitter. Describe the material of the substrate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. - substrate_material: - doc: | - Specify the material of the beam splitter. If the device has a coating - it should be described in coating/coating_material. Is the material - birefringent? - substrate_thickness(NX_FLOAT): - doc: | - Thickness of the beam splitter substrate. Define the minimum and - maximum thickness (for a wedged geomtry). For a homogeneous thickness - (e.g. as in plate beam splitters) the minimum and maximum values are - equal. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1,2]] - index_of_refration_substrate(NX_FLOAT): - doc: | - Complex index of refraction of the beam splitter substrate. Specify at - given spectral values (e.g. wavelength, energy, wavenumber etc.). - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum] - ] - - coating(NXsample): - doc: | - Is the beam splitter coated? If yes, specify the type and material of the - coating and the spectral range for which it is designed. If known, you - may also provide its index of refraction. For a beam splitter cube - consisting of two prisms which are glued together, you may want to - specify the the glue and the coatings of each prism. - coating_type: - doc: | - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - coating_material: - doc: Specify the coating material. - coating_thickness(NX_FLOAT): - doc: Thickness of the coating. - unit: NX_LENGTH - wavelength_range_coating(NX_FLOAT): - exists: recommended - doc: | - Wavelength range for which the coating is designed. Enter the minimum - and maximum values of the wavelength range. - unit: NX_WAVELENGTH - dimensions: - rank: 1 - dim: [[1,2]] - index_of_refraction_coating(NX_FLOAT): - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (e.g. wavelength, energy, wavenumber etc.). - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum] - ] - - wavelength_range(NX_FLOAT): - exists: recommended - doc: | - Wavelength range for which the beam splitter is designed. Enter the - minimum and maximum values of the wavelength range. Alternatively, or - additionally, you may define the wavelength range for the coating in - coating/wavelength_range_coating. - unit: NX_WAVELENGTH - dimensions: - rank: 1 - dim: [[1, 2]] - - optical_loss(NX_NUMBER): - doc: | - Optical loss of the beam splitter for the various outputs (i.e. the paths - of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, N_outputs]] - - incident_angle(NX_NUMBER): - doc: Optimized angle of incidence for the desired splitting ratio. - unit: NX_ANGLE - - deflection_angle(NX_NUMBER): - # is this really needed? - doc: | - Angle of deflection corresponding to the optimized angle of incidence - defined in incident_angle. - unit: NX_ANGLE - - AOI_range(NX_NUMBER): - doc: | - Range of the angles of incidence (AOI) for which the beam splitter can be - operated. Specify the minimum and maximum angles of the range. - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, 2]] - # Aren't some beamsplitters defined for specific angles? Should we instead - # use dim: [[1,N_angles]], N_angles being the number of angles for which the - # beam splitter can be operated? - # If this is the case for some devices, we might also have to define a field - # for the corresponding defelction angles... - - reflectance(NX_FLOAT): - doc: | - Reflectance of the beam splitter at given spectral values. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: - [ - [1, N_spectrum_RT] - ] - - transmission(NX_FLOAT): - doc: | - Transmission at given spectral values for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, N_outputs], - [2, N_spectrum_RT] - ] - diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml deleted file mode 100644 index b0a4e31eb6..0000000000 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ /dev/null @@ -1,51 +0,0 @@ -category: base -symbols: - doc: "The symbols used in the schema to specify e.g. dimensions of arrays" - ncoeff: "Number of coefficients of the calibration function" - nfeat: "Number of features used to fit the calibration function" - ncal: "Number of points of the calibrated and uncalibrated axes" -doc: "Subclass of NXprocess to describe post-processing calibrations." -NXcalibration: - last_process(NX_CHAR): - doc: "Indicates the name of the last operation applied in the NXprocess sequence." - applied(NX_BOOLEAN): - doc: "Has the calibration been applied?" - coefficients(NX_FLOAT): - doc: - "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." - unit: NX_ANY - dimensions: - dim: [[1, ncoeff]] - rank: 1 - fit_function(NX_CHAR): - doc: | - 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. - scaling(NX_FLOAT): - doc: "For linear calibration. Scaling parameter." - unit: NX_ANY - offset(NX_FLOAT): - doc: "For linear calibration. Offset parameter." - unit: NX_ANY - calibrated_axis(NX_FLOAT): - doc: "A vector representing the axis after calibration, matching the data length" - unit: NX_ANY - dimensions: - dim: [[1, ncal]] - rank: 1 - original_axis(NX_FLOAT): - doc: "Vector containing the data coordinates in the original uncalibrated axis" - unit: NX_ANY - dimensions: - dim: [[1, ncal]] - rank: 1 - description(NX_CHAR): - doc: "A description of the procedures employed." diff --git a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml deleted file mode 100644 index fc033c7574..0000000000 --- a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml +++ /dev/null @@ -1,83 +0,0 @@ -category: base -doc: | - Computational geometry description of alpha shapes or wrappings to primitives. - - For details see: - - * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, - * https://dx.doi.org/10.1145/174462.156635 for 3D, - * https://dl.acm.org/doi/10.5555/871114 for weighted, and - * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap - - in CGAL, the Computational Geometry Algorithms Library. - As a starting point, we follow the conventions of the CGAL library. -# weighted alpha shapes -# The so-called spectrum or sets of (weighted) alpha shapes includes the -# convex hull of a point set. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality of the alpha shape, for now 2 or 3. - # generalize to d > 3 - n_e: The number of edges. - n_f: The number of faces. - n_c: The number of cells. -NXcg_alpha_complex: - dimensionality(NX_UINT): - unit: NX_UNITLESS - enumeration: [2, 3] - type: - doc: | - Specify which general type of alpha shape is computed. - Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. - Alpha_wrapping means meshes created using alpha wrapping procedures. - enumeration: [convex_hull, alpha_shape, alpha_wrapping] # , weighted] - mode: - doc: | - Specifically when computed with the CGAL, the mode specifies if singular - faces are removed (regularized) of the alpha complex. - # CHECK THIS AGAIN CAREFULLY - enumeration: [general, regularized] - alpha(NX_NUMBER): - doc: | - The alpha, (radius of the alpha-sphere) parameter to be used for alpha - shapes and alpha wrappings. - unit: NX_LENGTH - offset(NX_NUMBER): - doc: | - The offset distance parameter to be used in addition to alpha - in the case of alpha_wrapping. - unit: NX_LENGTH - # check again carefully the CGAL documentation talks about, for 3D, the square of the radius! - point_set(NXcg_point_set): - doc: Point cloud for which the alpha shape or wrapping should be computed. - # this could also just be implemented as a link but how would this be possible - # unfold the NXcg_point_set and add a - # weight(NX_NUMBER): - # doc: Weights for each point - # In general, an alpha complex is a disconnected and non-pure complex, - # meaning in particular that the alpha complex may have singular faces. - # so the number of cells, faces and edges depends on how a specific alpha complex, - # i.e. an alpha-shape of S for alpha, is filtrated with respect to k < d-dimensional - # simplices. Here we assume that number_of_cells, number_of_faces, number_of_edges - # are reported assuming one filtrates these simplices according to mode. - # also using the assumption the base class reports the unique vertices - # of the specifically filtrated alpha complex. - triangle_set(NXcg_triangle_set): - doc: Triangle soup for which the alpha wrapping should be computed. - triangulation(NXcg_triangle_set): - doc: A meshed representation of the resulting shape. - # should be a mesh - # add for each triangle if desirable a notation of whether the simplex is - # exterior, regular, singular, or interior with respect to the alpha complex - # but a triangulation is more than a triangle (soup)/set because there is - # connectivity information - # customize the NXcg_triangle_set base class members such that connectivity - # information is contained - # we need to find also a better name for this, what people intutive understand - # as the interior, may not even exist for a given alpha value - # more specifically it is the set of filtrated cells acknowledging mode - # e.g. the interior cells of the regularized alpha complex - interior_cells(NXcg_tetrahedron_set): - # document the alpha status - # https://doc.cgal.org/latest/Alpha_shapes_3/classCGAL_1_1Alpha__status.html diff --git a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml deleted file mode 100644 index f96547014e..0000000000 --- a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml +++ /dev/null @@ -1,112 +0,0 @@ -# redundant as there is NXcsg, NXquadric, NXsolid_geometry with which -# cylinder could be constructed, but NXcylinder is easier to understand -category: base -doc: | - Computational geometry description of a set of cylinders in Euclidean space. - - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - c: The cardinality of the set, i.e. the number of cylinders or cones. -NXcg_cylinder_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish members for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - doc: | - The geometric center of each member. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - height(NX_NUMBER): - doc: | - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - # alternatively one could store the center of the lower and upper cap but - # these are then no longer necessarily on the same axis - # maybe a future feature for representing skewed cylinder, but then - # one should really better use NXquadric... - radii(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - upper_cap_radius(NX_NUMBER): - doc: | - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - lower_cap_radius(NX_NUMBER): - doc: | - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - # properties of the cylinder - volume(NX_NUMBER): - doc: Interior volume of each cylinder - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, c]] - lateral_surface_area(NX_NUMBER): - doc: Lateral surface area - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - cap_surface_area(NX_NUMBER): - doc: Area of the upper and the lower cap of each cylinder respectively. - unit: NX_AREA - dimensions: - rank: 2 - dim: [[1, c], [2, 2]] - surface_area(NX_NUMBER): - doc: Cap and lateral surface area for each cylinder. - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] -# again cap, lateral surface area and volume are so trivial to compute -# do we need really storage for this or recompute on-the-fly? -# similarly to hollow sphere discussion, hollow cylinder, cylinder stack -# do wish to define intersections?, if this is the case, one -# should use the NXcsg and NXquadric descriptions? diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml deleted file mode 100644 index 384cd3f47d..0000000000 --- a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml +++ /dev/null @@ -1,87 +0,0 @@ -# redundant as there is NXcsg, and NXquadric but easier to understand -category: base -doc: | - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality, which has to be at least 2. - c: The cardinality of the set, i.e. the number of ellipses, or ellipsoids. -NXcg_ellipsoid_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish ellipsoids for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - doc: | - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - half_axes_radius(NX_NUMBER): - doc: | - If all ellipsoids in the set have the same half-axes. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, d]] - half_axes_radii(NX_NUMBER): - doc: | - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - # properties of ellipsoids - is_closed(NX_BOOLEAN): - doc: Are the ellipsoids closed or hollow? - dimensions: - rank: 1 - dim: [[1, c]] - volume(NX_NUMBER): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, c]] - surface_area(NX_NUMBER): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, c]] - # NXcg_orientation_set - orientation(NX_NUMBER): - doc: | - Direction unit vector which points along the largest half-axes. - unit: NX_DIMENSIONLESS - dimensions: - rank: 2 - dim: [[1, c], [2, d]] diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml deleted file mode 100644 index fb9569afee..0000000000 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml +++ /dev/null @@ -1,169 +0,0 @@ -# duplicate of an NXoff_geometry ? -category: base -doc: | - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality, which has to be at least 2. - n_v: The number of vertices. - n_e: The number of edges. - n_f: The number of faces. - n_total: The total number of vertices of all faces. Faces are polygons. - n_weinberg: The total number of Weinberg vector values of all faces. -NXcg_face_list_data_structure: - dimensionality(NX_POSINT): - doc: Dimensionality. - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - doc: Number of vertices. - unit: NX_UNITLESS - number_of_edges(NX_POSINT): - doc: Number of edges. - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - doc: Number of faces. - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - edge_identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - vertex_identifier(NX_INT): - doc: Integer used to distinguish vertices explicitly. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_v]] - edge_identifier(NX_INT): - doc: Integer used to distinguish edges explicitly. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_e]] - face_identifier(NX_INT): - doc: Integer used to distinguish faces explicitly. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_f]] - vertices(NX_NUMBER): - doc: | - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, d]] - edges(NX_INT): - doc: | - The edges are stored as a pairs of vertex identifier values. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_e], [2, 2]] - # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology - number_of_vertices(NX_POSINT): - doc: | - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_f]] - faces(NX_INT): - doc: | - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_total]] - # properties - vertices_are_unique(NX_BOOLEAN): - doc: | - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - edges_are_unique(NX_BOOLEAN): - doc: | - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - faces_are_unique(NX_BOOLEAN): - winding_order(NX_INT): - doc: | - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_f]] diff --git a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml deleted file mode 100644 index e61e00d22d..0000000000 --- a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml +++ /dev/null @@ -1,28 +0,0 @@ -category: base -doc: | - Computational geometry description of a geodesic mesh. - - People from geodesic/surveyors will likely have specific demands and - different views about what should be included in such a base class, given - that nested geodesic meshes are a key component of climate modelling tools. - For now we propose to use this base class as a container to organize metadata - and data related to geodesic meshes. - - Specifically an instance of this base class should detail the rule set how - how the geodesic (surface) mesh was instantiated as there are many - possibilities. A geodesic surface mesh is in this sense a triangulated - surface mesh with metadata. For additional details as an introduction - into the topic see e.g.: - - * `E. S. Popko and C. J. Kitrick `_ - - Here, especially the section on subdivision schemes is relevant. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcg_geodesic_mesh: - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - (NXcg_triangulated_surface_mesh): -# Discussions with NFDI-Earth could make this base class more meaty and detailed. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcg_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml deleted file mode 100644 index 3a072e78c4..0000000000 --- a/contributed_definitions/nyaml/NXcg_grid.yaml +++ /dev/null @@ -1,114 +0,0 @@ -category: base -doc: | - Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. - - Frequently convenient three-dimensional grids with cubic cells are used. - Exemplar applications are spectral-solver based crystal plasticity - and stencil methods like phase-field or cellular automata. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality of the grid. - c: The cardinality or total number of cells/grid points. - n_b: Number of boundaries of the bounding box or primitive to the grid. -NXcg_grid: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - origin(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, d]] - symmetry: - doc: The symmetry of the lattice defining the shape of the unit cell. - enumeration: [cubic] - cell_dimensions(NX_NUMBER): - doc: | - The unit cell dimensions using crystallographic notation. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, d]] - extent(NX_POSINT): - doc: | - Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, d]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - # number_of_cells(NX_UINT): maybe already too trivial quantities - # should constraints on the grid be place here or not - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for cells. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish cells for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - position(NX_NUMBER): - doc: Position of each cell in Euclidean space. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - coordinate(NX_INT): - doc: Coordinate of each cell with respect to the discrete grid. - unit: NX_DIMENSIONLESS - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - # this should be a ROI - bounding_box(NXcg_polyhedron_set): - doc: A tight bounding box or sphere or bounding primitive about the grid. - # a good example for a general bounding box description for such a grids of triclinic cells - # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped - number_of_boundaries(NX_POSINT): - doc: | - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - unit: NX_UNITLESS - boundaries: - doc: | - Name of domain boundaries of the simulation box/ROI e.g. left, right, - front, back, bottom, top. - # The field must have as many entries as there are number_of_boundaries. - dimensions: - rank: 1 - dim: [[1, n_b]] - boundary_conditions(NX_INT): - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_b]] diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml deleted file mode 100644 index e136c2420a..0000000000 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ /dev/null @@ -1,115 +0,0 @@ -category: base -doc: | - Computational geeometry description of a half-edge data structure. - - Such a data structure can be used to efficiently circulate around faces - and iterate over vertices of a planar graph. -# holes in the polygon mesh can be handled -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality, which has to be at least 2. - n_v: The number of vertices. - n_f: The number of faces. - n_he: The number of half-edges. -NXcg_half_edge_data_structure: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - number_of_half_edges(NX_POSINT): - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - doc: | - In this half-edge data structure vertex identifiers start at 1. - Vertices are identified with consecutive integers up to number_of_vertices. - This field can be used to document which constant integer has to be - added to another set of vertex_identifier to assure that these other - identifiers also start at 1. - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - doc: | - In this half-edge data structure face identifiers start at 1. - Faces are identified with consecutive integers up to number_of_faces. - This field can be used to document which constant integer has to be - added to another set of face_identifier to assure that these other - identifiers also start at 1. - - The face identifier zero is reserved for the NULL face ! - unit: NX_UNITLESS - half_edge_identifier_offset(NX_INT): - doc: | - In this half-edge data structure half-edge identifiers start at 1. - Half-edges are identified with consecutive integers up to number_of_half_edges. - This field can be used to document which constant integer has to be - added to another set of half_edge_identifier to assure that these other - identifiers also start at 1. - unit: NX_UNITLESS - # therefore, vertex_-, face_-, half_edge_-identifier are implicit - position(NX_NUMBER): - doc: The position of the vertices. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, d]] - vertex_incident_half_edge(NX_UINT): - doc: Identifier of the incident half-edge. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_v]] - face_half_edge(NX_UINT): - doc: Identifier of the (starting)/associated half-edge of the face. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_f]] - half_edge_vertex_origin(NX_UINT): - doc: | - The identifier of the vertex from which this half-edge is outwards pointing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_twin(NX_UINT): - doc: Identifier of the associated oppositely pointing half-edge. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_incident_face(NX_UINT): - doc: | - If the half-edge is a boundary half-edge the - incident face identifier is NULL, i.e. 0. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_next(NX_UINT): - doc: Identifier of the next half-edge. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_prev(NX_UINT): - doc: Identifier of the previous half-edge. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_he]] - weinberg_vector: - doc: | - Users are referred to the literature for the background of L. Weinberg's - work about topological characterization of planar graphs: - - * `L. Weinberg 1966a, `_ - * `L. Weinberg, 1966b, `_ - * `E. A. Lazar et al. `_ - - and how this work can e.g. be applied in space-filling tessellations - of microstructural objects like crystals/grains. -# eventually store the Weinberg vector as an integer array -# which could be more efficient -# see https://jerryyin.info/geometry-processing-algorithms/half-edge/ -# for an illustrative example of half-edge data structures diff --git a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml deleted file mode 100644 index 0dc7f274b7..0000000000 --- a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml +++ /dev/null @@ -1,178 +0,0 @@ -# it is useful to define own base classes for frequently used classes -# a polyhedron is a specific polytope in 3d, do we need -# higher-dimensional polytopes? that could be useful for simplicies though -# as they are used in numerics etc. maybe reach out here to our friends -# from MarDI, for now let's assume we do not need polytopes for d > 3 -category: base -doc: | - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - c: The cardinality of the set, i.e. the number of hexahedra. -NXcg_hexahedron_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - # qualifiers and properties of hexahedra - shape(NX_NUMBER): - doc: A qualitative description of each hexahedron/cuboid/cube/box. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - length(NX_NUMBER): - doc: | - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of an edge within - a specific coordinate system. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - height(NX_NUMBER): - doc: | - Qualifier often used to describe the length of an edge within - a specific coordinate system. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - doc: | - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - volume(NX_NUMBER): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, c]] - surface_area(NX_NUMBER): - doc: Total area (of all six faces) of each hexahedron. - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - face_area(NX_NUMBER): - doc: Area of each of the six faces of each hexahedron. - unit: NX_AREA - dimensions: - rank: 2 - dim: [[1, c], [2, 6]] - is_box(NX_BOOLEAN): - doc: | - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - dimensions: - rank: 1 - dim: [[1, c]] - is_axis_aligned(NX_BOOLEAN): - doc: | - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish hexahedra for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - # substantially more detailed descriptors of the shape, the mesh - orientation(NXorientation_set): - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # detailed mesh-based representation - hexahedra(NXcg_face_list_data_structure): - # exists: [min, 0, max, 1] - doc: | - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - hexahedron(NXcg_face_list_data_structure): - # exists: [min, 0, max, infty] # can this be max, c? - doc: Disentangled representations of the mesh of specific hexahedra. - hexahedron_half_edge(NXcg_half_edge_data_structure): - # exists: [min, 0, max, infty] - doc: | - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml deleted file mode 100644 index d52388bb47..0000000000 --- a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Computational geometry description of the marching cubes algorithm. - - Documenting which specific version was used can help to understand how robust - the results are with respect to the topology of the triangulation. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcg_marching_cubes: - grid(NXcg_grid): - doc: | - Reference/link to and/or details of the grid on which a specific - marching cubes algorithm implementation is operating. - implementation: - doc: | - Reference to the specific implementation of marching cubes used. - - See for example the following papers for details about how to identify a - DOI which specifies the implementation used: - - * `W. E. Lorensen `_ - * `T. S. Newman and H. Yi `_ - - The value placed here should be a DOI. If there are no specific DOI or - details write not_further_specified, or give at least a free-text - description. - program: - doc: | - Commercial or otherwise given name to the program which was used. - \@version: - doc: | - Program 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. -# we could also think about storing the rule sets in here explicitly including the -# coordinate system conventions; however, the problem is that many commercial -# tools like Matlab do not expose the rule set. diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml deleted file mode 100644 index 44e56bceb9..0000000000 --- a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml +++ /dev/null @@ -1,132 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - c: The cardinality of the set, i.e. the number of parallelograms. -NXcg_parallelogram_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [2] - cardinality(NX_POSINT): - unit: NX_UNITLESS - # qualifiers and properties of parallelograms - shape(NX_NUMBER): - doc: A qualitative description of each parallelogram/rectangle/square/box. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 2]] - length(NX_NUMBER): - doc: | - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of an edge within - a specific coordinate system. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - doc: | - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 2]] - surface_area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - is_axis_aligned(NX_BOOLEAN): - doc: | - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish parallelograms for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - # substantially more detailed descriptors of the shape, the mesh - orientation(NXorientation_set): - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # detailed mesh-based representation - parallelograms(NXcg_face_list_data_structure): - # exists: [min, 0, max, 1] - doc: | - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - parallelogram(NXcg_face_list_data_structure): - # exists: [min, 0, max, infty] # can this be max, c? - doc: Disentangled representations of the mesh of specific parallelograms. - # ##MK::a half-edge structure would be overkill as this is a simple primitive diff --git a/contributed_definitions/nyaml/NXcg_point_set.yaml b/contributed_definitions/nyaml/NXcg_point_set.yaml deleted file mode 100644 index 017bd77382..0000000000 --- a/contributed_definitions/nyaml/NXcg_point_set.yaml +++ /dev/null @@ -1,55 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality, which has to be at least 1. - c: The cardinality of the set, i.e. the number of points. -NXcg_point_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish points for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - position(NX_NUMBER): - doc: The array of point coordinates. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - time(NX_NUMBER): - doc: The optional array of time for each vertex. - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.yaml b/contributed_definitions/nyaml/NXcg_polygon_set.yaml deleted file mode 100644 index 624d047ff6..0000000000 --- a/contributed_definitions/nyaml/NXcg_polygon_set.yaml +++ /dev/null @@ -1,171 +0,0 @@ -category: base -# somewhat redundant as there is NXoff_geometry but easier to understand -doc: | - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. -# Users can take advantage of NXcg_polygon_set to describe such complexes -# when using the defines_plc and related topological and boundary constraint -# descriptors. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality, which has to be either 2 or 3. - c: The cardinality of the set, i.e. the number of polygons. - # n_unique: Number of unique points supporting the polygons. - n_total: The total number of vertices when visiting every polygon. -NXcg_polygon_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [2, 3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - number_of_total_vertices(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish polygons for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - polygons(NXcg_face_list_data_structure): - # exists: [min, 0, max, 1] - doc: | - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - # detailed additional information eventually mesh-related data - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # triangles_half_edge(NXcg_half_edge_data_structure): - # properties of the polygon primitives - area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - edge_length(NX_NUMBER): - doc: The accumulated length of the polygon edge. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - interior_angle(NX_NUMBER): - doc: | - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, n_total]] - shape(NX_INT): - doc: | - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - doc: The center of mass of each polygon. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - bounding_box(NXcg_hexahedron_set): - doc: Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - # ##MK::ROI about the set ? -# a set of polygons can be interpreted as a descriptor for an object -# an, in TetGen terminology, piecewise-linear complex -# defines_plc(NX_BOOLEAN): -# doc: True, if the set describes a piecewise-linear complex. -# ##MK::each polygon could be given a role with respect to what the polygon -# ##MK::represents of the complex, this would allow to define a complex with -# ##MK::holes -# vertices(NXcg_point_set): -# doc: | -# The set of vertices supporting the polygons. -# -# The dimensionality of the point set and this polygon set are the same. -# The number of vertices is arbitrary because polygons may different in -# their number of edges. -# -# Like it is the case for NXcg_triangle_set instances, individual -# polygons may make edge contact in which case a lower number of vertices -# suffices than naively expected from a summation of the edges. -# -# Users are encouraged to reduce the vertex set to a set of unique vertices -# as this can often turn out to allow for a more efficient storage -# of the geometry data. It is also possible though to store -# the vertices naively in which case vertices_are_unique is likely False. -# vertices_are_unique(NX_BOOLEAN): -# doc: | -# If true indicates that the vertices are all placed at different positions -# and have different identifiers, i.e. no points overlap or are counted twice. -# number_of_vertices(NX_POSINT): -# doc: | -# Array which specifies of how many vertices each polygon is built. -# The number of vertices represent the total number of vertices for -# each polygon, irrespectively whether vertices are shared or not. -# See the docstring for polygons for further details about how -# a set with different polyline members should be stored. -# unit: NX_UNITLESS -# dimensions: -# rank: 1 -# dimensions: [[1, c]] -# # ##MK::there is nothing like value constraints... or minimum bitdepth -# polygons(NX_INT): -# doc: | -# Array of identifiers from vertices which describe each polygon. -# -# The first entry is the identifier of the start vertex of the first polyline, -# followed by the second vertex of the first polyline, until the last vertex -# of the polyline. Thereafter, the start vertex of the second polyline, and -# so on and so forth. Using the (cumulated) counts in number_of_vertices, -# the vertices of the n-th polyline can be accessed on the following -# array index interval: -# [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. -# -# Users are advised to store the vertex identifiers, if possible and -# ideally then for all of them, according to and using winding order. -# If the winding_order field is given, it has to report the specific winding -# order used. -# unit: NX_UNITLESS -# dimensions: -# rank: 1 -# dim: [[1, n_total]] diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml deleted file mode 100644 index 7142213823..0000000000 --- a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml +++ /dev/null @@ -1,131 +0,0 @@ -# it is useful to define own base classes for frequently used classes -# a polyhedron is a specific polytope in 3d, do we need -# higher-dimensional polytopes? that could be useful for simplicies though -# as they are used in numerics etc. maybe reach out here to our friends -# from MarDI, for now let's assume we do not need polytopes for d > 3 -# NeXus already supports polyhedra via NXoff_geometry -# the here proposed base class extends the capabilities to qualifiers of -# polyhedra and also half_edge_data_structures that can be useful -# for clean graph-based descriptions of polyhedra. -category: base -doc: | - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - c: The cardinality of the set, i.e. the number of polyhedra. - n_e_total: The total number of edges for all polyhedra. - n_f_total: The total number of faces for all polyhedra. -NXcg_polyhedron_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - # qualifiers and properties of polyhedra - volume(NX_NUMBER): - doc: Interior volume - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - doc: | - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - surface_area(NX_NUMBER): - doc: Total surface area as the sum of all faces. - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - number_of_faces(NX_POSINT): - doc: | - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - face_area(NX_NUMBER): - doc: | - Area of each of the four triangular faces of each tetrahedron. - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, n_f_total]] - number_of_edges(NX_POSINT): - doc: | - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - edge_length(NX_NUMBER): - doc: | - Length of each edge of each tetrahedron. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_e_total]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - # substantially more detailed descriptors of the shape, the mesh - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish polyhedra for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # detailed mesh-based representation - polyhedra(NXcg_face_list_data_structure): - # exists: [min, 0, max, 1] - doc: | - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - polyhedron(NXcg_face_list_data_structure): - # exists: [min, 0, max, infty] # can this be max, c? - doc: Disentangled representations of the mesh of specific polyhedron. - polyhedron_half_edge(NXcg_half_edge_data_structure): - # exists: [min, 0, max, infty] - doc: | - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. -# face_type(NX_UINT): #maybe a better name maybe topology, although this is misleading for the above-mentioned reasons -# doc: A concatenated array, for each polygon face the number of vertices. -# unit: NX_UNITLESS -# dimensions: -# rank: 1 -# dim: [[1, nfaces]] -# intersections between members? as a graph -# contact with external primitives like simulation domain etc \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.yaml b/contributed_definitions/nyaml/NXcg_polyline_set.yaml deleted file mode 100644 index 78d1dec642..0000000000 --- a/contributed_definitions/nyaml/NXcg_polyline_set.yaml +++ /dev/null @@ -1,131 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of polylines in Euclidean space. - - Each polyline is built from a sequence of vertices (points with identifiers). - Each polyline must have a start and an end point. - The sequence describes the positive traversal along the polyline when walking - from the start vertex to the end/last vertex. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality, which has to be at least 1. - c: The cardinality of the set, i.e. the number of polylines. - # n_unique: The number of unique vertices supporting the polyline. - # multiple vertices possible with the same point coordinates but different names. - n_v: The number of vertices, supporting the polylines. - n_total: The total number of vertices traversed when visiting every polyline. -NXcg_polyline_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - # number_of_unique_vertices(NX_POSINT): - # unit: NX_UNITLESS - number_of_total_vertices(NX_POSINT): - doc: | - The total number of vertices, irrespective of their eventual uniqueness, - i.e. the total number of vertices that have to be visited when walking - along each polyline. - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - doc: | - The number of vertices. If vertices are reduced to the unique ones, this - number_of_vertices is not necessarily equal to the total number of vertices. - unit: NX_UNITLESS - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and polyline data are interpretable. - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - polylines. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish polylines for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - vertices(NX_NUMBER): - doc: | - Positions of the vertices which support the members of the polyline set. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - # Users are encouraged to reduce the vertex set to the unique vertices. - # Unique means not necessarily unique in position only but also unique in - # identifier. In fact, it is possible to distinguish two vertices as two when - # they share the same position in space but have different identifiers. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, d]] - vertices_are_unique(NX_BOOLEAN): - doc: | - If true indicates that the vertices are all placed at different - positions and have different identifiers, i.e. no points overlap - or are counted twice. - number_of_vertices(NX_POSINT): - doc: | - Array which specifies of how many vertices each polyline is built. - The number of vertices represent the total number of vertices for - each polyline, irrespectively whether vertices are shared or not. - See the docstring for polylines for further details about how - a set with different polyline members should be stored. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - polylines(NX_INT): - doc: | - Sequence of vertex identifiers which describe each polyline. - - A trivial example is a set with two polylines with three vertices each. - If the polylines meet in a junction, say the second vertex is shared - and marking the junction between the two polylines, it is possible that - there are only five unique positions suggesting five unique vertices. - - A non-trivial example is a set with several polylines, each of which with - eventually different number of vertices. The array stores the vertex - identifiers in the order how the polylines are visited: - - The first entry is the identifier of the start vertex of the first polyline, - followed by the second vertex of the first polyline, until the last vertex - of the polyline. Thereafter, the start vertex of the second polyline, and - so on and so forth. Using the (cumulated) counts in number_of_vertices, - the vertices of the n-th polyline can be accessed on the following - array index interval: - :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_total]] - # properties of the polyline primitives - length(NX_NUMBER): - doc: The length of each polyline. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - is_closed(NX_BOOLEAN): - doc: | - If true specifies that a polyline is closed, i.e. - its end point is connected to the start point. - dimensions: - rank: 1 - dim: [[1, c]] - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): diff --git a/contributed_definitions/nyaml/NXcg_roi_set.yaml b/contributed_definitions/nyaml/NXcg_roi_set.yaml deleted file mode 100644 index a28aae9e2e..0000000000 --- a/contributed_definitions/nyaml/NXcg_roi_set.yaml +++ /dev/null @@ -1,13 +0,0 @@ -# eventually redundant NXsolid_geometry? -category: base -doc: | - Base class to hold geometric primitives. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcg_roi_set: - CG_SPHERE_SET(NXcg_sphere_set): - CG_ELLIPSOID_SET(NXcg_ellipsoid_set): - CG_CYLINDER_SET(NXcg_cylinder_set): - CG_POLYHEDRON_SET(NXcg_polyhedron_set): -# doc: An eventually redundant container to hold multiple primitives. -# how to handle cases where multiple primitives should be included? diff --git a/contributed_definitions/nyaml/NXcg_sphere_set.yaml b/contributed_definitions/nyaml/NXcg_sphere_set.yaml deleted file mode 100644 index 1ae6751e33..0000000000 --- a/contributed_definitions/nyaml/NXcg_sphere_set.yaml +++ /dev/null @@ -1,76 +0,0 @@ -# redundant as there is NXcsg, and NXquadric but easier to understand -category: base -doc: | - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality, which has to be at least 2. - c: The cardinality of the set, i.e. the number of circles or spheres. -NXcg_sphere_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish spheres for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - doc: | - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - radius(NX_NUMBER): - doc: | - In the case that all spheres have the same radius. - unit: NX_LENGTH - radii(NX_NUMBER): - doc: | - In the case that spheres have different radius use this - instead of the radius field. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - # properties of spheres - is_closed(NX_BOOLEAN): - doc: Are the spheres closed or hollow? - dimensions: - rank: 1 - dim: [[1, c]] - volume(NX_NUMBER): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, c]] - surface_area(NX_NUMBER): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, c]] diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml deleted file mode 100644 index fd5376fc0d..0000000000 --- a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml +++ /dev/null @@ -1,122 +0,0 @@ -# it is useful to define own base classes for frequently used classes -# a polyhedron is a specific polytope in 3d, do we need -# higher-dimensional polytopes? that could be useful for simplicies though -# as they are used in numerics etc. maybe reach out here to our friends -# from MarDI, for now let's assume we do not need polytopes for d > 3 -category: base -doc: | - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - c: The cardinality of the set, i.e. the number of tetrahedra. -NXcg_tetrahedron_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - # qualifiers and properties of tetrahedra - volume(NX_NUMBER): - doc: Interior volume - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - doc: | - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - surface_area(NX_NUMBER): - doc: Total surface area as the sum of all four triangular faces. - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - face_area(NX_NUMBER): - doc: | - Area of each of the four triangular faces of each tetrahedron. - unit: NX_AREA - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - edge_length(NX_NUMBER): - doc: | - Length of each edge of each tetrahedron. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 6]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - # substantially more detailed descriptors of the shape, the mesh - # interior_angle(NX_NUMBER): - # doc: | - # Array of interior angle values. For each tetrahedron the quadruplet of - # angles is a sequence following the order of the vertices. The angle - # is the angle at the specific vertex. TODO lexiographical order. - # Winding order has to be interpreted to resolve the individual angles - # between edges of adjoining face triangles meeting at each corner/vertex. - # unit: NX_ANGLE - # dimensions: - # rank: 2 - # dim: [[1, c], [2, 12]] - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish tetrahedra for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # detailed mesh-based representation - tetrahedra(NXcg_face_list_data_structure): - # exists: [min, 0, max, 1] - doc: | - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - tetrahedron(NXcg_face_list_data_structure): - # exists: [min, 0, max, infty] # can this be max, c? - doc: Disentangled representations of the mesh of specific tetrahedra. - tetrahedron_half_edge(NXcg_half_edge_data_structure): - # exists: [min, 0, max, infty] - doc: | - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.yaml b/contributed_definitions/nyaml/NXcg_triangle_set.yaml deleted file mode 100644 index 848b3d366a..0000000000 --- a/contributed_definitions/nyaml/NXcg_triangle_set.yaml +++ /dev/null @@ -1,79 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of triangles in Euclidean space. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality, which has to be at least 2. - c: The cardinality of the set, i.e. the number of triangles. - n_unique: The number of unique vertices supporting the triangles. -NXcg_triangle_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - number_of_unique_vertices(NX_POSINT): - unit: NX_UNITLESS - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish triangles for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - triangles(NXcg_face_list_data_structure): - # exists: [min, 0, max, 1] - doc: | - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - # detailed additional information eventually mesh-related data - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # triangles_half_edge(NXcg_half_edge_data_structure): - # properties of triangles - area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - edge_length(NX_NUMBER): - doc: | - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - interior_angle(NX_NUMBER): - doc: | - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - center(NX_NUMBER): - doc: The center of mass of each polygon. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - bounding_box(NXcg_hexahedron_set): - doc: Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml deleted file mode 100644 index 79af29f276..0000000000 --- a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml +++ /dev/null @@ -1,27 +0,0 @@ -category: base -doc: | - Computational geometry description of a mesh of triangles. - - The mesh may be self-intersecting and have holes but the - triangles must not be degenerated. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcg_triangulated_surface_mesh: -# (NXtransformations): -# doc: | -# Reference to or definition of a coordinate system with -# which the qualifiers and mesh data are interpretable. -# # substantially more detailed descriptors of the shape, the mesh -# vertex_normal(NXcg_unit_normal_set): -# edge_normal(NXcg_unit_normal_set): -# face_normal(NXcg_unit_normal_set): -# # detailed mesh-based representation -# (NXcg_face_list_data_structure): -# doc: | -# A simple approach to describe the mesh when the main intention is to -# store its triangles for visualization. - (NXcg_triangle_set): - (NXcg_half_edge_data_structure): - doc: | - A graph-based approach to describe the mesh when it is also desired - to perform topological processing or analyses on the mesh. diff --git a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml deleted file mode 100644 index 4a04ae634b..0000000000 --- a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml +++ /dev/null @@ -1,33 +0,0 @@ -# the benefit of NXcg_point_set is that the origin is 0 by default -# how to resolve the association between the unit normal and its associated primitive? -# rather make this a set of vectors, irrespective whether these are unit or not -category: base -doc: | - Computational geometry description of a set of (oriented) unit normal vectors. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality, which has to be at least 2. - c: The cardinality of the set, i.e. the number of unit normals. -NXcg_unit_normal_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - doc: Direction of each normal - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - orientation(NX_INT): - doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] diff --git a/contributed_definitions/nyaml/NXchamber.yaml b/contributed_definitions/nyaml/NXchamber.yaml deleted file mode 100644 index da826038d1..0000000000 --- a/contributed_definitions/nyaml/NXchamber.yaml +++ /dev/null @@ -1,11 +0,0 @@ -category: base -doc: | - Component of an instrument to store or place objects and specimens. -NXchamber: - name: - doc: Given name/alias. - description: - doc: | - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. - (NXfabrication): diff --git a/contributed_definitions/nyaml/NXchemical_composition.yaml b/contributed_definitions/nyaml/NXchemical_composition.yaml deleted file mode 100644 index ce334b02c6..0000000000 --- a/contributed_definitions/nyaml/NXchemical_composition.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - (Chemical) composition of a sample or a set of things. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n: The number of samples or things. -NXchemical_composition: - # molecule descriptor - # chemical_formula: - # doc: | - # IUPAC chemical formula - total(NX_NUMBER): - doc: | - Total based on which composition information is normalized. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n]] - ION(NXion): - count(NX_NUMBER): - doc: | - Count or weight which, when divided by total yields the composition - of this element, isotope, molecule or ion. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n]] - composition(NX_NUMBER): - doc: | - Count divided by total in atom percent. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n]] diff --git a/contributed_definitions/nyaml/NXcircuit_board.yaml b/contributed_definitions/nyaml/NXcircuit_board.yaml deleted file mode 100644 index 882a9ca2c6..0000000000 --- a/contributed_definitions/nyaml/NXcircuit_board.yaml +++ /dev/null @@ -1,17 +0,0 @@ -category: base -doc: | - Circuit board with e.g. ADC and/or DAC electronic components. - - Currently used to store the settings of the so-called magboards used in - Nion electron microscopes but likely this could be a useful base class for - substantially more use cases where details at a deep technical instrument design - level are relevant or important. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcircuit_board: - relay(NX_NUMBER): - doc: | - TBD by Nion Co. - unit: NX_UNITLESS - (NXdac): - (NXadc): diff --git a/contributed_definitions/nyaml/NXclustering.yaml b/contributed_definitions/nyaml/NXclustering.yaml deleted file mode 100644 index cbb0bd96c6..0000000000 --- a/contributed_definitions/nyaml/NXclustering.yaml +++ /dev/null @@ -1,67 +0,0 @@ -category: base -doc: | - Metadata to the results of a clustering analysis. - - Clustering algorithms are routine tools to segment a set of objects/primitives - into groups, objects of different type. A plethora of algorithms have been - proposed for geometric primitives as objects, such as points, triangles, - or (abstract) objects. - - This base class considers metadata and results of one clustering - applied to a set in which objects are either categorized as noise - or belonging to a cluster, specifically here only one cluster. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_lbl_num: Number of numeral labels per object. - n_lbl_cat: Number of categorical labels per object. - n_cluster: Total number of clusters detected. -NXclustering: - number_of_numeric_labels(NX_UINT): - doc: How many numeric labels does each object have. - unit: NX_UNITLESS - number_of_categorical_labels(NX_UINT): - doc: How many categorical labels does each object have. - unit: NX_UNITLESS - objects: - doc: | - Reference to a set of objects investigated in a cluster analysis. - Objects must have clear integer identifier. - numeric_label(NX_NUMBER): - doc: | - Reference to numeric attribute data for each object. - categorical_label: - doc: | - Reference to categorical attribute data for each object. - # list instances of base classes of an applied cluster algorithm - # e.g. (NXclustering_hdbscan): - identifier_offset(NX_UINT): - doc: | - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - unit: NX_UNITLESS - unassigned(NX_UINT): - doc: Total number of objects categorized as unassigned. - unit: NX_UNITLESS - noise(NX_UINT): - doc: Total number of objects categorized as noise. - unit: NX_UNITLESS - number_of_cluster(NX_UINT): - doc: Total number of clusters (excluding noise and unassigned). - unit: NX_UNITLESS - size(NX_NUMBER): - doc: | - Number of objects associated to each cluster. The labels are implicit, - meaning the zeroth/first entry in the array belongs to the first cluster, - the second entry to the second cluster and so on and so forth. - The first cluster has the value of identifier_offset as its identifier. - The second cluster has identifier_offset + 1, and so on and so forth. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_cluster]] - # should we handle, and if so how fuzzy assignments or similarly probability diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yaml b/contributed_definitions/nyaml/NXcollectioncolumn.yaml deleted file mode 100644 index 55a76cd957..0000000000 --- a/contributed_definitions/nyaml/NXcollectioncolumn.yaml +++ /dev/null @@ -1,40 +0,0 @@ -category: base -doc: "Subclass of NXelectronanalyser to describe the electron collection column - of a photoelectron analyser." -NXcollectioncolumn: - scheme(NX_CHAR): - doc: - "Scheme of the electron collection lens, i.e. standard, deflector, PEEM, - momentum microscope, etc." - extractor_voltage(NX_FLOAT): - doc: "Voltage applied to the extractor lens" - unit: NX_VOLTAGE - extractor_current(NX_FLOAT): - doc: "Current necessary to keep the extractor lens at a set voltage. - Variations indicate leakage, field emission or arc currents to the extractor lens." - unit: NX_CURRENT - working_distance(NX_FLOAT): - doc: "Distance between sample and detector entrance" - unit: NX_LENGTH - mode(NX_CHAR): - doc: "Labelling of the lens setting in use." - projection(NX_CHAR): - doc: "The space projected in the angularly dispersive directions, real or reciprocal" - enumeration: ["real", "reciprocal"] - magnification(NX_FLOAT): - doc: "The magnification of the electron lens assembly." - unit: NX_DIMENSIONLESS - depends_on(NX_CHAR): - doc: "Specifies the position of the collectioncolumn by pointing to the last transformation in the transformation chain in the NXtransformations group." - (NXtransformations): - doc: - "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 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." - (NXaperture): - doc: "The size and position of an aperture inserted in the column, e.g. field aperture or contrast aperture" - (NXdeflector): - doc: "Deflectors in the collection column section" - (NXlens_em): - doc: "Individual lenses in the collection column section" diff --git a/contributed_definitions/nyaml/NXcontainer.yaml b/contributed_definitions/nyaml/NXcontainer.yaml deleted file mode 100644 index 2bfbdf7f58..0000000000 --- a/contributed_definitions/nyaml/NXcontainer.yaml +++ /dev/null @@ -1,294 +0,0 @@ -category: base -doc: | - State of a container holding the sample under investigation. - - A container is any object in the beam path which absorbs the beam and - whose contribution to the overall attenuation/scattering needs to be - determined to process the experimental data. Examples of containers - include glass capillary tubes, vanadium cans, windows in furnaces or - diamonds in a Diamond Anvil Cell. The following figures show a complex - example of a container: - - .. figure:: container/ComplexExampleContainer.png - - A hypothetical capillary furnace. The beam passes from left to right - (blue dashes), passing through window 1, then window 2, before - passing through the downstream wall of the capillary. It is then - scattered by the sample with scattered beams passing through the - upstream wall of the capillary, then windows 4 and 5. As part of the - corrections for a PDF experiment it is necessary to subtract the PDF - of the empty container (i.e. each of the windows and the capillary). - To calculate the PDF of the empty container it is necessary to have - the measured scattering data and to know the nature (e.g. density, - elemental composition, etc.) of the portion of the container which - the beam passed through. - - .. figure:: container/ComplexContainerBeampath.png - - A complete description of the shapes of the container elements with - their orientation relative to the beam and also information on - whether they are upstream or downstream of the sample is also - therefore important. For example, although the windows 2 and 4 have - the same shape, the path taken through them by the beam is very - different and this needs to be modelled. Furthermore, it is not - inconceivable that windows might move during an experiment and thus - the changes to the beampath would need to be accounted for. - - This class encodes the position of the container with respect to the - sample and allows the calculation of the beampath through the container. - It also includes sufficient data to model beam absorption of the - container and a link to a dataset containing a measurement of the - container with nothing inside, to allow data corrections (at a specific - beam energy/measurement time) to be made. -type: group -NXcontainer(NXobject): - name: - doc: | - Descriptive name of container. - description: - doc: | - Verbose description of container and how it fits into the wider - experimental set up. - chemical_formula: - doc: | - Chemical composition of the material the container is made from. - Specified using CIF conventions. Abbreviated version of CIF - standard: - - * 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. - - * This is the *Hill* system used by Chemical Abstracts. - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of the material the container is made from. - dimensions: - rank: 1 - dim: [[1, n_comp]] - packing_fraction(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Fraction of the volume of the container occupied by the material - forming the container. - dimensions: - dim: [[1, n_comp]] - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative molecular mass of container. - dimensions: - rank: 1 - dim: [[1, n_comp]] - beam(NXbeam): - doc: | - Details of beam incident on container, including the position - relative to the sample (to determine whether the container is - upstream or downstream of the sample). - shape(NXshape): - doc: | - Shape of the container. In combination with orientation this - should allow the beampath through the container to be modelled to - allow the adsorption to be calculated. - orientation(NXtransformations): - doc: | - The angle the container makes to the beam and how it may change - during the experiment.In combination with shape this should allow - the beampath through the container to be modelled to allow the - adsorption of the container to be calculated. - reference_measurement(link): - target: /NXentry - doc: | - A link to a full data collection which contains the actual - measured data for this container within the experimental set up - (with no sample or inner container(s)). This data set will also - include the wavelength/energy, measurement time and intensity for - which these data are valid. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fbb634b42fbf75d55158a96329119a770f9ff716d2e3ec127b28b192c5fe872a -# -# -# -# -# -# -# State of a container holding the sample under investigation. -# -# A container is any object in the beam path which absorbs the beam and -# whose contribution to the overall attenuation/scattering needs to be -# determined to process the experimental data. Examples of containers -# include glass capillary tubes, vanadium cans, windows in furnaces or -# diamonds in a Diamond Anvil Cell. The following figures show a complex -# example of a container: -# -# .. figure:: container/ComplexExampleContainer.png -# -# A hypothetical capillary furnace. The beam passes from left to right -# (blue dashes), passing through window 1, then window 2, before -# passing through the downstream wall of the capillary. It is then -# scattered by the sample with scattered beams passing through the -# upstream wall of the capillary, then windows 4 and 5. As part of the -# corrections for a PDF experiment it is necessary to subtract the PDF -# of the empty container (i.e. each of the windows and the capillary). -# To calculate the PDF of the empty container it is necessary to have -# the measured scattering data and to know the nature (e.g. density, -# elemental composition, etc.) of the portion of the container which -# the beam passed through. -# -# .. figure:: container/ComplexContainerBeampath.png -# -# A complete description of the shapes of the container elements with -# their orientation relative to the beam and also information on -# whether they are upstream or downstream of the sample is also -# therefore important. For example, although the windows 2 and 4 have -# the same shape, the path taken through them by the beam is very -# different and this needs to be modelled. Furthermore, it is not -# inconceivable that windows might move during an experiment and thus -# the changes to the beampath would need to be accounted for. -# -# This class encodes the position of the container with respect to the -# sample and allows the calculation of the beampath through the container. -# It also includes sufficient data to model beam absorption of the -# container and a link to a dataset containing a measurement of the -# container with nothing inside, to allow data corrections (at a specific -# beam energy/measurement time) to be made. -# -# -# -# Descriptive name of container. -# -# -# -# -# Verbose description of container and how it fits into the wider -# experimental set up. -# -# -# -# -# Chemical composition of the material the container is made from. -# Specified using CIF conventions. Abbreviated version of CIF -# standard: -# -# * 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. -# -# * This is the *Hill* system used by Chemical Abstracts. -# -# -# -# -# Density of the material the container is made from. -# -# -# -# -# -# -# -# Fraction of the volume of the container occupied by the material -# forming the container. -# -# -# -# -# -# -# Relative molecular mass of container. -# -# -# -# -# -# -# Details of beam incident on container, including the position -# relative to the sample (to determine whether the container is -# upstream or downstream of the sample). -# -# -# -# -# Shape of the container. In combination with orientation this -# should allow the beampath through the container to be modelled to -# allow the adsorption to be calculated. -# -# -# -# -# The angle the container makes to the beam and how it may change -# during the experiment.In combination with shape this should allow -# the beampath through the container to be modelled to allow the -# adsorption of the container to be calculated. -# -# -# -# -# A link to a full data collection which contains the actual -# measured data for this container within the experimental set up -# (with no sample or inner container(s)). This data set will also -# include the wavelength/energy, measurement time and intensity for -# which these data are valid. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml deleted file mode 100644 index 9c0d26edda..0000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ /dev/null @@ -1,116 +0,0 @@ -category: base -doc: | - 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 `_ 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.) - -NXcoordinate_system_set: - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - (NXtransformations): - doc: | - 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. - - # NEW ISSUE: add an illustrated example - - # thoughts on how to use this - # these user-defined frames could be the sample surface, the detector, - # individual frames attached to specific instruments, for instance in an - # atom probe experiment we usually have a lab, specimen surface/apex, laser (pinhole), detector, reconstruction frames - # in electron/focused ion beam, lab, e-beam, i-beam, sample surface, individual frames for each detector - - # THE REMAINING TEXT IS NOT PART OF THE BASE CLASS - # An example follows how each field under transformations can look like - # I would like to encourage a description where each coordinate system is defined - # and for each coordinate system a transformation written down which maps each - # user-defined Frame_i onto Frame_McStas (and maybe for convenience purposes also vice versa - # Frame_McStas = T_i * Frame_i - # if there would be a small python tool that takes a collection of frames - # and does the mapping automatically and writing the respective NeXus entries - # this would be very useful. - - # # \@transformation_type should not be used - # # define frame of reference that is understood as the laboratory coordinate system - # x_axis(NX_NUMBER): - # unit: NX_TRANSFORMATION - # \@depends_on: # "." meaning the root coordinate system, i.e. the McStas - # \@vector(NX_NUMBER): # [1, 0, 0] - # # \@offset(NX_NUMBER): - # y_axis(NX_NUMBER): - # unit: NX_TRANSFORMATION - # \@depends_on: # "." - # \@vector(NX_NUMBER): # [0, 1, 0] - # # \@offset(NX_NUMBER): - # z_axis(NX_NUMBER): - # unit: NX_TRANSFORMATION - # \@depends_on: # "." - # \@vector(NX_NUMBER): # [0, 0, 1] - # \@offset(NX_NUMBER): # is [0, 0, 0] if the origin of the McStas coordinate system and of the laboratory_frame overlap - # # \@offset_units: # should be an NX_LENGTH - # # and how it translates into the McStas convention - # lab_mcstas(NX_NUMBER): - # doc: Rotation matrix which maps the x_axis of the laboratory_frame to the x_axis of the McStas system. - # # BUT as far as I know you cannot define a 3D rotation matrix, you should rather make a chain of transformations - # # each about a single axis and thus building a depends_on chain - # # for example a 4x4 translation with a more-than-one-value-non-zero/non-identity rotation matrix - # # could be you first rotate about Z by R_Z'/R_1 depends_on is x_axis := X, yielding X', Y', Z' - # # second you rotate about the X' by R_X/R_2 depends_on is X', yielding X'', Y'', Z'' - # # third you rotate about the Z'' by R_Z''/R_3 depends_on is then Z'', yielding X''', Y''', Z''' matching McStas, - # # this is the Bunge-Euler way of doing it, but would it also be possible to just define - # # the lab_mcstas(NX_NUMBER) value as an 3x3 array and give the offsets and translations as it is discussed in the manual ? - # unit: NX_ANGLE - # \@depends_on: # x_axis - # # 3x3 rotation matrices are decoupled into three successive planar rotations - # see https://manual.nexusformat.org/classes/base_classes/NXtransformations.html - # mcstas_to_lab(NX_NUMBER): - # # same story but the inverse affine transformation diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml deleted file mode 100644 index 1f2d711ecf..0000000000 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ /dev/null @@ -1,54 +0,0 @@ -category: base -doc: | - Corrector for aberrations in an electron microscope. - - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. -NXcorrector_cs: - applied(NX_BOOLEAN): - doc: Was the corrector used? - name: - doc: Given name/alias. - (NXfabrication): - description: - doc: | - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - # NEW ISSUE: clarify the mathematical details behind the - # NEW ISSUE: following parameters of the these constants and how they are useful - ZEMLIN_TABLEAU(NXprocess): - doc: | - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the microscope. - description: - doc: | - Discouraged free-text field to add further details about the alignment procedure. - tilt_angle(NX_FLOAT): - doc: | - The outer tilt angle of the beam in tableau aquisition. - unit: NX_ANGLE - exposure_time(NX_FLOAT): - doc: | - The exposure time of the single tilt images. - unit: NX_TIME - magnification(NX_NUMBER): - doc: | - The factor of enlargement of the apparent size, - not physical size, of an object. - unit: NX_DIMENSIONLESS - (NXprocess): - doc: | - Place for storing measured or estimated aberrations (for each image or final). - ceos(NXaberration_model_ceos): - nion(NXaberration_model_nion): - - # technical components of the corrector - (NXlens_em): - (NXtransformations): -# NEW ISSUE: add the reference to the conversion table between -# NEW ISSUE: Haider and Krivanek The table [##MK]() is here used for reference. diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml deleted file mode 100644 index 45e2d3ef83..0000000000 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ /dev/null @@ -1,32 +0,0 @@ -category: base -doc: | - Computer science description of a set of computing nodes. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcs_computer: - name: - doc: Given name/alias to the computing system, e.g. MyDesktop. - operating_system: - doc: | - Name of the operating system, e.g. Windows, Linux, Mac, Android. - \@version: - doc: | - 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. - # difference e.g. in Win11 between hardware ID, UUID, and device ID - uuid: - doc: | - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - # when it comes to performance monitoring - (NXcs_cpu): - doc: A list of physical processing units (can be multi-core chips). - (NXcs_gpu): - doc: A list of physical coprocessor/graphic cards/accelerator units. - (NXcs_mm_sys): - doc: Details about the memory sub-system. - (NXcs_io_sys): - doc: Details about the I/O sub-system. diff --git a/contributed_definitions/nyaml/NXcs_cpu.yaml b/contributed_definitions/nyaml/NXcs_cpu.yaml deleted file mode 100644 index ae9b3f8285..0000000000 --- a/contributed_definitions/nyaml/NXcs_cpu.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Computer science description of a central processing unit (CPU) of a computer. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcs_cpu: - name: - doc: Given name of the CPU. Users should be as specific as possible. - (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml deleted file mode 100644 index a43dc803a4..0000000000 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml +++ /dev/null @@ -1,59 +0,0 @@ -category: base -doc: | - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_objs: Number of entries (e.g. number of points or objects). - bitdepth: Number of bits assumed for the container datatype used. - n_total: Length of mask considering the eventual need for padding. -NXcs_filter_boolean_mask: - number_of_objects(NX_UINT): - doc: Number of objects represented by the mask. - unit: NX_UNITLESS - bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - unit: NX_UNITLESS - mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_total]] - identifier(NX_UINT): - doc: | - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - dimensions: - rank: 1 - dim: [[1, n_object]] diff --git a/contributed_definitions/nyaml/NXcs_gpu.yaml b/contributed_definitions/nyaml/NXcs_gpu.yaml deleted file mode 100644 index 67809eb18c..0000000000 --- a/contributed_definitions/nyaml/NXcs_gpu.yaml +++ /dev/null @@ -1,10 +0,0 @@ -category: base -doc: | - Computer science description of a graphic processing unit (GPU) of a computer. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcs_gpu: - name: - doc: Given name of the GPU. Users should be as specific as possible. - (NXfabrication): - diff --git a/contributed_definitions/nyaml/NXcs_io_obj.yaml b/contributed_definitions/nyaml/NXcs_io_obj.yaml deleted file mode 100644 index 78396ac05b..0000000000 --- a/contributed_definitions/nyaml/NXcs_io_obj.yaml +++ /dev/null @@ -1,17 +0,0 @@ -category: base -doc: | - Computer science description of a storage object in an input/output system. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcs_io_obj: - technology: - doc: Qualifier for the type of storage medium used. - enumeration: [solid_state_disk, hard_disk, tape] - # recording technique etc. - max_physical_capacity(NX_NUMBER): - doc: Total amount of data which the medium can hold. - # unit: NX_BIT - name: - doc: Given name to the I/O unit. - (NXfabrication): - diff --git a/contributed_definitions/nyaml/NXcs_io_sys.yaml b/contributed_definitions/nyaml/NXcs_io_sys.yaml deleted file mode 100644 index 5c53610f2f..0000000000 --- a/contributed_definitions/nyaml/NXcs_io_sys.yaml +++ /dev/null @@ -1,7 +0,0 @@ -category: base -doc: | - Computer science description of system of a computer. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcs_io_sys: - (NXcs_io_obj): diff --git a/contributed_definitions/nyaml/NXcs_mm_sys.yaml b/contributed_definitions/nyaml/NXcs_mm_sys.yaml deleted file mode 100644 index a9f310913e..0000000000 --- a/contributed_definitions/nyaml/NXcs_mm_sys.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Computer science description of a main memory system of a computer. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcs_mm_sys: - total_physical_memory(NX_NUMBER): - doc: How much physical memory does the system provide. - # unit: NX_BIT \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcs_prng.yaml b/contributed_definitions/nyaml/NXcs_prng.yaml deleted file mode 100644 index f77ed6b7a8..0000000000 --- a/contributed_definitions/nyaml/NXcs_prng.yaml +++ /dev/null @@ -1,44 +0,0 @@ -category: base -doc: | - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcs_prng: - type: - doc: | - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - enumeration: [physical, system_clock, mt19937, other] - program: - doc: | - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - \@version: - doc: Version and build number, or commit hash. - seed(NX_NUMBER): - doc: | - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - unit: NX_UNITLESS - warmup(NX_NUMBER): - doc: | - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - # reformulate last part of the first sentence. - unit: NX_UNITLESS - # one could add spectral properties but this is usually well documented in the PRNG literature - # one could also think about making reference to the NIST PRNG test suite to qualify the PRNG diff --git a/contributed_definitions/nyaml/NXcs_profiling.yaml b/contributed_definitions/nyaml/NXcs_profiling.yaml deleted file mode 100644 index 748ee5f950..0000000000 --- a/contributed_definitions/nyaml/NXcs_profiling.yaml +++ /dev/null @@ -1,106 +0,0 @@ -category: base -doc: | - Computer science description for summary performance/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 - contributions to performance: - - * Hardware capabilities and configuration - * 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. - - 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. - - 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 - 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. - - This base class cannot and should not replace these specific solutions. - 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 - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXcs_profiling: - # details about queuing systems etc - current_working_directory: - doc: | - Path to the directory from which the tool was called. - command_line_call: - doc: | - Command line call with arguments if applicable. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - total_elapsed_time(NX_NUMBER): - doc: | - 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. - unit: NX_TIME - number_of_processes(NX_POSINT): - doc: | - 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. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - unit: NX_UNITLESS - number_of_threads(NX_POSINT): - doc: | - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - unit: NX_UNITLESS - number_of_gpus(NX_POSINT): - doc: | - Qualifier with how many nominal GPUs the app was invoked at runtime. - unit: NX_UNITLESS - # there are more complicated usage models, where GPUs are activated in - # between runs etc, but here application definition and base class developers - # should feel free to suggest customizations wrt to if and how such more - # complicated models should be captured. - # how can you have an empty list? - (NXcs_computer): - doc: | - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - (NXcs_profiling_event): - doc: | - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. -# how to retrieve UUID for cloud computing instances -# https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html diff --git a/contributed_definitions/nyaml/NXcs_profiling_event.yaml b/contributed_definitions/nyaml/NXcs_profiling_event.yaml deleted file mode 100644 index 8a5eaeb6f7..0000000000 --- a/contributed_definitions/nyaml/NXcs_profiling_event.yaml +++ /dev/null @@ -1,52 +0,0 @@ -category: base -doc: | - Computer science description of a profiling event. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_processes: Number of processes. -NXcs_profiling_event: - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - description: - doc: | - Free-text description what was monitored/executed during the event. - elapsed_time(NX_NUMBER): - doc: | - 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. - Elapsed time may contain time portions where resources were idling. - unit: NX_TIME - number_of_processes(NX_POSINT): - doc: | - Number of processes used (max) during the execution of this event. - unit: NX_UNITLESS - number_of_threads(NX_POSINT): - doc: | - Number of threads used (max) during the execution of this event. - unit: NX_UNITLESS - number_of_gpus(NX_POSINT): - doc: | - Number of GPUs used (max) during the execution of this event. - unit: NX_UNITLESS - max_virtual_memory_snapshot(NX_NUMBER): - doc: | - Maximum amount of virtual memory allocated per process during the event. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_processes]] - max_resident_memory_snapshot(NX_NUMBER): - doc: | - Maximum amount of resident memory allocated per process during the event. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_processes]] diff --git a/contributed_definitions/nyaml/NXcsg.yaml b/contributed_definitions/nyaml/NXcsg.yaml deleted file mode 100644 index e7f408c7a2..0000000000 --- a/contributed_definitions/nyaml/NXcsg.yaml +++ /dev/null @@ -1,119 +0,0 @@ -category: base -doc: | - Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` -type: group -NXcsg(NXobject): - operation: - doc: | - One of the standard construction solid geometry set operations, - or if the CSG is a pointer to the geometry provided by an - :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: - enumeration: [UNION, INTERSECTION, DIFFERENCE, COMPLEMENT, IS_QUADRIC, IS_MESH] - a(NXcsg): - exists: ['min', '0', 'max', '1'] - doc: | - The first operand of constructive solid geometry - operation. Compulsory if 'operation' is UNION, INTERSECTION, - DIFFERENCE or COMPLEMENT. - b(NXcsg): - exists: ['min', '0', 'max', '1'] - doc: | - The second operand of constructive solid geometry - operation. Compulsory if 'operation' is UNION, INTERSECTION or - DIFFERENCE. - geometry(NX_CHAR): - exists: ['min', '0', 'max', '1'] - doc: | - Path to a field that is either an :ref:`NXquadric` (if - 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if - 'operation' = IS_MESH) that defines the surface making up the - constructive solid geometry component. Compulsory if 'operation' - is IS_QUADRIC or IS_MESH. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 26b9cbb33ac382f8758dc8bda210c12a550d888e5d33c1a0e662e9671d2788db -# -# -# -# -# -# Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` -# -# -# One of the standard construction solid geometry set operations, -# or if the CSG is a pointer to the geometry provided by an -# :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: -# -# -# -# -# -# -# -# -# -# -# -# -# The first operand of constructive solid geometry -# operation. Compulsory if 'operation' is UNION, INTERSECTION, -# DIFFERENCE or COMPLEMENT. -# -# -# -# -# The second operand of constructive solid geometry -# operation. Compulsory if 'operation' is UNION, INTERSECTION or -# DIFFERENCE. -# -# -# -# -# Path to a field that is either an :ref:`NXquadric` (if -# 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if -# 'operation' = IS_MESH) that defines the surface making up the -# constructive solid geometry component. Compulsory if 'operation' -# is IS_QUADRIC or IS_MESH. -# -# -# diff --git a/contributed_definitions/nyaml/NXcxi_ptycho.yaml b/contributed_definitions/nyaml/NXcxi_ptycho.yaml deleted file mode 100644 index 1b68b54452..0000000000 --- a/contributed_definitions/nyaml/NXcxi_ptycho.yaml +++ /dev/null @@ -1,440 +0,0 @@ -category: application -doc: | - Application definition for a ptychography experiment, compatible with CXI from version 1.6. - - This is compatible with CXI from version 1.6 if this application definition - is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important - to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, - with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. - - An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths - with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). -symbols: - doc: | - These symbols will be used below to coordinate the shapes of the datasets. - npts_x: | - The number of points in the x direction - npts_y: | - Number of points in the y direction. - frame_size_x: | - Number of detector pixels in x - frame_size_y: | - Number of detector pixels in y -type: group -NXcxi_ptycho(NXobject): - (NXentry)entry_1: - title: - exists: ['min', '0', 'max', '1'] - start_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - end_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - definition(NX_CHAR): - exists: ['min', '1', 'max', '1'] - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXcxi_ptycho] - (NXinstrument)instrument_1: - exists: ['min', '1', 'max', '1'] - (NXsource)source_1: - exists: ['min', '1', 'max', '1'] - name(NX_CHAR): - exists: ['min', '1', 'max', '1'] - energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - doc: | - This is the energy of the machine, not the beamline. - probe(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - type(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - (NXbeam)beam_1: - exists: ['min', '1', 'max', '1'] - energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - extent(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - incident_beam_divergence(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - incident_beam_energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - incident_energy_spread(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - (NXdetector)detector_1: - exists: ['min', '1', 'max', '1'] - \@axes: - type: NX_CHAR - doc: | - should have value "[, data]" - \@signal: - type: NX_CHAR - doc: | - should have value "data" - (NXtransformations)transformations: - vector(NX_NUMBER): - exists: ['min', '1', 'max', '1'] - translation(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1', 'max', '1'] - doc: | - This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y - \@units: - type: NX_CHAR - exists: optional - \@axes: - exists: optional - type: NX_CHAR - doc: | - this should take the value "translation:$slowaxisname:$fastaxisname" - \@interpretation: - exists: optional - type: NX_CHAR - doc: | - This should be "image" - data(NX_INT): - signal: 1 - exists: ['min', '1', 'max', '1'] - dimensions: - rank: 3 for arbitrary scan, 4 for raster - dim: [[1, npts_x], [2, npts_y], [3, frame_size_x], [4, frame_size_y]] - data_1(link): - target: /NXentry/NXinstrument/NXdetector/data - doc: | - This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless - of the scan pattern. Use hdf5 virtual dataset to achieve this. - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1', 'max', '1'] - doc: | - The distance between the detector and the sample - \@units: - type: NX_CHAR - exists: optional - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - (NXmonitor): - exists: ['min', '0', 'max', '1'] - data(NX_FLOAT): - dimensions: - rank: 1 for arbitrary scan, 2 for raster - dim: [[1, npts_x], [2, npts_y]] - (NXdata): - exists: ['min', '1', 'max', '1'] - \@axes: - type: NX_CHAR - exists: optional - doc: | - This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster - \@signal: - type: NX_CHAR - exists: optional - doc: | - This should be "data" - data(link): - target: /NXentry/NXinstrument/NXdetector/data - x(link): - target: /NXentry/NXsample/NXtransformations/x - y(link): - target: /NXentry/NXsample/NXtransformations/y - x_indices(NX_CHAR): - y_indices(NX_CHAR): - (NXcollection)data_1: - exists: ['min', '1', 'max', '1'] - doc: | - To ensure CXI compatibility the data in this group must always have shape that is - (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that - hdf5 virtual dataset is used. - data(link): - target: /NXentry/NXinstrument/NXdetector/data - translation(link): - target: /NXentry/NXinstrument/NXdetector/translation - (NXsample)sample_1: - exists: ['min', '1', 'max', '1'] - name(NX_CHAR): - exists: ['min', '0', 'max', '1'] - transformations(NXtransformations): - doc: | - This must contain two fields with the x and y motors that are linked via the - dependency tree according to the real-life motor layout dependency. - For raster scans x and y will have shape (npts_x, npts_y) - For arbitrary scans x and y will be (npts_x*npts_y,) - An attribute with the units for each motor is required. - \@vector: - exists: optional - type: NX_NUMBER - (NXcollection)geometry_1: - exists: ['min', '1', 'max', '1'] - translation(link): - target: /NXentry/NXinstrument/NXdetector/translation - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cc83e17501fdd8eab38f6229fd41422c15a196db1698921004af9d9736c9cb83 -# -# -# -# -# -# -# These symbols will be used below to coordinate the shapes of the datasets. -# -# -# -# -# The number of points in the x direction -# -# -# -# -# -# Number of points in the y direction. -# -# -# -# -# Number of detector pixels in x -# -# -# -# -# -# Number of detector pixels in y -# -# -# -# -# -# Application definition for a ptychography experiment, compatible with CXI from version 1.6. -# -# This is compatible with CXI from version 1.6 if this application definition -# is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important -# to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, -# with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. -# -# An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths -# with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). -# -# -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# This is the energy of the machine, not the beamline. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# should have value "[, data]" -# -# -# -# -# should have value "data" -# -# -# -# -# -# -# -# This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y -# -# -# -# -# this should take the value "translation:$slowaxisname:$fastaxisname" -# -# -# -# -# This should be "image" -# -# -# -# -# -# -# -# -# -# -# -# -# -# This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless -# of the scan pattern. Use hdf5 virtual dataset to achieve this. -# -# -# -# -# -# -# -# -# -# -# The distance between the detector and the sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster -# -# -# -# -# This should be "data" -# -# -# -# -# -# -# -# -# -# -# To ensure CXI compatibility the data in this group must always have shape that is -# (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that -# hdf5 virtual dataset is used. -# -# -# -# -# -# -# -# -# -# This must contain two fields with the x and y motors that are linked via the -# dependency tree according to the real-life motor layout dependency. -# For raster scans x and y will have shape (npts_x, npts_y) -# For arbitrary scans x and y will be (npts_x*npts_y,) -# An attribute with the units for each motor is required. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXdac.yaml b/contributed_definitions/nyaml/NXdac.yaml deleted file mode 100644 index b8fb0aa99c..0000000000 --- a/contributed_definitions/nyaml/NXdac.yaml +++ /dev/null @@ -1,10 +0,0 @@ -category: base -doc: | - Digital-to-analog converter component/integrated circuit. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXdac: - value(NX_NUMBER): - doc: | - TBD. - unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXdeflector.yaml b/contributed_definitions/nyaml/NXdeflector.yaml deleted file mode 100644 index 32c8e0ccce..0000000000 --- a/contributed_definitions/nyaml/NXdeflector.yaml +++ /dev/null @@ -1,27 +0,0 @@ -category: base -doc: "Deflectors as they are used e.g. in an electron analyser." -NXdeflector: - type: - doc: "Qualitative type of deflector with respect to the number of pole pieces" - enumeration: ["dipole", "quadrupole", "hexapole", "octupole"] - name: - doc: "Colloquial or short name for the deflector. For manufacturer names and identifiers use respective manufacturer fields." - manufacturer_name: - doc: "Name of the manufacturer who built/constructed the deflector." - manufacturer_model: - doc: "Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the deflector." - description: - doc: "Ideally an identifier, persistent link, or free text which gives further details about the deflector." - voltage(NX_NUMBER): - doc: "Excitation voltage of the deflector. For dipoles it is a single number. For higher orders, it is an array." - unit: NX_VOLTAGE - current(NX_NUMBER): - doc: "Excitation current of the deflector. For dipoles it is a single number. For higher orders, it is an array." - unit: NX_CURRENT - depends_on(NX_CHAR): - doc: "Specifies the position of the deflector by pointing to the last transformation in the transformation chain in the NXtransformations group." - (NXtransformations): - doc: "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 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/nyaml/NXdelocalization.yaml b/contributed_definitions/nyaml/NXdelocalization.yaml deleted file mode 100644 index 0a3d48f4d3..0000000000 --- a/contributed_definitions/nyaml/NXdelocalization.yaml +++ /dev/null @@ -1,83 +0,0 @@ -category: base -doc: | - Base class to describe the delocalization of point-like objects on a grid. - - Such a procedure is for instance used in image processing and e.g. atom probe - microscopy (APM) to discretize a point cloud onto a grid to enable e.g. - computing of point density, composition, or concentration values, obtain - scalar fields, and compute gradients of these fields. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_p: Number of points/objects. - n_m: Number of mark data per point/object. - n_atoms: Number of atoms in the whitelist. - n_isotopes: Number of isotopes in the whitelist. -NXdelocalization: - grid: - doc: Reference or link to the grid on which the delocalization is applied. - objects: - doc: Reference or link to the points which are delocalized on the grid. - # for APM the speciality is nothing but: - # each point marks the location of an ion (object) in the tomographic reconstruction - # there is a boolean mask which filters which ions, i.e. points are considered - # plus there is a weight interpretation model, specifically in atom probe - # if a (molecular) ion is decomposed into its atoms or isotopes - # plus, given there is such a weight interpretation model, there is a weight - # associated, specifically an integer >= 1 with each considered ion and 0 for - # all ions which are not considered, - # this weight is the multiplicity with respect to the interpretation model - # i.e. a C:2 molecular ion has a multiplicity of 2 if the ion is considered - # and the interpretation model that to consider carbon atoms or carbon ions - weighting_model: - doc: | - The weighting model specifies how mark data are mapped to a weight per point. - For atom probe microscopy (APM) as an example, different models are used which - account differently for the multiplicity of an ion/atom: - - * default, points all get the same weight 1.; - for APM this is equivalent to ion species - * atomic_decomposition, points get as much weight as they have atoms - of a type in element_whitelist, - * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotope_whitelist. - - This description shows an example that could be reinterpreted for - similar such data processing steps in other fields of science. - enumeration: [default, atomic_decomposition, isotope_decomposition] - # other - # can one conditionally set a field required if a weighting_model has a - # specific value, - # i.e. if atomic_decomposition is set element_whitelist t is required - # i.e. if isotope_decomposition is set isotope_whitelist is required? - element_whitelist(NX_UINT): # optional for atom probe - doc: | - A list of elements (via proton number) to consider for the atomic_decomposition - weighting model. Elements must exist in the periodic table of elements. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_atoms]] - isotope_whitelist(NX_UINT): # optional for atom probe - doc: | - A list of isotopes to consider for the isotope_decomposition weighting model. - Isotopes must exist in the nuclid table. Entries in the fastest changing - dimension should be the pair of proton (first entry) and neutron number - (second entry). - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_isotopes], [2, 2]] - mark(NX_NUMBER): - doc: | - Attribute data for each member of the point cloud. For APM these are the - ion species labels generated via ranging. The number of mark data per - point is 1 in the case for atom probe. - dimensions: - rank: 2 - dim: [[1, n_p], [2, n_m]] - weight(NX_NUMBER): - doc: | - Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point. For APM the weight are positive - integer values, specifically the multiplicity of the ion, - according to the details of the weighting_model. diff --git a/contributed_definitions/nyaml/NXdispersion.yaml b/contributed_definitions/nyaml/NXdispersion.yaml deleted file mode 100644 index 963d7b12b3..0000000000 --- a/contributed_definitions/nyaml/NXdispersion.yaml +++ /dev/null @@ -1,11 +0,0 @@ -category: base -doc: | - A dispersion denoting a sum of different dispersions. - All NXdispersion_table and NXdispersion_function groups will be added together - to form a single dispersion. -NXdispersion: - model_name(NX_CHAR): - doc: | - The name of the composite model. - (NXdispersion_table): - (NXdispersion_function): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_function.yaml b/contributed_definitions/nyaml/NXdispersion_function.yaml deleted file mode 100644 index e197e3f507..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_function.yaml +++ /dev/null @@ -1,73 +0,0 @@ -category: base -doc: | - This describes a dispersion function for a material or layer -symbols: - n_repetitions: | - The number of repetitions for the repeated parameters -NXdispersion_function: - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - formula(NX_CHAR): - doc: | - This should be a python parsable function. - Here we should provide which keywords are available - and a BNF of valid grammar. - convention(NX_CHAR): - doc: | - The sign convention being used (n + or - ik) - enumeration: ["n + ik", "n - ik"] - energy_identifier(NX_CHAR): - doc: | - The identifier used to represent energy - in the formula. It is recommended to use `E`. - energy_min(NX_NUMBER): - doc: | - The minimum energy value at which this formula is valid. - unit: NX_ENERGY - energy_max(NX_NUMBER): - doc: | - The maximum energy value at which this formula is valid. - unit: NX_ENERGY - energy_unit(NX_NUMBER): - doc: | - The energy unit used in the formula. - The field value is a scaling factor for the units attribute. - It is recommeded to set the field value to 1 and carry all the unit - scaling information in the units attribute. - unit: NX_ENERGY - wavelength_identifier(NX_CHAR): - doc: | - The identifier useed to represent wavelength - in the formula. It is recommended to use `lambda`. - wavelength_unit(NX_NUMBER): - doc: | - The wavelength unit used in the formula. - The field value is a scaling factor for the units attribute. - It is recommeded to set the field value to 1 and carry all the unit - scaling information in the units attribute. - unit: NX_LENGTH - wavelength_min(NX_NUMBER): - doc: | - The minimum wavelength value at which this formula is valid. - unit: NX_LENGTH - wavelength_max(NX_NUMBER): - doc: | - The maximum wavelength value at which this formula is valid. - unit: NX_LENGTH - representation(NX_CHAR): - doc: | - Which representation does the formula evaluate to. - This may either be n for refractive index or eps for dielectric function. - The appropriate token is then to be used inside the formula. - enumeration: [n, eps] - (NXdispersion_single_parameter): - (NXdispersion_repeated_parameter): - parameter_units: - dimensions: - rank: 1 - dim: [[1, n_repetitions]] - values(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_repetitions]] diff --git a/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml b/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml deleted file mode 100644 index 80b6e55178..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml +++ /dev/null @@ -1,30 +0,0 @@ -category: base -doc: | - A repeated parameter for a dispersion function -symbols: - n_repetitions: | - The number of parameter repetitions -NXdispersion_repeated_parameter: - name(NX_CHAR): - doc: | - The name of the parameter - description(NX_CHAR): - doc: | - A description of what this parameter represents - parameter_units(NX_CHAR): - doc: | - A unit array associating a unit with each parameter. - The first element should be equal to values/@unit. - The values should be SI interpretable standard units - with common prefixes (e.g. mikro, nano etc.) or their - short-hand notation (e.g. nm, mm, kHz etc.). - dimensions: - rank: 1 - dim: [[1, n_repetitions]] - values(NX_NUMBER): - doc: | - The value of the parameter - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_repetitions]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml b/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml deleted file mode 100644 index 571edf0464..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml +++ /dev/null @@ -1,14 +0,0 @@ -category: base -doc: | - A single parameter for a dispersion function -NXdispersion_single_parameter: - name(NX_CHAR): - doc: | - The name of the parameter - description(NX_CHAR): - doc: | - A description of what this parameter represents - value(NX_NUMBER): - doc: | - The value of the parameter - unit: NX_ANY \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_table.yaml b/contributed_definitions/nyaml/NXdispersion_table.yaml deleted file mode 100644 index 0c691a5fa6..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_table.yaml +++ /dev/null @@ -1,48 +0,0 @@ -category: base -doc: | - A dispersion table denoting energy, dielectric function tabulated values. -symbols: - doc: | - The symbols in this schema to denote the dimensions - n_points: | - The number of energy and dielectric function points -NXdispersion_table: - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - convention(NX_CHAR): - doc: | - The sign convention being used (n + or - ik) - enumeration: ['n + ik', 'n - ik'] - wavelength(NX_NUMBER): - doc: | - The wavelength array of the tabulated dataset. - This is essentially a duplicate of the energy field. - There should be one or both of them present. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_points]] - energy(NX_NUMBER): - doc: | - The energy array of the tabulated dataset. - This is essentially a duplicate of the wavelength field. - There should be one or both of them present. - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_points]] - refractive_index(NX_COMPLEX): - doc: | - The refractive index array of the tabulated dataset. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_points]] - dielectric_function(NX_COMPLEX): - doc: | - The dielectric function of the tabulated dataset. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_points]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersive_material.yaml b/contributed_definitions/nyaml/NXdispersive_material.yaml deleted file mode 100644 index 16613789ce..0000000000 --- a/contributed_definitions/nyaml/NXdispersive_material.yaml +++ /dev/null @@ -1,177 +0,0 @@ -category: application -doc: | - NXdispersion -NXdispersive_material: - (NXentry): - definition: - doc: "An application definition for a dispersive material." - \@version: - doc: "Version number to identify which definition of this application - definition was used for this entry/data." - \@url: - doc: "URL where to find further material (documentation, examples) - relevant to the application definition" - enumeration: [NXdispersive_material] - sample(NXsample): - chemical_formula(NX_CHAR): - atom_types(NX_CHAR): - exists: optional - doc: | - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - colloquial_name(NX_CHAR): - exists: optional - doc: | - The colloquial name of the material, e.g. graphite or diamond for carbon. - material_phase(NX_CHAR): - exists: optional - doc: | - The phase of the material - enumeration: [gas, liquid, solid, other] - material_phase_comment(NX_CHAR): - exists: optional - doc: | - Additional information about the phase if the - material phase is other. - additional_phase_information(NX_CHAR): - exists: recommended - doc: | - This field may be used to denote additional phase information, - such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or - if a measurement was done on a thin film or bulk material. - dispersion_type(NX_CHAR): - exists: recommended - doc: | - Denotes whether the dispersion is calculated or derived from an experiment - enumeration: ["measured", "simulated"] - REFERENCES(NXcite): - exists: recommended - text: - doc: | - A text description of this reference, e.g. - `E. Example et al, The mighty example, An example journal 50 (2023), 100` - doi: - dispersion_x(NXdispersion): - doc: | - The dispersion along the optical axis of the material. - This should be the only dispersion available for isotropic materials. - For uniaxial materials this denotes the ordinary axis. - For biaxial materials this denotes the x axis or epsilon 11 tensor element - of the diagionalized permittivity tensor. - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - (NXdispersion_table): - exists: recommended - model_name: - convention: - wavelength(NX_NUMBER): - dielectric_function(NX_COMPLEX): - exists: recommended - refractive_index(NX_COMPLEX): - exists: recommended - (NXdispersion_function): - exists: recommended - model_name: - formula: - convention: - energy_identifier: - exists: recommended - energy_unit(NX_NUMBER): - exists: recommended - wavelength_identifier: - exists: recommended - wavelength_unit(NX_NUMBER): - exists: recommended - representation: - (NXdispersion_single_parameter): - name: - value(NX_NUMBER): - (NXdispersion_repeated_parameter): - name: - values(NX_NUMBER): - plot(NXdata): - exists: recommended - dispersion_y(NXdispersion): - doc: | - This should only be filled for biaxial materials. - It denotes the epsilon 22 direction of the diagionalized - permittivity tensor. - exists: optional - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - (NXdispersion_table): - exists: recommended - model_name: - convention: - wavelength(NX_NUMBER): - dielectric_function(NX_COMPLEX): - exists: recommended - refractive_index(NX_COMPLEX): - exists: recommended - (NXdispersion_function): - exists: recommended - model_name: - formula: - convention: - energy_identifier: - exists: recommended - energy_unit(NX_NUMBER): - exists: recommended - wavelength_identifier: - exists: recommended - wavelength_unit(NX_NUMBER): - exists: recommended - representation: - (NXdispersion_single_parameter): - name: - value(NX_NUMBER): - (NXdispersion_repeated_parameter): - name: - values(NX_NUMBER): - plot(NXdata): - exists: recommended - dispersion_z(NXdispersion): - doc: | - This should only be filled for uniaxial or biaxial materials. - For uniaxial materials this denotes the extraordinary axis. - For biaxial materials this denotes the epsilon 33 tensor element - of the diagionalized perimittivty tensor. - exists: optional - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - (NXdispersion_table): - exists: recommended - model_name: - convention: - wavelength(NX_NUMBER): - dielectric_function(NX_COMPLEX): - exists: recommended - refractive_index(NX_COMPLEX): - exists: recommended - (NXdispersion_function): - exists: recommended - model_name: - formula: - convention: - energy_identifier: - exists: recommended - energy_unit(NX_NUMBER): - exists: recommended - wavelength_identifier: - exists: recommended - wavelength_unit(NX_NUMBER): - exists: recommended - representation: - (NXdispersion_single_parameter): - name: - value(NX_NUMBER): - (NXdispersion_repeated_parameter): - name: - values(NX_NUMBER): - plot(NXdata): - exists: recommended diff --git a/contributed_definitions/nyaml/NXdistortion.yaml b/contributed_definitions/nyaml/NXdistortion.yaml deleted file mode 100644 index 072e47e46a..0000000000 --- a/contributed_definitions/nyaml/NXdistortion.yaml +++ /dev/null @@ -1,54 +0,0 @@ -category: base -symbols: - doc: "The symbols used in the schema to specify e.g. dimensions of arrays" - nsym: "Number of symmetry points used for distortion correction" - ndx: "Number of points of the matrix distortion field (x direction)" - ndy: "Number of points of the matrix distortion field (y direction)" -doc: "Subclass of NXprocess to describe post-processing distortion correction." -NXdistortion: - last_process(NX_CHAR): - doc: "Indicates the name of the last operation applied in the NXprocess sequence." - applied(NX_BOOLEAN): - doc: "Has the distortion correction been applied?" - symmetry(NX_INT): - doc: | - For `symmetry-guided distortion correction`_, - where a pattern of features is mapped to the regular geometric structure expected - from the symmetry. Here we record the number of elementary symmetry operations. - - .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub - unit: NX_UNITLESS - original_centre(NX_FLOAT): - doc: - "For symmetry-guided distortion correction. Here we record the coordinates - of the symmetry centre point." - unit: NX_UNITLESS - dimensions: - dim: [[1, 2]] - rank: 1 - original_points(NX_FLOAT): - doc: - "For symmetry-guided distortion correction. Here we record the coordinates of - the relevant symmetry points." - unit: NX_UNITLESS - dimensions: - dim: [[1, nsym], [2, 2]] - rank: 2 - cdeform_field(NX_FLOAT): - doc: - "Column deformation field for general non-rigid distortion corrections. 2D matrix holding - the column information of the mapping of each original coordinate." - unit: NX_UNITLESS - dimensions: - dim: [[1, ndx], [2, ndy]] - rank: 2 - rdeform_field(NX_FLOAT): - doc: - "Row deformation field for general non-rigid distortion corrections. 2D matrix holding - the row information of the mapping of each original coordinate." - unit: NX_UNITLESS - dimensions: - dim: [[1, ndx], [2, ndy]] - rank: 2 - description(NX_CHAR): - doc: "Description of the procedures employed." diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml deleted file mode 100644 index b34479c5c6..0000000000 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ /dev/null @@ -1,55 +0,0 @@ -category: base -doc: | - Container for components to form a controlled beam in electron microscopy. -# symbols: -# doc: The symbols used in the schema to specify e.g. variables. -NXebeam_column: - (NXfabrication): - electron_source(NXsource): - doc: The source which creates the electron beam. - name: - doc: Given name/alias. - (NXfabrication): - voltage(NX_FLOAT): - doc: | - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - unit: NX_VOLTAGE - probe: - doc: Type of radiation. - enumeration: [electron] - emitter_type: - doc: | - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - enumeration: [filament, schottky, cold_cathode_field_emitter, other] - emitter_material: - doc: Material of which the emitter is build, e.g. the filament material. - ##MK could be made an instance of NXsample - description: - doc: | - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - # NEW ISSUE: details about the life/up-time of the source - # relevant from maintenance point of view - (NXtransformations): - doc: | - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - (NXaperture_em): - (NXlens_em): - (NXcorrector_cs): - # ebeam_deflector(NXscan_box_em): - (NXstage_lab): - (NXsensor): - doc: | - A sensor used to monitor an external or internal condition. - (NXbeam): - doc: | - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml deleted file mode 100644 index 11e8274857..0000000000 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ /dev/null @@ -1,74 +0,0 @@ -category: base -doc: "Subclass of NXinstrument to describe a photoelectron analyser." -symbols: - doc: "The symbols used in the schema to specify e.g. dimensions of arrays" - nfa: "Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity)" - nsa: "Number of slow axes (axes acquired scanning a pysical quantity)" -NXelectronanalyser: - description(NX_CHAR): - doc: "Free text description of the type of the detector " - name(NX_CHAR): - doc: "Name or model of the equipment" - \@short_name(NX_CHAR): - doc: "Acronym or other shorthand name" - energy_resolution(NX_FLOAT): - doc: "Energy resolution of the electron analyser (FWHM of gaussian broadening)" - unit: NX_ENERGY - momentum_resolution(NX_FLOAT): - doc: "Momentum resolution of the electron analyser (FWHM)" - unit: NX_WAVENUMBER - angular_resolution(NX_FLOAT): - doc: "Angular resolution of the electron analyser (FWHM)" - unit: NX_ANGLE - spatial_resolution(NX_FLOAT): - doc: "Spatial resolution of the electron analyser (Airy disk radius)" - unit: NX_LENGTH - fast_axes(NX_CHAR): - doc: | - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - dimensions: - dim: [[1, nfa]] - rank: 1 - slow_axes(NX_CHAR): - doc: - "List of the axes that are acquired by scanning a physical parameter, listed - in order of decreasing speed. See fast_axes for examples." - dimensions: - dim: [[1, nsa]] - rank: 1 - depends_on(NX_CHAR): - doc: "Refers to the last transformation specifying the positon of the manipulator in the NXtransformations chain." - (NXtransformations): - doc: - "Collection of axis-based translations and rotations to describe the location and geometry of the electron analyser 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." - (NXcollectioncolumn): - doc: - "Describes the electron collection (spatial and momentum imaging) - column" - (NXenergydispersion): - doc: "Describes the energy dispersion section" - (NXspindispersion): - doc: "Describes the spin dispersion section" - (NXdetector): - doc: "Describes the electron detector" - (NXdeflector): - doc: "Deflectors outside the main optics ensambles described by the subclasses" - (NXlens_em): - doc: "Individual lenses outside the main optics ensambles described by the subclasses" diff --git a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml deleted file mode 100644 index 821e7c9324..0000000000 --- a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml +++ /dev/null @@ -1,105 +0,0 @@ -category: base -doc: | - definition for a electrostatic kicker. -type: group -NXelectrostatic_kicker(NXobject): - description(NX_CHAR): - doc: | - extended description of the kicker. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - timing(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0', 'max', '1'] - doc: | - kicker timing as defined by ``description`` attribute - \@description: - type: NX_CHAR - set_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on supply. - read_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from supply. - value: - unit: NX_CURRENT - set_voltage(NX_FLOAT): - unit: NX_VOLTAGE - exists: ['min', '0', 'max', '1'] - doc: | - volage set on supply. - read_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8bc323e93c7d175eab0c362d716d4ca617041ffaf2f420a386d92ab7cb75d595 -# -# -# -# -# definition for a electrostatic kicker. -# -# extended description of the kicker. -# -# -# define position of beamline element relative to production target -# -# -# kicker timing as defined by ``description`` attribute -# -# -# -# current set on supply. -# -# -# current read from supply. -# -# -# -# volage set on supply. -# -# -# voltage read from supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml deleted file mode 100644 index d5d4651628..0000000000 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ /dev/null @@ -1,265 +0,0 @@ -# 06/2022 -# A draft version of a NeXus application definition for ellipsometry. - -# The document has the following main elements: -# - Instrument used and is characteristics -# - Sample: Properties of the sample -# - Data: measured data, data errors -# - Derived parameters: e.g. extra parameters derived in the measurement software - -category: application -doc: | - Ellipsometry, complex systems, up to variable angle spectroscopy. - - Information on ellipsometry is provided, e.g. in: - - * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, - John Wiley & Sons, 2007. - * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, - North-Holland Publishing Company, 1977. - * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, - William Andrew, 2005. - - Open access sources: - - * https://www.angstromadvanced.com/resource.asp - * https://pypolar.readthedocs.io/en/latest/ - - Review articles: - - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", - J. Phys. D: Appl. Phys. 32, R45 (1999), - https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", - Thin Solid Films 571, 334-344 (2014), - https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", - Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, - (3 October 1997), - https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", - Thin Solid Films 233, 96-111 (1993), - https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", - Adv. Opt. Techn., (2022), - https://doi.org/10.1515/aot-2022-0016 - -# symbols: -# doc: "Variables used throughout the document, e.g. dimensions and important parameters" -# N_wavelength: "Size of the energy or wavelength vector used, the length of -# NXinstrument/spectrometer/wavelength array" -# N_variables: "How many variables are saved in a measurement. e.g. 2 for Psi -# and Delta, 16 for Mueller matrix elements, 15 for normalized -# Mueller matrix, 3 for NCS, the length of NXsample/column_names" -# N_angles: "Number of incident angles used, the length of -# NXinstrument/angle_of_incidence array" - -# N_p1: -# "Number of sample parameters scanned, if you varied any of the parameters -# such as temperature, pressure, or pH, the maximal length of the arrays -# specified by NXsample/environment_conditions/SENSOR/value if it exists." -# N_time: "Number of time points measured, the length of NXsample/time_points" -symbols: - doc: Variables used throughout the document, e.g. dimensions or parameters. - N_spectrum: | - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - N_sensors: | - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. - N_measurements: | - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - N_detection_angles: | - Number of detection angles of the beam reflected or scattered off the - sample. - N_incident_angles: Number of angles of incidence of the incident beam. - N_observables: | - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - N_time: "Number of time points measured, the length of NXsample/time_points" - -NXellipsometry(NXopt): - (NXentry): - doc: | - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition defines: - - * elements of the experimental instrument - * calibration information if available - * parameters used to tune the state of the sample - * sample description - - definition: - doc: An application definition for ellipsometry. - \@version: - doc: | - Version number to identify which definition of this application - definition was used for this entry/data. - \@url: - doc: | - URL where to find further material (documentation, examples) relevant - to the application definition. - enumeration: [NXellipsometry] - experiment_description: - doc: | - An optional free-text description of the experiment. - - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description. - experiment_type: - doc: Specify the type of ellipsometry. - enumeration: - [ - in situ spectroscopic ellipsometry, - THz spectroscopic ellipsometry, - infrared spectroscopic ellipsometry, - ultraviolet spectroscopic ellipsometry, - uv-vis spectroscopic ellipsometry, - NIR-Vis-UV spectroscopic ellipsometry, - imaging ellipsometry - ] - - (NXinstrument): - doc: Properties of the ellipsometry equipment. - company: - exists: optional - doc: Name of the company which build the instrument. - construction_year(NX_DATE_TIME): - exists: optional - doc: | - ISO8601 date when the instrument was constructed. - UTC offset should be specified. - software(NXprocess): - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and metadata. - This program converts the measured signals to ellipsometry data. If - home written, one can provide the actual steps in the NOTE subfield - here. - ellipsometer_type: - doc: What type of ellipsometry was used? See Fujiwara Table 4.2. - enumeration: - [ - rotating analyzer, - rotating analyzer with analyzer compensator, - rotating analyzer with polarizer compensator, - rotating polarizer, - rotating compensator on polarizer side, - rotating compensator on analyzer side, - modulator on polarizer side, - modulator on analyzer side, - dual compensator, - phase modulation, - imaging ellipsometry, - null ellipsometry, - ] - rotating_element_type: - doc: Define which element rotates, e.g. polarizer or analyzer. - enumeration: - [ - polarizer (source side), - analyzer (detector side), - compensator (source side), - compensator (detector side), - ] - (NXbeam_path): - light_source(NXsource): - doc: Specify the used light source. Multiple selection possible. - source_type: - enumeration: [arc lamp, halogen lamp, LED, other] - focussing_probes(NXlens_opt): - exists: optional - doc: | - If focussing probes (lenses) were used, please state if the data - were corrected for the window effects. - data_correction(NX_BOOLEAN): - doc: | - Were the recorded data corrected by the window effects of the - focussing probes (lenses)? - angular_spread(NX_NUMBER): - exists: recommended - doc: Specify the angular spread caused by the focussing probes. - unit: NX_ANGLE - (NXdetector): - doc: | - Properties of the detector used. Integration time is the count time - field, or the real time field. See their definition. - rotating_element(NXwaveplate): - exists: optional - doc: | - Properties of the rotating element defined in - 'instrument/rotating_element_type'. - revolutions(NX_NUMBER): - exists: optional - doc: | - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. - unit: NX_COUNT - fixed_revolutions(NX_NUMBER): - exists: optional - doc: | - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). - unit: NX_COUNT - max_revolutions(NX_NUMBER): - exists: optional - doc: | - Specify the maximum value of revolutions of the rotating element - for each measurement. - unit: NX_COUNT - spectrometer(NXmonochromator): - exists: optional - doc: | - The spectroscope element of the ellipsometer before the detector, - but often integrated to form one closed unit. Information on the - dispersive element can be specified in the subfield GRATING. Note - that different gratings might be used for different wavelength - ranges. The dispersion of the grating for each wavelength range can - be stored in grating_dispersion. - - (NXsample): - backside_roughness(NX_BOOLEAN): - doc: | - Was the backside of the sample roughened? Relevant for infrared - ellipsometry. - - data_collection(NXprocess): - data_type: - doc: | - Select which type of data was recorded, for example Psi and Delta - (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). - It is possible to have multiple selections. Data types may also be - converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. This selection defines how many columns (N_observables) are - stored in the data array. - enumeration: - [ - Psi/Delta, - tan(Psi)/cos(Delta), - Mueller matrix, - Jones matrix, - N/C/S, - raw data, - ] - # column_names: - # doc: | - # Please list in this array the column names used in your actual data. - # That is ['Psi', 'Delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for - # a full Mueller matrix, etc. - # dimensions: - # rank: 1 - # dim: [[1, N_observables]] diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml deleted file mode 100644 index 8bce61967d..0000000000 --- a/contributed_definitions/nyaml/NXem.yaml +++ /dev/null @@ -1,2538 +0,0 @@ -category: application -doc: | - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of an embracing data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **An embracing schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and especially vocabulary in use with implementations of these - into many data and file formats. There is nothing which prevents the communities - to make these schemas open and interoperable. Open here means not that all - data stored according to such schemas have to end up in the open-source domain. - There can be embargo periods first of all. - - Open means that the metadata and associated schemata are documented in a manner - that as many details are open as possible in the sense that others can understand - what the (meta)data mean conceptually. Instead of trying of maintain a zoo - of eventually difficult to make interoperable formats and schema we would like - to advocate that the `FAIR principles `_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. `_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. Strictly speaking an application definition can only be - fully general if it does not make a single entry required, in which case however - it would also not offer much value as even empty datasets would be compliant - with such a schema. - - **Verification of constraints and conditions**: - Tools like NeXus so far do not avoid or protect against all such possible - inconsistencies; however NeXus offers a mechanism and toolset, through which - schemas can be documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Generic experimental details (time-zone-aware timestamp, identifiers, name); - conceptually these are session details. A session at a microscope may - involve the characterization of multiple specimens. For each specimen - an instance of an (NXentry) is created. Details of the instrument have to - be stored at least in an entry. Other entries should refer to these - metadata via links to reduce redundancies. - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have an own em_lab section. - The reason is that EMs can be highly dynamic, be used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, conceptually, this is a place for documenting - available default plottable data. A default plottable can be useful for - research data management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables not intended to serve every possible analysis and - visualization demand but be a preview. We made this choice because what - constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables to - display image and spectra with web technology visualization software. - NeXus specifies only the data model, i.e. the terms and their relations. - These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, - file storage, or even other formats, although HDF5 is often used. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional XDMF fields which support additional plotting of - the data with visualization software like Paraview or Blender. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images of electron counts detected in specific operation modes (bright - field, dark field in TEM, secondary/back-scattered, Kikuchi). - * Spectra (X-ray quanta or Auger electron counts) - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. To this end the schema here makes no - specific assumptions, not even that all the fields/group of a schema instance - have to be stored at all into a single file. Instead, the schema specifies the - relations between metadata, some of the constraints and conditions on how the - data should be formatted, what the data conceptually represent, and which terms - (controlled vocabulary) is practical to store to index specific quantities. - - In effect, the application definition is a graph which describes how - numerical data and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. -# While an important -# step this will still need in the future a mechains -# So far Essentially when the docstrings are no longer needed -# but can be replaced by a connection to an automated tool which understands -# what a specific field represents conceptually, EM data have become more -# generally interoperable EM data. -# NEW ISSUE: see duration and collection time, duty cycle -# NEW ISSUE: duration and collection_time needs a clearer description and -# definition by the community -# NEW ISSUE: should version always be an enumeration? -# NEW ISSUE: filter keywords \(.*?\) -# NEW ISSUE: NXdetector adding only those fields which have changed or not? -# symbols: -# the NeXus default for application definitions wrt to the exists keyword is -# that it is required -NXem: - (NXentry): - exists: [min, 1, max, infty] - # NEW ISSUE: the definition field and its version attribute enumeration - # NEW ISSUE: will be added by yaml2nxdl automatically - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - # enumeration: [sha_256_hash] - definition: - doc: | - NeXus NXDL schema to which this file conforms. - enumeration: [NXem] - experiment_identifier: - doc: | - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - experiment_description: - exists: optional - doc: | - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - start_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - experiment_documentation(NXnote): - exists: optional - doc: | - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - thumbnail(NXnote): - exists: optional - doc: | - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - \@type: - (NXuser): - exists: [min, 1, max, infty] - doc: | - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - name: - doc: Given (first) name and surname of the user. - affiliation: - exists: recommended - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. - address: - exists: recommended - doc: Postal address of the affiliation. - email: - exists: recommended - doc: | - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - orcid: - exists: recommended - doc: | - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - orcid_platform: - exists: recommended - doc: | - Name of the OrcID or ResearcherID where the account - under orcid is registered. - telephone_number: - exists: optional - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - role: - exists: recommended - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - social_media_name: - exists: optional - doc: | - Account name that is associated with the user in social media platforms. - social_media_platform: - exists: optional - doc: | - Name of the social media platform where the account - under social_media_name is registered. - sample(NXsample): - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - # ID: -> maps to name - # name: -> short_title - # user: -> not matched right now - # citation: doi ->why relevant, should be solved by RDMS - doc: | - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - method: - doc: | - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - enumeration: [experiment, simulation] - # MK:: declared_by_vendor I would rather expect this for a substance - # COMPONENT.yaml - # SUBSTANCE: - # QUANTIFY - name: # MK: for now the ID - doc: | - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - sample_history: - doc: | - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - preparation_date(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - short_title: - exists: optional - doc: | - Possibility to give an abbreviation or alias of the specimen name field. - atom_types: - doc: | - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample - thickness(NX_FLOAT): - doc: | - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - unit: NX_LENGTH - # \@units: nm - # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful - # NEW ISSUE: error model - # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive - # etc. The problem with this is that beam sensitivity is too vague, spatio-temporal electron dose integral dependent - # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making - # simple could be problematic or not decision, it is also these descriptors if remaining vague are also not useful - # what are good or bad properties, it would make sense though to quantify these values - # this includes the description of eventual plasma cleaning steps, - # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough - # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM - # are the ibeam description capabilities not sufficient enough? - - density(NX_FLOAT): - exists: optional - doc: | - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - unit: NX_ANY - # \@units: g/cm^3 - description: - exists: optional - doc: | - Discouraged free-text field in case properly designed records - for the sample_history are not available. - (NXdata): - exists: optional - doc: | - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - (NXcoordinate_system_set): - exists: recommended - TRANSFORMATIONS(NXtransformations): - exists: [min, 0, max, infty] - # in what follows each component of the instrument might be equipped with an NXmonitor - (NXmonitor): - exists: optional - # NEW ISSUE ADD AS MANY MONITORS AS NEEDED, also for pressure etc. - - # in what follows, an as-detailed as desired collection of components - # making up the instrument follows at this level of the hierarchy - em_lab(NXinstrument): - doc: | - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - instrument_name: - doc: | - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - location: - exists: optional - doc: | - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - (NXfabrication): - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - (NXchamber): - exists: optional - (NXebeam_column): - exists: [min, 1, max, 1] - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXchamber): - exists: optional - electron_source(NXsource): - name: - exists: recommended - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - voltage(NX_FLOAT): - emitter_type: - exists: recommended - enumeration: ["thermionic", "schottky", "field_emission"] - (NXaperture_em): - exists: [min, 0, max, infty] - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - value(NX_NUMBER): - name: - description: - exists: optional - (NXlens_em): - exists: [min, 0, max, infty] - doc: | - If the lens is described at least one of the fields - voltage, current, or value should be defined. - # a classical case where we want at least one field of multiple to exist - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - voltage(NX_NUMBER): - exists: recommended - current(NX_NUMBER): - exists: recommended - value(NX_NUMBER): - exists: recommended - aberration_correction(NXcorrector_cs): - exists: recommended - applied(NX_BOOLEAN): - name: - exists: optional - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - ZEMLIN_TABLEAU(NXprocess): - exists: recommended - description: - exists: optional - tilt_angle(NX_FLOAT): - exists: recommended - unit: NX_ANGLE - exposure_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - magnification(NX_NUMBER): - exists: optional - unit: NX_DIMENSIONLESS - (NXprocess): - exists: [min, 0, max, infty] - ceos(NXaberration_model_ceos): - exists: optional - c_1(NXaberration): # Defocus - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_1(NXaberration): # Two-fold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - b_2(NXaberration): # Second-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_2(NXaberration): # Threefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - c_3(NXaberration): # Spherical aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - s_3(NXaberration): # Star aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_3(NXaberration): # Fourfold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - # based on feedback from Thilo Remmele the following aberrations could be measured - b_4(NXaberration): # Fourth-order axial coma - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - d_4(NXaberration): # Three-lobe aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_4(NXaberration): # Fivefold astigmatism - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - c_5(NXaberration): # Fifth-order spherical aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - s_5(NXaberration): # Fifth-order star aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - r_5(NXaberration): # Rosette aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_6(NXaberration): # Sixfold astigmatism - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - nion(NXaberration_model_nion): - exists: optional - c_1_0(NXaberration): # Defocus - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_1_2_a(NXaberration): # Two-fold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_1_2_b(NXaberration): # Two-fold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_1_a(NXaberration): # Second-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_1_b(NXaberration): # Second-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_3_a(NXaberration): # Threefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_3_b(NXaberration): # Threefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_0(NXaberration): # Spherical aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_2_a(NXaberration): # Star aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_2_b(NXaberration): # Star aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_4_a(NXaberration): # Fourfold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_4_b(NXaberration): # Fourfold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_1_a(NXaberration): # Fourth-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_1_b(NXaberration): # Fourth-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_3_a(NXaberration): # Three-lobe aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_3_b(NXaberration): # Three-lobe aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_5_a(NXaberration): # Fivefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_5_b(NXaberration): # Fivefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_0(NXaberration): # Fifth-order spherical aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_2_a(NXaberration): # Fifth-order star aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_2_b(NXaberration): # Fifth-order star aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_4_a(NXaberration): # Rosette aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_4_b(NXaberration): # Rosette aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_6_a(NXaberration): # Sixfold astigmatism - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_6_b(NXaberration): # Sixfold astigmatism - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - (NXibeam_column): - exists: [min, 0, max, 2] - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXchamber): - exists: optional - ion_source(NXsource): - name: - exists: recommended - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - emitter_type: - probe(NXion): - charge_state(NX_INT): - exists: recommended - isotope_vector(NX_UINT): - exists: recommended - name: - exists: recommended - voltage(NX_FLOAT): - current(NX_FLOAT): - (NXaperture_em): - exists: recommended - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - value(NX_NUMBER): - (NXlens_em): - exists: recommended - doc: | - If the lens is described at least one of the fields - voltage, current, or value should be defined. - (NXfabrication): - exists: recommended - identifier: - exists: recommended - voltage(NX_NUMBER): - exists: recommended - current(NX_NUMBER): - exists: recommended - value(NX_NUMBER): - exists: recommended - EBEAM_DEFLECTOR(NXscanbox_em): - exists: [min, 0, max, infty] - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - pixel_time(NX_FLOAT): - exists: recommended - IBEAM_DEFLECTOR(NXscanbox_em): - exists: [min, 0, max, infty] - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXoptical_system_em): - exists: recommended - camera_length(NX_NUMBER): - exists: optional - magnification(NX_NUMBER): - exists: optional - defocus(NX_NUMBER): - exists: recommended - # this is c_1_0 of aberration_correction - semi_convergence_angle(NX_NUMBER): - exists: recommended - working_distance(NX_FLOAT): - exists: recommended - beam_current(NX_FLOAT): - exists: recommended - beam_current_description: - exists: recommended - # vendor/instrument-specific data currently case-by-case dependent - # e.g. Nion Co. magboard settings - # instances of NXoptical system can be placed here and specific for - # each NXevent_data_em instance if desired - DETECTOR(NXdetector): - # ##MK::eventually only adding (NXfabrication) and the new docstring - # is needed, will the rest be inferred automatically? - exists: [min, 1, max, infty] - doc: | - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - local_name: - doc: | - Instrument-specific alias/name - (NXfabrication): - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use - exists: recommended - identifier: - exists: recommended - (NXpump): - exists: [min, 0, max, infty] - # NEW ISSUE: do we consider the EELS spectrometer an own detector or an own functional unit i.e. NXeels - stage_lab(NXstage_lab): - name: - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - design: - exists: recommended - description: - exists: optional - # tricky for arbitrary design we cannot enforce all the below to exist at all - position(NX_FLOAT): - exists: recommended - rotation(NX_FLOAT): - exists: recommended - tilt_1(NX_FLOAT): - exists: recommended - tilt_2(NX_FLOAT): - exists: recommended - measurement(NXevent_data_em_set): - exists: [min, 0, max, 1] - ##MK because it should be possible to use the application definition - ##MK to store e.g. just some descriptions about the instrument - ##MK:with which then no measurements are attached - # this would enable to use nxs file also for instrument inventory - # system like offer through ELNs/or LIMS - doc: | - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - (NXevent_data_em): - exists: [min, 1, max, infty] - doc: | - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - event_identifier: - exists: recommended - event_type: - exists: recommended - # a collection of images take and group under this event - # NEW ISSUE: should this only be one instance for a given event? - IMAGE_SET(NXimage_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: [min, 0, max, infty] - program: - \@version: - stack(NXdata): - exists: recommended - \@signal: - \@axes: - \@AXISNAME_indices: - title: - data_counts(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 3 - # dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_image_identifier(NX_UINT): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_images]] - axis_y(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - SPECTRUM_SET(NXspectrum_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: [min, 0, max, infty] - program: - \@version: - stack(NXdata): - exists: recommended - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, n_energy]] - \@long_name: - # \@signal: counts - # \@axes: [ypos, xpos, energy] - # \@ypos_indices: 0 - # \@xpos_indices: 1 - # \@energy_indices: 2 - axis_y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - axis_x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - axis_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - summary(NXdata): - exists: recommended - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - # \@signal: counts - # \@axes: [energy] - # \@energy_indices: 0 - axis_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - adf(NXimage_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: [min, 0, max, infty] - program: - \@version: - inner_half_angle(NX_FLOAT): - exists: recommended - doc: | - Annulus inner half angle - unit: NX_ANGLE - outer_half_angle(NX_FLOAT): - exists: recommended - doc: | - Annulus outer half angle - unit: NX_ANGLE - stack(NXdata): - exists: recommended - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - axis_image_identifier(NX_UINT): - \@long_name: - # dimensions: - # rank: 3 - # dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_y(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - xray(NXspectrum_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: [min, 0, max, infty] - program: - \@version: - stack(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 3 - # dim: [[1, n_y], [2, n_x], [3, n_photon_energy]] - axis_y(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - axis_photon_energy(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_photon_energy]] - summary(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_photon_energy]] - axis_photon_energy(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_photon_energy]] - # NEW ISSUE: all of this should be offloaded to NXem_edx --> - indexing(NXprocess): - exists: optional - # ##MK:: much content of the base class has not been added although - # should be considered and made recommended at least - ELEMENTNAME(NXprocess): - exists: [min, 1, max, 256] - summary(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 2 - # dim: [[1, n_y], [2, n_x]] - axis_y(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - # NEW ISSUE: all of this should be offloaded to NXem_edx --> - eels(NXspectrum_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: [min, 0, max, infty] - program: - \@version: - stack(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 3 - # dim: [[1, n_y], [2, n_x], [3, n_energy_loss]] - axis_y(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - axis_energy_loss(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_energy_loss]] - summary(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_energy_loss]] - axis_energy_loss(NX_NUMBER): - # dimensions: - # rank: 1 - # dim: [[1, n_energy_loss]] - \@long_name: - # base classes for which we have at the moment no example implemented - # consider to replace se, bse, bf, df, chamber, ronchigram, by generic NXimage_set - # NEW ISSUE: all of this should be offloaded to NXem_eels --> - kikuchi(NXimage_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: [min, 0, max, infty] - program: - \@version: - stack(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 3 - # dim: [[1, n_p], [2, n_y], [3, n_x]] - pattern_identifier(NX_UINT): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - axis_y(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - scan_point_identifier(NX_UINT): - # \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # no summary because this will be handled by EBSD - - # (NXimage_set_em_se): - # exists: optional - # (NXimage_set_em_bse): - # exists: optional - # (NXimage_set_em_bf): - # exists: optional - # (NXimage_set_em_df): - # exists: optional - # (NXspectrum_set_em_auger): - # exists: optional - # (NXspectrum_set_em_cathodolum): - # exists: optional - # (NXimage_set_em_ecci): - # exists: optional - # (NXimage_set_em_diffrac): - # exists: optional - # (NXimage_set_em_ronchigram): - # exists: optional - # (NXimage_set_em_chamber): - # exists: optional - # a collection of specific details about state of the microscope - em_lab(NXinstrument): - exists: optional - (NXchamber): - exists: optional - (NXebeam_column): - exists: [min, 0, max, 1] - (NXchamber): - exists: optional - electron_source(NXsource): - exists: optional - voltage(NX_FLOAT): - (NXaperture_em): - exists: optional - value(NX_NUMBER): - (NXlens_em): - exists: optional - voltage(NX_NUMBER): - exists: recommended - current(NX_NUMBER): - exists: recommended - value(NX_NUMBER): - exists: recommended - aberration_correction(NXcorrector_cs): - exists: recommended - applied(NX_BOOLEAN): - name: - exists: optional - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - ZEMLIN_TABLEAU(NXprocess): - exists: recommended - description: - exists: optional - tilt_angle(NX_FLOAT): - exists: recommended - unit: NX_ANGLE - exposure_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - magnification(NX_NUMBER): - exists: optional - unit: NX_DIMENSIONLESS - (NXprocess): - exists: [min, 0, max, infty] - ceos(NXaberration_model_ceos): - exists: optional - c_1(NXaberration): # Defocus - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_1(NXaberration): # Two-fold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - b_2(NXaberration): # Second-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_2(NXaberration): # Threefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - c_3(NXaberration): # Spherical aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - s_3(NXaberration): # Star aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_3(NXaberration): # Fourfold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - # based on feedback from Thilo Remmele the following aberrations could be measured - b_4(NXaberration): # Fourth-order axial coma - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - d_4(NXaberration): # Three-lobe aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_4(NXaberration): # Fivefold astigmatism - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - c_5(NXaberration): # Fifth-order spherical aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - s_5(NXaberration): # Fifth-order star aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - r_5(NXaberration): # Rosette aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_6(NXaberration): # Sixfold astigmatism - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - nion(NXaberration_model_nion): - exists: optional - c_1_0(NXaberration): # Defocus - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_1_2_a(NXaberration): # Two-fold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_1_2_b(NXaberration): # Two-fold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_1_a(NXaberration): # Second-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_1_b(NXaberration): # Second-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_3_a(NXaberration): # Threefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_3_b(NXaberration): # Threefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_0(NXaberration): # Spherical aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_2_a(NXaberration): # Star aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_2_b(NXaberration): # Star aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_4_a(NXaberration): # Fourfold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_4_b(NXaberration): # Fourfold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_1_a(NXaberration): # Fourth-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_1_b(NXaberration): # Fourth-order axial coma - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_3_a(NXaberration): # Three-lobe aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_3_b(NXaberration): # Three-lobe aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_5_a(NXaberration): # Fivefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_5_b(NXaberration): # Fivefold astigmatism - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_0(NXaberration): # Fifth-order spherical aberration - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_2_a(NXaberration): # Fifth-order star aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_2_b(NXaberration): # Fifth-order star aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_4_a(NXaberration): # Rosette aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_4_b(NXaberration): # Rosette aberration - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_6_a(NXaberration): # Sixfold astigmatism - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_6_b(NXaberration): # Sixfold astigmatism - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - (NXibeam_column): - exists: [min, 0, max, 2] - (NXchamber): - exists: optional - ion_source(NXsource): - exists: optional - probe(NXion): - exists: recommended - charge_state(NX_INT): - exists: recommended - isotope_vector(NX_UINT): - exists: recommended - name: - exists: recommended - voltage(NX_FLOAT): - exists: recommended - current(NX_FLOAT): - exists: recommended - (NXaperture_em): - exists: optional - value(NX_NUMBER): - exists: recommended - (NXlens_em): - exists: optional - voltage(NX_NUMBER): - exists: recommended - current(NX_NUMBER): - exists: recommended - value(NX_NUMBER): - exists: recommended - ebeam_deflector(NXscanbox_em): - exists: optional - pixel_time(NX_FLOAT): - exists: recommended - ibeam_deflector(NXscanbox_em): - exists: optional - # NEW ISSUE: how to handle situations where we wish to describe multiple deflectors? - (NXoptical_system_em): - exists: optional - camera_length(NX_NUMBER): - exists: optional - magnification(NX_NUMBER): - exists: optional - defocus(NX_NUMBER): - exists: recommended - semi_convergence_angle(NX_NUMBER): - exists: recommended - working_distance(NX_FLOAT): - exists: recommended - beam_current(NX_FLOAT): - exists: recommended - beam_current_description: - exists: recommended - (NXdetector): - exists: optional - # dynamically changing detector settings uses only during this NXevent_data_em - (NXpump): - exists: optional - (NXstage_lab): - exists: optional - position(NX_FLOAT): - exists: recommended - rotation(NX_FLOAT): - exists: recommended - tilt_1(NX_FLOAT): - exists: recommended - tilt_2(NX_FLOAT): - exists: recommended - (NXuser): - exists: [min, 0, max, infty] - name: - diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml deleted file mode 100644 index 2c9a1b72d2..0000000000 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ /dev/null @@ -1,1700 +0,0 @@ -category: application -symbols: - n_op: Number of arguments per orientation for given parameterization. - n_sc: Number of scan points. - n_z: Number of pixel along the slowest changing dimension for a rediscretized, i.e. standardized default orientation mapping. - n_y: Number of pixel along slow changing dimension for a rediscretized i.e. standardized default orientation mapping. - n_x: Number of pixel along fast changing dimension for a rediscretized i.e. standardized default orientation mapping. -# what to do when multiple pattern are averaged into one before the beam moves further? -doc: | - Application definition for collecting and indexing Kikuchi pattern into orientation maps. - - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. - - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. - - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. - - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. -# The respective partner application definition NXxray_fourd -# can be used for storing data and post-processing results of X-ray diffraction -# experiments which can yield also orientation maps in one, two- or three-dimensions. -# -# These complementary techniques and associated application definitions can be used -# to inform NXms, another partner application definition to NXem_ebsd. NXms describes -# the connection between measured or simulated structural features with a focus of -# the length and time-scale coarser then the atomic scale. The term microstructure -# is used here but is not restricted to features at the micron scale. - -# the IUCr DMI should work on an e.g. NXhedm -# NXem_tkd is not needed as it can be covered by NXem_ebsd as well. -# if we think of the metadata/data graph collected from the microscope session -# documented in NXem there may be only a few relations between nodes of an instance -# of NXem_ebsd and NXem. Key data from NXem which many users would expect to find -# also enumerated in NXem_ebsd could be settings of the microscope, timestamp data -# when tasks were performed at the microscope using which specimen, operated -# and prepared by whom. These latter pieces of information are all available -# in NXem but if we were to make fields in NXem deep inside an instance -# of NXem_event_data required than we factually more and more granularize and -# pull in steps of detailed numerical post-processing which arguably is not -# any longer at all necessarily related to the microscope session. -# We know many cases in EBSD community, see the work of e.g. Marc de Graef's group -# or of Hakon Wiik Anes and Knut Marthinsen who spent much longer with a collected -# dataset in post-processing than collecting it at the microscope. Therefore, we -# need to have the flexibility that documentation of the actual microscope session -# and the post-processing of some of the data therein collected remain coupled -# but not too repetively and with too stiff constraints on the existence of specific -# fields as otherwise there can be contradictions for which NXem_ebsd would no longer -# be applicable when one wishes to remain at the same time conformant with the data -# scheme. -# The idea used here is to use a reference to another NeXus file in the NXem_ebsd -# file instance and the NXem file instance. So far we acknowledge that exporting -# data as an NXem application definition is limited and scientists currently have -# specific file formats from commercial or open-source tools to work with. -# Therefore, we so far model the connections between the application definitions -# as NXprocesses. As soon as NXem is more supported these NXclasses should become -# NXem e.g. though. -# Details about scan positions should not be reproduced unless needed for -# interpolating between results of neighboring scan positions. -# Currently, we suggest to leave the scan positions as closely to where they are -# collected, i.e. inside NXem. -# What this exampe of linking information rather than duplicating shows is that -# somewhat a culture change is needed: Instead of packing everything in one file -# we just need to assure that we have a tool whereby we can follow and inspect a -# set of linked objects if you would like to say so, also having multiple files -# is okay. -# Finally, this application definition makes any assumptions about -# gridding, this enables to handle all sort of scan schemes. -# We follow the argumentation of MTex, in certain cases data will not yield -# fully occupied grids anyway. -# NXem_ebsd could also be useful/used for storing generic simulations of EBSD pattern -# which is one example for simulations of diffractions patterns as they may be observed -# with electron microscopes. In this case, there should be simulation(NXprocess) under this -# the simulation group where one can store the minimum required set of pieces of information -# which comes with every diffraction pattern simulation. -# The main problem is in this case that the simulation group is required but then there must -# either be no measurement group and on_the_fly_indexing group, and eventually calibration ? -# or these groups should be created but remain empty. -# Using the current NeXus appdef design and rules for setting constraints demands that then the -# same appdef should be used for post-processing measured data. So there is a conflict: -# The simulation must not be required and measurement must not be optional. -# Arguably one may call for two application definitions in this case but most constraints and -# concepts would then match those of NXem_ebsd which works again standardization and -# reducing the total number of ontologies. - -NXem_ebsd: - (NXentry): - exists: [min, 1, max, infty] - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - # NEW ISSUE: FILE or ARTIFACT? - # enumeration: [sha_256_hash] - definition: - doc: NeXus NXDL schema to which this file conforms. - enumeration: [NXem_ebsd] - workflow_identifier: - doc: | - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - workflow_description: - exists: optional - doc: | - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - start_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - (NXprogram): - exists: [min, 1, max, infty] - doc: | - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - program: - \@version: - (NXuser): - exists: [min, 0, max, infty] - doc: | - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - name: - doc: Given (first) name and surname of the user. - affiliation: - exists: recommended - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. - address: - exists: recommended - doc: Postal address of the affiliation. - email: - exists: recommended - doc: | - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - orcid: - exists: recommended - doc: | - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - orcid_platform: - exists: recommended - doc: | - Name of the OrcID or ResearcherID where the account - under orcid is registered. - telephone_number: - exists: optional - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - role: - exists: recommended - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - social_media_name: - exists: optional - doc: | - Account name that is associated with the user - in social media platforms. - social_media_platform: - exists: optional - doc: | - Name of the social media platform where the account - under social_media_name is registered. - - # rotation and reference frame conventions - # we assume that the conventions are the same across all experiments and/or - # simulations which this application definition captures - conventions(NXem_ebsd_conventions): - rotation_conventions(NXprocess): - three_dimensional_rotation_handedness: - rotation_convention: - euler_angle_convention: - axis_angle_convention: - orientation_parameterization_sign_convention: - processing_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - xaxis_alias: - yaxis_direction: - yaxis_alias: - zaxis_direction: - zaxis_alias: - origin: - sample_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - yaxis_direction: - zaxis_direction: - origin: - detector_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - yaxis_direction: - zaxis_direction: - origin: - gnomonic_projection_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - yaxis_direction: - zaxis_direction: - origin: - pattern_centre(NXprocess): - xaxis_boundary_convention: - xaxis_normalization_direction: - yaxis_boundary_convention: - yaxis_normalization_direction: - - # either we have simulated data or we have a set of measured data - # in every case data are Kikuchi diffraction pattern and their metadata - simulation(NXprocess): - exists: recommended - doc: | - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - sequence_index(NX_POSINT): # 1 - (NXprogram): - exists: [min, 0, max, infty] - program: - \@version: - (NXcg_geodesic_mesh): - exists: [min, 0, max, infty] - (NXimage_set_em_kikuchi): - stack(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 3 - # dim: [[1, n_p], [2, n_y], [3, n_x]] - pattern_identifier(NX_UINT): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - axis_y(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - - experiment(NXprocess): - exists: [min, 0, max, infty] - doc: | - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - time(NX_NUMBER): - unit: NX_TIME - exists: optional # required for spatial and/or temporal for a correlation process - doc: | - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - (NXtransformations): - exists: optional # required for a spatial correlation process - doc: | - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - calibration(NXprocess): # the more NeXus becomes supported the more we should go for (NXem) instead - exists: recommended # it should be required even for pattern simulations - # although one could simulate spherical Kikuchi pattern without modeling the detector system - doc: | - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - sequence_index(NX_POSINT): # 1 - origin: - doc: | - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - \@version: - doc: Commit identifying this resource. - path: - doc: | - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - acquisition(NXprocess): - exists: recommended # the measurement should be required unless the - # data come from e.g. a Kikuchi pattern simulation! - doc: | - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - sequence_index(NX_POSINT): # 2 - origin: - doc: | - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - \@version: - doc: | - Commit or e.g. at least SHA256 checksum identifying this resource. - path: - doc: | - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - # base class for indexing methods with relevant vocabulary - indexing(NXprocess): - exists: recommended # making it recommended makes not much sense as then we will not have - # IPF default plots in this case we need to use simulated Kikuchi pattern as a fallback - doc: | - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - sequence_index(NX_POSINT): # 3 - on_the_fly_indexing(NXprocess): - exists: optional - doc: | - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - (NXprogram): - exists: [min, 1, max, infty] - doc: | - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - program: - \@version: - origin: - doc: | - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - \@version: - doc: | - Hash of that file. - path: - doc: | - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - method: - doc: | - Principal algorithm used for indexing. - enumeration: [ - undefined, - hough_transform, - dictionary, - radon_transform, - other, - ] # emsoft, astro, mtex - background_correction(NXprocess): - exists: optional - doc: | - Details about the background correction applied to each Kikuchi pattern. - sequence_index(NX_POSINT): - # for each process the program used - # auto_background_correction: - # static_or_dynamic: - # pattern_averaging(NXprocess): - # doc: | - # Details about how patterns of each scan point are average or how - # pattern from scan points and neighboring scan points are spatially - # averaged (using weighting schemes and e.g. kernels) before these - # patterns are passed to the indexing algorithm. - binning(NXprocess): # NEW ISSUE: binning replace by NXgrid - exists: optional - doc: | - Binning i.e. downsampling of the pattern. - sequence_index(NX_POSINT): - # for each process the program used - # mode: - # doc: Free-text description for instrument specific settings - # binning(NX_UINT): ##MK equivalent to pattern height and width? - # doc: | - # How is the camera signal binned. - # First the number of pixel along the slow direction. - # Second the number of pixel along the fast direction. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, 2]] - parameter(NXprocess): - exists: optional - doc: | - Specific parameter relevant only for certain algorithms used - sequence_index(NX_POSINT): - # mode: - # doc: Which method used to index pattern? - # enumeration: [optimize_bd] # what does optimize_bd mean Oxford? - (NXem_ebsd_crystal_structure_model): # phaseID(NXem_ebsd_crystal_structure_model) - exists: [min, 1, max, infty] - crystallographic_database_identifier: - exists: recommended - crystallographic_database: - exists: recommended - unit_cell_abc(NX_FLOAT): - unit_cell_alphabetagamma(NX_FLOAT): - space_group: - exists: recommended - phase_identifier(NX_UINT): - phase_name: - exists: recommended - atom_identifier: - exists: recommended - atom(NX_UINT): - exists: recommended - atom_positions(NX_FLOAT): - exists: recommended - atom_occupancy(NX_FLOAT): - exists: recommended - number_of_planes(NX_UINT): - exists: recommended - plane_miller(NX_NUMBER): - exists: recommended - dspacing(NX_FLOAT): - exists: recommended - relative_intensity(NX_FLOAT): - exists: recommended - # connection to data collected using kinematic or - # NEW ISSUE: dynamic diffraction theory simulations - - # individual mappings - # (scientists in EBSD consult all sorts of mappings) - # like image_quality map, orientation mapping, ipf mapping, grain mapping - # etc. in fact these could be all the possible mappings which one can - # create with the famous commercial software solutions - # the problem a RDMS cannot understand these mappings unless they - # are standardized in the sense, one has an exchange format whereby - # these mappings can be exported/transcoded from their representation - # in the commercial software, e.g. - # keep in mind, everybody uses the TSL OIM or Bruker AZTec OIM mapping - # but even these two are not directly interoperable, which is why - # they are also not interoperable in some RDMS if one does not come - # up with a way how to go about standardizing their description - # summary(NXdata): - # doc: | - status(NX_UINT): - exists: optional - doc: | - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - # data(NX_UINT): - # doc: | - # Status value of each pixel of the orientation mapping. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_sc]] - # axis_y(NX_NUMBER): - # doc: | - # Coordinate along the slow direction. - # axis_x(NX_NUMBER): - # doc: | - # Coordinate along the fast direction. - n_phases_per_scan_point(NX_UINT): - exists: recommended - doc: | - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_sc]] - phase_identifier(NX_UINT): - exists: recommended - doc: | - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] # with i = sum of n_phases_per_scan_point - phase_matching(NX_NUMBER): - exists: recommended - doc: | - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] # with i = sum of n_phases_per_scan_point - phase_matching_descriptor: - exists: recommended - doc: | - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - enumeration: [undefined, ci, mad, other] - orientation_parameterization: - exists: recommended # required when orientation exists - doc: | - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - enumeration: [euler, axis_angle, rodrigues, quaternion, homochoric] - orientation(NX_NUMBER): - exists: recommended - doc: | - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - unit: NX_ANY # because differs for different parameterizations - dimensions: - rank: 2 - dim: [[1, i], [2, n_op]] - scan_point_positions(NX_NUMBER): - exists: recommended - # we make this only required as people may not yet be so happy with - # having to walk a graph from measurement -> path -> NXevent_data_em - # -> em_lab/ebeam_deflector to retrieve the actual scan positions - # although this would be much cleaner - doc: | - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_sc], [2, 2]] # could also become a [2, 3] - # EW ISSUE: this is in fact a duplicate because if we know th - # path to the measurement we would have available all ebeam_deflector - # settings and thus could identify where the beam was scanning for each - # NXevent_data_em instance, we have even more - - # NEW ISSUE: replace by a more generic pivot table - hit_rate(NX_NUMBER): - exists: optional - doc: | - Fraction of successfully indexed pattern - of the set averaged over entire set. - unit: NX_DIMENSIONLESS - - # candidate for default plot - region_of_interest(NXprocess): # conceptually this a virtual detector - exists: [min, 1, max, 1] - doc: | - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - descriptor: - doc: | - Descriptor representing the image contrast. - # taking two examples (CTF and H5OINA choked completely of possibility to find s.th. conceptually common to plot - enumeration: - ["normalized_band_contrast", "normalized_confidence_index"] - roi(NXdata): - doc: | - Container holding a default plot of the region on the sample - investigated with EBSD. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: # 0 - # \@axis_y_indices: # 1 - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data(NX_NUMBER): - doc: | - Descriptor values displaying the ROI. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_y], [2, n_x]] - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: Signal - axis_y(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the slow axis. - unit: NX_LENGTH # pixel coordinates - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Label for the y axis - axis_x(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the fast axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Label for the x axis - - (NXprocess): # ipf_mapID(NXprocess): - exists: [min, 0, max, infty] # should be as many as crystal structure models - doc: | - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - phase_identifier(NX_UINT): - doc: | - Specifying which phase this IPF mapping visualizes. - unit: NX_UNITLESS - phase_name: - doc: | - Alias/name for the phase whose indexed scan points are displayed. - description: - exists: optional - doc: | - Which IPF definition computation according to backend. - # AS THE FIRST STEP WE DO NOT IMPLEMENT A GENERIC ORIENTATION AND REFERENCE - # FRAME LIBRARY WHICH CAN TRANSLATE BETWEEN ALL POSSIBLE CONVENTIONS. - # INSTEAD WE TAKE THE RESULTS COMPUTED FROM THE BACKEND THAT IS - # For cpr/crc/ang the pythonEBSD backend - # For other file either MTex or kikuchipy - # For DREAM.3D this is DREAM.3D - # For pyxem following the orix library (which has some, though not yet in - # all details checked links and usage of the orix library because kikuchipy - # is somehow connected to pyxem. NEED TO TALK TO DEVELOPERS HERE! - projection_direction(NX_NUMBER): - doc: | - Along which axis to project? Typically [0, 0, 1] is chosen. - # NEW ISSUE: [0, 0, 1] is defined in which coordinate system? - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 3]] - bitdepth(NX_UINT): - doc: | - Bitdepth used for the RGB color model. Usually 8 bit. - unit: NX_UNITLESS - # can an NX_UINT have an enumeration? - (NXprogram): - exists: [min, 1, max, infty] - doc: | - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - program: - \@version: - # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] - - ipf_rgb_map(NXdata): - doc: | - The RGB image which represents the IPF map. - # \@signal: # rgb - # \@axes: # [zpos, ypos, xpos] # rgb - # # \@rgb_indices: 0 - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # # \@zpos_indices: 2 - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data(NX_UINT): - doc: | - RGB array, with resolution per fastest changing value - defined by bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] - # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - IPF color-coded orientation mapping - axis_y(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the slow axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Label for the y axis - # but for h5web RGB we need n_y + 1, was an issue in v6.6.1 - axis_x(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the fast axis. - dimensions: - rank: 1 - dim: [[1, n_x]] # but for h5web RGB we need n_x + 1 - \@long_name: - doc: Label for the x axis - - ipf_rgb_color_model(NXdata): - doc: | - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - # \@signal: # rgb - # \@axes: # [ypos, xpos] # rgb - # # \@rgb_indices: 0 - # \@axis_x_indices: # 0 - # \@axis_y_indices: # 1 - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data(NX_UINT): - doc: | - RGB array, with resolution per fastest changing value defined by bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - IPF color key in stereographic standard triangle (SST) - axis_y(NX_NUMBER): - doc: | - Pixel coordinate along the slow axis. - unit: NX_ANY # pixel coordinates - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Label for the y axis - axis_x(NX_NUMBER): - doc: | - Pixel coordinate along the fast axis. - unit: NX_ANY # pixel coordinates - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Label for the x axis - - correlation(NXprocess): - exists: optional # making it recommended makes not much sense as then we will not have - doc: | - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - sequence_index(NX_POSINT): # 4 - - (NXem_ebsd_crystal_structure_model): # phaseID(NXem_ebsd_crystal_structure_model) - exists: [min, 1, max, infty] - crystallographic_database_identifier: - exists: recommended - crystallographic_database: - exists: recommended - unit_cell_abc(NX_FLOAT): - unit_cell_alphabetagamma(NX_FLOAT): - space_group: - exists: recommended - phase_identifier(NX_UINT): - phase_name: - exists: recommended - - # candidate for default plot - region_of_interest(NXprocess): # conceptually this a virtual detector - exists: [min, 1, max, 1] - doc: | - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - descriptor: - doc: | - Descriptor representing the image contrast. - # enumeration: ["normalized_band_contrast", "normalized_confidence_index"] - roi(NXdata): - doc: | - Container holding a default plot of the reconstructed volume. - # \@signal: # data - # \@axes: # [axis_z, axis_y, axis_x] - # \@axis_x_indices: # 0 - # \@axis_y_indices: # 1 - # \@axis_z_indices: # 2 - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data(NX_NUMBER): - doc: | - Descriptor values displaying the ROI. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: Signal - axis_z(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the slow axis. - unit: NX_LENGTH # pixel coordinates - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - doc: Label for the z axis - axis_y(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the fast axis. - unit: NX_LENGTH # pixel coordinates - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Label for the y axis - axis_x(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the fastest axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Label for the x axis - - (NXprocess): # ipf_mapID(NXprocess): - exists: [min, 0, max, infty] # should be as many as crystal structure models - doc: | - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - phase_identifier(NX_UINT): - doc: | - Specifying which phase this IPF mapping visualizes. - unit: NX_UNITLESS - phase_name: - doc: | - Alias/name for the phase whose indexed scan points are displayed. - description: - exists: optional - doc: | - Which IPF definition computation according to backend. - projection_direction(NX_NUMBER): - doc: | - Along which axis to project? Typically [0, 0, 1] is chosen. - # NEW ISSUE: [0, 0, 1] is defined in which coordinate system? - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 3]] - bitdepth(NX_UINT): - doc: | - Bitdepth used for the RGB color model. Usually 8 bit. - unit: NX_UNITLESS - (NXprogram): - exists: [min, 1, max, infty] - doc: | - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - program: - \@version: - - # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] - - ipf_rgb_map(NXdata): - doc: | - The RGB image which represents the IPF map. - # \@signal: # rgb - # \@axes: # [zpos, ypos, xpos] # rgb - # # \@rgb_indices: 0 - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@axis_z_indices: 2 - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data(NX_UINT): - doc: | - RGB array, with resolution per fastest changing value - defined by bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 4 - dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] - # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - IPF color-coded orientation mapping - axis_z(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the slow axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - doc: Label for the z axis - # but for h5web RGB we need n_z + 1, was an issue in v6.6.1 - axis_y(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the faster axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Label for the y axis - # but for h5web RGB we need n_y + 1, was an issue in v6.6.1 - axis_x(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the fastest axis. - dimensions: - rank: 1 - dim: [[1, n_x]] # but for h5web RGB we need n_x + 1 - \@long_name: - doc: Label for the x axis - - ipf_rgb_color_model(NXdata): - doc: | - Same comments as for the two-dimensional case apply. - # \@signal: # rgb - # \@axes: # [ypos, xpos] # rgb - # # \@rgb_indices: 0 - # \@axis_x_indices: # 0 - # \@axis_y_indices: # 1 - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data(NX_UINT): - doc: | - RGB array, with resolution per fastest changing value defined by bitdepth. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - IPF color key in stereographic standard triangle (SST) - axis_y(NX_NUMBER): - doc: | - Pixel coordinate along the slow axis. - unit: NX_ANY # pixel coordinates - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Label for the y axis - axis_x(NX_NUMBER): - doc: | - Pixel coordinate along the fast axis. - unit: NX_ANY # pixel coordinates - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Label for the x axis - - # NEW ISSUE: frame averaging - # NEW ISSUE: going towards the level of suggestions what would all be immediately possible - # ebsd_mapping(NXprocess): - # doc: | - # An EBSD mapping is the result of a collecting and indexing of Kikuchi - # pattern, so that for each pattern there is either an associated - # phase_identifier or a status marker stating that no solution was found - # (NXsst_color_model): ##MK - # doc: | - # For each stereographic standard triangle, (fundamental zone) of - # the orientation space, it is possible to define a color model which - # associates an orientation in the fundamental zone to a color. - # - # For details see: - # * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - # * Srikanth Patala and coworkers"'" work and of others. - # (NXorientation_set): - # doc: | - # Collection of quaternions in the SO3 fundamental zone with colors and - # rgb(NX_NUMBER): - # doc: RGB colors. - # unit: NX_UNITLESS - # dimensions: [[1, n_oris], [2, 3]] - # # hsv and other models - # (NXcg_point_set): - # rgb(NX_NUMBER): - # dimensions: [[1, n_points], [2, 3]] - # mapping(NX_NUMBER): - # doc: | - # The EBSD mapping with colors outlined - # unit: NX_UNITLESS - # dimensions: [[1, n_y], [2, n_x], [3, 3]] - # NEW ISSUE: it would also be possible to define additional color models to overlay - # check n_p vs n_sc vs n_p_or_z - - # confidence_index(NX_FLOAT): - # doc: | - # Is a technology-partner-specific (TSL OIM) AMETEK phase_matching descriptor. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, i]] - # mean_angular_deviation(NX_FLOAT): - # doc: | - # The mean angular deviation is also a technology-partner-specific - # (HKL Channel5) solution-to-reflector matching descriptor. - # unit: NX_ANGLE - # dimensions: - # rank: 1 - # dim: [[1, i]] - # there are many other type of descriptor especially for new machine learning - # type and dictionary type indexing methods - # some descriptors are relevant only for Hough based indexing and technology-partner-specific - # band_count(NX_UINT): - # doc: | - # How many bands were detected in the pattern. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # band_minimum(NX_UINT): - # doc: | - # Minimum number of bands required to index the pattern - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # band_maximum(NX_UINT): - # doc: | - # Maximum number of bands required to index the pattern - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # resolution(NX_NUMBER): - # doc: | - # Resolution in Hough space. - # unit: NX_ANGLE # or NX_ANY - # band_detection(NXprocess): # for hough_transform - # mode: - # doc: | - # How are Kikuchi bands detected - # enumeration: [center] - # band_contrast(NX_NUMBER): - # doc: | - # Value for band contrast descriptor. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # band_slope(NX_NUMBER): - # doc: | - # Value for band slope descriptor. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # centre(NX_FLOAT): - # doc: | - # Pattern centre location used for analyzing each pattern. - # unit: NX_LENGTH - # dimensions: - # rank: 2 - # dim: [[1, n_p], [2, 2]] # what to do when a different one for each pattern seldom but possible - # distance(NX_FLOAT): - # doc: | - # Pattern centre distance used for analyzing each pattern. - # unit: NX_LENGTH - # dimensions: - # rank: 2 - # dim: [[1, n_p], [2, 2]] - # vh_ratio(NX_FLOAT): - # doc: | - # TBD Oxford/HKL Channel 5 CPR files - # unit: NX_DIMENSIONLESS - # how to parameterize a group with value, and descriptor type or a - # field with descriptor type as attribute? - # pattern_quality(NXprocess): - # value(NX_NUMBER): - # doc: | - # Pattern quality descriptor - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # model: - # doc: | - # Model used to describe some aspect of the pattern. - # enumeration: [band_contrast, mean_angular_deviation] -# tilt_angle(NX_FLOAT): -# maybe better make this integrated into the NXtransformations of the stage_lab, a stage_lab event? -# beam_position(NXcg_point_set): -# (NXdetector): -# exposure_time(NX_FLOAT): -# unit: NX_TIME -# gain(NX_FLOAT): -# ##MK how does a gain translate mathematically an input signal into an intensity signal? -# insertion_distance(NX_FLOAT): -# unit: NX_LENGTH -# ##MK a coordinate system for the detector in the NXcoordinate_system_set -# drift_correction(NX_BOOLEAN): ##MK?? -# move the next two rather to detector -# acquisition_speed(NX_FLOAT): -# doc: | -# Average number of patterns taken per second averaged over entire set. -# unit: NX_FREQUENCY -# acquisition_time(NX_FLOAT): -# doc: Wall-clock time the acquisition took. -# unit: NX_TIME diff --git a/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml b/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml deleted file mode 100644 index 22875c331a..0000000000 --- a/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml +++ /dev/null @@ -1,325 +0,0 @@ -category: base -# symbols: -doc: | - Conventions for rotations and coordinate systems to interpret EBSD data. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. -NXem_ebsd_conventions: - # mandatory information about used or - # assumed reference frame and rotation conventions - rotation_conventions(NXprocess): - doc: | - Mathematical conventions and materials-science-specific conventions - required for interpreting every collection of orientation data. - three_dimensional_rotation_handedness: - doc: | - 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. - enumeration: [undefined, counter_clockwise, clockwise] - rotation_convention: - doc: | - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, passive, active] - euler_angle_convention: - doc: | - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) 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. - enumeration: [undefined, zxz] - axis_angle_convention: - doc: | - 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. - enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] - orientation_parameterization_sign_convention: - doc: | - 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. - enumeration: [undefined, p_plus_one, p_minus_one] - processing_reference_frame(NXprocess): - doc: | - Details about eventually relevant named directions that may - give reasons for anisotropies. The classical example is cold-rolling - where one has to specify which directions (rolling, transverse, and normal) - align how with the direction of the base vectors of the sample_reference_frame. - reference_frame_type: - doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] - xaxis_direction: - doc: | - Direction of the positively pointing x-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - enumeration: [undefined, north, east, south, west, in, out] - xaxis_alias: - doc: | - Name or alias assigned to the x-axis base vector, e.g. rolling direction. - yaxis_direction: - doc: | - Direction of the positively pointing y-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - yaxis_alias: - doc: | - Name or alias assigned to the y-axis base vector, e.g. transverse direction. - zaxis_direction: - doc: | - Direction of the positively pointing z-axis base vector of - the processing_reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - zaxis_alias: - doc: | - Name or alias assigned to the z-axis base vector, e.g. normal direction. - origin: - doc: | - Location of the origin of the processing_reference_frame. - This specifies the location Xp = 0, Yp = 0, Zp = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - - sample_reference_frame(NXprocess): - doc: | - Details about the sample/specimen reference frame. - reference_frame_type: - doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - The reference frame for the sample surface reference is used for - identifying positions on a (virtual) image which is formed by - information collected from an electron beam scanning the - sample surface. We assume the configuration is inspected by - looking towards the sample surface from a position that is - located behind the detector. - Reference DOI: 10.1016/j.matchar.2016.04.008 - The sample surface reference frame has coordinates Xs, Ys, Zs. - In three dimensions these coordinates are not necessarily - located on the surface of the sample as there are multiple - faces/sides of the sample. Most frequently though the coordinate - system here is used to define the surface which the electron - beam scans. - enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] - xaxis_direction: - doc: | - Direction of the positively pointing x-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - yaxis_direction: - doc: | - Direction of the positively pointing y-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - zaxis_direction: - doc: | - Direction of the positively pointing z-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - origin: - doc: | - Location of the origin of the sample surface reference frame. - This specifies the location Xs = 0, Ys = 0, Zs = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - - detector_reference_frame(NXprocess): - doc: | - Details about the detector reference frame. - reference_frame_type: - doc: | - Type of coordinate system/reference frame used for - identifying positions in detector space Xd, Yd, Zd, - according to DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] - xaxis_direction: - doc: | - Direction of the positively pointing x-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - yaxis_direction: - doc: | - Direction of the positively pointing y-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - zaxis_direction: - doc: | - Direction of the positively pointing z-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - origin: - doc: | - Where is the origin of the detector space reference - frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - gnomonic_projection_reference_frame(NXprocess): - doc: | - Details about the gnomonic projection reference frame. - reference_frame_type: - doc: | - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] - xaxis_direction: - doc: | - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - yaxis_direction: - doc: | - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - zaxis_direction: - doc: | - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - origin: - doc: | - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, in_the_pattern_centre] - pattern_centre(NXprocess): - doc: | - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - xaxis_boundary_convention: - doc: | - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - enumeration: [undefined, top, right, bottom, left] - xaxis_normalization_direction: - doc: | - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - enumeration: [undefined, north, east, south, west] - yaxis_boundary_convention: - doc: | - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - enumeration: [undefined, top, right, bottom, left] - yaxis_normalization_direction: - doc: | - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - enumeration: [undefined, north, east, south, west] - # distance_convention: - # doc: | - # How is the third of the three pattern centre parameter values, - # the (distance) parameter DD, normalized. Which convention - # is followed. We are aware that specifying one of the options here - # also implicitly comes with conventions for some of the parameter - # requested in this ELN. For now we would rather like to ask - # the users though to be specific also to learn how such an ELN - # will be used in practice. - # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] diff --git a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml deleted file mode 100644 index 933a82cad6..0000000000 --- a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml +++ /dev/null @@ -1,150 +0,0 @@ -category: base -symbols: - n_hkl: Number of reflectors (Miller crystallographic plane triplets). - n_pos: Number of atom positions. -doc: | - Crystal structure phase models used for indexing Kikuchi pattern. - - This base class contains key metadata relevant to every physical - kinematic or dynamic diffraction model to be used for simulating - Kikuchi diffraction pattern. - The actual indexing of Kikuchi pattern however maybe use different - algorithms which build on these simulation results but evaluate different - workflows of comparing simulated and measured Kikuchi pattern to make - suggestions which orientation is the most likely (if any) for each - scan point investigated. - - Traditionally Hough transform based indexing has been the most frequently - used algorithm. More and more dictionary based alternatives are used. - Either way both algorithm need a crystal structure model. -NXem_ebsd_crystal_structure_model: - # for EBSD specifically we need to know the assumed crystal structure - # with assumed statistically distributed atoms, i.e. structure and atom - # positions - crystallographic_database_identifier: - doc: | - Identifier of an entry from crystallographic_database which was used - for creating this structure model. - crystallographic_database: - doc: | - Name of the crystallographic database to resolve - crystallographic_database_identifier e.g. COD or others. - unit_cell_abc(NX_FLOAT): - doc: | - Crystallography unit cell parameters a, b, and c. - # defined using which convention? - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - unit_cell_alphabetagamma(NX_FLOAT): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - # defined using which convention? - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, 3]] - unit_cell_volume(NX_FLOAT): - doc: | - Volume of the unit cell - unit: NX_VOLUME - space_group: - doc: | - Crystallographic space group - # add enumeration all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - 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). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - laue_group: - doc: | - Laue group - # add enumeration all possible - point_group: - doc: | - Point group using International Notation. - # add enumeration all possible - unit_cell_class: - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - phase_identifier(NX_UINT): - doc: | - Numeric identifier for each phase. - The value 0 is reserved for the unknown phase essentially representing the - null-model that no phase model was sufficiently significantly confirmed. - Consequently, the value 0 must not be used as a phase_identifier. - unit: NX_UNITLESS - phase_name: - doc: | - Name of the phase/alias. - atom_identifier: - doc: | - Labels for each atom position - dimensions: - rank: 1 - dim: [[1, n_pos]] - atom(NX_UINT): - doc: | - 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) `_ - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_pos]] - atom_positions(NX_FLOAT): - doc: | - Atom positions x, y, z. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_pos], [2, 3]] - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_FLOAT): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_pos]] - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. Value has to be n_hkl. - unit: NX_UNITLESS - plane_miller(NX_NUMBER): - doc: | - Miller indices :math:`(hkl)`. - # Miller indices :math:`(hkl)[uvw]`. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_hkl], [2, 3]] - dspacing(NX_FLOAT): - doc: | - D-spacing. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_hkl]] - relative_intensity(NX_FLOAT): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_hkl]] -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml deleted file mode 100644 index 784abbecbb..0000000000 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ /dev/null @@ -1,37 +0,0 @@ -category: base -doc: "Subclass of NXelectronanalyser to describe the energy dispersion section - of a photoelectron analyser." -NXenergydispersion: - scheme(NX_CHAR): - doc: "Energy dispersion scheme employed, for example: - tof, hemispherical, cylindrical, mirror, retarding grid, etc." - pass_energy(NX_FLOAT): - doc: "Energy of the electrons on the mean path of the analyser. - Pass energy for hemispherics, drift energy for tofs." - unit: NX_ENERGY - center_energy(NX_FLOAT): - doc: "Center of the energy window" - unit: NX_ENERGY - energy_interval(NX_FLOAT): - doc: - "The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector containing - the extrema of the transmitted energy window (smaller number first). With a - swept scan of m steps it is a 2xm array of windows one for each measurement - point." - unit: NX_ENERGY - (NXaperture): - doc: "Size, position and shape of a slit in dispersive analyzer, e.g. entrance and exit slits." - diameter(NX_FLOAT): - doc: "Diameter of the dispersive orbit" - unit: NX_LENGTH - energy_scan_mode(NX_CHAR): - doc: "Way of scanning the energy axis (fixed or sweep)." - enumeration: ["fixed", "sweep"] - tof_distance(NX_FLOAT): - doc: "Length of the tof drift electrode" - unit: NX_LENGTH - (NXdeflector): - doc: "Deflectors in the energy dispersive section" - (NXlens_em): - doc: "Individual lenses in the energy dispersive section" diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml deleted file mode 100644 index b66e01b8f3..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ /dev/null @@ -1,195 +0,0 @@ -category: base -doc: | - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. `_ - * `B. Berkels et al. `_ - * `L. Jones et al. `_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. -NXevent_data_em: - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - event_identifier: - doc: | - Reference to a specific state and setting of the microscope. - event_type: - doc: | - Which specific event/measurement type. Examples are: - - * In-lens/backscattered electron, usually has quadrants - * Secondary_electron, image, topography, fractography, overview images - * Backscattered_electron, image, Z or channeling contrast (ECCI) - * Bright_field, image, TEM - * Dark_field, image, crystal defects - * Annular dark field, image (medium- or high-angle), TEM - * Diffraction, image, TEM, or a comparable technique in the SEM - * Kikuchi, image, SEM EBSD and TEM diffraction - * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) - * Electron energy loss spectra for points, lines, surfaces, TEM - * Auger, spectrum, (low Z contrast element composition) - * Cathodoluminescence (optical spectra) - * Ronchigram, image, alignment utility specifically in TEM - * Chamber, e.g. TV camera inside the chamber, education purposes. - - This field may also be used for storing additional information about the event. - (NXimage_set): - (NXspectrum_set): - (NXinstrument): - (NXuser): - (NXinteraction_vol_em): - # a collection of images take and group under this event - # NEW ISSUE: should this only be one instance for a given event? - # (NXimage_set_em_se): - # (NXimage_set_em_bse): - # (NXimage_set_em_ecci): - # (NXimage_set_em_bf): - # (NXimage_set_em_df): - # (NXimage_set_em_adf): - # (NXimage_set_em_kikuchi): - # (NXimage_set_em_diffrac): - # (NXspectrum_set_em_xray): - # (NXspectrum_set_em_eels): - # (NXspectrum_set_em_auger): - # (NXspectrum_set_em_cathodolum): - # (NXimage_set_em_ronchigram): - # (NXimage_set_em_chamber): - # a collection of specific details about state of the microscope - diff --git a/contributed_definitions/nyaml/NXevent_data_em_set.yaml b/contributed_definitions/nyaml/NXevent_data_em_set.yaml deleted file mode 100644 index b0ec49f075..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_em_set.yaml +++ /dev/null @@ -1,8 +0,0 @@ -category: base -doc: | - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. -NXevent_data_em_set: - (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml deleted file mode 100644 index 4f01979e03..0000000000 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ /dev/null @@ -1,17 +0,0 @@ -category: base -doc: | - Details about a component as defined by its manufacturer. -NXfabrication: - vendor: - doc: Company name of the manufacturer. - model: - doc: Version or model of the component named by the manufacturer. - identifier: - doc: | - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. - capability: - doc: | - Free-text list with eventually multiple terms of - functionalities which the component offers. - # NEW ISSUE: Define a bag of controlled words and use only these. Examples are Feg, Astar, OmegaFilter. diff --git a/contributed_definitions/nyaml/NXfiber.yaml b/contributed_definitions/nyaml/NXfiber.yaml deleted file mode 100644 index 29201d6a7f..0000000000 --- a/contributed_definitions/nyaml/NXfiber.yaml +++ /dev/null @@ -1,160 +0,0 @@ -# A draft of a new base class to describe an optical fiber (e.g. glass fiber) - -category: base -symbols: - N_spectrum_core: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the core material is given. - N_spectrum_clad: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the cladding material is given. - N_spectrum_attenuation: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - attenuation curve is given. - -doc: | - An optical fiber, e.g. glass fiber. - - Specify the quantities that define the fiber. Fiber optics are described in - detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for - example. - -NXfiber: - description: - exists: recommended - doc: | - Descriptive name or brief description of the fiber, e.g. by stating its - dimension. The dimension of a fiber can be given as 60/100/200 which - refers to a core diameter of 60 micron, a clad diameter of 100 micron, - and a coating diameter of 200 micron. - - type: - doc: | - Type/mode of the fiber. Modes of fiber transmission are shown in - Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). - enumeration: - [ - "single mode", - "multimode graded index", - "multimode step index" - ] - - dispersion_type: - doc: Type of dispersion. - enumeration: - [ - "modal", - "material", - "chromatic" - ] - dispersion(NX_FLOAT): - doc: | - Spectrum-dependent (or refractive index-dependent) dispersion of the - fiber. Specify in ps/nm*km. - unit: NX_TIME - dimensions: - rank: 1 - dim: - [ - [1, N_spectrum_core] - ] - - core(NXsample): - doc: | - Core of the fiber, i.e. the part of the fiber which transmits the light. - core_material: - doc: Specify the material of the core of the fiber. - core_diameter(NX_FLOAT): - doc: Core diameter of the fiber (e.g. given in micrometer). - unit: NX_LENGTH - core_index_of_refraction(NX_FLOAT): - doc: | - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum_core] - ] - - cladding(NXsample): - doc: | - Core of the fiber, i.e. the part of the fiber which transmits the light. - clad_material: - doc: Specify the material of the core of the fiber. - clad_diameter(NX_FLOAT): - doc: Clad diameter of the fiber (e.g. given in micrometer). - unit: NX_LENGTH - clad_index_of_refraction(NX_FLOAT): - doc: | - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum_clad] - ] - - coating(NXsample): - doc: Coating of the fiber. - coating_material: - doc: Specify the material of the coating of the fiber. - coating_diameter(NX_FLOAT): - doc: Outer diameter of the fiber (e.g. given in micrometer). - unit: NX_LENGTH - - length(NX_FLOAT): - doc: Length of the fiber. - unit: NX_LENGTH - - spectral_range(NX_FLOAT): - exists: recommended - doc: | - Spectral range for which the fiber is designed. Enter the minimum and - maximum values (lower and upper limit) of the wavelength range. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1,2]] - \@units: - doc: | - Unit of spectral array (e.g. nanometer or angstrom for wavelength, or - electronvolt for energy etc.). - - transfer_rate(NX_FLOAT): - doc: Transfer rate of the fiber (in GB per second). - unit: NX_ANY - \@units: - doc: GB/s - - numerical_aperture(NX_FLOAT): - doc: Numerical aperture (NA) of the fiber. - unit: NX_UNITLESS - - attenuation(NX_FLOAT): - doc: Wavelength-dependent attenuation of the fiber (specify in dB/km). - unit: NX_ANY - dimensions: - rank: 1 - dim: - [ - [1, N_spectrum_attenuation] - ] - \@units: - doc: Use dB/km. - enumeration: - [dB/km] - - power_loss(NX_FLOAT): - doc: Power loss of the fiber in percentage. - unit: NX_UNITLESS - - acceptance_angle(NX_FLOAT): - doc: Acceptance angle of the fiber. - unit: NX_ANGLE diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.yaml b/contributed_definitions/nyaml/NXgraph_edge_set.yaml deleted file mode 100644 index fb3759ee00..0000000000 --- a/contributed_definitions/nyaml/NXgraph_edge_set.yaml +++ /dev/null @@ -1,69 +0,0 @@ -category: base -doc: | - A set of (eventually directed) edges which connect nodes/vertices of a graph. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_edges: The number of edges. -NXgraph_edge_set: - number_of_edges(NX_POSINT): - doc: Total number of edges, counting eventual bidirectional edges only once. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish edges for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_edges]] - directionality(NX_INT): - doc: | - Specifier whether each edge is non-directional, one-directional, - or bidirectional. Use the smallest available binary representation - which can store three different states: - - * 0 / state 0x00 is non-directional - * 1 / state 0x01 is one-directional - * 2 / state 0x02 is bi-directional - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_edges]] - node_pair(NX_INT): - doc: | - Pairs of node/vertex identifier. Each pair represents the connection - between two nodes. - - In the case that the edge is non- or bi-directional - node identifier should be stored in ascending order is preferred. - - In the case of one-directional, for each pair the identifier of the source - node is the first entry in the pair. The identifier of the target is the - second entry in the pair, i.e. the pair encodes the information as - if one traverses the edge from the source node walking to the target node. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_edges], [2, 2]] - is_a: - doc: | - A human-readable qualifier which type or e.g. class instance the - edge is an instance of. - dimensions: - rank: 1 - dim: [[1, c]] - label: - doc: A human-readable label/caption/tag for the edge. - dimensions: - rank: 1 - dim: [[1, n_edges]] diff --git a/contributed_definitions/nyaml/NXgraph_node_set.yaml b/contributed_definitions/nyaml/NXgraph_node_set.yaml deleted file mode 100644 index 3bb225aef9..0000000000 --- a/contributed_definitions/nyaml/NXgraph_node_set.yaml +++ /dev/null @@ -1,48 +0,0 @@ -category: base -doc: | - A set of nodes/vertices in space representing members of a graph. -# a graph in which space d-dimensional, categorical, at all a metric one? -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality of the graph. Eventually use one for categorical. - c: The cardinality of the set, i.e. the number of nodes/vertices of the graph. -NXgraph_node_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - nodes. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish nodes for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - is_a: - doc: | - A human-readable qualifier which type or e.g. class instance the - node is an instance of. As e.g. a NeXus application definition is a - graph, more specifically a hierarchical directed labelled property graph, - instances which are groups like NXgraph_node_set could have an is_a - qualifier reading NXgraph_node_set. - dimensions: - rank: 1 - dim: [[1, c]] - label: - doc: A human-readable label/caption/tag of the graph. - dimensions: - rank: 1 - dim: [[1, c]] -# how to handle arrays which are compressed? This can be useful for instance -# if there are substantially fewer disjoint labels than c \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXgraph_root.yaml b/contributed_definitions/nyaml/NXgraph_root.yaml deleted file mode 100644 index 2bdee47d39..0000000000 --- a/contributed_definitions/nyaml/NXgraph_root.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - An instance of a graph. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXgraph_root: - nodes(NXgraph_node_set): - relation(NXgraph_edge_set): - # further attributes diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml deleted file mode 100644 index a904e1bb5f..0000000000 --- a/contributed_definitions/nyaml/NXibeam_column.yaml +++ /dev/null @@ -1,93 +0,0 @@ -category: base -doc: | - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. `_ - * `E. I. Preiß et al. `_ - * `J. F. Ziegler et al. `_ - * `J. Lili `_ - -# symbols: -# doc: The symbols used in the schema to specify e.g. variables. -NXibeam_column: - (NXfabrication): - ion_source(NXsource): - doc: The source which creates the ion beam. - name: - doc: Given name/alias for the ion gun. - emitter_type: - doc: | - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - enumeration: [liquid_metal, plasma, gas_field, other] - description: - doc: | - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - probe(NXion): - doc: | - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - # NEW ISSUE: use NXion instead - brightness(NX_FLOAT): - doc: Average/nominal brightness - unit: NX_ANY - # \@units: A/cm*sr - # NEW ISSUE: (at which location?). - current(NX_FLOAT): - doc: Charge current - unit: NX_CURRENT - voltage(NX_FLOAT): - doc: Ion acceleration voltage upon source exit and entering the vacuum flight path. - unit: NX_VOLTAGE - ion_energy_profile(NX_NUMBER): - unit: NX_ENERGY - (NXtransformations): - doc: Affine transformation which detail the arrangement in the microscope relative to the optical axis and beam path. - # NEW ISSUE: details about the life/up-time of the source - # relevant from maintenance point of view - (NXaperture_em): - (NXlens_em): - # ibeam_deflector(NXscanbox_em): - (NXsensor): #for column pressure, temperature, magnetic fields etc - (NXbeam): - doc: | - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - # all these components of the FIB system are usually controlled via an - # instrment control software that is often part of the e.g. microscope control # software or at least linked to this software. - # NEW ISSUE: scan_align(NXprocess): - # NEW ISSUE: milling_plan(NXprocess): - # doc: Description of the program and sequence of sample positions sputtered. - # in here we can store time-dependent quantities - # NEW ISSUE: for documentation of charge compensation - # (NXtransformation): - # doc: | - # A right-handed Cartesian coordinate system is used whose positive - # z-axis points in the direction of the ion beam, i.e. towards the - # sample. For modelling ion milling it is relevant to document the - # illumination vector. NXtransformations offers a place to store how the - # ion gun coordinate system has to be rotated to align its positive z-axis - # with the positive z-axis of e.g. the electron beam and ion beam - # respectively. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml deleted file mode 100644 index ef8076480e..0000000000 --- a/contributed_definitions/nyaml/NXimage_set.yaml +++ /dev/null @@ -1,60 +0,0 @@ -category: base -doc: | - Container for reporting a set of images taken. -symbols: - n_images: Number of images in the stack. - n_y: Number of pixel per image in the slow direction. - n_x: Number of pixel per image in the fast direction. -NXimage_set: - (NXprocess): - doc: | - Details how images were processed from the detector readings. - source: - doc: | - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - mode: - doc: | - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - detector_identifier: - doc: | - Link or name of an NXdetector instance with which the data were collected. - (NXprogram): - stack(NXdata): - doc: | - Image (stack). - data_counts(NX_NUMBER): - doc: Image intensity values. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_image_identifier(NX_UINT): - doc: Image identifier - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_images]] - \@long_name: - doc: Image identifier. - axis_y(NX_NUMBER): - doc: Pixel coordinate center of mass along y direction. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Coordinate along y direction. - axis_x(NX_NUMBER): - doc: Pixel coordinate center of mass along x direction. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml deleted file mode 100644 index 371515db31..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml +++ /dev/null @@ -1,89 +0,0 @@ -category: base -doc: | - Container for reporting a set of annular dark field images. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. -symbols: - n_images: Number of images in the stack. - n_y: Number of pixel per image in the slow direction. - n_x: Number of pixel per image in the fast direction. -NXimage_set_em_adf: - (NXprocess): - doc: | - Details how (HA)ADF images were processed from the detector readings. - source: - doc: | - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXimage_set_em_adf were loaded during - parsing to represent them in e.g. databases. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - program: - doc: | - Commercial or otherwise given name to the program which was used - to process detector data into the adf image(s). - \@version: - doc: | - Program 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. - adf_inner_half_angle(NX_FLOAT): - doc: Annulus inner half angle - unit: NX_ANGLE - adf_outer_half_angle(NX_FLOAT): - doc: Annulus outer half angle - unit: NX_ANGLE - stack(NXdata): - doc: | - Annular dark field image stack. - # \@signal: intensity - # \@axes: [image_id, ypos, xpos] - # \@xpos_indices: 2 - # \@ypos_indices: 1 - # \@image_indices: 0 - data_counts(NX_NUMBER): - doc: Image intensity values. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_image_identifier(NX_UINT): - doc: | - Image identifier - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_images]] - \@long_name: - doc: Image ID. - axis_y(NX_NUMBER): - doc: | - Pixel center of mass along y direction. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - doc: | - Pixel center of mass along x direction. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml deleted file mode 100644 index 2711ff2a9a..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml +++ /dev/null @@ -1,139 +0,0 @@ -category: base -symbols: - n_sc: Number of scanned points. Scan point may have none, one, or more pattern. - n_p: Number of diffraction pattern. - n_y: Number of pixel per Kikuchi pattern in the slow direction. - n_x: Number of pixel per Kikuchi pattern in the fast direction. -doc: | - Measured set of electron backscatter diffraction data, aka Kikuchi pattern. - Kikuchi pattern are the raw data for computational workflows in the field - of orientation (imaging) microscopy. The technique is especially used in - materials science and materials engineering. - - Based on a fuse of the `M. A. Jackson et al. `_ - of the DREAM.3D community and the open H5OINA format of Oxford Instruments - `P. Pinard et al. `_ - - EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional - orientation microscopy. So-called serial section analyses. For a detailed - overview of these techniques see e.g. - - * `M. A. Groeber et al. `_ - * `A. J. Schwartz et al. `_ - * `P. A. Rottman et al. `_ - - With serial-sectioning this involves however always a sequence of measuring, - milling. In this regard, each serial section (measuring) and milling - is an own NXevent_data_em instance and thus there such a three-dimensional - characterization should be stored as a set of two-dimensional data, - with as many NXevent_data_em instances as sections were measured. - - These measured serial sectioning images need virtually always post-processing - to arrive at the aligned and cleaned image stack before a respective digital - model of the inspected microstructure can be analyzed. The resulting volume - is often termed a so-called (representative) volume element (RVE). - Several software packages are available for performing this post-processing. - For now we do not consider metadata of these post-processing steps - as a part of this base class because the connection between the large variety - of such post-processing steps and the measured electron microscopy data - is usually very small. - - If we envision a (knowledge) graph for EBSD it consists of individual - sub-graphs which convey information about the specimen preparation, - the measurement of the specimen in the electron microscope, - the indexing of the collected Kikuchi pattern stack, - eventual post-processing of the indexed orientation image - via similarity grouping algorithms to yield (grains, texture). - Conceptually these post-processing steps are most frequently - serving the idea to reconstruct quantitatively so-called - microstructural features (grains, phases, interfaces). Materials scientists - use these features according to the multi-scale materials modeling paradigm - to infer material properties. They do so by quantifying correlations between - the spatial arrangement of the features, their individual properties, - and (macroscopic) properties of materials. -NXimage_set_em_kikuchi: - # a collection of pattern-related metadata - (NXprocess): - doc: | - Details how Kikuchi pattern were processed from the detector readings. - Scientists interested in EBSD should inspect the respective NXem_ebsd - application definition which can be used as a partner application definition - to detail substantially more details to this processing. - stack(NXdata): - doc: | - Collected Kikuchi pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably by the instrument - given the way how the instrument and control software was configured - for your microscope session. - scan_point_identifier(NX_UINT): - doc: | - Array which resolves the scan point to which each pattern belongs. - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belong to which scan point. - In an example we may assume we collected three scan points. For the first - we measure one pattern, for the second we measure three pattern, - for the last we measure no pattern. - The values of scan_point_identifier will be 0, 1, 1, 1, as we have - measured four pattern in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. Use compressed - arrays allows to store the scan_point_identifier efficiently. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_p]] - data_counts(NX_NUMBER): - doc: | - Signal intensity. For so-called three-dimensional or serial sectioning - EBSD it is necessary to follow a sequence of specimen surface preparation - and data collection. In this case users should collect the data for each - serial sectioning step in an own instance of NXimage_set_em_kikuchi. - All eventual post-processing of these measured data should be documented - via NXebsd, resulting microstructure representations should be stored - as NXms. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_p], [2, n_y], [3, n_x]] - # n_p fast 2, n_y faster 1, n_x fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: Kikuchi pattern intensity - # \@signal: intensity - # \@axes: [pattern_identifier, ypos, xpos] - # \@xpos_indices: 0 - # \@ypos_indices: 1 - # \@pattern_identifier_indices: 2 - pattern_identifier(NX_UINT): - doc: | - Pattern are enumerated starting from 0 to n_p - 1. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_p]] - \@long_name: - doc: Kikuchi pattern identifier - axis_y(NX_NUMBER): - doc: Pixel coordinate along the y direction. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Label for the y axis - axis_x(NX_NUMBER): - doc: Pixel coordinate along the x direction. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Label for the x axis - # maybe time code data when the pattern were taken? - # key is it all happened in between the time defined in NXevent_data_em - # optionally link to NXebsd instance? diff --git a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml deleted file mode 100644 index 916ca1dacc..0000000000 --- a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml +++ /dev/null @@ -1,75 +0,0 @@ -category: base -doc: | - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. `_ - * `J. Bünger et al. `_ -type: group -(NXobject)NXinteraction_vol_em: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 29b6daff56a280c88764ab6e66b9b4e67228cd110dbb825726104e01550aeeb7 -# -# -# -# -# Base class for storing details about a modelled shape of interaction volume. -# -# The interaction volume is mainly relevant in scanning electron microscopy -# when the sample is thick enough so that the beam is unable to illuminate -# through the specimen. -# Computer models like Monte Carlo or molecular dynamics / electron beam -# interaction simulations can be used to qualify and/or quantify the shape of -# the interaction volume. -# -# Explicit or implicit descriptions are possible. -# -# * An implicit description is via a set of electron/specimen interactions -# represented ideally as trajectory data from the computer simulation. -# * An explicit description is via an iso-contour surface using either -# a simulation grid or a triangulated surface mesh of the approximated -# iso-contour surface evaluated at specific threshold values. -# Iso-contours could be computed from electron or particle fluxes through -# an imaginary control surface (the iso-surface). -# Threshold values can be defined by particles passing through a unit control -# volume (electrons) or energy-levels (e.g. the case of X-rays). -# Details depend on the model. -# * Another explicit description is via theoretical models which may -# be relevant e.g. for X-ray spectroscopy -# -# Further details on how the interaction volume can be quantified -# is available in the literature for example: -# -# * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ -# * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ -# -# -# -# diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml deleted file mode 100644 index 670bff238d..0000000000 --- a/contributed_definitions/nyaml/NXion.yaml +++ /dev/null @@ -1,116 +0,0 @@ -category: base -doc: | - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ivecmax: | - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - n_ranges: | - Number of mass-to-charge-state-ratio range intervals for ion type. -NXion: - identifier: - doc: | - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - identifier_type: - doc: | - How can the identifier be resolved? - enumeration: [inchi] - ion_type(NX_UINT): - doc: | - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - unit: NX_UNITLESS - isotope_vector(NX_UINT): - doc: | - 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) `_ - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, 1], [2, n_ivecmax]] - nuclid_list(NX_UINT): - doc: | - 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. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, 2], [2, n_ivecmax]] - color: - doc: | - Color code used for visualizing such ions. - volume(NX_FLOAT): - doc: | - 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. - unit: NX_VOLUME - charge(NX_FLOAT): - doc: | - Charge of the ion. - unit: NX_CHARGE - charge_state(NX_INT): - doc: | - 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 `_ - unit: NX_UNITLESS - name: - doc: | - 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. - mass_to_charge_range(NX_FLOAT): - doc: | - 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. - unit: NX_ANY - # \@units: Da - dimensions: - rank: 2 - dim: [[1, n_ranges], [2, 2]] diff --git a/contributed_definitions/nyaml/NXisocontour.yaml b/contributed_definitions/nyaml/NXisocontour.yaml deleted file mode 100644 index 9bdb30cb13..0000000000 --- a/contributed_definitions/nyaml/NXisocontour.yaml +++ /dev/null @@ -1,30 +0,0 @@ -category: base -doc: | - Computational geometry description of isocontouring/phase-fields in Euclidean space. - - Iso-contouring algorithms such as MarchingCubes and others are frequently - used to segment d-dimensional regions into regions where intensities are - lower or higher than a threshold value, the so-called isovalue. - - Frequently in computational materials science phase-field methods are - used which generate data on discretized grids. Isocontour algorithms - are often used in such context to pinpoint the locations of microstructural - features from this implicit phase-field-variable-based description. - - One of the key intentions of this base class is to provide a starting point - for scientists from the phase-field community (condensed matter physicists, - and materials engineers) to incentivize that also phase-field simulation - data could be described with NeXus, provided base classes such as the this one - get further extend according to the liking of the phase-field community. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality of the description. -NXisocontour: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - grid(NXcg_grid): - doc: | - The discretized grid on which the iso-contour algorithm operates. - isovalue(NX_NUMBER): - doc: The threshold or iso-contour value. - unit: NX_ANY diff --git a/contributed_definitions/nyaml/NXiv_temp.yaml b/contributed_definitions/nyaml/NXiv_temp.yaml deleted file mode 100644 index 31125a4a08..0000000000 --- a/contributed_definitions/nyaml/NXiv_temp.yaml +++ /dev/null @@ -1,40 +0,0 @@ -doc: | - Application definition for temperature-dependent IV curve measurements. - - In this application definition, times should be specified always together - with an UTC offset. - - This is the application definition describing temperature dependent IV curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. -symbols: - n_different_temperatures: "Number of different temperature setpoints used in the experiment." - n_different_voltages: "Number of different voltage setpoints used in the experiment." -category: application -NXiv_temp(NXsensor_scan): - (NXentry): - definition: - enumeration: [NXiv_temp] - (NXinstrument): - (NXenvironment): - doc: | - Describes an environment setup for a temperature-dependent IV measurement experiment. - - The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. - voltage_controller(NXsensor): - temperature_controller(NXsensor): - current_sensor(NXsensor): - (NXdata): - doc: | - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - temperature(NX_NUMBER): - voltage(NX_NUMBER): - current(NX_NUMBER): - dimensions: - rank: 2 - dim: [[1, n_different_temperatures], [2, n_different_voltages]] diff --git a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml deleted file mode 100644 index f2e4f4f738..0000000000 --- a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml +++ /dev/null @@ -1,113 +0,0 @@ -category: application -doc: | - Grinding and polishing of a sample using abrasives in a wet lab. - Manual procedures, electro-chemical, vibropolishing. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXlab_electro_chemo_mechanical_preparation: - (NXentry): - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently - \@version: - doc: Version specifier of this application definition. - definition: - doc: Official NeXus NXDL schema with which this file was written. - enumeration: [NXlab_electro_chemo_mechanical_preparation] - workflow_step_identifier(NX_UINT): - workflow_step_description: - SAMPLE(NXsample): # identifier and the usual stuff, and conditions, temperature, humidity, pH, atmosphere and its pressure - exists: [min, 1, max, 1] - USER(NXuser): - exists: [min, 1, max, infty] - # (NXlab_grinding_machine): - grinding_machine(NXfabrication): - vendor: - model: - identifier: - exists: recommended - GRINDING_STEP(NXprocess): - doc: | - A preparation step performed by a human or a robot/automated system. - # maybe a user per step as sometimes samples are prepared by more than - # one person or not each person performs all polishing steps - sequence_index(NX_POSINT): - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - abrasive_medium_carrier: - doc: | - Carrier/plate used on which the abrasive/(lubricant) mixture was applied. - # enumeration: [plate] - # controlled vocabulary items - abrasive_medium: - doc: | - Medium on the abrasive_medium_carrier (cloth or grinding plate) - whereby material is abrasively weared. - # enumeration: [SiC180] - # controlled vocabulary items or instance of chemical, need for free-text? - # also need for free-text in subsequent files? - lubricant: - doc: | - Lubricant - # enumeration: [none, water, ethanol, oil] - # from a list of controlled vocabulary items, or instance of chemical - # etching/corrosive attack, tracking the environment, what can we - # learn from our colleagues within NFDI4Cat, NFDI4Chem, and NFDI-MatWerk? - rotation_control: - doc: | - Qualitative statement how the revelation of the machine was configured. - If the rotation was controlled manually, e.g. by turning knobs - choose manual and estimate the nominal average rotation. - If the rotation was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal rotation. - If programmed use rotation_history (e.g. for automated/robot systems). - enumeration: [undefined, manual, fixed, programmed] - force_control: - doc: | - Qualitative statement how the (piston) force with which the sample - was pressed into/against the abrasive medium was controlled if at all. - If the force was controlled manually e.g. by turning knobs - choose manual and estimate nominal average force. - If the force was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal force. - If programmed use force_history (e.g. for automated/robot systems). - enumeration: [undefined, manual, fixed, programmed] - time_control: - doc: | - Qualitative statement for how long (assuming regular uninterrupted) - preparation at the specified conditions the preparation step was - applied. - enumeration: [undefined, manual, fixed, programmed] - rotation(NX_NUMBER): - doc: | - Turns per unit time. - unit: NX_FREQUENCY - # rotation_history(NX_NUMBER): - force(NX_NUMBER): - doc: | - Force exerted on the sample to press it into the abrasive. - unit: NX_ANY - # force-history(NX_NUMBER): - time(NX_NUMBER): - doc: | - Seconds - unit: NX_TIME - removal: - doc: | - Qualitative statement how the material removal was characterized. - enumeration: [undefined, estimated, measured] - thickness_reduction(NX_NUMBER): - doc: | - How thick a layer was removed. - unit: NX_LENGTH - # time_history(NX_NUMBER): - # SENSOR_SCAN(NXsensor_scan): - # electro-chemical preparation is nothing but an I(V) curve within - # a corrosive medium, eventually some wet lab steps have characteristics - # of pure grinding, mechanical polishing, or a mixture with corrosive - # attack - CLEANING_STEP(NXprocess): - doc: | - A preparation step performed by a human or a robot/automated system - with the aim to remove residual abrasive medium from the specimen surface. - sequence_index(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml deleted file mode 100644 index 79a404dab6..0000000000 --- a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml +++ /dev/null @@ -1,51 +0,0 @@ -category: application -doc: | - Embedding of a sample in a medium for easing processability. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -NXlab_sample_mounting: - (NXentry): - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXlab_sample_mounting] - SAMPLE(NXsample): # identifier and the usual stuff, and conditions, temperature, humidity, pH, atmosphere and its pressure - exists: [min, 1, max, 1] - USER(NXuser): - exists: [min, 1, max, infty] - start_time(NX_DATE_TIME): # how to define ? - end_time(NX_DATE_TIME): # how to define (epoxy hardening is a continuous process) ? - # (NXlab_mounting_machine): - mounting_machine(NXfabrication): - vendor: - model: - identifier: - exists: recommended - mounting_method: - doc: | - Qualitative statement how the sample was mounted. - enumeration: [cold_mounting, hot_mounting] - embedding_medium: # or material from controlled vocabulary list - doc: | - Type of material. - enumeration: [resin, epoxy] - electrical_conductivity(NX_FLOAT): - doc: | - Electrical conductivity of the embedding medium. - unit: NX_ANY - # temperature control of the mounting (e.g. relevant when hot_mounting Al) - # cleaning procedures - # a descriptor of the shape of the specimen - # borrow from NXlab_thermo_mechanical_processing to document the external - # stimuli (eventually) applied during mounting - # temperature, mechanical, magnetic, electro-magnetic, are externally - # applied stimuli on the sample, can we use one master schema? - # e.g. one can even store NXcg_polyhedron_set and NXcg_face_list_data_structure - # instances to keep track of the geometry of specific instrument and how - # the samples were arranged in these - # key question is which steps has the sample experienced? \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml deleted file mode 100644 index d8e0cc4e79..0000000000 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ /dev/null @@ -1,50 +0,0 @@ -category: base -doc: | - 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 `_ -NXlens_em: - type: - doc: Qualitative type of lens with respect to the number of pole pieces. - enumeration: [single, double, quadrupole, hexapole, octupole] - name: - doc: | - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - manufacturer_name: - doc: Name of the manufacturer who built/constructed the lens. - (NXfabrication): - model: - doc: Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens. - description: - doc: Ideally an identifier, persistent link, or free text which gives further details about the lens. - voltage(NX_NUMBER): - doc: Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array. - unit: NX_VOLTAGE - current(NX_NUMBER): - doc: Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array. - unit: NX_CURRENT - value(NX_NUMBER): - doc: | - 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. - unit: NX_ANY - depends_on: - doc: Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - 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/nyaml/NXlens_opt.yaml b/contributed_definitions/nyaml/NXlens_opt.yaml deleted file mode 100644 index 9669433ddd..0000000000 --- a/contributed_definitions/nyaml/NXlens_opt.yaml +++ /dev/null @@ -1,140 +0,0 @@ -# A draft of a new base class describing an optical lens -# (Note: NXlens_em describes an electro-magnetic lens or a compound lens) - -category: base -symbols: - N_spectrum: | - Size of the wavelength array for which the refractive index of the material - is given. - N_spectrum_coating: | - Size of the wavelength array for which the refractive index of the coating - is given. - N_spectrum_RT: | - Size of the wavelength array for which the reflectance or transmission of - the lens is given. - -doc: Description of an optical lens. - -NXlens_opt: - type: - doc: Type of the lens (e.g. concave, convex etc.). - enumeration: - [ - "biconcave", - "plano-concave", - "convexo-concave", - "biconvex", - "plano-convex", - "concavo-convex", - "Fresnel lens", - "other" - ] - other_type: - doc: If you chose 'other' as type specify what it is. - - chromatic(NX_BOOLEAN): # chromatic or achromatic - doc: Is it a chromatic lens? - - lens_diameter(NX_NUMBER): - doc: Diameter of the lens. - unit: NX_LENGTH - - substrate(NXsample): - doc: | - Properties of the substrate material of the lens. If the lens has a - coating specify the coating material and its properties in 'coating'. - substrate_material: - doc: Specify the substrate material of the lens. - substrate_thickness(NX_NUMBER): - doc: Thickness of the lens substrate at the optical axis. - unit: NX_LENGTH - index_of_refraction(NX_NUMBER): - doc: | - Complex index of refraction of the lens material. Specify at given - wavelength (or energy, wavenumber etc.) values. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum] - ] - - COATING(NXsample): - # Used captial letters for COATING so that more than one can be defined if - # the lens has different coatings on the front and back side. - doc: | - If the lens has a coating describe the material and its properties. - Some basic information can be found e.g. [here] - (https://www.opto-e.com/basics/reflection-transmission-and-coatings). - If the back and front side of the lens are coated with different - materials, use separate COATING(NXsample) fields to describe the coatings - on the front and back side, respectively. For example: - coating_front(NXsample) and coating_back(NXsample). - coating_type: - doc: | - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - coating_material: - doc: Describe the coating material (e.g. MgF2). - coating_thickness(NX_NUMBER): - doc: Thickness of the coating. - unit: NX_LENGTH - index_of_refraction_coating(NX_NUMBER): - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum_coating] - ] - - reflectance: - doc: Reflectance of the lens at given spectral values. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: - [ - [1, N_spectrum_RT] - ] - - transmission: - doc: Transmission of the lens at given spectral values. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: - [ - [1, N_spectrum_RT] - ] - - focal_length(NX_NUMBER): - exists: recommended - doc: | - Focal length of the lens on the front side (first value), i.e. where the - beam is incident, and on the back side (second value). - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 2]] - - curvature_radius_FACE(NX_NUMBER): - exists: recommended - doc: | - Curvature radius of the lens. - Instead of 'FACE' in the name of this field, the user is advised to - specify for which surface (e.g. front or back) the curvature is provided: - e.g. curvature_front or curvature_back. The front face is the surface on - which the light beam is incident, while the back face is the one from - which the light beam exits the lens. - unit: NX_LENGTH - - Abbe_number(NX_NUMBER): - doc: Abbe number (or V-number) of the lens. - unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml deleted file mode 100644 index 317325e62a..0000000000 --- a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml +++ /dev/null @@ -1,102 +0,0 @@ -category: base -doc: | - definition for a magnetic kicker. -type: group -NXmagnetic_kicker(NXobject): - description(NX_CHAR): - doc: | - extended description of the kicker. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - timing(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0', 'max', '1'] - doc: | - kicker timing as defined by ``description`` attribute - \@description: - type: NX_CHAR - set_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on supply. - read_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from supply. - value: - unit: NX_CURRENT - set_voltage(NX_FLOAT): - unit: NX_VOLTAGE - exists: ['min', '0', 'max', '1'] - doc: | - voltage set on supply. - read_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 34b7476f76592e9226269d3b02886646193836d024fce656135de8c230c8119c -# -# -# -# -# definition for a magnetic kicker. -# -# extended description of the kicker. -# -# -# define position of beamline element relative to production target -# -# -# kicker timing as defined by ``description`` attribute -# -# -# -# current set on supply. -# -# -# current read from supply. -# -# -# -# voltage set on supply. -# -# -# voltage read from supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml deleted file mode 100644 index b54624b2d6..0000000000 --- a/contributed_definitions/nyaml/NXmanipulator.yaml +++ /dev/null @@ -1,41 +0,0 @@ -category: base -doc: - "Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments." -NXmanipulator: - name(NX_CHAR): - doc: "Name of the manipulator." - description(NX_CHAR): - doc: "A description of the manipulator." - type(NX_CHAR): - doc: "Type of manipulator, Hexapod, Rod, etc. " - cryocoolant(NX_BOOLEAN): - doc: "Is cryocoolant flowing through the manipulator?" - cryostat_temperature(NX_FLOAT): - doc: "Temperature of the cryostat (coldest point)" - unit: NX_TEMPERATURE - heater_power(NX_FLOAT): - doc: "Power in the heater for temperature control." - unit: NX_POWER - sample_temperature(NX_FLOAT): - doc: "Temperature at the closest point to the sample. - This field may also be found in NXsample if present." - unit: NX_TEMPERATURE - drain_current(NX_FLOAT): - doc: "Current to neutralize the photoemission current. - This field may also be found in NXsample if present." - unit: NX_CURRENT - sample_bias(NX_FLOAT): - doc: "Possible bias of the sample with trespect to analyser ground. - This field may also be found in NXsample if present." - unit: NX_CURRENT - (NXpositioner): - doc: "Class to describe the motors that are used in the manipulator" - depends_on(NX_CHAR): - doc: "Refers to the last transformation specifying the positon of the manipulator in the NXtransformations chain." - (NXtransformations): - doc: - "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/nyaml/NXmatch_filter.yaml b/contributed_definitions/nyaml/NXmatch_filter.yaml deleted file mode 100644 index 06f3a0c759..0000000000 --- a/contributed_definitions/nyaml/NXmatch_filter.yaml +++ /dev/null @@ -1,26 +0,0 @@ -category: base -doc: | - Settings of a filter to select or remove entries based on their value. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_values: How many different match values does the filter specify. -NXmatch_filter: - method: - doc: | - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - enumeration: [whitelist, blacklist] - match(NX_NUMBER): - doc: | - Array of values to filter according to method. For example if the filter - specifies [1, 5, 6] and method is whitelist, only entries with values - matching 1, 5 or 6 will be processed. All other entries will be filtered - out. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_values]] diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml deleted file mode 100644 index 6b82c6233f..0000000000 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ /dev/null @@ -1,234 +0,0 @@ -#Pincelli, Rettig, Arora at fhi-berlin.mpg.de, Dobener at hu-berlin.de, 06/2022 -#Draft version of a NeXus application definition for photoemission, -#It is designed to be extended by other application definitions -#with higher granularity in the data description. - -doc: This is the most general application definition for multidimensional photoelectron spectroscopy. -category: application -NXmpes: - (NXentry): - title: - start_time(NX_DATE_TIME): - doc: "Datetime of the start of the measurement." - definition: - \@version: - enumeration: ["NXmpes"] - (NXuser): - doc: "Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users if relevant is recommended." - name: - doc: "Name of the user." - affiliation: - exists: recommended - doc: "Name of the affiliation of the user at the point in time when the - experiment was performed." - address: - exists: recommended - doc: "Full address (street, street number, ZIP, city, country) of the - user's affiliation." - email: - doc: "Email address of the user." - orcid: - exists: recommended - doc: "Author ID defined by https://orcid.org/." - (NXinstrument): - energy_resolution(NX_FLOAT): - unit: NX_ENERGY - (NXsource): - doc: "The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. - For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on." - type: - enumeration: [ - "Synchrotron X-ray Source", - "Rotating Anode X-ray", - "Fixed Tube X-ray", - "UV Laser", - "Free-Electron Laser", - "Optical Laser", - "UV Plasma Source", - "Metal Jet X-ray", - "HHG laser" - ] - name: - probe: - doc: "Type of probe. In photoemission it's always photons, so the full NIAC list is restricted." - enumeration: ["x-ray","ultraviolet", "visible light"] - (NXbeam): - distance(NX_NUMBER): - doc: "Distance of the point of evaluation of the beam from the sample surface." - unit: NX_LENGTH - incident_energy(NX_FLOAT): - unit: NX_ENERGY - incident_energy_spread(NX_NUMBER): - exists: recommended - unit: NX_ENERGY - incident_polarization(NX_NUMBER): - exists: recommended - unit: NX_ANY - (NXelectronanalyser): - description: - energy_resolution(NX_FLOAT): - exists: recommended - doc: "Energy resolution of the analyser with the current setting. May be linked from a NXcalibration." - unit: NX_ENERGY - fast_axes(NX_CHAR): - exists: recommended - slow_axes: - exists: recommended - (NXcollectioncolumn): - scheme: - doc: "Scheme of the electron collection column." - enumeration: [ - "Standard", - "Angular dispersive", - "Selective area", - "Deflector", - "PEEM", - "Momentum Microscope" - ] - mode: - exists: recommended - projection: - exists: recommended - field_aperture(NXaperture): - exists: optional - doc: "The size and position of the field aperture inserted in the column. - To add additional or other apertures use the APERTURE group of NXcollectioncolumn." - contrast_aperture(NXaperture): - exists: optional - doc: "The size and position of the contrast aperture inserted in the column. - To add additional or other apertures use the APERTURE group of NXcollectioncolumn." - (NXenergydispersion): - scheme: - enumeration: - [ - "tof", - "hemispherical", - "double hemispherical", - "cylindrical mirror", - "display mirror", - "retarding grid", - ] - pass_energy(NX_FLOAT): - unit: NX_ENERGY - energy_scan_mode: - entrance_slit(NXaperture): - exists: optional - doc: "Size, position and shape of the entrance slit in dispersive analyzers. - To add additional or other slits use the APERTURE group of NXenergydispersion." - exit_slit(NXaperture): - exists: optional - doc: "Size, position and shape of the exit slit in dispersive analyzers. - To add additional or other slits use the APERTURE group of NXenergydispersion." - (NXdetector): - amplifier_type: - exists: recommended - doc: "Type of electron amplifier in the first amplification step." - enumeration: ["MCP", "channeltron"] - # ToDo: Representation of count rate calibration - detector_type: - exists: recommended - doc: "Description of the detector type." - enumeration: ["DLD","Phosphor+CCD","Phosphor+CMOS","ECMOS", "Anode", "Multi-anode"] - (NXdata): # Raw signal without calibrated axes. - exists: recommended - \@signal: - enumeration: ['raw'] - raw(NX_NUMBER): # There is a block of numbers named raw. - doc: "Raw data before calibration." - (NXmanipulator): - exists: optional - doc: "Manipulator for positioning of the sample." - sample_temperature(NX_FLOAT): - exists: recommended - unit: NX_TEMPERATURE - drain_current(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - sample_bias(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - (NXprocess): - doc: "Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using - one or more of the following NXcalibrations" - energy_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an energy calibration been applied?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting." - angular_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an angular calibration been applied?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated angular axis to be used for data plotting." - spatial_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an spatial calibration been applied?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated spatial axis to be used for data plotting." - momentum_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an momentum calibration been applied?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the momentum axis to be used for data plotting." - (NXsample): - name: - chemical_formula: - exists: recommended - doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." - sample_history(NXnote): - exists: recommended - doc: "A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. - Ideally, a full report of the previous operations, in any format (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." - atom_types: - exists: recommended - doc: | - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - preparation_date(NX_DATE_TIME): - exists: recommended - doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." - preparation_description(NXnote): - doc: "Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. - Ideally, a full report of the previous operations, in any format(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." - # Problem: if the temperature is logged, the data is an array of temperature/timestamp pairs. - # the timestamp NX_DATE_TIME structure of the timestamp can not be easily handled by just a field. - # there is a base class for this, NXlog. The NIAC decided to use the same name (temperature) instead of the previous temperature_log. - # how do I explain here in an appdef that temperature can be either NXnumber (single value or scanned array) or a NXlog? - # It seems quite contorted to ask to create a separate timestamp array when we have a base class that handles it more elegantly. - temperature(NX_FLOAT): - doc: "In the case of a fixed temperature measurement this is the scalar temperature of the sample. - In the case of an experiment in which the temperature is changed and recoded, this is an array of length m of temperatures. - This should be a link to - /entry/instrument/manipulator/sample_temperature." - unit: NX_TEMPERATURE - situation: - enumeration: ["vacuum", "inert atmosphere", "oxidising atmosphere", "reducing atmosphere"] - # Similar situation here, ca be a single number or a log. - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - (NXdata): - \@signal: - enumeration: ["data"] # There is an object named data that contains the signal - data(NX_NUMBER): # There is a block of numbers named data. - doc: "Represents a measure of one- or more-dimensional photoemission counts, where - the varied axis may be for example - energy, momentum, spatial coordinate, pump-probe delay, spin index, temperature, etc. - The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." - unit: NX_ANY diff --git a/contributed_definitions/nyaml/NXms.yaml b/contributed_definitions/nyaml/NXms.yaml deleted file mode 100644 index 46c1807f98..0000000000 --- a/contributed_definitions/nyaml/NXms.yaml +++ /dev/null @@ -1,450 +0,0 @@ -# key points to keep in mind when thinking about a general enough description for coarse-graining systems of atoms into -# so-called microstructural features of interest for which we may store also thermodynamic properties or other feature-specific descriptors -# several viewpoints how to coarse-grain are equally justified: grains are useful when there are crystallites with adjoining interfaces and # none, or only some statistical populations of defects and/or some spatially-well defined defects inside these -# however, if grains are build almost only from defects like dislocation walls, it might no longer be useful to define the grains -# as a well identifiable region whose majority volume shows long-range atomic periodicity (so that defining an orientation makes) sense. -# one could then rather describe the set of defects. Alternatively one could describe a material volume by sampling individual so-called -# material points (e.g. in continuum-scale plasticity models) or describe the material volume really from the atoms up -# but there are many terms used in materials engineering which people may want to distinguish which stand however between the scales e.g. -# lattice curvature, this is jargon with some truth in it but curvature has to be build from atoms and defects need to build the curvature -# dislocations are another good example where different research questions demand differently granularized descriptions e.g. -# average density, total line length, per character, per family, line length, curvature, jog, kink density, -# coarse-grainable structural motifs in the dislocation core, atomic structure -# also different scales one would like to distinguish as this is relevant when defects couple/show spatiotemporal correlations -# to specific mechanisms (e.g. phonons) or when defect affect the properties of other defects -# ambiguous choices: is the grain boundary part of the grain or is it an own defect? -# i.e. can/should we store grains as childs of their grain boundary set vs the interface the childs of the grains? -# Depending on the use case we need to have a flexible description which can address a continuum of descriptors: -# important is that one can logically map different features -# Length scale of homogeneity: With the reality of a multi-parameter space of all possible methods and effects and -# different external stimuli applied for real materials, simulations in computational materials science typically focus -# their analysis on a few individual, spatiotemporally constrained effects and boundary conditions for which the simulation -# is formulated, useful, interpretable, and comparable to experiment. -# Data structures for multi-scale materials modeling IMM/ICME are currently diverse because they reflect the above-mentioned needs -# and different views which researchers have on their simulations e.g. DFT (time, length-scale, which electronic effects) -# RVE annealing phenomena at the micrometer scale (pressure, temperature, length scale, interactions considered or not) -# Some regions are well separated spatially (although it can be non-trivial to quantify the distance in a multi-dim parameter space) -# Some simulations are cross-scale (classical MD at the cutting edge with micrometer crystal plasticity microsecond and/or annealing at -# ns time scale) MD with classical vs abinitio-informed potential for studying evolution of mechanisms and phenomena at different length scales -category: application -doc: | - Application definition, spatiotemporal characterization of a microstructure. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_b: | - Number of boundaries of the bounding box or primitive to domain. - n_p: | - Number of parameter required for the chosen orientation parameterization. - c: | - Number of texture components identified. -NXms: # (NXannealing) - (NXentry): - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - # enumeration: [sha_256_hash] - definition: - doc: | - NeXus NXDL schema to which this file conforms. - enumeration: [NXms] - workflow_identifier: - doc: | - Ideally, a (globally) unique persistent identifier - for referring to this experiment or computer simulation. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - workflow_description: - exists: optional - doc: | - Free-text description about the workflow (experiment/analysis/simulation). - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the characterization started. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC included - when the characterization ended. - PROGRAM(NXprogram): - exists: [min, 1, max, infty] - program_name: - \@version: - experiment_or_simulation: - doc: | - Specify if the (characterization) results/data of this instance of an - application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe - a microstructure. - - The term microstructure is used to describe the spatial arrangement of - crystal defects inside a sample/specimen without demanding necessarily - that this structure is mainly at the micron length scale. - Nanostructure and macrostructure are close synonyms. - Material architecture is a narrow synonym. - - Given that microstructure simulations nowadays more and more consider - the atomic arrangement, this application definition can also be used - to describe features at the scale of atoms. - enumeration: [experiment, simulation] - USER(NXuser): - exists: [min, 0, max, infty] - doc: | - Contact information and eventually details of at least one person - involved in creating this result. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is recommended. - name: - doc: Given (first) name and surname of the user. - affiliation: - exists: recommended - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. - address: - exists: recommended - doc: Postal address of the affiliation. - email: - exists: recommended - doc: | - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - orcid: - exists: recommended - doc: | - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - orcid_platform: - exists: recommended - doc: | - Name of the OrcID or ResearcherID where the account - under orcid is registered. - telephone_number: - exists: optional - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - role: - exists: recommended - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - social_media_name: - exists: optional - doc: | - Account name that is associated with the user in social media platforms. - social_media_platform: - exists: optional - doc: | - Name of the social media platform where the account - under social_media_name is registered. - specimen(NXsample): - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - name: - doc: | - Descriptive name or ideally (globally) unique persistent identifier. - # sample_history: - # doc: | - # Ideally, a reference to the location of or a (globally) unique - # persistent identifier of e.g. another file which should document - # ideally as many details as possible of the material, its - # microstructure, and its thermo-chemo-mechanical processing/ - # preparation history. - # preparation_date(NX_DATE_TIME): - # doc: | - # ISO 8601 time code with local time zone offset to UTC information - # when the specimen was prepared. - (NXdata): - exists: optional - doc: | - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - (NXcoordinate_system_set): - doc: | - Container to hold different coordinate systems conventions. - A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Each base vector of the - coordinate system should be described with an NXtransformations instance. - TRANSFORMATIONS(NXtransformations): - exists: [min, 3, max, infty] - - conventions(NXem_ebsd_conventions): - rotation_conventions(NXprocess): - three_dimensional_rotation_handedness: - rotation_convention: - euler_angle_convention: - axis_angle_convention: - orientation_parameterization_sign_convention: - processing_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - xaxis_alias: - yaxis_direction: - yaxis_alias: - zaxis_direction: - zaxis_alias: - origin: - sample_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - yaxis_direction: - zaxis_direction: - origin: - - ROI_SET(NXcg_roi_set): - exists: [min, 1, max, infty] # usually a single domain covering the entire simulated or measured material volume - # however for solitary unit models (i.e. ensembles of volume elements/simulation domains) and for replica methods - # we may need more than one domain - # the volume element is not called representative because for what a volume element is representative is a matter of - # interpretation (fundamentally this is an assumption) and can differ for different descriptors - doc: | - The simulated or characterized material volume element aka domain. - At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs - to contain details about the boundary conditions. - grid(NXcg_grid): - exists: optional - # specific application definitions can use these fields to specialize - point_set(NXcg_point_set): # how to model either or case? - exists: optional - polyhedron_set(NXcg_polyhedron_set): - exists: optional - boundary(NXcg_polyhedron_set): # how to model either or case? - exists: optional - doc: | - A boundary to the volume element. - Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. - # a good example for a general bounding box description for such a grids of triclinic cells - # https://docs.lammps.org/Howto_triclinic.html NXcg_hexahedron_set because can be a parallelepiped - number_of_boundaries(NX_POSINT): - doc: | - How many distinct boundaries are distinguished. Value required equal to n_b. - unit: NX_UNITLESS - boundaries: - doc: | - Name of the boundaries. E.g. left, right, front, back, bottom, top, - dimensions: - rank: 1 - dim: [[1, n_b]] - boundary_conditions(NX_UINT): - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_b]] - snapshot_set(NXms_snapshot_set): - doc: | - Collection of microstructural data observed/simulated. - identifier_offset(NX_UINT): - doc: | - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate - if the identifiers are expected to start from 1 (referred to as - Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index - notation) respectively. - unit: NX_UNITLESS - - # essentially NXmonitor instances for evolution of ensemble summary statistics - evolution(NXprocess): - exists: optional - doc: | - Summary quantities which are the result of some post-processing of - the snapshot data (averaging, integrating, interpolating). - Frequently used descriptors from continuum mechanics and thermodynamics - can be used here. A few examples are given. Each descriptor is currently - modelled as an instance of an NXprocess because it is relevant to - understand how the descriptors are computed. - temperature(NXprocess): - exists: optional - pressure(NXprocess): - exists: optional - stress(NXprocess): - exists: optional - strain(NXprocess): - exists: optional - deformation_gradient(NXprocess): - exists: optional - magnetic_field(NXprocess): - exists: optional - electric_field(NXprocess): - exists: optional - - # time-resolved results for individual snapshots - # virtually all computer simulations and all experiments always probe - # snapshots - MS_SNAPSHOT(NXms_snapshot): # equivalent to time-step - time(NX_NUMBER): - doc: | - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - unit: NX_TIME - iteration(NX_UINT): - doc: | - Iteration or increment counter. - unit: NX_UNITLESS - # optional places to store the grid for instance if it changes - grid(NXcg_grid): - exists: optional - polyhedron_set(NXcg_polyhedron_set): - exists: optional - point_set(NXcg_point_set): - exists: optional - # homogenization: - # constituent: - # constitutive: - # ROI(NXcg_roi_set): #multiple rois, for each geometry, connectivity/topology, cellType... - # see that the materialpoint that is tracked conceptually in tools like DAMASK is a ROI (which is currently scale-invariant), isnt a coarse-graining of atom configurations a homogenization - # several "results" homogenized quantities at (eventually different length scales - # continuum-scale view thermodynamic(NXview) - # mechanical - # damage - # thermal - # composition - MS_FEATURE_SET(NXms_feature_set): - exists: [min, 0, max, infty] - doc: | - Conceptually distinguished object/feature in the ROI/ - system with some relevance. Instances of NXms_feature_set can - be nested to build a hierarchy of logically-related objects. - - A typical example for MD simulations is to have one - ms_feature_set for the atoms which is the parent to another - ms_feature_set for monomers/molecules/proteins which is then the - parent to another ms_feature_set for the secondary, another feature_set - for the tertiary, and the parent for another feature_set for the - quaternary structure. - - Another typical example from materials engineering is to have - one ms_feature_set for crystals (grains/phases) which serves as - the parent to another ms_feature_set for interfaces between these - crystals which then is the parent for another ms_feature_set to - describe the triple junctions which is then the parent for the - quadruple/higher-order junctions between which connect the - triple lines. - - Another example from discrete dislocation dynamics could be to - have one ms_feature_set for the dislocations (maybe separate - sets for each dislocation type or family) which are then - parents to other ms_feature_set which describe junctions between - dislocations or features along the dislocation line network. - # respective application definitions based on NXms should add and - # specialize - odf(NXprocess): # (NXodf): - exists: optional - doc: | - Details about the orientation distribution function - within the entire domain. - computation_method: - doc: | - With which method was the ODF approximated? - # add approximation parameter - texture_index(NX_NUMBER): - exists: optional - doc: | - TO BE DEFINED - unit: NX_ANY - texture_strength(NX_NUMBER): - exists: optional - doc: | - TO BE DEFINED - unit: NX_ANY - volume_statistics(NXorientation_set): - exists: optional - doc: | - Collection of texture components commonly referred to. - TRANSFORMATIONS(NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the definitions are interpretable. - parameterization: - enumeration: [bunge-euler (ZXZ), quaternion] - orientation(NX_NUMBER): - doc: Parameterized orientations. - unit: NX_ANY - dimensions: - rank: 2 - dim: [[1, c], [2, n_p]] - name: - doc: | - Name of each texture component, e.g. Cube, Dillamore, Y. - dimensions: - rank: 1 - dim: [[1, c]] - integration_radius(NX_NUMBER): - doc: | - The portion of orientation space integrated over - to compute the volume fraction. - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, c]] - volume_fraction(NX_NUMBER): - doc: | - The volume fraction of each texture component. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, c]] - - # a grain-boundary character distribution - # is again a spatial correlation statistics, GBCD can be understood like an ODF in that the entire surface Of a grain boundary (interface) network is partitioned into regions between grains in specific disorientation relationships, and boundary plane inclination so that one can again ask for the "texture" i.e. which fraction of the area network is of specific disorientation and nominal plane inclination relationship - modf(NXprocess): # (NXmodf): - exists: optional - doc: | - Details about the disorientation distribution function - within the entire domain. - gbcd(NXprocess): # (NXgbcd): - exists: optional - doc: | - Details about the grain boundary character distribution - within the entire domain. - # add descriptions for the state of each cell - # e.g. values of phase field variables if desired - - temperature(NXprocess): - exists: optional - pressure(NXprocess): - exists: optional - stress(NXprocess): - exists: optional - strain(NXprocess): - exists: optional - deformation_gradient(NXprocess): - exists: optional - magnetic_field(NXprocess): - exists: optional - electric_field(NXprocess): - exists: optional - - recrystallization_kinetics(NXprocess): - exists: optional - grain_size_distribution(NXprocess): - exists: optional - recrystallization_front(NXprocess): - exists: optional diff --git a/contributed_definitions/nyaml/NXms_feature_set.yaml b/contributed_definitions/nyaml/NXms_feature_set.yaml deleted file mode 100644 index 402d5e090e..0000000000 --- a/contributed_definitions/nyaml/NXms_feature_set.yaml +++ /dev/null @@ -1,233 +0,0 @@ -# NXms_feature_set can be used e.g. as groups inside instances of NXms_snapshot -# for an MD simulation each timestep is such snapshot all snapshot for a set -# which is the parent group that has all these NXms_snapshot instances as childs -# time_stamp: # simulated, physical -category: base -doc: | - Set of topological/spatial features in materials build from other features. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: Dimensionality - c: Cardinality/number of members/features in the feature set. - n_type_dict: | - Number of types in the dictionary of human-readable types of features. - n_parent_ids: | - Total number of parent identifier. -# Thea, Joseph, Lauri, Dinga (TJLD) just for comparison for each group and field to what this would map in their model for the MDTutorial 2 -NXms_feature_set: - # TJLD: this class represents a generalization of AtomGroups - # TJLD: one such for atoms(NXms_feature_set) - # TJLD: one such for atom_groups(NXms_feature_set) - # TJLD: but not one for every molecule, i.e. all molecules and how their atoms with ids are related to atoms ids is concatenated - # TJLD: clearly there are two possibilities: either concatenate or make one NXms_feature_set for each molecule or component in the topology hierarchy - # TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations - \@depends_on: - # TJLD: not required it is currently assumed that features are always build from atoms and this relation is shown using their ids, integers on [0, n_atoms-1] - doc: | - Name (or link?) to another NXms_feature_set which defines features what are - assumed as the parents/super_features of all members in this feature set. - If depends_on is set to "." or this attribute is not defined in an instance - of this application definition, assume that this feature_set instance - represents the root feature_set of the feature tree/graph. - - # the design of this base class makes it possible to have Joseph's suggestion - # but it has the additional benefit that as it defines the set one also - # bundle the description for all features at this hierarchy level into combined - # arrays to make the eventual storage of this for instances with millions of features - # more efficient as in the current design each molecule would again be a group - # and having millions of groups comes with e.g. HDF5 with substantial overlap - # I faced this when storing grains from micro-scale continuum crystal growth simulations - # TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXms_feature_set - # TJLD: the key point we can use NXms_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... - # but with the additional benefit of a much richer geometrical description and the details about the uncertainty of these descriptions - # I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming - # their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description - dimensionality(NX_UINT): - # TJLD: not needed because they assume everything is 3d - doc: | - What is the best matching description how dimensional the feature is. - enumeration: [0, 1, 2, 3] - cardinality(NX_UINT): - # TJLD: equivalent to the number of AtomGroups class instance childs - doc: | - How many features/members are in this set? - unit: NX_UNITLESS - type_dict_keyword: - # TJLD: equivalent to the controlled vocabulary term monomer or molecule, i.e. label - # TJLD: but with the difference that in this NeXus design here different features can take different roles - # TJLD: and do not conceptually have to be atoms, alternatively one could also create an NXms_interface_set which - # TJLD: inherits from NXms_feature_set but would need to have no dimensionality - doc: | - The keywords of the dictionary of human-readable types of features. - Using terms from a community-agreed upon controlled vocabulary, e.g. - atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, - quadruple junction, triple line, disconnection, dislocation, - kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, - surface, thermal_groove_root, precipitate, dispersoid, pore, crack - is recommended. - dimensions: - rank: 1 - dim: [[1, n_type_dict]] - type_dict_value(NX_UINT): - # TJLD: equivalent to the AtomGroups index - doc: | - The integer identifier used to resolve of which type each feature is, - i.e. the values of the dictionary of human-readable types of features. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_type_dict]] - number_of_parent_identifier(NX_UINT): - doc: | - For each feature in the set specify the associated number of identifier - to parent features as are resolvable via depends_on. - This array enables to compute the array interval from which details for - specific features can be extracted as if they would be stored in an own - group. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - parent_identifier(NX_UINT): - doc: | - Concatenated array of parent identifier for each feature (in the sequence) - according to identifier and how the identifier of features in the here - described feature set are defined (implicitly from 0, to c-1 or via explicit - identifier. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_parent_ids]] - # description of the geometry of the features - # MK::how can be define that inside lines(NXprocess) we assure that there is either no geometry or only one geometry but then this geometry can be either an NXcg_polyline_set or NXcg_spline_set? - # the key problem is that at least for an implementation in HDF5 we are not allowed to have two groups named geometry even if their attributes are different because - # HDF5 implements no conceptual understanding of the relations between elements in the underlying graph which holds the data, these elements are either attributes, fields, groups, all of which - # end up as links - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - features. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish features for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - points(NXprocess): - # TJLD: this design here is different, TJLD give atom positions only (at least as of now) for the root of an object - # TJLD: while all higher-order features that are connected through their assumed topology just refer to the atoms in the root - # TJLD: via their IDs, TJLD design is ideal for systems build from atoms but would create unnecessary copies for higher-dimensional-type features - # TJLD: in fact initially I also thought it is useful to create an NXms_dislocation_set, and an NXms_atom_set but overall these are just - # specializations of NXms_feature_set. Instead I like the key approach in TJLD which is to nest instances of the same class in TJLD's case AtomGroups - # but here NXms_feature_set instances - doc: | - Assumptions and parameter to arrive at geometric primitives - to locate zero-dimensional/point-(like) features which are - discretized/represented by points. - geometry(NXcg_point_set): - uncertainty(NXprocess): - doc: | - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - lines(NXprocess): - # TJLD: not conceptualized, see comments for points and what the benefit of using NeXus would be - doc: | - Assumptions and parameters to arrive at geometric primitives - to locate one-dimensional/line-like features which are - discretized by polylines. - # MK::geometry(NXcg_spline_set) - geometry(NXcg_polyline_set): - uncertainty(NXprocess): - doc: | - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - interfaces(NXprocess): - doc: | - Assumptions and parameters to arrive at geometric primitives - to locate two-dimensional/interface features which are - discretized by triangulated surface meshes. - # MK::geometry(NXcg_nurbs_set): - geometry(NXcg_triangle_set): - uncertainty(NXprocess): - doc: | - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - volumes(NXprocess): - doc: | - Assumptions and parameters to arrive at geometric primitives - to locate three-dimensional/volumetric features which are - discretized by triangulated surface meshes of polyhedra. - # MK::geometry(NXcg_nurbs_set): - geometry(NXcg_polyhedron_set): - uncertainty(NXprocess): - doc: | - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - -# Sandor and Markus agree that how trajectories are extracted should be stored in instances of NXprocess at respective places -# Sandor suggested it can be useful to also describe how one could transform system-specific atom positions from the system-focused coordinate system to a molecule- or atom-focused local coordinate system - -# how to map results from MD simulations was already sketched by the comments from TJLD -# but ones more here stating it explicitly -# atoms(NXms_feature_set): -# # no \@depends_on: as everything is build spatiotemporally coarse-grained from the sampled atom positions and/or their trajectories -# dislocations(NXms_feature_set): -# # \@depends_on: <>/atoms -# # is trivially the same case as was described already for the DDD simulation - -# how to map from DREAM.3D to NXms_feature_set -# material_points(NXms_feature_set): # material points can be voxels of a grid (which should be specified with an instance of NXcg_grid) or real material points -# # no \@depends_on: "." required or value can be "." as material_points are considered the root -# grains(NXms_feature_set): -# \@depends_on: <>/material_points -# boundaries(NXms_feature_set): -# \@depends_on: <>/grains -# triple_lines(NXms_feature_set): -# \@depends_on: <>/boundaries -# quadruple_junctions(NXms_feature_set): -# \@depends_on: <>/triple_lines - -# how to map from e.g. DDD codes like ParaDis to NXms_feature_set -# dislocations(NXms_feature_set): -# either all types of dislocations are specified via the type_dict dictionary or by making several named instances of NXms_feature_set classes, i.e. groups -# multi_junctions(NXms_feature_set): -# \@depends_on: <>/dislocations - -# how to describe e.g. 3D cracks -# cracks(NXms_feature_set): -# # you can use volumes and interfaces to describe explicitly the 3D geometry -# # alternatively you can - -# how to map from an MTex v5.8.2 @grain2d object -# grains.poly is a cell of list of vertex indices referring to grains.V -# grains.id -# grains.phaseId to which phase does each grain belong why is it different to phase? -# grains.prop (mean and gos) -# grains.boundary -# F, list of minmax-hashed vertex indices building the facet -# grainId, list of pairs of grains incident at facet special value 0 marks grains with boundary contact -# ebsdId, list of interpolated scan points incident -# phaseId, homo/heterophase information list of pairs of phases incident at facet -# V, list of facet support vertices, the support of the polyline -# midPoint, list of facet midPoint coordinates -# direction 3d vector (V(F(i, 1),:) - V(F(i, 2), :)) and with z = 0 and then normalized, so not respecting winding order -# grains.triplePoints -# id, list of vertex id for the location of the triple point referring to grains.V or grains.boundary.V as these lists are equivalent -# grainid, triplet of adjoining grain ids -# boundaryId, triplet of adjoining boundary facets from grains.boundary.F -# nextVertexId, next vertex hit when walking from the triple point -# phaseId, is it a triple point between homophases or heterophases -# V, list of x, y coordinates for the triple points -# angles, trivial nextVertexId to triplePoint vertex angles -# grains(NXms_feature_set): -# boundaries(NXms_feature_set): -# # alternatively one NXms_feature_set for homophase boundaries diff --git a/contributed_definitions/nyaml/NXms_score_config.yaml b/contributed_definitions/nyaml/NXms_score_config.yaml deleted file mode 100644 index 5b3cf22fec..0000000000 --- a/contributed_definitions/nyaml/NXms_score_config.yaml +++ /dev/null @@ -1,318 +0,0 @@ -category: application -doc: | - Application definition to control a simulation with the SCORE model. -symbols: - n_dg_ori: | - Number of Bunge-Euler angle triplets for deformed grains. - n_rx_ori: | - Number of Bunge-Euler angle triplets for recrystallization nuclei. - n_su: | - Number of solitary unit domains to export. -NXms_score_config: - (NXentry): - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXms_score_config] - PROGRAM(NXprogram): - program_name: - \@version: - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - initial_microstructure(NXprocess): - doc: | - Relevant data to instantiate a starting configuration that is typically - a microstructure in deformed conditions where stored (elastic) energy - is stored in the form of crystal defects, which in the SCORE model are - is considered as mean-field dislocation content. - type: - doc: | - Which model should be used to generate a starting microstructure. - enumeration: [cuboidal, poisson_voronoi, ebsd, damask] - cell_size(NX_FLOAT): - doc: | - Edge length of the cubic cells of each CA domain. - unit: NX_LENGTH - domain_size(NX_UINT): - doc: | - Extend of each CA domain in voxel along the x, y, and z direction. - Deformation of sheet material is assumed. - The x axis is assumed pointing along the rolling direction. - The y axis is assumed pointing along the transverse direction. - The z axis is assumed pointing along the normal direction. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 3]] - grain_size(NX_FLOAT): - doc: | - Extent of each deformed grain along the x, y, and z direction when type is cuboidal. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - grain_diameter(NX_FLOAT): - doc: | - Average spherical diameter when type is poisson_voronoi. - unit: NX_LENGTH - grain_euler(NX_FLOAT): - doc: | - Set of Bunge-Euler angles to sample orientations randomly from. - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, n_dg_ori], [2, 3]] - ebsd(NXprocess): - exists: optional - doc: | - The EBSD dataset from which the initial microstructure is instantiated - if initial_microstructure/type has value ebsd. - filename: - doc: | - Path and name of the EBSD dataset from which to generate the starting microstructure. - \@version: - doc: | - SHA256 checksum of the file which contains the EBSD dataset. - stepsize(NX_FLOAT): - doc: | - Size of the EBSD. The EBSD orientation mapping has to be on a - regular grid of square-shaped pixels. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 2]] - nucleation_model(NXprocess): - doc: | - Phenomenological model according to which it nuclei are placed - into the domain and assumed growing. - spatial_distribution_model: - doc: | - According to which model will the nuclei become distributed spatially. - CSR means complete spatial randomness. - Custom is implementation specific. - GB places nuclei at grain boundaries. - enumeration: [csr, custom, gb] - incubation_time_model: - doc: | - According to which model will the nuclei start to grow. - enumeration: [site_saturation] - orientation_model: - doc: | - According to which model will the nuclei get their orientation assigned. - enumeration: [sample_from_nucleus_euler] - nucleus_euler(NX_FLOAT): - doc: | - Set of Bunge-Euler angles to sample orientations of nuclei randomly from. - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, n_rx_ori], [2, 3]] - material_properties(NXprocess): - doc: | - (Mechanical) properties of the material which scale the amount - of stored (elastic) energy in the ROI/system. - reference_shear_modulus(NX_FLOAT): - doc: | - Shear modulus at zero Kelvin. - unit: NX_PRESSURE - reference_burgers_magnitude(NX_FLOAT): - doc: | - Magnitude at the Burgers vector at zero Kelvin. - unit: NX_LENGTH - # firstOrderdG0dT - # alloyConstantThermalExpCoeff - # FirstOrderThermalExpCoeff - # SecondOrderThermalExpCoeff - melting_temperature(NX_FLOAT): - doc: | - Melting temperature in degrees Celsius. - unit: NX_TEMPERATURE - grain_boundary_mobility_model(NXprocess): - doc: | - Model for the assumed mobility of grain boundaries with different disorientation. - model: - doc: | - Which type of fundamental model for the grain boundary mobility: - For the Sebald-Gottstein model the following equation is used. - For the Rollett-Holm model the following equation is used. - enumeration: [sebald_gottstein, rollett_holm] - sebald_gottstein_parameters(NXcollection): - lagb_pre_factor(NX_FLOAT): - unit: NX_ANY - lagb_enthalpy(NX_FLOAT): - unit: NX_ANY - hagb_pre_factor(NX_FLOAT): - unit: NX_ANY - hagb_enthalpy(NX_FLOAT): - unit: NX_ANY - special_pre_factor(NX_FLOAT): - unit: NX_ANY - special_enthalpy(NX_FLOAT): - unit: NX_ANY - rollett_holm_parameters(NXcollection): - hagb_pre_factor(NX_FLOAT): - unit: NX_ANY - hagb_enthalpy(NX_FLOAT): - unit: NX_ANY - lagb_to_hagb_cut(NX_FLOAT): - unit: NX_ANY - lagb_to_hagb_transition(NX_FLOAT): - unit: NX_ANY - lagb_to_hagb_exponent(NX_FLOAT): - unit: NX_ANY - stored_energy_recovery_model(NXprocess): - doc: | - Simulated evolution of the dislocation density as the stored - (elastic) energy assumed stored in each grain. - model: - doc: | - Which type of recovery model. - enumeration: [none] - dispersoid_drag_model(NXprocess): - doc: | - Simulated reduction of the grain boundary speed due to - the presence of dispersoids through which the total grain boundary - area of the recrystallization front can be reduced. - model: - doc: | - Which type of drag model. - enumeration: [none, zener_smith] - zener_smith_parameter(NXcollection): - pre_factor(NX_FLOAT): - surface_energy_density(NX_FLOAT): - time(NX_FLOAT): - doc: | - Support point of the linearized curve of simulated time matching - a specific support point of the average dispersoid radius. - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, i]] - radius(NX_FLOAT): - doc: | - Support point of the linearized curve of the average dispersoid radius. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, i]] - time_temperature_history(NXprocess): - doc: | - Simulated time temperature profile - time(NX_FLOAT): - doc: | - Support point of the linearized curve of simulated time matching - a specific support point of the temperature. - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, j]] - temperature(NX_FLOAT): - doc: | - Support point of the linearized curve of the temperature. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, j]] - stop_criteria(NXprocess): - doc: | - Criteria which enable to stop the simulation in a controlled manner. - Whichever criterion is fulfilled first stops the simulation. - max_x(NX_FLOAT): - doc: | - Maximum recrystallized volume fraction. - unit: NX_DIMENSIONLESS - max_time(NX_NUMBER): - doc: | - Maximum simulated physical time. - unit: NX_TIME - max_iteration(NX_UINT): - doc: | - Maximum number of iteration steps. - unit: NX_UNITLESS - numerics(NXprocess): - doc: | - Settings relevant for stable numerical integration. - max_delta_x(NX_FLOAT): - doc: | - Maximum fraction equivalent to the migration of the - fastest grain boundary in the system how much a cell - may be consumed in a single iteration. - unit: NX_DIMENSIONLESS - initial_cell_cache(NX_FLOAT): - doc: | - Fraction of the total number of cells in the CA which - should initially be allocated for offering cells in the - recrystallization front. - unit: NX_UNITLESS - realloc_cell_cache(NX_FLOAT): - doc: | - By how much more times should the already allocated memory - be is increased to offer space for storing states of cells - in the recrystallization front. - unit: NX_UNITLESS - defragment_cell_cache(NX_BOOLEAN): - doc: | - Should the cache for cells in the recrystallization front - be defragmented on-the-fly. - defragment_x(NX_FLOAT): - doc: | - Heuristic recrystallized volume target values at which - the cache for cells in the recrystallization front - will be defragmented on-the-fly. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, i]] - snapshot_x(NX_FLOAT): - doc: | - List of recrystallized volume target values at which a - snapshot of the CA state should be exported for. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, j]] - solitary_unit_model(NXprocess): - apply(NX_BOOLEAN): - doc: | - Perform a statistical analyses of the results as it was - proposed by M. Kühbach (solitary unit model ensemble approach). - number_of_domains(NX_UINT): - doc: | - How many independent cellular automaton domains - should be instantiated. - unit: NX_UNITLESS - rediscretization(NX_UINT): - doc: | - Into how many time steps should the real time interval be discretized upon during post-processing the results with the solitary unit modeling approach. - unit: NX_UNITLESS - domain_identifier(NX_UINT): - doc: | - List of identifier for those domain which should be rendered. - Identifier start from 0. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_su]] - - performance(NXcs_profiling): - current_working_directory: diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml deleted file mode 100644 index 8dc48b55c2..0000000000 --- a/contributed_definitions/nyaml/NXms_score_results.yaml +++ /dev/null @@ -1,598 +0,0 @@ -# inspect comments behind NXms -category: application -doc: | - Application definition for storing results of the SCORE cellular automaton. - - The SCORE cellular automaton model for primary recrystallization is an - example of typical materials engineering applications used within the field - of so-called Integral Computational Materials Engineering (ICME) whereby - one can simulate the evolution of microstructures. - - Specifically the SCORE model can be used to simulate the growth of static - recrystallization nuclei. The model is described in the literature: - - * `M. Kühbach et al. `_ - * `C. Haase et al. `_ - * `M. Diehl et al. `_ - -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_b: | - Number of boundaries of the bounding box or primitive to domain. - n_p: | - Number of parameter required for chosen orientation parameterization. - n_tex: | - Number of texture components identified. - d: | - Dimensionality. - c: | - Cardinality. - n_front: | - Number of active cells in the (recrystallization) front. - n_grains: | - Number of grains in the computer simulation. -NXms_score_results: - (NXentry): - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - # enumeration: [sha_256_hash] - definition: - doc: | - NeXus NXDL schema to which this file conforms. - enumeration: [NXms_score_results] - analysis_identifier: - doc: | - Ideally, a (globally) unique persistent identifier - for referring to this computer simulation. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - analysis_description: - exists: optional - doc: | - Free-text description about the workflow (analysis/simulation). - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the characterization started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC included - when the characterization ended. - PROGRAM(NXprogram): - exists: [min, 1, max, infty] - program_name: - \@version: - experiment_or_simulation: - doc: | - Specify if the (characterization) results/data of this instance of an - application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe a microstructure. - The term microstructure is used to describe the spatial arrangement of - crystal defects inside a sample/specimen without demanding necessarily - that this structure is mainly at the micron length scale. - Nanostructure and macrostructure are close synonyms. - Material architecture is a narrow synonym. - enumeration: [experiment, simulation] - # always a simulation! - config_filename: - doc: | - The path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the SCORE executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - USER(NXuser): - exists: [min, 0, max, infty] - doc: | - Contact information and eventually details of at least one person - involved in creating this result. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is recommended. - name: - doc: Given (first) name and surname of the user. - affiliation: - exists: recommended - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. - address: - exists: recommended - doc: Postal address of the affiliation. - email: - exists: recommended - doc: | - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - orcid: - exists: recommended - doc: | - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - orcid_platform: - exists: recommended - doc: | - Name of the OrcID or ResearcherID where the account - under orcid is registered. - telephone_number: - exists: optional - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - role: - exists: recommended - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - social_media_name: - exists: optional - doc: | - Account name that is associated with the user in social media platforms. - social_media_platform: - exists: optional - doc: | - Name of the social media platform where the account - under social_media_name is registered. - specimen(NXsample): - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - name: - doc: | - Descriptive name or ideally (globally) unique persistent identifier. - # sample_history: - # doc: | - # Ideally, a reference to the location of or a (globally) unique - # persistent identifier of e.g. another file which should document - # ideally as many details as possible of the material, its - # microstructure, and its thermo-chemo-mechanical processing/ - # preparation history. - # preparation_date(NX_DATE_TIME): - # doc: | - # ISO 8601 time code with local time zone offset to UTC information - # when the specimen was prepared. - (NXdata): - exists: optional - doc: | - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - (NXcoordinate_system_set): - doc: | - Container to hold different coordinate systems conventions. - A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Each base vector of the - coordinate system should be described with an NXtransformations instance. - TRANSFORMATIONS(NXtransformations): - exists: [min, 3, max, infty] - - conventions(NXem_ebsd_conventions): - rotation_conventions(NXprocess): - three_dimensional_rotation_handedness: - rotation_convention: - euler_angle_convention: - axis_angle_convention: - orientation_parameterization_sign_convention: - processing_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - xaxis_alias: - yaxis_direction: - yaxis_alias: - zaxis_direction: - zaxis_alias: - origin: - sample_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - yaxis_direction: - zaxis_direction: - origin: - - ROI_SET(NXcg_roi_set): - exists: [min, 1, max, infty] # usually a single domain covering the entire simulated or measured material volume - # however for solitary unit models aka volume element ensemble, replica methods we may need more than one domain - # the volume element is not called representative because for what we consider the volume element to be representative - # for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors - doc: | - The simulated or characterized material volume element aka domain. - At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs - to contain details about the boundary conditions. - grid(NXcg_grid): - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - origin(NX_NUMBER): - symmetry: - cell_dimensions(NX_NUMBER): - extent(NX_POSINT): - identifier_offset(NX_INT): - boundary(NXcg_polyhedron_set): - doc: A tight bounding box or sphere or bounding primitive about the grid. - # a good example for a general bounding box description for such a grids of triclinic cells - # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped - number_of_boundaries(NX_POSINT): - doc: | - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - unit: NX_UNITLESS - boundaries: - exists: recommmended - doc: | - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - boundary_conditions(NX_INT): - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_b]] - - snapshot_set(NXms_snapshot_set): - doc: | - Collection of microstructural data observed/simulated. - identifier_offset(NX_UINT): - doc: | - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate - if the identifiers are expected to start from 1 (referred to as - Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index - notation) respectively. - unit: NX_UNITLESS - - # essentially NXmonitor instances for evolution of ensemble summary statistics - evolution(NXprocess): - exists: optional - doc: | - Summary quantities which are the result of some post-processing of - the snapshot data (averaging, integrating, interpolating). - Frequently used descriptors from continuum mechanics and thermodynamics - can be used here. A few examples are given. Each descriptor is currently - modelled as an instance of an NXprocess because it is relevant to - understand how the descriptors are computed. - time(NXprocess): - exists: optional - doc: | - Evolution of the physical time. - temperature(NXprocess): - exists: optional - doc: | - Evolution of the simulated temperature over time. - # pressure(NXprocess): - # exists: optional - # stress(NXprocess): - # exists: optional - # strain(NXprocess): - # exists: optional - # deformation_gradient(NXprocess): - # exists: optional - # magnetic_field(NXprocess): - # exists: optional - # electric_field(NXprocess): - # exists: optional - kinetics(NXprocess): - exists: optional - doc: | - Evolution of the recrystallized volume fraction over time. - # recrystallization_front(NXprocess): - # exists: optional - # time-resolved results for individual snapshots - # virtually all computer simulations and all experiments always probe - # snapshots - MS_SNAPSHOT(NXms_snapshot): # equivalent to time-step - time(NX_NUMBER): - doc: | - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - unit: NX_TIME - temperature(NX_NUMBER): - doc: | - Simulated temperature. - unit: NX_TEMPERATURE - iteration(NX_UINT): - doc: | - Iteration or increment counter. - unit: NX_UNITLESS - # optional places to store the grid for instance if it changes - grid(NXcg_grid): # cell_based quantities for Vitesh Shah - exists: recommended - grain_identifier(NX_UINT): - exists: recommended - doc: | - Grain identifier for each cell. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_x], [2, n_y], [3, n_z]] - thread_identifier(NX_UINT): - exists: optional - doc: | - Identifier of the OpenMP thread which processed this part of the grid. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_x], [2, n_y], [3, n_z]] - # check comments behind NXms - recrystallization_front(NXprocess): # front_based quantities for Vitesh Shah - exists: recommended - doc: | - Details about those cells which in this time step represent - the discretized recrystallization front. - halo_region(NX_UINT): - exists: optional - doc: | - Which cells are currently in a halo region of threads. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_front]] - mobility_weight(NX_NUMBER): - exists: recommended - doc: | - So-called mobility weight which is a scaling factor to - control the mobility of the grain boundary which is assumed - to sweep currently this volume. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_front]] - coordinate(NX_NUMBER): - exists: recommended - doc: | - Grid coordinates of each cell in the recrystallization front. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_front], [2, 3]] - deformed_grain_identifier(NX_UINT): - exists: recommended - doc: | - Grain identifier assigned to each cell in the recrystallization front. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_front]] - recrystallized_grain_identifier(NX_UINT): - exists: recommended - doc: | - Grain identifier assigned to each nucleus which affected that cell in the recrystallization front. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_front]] - recrystallized_volume_fraction(NX_NUMBER): - exists: recommended - doc: | - Relative volume transformed as a measure of infection progress. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_front]] - thread_identifier(NX_UINT): - exists: optional - doc: | - Identifier of the OpenMP thread processing each cell in the recrystallization front. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_front]] - infection_direction(NX_UINT): - exists: optional - doc: | - Hint about the direction from which the cell was infected. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_front]] - grain_ensemble(NXprocess): # grain_based quantities for Vitesh Shah - exists: recommended - doc: | - Current grain-related quantities. - euler(NX_NUMBER): - exists: optional - doc: | - Bunge-Euler angle triplets for each grain. - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, n_grains], [2, 3]] - volume(NX_NUMBER): - doc: | - Discrete volume of each grain accounting also for partially - transformed cells. - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, n_grains]] - dislocation_density(NX_NUMBER): - exists: recommended - doc: | - Current value for the dislocation density as a measure of - the remaining stored energy in assumed crystal defects inside - each grain. The difference between these values scales the - driving force of grain boundary migration. - unit: NX_ANY # 1/m^2 - dimensions: - rank: 1 - dim: [[1, n_grains]] - is_deformed(NX_BOOLEAN): - exists: recommended - doc: | - Is the grain deformed. - dimensions: - rank: 1 - dim: [[1, n_grains]] - is_recrystallized(NX_BOOLEAN): - exists: recommended - doc: | - Is the grain recrystallized. - dimensions: - rank: 1 - dim: [[1, n_grains]] - - recrystallized_kinetics(NXprocess): - doc: | - Current recrystallized volume fraction. - value(NX_NUMBER): - doc: | - Currently evaluated actual recrystallized volume fraction. - This takes into account partially recrystallized cells. - unit: NX_DIMENSIONLESS - target(NX_NUMBER): - doc: | - Currently desired target recrystallized volume fraction at - which the user requested to log a snapshot. - unit: NX_DIMENSIONLESS - # pressure(NXprocess): - # exists: optional - stress(NXprocess): - exists: optional - value(NX_NUMBER): - doc: | - Currently assumed globally applied Cauchy stress tensor on the ROI. - unit: NX_ANY - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - strain(NXprocess): - exists: optional - value(NX_NUMBER): - doc: | - Currently assumed globally applied Cauchy strain tensor on the ROI. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - # deformation_gradient(NXprocess): - # exists: optional - # magnetic_field(NXprocess): - # exists: optional - # electric_field(NXprocess): - # exists: optional - - performance(NXcs_profiling): - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: [min, 0, max, infty] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: [min, 0, max, 1] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: [min, 0, max, 1] - (NXcs_io_obj): - exists: [min, 1, max, infty] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended diff --git a/contributed_definitions/nyaml/NXms_snapshot.yaml b/contributed_definitions/nyaml/NXms_snapshot.yaml deleted file mode 100644 index 81a6da6ef8..0000000000 --- a/contributed_definitions/nyaml/NXms_snapshot.yaml +++ /dev/null @@ -1,20 +0,0 @@ -category: base -doc: | - Base class for data on the state of the microstructure at a given time/iteration. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -NXms_snapshot: - comment: - doc: | - Is this time for a measurement or a simulation. - enumeration: [measurement, simulation] - time(NX_NUMBER): - doc: | - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - unit: NX_TIME - iteration(NX_INT): - doc: | - Iteration or increment counter. - unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXms_snapshot_set.yaml b/contributed_definitions/nyaml/NXms_snapshot_set.yaml deleted file mode 100644 index d923384e0d..0000000000 --- a/contributed_definitions/nyaml/NXms_snapshot_set.yaml +++ /dev/null @@ -1,28 +0,0 @@ -category: base -doc: | - A collection of spatiotemporal microstructure data. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXms_snapshot_set: - comment: - doc: Is this set describing a measurement or a simulation? - enumeration: [measurement, simulation] - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - # should we rather name snapshots explicitly always snapshot_1, snapshot_2 - # in which case identifier fields are not required, on the other hand - # if we give the names of the snapshots free via making them all capital - # how can we assure that snapshots are numbered consecutively? - # MS_SNAPSHOT - (NXms_snapshot): - # exists: [min, 0, max, infty] diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml deleted file mode 100644 index 5073a3d5d6..0000000000 --- a/contributed_definitions/nyaml/NXopt.yaml +++ /dev/null @@ -1,703 +0,0 @@ -# 05/2023 -# Draft of a NeXus application definition which serves as a template for various -# optical spectroscopy experiments - -# To do: -# [ ] Check base classes (NXbeam_path + base classes used by it) -# [ ] Harmonize NXopt and NXellipsometry -# [ ] Fix dimensions and ranks - -category: application -doc: | - An application definition for optical spectroscopy experiments. -symbols: - doc: Variables used throughout the document, e.g. dimensions or parameters. - N_spectrum: | - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - N_sensors: | - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. - N_measurements: | - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - N_detection_angles: | - Number of detection angles of the beam reflected or scattered off the - sample. - N_incident_angles: Number of angles of incidence of the incident beam. - N_observables: | - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - -NXopt: - (NXentry): - doc: | - An application definition template for optical spectroscopy experiments. - - A general optical experiment consists of a light or excitation source, a - beam path, a sample + its stage + its environment, and a detection unit. - Examples are reflection or transmission measurements, photoluminescence, - Raman spectroscopy, ellipsometry etc. - - definition: - doc: An application definition describing a general optical experiment. - \@version: - doc: | - Version number to identify which definition of this application - definition was used for this entry/data. - \@url: - doc: | - URL where to find further material (documentation, examples) relevant - to the application definition. - enumeration: [NXopt] - experiment_identifier: - doc: | - A (globally persistent) unique identifier of the experiment. - (i) The identifier is usually defined by the facility or principle - investigator. - (ii) The identifier enables to link experiments to e.g. proposals. - experiment_description: - exists: optional - doc: | - An optional free-text description of the experiment. - - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description. - experiment_type: - doc: Specify the type of the optical experiment. - start_time(NX_DATE_TIME): - doc: Start time of the experiment. UTC offset should be specified. - (NXuser): - doc: | - Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users, if relevant, is recommended. - name(NX_CHAR): - doc: Name of the user. - affiliation(NX_CHAR): - exists: recommended - doc: | - Name of the affiliation of the user at the point in time when the - experiment was performed. - address(NX_CHAR): - exists: recommended - doc: Street address of the user's affiliation. - email(NX_CHAR): - doc: Email address of the user. - orcid(NX_CHAR): - exists: recommended - doc: Author ID defined by https://orcid.org/. - telephone_number(NX_CHAR): - exists: recommended - doc: Telephone number of the user. - - (NXinstrument): - doc: | - Properties of the experimental setup. This includes general information - about the instrument (such as model, company etc.), information about - the calibration of the instrument, elements of the beam path including - the excitation or light source and the detector unit, the sample stage - (plus the sample environment, which also includes sensors used to - monitor external conditions) and elements of the beam path. - - Meta data describing the sample should be specified in ENTRY/SAMPLE - outside of ENTRY/INSTRUMENT. - model: - doc: The name of the instrument. - \@version: - doc: | - The used version of the hardware if available. If not a commercial - instrument use date of completion of the hardware. - company: - exists: optional - doc: Name of the company which build the instrument. - construction_year(NX_DATE_TIME): - exists: optional - doc: | - ISO8601 date when the instrument was constructed. - UTC offset should be specified. - software(NXprocess): - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to measure the data, i.e. the software used to start and - record the measured data and/or metadata. - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@url: - exists: optional - doc: Website of the software. - firmware(NXprogram): - exists: recommended - doc: | - Commercial or otherwise defined name of the firmware that was used - for the measurement - if available. - \@version: - doc: | - Version and build number or commit hash of the software source code. - \@url: - exists: optional - doc: Website of the software. - calibration_status(NX_CHAR): - doc: | - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. - enumeration: - [ - calibration time provided, - no calibration, - within 1 hour, - within 1 day, - within 1 week, - ] - calibration(NXsubentry): - exists: recommended - doc: The calibration data and metadata should be described in a - separate NeXus file with the link provided in 'calibration_link'. - calibration_time(NX_DATE_TIME): - exists: optional - doc: | - If calibtration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. - calibration_data_link: - doc: | - Link to the NeXus file containing the calibration data and metadata. - (NXbeam_path): - doc: | - Describes an arrangement of optical or other elements, e.g. the beam - path between the light source and the sample, or between the sample - and the detector unit (including the sources and detectors - themselves). - - If a beam splitter (i.e. a device that splits the incoming beam into - two or more beams) is part of the beam path, two or more NXbeam_path - fields may be needed to fully describe the beam paths and the correct - sequence of the beam path elements. - Use as many beam paths as needed to describe the setup. - angle_of_incidence(NX_NUMBER): - doc: | - Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, N_incident_angles]] - \@units: - detection_angle(NX_NUMBER): - exists: optional - doc: | - Detection angle(s) of the beam reflected or scattered off the sample - vs. the normal of the bottom reflective (substrate) surface in the - sample if not equal to the angle(s) of incidence. - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, N_detection_angles]] - sample_stage(NXsubentry): - doc: | - Sample stage, holding the sample at a specific position in X,Y,Z - (Cartesian) coordinate system and at an orientation defined - by three Euler angles (alpha, beta, gamma). - stage_type: - doc: Specify the type of the sample stage. - enumeration: - [ - manual stage, - scanning stage, - liquid stage, - gas cell, - cryostat - ] - alternative: - exists: optional - doc: | - If there is no motorized stage, we should at least qualify where - the beam hits the sample and in what direction the sample stands - in a free-text description, e.g. 'center of sample, long edge - parallel to the plane of incidence'. - environment_conditions(NXenvironment): - doc: | - Specify external parameters that have influenced the sample, such - as the surrounding medium, and varied parameters e.g. temperature, - pressure, pH value, optical excitation etc. - medium: - doc: | - Describe what was the medium above or around the sample. The - common model is built up from the substrate to the medium on the - other side. Both boundaries are assumed infinite in the model. - Here, define the name of the medium (e.g. water, air, UHV, etc.). - medium_refractive_indices(NX_FLOAT): - exists: optional - doc: | - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum] - ] - PARAMETER(NXsensor): - exists: optional - doc: | - A sensor used to monitor an external condition influencing the - sample, such as temperature or pressure. It is suggested to - replace 'PARAMETER' by the type of the varied parameter defined - in 'parameter_type'. - The measured parameter values should be provided in 'values'. - For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. - In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. - parameter_type: - doc: | - Indicates which parameter was changed. Its definition must exist - below. The specified variable has to be N_measurements long, - providing the parameters for each data set. If you vary more than - one parameter simultaneously. - If the measured parameter is not contained in the list `other` - should be specified and the `parameter_type_name` should be provided. - enumeration: - [ - conductivity, - detection_angle, - electric_field, - flow, - incident_angle, - magnetic_field, - optical_excitation, - pH, - pressure, - resistance, - shear, - stage_positions, - strain, - stress, - surface_pressure, - temperature, - voltage, - other, - ] - parameter_type_name: - doc: | - If the parameter_type is `other` a name should be specified here. - exists: optional - number_of_parameters(NX_POSINT): - doc: | - Number of different parameter values at which the measurement - was performed. For example, if the measurement was performed at - temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - unit: NX_UNITLESS - values(NX_FLOAT): - unit: NX_ANY - doc: | - Vector containing the values of the varied parameter. Its - length is equal to N_measurements. The order of the values - should be as follows: - - * Order the sensors according to number_of_parameters starting - with the lowest number. If number_of_parameters is equal for - two sensors order them alphabetically (sensor/parameter name). - * The first sensor's j parameters should be ordered in the - following way. The first N_measurements/number_of_parameters - entries of the vector contain the first parameter (a1), the - second N_measurements/number_of_parameters contain the second - parameter (a2) etc., so the vector looks like: - [ - a1,a1,...,a1, - a2,a2,...,a2, - ... - aj,aj,...aj - ] - * The kth sensor's m parameters should be ordered in the - following way: - [ - p1,...p1,p2,...,p2,...pm,...,pm, - p1,...p1,p2,...,p2,...pm,...,pm, - ... - p1,...p1,p2,...,p2,...pm,...,pm - ] - * The last sensor's n parameters should be ordered in the - following way: - [ - z1,z2,...,zn, - z1,z2,...,zn, - ... - z1,z2,...,zn] - - For example, if the experiment was performed at three different - temperatures (T1, T2, T3), two different pressures (p1, p2) and - two different angles of incidence (a1, a2), then - N_measurements = 12 and the order of the values for the various - parameter vectors is: - - * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] - * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] - * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] - - dimensions: - rank: 1 - dim: [[1, N_measurements]] - WINDOW(NXaperture): - exists: optional - doc: | - For environmental measurements, the environment (liquid, vapor - etc.) is enclosed in a cell, which has windows both in the - direction of the source (entry window) and the detector (exit - window) (looking from the sample). In case that the entry and exit - windows are not the same type and do not have the same properties, - use a second 'WINDOW(MXaperture)' field. - - The windows also add a phase shift to the light altering the - measured signal. This shift has to be corrected based on measuring - a known sample (reference sample) or the actual sample of interest - in the environmental cell. State if a window correction has been - performed in 'window_effects_corrected'. Reference data should be - considered as a separate experiment, and a link to the NeXus file - should be added in reference_data_link in measured_data. - - The window is considered to be a part of the sample stage but also - beam path. Hence, its position within the beam path should be - defined by the 'depends_on' field. - depends_on: - exists: recommended - doc: | - Specify the position of the window in the beam path by pointing - to the preceding element in the sequence of beam path elements. - window_effects_corrected(NX_BOOLEAN): - doc: | - Was a window correction performed? If 'True' describe the window - correction procedure in 'window_correction/procedure'. - window_correction(NXprocess): - exists: optional - doc: | - Was a window correction performed? If 'True' describe the - window correction procedure in '' - procedure: - doc: | - Describe when (before or after the main measurement + time - stamp in 'date') and how the window effects have been - corrected, i.e. either mathematically or by performing a - reference measurement. In the latter case, provide the link to - to the reference data in 'reference_data_link'. - reference_data_link: - exists: optional - doc: | - Link to the NeXus file which describes the reference data if a - reference measurement for window correction was performed. - Ideally, the reference measurement was performed on a reference - sample and on the same sample, and using the same conditions as - for the actual measurement with and without windows. It should - have been conducted as close in time to the actual measurement - as possible. - material(NX_CHAR): - doc: The material of the window. - enumeration: - [ - quartz, - diamond, - calcium fluoride, - zinc selenide, - thallium bromoiodide, - alkali halide compound, - Mylar, - other, - ] - other_material(NX_CHAR): - exists: optional - doc: | - If you specified 'other' as material, decsribe here what it is. - thickness(NX_FLOAT): - doc: Thickness of the window. - unit: NX_LENGTH - orientation_angle(NX_FLOAT): - doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - unit: NX_ANGLE - - (NXsample): - doc: | - Properties of the sample, such as sample type, layer structure, - chemical formula, atom types, its history etc. - Information about the sample stage and sample environment should be - described in ENTRY/INSTRUMENT/sample_stage. - sample_name: - doc: Descriptive name of the sample - sample_type: - doc: | - Specify the type of sample, e.g. thin film, single crystal etc. - enumeration: - [ - 'thin film', - 'single crystal', - 'poly crystal', - 'single layer', - 'multi layer' - ] - layer_structure: - doc: | - Qualitative description of the layer structure for the sample, - starting with the top layer (i.e. the one on the front surface, on - which the light incident), e.g. native oxide/bulk substrate, or - Si/native oxide/thermal oxide/polymer/peptide. - chemical_formula: - doc: | - Chemical formula of the sample. Use the Hill system (explained here: - https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write - the chemical formula. In case the sample consists of several layers, - this should be a list of the chemical formulas of the individual - layers, where the first entry is the chemical formula of the top - layer (the one on the front surface, on which the light incident). - The order must be consistent with layer_structure - atom_types: - doc: | - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - 'atom_types'. - sample_history: - doc: | - Ideally, a reference to the location or a unique (globally - persistent) identifier (e.g.) of e.g. another file which gives - as many as possible details of the material, its microstructure, - and its thermo-chemo-mechanical processing/preparation history. - In the case that such a detailed history of the sample is not - available, use this field as a free-text description to specify - details of the sample and its preparation. - preparation_date(NX_DATE_TIME): - exists: recommended - doc: ISO8601 date with time zone (UTC offset) specified. - substrate: - exists: recommended - doc: Description of the substrate. - sample_orientation: - exists: optional - doc: Specify the sample orientation. - - data_collection(NXprocess): - doc: | - Measured data, data errors, and varied parameters. If reference data - were measured they should be considered a separate experiment and a - link to its NeXus file should be added in reference_data_link. - data_identifier(NX_NUMBER): - doc: | - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0-N. - data_type: - doc: | - Select which type of data was recorded, for example intensity, - reflectivity, transmittance, Psi and Delta etc. - It is possible to have multiple selections. The enumeration list - depends on the type of experiment and may differ for different - application definitions. - enumeration: - [ - intensity, - reflectivity, - transmittance, - Psi/Delta, - tan(Psi)/cos(Delta), - Mueller matrix, - Jones matrix, - N/C/S, - raw data, - ] - NAME_spectrum(NX_FLOAT): - # This should be a required field, but is set to 'optional' for the moment - exists: optional - doc: | - Spectral values (e.g. wavelength or energy) used for the measurement. - An array of 1 or more elements. Length defines N_spectrum. Replace - 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, N_spectrum]] - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - measured_data(NX_FLOAT): - doc: | - Resulting data from the measurement, described by 'data_type'. - - The first dimension is defined by the number of measurements taken, - (N_measurements). The instructions on how to order the values - contained in the parameter vectors given in the doc string of - INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, - define the N_measurements parameter sets. For example, if the - experiment was performed at three different temperatures - (T1, T2, T3), two different pressures (p1, p2) and two different - angles of incidence (a1, a2), the first measurement was taken at the - parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. - unit: NX_ANY - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, N_observables], # 2 for Psi and Delta, 16 for Mueller matrix etc - [3, N_spectrum] - ] - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - measured_data_errors(NX_FLOAT): - exists: optional - doc: | - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. - unit: NX_ANY - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, N_observables], # 2 for Psi and Delta, 16 for Mueller matrix etc - [3, N_spectrum] - ] - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - varied_parameter_link: - exists: optional - doc: | - List of links to the values of the sensors. Add a link for each - varied parameter (i.e. for each sensor). - dimensions: - rank: 1 - dim: [[1, N_sensors]] - reference_data_link: - exists: optional - doc: | - Link to the NeXus file which describes the reference data if a - reference measurement was performed. Ideally, the reference - measurement was performed using the same conditions as the actual - measurement and should be as close in time to the actual measurement - as possible. - data_software(NXprocess): - exists: optional - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and/or - metadata (in most cases, this is the same as INSTRUMENT/software). - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@url: - exists: optional - doc: Website of the software. - (NXdata): - exists: optional - doc: | - A plot of the multi-dimensional data array provided in - ENTRY/data/measured_data. - \@axes: - doc: Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - - derived_parameters(NXprocess): - exists: optional - doc: Parameters that are derived from the measured data. - depolarization(NX_NUMBER): - exists: optional - doc: Light loss due to depolarization as a value in [0-1]. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, 1], - [3, N_spectrum] - ] - Jones_quality_factor(NX_NUMBER): - exists: optional - doc: Jones quality factor. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, 1], - [3, N_spectrum] - ] - reflectivity(NX_NUMBER): - exists: optional - doc: Reflectivity. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, 1], - [3, N_spectrum] - ] - transmittance(NX_NUMBER): - exists: optional - doc: Transmittance. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, 1], - [3, N_spectrum] - ] - ANALYSIS_program(NXprocess): - exists: optional - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to generate or calculate the derived parameters. - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - plot(NXdata): - doc: | - A default view of the data provided in ENTRY/data_collection/measured_data. This - should be the part of the data set which provides the most suitable - representation of the data. - \@axes: - doc: Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml deleted file mode 100644 index f6a7b5c47e..0000000000 --- a/contributed_definitions/nyaml/NXoptical_system_em.yaml +++ /dev/null @@ -1,50 +0,0 @@ -category: base -doc: | - A container for qualifying an electron optical system. -NXoptical_system_em: - # NEW ISSUE: for now used to store difficult to place entries - # NEW ISSUE: all the definitions here should better be backed up by the - # work of the HMC EM glossary activities - camera_length(NX_NUMBER): - doc: | - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - unit: NX_LENGTH - magnification(NX_NUMBER): - doc: | - The factor of enlargement of the apparent size, not physical size, of an object. - unit: NX_DIMENSIONLESS - defocus(NX_NUMBER): - doc: | - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - unit: NX_LENGTH - semi_convergence_angle(NX_NUMBER): - doc: | - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - unit: NX_ANGLE - field_of_view(NX_NUMBER): - doc: | - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - unit: NX_LENGTH - working_distance(NX_FLOAT): - doc: | - Citing `Globalsino `_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - unit: NX_LENGTH - beam_current(NX_FLOAT): - doc: | - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - unit: NX_CURRENT - beam_current_description: - doc: | - Specify further details how the beam current was measured or estimated. - # NEW ISSUE: the KIT/SCC propose: - # adding of the image_mode or field mode - # imageMode: enum: [normal_image, sad, eds, nbd, cbed] - # fieldMode: enum: [dark_field, bright_field] diff --git a/contributed_definitions/nyaml/NXorientation_set.yaml b/contributed_definitions/nyaml/NXorientation_set.yaml deleted file mode 100644 index 4a54c2b33f..0000000000 --- a/contributed_definitions/nyaml/NXorientation_set.yaml +++ /dev/null @@ -1,84 +0,0 @@ -category: base -doc: | - Details about individual orientations of a set of objects. - - For a more detailed insight into the discussion of parameterizing - orientations in materials science see: - - * https://doi.org/10.1016/j.matchar.2016.04.008 - * https://doi.org/10.1088/0965-0393/23/8/083501 - * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations - * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge - - -# This class stores a set of specifically parameterized NXtransformations which describe -# how each object is oriented/rotated with respect to a reference coordinate system. -# we should offer here support for d==2, d==3 -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality of the reference space/coordinate system. - c: The cardinality of the set, i.e. the number of orientations. - n_p: Number of parameters for the chosen parameterization. -NXorientation_set: - # depending on the dimensionality n_p is correlated but not necessarily, e.g. for d==3 one can store quaternions (n_p==4) or Bunge-Euler angles (n_p==3) - # clearly one could think about a single best approach that everybody should use, and indeed quaternions could be a candidate but this conflicts with the - # expectations understanding and in fact habit by very many materials engineers who know and report their values in Euler angles so at least one would need to - # have a system in place which converts... - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the definitions are interpretable. - parameterization: - enumeration: [bunge-euler (ZXZ), quaternion] # there are many more ways of parameterizing orientations and for each of them different conventions to be used. many scientists do not recall by hard which rule set is associated with an e.g. ZXZ Bunge-Euler angles vers ZXY so there are at least two ways how to encode these metadata: Either to have different enumerations like bunge-euler-zxz, bunge-euler-zxy, etc. or a base class NXori_bunge_euler and then internally here a rule set...? - # how to take into account the reduction to two-d? just list these cases XY, XZ, ... also in the enumeration? - # an instance of an NXorientation_set is useful as attribute (meta)data to a set of microstructural objects e.g. crystals, grains when the base class is stored as a sub-ordinate of the grain_set - # one may argue we expect that for each grain there is an orientation value, in this case the indexing is implicit and this is often used in computer simulations - # without making a specific statement that e.g. the 0-th value of the array gives the volume of the 0-th grain but that 0-th grain might not necessarily be named as grain 0 but e.g. grain 23 - # because many computer simulations deal with ensemble where the number of objects changes over time, e.g. molecular dynamics simulation treat always the same set of atoms but post-processing - # of the data may reveal these atoms are grouped/labelled as different microstructural features (grains, dislocations, vacancies) and then the names/identifiers of the objects may change over time - # therefore the idea to specify if we use implicit or explicit indexing and listing of the indices because I know of colleagues where even that went havoc! - objects: - doc: | - A link or reference to the objects whose identifier are referred to in - identifier to resolve which row tuple is the orientation of each object - by reading orientations. - identifier_offset(NX_INT): - doc: | - Integer which specifies which orientation (row of array orientation) matches - to which object.e first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Integer used to distinguish how a row in orientation describes a specific - object with an explicit identifier that can be queried via inspecting the - list of available objects in objects. - - The rational behind having such a more complicated pattern is that not - all objects referred when following the link in objects may still exists - or are still tracked when the orientation set was characterized. - - This design enables to also use NXorientation_set in situations where - the orientation of objects change as a function in time. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, c]] - orientation(NX_NUMBER): - doc: Parameterized orientations. - unit: NX_ANY - dimensions: - rank: 2 - dim: [[1, c], [2, n_p]] - # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists - # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) - # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. - -# the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml deleted file mode 100644 index c1c7d020c1..0000000000 --- a/contributed_definitions/nyaml/NXpeak.yaml +++ /dev/null @@ -1,43 +0,0 @@ -category: base -doc: | - Description of peaks, their functional form or measured support. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_support: Number of support points -NXpeak: - label: - doc: | - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - peak_model: - doc: | - 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. - enumeration: [empirical, gaussian, lorentzian, other] - position(NX_NUMBER): - doc: | - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_support]] - intensity(NX_NUMBER): - doc: | - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_support]] - (NXcollection): - doc: | - 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/nyaml/NXpid.yaml b/contributed_definitions/nyaml/NXpid.yaml deleted file mode 100644 index e4a6e17e54..0000000000 --- a/contributed_definitions/nyaml/NXpid.yaml +++ /dev/null @@ -1,46 +0,0 @@ -doc: | - Contains the settings of a PID controller. -category: base -NXpid: - description: - doc: | - Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. - - For example, a set of sensors could be averaged over before feeding it back into the loop. - pv_sensor(NXsensor): - doc: | - The sensor representing the Process Value used in the feedback loop for the PID. - - In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. - value_log(NXlog): - value(NX_NUMBER): - doc: | - The actual timeseries data fed back to the PID loop. - setpoint(NX_FLOAT): - unit: NX_ANY - doc: | - The Setpoint(s) used as an input for the PID controller. - - It can also be a link to an NXsensor.value field. - K_p_value(NX_NUMBER): - doc: | - 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. - K_i_value(NX_NUMBER): - doc: | - The contribution from the integral term is proportional to both - the magnitude of the error and the duration of the error. - The integral in a PID controller is the sum of the instantaneous - error over time and gives the accumulated offset that should have - been corrected previously. The accumulated error is then - multiplied by the integral gain (Ki) and added to the - controller output. - K_d_value(NX_NUMBER): - doc: | - The derivative of the process error is calculated by determining - the slope of the error over time and multiplying this rate of - change by the derivative gain K_d. The magnitude of the - contribution of the derivative term to the overall control - action is termed the derivative gain, K_d diff --git a/contributed_definitions/nyaml/NXpolarizer_opt.yaml b/contributed_definitions/nyaml/NXpolarizer_opt.yaml deleted file mode 100644 index e4eeb7e17a..0000000000 --- a/contributed_definitions/nyaml/NXpolarizer_opt.yaml +++ /dev/null @@ -1,201 +0,0 @@ -# A draft of a new base class to describe an optical polarizer -# (NXpolarizer describes a spin polarizer) - -category: base -symbols: - N_spectrum: | - Size of the wavelength array for which the refractive index of the material - and/or coating is given. - N_spectrum_RT: | - Size of the wavelength array for which the reflectance or transmission of - the polarizer is given. - -doc: | - An optical polarizer. - - Information on the properties of polarizer is provided e.g. - [here](https://www.rp-photonics.com/polarizers.html). - -NXpolarizer_opt: - type: - doc: Type of the polarizer (e.g. dichroic, linear, circular etc.) - enumeration: - [ - "dichroic", - "linear", - "circular", - "Glan-Thompson prism", - "Nicol prism", - "Glan-Taylor prism", - "Glan-Focault prism", - "Wollaston prism", - "Normarski prism", - "Senarmont prism", - "thin-film polarizer", - "wire grid polarizer", - "other" - ] - # ??? Any other common polarizer types ??? - type_other: - doc: If you selected 'other' in type specify what it is. - - polarizer_angle(NX_NUMBER): - exists: recommended - doc: Angle of the polarizer. - unit: NX_ANGLE - - acceptance_angle(NX_NUMBER): - exists: recommended - doc: Acceptance angle of the polarizer (range). - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, 2]] - - (NXshape): - exists: recommended - doc: | - Describe the geometry (shape, dimension etc.) of the device. - Specify the dimensions in 'SHAPE/size'. A sketch of the device should be - provided in the 'sketch(NXdata)' field to clarify (i) the shape and - dimensions of the device, and (ii) the input and outputs (i.e. the - direction of the incoming and outcoming (split) beams). - # !!! NOTE: this class is the same as for NXbeam_path !!! - shape: - doc: Describe the shape (plate, cube, wedged, prism etc.). - enumeration: - [ - cube, - cylinder, - plate, - prism, - wedged, - other - ] - other_shape: - doc: If you chose 'other' in 'shape' describe what it is. - sketch(NXdata): - doc: | - Sketch of thedevice showing its geometry. The paths of the - incoming and outgoing beam should be illustrated and labelled (0 for - the incoming beam, and 1, 2,..., N_outputs for the outputs). - size: - doc: | - Physical extent of the device. The device might be made up of one or - more objects (NX_objects). The meaning and location of the axes used - will vary according to the value of the 'shape' variable. 'N_shapepar' - defines how many parameters: - - * For 'cube' the parameters are (width, length). - * For 'cylinder' the parameters are (diameter, length). - * For 'plate' the parameters are (width, height, length). - * For 'prism' the parameters are (width, height, length). - * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. - * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. - dimensions: - rank: 2 - dim: - [ - [1, N_objects], - [2, N_shapepar] - ] - wedge_angle(NX_FLOAT): - doc: Wedge angle if 'shape' is 'wedged'. - unit: NX_ANGLE - - wavelength_range(NX_FLOAT): - exists: recommended - doc: | - Wavelength range for which the polarizer is designed. Enter the minimum - and maximum wavelength (lower and upper limit) of the range. - unit: NX_WAVELENGTH - dimensions: - rank: 1 - dim: [[1,2]] - - substrate(NXsample): - doc: | - Properties of the substrate material of the polarizer. If the device has - a coating specify the coating material and its properties in 'coating'. - substrate_material: - doc: Specify the substrate material of the polarizer. - substrate_thickness(NX_FLOAT): - doc: Thickness of the polarizer substrate. - unit: NX_LENGTH - index_of_refraction(NX_FLOAT): - doc: | - Complex index of refraction of the polarizer material. Specify at given - spectral values (wavelength, energy, wavenumber etc.). - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum] - ] - - COATING(NXsample): - # Used captial letters for COATING so that more than one can be defined if - # the device has different coatings on the front and back side. - doc: | - If the device has a coating describe the material and its properties. - Some basic information can be found e.g. [here] - (https://www.opto-e.com/basics/reflection-transmission-and-coatings). - If the back and front side of the polarizer are coated with different - materials, you may define two coatings (e.g. COATING1 and COATING2). - coating_type: - doc: | - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - coating_material: - doc: Describe the coating material (e.g. MgF2). - coating_thickness(NX_FLOAT): - doc: Thickness of the coating. - unit: NX_LENGTH - index_of_refraction_coating(NX_FLOAT): - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum_coating] - ] - - extinction_ratio(NX_FLOAT): - doc: Extinction ratio (maximum to minimum transmission). - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: - [ - [1, N_spectrum] - ] - - reflection(NX_FLOAT): - doc: Reflection of the polarizer at given wavelength values. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: - [ - [1, N_spectrum_RT], - ] - - transmission(NX_FLOAT): - doc: Transmission of the polarizer at given wavelength values. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: - [ - [1, N_spectrum_RT], - ] - - # anything missing? \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXprogram.yaml b/contributed_definitions/nyaml/NXprogram.yaml deleted file mode 100644 index 9fda651b6b..0000000000 --- a/contributed_definitions/nyaml/NXprogram.yaml +++ /dev/null @@ -1,20 +0,0 @@ -category: base -doc: | - Base class to describe a software tool or library. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -NXprogram: - program: - doc: | - Given name of the program. Program can be a commercial one a script, - or a library or a library component. - \@version: - doc: | - Program version plus build number, or commit hash. - \@url: - doc: | - Description of an ideally ever persistent resource where the source code - of the program or this specific compiled version of the program can be - found so that the program yields repeatably exactly the same numerical - and categorical results. diff --git a/contributed_definitions/nyaml/NXpulser_apm.yaml b/contributed_definitions/nyaml/NXpulser_apm.yaml deleted file mode 100644 index 54021f6e78..0000000000 --- a/contributed_definitions/nyaml/NXpulser_apm.yaml +++ /dev/null @@ -1,103 +0,0 @@ -category: base -doc: | - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: Total number of ions collected. -NXpulser_apm: - (NXfabrication): - pulse_mode: - doc: | - How is field evaporation physically triggered. - enumeration: [laser, voltage, laser_and_voltage] - pulse_frequency(NX_FLOAT): - doc: | - Frequency with which the high voltage or laser pulser fires. - unit: NX_FREQUENCY - # This can change over the course of the experiment, APT HDF defines it therefore as follows: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of the high voltage or laser pulser. first entry : first pulse number where the spacing between this and all subsequent pulses are considered to be at the selected frequency. Each first entry must be strictly increasing in value. The second entry contains the frequency value" as data can be compressed in this case very efficiently we go for with an array of length 1xn_ions - dimensions: - rank: 1 - dim: [[1, n_ions]] - pulse_fraction(NX_FLOAT): - doc: | - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - pulsed_voltage(NX_FLOAT): - doc: | - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - unit: NX_VOLTAGE - dimensions: - rank: 1 - dim: [[1, n_ions]] - pulse_number(NX_UINT): - doc: | - Absolute number of pulses starting from the beginning of the experiment. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] - standing_voltage(NX_FLOAT): - doc: | - Direct current voltage between the specimen and the (local electrode) in - the case of local electrode atom probe (LEAP) instrument. - The standing voltage applied to the sample, relative to system ground. - unit: NX_VOLTAGE - dimensions: - rank: 1 - dim: [[1, n_ions]] - (NXsource): - doc: | - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - name: - doc: Given name/alias. - (NXfabrication): - wavelength(NX_FLOAT): - doc: Nominal wavelength of the laser radiation. - unit: NX_WAVELENGTH - power(NX_FLOAT): - doc: Nominal power of the laser source while illuminating the specimen. - unit: NX_POWER - pulse_energy(NX_FLOAT): - doc: Average energy of the laser at peak of each pulse. - # NEW ISSUE: needs clearer specification/definition - unit: NX_ENERGY - (NXbeam): - doc: | - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - incidence_vector(NXcollection): - doc: | - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set - doc: | - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - spot_position(NXcollection): # NXsnapshot, NXcg_point_set - doc: | - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - (NXtransformations): - doc: | - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. diff --git a/contributed_definitions/nyaml/NXpump.yaml b/contributed_definitions/nyaml/NXpump.yaml deleted file mode 100644 index 8755f51514..0000000000 --- a/contributed_definitions/nyaml/NXpump.yaml +++ /dev/null @@ -1,11 +0,0 @@ -category: base -doc: | - Device to reduce an atmosphere to a controlled remaining pressure level. -NXpump: - (NXfabrication): - design: - doc: Principle type of the pump. - enumeration: [membrane, rotary_vane, roots, turbo_molecular] -# NEW ISSUE: take community input and work further to store what is relevant to report about pumps -# NEW ISSUE: see e.g. https://www.youtube.com/watch?v=Nsr_AdTiIIA for a discussion about -# NEW ISSUE: the role, pros and cons of pump used for atom probe microscopy diff --git a/contributed_definitions/nyaml/NXquadric.yaml b/contributed_definitions/nyaml/NXquadric.yaml deleted file mode 100644 index f220b55003..0000000000 --- a/contributed_definitions/nyaml/NXquadric.yaml +++ /dev/null @@ -1,117 +0,0 @@ -category: base -doc: | - definition of a quadric surface. -type: group -NXquadric(NXobject): - parameters(NX_NUMBER): - unit: NX_PER_LENGTH - doc: | - Ten real values of the matrix that defines the quadric surface - in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, - P2, P3, R. Takes a units attribute of dimension reciprocal - length. R is scalar. P has dimension reciprocal length, and the - given units. Q has dimension reciprocal length squared, and - units the square of those given. - dimensions: - dim: [[1, 10]] - surface_type: - exists: ['min', '0', 'max', '1'] - doc: | - An optional description of the form of the quadric surface: - enumeration: [ELLIPSOID, ELLIPTIC_PARABOLOID, HYPERBOLIC_PARABOLOID, ELLIPTIC_HYPERBOLOID_OF_1_SHEET, ELLIPTIC_HYPERBOLOID_OF_2_SHEETS, ELLIPTIC_CONE, ELLIPTIC_CYLINDER, HYPERBOLIC_CYLINDER, PARABOLIC_CYLINDER, SPHEROID, SPHERE, PARABOLOID, HYPERBOLOID_1_SHEET, HYPERBOLOID_2_SHEET, CONE, CYLINDER, PLANE, IMAGINARY, UNKNOWN] - depends_on(NX_CHAR): - exists: ['min', '0', 'max', '1'] - doc: | - Path to an :ref:`NXtransformations` that defining the axis on - which the orientation of the surface depends. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 267b94fd8c62dec6dbb2c835d40cda184ec544f98b054c545c067c0206a6680f -# -# -# -# -# definition of a quadric surface. -# -# -# Ten real values of the matrix that defines the quadric surface -# in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, -# P2, P3, R. Takes a units attribute of dimension reciprocal -# length. R is scalar. P has dimension reciprocal length, and the -# given units. Q has dimension reciprocal length squared, and -# units the square of those given. -# -# -# -# -# -# -# -# An optional description of the form of the quadric surface: -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Path to an :ref:`NXtransformations` that defining the axis on -# which the orientation of the surface depends. -# -# -# diff --git a/contributed_definitions/nyaml/NXquadrupole_magnet.yaml b/contributed_definitions/nyaml/NXquadrupole_magnet.yaml deleted file mode 100644 index 62bec22844..0000000000 --- a/contributed_definitions/nyaml/NXquadrupole_magnet.yaml +++ /dev/null @@ -1,84 +0,0 @@ -category: base -doc: | - definition for a quadrupole magnet. -type: group -NXquadrupole_magnet(NXobject): - description(NX_CHAR): - doc: | - extended description of the magnet. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - set_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on supply. - read_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from supply. - value: - unit: NX_CURRENT - read_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 87dac0535ae7038f0b632b817a8a67683a20a6257cea6283e449a7b8bd0f3587 -# -# -# -# -# definition for a quadrupole magnet. -# -# extended description of the magnet. -# -# -# define position of beamline element relative to production target -# -# -# current set on supply. -# -# -# current read from supply. -# -# -# -# voltage read from supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXreflectron.yaml b/contributed_definitions/nyaml/NXreflectron.yaml deleted file mode 100644 index 5e2a3564f6..0000000000 --- a/contributed_definitions/nyaml/NXreflectron.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). -NXreflectron: - name: - doc: Given name/alias. - (NXfabrication): - description: - doc: | - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - # IFES_APT_TC "ReflectronVoltage: Real, 1xn array (V) Must be present if ReflectronInfo is not “None” The maximum voltage applied to the reflectron, relative to system ground." - (NXtransformations): - doc: | - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. diff --git a/contributed_definitions/nyaml/NXregion.yaml b/contributed_definitions/nyaml/NXregion.yaml deleted file mode 100644 index b074a5f157..0000000000 --- a/contributed_definitions/nyaml/NXregion.yaml +++ /dev/null @@ -1,340 +0,0 @@ -category: base -doc: | - Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. - - This can be used to describe a subset of data used to create downsampled data or to derive - some data from that subset. - - Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters - (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, - then **stride** :math:`\equiv` **step** in Python slicing. - - For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: - - detector:NXdetector/ - data[60,256,512] - region:NXregion/ - @region_type = "rectangular" - parent = "data" - start = [20,50] - count = [220,120] - statistics:NXdata/ - @signal = "sum" - sum[60] - - the ``sum`` dataset contains the summed areas in each frame. - Another example, a hyperspectral image downsampled 16-fold in energy:: - - detector:NXdetector/ - data[128,128,4096] - region:NXregion/ - @region_type = "rectangular" - parent = "data" - start = [2] - count = [20] - stride = [32] - block = [16] - downsampled:NXdata/ - @signal = "maximum" - @auxiliary_signals = "copy" - maximum[128,128,20] - copy[128,128,320] - - the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, - the ``maximum`` dataset will show maximum values in each 16-channel block - in every spectra. -symbols: - doc: | - These symbols will denote how the shape of the parent group's data field, - - .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) - - could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, - and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, - where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. - O: | - Outer rank - R: | - Region rank -type: group -NXregion(NXobject): - \@region_type: - exists: optional - doc: | - This is ``rectangular`` to describe the region as a hyper-rectangle in - the index space of its parent group's data field. - enumeration: [rectangular] - parent: - doc: | - The name of data field in the parent group or the path of a data field relative - to the parent group (so it could be a field in a subgroup of the parent group) - parent_mask: - doc: | - The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and - dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an - :ref:`NXdetector`. - start(NX_NUMBER): - exists: recommended - doc: | - The starting position for region in detector data field array. - This is recommended as it also defines the region rank. - If omitted then defined as an array of zeros. - dimensions: - rank: 1 - dim: [[1, R]] - count(NX_INT): - exists: recommended - doc: | - The number of blocks or items in the hyperslab selection. - If omitted then defined as an array of dimensions that take into account - the other hyperslab selection fields to span the parent data field's shape. - dimensions: - rank: 1 - dim: [[1, R]] - stride(NX_INT): - doc: | - An optional field to define striding used to downsample data. - If omitted then defined as an array of ones. - dimensions: - rank: 1 - dim: [[1, R]] - block(NX_INT): - doc: | - An optional field to define the block size used to copy or downsample data. In the - :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` - then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` - then the blocks are contiguous; otherwise the blocks overlap. - If omitted then defined as an array of ones. - dimensions: - rank: 1 - dim: [[1, R]] - scale(NX_NUMBER): - doc: | - An optional field to define a divisor for scaling of reduced data. For example, in a - downsampled sum, it can reduce the maximum values to fit in the domain of the result - data type. In an image that is downsampled by summing 2x2 blocks, using - :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as - the parent dataset. - If omitted then no scaling occurs. - dimensions: - rank: 1 - dim: [[1, R]] - downsampled(NXdata): - doc: | - An optional group containing data copied/downsampled from parent group’s data. Its dataset name - must reflect how the downsampling is done over each block. So it could be a reduction operation - such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each - block then use "copy" as the name. Where more than one downsample dataset is written - (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, - the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, - otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. - - The following figure shows how blocks are used in downsampling: - - .. figure:: region/NXregion-example.png - :width: 60% - - A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from - a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. - statistics(NXdata): - doc: | - An optional group containing any statistics derived from the region in parent group’s data - such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one - statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` - listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8426e78db8c7bfc828d27cea0e29c7cc255b78f1ca7e809672cb6b0174497dd0 -# -# -# -# -# -# -# These symbols will denote how the shape of the parent group's data field, -# -# .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) -# -# could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, -# and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, -# where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. -# -# Outer rank -# Region rank -# -# -# Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. -# -# This can be used to describe a subset of data used to create downsampled data or to derive -# some data from that subset. -# -# Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters -# (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, -# then **stride** :math:`\equiv` **step** in Python slicing. -# -# For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: -# -# detector:NXdetector/ -# data[60,256,512] -# region:NXregion/ -# @region_type = "rectangular" -# parent = "data" -# start = [20,50] -# count = [220,120] -# statistics:NXdata/ -# @signal = "sum" -# sum[60] -# -# the ``sum`` dataset contains the summed areas in each frame. -# Another example, a hyperspectral image downsampled 16-fold in energy:: -# -# detector:NXdetector/ -# data[128,128,4096] -# region:NXregion/ -# @region_type = "rectangular" -# parent = "data" -# start = [2] -# count = [20] -# stride = [32] -# block = [16] -# downsampled:NXdata/ -# @signal = "maximum" -# @auxiliary_signals = "copy" -# maximum[128,128,20] -# copy[128,128,320] -# -# the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, -# the ``maximum`` dataset will show maximum values in each 16-channel block -# in every spectra. -# -# -# -# This is ``rectangular`` to describe the region as a hyper-rectangle in -# the index space of its parent group's data field. -# -# -# -# -# -# -# -# The name of data field in the parent group or the path of a data field relative -# to the parent group (so it could be a field in a subgroup of the parent group) -# -# -# -# -# The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and -# dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an -# :ref:`NXdetector`. -# -# -# -# -# The starting position for region in detector data field array. -# This is recommended as it also defines the region rank. -# If omitted then defined as an array of zeros. -# -# -# -# -# -# -# -# The number of blocks or items in the hyperslab selection. -# If omitted then defined as an array of dimensions that take into account -# the other hyperslab selection fields to span the parent data field's shape. -# -# -# -# -# -# -# -# An optional field to define striding used to downsample data. -# If omitted then defined as an array of ones. -# -# -# -# -# -# -# -# An optional field to define the block size used to copy or downsample data. In the -# :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` -# then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` -# then the blocks are contiguous; otherwise the blocks overlap. -# If omitted then defined as an array of ones. -# -# -# -# -# -# -# -# An optional field to define a divisor for scaling of reduced data. For example, in a -# downsampled sum, it can reduce the maximum values to fit in the domain of the result -# data type. In an image that is downsampled by summing 2x2 blocks, using -# :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as -# the parent dataset. -# If omitted then no scaling occurs. -# -# -# -# -# -# -# -# An optional group containing data copied/downsampled from parent group’s data. Its dataset name -# must reflect how the downsampling is done over each block. So it could be a reduction operation -# such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each -# block then use "copy" as the name. Where more than one downsample dataset is written -# (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, -# the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, -# otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. -# -# The following figure shows how blocks are used in downsampling: -# -# .. figure:: region/NXregion-example.png -# :width: 60% -# -# A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from -# a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. -# -# -# -# -# -# An optional group containing any statistics derived from the region in parent group’s data -# such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one -# statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` -# listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. -# -# -# diff --git a/contributed_definitions/nyaml/NXregistration.yaml b/contributed_definitions/nyaml/NXregistration.yaml deleted file mode 100644 index 39229b31a2..0000000000 --- a/contributed_definitions/nyaml/NXregistration.yaml +++ /dev/null @@ -1,15 +0,0 @@ -category: base -doc: "Describes image registration procedures." -NXregistration: - applied(NX_BOOLEAN): - doc: "Has the registration been applied?" - last_process(NX_CHAR): - doc: "Indicates the name of the last operation applied in the NXprocess sequence." - depends_on(NX_CHAR): - doc: "Specifies the position by pointing to the last transformation in the transformation chain in the NXtransformations group." - (NXtransformations): - doc: - "To describe the operations of image registration (combinations of rigid - translations and rotations)" - description(NX_CHAR): - doc: "Description of the procedures employed." diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml deleted file mode 100644 index 19436b41e6..0000000000 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ /dev/null @@ -1,29 +0,0 @@ -category: base -doc: | - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. -NXscanbox_em: - calibration_style: - center(NX_NUMBER): - unit: NX_ANY - # \@units: - # enumeration: nm - flyback_time(NX_FLOAT): - unit: NX_TIME - line_time(NX_FLOAT): - unit: NX_TIME - pixel_time(NX_FLOAT): - # pixel_dwell_time? - unit: NX_TIME - requested_pixel_time(NX_FLOAT): - unit: NX_TIME - rotation(NX_FLOAT): - unit: NX_ANGLE - ac_line_sync(NX_BOOLEAN): - (NXfabrication): -# (NXcg_point_set): -# NEW ISSUE: build on work of EMglossary with HMC and use duty cycle instead -# NEW ISSUE: make use of and define duty cycle diff --git a/contributed_definitions/nyaml/NXsensor_scan.yaml b/contributed_definitions/nyaml/NXsensor_scan.yaml deleted file mode 100644 index bcc0e3adef..0000000000 --- a/contributed_definitions/nyaml/NXsensor_scan.yaml +++ /dev/null @@ -1,131 +0,0 @@ -category: application -doc: | - Application definition for a generic scan using sensors. - - In this application definition, times should be specified always together - with an UTC offset. -symbols: - doc: "Variables used to set a common size for collected sensor data." - N_scanpoints: "The number of scan points measured in this scan." -NXsensor_scan: - (NXentry): - definition(NX_CHAR): - \@version: - enumeration: [NXsensor_scan] - experiment_identifier(NX_CHAR): - exists: recommended - experiment_description(NX_CHAR): - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - (NXprocess): - doc: | - Define the program that was used to generate the results file(s) - with measured data and metadata. - program(NX_CHAR): - doc: | - Commercial or otherwise defined given name of the program - (or a link to the instrument software). - \@version: - doc: | - Either version with build number, commit hash, or description of an - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@program_url: - doc: | - Website of the software. - (NXuser): - doc: | - Contact information of at least the user of the instrument or the - investigator who performed this experiment. Adding multiple users if - relevant is recommended. - name(NX_CHAR): - doc: | - Name of the user. - affiliation(NX_CHAR): - exists: recommended - doc: | - Name of the affiliation of the user at the point in time when - the experiment was performed. - address(NX_CHAR): - exists: recommended - doc: | - Full address (street, street number, ZIP, city, country) - of the user's affiliation. - email(NX_CHAR): - exists: recommended - doc: | - Email address of the user. - orcid(NX_CHAR): - exists: recommended - doc: | - Author ID defined by https://orcid.org/. - telephone_number(NX_CHAR): - exists: recommended - doc: | - Official telephone number of the user. - (NXinstrument): - (NXenvironment): - doc: | - Describes an environment setup for the experiment. - - All the setting values of the independently scanned controllers are listed under corresponding - NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each - measurement sensor. - - For example, in a temperature-dependent IV measurement, the temperature and voltage must be - present as independently scanned controllers and the current sensor must also be present with - its readings. - (NXsensor): - (NXdata): - exists: recommended - doc: | - Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. - value(NX_FLOAT): - unit: NX_ANY - doc: | - For each point in the scan space, either the nominal setpoint of an independently scanned controller - or a representative average value of a measurement sensor is registered. - - The length of each sensor's data value array stored in this group should be equal to the number of scan points - probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. - This allows the scan to be made in any order as the user describes above in the experiment. We get matching - values simply using the index of the scan point. - dimensions: - rank: 1 - dim: [[1, N_scanpoints]] - - value_timestamp(NX_DATE_TIME): - exists: recommended - doc: | - Timestamp for when the values provided in the value field were registered. - - Individual readings can be stored with their timestamps under value_log. This is to timestamp - the nominal setpoint or average reading values listed above in the value field. - run_control(NX_CHAR): - exists: recommended - \@description: - doc: | - Free-text describing the data acquisition control: an internal - sweep using the built-in functionality of the controller device, - or a set/wait/read/repeat mechanism. - calibration_time(NX_DATE_TIME): - doc: | - ISO8601 datum when calibration was last performed - before this measurement. UTC offset should be specified. - (NXpid): - independent_controllers: - doc: | - A list of names of NXsensor groups used as independently scanned controllers. - measurement_sensors: - doc: | - A list of names of NXsensor groups used as measurement sensors. - (NXsample): - name(NX_CHAR): - (NXdata): - doc: | - A scan specific representation of the measured signals as a function of the independently controlled environment settings. - Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. diff --git a/contributed_definitions/nyaml/NXseparator.yaml b/contributed_definitions/nyaml/NXseparator.yaml deleted file mode 100644 index f3d94ab6ac..0000000000 --- a/contributed_definitions/nyaml/NXseparator.yaml +++ /dev/null @@ -1,108 +0,0 @@ -category: base -doc: | - definition for an electrostatic separator. -type: group -NXseparator(NXobject): - description(NX_CHAR): - doc: | - extended description of the separator. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - set_Bfield_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on magnet supply. - read_Bfield_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from magnet supply. - value: - unit: NX_CURRENT - read_Bfield_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from magnet supply. - value: - unit: NX_VOLTAGE - set_Efield_voltage(NX_FLOAT): - unit: NX_VOLTAGE - exists: ['min', '0', 'max', '1'] - doc: | - current set on HT supply. - read_Efield_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from HT supply. - value: - unit: NX_CURRENT - read_Efield_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from HT supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0221be104fb3192c4a5b942ad422bee251f3519e222030df39dbc3acf85b4fc4 -# -# -# -# -# definition for an electrostatic separator. -# -# extended description of the separator. -# -# -# define position of beamline element relative to production target -# -# -# current set on magnet supply. -# -# -# current read from magnet supply. -# -# -# -# voltage read from magnet supply. -# -# -# -# current set on HT supply. -# -# -# current read from HT supply. -# -# -# -# voltage read from HT supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml deleted file mode 100644 index 89e708ec77..0000000000 --- a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml +++ /dev/null @@ -1,100 +0,0 @@ -category: base -doc: | - Metadata to the results of a similarity grouping analysis. - - Similarity grouping analyses can be supervised segmentation or machine learning - clustering algorithms. These are routine methods which partition the member of - a set of objects/geometric primitives into (sub-)groups, features of - different type. A plethora of algorithms have been proposed which can be applied - also on geometric primitives like points, triangles, or (abstract) features aka - objects (including categorical sub-groups). - - This base class considers metadata and results of one similarity grouping - analysis applied to a set in which objects are either categorized as noise - or belonging to a cluster. - As the results of the analysis each similarity group, here called feature - aka object can get a number of numerical and/or categorical labels. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - c: Cardinality of the set. - n_lbl_num: Number of numerical labels per object. - n_lbl_cat: Number of categorical labels per object. - n_features: Total number of similarity groups aka features, objects, clusters. -NXsimilarity_grouping: - cardinality(NX_UINT): - doc: Number of members in the set which is partitioned into features. - unit: NX_UNITLESS - number_of_numeric_labels(NX_UINT): - doc: How many numerical labels does each feature have. - unit: NX_UNITLESS - number_of_categorical_labels(NX_UINT): - doc: How many categorical labels does each feature have. - unit: NX_UNITLESS - # features: - # doc: | - # Reference to a set of features investigated in a cluster analysis. - # Features need to have disjoint numeric identifier. - identifier_offset(NX_UINT): - doc: | - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_lbl_num]] - numerical_label(NX_UINT): - doc: | - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the cluster_identifier. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, c], [2, n_lbl_num]] - categorical_label(NX_CHAR): - doc: | - Matrix of categorical attribute data for each member in the set. - # list instances of base classes of an applied cluster algorithm - # e.g. (NXclustering_hdbscan): - dimensions: - rank: 2 - dim: [[1, c], [2, n_lbl_cat]] - statistics(NXprocess): - doc: | - In addition to the detailed storage which members was grouped to which - feature/group summary statistics are stored under this group. - # at the level of the set - number_of_unassigned_members(NX_UINT): - doc: Total number of members in the set which are categorized as unassigned. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_lbl_num]] - noise(NX_UINT): - doc: Total number of members in the set which are categorized as noise. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_lbl_num]] - # at the level of the feature set - number_of_features(NX_UINT): - doc: Total number of clusters (excluding noise and unassigned). - unit: NX_UNITLESS - feature_identifier(NX_UINT): - doc: Array of numerical identifier of each feature (cluster). - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_features], [2, n_lbl_num]] - feature_member_count(NX_UINT): - doc: Array of number of members for each feature. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_features], [2, n_lbl_num]] diff --git a/contributed_definitions/nyaml/NXslip_system_set.yaml b/contributed_definitions/nyaml/NXslip_system_set.yaml deleted file mode 100644 index da0651ea37..0000000000 --- a/contributed_definitions/nyaml/NXslip_system_set.yaml +++ /dev/null @@ -1,38 +0,0 @@ -category: base -doc: | - Base class for describing a set of crystallographic slip systems. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n: Number of slip systems. -NXslip_system_set: - # number_of_objects(NX_UINT): - # identifier_offset(NX_UINT): - # identifier(NX_UINT): - lattice_type: - # doc: Array of lattice types. - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, trigonal, hexagonal, cubic] - # dimensions: - # rank: 1 - # dim: [[1, n]] - miller_plane(NX_NUMBER): - doc: Array of Miller indices which describe the crystallographic plane. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n], [2, i]] - # fastest changing dimension needs to be i because for instance for hexagonal hkil is needed - miller_direction(NX_NUMBER): - doc: Array of Miller indices which describe the crystallographic direction. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n], [2, i]] - is_specific(NX_BOOLEAN): - doc: | - For each slip system a marker whether the specified Miller indices - refer to the specific slip system or the set of crystallographic equivalent - slip systems of the respective family of slip systems. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n]] diff --git a/contributed_definitions/nyaml/NXsnsevent.yaml b/contributed_definitions/nyaml/NXsnsevent.yaml deleted file mode 100644 index dae92ff25b..0000000000 --- a/contributed_definitions/nyaml/NXsnsevent.yaml +++ /dev/null @@ -1,640 +0,0 @@ -category: application -doc: | - This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. -type: group -NXsnsevent(NXobject): - (NXentry): - exists: ['min', '1'] - (NXcollection)DASlogs: - doc: | - Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). - (NXlog): - exists: ['min', '1'] - average_value(NX_FLOAT): - average_value_error(NX_FLOAT): - exists: optional - deprecated: - see https://github.com/nexusformat/definitions/issues/821 - average_value_errors(NX_FLOAT): - description: - duration(NX_FLOAT): - maximum_value(NX_FLOAT): - minimum_value(NX_FLOAT): - time(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nvalue]] - value(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nvalue]] - (NXpositioner): - exists: ['min', '0'] - doc: | - Motor logs from cvinfo file. - average_value(NX_FLOAT): - average_value_error(NX_FLOAT): - exists: optional - deprecated: - see https://github.com/nexusformat/definitions/issues/821 - average_value_errors(NX_FLOAT): - description: - duration(NX_FLOAT): - maximum_value(NX_FLOAT): - minimum_value(NX_FLOAT): - time(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, numvalue]] - value(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, numvalue]] - (NXnote)SNSHistoTool: - SNSbanking_file_name: - SNSmapping_file_name: - author: - command1: - doc: | - Command string for event2nxl. - date: - description: - version: - (NXdata): - exists: ['min', '1'] - - # for all NXdata/banks - data_x_y(link): - target: /NXentry/NXinstrument/NXdetector/data_x_y - x_pixel_offset(link): - target: /NXentry/NXinstrument/NXdetector/x_pixel_offset - y_pixel_offset(link): - target: /NXentry/NXinstrument/NXdetector/y_pixel_offset - (NXevent_data): - exists: ['min', '1'] - - # for all NXdata/banks - event_index(link): - target: /NXentry/NXinstrument/NXdetector/event_index - event_pixel_id(link): - target: /NXentry/NXinstrument/NXdetector/event_pixel_id - event_time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/event_time_of_flight - pulse_time(link): - target: /NXentry/NXinstrument/NXdetector/pulse_time - collection_identifier: - collection_title: - definition: - doc: | - Official NXDL schema after this file goes to applications. - enumeration: [NXsnsevent] - duration(NX_FLOAT): - unit: NX_TIME - end_time(NX_DATE_TIME): - entry_identifier: - experiment_identifier: - (NXinstrument)instrument: - (NXsource)SNS: - frequency(NX_FLOAT): - unit: NX_FREQUENCY - name: - probe: - type: - SNSdetector_calibration_id: - doc: | - Detector calibration id from DAS. - SNSgeometry_file_name: - - # SNSnxtranslate - SNStranslation_service: - (NXdetector): - exists: ['min', '1'] - - # for all NXdetector/banks - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - data_x_y(NX_UINT): - doc: | - expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" - - # axes are set in data files - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - event_index(NX_UINT): - dimensions: - rank: 1 - dim: [[1, numpulses]] - event_pixel_id(NX_UINT): - dimensions: - rank: 1 - dim: [[1, numevents]] - event_time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, numevents]] - (NXgeometry)origin: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - pixel_id(NX_UINT): - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - pulse_time(NX_FLOAT): - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, numpulses]] - total_counts(NX_UINT): - x_pixel_offset(NX_FLOAT): - axis: 1 - primary: 1 - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, numx]] - y_pixel_offset(NX_FLOAT): - axis: 2 - primary: 1 - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, numy]] - beamline: - (NXdisk_chopper): - exists: ['min', '0'] - distance(NX_FLOAT): - unit: NX_LENGTH - (NXmoderator)moderator: - coupling_material: - distance(NX_FLOAT): - unit: NX_LENGTH - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - type: - name: - (NXaperture): - exists: ['min', '0'] - (NXgeometry)origin: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - x_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - (NXattenuator): - exists: ['min', '0'] - distance(NX_FLOAT): - unit: NX_LENGTH - - # motor links from DASlogs when exist - (NXpolarizer): - exists: ['min', '0'] - - # motor links from DASlogs when exist - (NXcrystal): - exists: ['min', '0'] - (NXgeometry)origin: - description: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - type: - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - (NXmonitor): - exists: ['min', '0'] - data(NX_UINT): - doc: | - expect ``signal=1 axes="time_of_flight"`` - dimensions: - rank: 1 - dim: [[1, numtimechannels]] - distance(NX_FLOAT): - unit: NX_LENGTH - mode: - time_of_flight(NX_FLOAT): - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, numtimechannels + 1]] - notes: - proton_charge(NX_FLOAT): - unit: NX_CHARGE - raw_frames(NX_INT): - run_number: - (NXsample)sample: - changer_position: - holder: - identifier: - name: - doc: | - Descriptive name of sample - nature: - start_time(NX_DATE_TIME): - title: - total_counts(NX_UINT): - unit: NX_UNITLESS - total_uncounted_counts(NX_UINT): - unit: NX_UNITLESS - (NXuser): - exists: ['min', '1'] - facility_user_id: - name: - role: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5c4b685e1799791496ef54d585f15144de4b9a3fd442811acae7f43aadc3dd34 -# -# -# -# -# This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. -# -# -# -# Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Motor logs from cvinfo file. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Command string for event2nxl. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Official NXDL schema after this file goes to applications. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Detector calibration id from DAS. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# expect ``signal=1 axes="time_of_flight"`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsnshisto.yaml b/contributed_definitions/nyaml/NXsnshisto.yaml deleted file mode 100644 index adbb825170..0000000000 --- a/contributed_definitions/nyaml/NXsnshisto.yaml +++ /dev/null @@ -1,670 +0,0 @@ -category: application -doc: | - This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. -type: group -NXsnshisto(NXobject): - (NXentry): - exists: ['min', '1'] - (NXcollection)DASlogs: - doc: | - Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). - (NXlog): - exists: ['min', '1'] - average_value(NX_FLOAT): - average_value_error(NX_FLOAT): - exists: optional - deprecated: - see https://github.com/nexusformat/definitions/issues/821 - average_value_errors(NX_FLOAT): - description: - duration(NX_FLOAT): - maximum_value(NX_FLOAT): - minimum_value(NX_FLOAT): - time(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nvalue]] - value(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nvalue]] - (NXpositioner): - exists: ['min', '0'] - doc: | - Motor logs from cvinfo file. - average_value(NX_FLOAT): - average_value_error(NX_FLOAT): - exists: optional - deprecated: - see https://github.com/nexusformat/definitions/issues/821 - average_value_errors(NX_FLOAT): - description: - duration(NX_FLOAT): - maximum_value(NX_FLOAT): - minimum_value(NX_FLOAT): - time(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, numvalue]] - value(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, numvalue]] - (NXnote)SNSHistoTool: - SNSbanking_file_name: - SNSmapping_file_name: - author: - command1: - doc: | - Command string for event2histo_nxl. - date: - description: - version: - (NXdata): - exists: ['min', '1'] - - # for all NXdata/banks - data(link): - target: /NXentry/NXinstrument/NXdetector/data - data_x_time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/data_x_time_of_flight - data_x_y(link): - target: /NXentry/NXinstrument/NXdetector/data_x_y - data_y_time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/data_y_time_of_flight - pixel_id(link): - target: /NXentry/NXinstrument/NXdetector/pixel_id - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - total_counts(link): - target: /NXentry/NXinstrument/NXdetector/total_counts - x_pixel_offset(link): - target: /NXentry/NXinstrument/NXdetector/x_pixel_offset - y_pixel_offset(link): - target: /NXentry/NXinstrument/NXdetector/y_pixel_offset - collection_identifier: - collection_title: - definition: - doc: | - Official NXDL schema after this file goes to applications. - enumeration: [NXsnshisto] - duration(NX_FLOAT): - unit: NX_TIME - end_time(NX_DATE_TIME): - entry_identifier: - experiment_identifier: - (NXinstrument)instrument: - (NXsource)SNS: - frequency(NX_FLOAT): - unit: NX_FREQUENCY - name: - probe: - type: - SNSdetector_calibration_id: - doc: | - Detector calibration id from DAS. - SNSgeometry_file_name: - - # SNSnxtranslate - SNStranslation_service: - (NXdetector): - exists: ['min', '1'] - - # for all NXdetector/banks - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - data(NX_UINT): - signal: 1 - axes: x_pixel_offset,y_pixel_offset,time_of_flight - dimensions: - rank: 3 - dim: [[1, numx], [2, numy], [3, numtof]] - data_x_time_of_flight(NX_UINT): - signal: 3 - axes: x_pixel_offset,time_of_flight - dimensions: - rank: 2 - dim: [[1, numx], [2, numtof]] - data_x_y(NX_UINT): - signal: 2 - axes: x_pixel_offset,y_pixel_offset - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - data_y_time_of_flight(NX_UINT): - signal: 4 - axes: y_pixel_offset,time_of_flight - dimensions: - rank: 2 - dim: [[1, numy], [2, numtof]] - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - (NXgeometry)origin: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - pixel_id(NX_UINT): - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - time_of_flight(NX_FLOAT): - axis: 3 - primary: 1 - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, numtof + 1]] - total_counts(NX_UINT): - x_pixel_offset(NX_FLOAT): - axis: 1 - primary: 1 - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, numx]] - y_pixel_offset(NX_FLOAT): - axis: 2 - primary: 1 - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, numy]] - beamline: - (NXdisk_chopper): - exists: ['min', '0'] - doc: | - Original specification called for NXchopper, - which is not a valid NeXus base class. - Select either NXdisk_chopper or NXfermi_chopper, as appropriate. - distance(NX_FLOAT): - unit: NX_LENGTH - (NXfermi_chopper): - exists: ['min', '0'] - doc: | - Original specification called for NXchopper, - which is not a valid NeXus base class. - Select either NXdisk_chopper or NXfermi_chopper, as appropriate. - distance(NX_FLOAT): - unit: NX_LENGTH - (NXmoderator)moderator: - coupling_material: - distance(NX_FLOAT): - unit: NX_LENGTH - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - type: - name: - (NXaperture): - exists: ['min', '0'] - (NXgeometry)origin: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - x_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - (NXattenuator): - exists: ['min', '0'] - distance(NX_FLOAT): - unit: NX_LENGTH - - # motor links from DASlogs when exist - (NXpolarizer): - exists: ['min', '0'] - - # motor links from DASlogs when exist - (NXcrystal): - exists: ['min', '0'] - (NXgeometry)origin: - description: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - type: - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - (NXmonitor): - exists: ['min', '0'] - data(NX_UINT): - signal: 1 - axes: time_of_flight - dimensions: - rank: 1 - dim: [[1, numtimechannels]] - distance(NX_FLOAT): - unit: NX_LENGTH - mode: - time_of_flight(NX_FLOAT): - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, numtimechannels + 1]] - notes: - proton_charge(NX_FLOAT): - unit: NX_CHARGE - raw_frames(NX_INT): - run_number: - (NXsample)sample: - changer_position: - holder: - identifier: - name: - doc: | - Descriptive name of sample - nature: - start_time(NX_DATE_TIME): - title: - total_counts(NX_UINT): - unit: NX_UNITLESS - total_uncounted_counts(NX_UINT): - unit: NX_UNITLESS - (NXuser): - exists: ['min', '1'] - facility_user_id: - name: - role: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 416fcb00afa79775d07f92148b37bcc4250c622609ced0374cc7490a7349ee25 -# -# -# -# -# This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. -# -# -# -# Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Motor logs from cvinfo file. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Command string for event2histo_nxl. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Official NXDL schema after this file goes to applications. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Detector calibration id from DAS. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Original specification called for NXchopper, -# which is not a valid NeXus base class. -# Select either NXdisk_chopper or NXfermi_chopper, as appropriate. -# -# -# -# -# -# Original specification called for NXchopper, -# which is not a valid NeXus base class. -# Select either NXdisk_chopper or NXfermi_chopper, as appropriate. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsolenoid_magnet.yaml b/contributed_definitions/nyaml/NXsolenoid_magnet.yaml deleted file mode 100644 index ae5f355fa5..0000000000 --- a/contributed_definitions/nyaml/NXsolenoid_magnet.yaml +++ /dev/null @@ -1,84 +0,0 @@ -category: base -doc: | - definition for a solenoid magnet. -type: group -NXsolenoid_magnet(NXobject): - description(NX_CHAR): - doc: | - extended description of the magnet. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - set_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on supply. - read_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from supply. - value: - unit: NX_CURRENT - read_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1364b1b892354a667957c67d8d4d7b6ebb5f1a1bd7fc2dc5876622ed45239995 -# -# -# -# -# definition for a solenoid magnet. -# -# extended description of the magnet. -# -# -# define position of beamline element relative to production target -# -# -# current set on supply. -# -# -# current read from supply. -# -# -# -# voltage read from supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXsolid_geometry.yaml b/contributed_definitions/nyaml/NXsolid_geometry.yaml deleted file mode 100644 index 3d752e4626..0000000000 --- a/contributed_definitions/nyaml/NXsolid_geometry.yaml +++ /dev/null @@ -1,76 +0,0 @@ -category: base -doc: | - the head node for constructively defined geometry -type: group -NXsolid_geometry(NXobject): - (NXquadric): - exists: ['min', '0'] - doc: | - Instances of :ref:`NXquadric` making up elements of the geometry. - (NXoff_geometry): - exists: ['min', '0'] - doc: | - Instances of :ref:`NXoff_geometry` making up elements of the geometry. - (NXcsg): - exists: ['min', '0'] - doc: | - The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 71a1b3ca39b88fdae9499a10284ddc6fd89423b5d2e3e1d544bacfa3793bb5c0 -# -# -# -# -# -# the head node for constructively defined geometry -# -# -# -# Instances of :ref:`NXquadric` making up elements of the geometry. -# -# -# -# -# Instances of :ref:`NXoff_geometry` making up elements of the geometry. -# -# -# -# -# The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. -# -# -# diff --git a/contributed_definitions/nyaml/NXspatial_filter.yaml b/contributed_definitions/nyaml/NXspatial_filter.yaml deleted file mode 100644 index 7f2b341296..0000000000 --- a/contributed_definitions/nyaml/NXspatial_filter.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Spatial filter to filter entries within a region-of-interest based on their position. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ellipsoids: Number of ellipsoids. - n_hexahedra: Number of hexahedra. - n_cylinders: Number of cylinders. -# n_polyhedra: Number of polyhedra. -# n_vertices: Number of vertices for polyhedra. -# n_facets: Number of facets for polyhedra. -NXspatial_filter: - windowing_method: - doc: | - Qualitative statement which specifies which spatial filtering with respective - geometric primitives or bitmask is used. These settings are possible: - - * entire_dataset, no filter is applied, the entire dataset is used. - * union_of_primitives, a filter with (rotated) geometric primitives. - All ions in or on the surface of the primitives are considered - while all other ions are ignored. - * bitmasked_points, a boolean array whose bits encode with 1 - which ions should be included. Those ions whose bit is set to 0 - will be excluded. Users of python can use the bitfield operations - of the numpy package to define such bitfields. - - Conditions: - In the case that windowing_method is entire_dataset all entries are processed. - In the case that windowing_method is union_of_primitives, - it is possible to specify none or all types of primitives - (ellipsoids, cylinder, hexahedra). If no primitives are specified - the filter falls back to entire_dataset. - In the case that windowing_method is bitmask, the bitmask has to be defined; - otherwise the filter falls back to entire dataset. - enumeration: [entire_dataset, union_of_primitives, bitmask] - (NXcg_ellipsoid_set): - (NXcg_cylinder_set): - (NXcg_hexahedron_set): - (NXcs_filter_boolean_mask): diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml deleted file mode 100644 index 1b44d65938..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set.yaml +++ /dev/null @@ -1,91 +0,0 @@ -category: base -doc: | - Container for reporting a set of spectra. -symbols: -# n_p: Number of scan points - n_y: Number of pixel in the slow direction. - n_x: Number of pixel in the fast direction. - n_energy: Number of energy bins. -NXspectrum_set: - (NXprocess): - doc: | - Details how spectra were processed from the detector readings. - source: - doc: | - Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - mode: - doc: | - Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - detector_identifier: - doc: | - Link or name of an NXdetector instance with which the data were collected. - (NXprogram): - # ##MK::feel free to contact us when you would like to include more complicated scan pattern than rectangular ones. - stack(NXdata): - doc: | - Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, n_energy]] - \@long_name: - doc: Counts - # \@signal: counts - # \@axes: [ypos, xpos, energy] - # \@ypos_indices: 0 - # \@xpos_indices: 1 - # \@energy_indices: 2 - axis_y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Coordinate along y direction - axis_x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Coordinate along x direction - axis_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - doc: Energy - # in the majority of cases rectangular or line scans are performed - # if there is interest to support arbitrary scan pattern one should use - # scan points and contact us to generalize this base class and related - # base classes - summary(NXdata): - doc: | - Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - doc: Counts - # \@signal: counts - # \@axes: [energy] - # \@energy_indices: 0 - axis_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - doc: Energy diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml deleted file mode 100644 index 69a903a2c8..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml +++ /dev/null @@ -1,105 +0,0 @@ -category: base -doc: | - Container for reporting a set of electron energy loss (EELS) spectra. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - - The latter pattern is the most frequently used. - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. -symbols: -# n_p: Number of scan points - n_y: Number of pixel per EELS mapping in the slow direction. - n_x: Number of pixel per EELS mapping in the fast direction. - n_energy_loss: Number of electron energy loss bins. -NXspectrum_set_em_eels: - (NXprocess): - doc: | - Details how EELS spectra were processed from the detector readings. - source: - doc: | - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXspectrum_set_em_eels were loaded during - parsing to represent them in e.g. databases. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - program: - doc: | - Commercial or otherwise given name to the program which was used - to process detector data into the EELS spectra stack and summary. - \@version: - doc: | - Program 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. - stack(NXdata): - doc: | - Collected EELS spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - doc: Counts for one spectrum per each pixel. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, n_energy_loss]] - \@long_name: - doc: EELS counts - # \@signal: counts - # \@axes: [ypos, xpos, energy_loss] - # \@energy_loss_indices: 2 - # \@xpos_indices: 1 - # \@ypos_indices: 0 - axis_y(NX_NUMBER): - doc: Pixel center of mass position y-coordinates. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Coordinate along y direction. - axis_x(NX_NUMBER): - doc: Pixel center of mass position x-coordinates. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Coordinate along x direction. - axis_energy_loss(NX_NUMBER): - doc: Pixel center of mass energy loss bins. - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy_loss]] - \@long_name: - doc: Coordinate along energy loss axis. - summary(NXdata): - doc: | - Accumulated EELS spectrum over all pixels of a rectangular - region-of-interest. This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - doc: Counts for specific energy losses. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_energy_loss]] - \@long_name: - doc: Counts electrons with an energy loss within binned range. - # \@signal: counts - # \@axes: [energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - doc: Pixel center of mass energy loss bins. - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy_loss]] - \@long_name: - doc: Coordinate along energy loss axis. diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml deleted file mode 100644 index 1cdd2f9019..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml +++ /dev/null @@ -1,196 +0,0 @@ -category: base -doc: | - Container for reporting a set of energy-dispersive X-ray spectra. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - `IUPAC instead of Siegbahn notation `_ - should be used. -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: -# n_p: Number of scan points - n_y: Number of pixel per X-ray mapping in the slow direction - n_x: Number of pixel per X-ray mapping in the fast direction - n_photon_energy: Number of X-ray photon energy (bins) - n_elements: Number of identified elements - n_peaks: Number of peaks -NXspectrum_set_em_xray: - (NXprocess): - doc: | - Details how X-ray spectra were processed from the detector readings. - source: - doc: | - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXspectrum_set_em_xray were loaded during - parsing to represent them in e.g. databases. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - program: - doc: | - Commercial or otherwise given name to the program which was used - to process detector data into the X-ray spectra stack and summary. - \@version: - doc: | - Program 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. - # ##MK::for supporting arbitrary scan pattern we need a good example first - # ##MK::feel free to contact us in this regard! - stack(NXdata): - doc: | - Collected X-ray spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, n_photon_energy]] - \@long_name: - doc: X-ray photon counts - # \@signal: counts - # \@axes: [ypos, xpos, photon_energy] - # \@ypos_indices: 0 - # \@xpos_indices: 1 - # \@photon_energy_indices: 2 - axis_y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Coordinate along y direction. - axis_x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Coordinate along x direction. - axis_photon_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_photon_energy]] - \@long_name: - doc: Photon energy. - summary(NXdata): - doc: | - Accumulated X-ray spectrum over all pixels of a rectangular - region-of-interest. This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_photon_energy]] - \@long_name: - doc: X-ray photon counts - # \@signal: counts - # \@axes: [photon_energy] - # \@photon_energy_indices: 0 - axis_photon_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_photon_energy]] - \@long_name: - doc: Photon energy - - # for post-processing of/with the above-defined data entries - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - program: - doc: | - Given name of the program that was used to perform this computation. - \@version: - doc: | - Program 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. - (NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - iupac_line_names: - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are group with the same peak. - element_names: - doc: List of the names of identified elements. - dimensions: - rank: 1 - dim: [[1, n_elements]] - ELEMENTNAME(NXprocess): - doc: | - Individual element-specific EDX/EDS/EDXS/SXES mapping - - A composition map is an image whose intensities for each pixel are the - accumulated X-ray quanta *under the curve(s)* of a set of peaks. - program: - doc: | - Given name of the program that was used to perform this computation. - \@version: - doc: | - Program 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. - peaks: - doc: | - A list of strings of named instances of NXpeak from indexing - whose X-ray quanta where accumulated for each pixel. - dimensions: - rank: 1 - dim: [[1, n_peaks]] - name: - doc: Human-readable, given name to the image. - # example how an element-specific pattern could be stored - summary(NXdata): - doc: | - Individual element-specific maps. Individual maps should - each be a group and be named according to element_names. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_y], [2, n_x]] - \@long_name: - doc: Accumulated photon counts for observed element. - # \@signal: counts - # \@axes: [ypos, xpos] - # \@xpos_indices: 1 - # \@ypos_indices: 0 - axis_y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Coordinate along y direction. - axis_x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXspin_rotator.yaml b/contributed_definitions/nyaml/NXspin_rotator.yaml deleted file mode 100644 index 8cdf66348c..0000000000 --- a/contributed_definitions/nyaml/NXspin_rotator.yaml +++ /dev/null @@ -1,108 +0,0 @@ -category: base -doc: | - definition for a spin rotator. -type: group -NXspin_rotator(NXobject): - description(NX_CHAR): - doc: | - extended description of the spin rotator. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - set_Bfield_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on magnet supply. - read_Bfield_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from magnet supply. - value: - unit: NX_CURRENT - read_Bfield_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from magnet supply. - value: - unit: NX_VOLTAGE - set_Efield_voltage(NX_FLOAT): - unit: NX_VOLTAGE - exists: ['min', '0', 'max', '1'] - doc: | - current set on HT supply. - read_Efield_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from HT supply. - value: - unit: NX_CURRENT - read_Efield_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from HT supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 260f697bca7fcdb6e806e85e0cb1459de350eab0f1eb633c5b15ac31d38c1572 -# -# -# -# -# definition for a spin rotator. -# -# extended description of the spin rotator. -# -# -# define position of beamline element relative to production target -# -# -# current set on magnet supply. -# -# -# current read from magnet supply. -# -# -# -# voltage read from magnet supply. -# -# -# -# current set on HT supply. -# -# -# current read from HT supply. -# -# -# -# voltage read from HT supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXspindispersion.yaml b/contributed_definitions/nyaml/NXspindispersion.yaml deleted file mode 100644 index 7745255c78..0000000000 --- a/contributed_definitions/nyaml/NXspindispersion.yaml +++ /dev/null @@ -1,38 +0,0 @@ -category: base -doc: - "Subclass of NXelectronanalyser to describe the spin filters in photoemission - experiments." -NXspindispersion: - type(NX_CHAR): - doc: "Type of spin detector, VLEED, SPLEED, Mott, etc. " - figure_of_merit(NX_FLOAT): - doc: "Figure of merit of the spin detector" - unit: NX_DIMENSIONLESS - shermann_function(NX_FLOAT): - doc: "Effective Shermann function, calibrated spin selectivity factor" - unit: NX_DIMENSIONLESS - scattering_energy(NX_FLOAT): - doc: "Energy of the spin-selective scattering " - unit: NX_ENERGY - scattering_angle(NX_FLOAT): - doc: "Angle of the spin-selective scattering" - unit: NX_ANGLE - target(NX_CHAR): - doc: "Name of the target" - target_preparation(NX_CHAR): - doc: "Preparation procedure of the spin target" - target_preparation_date(NX_DATE_TIME): - doc: "Date of last preparation of the spin target" - depends_on(NX_CHAR): - doc: "Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group." - (NXtransformations): - doc: - "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 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." - - (NXdeflector): - doc: "Deflectors in the spin dispersive section" - (NXlens_em): - doc: "Individual lenses in the spin dispersive section" diff --git a/contributed_definitions/nyaml/NXstage_lab.yaml b/contributed_definitions/nyaml/NXstage_lab.yaml deleted file mode 100644 index 9cb60d2d22..0000000000 --- a/contributed_definitions/nyaml/NXstage_lab.yaml +++ /dev/null @@ -1,131 +0,0 @@ -category: base -doc: | - 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 `_ - * `Chip-based designs `_ - * `Further chip-based designs `_ - * `Stages in transmission electron microscopy `_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy `_ (page 124ff) - * `Specimens in atom probe `_ (page 47ff) - * `Exemplar micro-manipulators `_ - -NXstage_lab: - design: - doc: | - 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 - name: - doc: Given name/alias for the components making the stage. - (NXfabrication): - description: - doc: | - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - tilt_1(NX_FLOAT): - doc: Should be defined by the application definition. - unit: NX_ANGLE - tilt_2(NX_FLOAT): - doc: Should be defined by the application definition. - unit: NX_ANGLE - rotation(NX_FLOAT): - doc: Should be defined by the application definition. - unit: NX_ANGLE - position(NX_FLOAT): - doc: Should be defined by the application definition. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - bias_voltage(NX_FLOAT): - doc: Voltage applied to the stage to decelerate electrons. - unit: NX_VOLTAGE - # NEW ISSUE: rather the field if possible should be specified - (NXtransformations): - doc: | - 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. - (NXpositioner): -# see for complicated positioning tools like an eucentric five-axis table stage in an SEM -# https://www.nanotechnik.com/e5as.html -# shipswing_tilt(NXpositioner): -# normal_rotate(NXpositioner): -# normal_height(NXpositioner): -# inplane_translate1(NXpositioner): -# inplane_translate2(NXpositioner): -# NEW ISSUE: add temperature control units and components to apply external stimuli -# NEW ISSUE: on the specimen such as NXmech_testing_unit and NXfurnace, NXreaction_cell -# NEW ISSUE: by contrast, the purpose and design of so-called nano/or micromanipulators, -# i.e. automatable devices to perform e.g. site-specific lift out, procedures warrants -# to define an own class NXspecimen_manipulator given this is nothing else than -# miniature robot arm essential one could also think about creating an own NXrobotarm class, -# below are two examples of such tools as they are used in FIB and SEMs \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/NXsubsampling_filter.yaml deleted file mode 100644 index 96b69dba88..0000000000 --- a/contributed_definitions/nyaml/NXsubsampling_filter.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Settings of a filter to sample entries based on their value. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXsubsampling_filter: - linear_range_min_incr_max(NX_UINT): - doc: | - Triplet of the minimum, increment, and maximum value which will - be included in the analysis. The increment controls which n-th entry to take. - - Take as an example a dataset with 100 entries (their indices start at zero) - and the filter set to 0, 1, 99. This will process each entry. - 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third - entry beginning from entry 90 up to 99. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 3]] diff --git a/contributed_definitions/nyaml/NXtransmission.yaml b/contributed_definitions/nyaml/NXtransmission.yaml deleted file mode 100644 index ce2c2fd0a0..0000000000 --- a/contributed_definitions/nyaml/NXtransmission.yaml +++ /dev/null @@ -1,211 +0,0 @@ -# FAIRmat consortium 21.07.2022 -# Draft NeXus application definition for transmission experiments - -category: application -doc: Application definition for transmission experiments -symbols: - doc: Variables used throughout the experiment - N_wavelengths: Number of wavelength points - N_scans: Number of scans - -NXtransmission: - (NXentry): - doc: | - This application definition - definition: - doc: "An application definition for transmission." - \@version: - doc: "Version number to identify which definition of this application - definition was used for this entry/data." - \@url: - doc: "URL where to find further material (documentation, examples) - relevant to the application definition." - enumeration: [NXtransmission] - start_time(NX_DATE_TIME): - doc: "Start time of the experiment." - experiment_identifier(NX_CHAR): - doc: | - Unique identifier of the experiment, such as a (globally persistent) - unique identifier. - - * The identifier is usually defined by the facility or principle - investigator. - * The identifier enables to link experiments to e.g. proposals. - experiment_description(NX_CHAR): - exists: optional - doc: "An optional free-text description of the experiment. - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description." - acquisition_program(NXfabrication): - # TODO: Just used a NXmanufacturer, maybe - # it is nicer to introduce a general NXprogram class? - # However, a program may also be viewed as some sort - # of instrument. - exists: optional - model(NX_CHAR): - doc: | - Commercial or otherwise defined given name to the program that was - used to generate the result file(s) with measured data and metadata. - identifier(NX_CHAR): - doc: | - Version number of the program that was used to generate the result - file(s) with measured data and metadata. - \@url(NX_CHAR): - exists: recommended - doc: Website of the software - operator(NXuser): - exists: [min, 1] - doc: "Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users if relevant is recommended." - name: - doc: "Name of the user." - affiliation: - doc: "Name of the affiliation of the user at the point in time when the - experiment was performed." - address: - doc: "Street address of the user's affiliation." - email: - doc: "Email address of the user." - url: - exists: recommended - doc: | - Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). - telephone_number: - exists: recommended - doc: "Telephone number of the user." - instrument(NXinstrument): - manufacturer(NXfabrication): - exists: recommended - doc: "Manufacturer of the instrument." - common_beam_mask(NXslit): - doc: Common beam mask to shape the incident beam - y_gap(NX_NUMBER): - doc: "The height of the common beam in percentage of the beam" - unit: NX_UNITLESS - common_beam_depolarizer(NX_BOOLEAN): - doc: | - If true, the incident beam is depolarized. - polarizer(NX_NUMBER): - doc: Polarizer value inside the beam path - unit: NX_ANGLE - ref_attenuator(NXattenuator): - doc: Attenuator in the reference beam - attenuator_transmission(NX_FLOAT): - sample_attenuator(NXattenuator): - doc: Attenuator in the sample beam - attenuator_transmission(NX_FLOAT): - spectrometer(NXmonochromator): - wavelength(NX_NUMBER): - doc: | - Wavelength value(s) used for the measurement. - An array of 1 or more elements. Length defines N_wavelenghts - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, N_wavelengths]] - spectral_resolution(NX_NUMBER): - doc: | - Overall spectral resolution of this spectrometer. - If several gratings are employed the spectral resoultion - should rather be specified for each grating inside the - NXgrating group of this spectrometer. - exists: optional - unit: NX_WAVENUMBER - (NXgrating): - exists: optional - doc: | - Diffraction grating, as could be used in a monochromator. - If two or more gratings were used, define the angular - dispersion and the wavelength range (min/max wavelength) - for each grating and make sure that the wavelength ranges - do not overlap. The dispersion should be defined for the - entire wavelength range of the experiment. - angular_dispersion(NX_NUMBER): - exists: optional - doc: Dispersion of the grating in nm/mm used. - blaze_wavelength(NX_NUMBER): - exists: optional - doc: The blaze wavelength of the grating used. - unit: NX_LENGTH - spectral_resolution(NX_NUMBER): - exists: optional - doc: | - Overall spectral resolution of the instrument - when this grating is used. - unit: NX_WAVENUMBER - wavelength_range(NX_NUMBER): - doc: Wavelength range in which this grating was used - dimensions: - rank: 1 - dim: [[1, 2]] - unit: NX_LENGTH - (NXdetector): - wavelength_range(NX_NUMBER): - doc: Wavelength range in which this detector was used - dimensions: - rank: 1 - dim: [[1, 2]] - unit: NX_LENGTH - type(NX_CHAR): - doc: Detector type - enumeration: [PMT, PbS, InGaAs] - response_time(NX_NUMBER): - doc: Response time of the detector - exists: optional - unit: NX_TIME - gain(NX_NUMBER): - doc: Detector gain - exists: optional - slit(NXslit): - doc: Slit setting used for measurement with this detector - type(NX_CHAR): - enumeration: [fixed, servo] - time_points(NX_NUMBER): - exists: optional - doc: An array of relative scan start time points. - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, N_scans]] - measured_data(NX_NUMBER): - doc: | - Resulting data from the measurement. - The length of the 2nd dimension is - the number of time points. - If it has length one the time_points - may be empty. - dimensions: - rank: 2 - dim: [[1, N_scans], [2, N_wavelengths]] - (NXsource): - doc: The lamp used for illumination - type(NX_CHAR): - doc: The type of lamp, e.g. halogen, D2 etc. - enumeration: [halogen, D2] - spectrum(NX_NUMBER): - doc: The spectrum of the lamp used - exists: optional - dimensions: - rank: 1 - dim: [[1, N_wavelengths]] - wavelength_range(NX_NUMBER): - doc: Wavelength range in which the lamp was used - dimensions: - rank: 1 - dim: [[1, 2]] - unit: NX_LENGTH - (NXsample): - # TODO: This should be extended by a generic - # NXsample class. - doc: Properties of the sample measured - name(NX_CHAR): - data(NXdata): - doc: | - A default view of the data emitted intensity vs. wavelength. - From measured_data plot intensity and wavelength. - \@axes: - doc: | - We recommend to use wavelength as a default attribute, but it can be - replaced by any suitable parameter along the X-axis. diff --git a/contributed_definitions/nyaml/NXwaveplate.yaml b/contributed_definitions/nyaml/NXwaveplate.yaml deleted file mode 100644 index aca40c9a9f..0000000000 --- a/contributed_definitions/nyaml/NXwaveplate.yaml +++ /dev/null @@ -1,132 +0,0 @@ -# A draft of a new base class to describe a waveplate - -category: base -symbols: - N_spectrum: | - Size of the wavelength array for which the refractive index of the material - and/or coating is given. - N_wavelengths: | - Number of discrete wavelengths for which the waveplate is designed. If it - operates for a range of wavelengths then N_wavelengths = 2 and the minimum - and maximum values of the range should be provided. - -doc: | - A waveplate or retarder. - -NXwaveplate: - type: - doc: | - Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). - # A waveplate can be e.g. a dual-wavelength multi-order plate - # => multiple selection needs to be possible - enumeration: - [ - "zero-order waveplate", - "achromatic waveplate", - "multiple-order waveplate", - "dual-wavelength waveplate", - "other" - ] - # Are there any other common wave plate types? - other_type: - doc: If you selected 'other' in type describe what it is. - - retardance: - doc: | - Specify the retardance of the waveplate (e.g. full-wave, half-wave - (lambda/2), quarter-wave (lambda/4) plate). - enumeration: - [ - "full-wave plate", - "half-wave plate", - "quarter-wave plate", - ] - - wavelengths(NX_NUMBER): - exists: recommended - doc: | - Discrete wavelengths for which the waveplate is designed. If the - waveplate operates over an entire range of wavelengths, enter the minimum - and maximum values of the wavelength range (in this case - N_wavelengths = 2). - dimensions: - rank: 1 - dim: - [ - [1, N_wavelengths] - ] - - diameter(NX_FLOAT): - doc: Diameter of the waveplate. - unit: NX_LENGTH - - clear_aperture(NX_FLOAT): - doc: | - Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of - length/height for square geometry). - unit: NX_UNITLESS - # Would it be better to provide the clear aperture as length? - - substrate(NXsample): - doc: | - Describe the material of the substrate of the wave plate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. - substrate_material: - doc: | - Specify the material of the wave plate. If the device has a - coating it should be described in coating/coating_material. - substrate_thickness(NX_NUMBER): - doc: Thickness of the wave plate substrate. - unit: NX_LENGTH - index_of_refration_substrate(NX_NUMBER): - doc: | - Complex index of refraction of the wave plate substrate. Specify at - given wavelength (or energy, wavenumber etc.) values. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum] - ] - - coating(NXsample): - doc: | - Is the wave plate coated? If yes, specify the type and material of the - coating and the wavelength range for which it is designed. If known, you - may also provide its index of refraction. - coating_type: - doc: | - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - coating_material: - doc: Specify the coating material. - coating_thickness(NX_NUMBER): - doc: Thickness of the coating. - unit: NX_LENGTH - wavelength_range_coating(NX_NUMBER): - exists: recommended - doc: | - Wavelength range for which the coating is designed. Enter the minimum - and maximum values of the wavelength range. - dimensions: - rank: 1 - dim: [[1,2]] - index_of_refraction_coating(NX_NUMBER): - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum] - ] - - reflectance(NX_NUMBER): - doc: Average reflectance of the waveplate in percentage. - unit: NX_UNITLESS \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXxpcs.yaml b/contributed_definitions/nyaml/NXxpcs.yaml deleted file mode 100644 index 20dd211c91..0000000000 --- a/contributed_definitions/nyaml/NXxpcs.yaml +++ /dev/null @@ -1,1085 +0,0 @@ -category: application -doc: | - X-ray Photon Correlation Spectroscopy (XPCS) data (results). - - The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data - in order to support development of community software tools. The definition presented here only - represents a starting point and contains fields that a common software tool should support for - community acceptance. - - Additional fields may be added to XPCS results file (either formally or informally). It is expected - that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or - 1D and/or 2D data. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxpcs(NXobject): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxpcs] - entry_identifier: - doc: | - **Locally** unique identifier for the experiment (a.k.a. run or scan). - - * For bluesky users, this is the run's `"scan_id"`. - * For SPEC users, this is the scan number (``SCAN_N``). - entry_identifier_uuid: - exists: ['min', '0', 'max', '1'] - doc: | - (optional) UUID identifier for this entry. - - See the `UUID standard `__ (or - `wikipedia `__) - for more information. - - * For `bluesky `__ users, this is the - run's `"uid"` and is expected for that application. - * Typically, `SPEC `__ users will - not use this field without further engineering. - scan_number(NX_INT): - deprecated: Use the ``entry_identifier`` field. - - # Use of "deprecated" is to advise the XPCS authors of this change. - # The `scan_number` field will be removed by 2022-12-31. - doc: | - Scan number (must be an integer). - - NOTE: Link to collection_identifier. - start_time(NX_DATE_TIME): - doc: | - Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". - end_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - doc: | - Ending time of experiment, such as "2021-02-11 11:23:45Z". - (NXdata)data: - doc: | - The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) - describing on-equilibrium dynamics consume more memory resources so these data are separated. - frame_sum(NX_NUMBER): - unit: NX_COUNT - exists: ['min', '0', 'max', '1'] - doc: | - Two-dimensional summation along the frames stack. - - sum of intensity v. time (in the units of "frames") - frame_average(NX_NUMBER): - unit: NX_COUNT - exists: ['min', '0', 'max', '1'] - doc: | - Two-dimensional average along the frames stack. - - average intensity v. time (in the units of "frames") - g2(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 - - .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 - - Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific - region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some - open-source XPCS libraries refer to these bins as "rois", which are not to be confused with - EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ - - In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if - the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats: - - * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value - * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value - - Note it is expected that "g2" and all quantities following it will be of the same length. - - Other formats are acceptable with sufficient axes description. - - See references below for related implementation information: - - .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` - .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata - \@storage_mode: - type: NX_CHAR - doc: | - storage_mode describes the format of the data to be loaded - - We encourage the documentation of other formats not represented here. - - * one array representing entire data set ("one_array") - * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") - enumeration: [one_array, data_exchange_keys, other] - g2_derr(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - error values for the :math:`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (:math:`\pm` error). The data should be in the same format as ``g2``. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array, data_exchange_keys, other] - G2_unnormalized(NX_NUMBER): - unit: NX_ANY - exists: ['min', '0', 'max', '1'] - doc: | - unnormalized intensity auto-correlation function. - - Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array, data_exchange_keys, other] - delay_difference(NX_INT): - unit: NX_COUNT - exists: ['min', '0', 'max', '1'] - doc: | - delay_difference (also known as delay or lag step) - - This is quantized difference so that the "step" between two consecutive - frames is one frame (or step ``= dt = 1 frame``) - - It is the "quantized" delay time corresponding to the ``g2`` values. - - The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, - refer to :ref:`NXdetector` for conversion to time units. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array, data_exchange_keys, other] - (NXdata)twotime: - exists: ['min', '0'] - doc: | - The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. - two_time_corr_func(NX_NUMBER): - unit: NX_ANY - exists: ['min', '0', 'max', '1'] - doc: | - two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) - - See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early - description applied to X-ray scattering: - - .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } - - in which time is quantized by frames. In principle, any data format is acceptable if - the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats: - - * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array - * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value - - - The computation of this result can be customized. These customizations can affect subsequently derived results (below). The - following attributes will be used to manage the customization. - - * Other normalization methods may be applied, but the method will not be specified in this - definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. - - * The various software libraries use different programming languages. Therefore, we need to - specify the ``time = 0`` origin location of the 2D array for each :math:`q`. - - * A method to reduce data storage needs is to only record half of the 2D array by populating - array elements above or below the array diagonal. - \@storage_mode: - type: NX_CHAR - doc: | - storage_mode describes the format of the data to be loaded - - We encourage the documention of other formats represented here. - enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] - \@baseline_reference: - type: NX_INT - doc: | - baseline is the expected value of a full decorrelation - - The baseline is a constant value added to the functional form of the auto-correlation - function. This value is required. - enumeration: [0, 1] - \@time_origin_location: - type: NX_CHAR - doc: | - time_origin_location is the location of the origin - enumeration: [upper_left, lower_left] - \@populated_elements: - type: NX_CHAR - doc: | - populated_elements describe the elements of the 2D array that are populated with data - enumeration: [all, upper_half, lower_half] - g2_from_two_time_corr_func(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - frame weighted average along the diagonal direction in ``two_time_corr_func`` - - The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" - - * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` - * 2D array with shape (:math:`g_2`, :math:`q`) - - Note that delay_difference is not included here because it is derived from the shape of - extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. - - The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The - following attributes will be used to manage the customization. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] - \@baseline_reference: - type: NX_INT - enumeration: [0, 1] - \@first_point_for_fit: - type: NX_INT - doc: | - first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. - - The first_point_for_fit is True ("1") or False ("0"). This value is required. - enumeration: [0, 1] - g2_err_from_two_time_corr_func(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - error values for the :math:`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (:math:`\pm` error). - \@storage_mode: - type: NX_CHAR - enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] - g2_from_two_time_corr_func_partials(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` - - Time slicing along the diagonal can be very sophisticated. This entry currently assumes - equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. - In principle, any data format is acceptable if the data and its axes are self describing as per NeXus - recommendations. However, the data is preferred in one of the following two formats: - - * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value - * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) - - Note that delay_difference is not included here because it is derived from the shape of - extracted :math:`g_2`. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array, data_exchange_keys, other] - \@baseline_reference: - type: NX_INT - enumeration: [0, 1] - g2_err_from_two_time_corr_func_partials(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - error values for the :math:`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (:math:`\pm` error). - (NXinstrument)instrument: - doc: | - XPCS instrument Metadata. - - Objects can be entered here directly or linked from other - objects in the NeXus file (such as within ``/entry/instrument``). - (NXbeam)incident_beam: - incident_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Incident beam line energy (either keV or eV). - incident_energy_spread(NX_FLOAT): - unit: NX_ENERGY - exists: ['min', '0', 'max', '1'] - doc: | - Spread of incident beam line energy (either keV or eV). This quantity is otherwise known - as the energy resolution, which is related to the longitudinal coherence length. - incident_polarization_type: - exists: ['min', '0', 'max', '1'] - doc: | - Terse description of the incident beam polarization. - - The value can be plain text, such as ``vertical``, ``C+``, - ``circular left``. - extent(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size (2-D) of the beam at this position. - - # FIXME: (h, v) or (v, h)? State this in the docs FOR EPICS AD, likeky v, h. But seems CSX is (h,v) if looking - # from the source's perspective at the face of the detector - see fig 11 and fig 12 of cxidb documentation. this - # is also relevant for the next section, which is just describing the 2D array V, H is python/bluesky - (NXdetector): - doc: | - XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes - this data is represented in different ways (sparse arrays or photon event list), but this detail - is left to the analysis software. Therefore, we only include requirements based on full array data. - - We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This - is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ - See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and - the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI - documentation (See Fig 11 vs Fig 12). - - Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to - convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may - either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. - - .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html - description: - exists: ['min', '0', 'max', '1'] - doc: | - Detector name. - distance(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Distance between sample and detector. - count_time(NX_NUMBER): - unit: NX_TIME - doc: | - Exposure time of frames, s. - frame_time(NX_NUMBER): - unit: NX_TIME - doc: | - Exposure period (time between frame starts) of frames, s - beam_center_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of beam center, x axis, in detector's coordinates. - beam_center_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of beam center, y axis, in detector's coordinates. - x_pixel_size(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - - # made this optional in case of single photon xy-time lists - doc: | - Length of pixel in x direction. - y_pixel_size(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Length of pixel in y direction. - (NXnote)masks: - exists: ['min', '0', 'max', '1'] - doc: | - Data masks or mappings to regions of interest (roi) for specific :math:`Q` values - - Fields in this ``masks`` group describe regions of interest - in the data by either a mask to select pixels or to associate - a *map* of rois with a (one-dimensional) *list* of values. - - "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, - which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. - - "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and - NXxpcs/entry/two_time. - - "Static" refers to finer binning used for computation not strictly used for the final - XPCS results. Implementation of _static_ binning is left for individual libraries to - document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or - development of new NeXus definitions for GI-SAXS or other reciprocal space - intensity mapping. - dynamic_roi_map(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - roi index array or labeled array - - The values of this mask index (or map to) the :math:`Q` value from the - the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations - are performed on all pixels with a value > 0. - - The ``units`` attribute should be set to ``"au"`` - indicating arbitrary units. - dynamic_q_list(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - 1-D list of :math:`Q` values, one for each roi index value. - - List order is determined by the index value of the associated roi map starting at ``1``. - - The only requirement for the list is that it may be iterable. Some expected formats are: - - * iterable list of floats (i.e., :math:`Q(r)`) - * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below - * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) - * iterable list of integers (for Nth roi_map value) or strings - - This format is chosen because results plotting packages are not common and simple I/O is required by end user. - The lists can be accessed as lists, arrays or via keys - dynamic_phi_list(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - Array of :math:`\varphi` value for each pixel. - - List order is determined by the index value of the associated roi map starting at ``1``. - static_roi_map(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0'] - doc: | - roi index array. - - The values of this mask index the :math:`|Q|` value from the - the ``static_q_list`` field. - - The ``units`` attribute should be set to ``"au"`` - indicating arbitrary units. - static_q_list(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - 1-D list of :math:`|Q|` values, 1 for each roi. - (NXsample)sample: - exists: ['min', '0'] - - # Describes the minimum requirements regarding equilibrium sample conditions. NXsample - # permits other quantities (e.g., applied fields, crystallographic information, name, etc) that - # may optionally be include for equilibrium conditions (which is not exclusively equilibrium - # dynamics from XPCS analysis). - # For non-equilibrium sample conditions (i.e., changing sample or process conditions - # during the XPCS measurement) will require either a new entry or an additional atttribute. - temperature_set(NX_NUMBER): - unit: NX_TEMPERATURE - exists: ['min', '0'] - doc: | - Sample temperature setpoint, (C or K). - temperature(NX_NUMBER): - unit: NX_TEMPERATURE - exists: ['min', '0'] - doc: | - Sample temperature actual, (C or K). - (NXpositioner)position_x: - exists: ['min', '0'] - (NXpositioner)position_y: - exists: ['min', '0'] - (NXpositioner)position_z: - exists: ['min', '0'] - (NXnote)NOTE: - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Any other notes. - - NAME: The NeXus convention, to use all upper case - to indicate the name (here ``NOTE``), is left to the file - writer. In our case, follow the suggested name - pattern and sequence: note_1, note_2, note_3, ... - Start with ``note_1`` if the first one, otherwise - pick the next number in this sequence. - (NXprocess): - doc: | - Describe the computation process that produced these results. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 24b656b7be7f0c85955748deed904585a8136c312327d128d6a4a377760052c8 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# X-ray Photon Correlation Spectroscopy (XPCS) data (results). -# -# The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data -# in order to support development of community software tools. The definition presented here only -# represents a starting point and contains fields that a common software tool should support for -# community acceptance. -# -# Additional fields may be added to XPCS results file (either formally or informally). It is expected -# that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or -# 1D and/or 2D data. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# **Locally** unique identifier for the experiment (a.k.a. run or scan). -# -# * For bluesky users, this is the run's `"scan_id"`. -# * For SPEC users, this is the scan number (``SCAN_N``). -# -# -# -# -# (optional) UUID identifier for this entry. -# -# See the `UUID standard <https://www.rfc-editor.org/rfc/rfc4122.html>`__ (or -# `wikipedia <https://en.wikipedia.org/wiki/Universally_unique_identifier>`__) -# for more information. -# -# * For `bluesky <https://blueskyproject.io/>`__ users, this is the -# run's `"uid"` and is expected for that application. -# * Typically, `SPEC <https://certif.com/content/spec/>`__ users will -# not use this field without further engineering. -# -# -# -# -# -# Scan number (must be an integer). -# -# NOTE: Link to collection_identifier. -# -# -# -# -# Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". -# -# -# -# -# Ending time of experiment, such as "2021-02-11 11:23:45Z". -# -# -# -# -# -# The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) -# describing on-equilibrium dynamics consume more memory resources so these data are separated. -# -# -# -# Two-dimensional summation along the frames stack. -# -# sum of intensity v. time (in the units of "frames") -# -# -# -# -# Two-dimensional average along the frames stack. -# -# average intensity v. time (in the units of "frames") -# -# -# -# -# normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 -# -# .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 -# -# Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific -# region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some -# open-source XPCS libraries refer to these bins as "rois", which are not to be confused with -# EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ -# -# In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if -# the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one -# of the following two formats: -# -# * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value -# * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value -# -# Note it is expected that "g2" and all quantities following it will be of the same length. -# -# Other formats are acceptable with sufficient axes description. -# -# See references below for related implementation information: -# -# .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` -# .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata -# -# -# -# storage_mode describes the format of the data to be loaded -# -# We encourage the documentation of other formats not represented here. -# -# * one array representing entire data set ("one_array") -# * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") -# -# -# -# -# -# -# -# -# -# -# error values for the :math:`g_2` values. -# -# The derivation of the error is left up to the implemented code. Symmetric error will be -# expected (:math:`\pm` error). The data should be in the same format as ``g2``. -# -# -# -# -# -# -# -# -# -# -# -# unnormalized intensity auto-correlation function. -# -# Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. -# -# -# -# -# -# -# -# -# -# -# -# -# delay_difference (also known as delay or lag step) -# -# This is quantized difference so that the "step" between two consecutive -# frames is one frame (or step ``= dt = 1 frame``) -# -# It is the "quantized" delay time corresponding to the ``g2`` values. -# -# The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, -# refer to :ref:`NXdetector` for conversion to time units. -# -# -# -# -# -# -# -# -# -# -# -# -# -# The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. -# -# -# -# two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) -# -# See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early -# description applied to X-ray scattering: -# -# .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } -# -# in which time is quantized by frames. In principle, any data format is acceptable if -# the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one -# of the following two formats: -# -# * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array -# * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value -# -# -# The computation of this result can be customized. These customizations can affect subsequently derived results (below). The -# following attributes will be used to manage the customization. -# -# * Other normalization methods may be applied, but the method will not be specified in this -# definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. -# -# * The various software libraries use different programming languages. Therefore, we need to -# specify the ``time = 0`` origin location of the 2D array for each :math:`q`. -# -# * A method to reduce data storage needs is to only record half of the 2D array by populating -# array elements above or below the array diagonal. -# -# -# -# -# -# storage_mode describes the format of the data to be loaded -# -# We encourage the documention of other formats represented here. -# -# -# -# -# -# -# -# -# -# -# baseline is the expected value of a full decorrelation -# -# The baseline is a constant value added to the functional form of the auto-correlation -# function. This value is required. -# -# -# -# -# -# -# -# -# time_origin_location is the location of the origin -# -# -# -# -# -# -# -# -# populated_elements describe the elements of the 2D array that are populated with data -# -# -# -# -# -# -# -# -# -# -# frame weighted average along the diagonal direction in ``two_time_corr_func`` -# -# The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" -# -# * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` -# * 2D array with shape (:math:`g_2`, :math:`q`) -# -# Note that delay_difference is not included here because it is derived from the shape of -# extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. -# -# The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The -# following attributes will be used to manage the customization. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. -# -# The first_point_for_fit is True ("1") or False ("0"). This value is required. -# -# -# -# -# -# -# -# -# -# error values for the :math:`g_2` values. -# -# The derivation of the error is left up to the implemented code. Symmetric error will be -# expected (:math:`\pm` error). -# -# -# -# -# -# -# -# -# -# -# -# -# subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` -# -# Time slicing along the diagonal can be very sophisticated. This entry currently assumes -# equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. -# In principle, any data format is acceptable if the data and its axes are self describing as per NeXus -# recommendations. However, the data is preferred in one of the following two formats: -# -# * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value -# * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) -# -# Note that delay_difference is not included here because it is derived from the shape of -# extracted :math:`g_2`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# error values for the :math:`g_2` values. -# -# The derivation of the error is left up to the implemented code. Symmetric error will be -# expected (:math:`\pm` error). -# -# -# -# -# -# -# XPCS instrument Metadata. -# -# Objects can be entered here directly or linked from other -# objects in the NeXus file (such as within ``/entry/instrument``). -# -# -# -# Incident beam line energy (either keV or eV). -# -# -# -# Spread of incident beam line energy (either keV or eV). This quantity is otherwise known -# as the energy resolution, which is related to the longitudinal coherence length. -# -# -# -# -# Terse description of the incident beam polarization. -# -# The value can be plain text, such as ``vertical``, ``C+``, -# ``circular left``. -# -# -# -# Size (2-D) of the beam at this position. -# -# -# -# -# -# -# XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes -# this data is represented in different ways (sparse arrays or photon event list), but this detail -# is left to the analysis software. Therefore, we only include requirements based on full array data. -# -# We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This -# is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ -# See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and -# the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI -# documentation (See Fig 11 vs Fig 12). -# -# Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to -# convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may -# either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. -# -# .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html -# -# -# Detector name. -# -# -# Distance between sample and detector. -# -# -# Exposure time of frames, s. -# -# -# -# Exposure period (time between frame starts) of frames, s -# -# -# -# -# Position of beam center, x axis, in detector's coordinates. -# -# -# -# -# Position of beam center, y axis, in detector's coordinates. -# -# -# -# -# -# Length of pixel in x direction. -# -# -# -# -# Length of pixel in y direction. -# -# -# -# -# -# -# Data masks or mappings to regions of interest (roi) for specific :math:`Q` values -# -# Fields in this ``masks`` group describe regions of interest -# in the data by either a mask to select pixels or to associate -# a *map* of rois with a (one-dimensional) *list* of values. -# -# "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, -# which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. -# -# "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and -# NXxpcs/entry/two_time. -# -# "Static" refers to finer binning used for computation not strictly used for the final -# XPCS results. Implementation of _static_ binning is left for individual libraries to -# document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or -# development of new NeXus definitions for GI-SAXS or other reciprocal space -# intensity mapping. -# -# -# -# roi index array or labeled array -# -# The values of this mask index (or map to) the :math:`Q` value from the -# the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations -# are performed on all pixels with a value > 0. -# -# The ``units`` attribute should be set to ``"au"`` -# indicating arbitrary units. -# -# -# -# -# 1-D list of :math:`Q` values, one for each roi index value. -# -# List order is determined by the index value of the associated roi map starting at ``1``. -# -# The only requirement for the list is that it may be iterable. Some expected formats are: -# -# * iterable list of floats (i.e., :math:`Q(r)`) -# * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below -# * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) -# * iterable list of integers (for Nth roi_map value) or strings -# -# This format is chosen because results plotting packages are not common and simple I/O is required by end user. -# The lists can be accessed as lists, arrays or via keys -# -# -# -# -# Array of :math:`\varphi` value for each pixel. -# -# List order is determined by the index value of the associated roi map starting at ``1``. -# -# -# -# -# roi index array. -# -# The values of this mask index the :math:`|Q|` value from the -# the ``static_q_list`` field. -# -# The ``units`` attribute should be set to ``"au"`` -# indicating arbitrary units. -# -# -# -# -# 1-D list of :math:`|Q|` values, 1 for each roi. -# -# -# -# -# -# -# -# -# -# Sample temperature setpoint, (C or K). -# -# -# -# -# Sample temperature actual, (C or K). -# -# -# -# -# -# -# -# -# -# Any other notes. -# -# NAME: The NeXus convention, to use all upper case -# to indicate the name (here ``NOTE``), is left to the file -# writer. In our case, follow the suggested name -# pattern and sequence: note_1, note_2, note_3, ... -# Start with ``note_1`` if the first one, otherwise -# pick the next number in this sequence. -# -# -# -# -# -# -# Describe the computation process that produced these results. -# -# -# From 8f0b40b32eb174fb20a04fa2535552ca10658a34 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 21 Jun 2023 16:24:58 +0200 Subject: [PATCH 185/203] separate documentation page for some groups of contibuted definitions --- dev_tools/docs/nxdl_index.py | 30 ++ .../contributed_definitions/apm-structure.rst | 331 ++++++++++++++++++ .../ellipsometry-structure.rst | 160 +++++++++ .../contributed_definitions/em-structure.rst | 149 ++++++++ .../mpes-structure.rst | 111 ++++++ .../transport-structure.rst | 26 ++ 6 files changed, 807 insertions(+) create mode 100644 manual/source/classes/contributed_definitions/apm-structure.rst create mode 100644 manual/source/classes/contributed_definitions/ellipsometry-structure.rst create mode 100644 manual/source/classes/contributed_definitions/em-structure.rst create mode 100644 manual/source/classes/contributed_definitions/mpes-structure.rst create mode 100644 manual/source/classes/contributed_definitions/transport-structure.rst diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 98f90b95bc..8ed3e3b429 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -45,6 +45,8 @@ def nxdl_indices() -> Dict[str, dict]: nxclass_name = nxdl_file.with_suffix("").stem classes.append(nxclass_name) summary = get_nxclass_description(nxdl_file, namespaces) + if "NXcg" in nxclass_name or "NXapm" in nxclass_name or "NXms" in nxclass_name: + continue rst_lines.append("\n") rst_lines.append(f":ref:`{nxclass_name}`\n") rst_lines.append(f"{indentation}{summary}\n") @@ -57,6 +59,19 @@ def nxdl_indices() -> Dict[str, dict]: rst_lines.append(".. toctree::\n") rst_lines.append(f"{indentation}:hidden:\n") rst_lines.append("\n") + if "index_file" in section.keys(): + file = section["index_file"] + print("----------", file) + file = os.path.abspath(file) + else: + file = "" + print("---------++++++++-", section) + if file.endswith("contributed_definitions/index.rst"): + rst_lines.append(f"{indentation}em-structure\n") + rst_lines.append(f"{indentation}ellipsometry-structure\n") + rst_lines.append(f"{indentation}mpes-structure\n") + rst_lines.append(f"{indentation}apm-structure\n") + rst_lines.append(f"{indentation}transport-structure\n") for cname in sorted(classes): rst_lines.append(f"{indentation}{cname}\n") @@ -141,5 +156,20 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: case not for general use. The :ref:`NIAC` is charged to review any new contributed definitions and provide feedback to the authors before ratification and acceptance as either a base class or application definition. + +Some contributions are groupped together: + :ref:`Optical Spectroscopy ` + + :ref:`Multi-dimensional Photoemission Spectroscopy ` + + :ref:`Atomprobe Microscopy ` + + :ref:`Electron Microscopy ` + + :ref:`Transport Measurements ` + + +and others are simply listed here: + """, } diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst new file mode 100644 index 0000000000..ef53f99989 --- /dev/null +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -0,0 +1,331 @@ +.. _Apm-Structure: + +========================= +Atom-probe tomography +========================= + +.. index:: + IntroductionApm + ApmAppDef + ApmBC + ApmRemovedBC + IntroductionApmParaprobe + WhatHasBeenAchieved + ApmParaprobeAppDef + ApmParaprobeNewBC + NextStep + + + + +.. _IntroductionApm: + +Introduction +############## + +Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. + +.. _ApmAppDef: + +Application Definitions +####################### + +We created one new application definition whose intention is to serve both the description of atom probe tomography and field-ion microscopy measurements: + + :ref:`NXapm`: + A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). + +.. _ApmBC: + +Base Classes +############ + +We developed new base classes to structure the application definition into lab experiment and computational steps: + + :ref:`NXchamber`: + A base class to describe a component of the instrument which houses other components. A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. + + :ref:`NXcoordinate_system_set` + A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. + + :ref:`NXion`: + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + + :ref:`NXfabrication`: + A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. + + :ref:`NXpeak`: + A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + + :ref:`NXpump`: + A base class to describe details about a pump in an instrument. + + :ref:`NXpulser_apm`: + A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. + + :ref:`NXreflectron`: + A base class to describe a kinetic-energy-sensitive filtering device for time of flight (ToF). + + :ref:`NXstage_lab`: + A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an + atom probe microscope or especially an electron microscope offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and one in an atom probe instrument, given that both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. + +Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually +a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. + +.. _ApmRemovedBC: + +.. Removed base classes +.. #################### + + + +.. _IntroductionApmParaprobe: + +Introduction +############## + +NORTH (the NOMAD Oasis Remote Tools Hub) is a NOMAD Oasis service which makes +preconfigured scientific software of different communities available and coupled +to Oasis and accessible via the webbrowser. This part of the proposal documents +examples for specific NeXus-related work to some of the tools and containers +available in NORTH. + + +apmtools +######## + +One tool is the paraprobe-toolbox software package in the the apmtools container. +The software is developed by `M. Kühbach et al. `_. + +Here we show how NeXus is used to consistently define application definitions +for scientific software in the field of atom probe. In this community the paraprobe-toolbox is an example of an open-source parallelized +software for analyzing point cloud data, for assessing meshes in 3D continuum +space, and analyzing the effects of parameterization on descriptors +about the microstructure of materials which were studied with atom probe microscopy. + +The need for a thorough documentation of the tools in not only the paraprobe-toolbox was motivated by several needs: + +First, users of software would like to better understand and also be able to +study themselves which individual parameter and settings for each tool exist +and how configuring these affects their analyses quantitatively. + +Second, scientific software like the tools in the paraprobe-toolbox implement a +numerical/algorithmical (computational) workflow whereby data from multiple input sources +(like previous analysis results) are processed and carried through more involved analysis +within several steps inside the tool. The tool then creates output as files. + +Individual tools are developed in C/C++ and/or Python. Here, having a possibility +for provenance tracking is useful as it is one component and requirement for +making workflows exactly numerically reproducible and thus to empower scientists +to fullfill better the "R", i.e. reproducibility of daily FAIR research practices. + +The paraprobe-toolbox is one example of a software which implements a workflow +via a sequence of operations executed within a jupyter notebook +(or Python script respectively). Specifically, individual tools are chained. +Convenience functions are available to create well-defined input/configuration +files for each tool. These config files instruct the tool upon processing. + +In this design, each workflow step (with a tool) is in fact a pair (or triple) of +at least two sub-steps: i) the creation of a configuration file, +ii) the actual analysis using the Python/or C/C++ tools, +iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 +files generated from each tool run using other software. + + +.. _WhatHasBeenAchieved: + +What has been achieved so far? +############################## + +This proposal summarizes both of the steps which we worked on between Q3/2022-Q1/2023 to change the interface and +file interaction in all tools of the paraprobe-toolbox to accept exclusively +well-defined configuration files and yield exclusively specific output. + +Data and metadata between the tools are exchanged with NeXus/HDF5 files. +Specifically, we created for each tool an application definition (see below) +which details all possible settings and options for the configuration as to +guide users. The config(uration) files are HDF5 files, whose content matches +to the naming conventions of the respective `config` application definition for each tool. +As an example NXapm_paraprobe_config_surfacer specifies how a configuration file +for the paraprobe-surfacer tool should be formatted and which parameter it contains. + +That is each config file uses a controlled vocabulary of terms. Furthermore, +the config files store a SHA256 checksum for each input file. +This implements a full provenance tracking on the input files along the +processing chain/workflow. + +As an example, a user may first range their reconstruction and then compute +correlation functions. The config file for the ranging tool stores the files +which hold the reconstructed ion position and ranging definitions. +The ranging tool generates a results file with the ion type labels stored. +This results file is formatted according to the tool-specific `results` +application definition. This results file and the reconstruction is +imported by the spatial statistics tool which again keeps track of all files. + +This design makes it possible to rigorously trace which numerical results +were achieved with a specific chain of input and +settings using specifically-versioned tools. + +We understand that this additional handling of metadata and provenance tracking +may not be at first glance super relevant for scientists or appears to be an +unnecessarily complex feature. There is indeed an additional layer of work which +came with the development and maintenance of this functionality. + +However, we are convinced that this is the preferred way of performing software +development and data analyses as it enables users to take advantage of a completely +automated provenance tracking which happens silently in the background. + +.. _ApmParaprobeAppDef: + +Application Definitions +####################### + +Firstly, we define application definitions for the input side (configuration) of each tool. + + :ref:`NXapm_paraprobe_config_transcoder`: + Configuration of paraprobe-transcoder + Load POS, ePOS, APSuite APT, RRNG, RNG, and NXapm HDF5 files. + + :ref:`NXapm_paraprobe_config_ranger`: + Configuration of paraprobe-ranger + Apply ranging definitions and explore possible molecular ions. + + :ref:`NXapm_paraprobe_config_selector`: + Configuration of paraprobe-selector + Defining complex spatial regions-of-interest to filter reconstructed datasets. + + :ref:`NXapm_paraprobe_config_surfacer`: + Configuration of paraprobe-surfacer + Create a model for the edge of a point cloud via convex hulls, alpha shapes. + + :ref:`NXapm_paraprobe_config_distancer`: + Configuration of paraprobe-distancer + Compute analytical distances between ions to a set of triangles. + + :ref:`NXapm_paraprobe_config_tessellator`: + Configuration of paraprobe-tessellator + Compute Voronoi cells for if desired all ions in a dataset. + + :ref:`NXapm_paraprobe_config_nanochem`: + Configuration of paraprobe-nanochem + Compute delocalization, iso-surfaces, analyze 3D objects, and composition profiles. + + :ref:`NXapm_paraprobe_config_intersector`: + Configuration of paraprobe-intersector + Assess intersections and proximity of 3D triangulated surface meshes in + continuum space to study the effect the parameterization of surface + extraction algorithms on the resulting shape, spatial arrangement, + and colocation of 3D objects via graph-based techniques. + + :ref:`NXapm_paraprobe_config_spatstat`: + Configuration of paraprobe-spatstat + Spatial statistics on the entire or selected regions of the reconstructed dataset. + + :ref:`NXapm_paraprobe_config_clusterer`: + Configuration of paraprobe-clusterer + Import cluster analysis results of IVAS/APSuite and perform clustering + analyses in a Python ecosystem. + +Secondly, we define application definitions for the output side (results) of each tool. + + :ref:`NXapm_paraprobe_results_transcoder`: + Results of paraprobe-transcoder + Store reconstructed positions, ions, and charge states. + + :ref:`NXapm_paraprobe_results_ranger`: + Results of paraprobe-ranger + Store applied ranging definitions and combinatorial analyses of all possible iontypes. + + :ref:`NXapm_paraprobe_results_selector`: + Results of paraprobe-selector + Store which points are inside or on the boundary of complex spatial regions-of-interest. + + :ref:`NXapm_paraprobe_results_surfacer`: + Results of paraprobe-surfacer + Store triangulated surface meshes of models for the edge of a dataset. + + :ref:`NXapm_paraprobe_results_distancer`: + Results of paraprobe-distancer + Store analytical distances between ions to a set of triangles. + + :ref:`NXapm_paraprobe_results_tessellator`: + Results of paraprobe-tessellator + Store volume of all Voronoi cells about each ion in the dataset. + + :ref:`NXapm_paraprobe_results_nanochem`: + Results of paraprobe-nanochem + Store all results of delocalization, isosurface, and interface detection algorithms, + store all extracted triangulated surface meshes of found microstructural features, + store composition profiles and corresponding geometric primitives (ROIs). + + :ref:`NXapm_paraprobe_results_intersector`: + Results of paraprobe-intersector + Store graph of microstructural features and relations/link identified between them. + + :ref:`NXapm_paraprobe_results_spatstat`: + Results of paraprobe-spatstat + Store spatial correlation functions. + + :ref:`NXapm_paraprobe_results_clusterer`: + Results of paraprobe-clusterer + Store results of cluster analyses. + +.. _ApmParaprobeNewBC: + +Base Classes +############ + +We envision that the above-mentioned definitions can be useful not only to take +inspiration for other software tools in the field of atom probe but also to support +a discussion towards a stronger standardization of the vocabulary used. +Therefore, we are happy for your comments and suggestions on this and the related +pages via the hypothesis web annotation service or as your issues posted on GitHub. + +We are convinced that the majority of data analyses in atom probe use +an in fact common set of operations and conditions on the input data +even though this might not be immediately evident. In particular this is not +the case for some community built tools with a very specific scope where oftentimes +the algorithms are hardcoded for specific material systems. A typical example is a +reseacher who implements a ranging tool and uses that all the examples are on a +specific material. We are convinced it is better to follow a much more generalized approach. + +In this spirit, we propose the following base classes and the above application +definitions as examples how very flexible constraints can be implemented which +restrict which ions in the dataset should be processed or not. We see that these +suggestions complement the proposal on computational geometry base classes: + + :ref:`NXapm_input_reconstruction`: + A description from which file the reconstructed ion positions are imported. + + :ref:`NXapm_input_ranging`: + A description from which file the ranging definitions are imported. + The design of the ranging definitions is, thanks to :ref:`NXion` so + general that all possible nuclids can be considered, be they observationally stable, + be they radioactive or transuranium nuclids. + +A detailed inspection of spatial and other type of filters used in atom probe microscopy +data analysis revealed that it is better to define atom probe agnostic, i.e. more +general filters: + + :ref:`NXspatial_filter`: + A proposal how a point cloud can be spatial filtered in a very specific, + flexible, yet general manner. This base class takes advantage of + :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, and :ref:`NXcg_hexahedron_set` + to cater for all of the most commonly used geometric primitives in + atom probe. + + :ref:`NXsubsampling_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered via sub-sampling. + + :ref:`NXmatch_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered based on their type (ion species) + or hit multiplicity. + +In summary, we report with this proposal our experience made in an experimental +project that is about using NeXus for standardizing a set of non-trivial scientific software tools. +During the implementation we learned that for handling computational geometry +and microstructure-related terms many subtilities have to be considered which +makes a controlled vocabulary valuable not only to avoid a reimplementing of the wheel. diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst new file mode 100644 index 0000000000..f0278abab8 --- /dev/null +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -0,0 +1,160 @@ +.. _Ellipsometry-Structure: + +======================== +Optical Spectroscopy +======================== + +.. index:: + Ellipsometry + DispersiveMaterial + + +.. _Ellipsometry: + +Ellipsometry +############## + +Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. The measurements are based on determining how the polarization state of light changes upon transmission and reflection. Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. + +In the application definition we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. + + +Application Definitions +----------------------- + +We created a generic application definition for every kind of Optical Spectroscopy experiments, and also a specialisation for Ellipsometry: + + :ref:`NXopt`: + A generic application definition for optial spectorscopy measurements, including complex systems up to variable angle spectroscopic ellipsometry. + + :ref:`NXellipsometry`: + A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. + + + +Base Classes Extended in Application Definitions +------------------------------------------------ + +We use existent base classes in application definitions and add descriptors: + + :ref:`NXinstrument` + Added fields to add information that is important for an ellipsometry setup, such as the ellipsometer type, the light source, the type of the sample stage, or the angle(s) of incidence, as well as information on calibration, focussing probes, data correction etc. + + :ref:`NXdetector` + Added fields to describe spectroscopic detection with polarization (e.g. rotating analyzer). + + :ref:`NXaperture` + Added fields to define parameters that describe windows (e.g. windows of a UHV cryostat), such as the thickness and the orientation angle of the window, as well as reference data to calculate window effects. + + :ref:`NXsample` + Added fields to specify the sample and material properties, as well as the sample environment (e.g. refractive index of surrounding medium) and experimental conditions (e.g. temperature, pressure, pH value etc.). + +.. _DispersiveMaterial: + + +Dispersive Material +################### + +A dispersive material is a description for the optical dispersion of materials. +This description may be used to store optical model data from an ellipsometric analysis +(or any other technique) or to build a database of optical constants for optical properties of materials. + +Application Definition +---------------------- + + :ref:`NXdispersive_material`: + An application definition to describe the dispersive properties of a material. + The material may be isotropic, uniaxial or biaxial. Hence, it may contain up + to three dispersive functions or tables. + + + +Base Classes +------------ + +There is a set of base classes for describing a dispersion. + + :ref:`NXdispersion` + This is an umbrella base class for a group of dispersion functions to describe the material. + For a simple dispersion it may contain only on NXdispersion_function or NXdispersion_table entry. + If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. + This allows for, e.g. splitting real and imaginary parts and describing them seperately or + adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). + + :ref:`NXdispersion_function` + This dispersion is described by a function and its single and repeated parameter values. + It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` + (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. + + :ref:`NXdispersion_single_parameter` + This denotes a parameter which is used outside the summed part of a dispersion function, + e.g. ``eps_inf`` in the formula example above. + + :ref:`NXdispersion_repeated_parameter` + This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. + ``A`` and ``B`` are repeated parameters in the formula above. + + :ref:`NXdispersion_table` + This describes a tabular dispersion where the dielectric function is an array versus wavelength or energy. + +Formula Grammar +--------------- + +Below you find a grammar to which the formula should adhere and which can be used to parse and +evaluate the dispersion function. The terms ``single_param_name`` and ``param_name`` should be +filled with the respective single and repeated params from the stored data. + +.. code-block:: + + ?assignment: "eps" "=" kkr_expression -> eps + | "n" "=" kkr_expression -> n + + ?kkr_expression: expression + | "" "+" "1j" "*" term -> kkr_term + + ?expression: term + | expression "+" term -> add + | expression "-" term -> sub + + ?term: factor + | term "*" factor -> mul + | term "/" factor -> div + + ?factor: power + | power "**" power -> power + + + ?power: "(" expression ")" + | FUNC "(" expression ")" -> func + | "sum" "[" repeated_expression "]" -> sum_expr + | NAME -> single_param_name + | SIGNED_NUMBER -> number + | BUILTIN -> builtin + + ?repeated_expression: repeated_term + | repeated_expression "+" repeated_term -> add + | repeated_expression "-" repeated_term -> sub + + + ?repeated_term: repeated_factor + | repeated_term "*" repeated_factor -> mul + | repeated_term "/" repeated_factor -> div + + ?repeated_factor: repeated_power + | repeated_power "**" repeated_power -> power + + ?repeated_power: "(" repeated_expression ")" + | FUNC "(" repeated_expression ")" -> func + | SIGNED_NUMBER -> number + | NAME -> param_name + | BUILTIN -> builtin + + FUNC.1: "sin" | "cos" | "tan" | "sqrt" | "dawsn" | "ln" | "log" | "heaviside" + BUILTIN.1: "1j" | "pi" | "eps_0" | "hbar" | "h" | "c" + + %import common.CNAME -> NAME + %import common.SIGNED_NUMBER + %import common.WS_INLINE + + %ignore WS_INLINE + diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst new file mode 100644 index 0000000000..7036198bd7 --- /dev/null +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -0,0 +1,149 @@ +.. _Em-Structure: + +======================= +Electron microscopy +======================= + +.. index:: + IntroductionEm + EmAppDef + EmBC + EmCommonBC + EmPartnerClasses + EmDeprecated + + + +.. _IntroductionEm: + +Introduction +############ + +Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. Realizing that we need to start somewhere, though, we focus for now on the condensed-matter physics, chemical physics of solids, and materials science applications of electron microscopy. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. Partner consortia in the German National Research Data Infrastructure are here NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. + +Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it additionally difficult to keep track of workflows and challenging to identify which specific quantities in the control software mean and represent in technical detail which physical quantity (and how these +quantities can be connected to the development of ontologies for electron microscopy experiments). + +.. _EmAppDef: + +Application Definitions +####################### + +We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet remains easy enough and useful across a variety of instruments, technology partners, and instrument use cases. Therefore, we conceptualized first the basic components of an electron microscope and the usual workflow how an electron microscope is used. That is scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments or prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. The session ends with the scientist removing +the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as session on the microscope. Next, we wrote base classes to describe these steps and events. + + :ref:`NXem`: + A general application definition which explores the possibilities of electron microscopes. + +.. _EmBC: + +Base Classes +############ + +We developed entirely new base classes. Some of them are also used for other techniques of this proposal but mentioned here for the sake of completeness: + + + :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: + Base classes to describe procedures and values for the calibration of aberrations based on either CEOS or Nion. + + :ref:`NXaperture_em`: + A base class to describe an aperture. + + :ref:`NXchamber`: + A base class to describe the chamber as a part of the microscope or storage unit for transferring specimens in-between or within an instrument. + + :ref:`NXcoordinate_system_set`: + A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. + + :ref:`NXcorrector_cs`: + A base class to describe details about corrective lens or compound lens devices which reduce the aberration of an electron beam. + + :ref:`NXebeam_column`: + A base class serving the possibility to group the components relevant for generating and shaping the electron beam in an electron microscope. + + :ref:`NXevent_data_em`: + A base class representing a container to hold time-stamped and microscope-state-annotated data during a session at an electron microscope. + + :ref:`NXevent_data_em_set`: + A base class to group all :ref:`NXevent_data_em` instances. + + :ref:`NXibeam_column`: + A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused ion beam (milling) capabilities. + + :ref:`NXimage_set`: + Base classes for storing acquisition details for individual images or stacks of images. Specialized versions can be defined and use controlled vocabulary terms for group name prefixes like **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction, **ronchigram** - convergent beam diffraction pattern, or **se** secondary electron. + + :ref:`NXinteraction_vol_em`: + A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. + + :ref:`NXion`: + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + + :ref:`NXlens_em`: + A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. + + :ref:`NXfabrication`: + A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. + + :ref:`NXoptical_system_em`: + A base class to store for now qualitative and quantitative values of frequent interest which are affected by the interplay of the components and state of an electron microscope. + Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. + + :ref:`NXpeak`: + A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + + :ref:`NXpump`: + A base class to describe details about a pump in an instrument. + + :ref:`NXscanbox_em`: + A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. + + :ref:`NXspectrum_set`: + Base class and specializations comparable to NXimage_set but for storing spectra. Specialized base classes should use controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. + + :ref:`NXstage_lab`: + As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. + + +.. _EmCommonBC: + +Common Base Classes +################### + +We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em` and :ref:`NXxraylens` have similarities. +It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general +base class lenses. We understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. + +The first result of such consolidations is the NXem_ebsd partner application definition. + +.. _EmPartnerClasses: + +Partner application definitions +############################### + +A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize these pieces of information in an own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that the pattern are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. in post-processing of these data. These numerical and algorithmic steps define computational workflows were data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints trigger the need for having an own but almost similar application definition. For this reason we use the concept of partner application definition which have fields/links where specifically relevant sources of information are connected to e.g. NXem. + +The first partner application definition is NXem_ebsd. + + :ref:`NXem_ebsd`: + Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- and four-dimensional case. + +Several new base classes are used by this application definition. + + :ref:`NXem_ebsd_conventions`: + A collection of reference frames and rotation conventions necessary to interpret the alignment and orientation data. + + :ref:`NXem_ebsd_crystal_structure_model`: + A description of a crystalline phase/structure used for a forward simulation using kinetic or dynamic diffraction theory to generate simulated diffraction pattern against which measured pattern can be indexed. + + +.. _EmDeprecated: + +Deprecated +########## + +In April/May 2023, we refactored the design of the NXimage_set and NXspectrum set base classes. Therefore, the following base classes should not longer be used: +NXimage_set_em_bf, NXimage_set_em_bse, NXimage_set_em_chamber, NXimage_set_em_df, NXimage_set_em_diffrac, NXimage_set_em_ecci, NXimage_set_em_kikuchi, NXimage_set_em_ronchigram, NXimage_set_em_se, NXimage_set_em, NXspectrum_set_em_eels, NXspectrum_set_em_xray, NXspectrum_set_em_auger, NXspectrum_set_em_cathodolum. + +With the NeXus 2022.06 Code Camp, we refactored the NXem application definition. Therefore, the following base classes and application definitions should no longer be used: +NXem_nion (replaced by :ref:`NXem`), NXfib (replaced by :ref:`NXibeam_column`). diff --git a/manual/source/classes/contributed_definitions/mpes-structure.rst b/manual/source/classes/contributed_definitions/mpes-structure.rst new file mode 100644 index 0000000000..a150b87de7 --- /dev/null +++ b/manual/source/classes/contributed_definitions/mpes-structure.rst @@ -0,0 +1,111 @@ +.. _Mpes-Structure: + +============================================== +Photoemission & core-level spectroscopy +============================================== + +.. index:: + IntroductionMpes + MpesAppDef + MpesBC + MpesCommonBC + MpesExtendedBC + + +.. _IntroductionMpes: + +Introduction +############ + +Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), +hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) +and photoemission electron microscopy (PEEM). We also included descriptors for advanced specializations, such as spin-resolution, time resolution, +near-ambient pressure conditions, dichroism etc. + +.. _MpesAppDef: + +Application Definitions +####################### + +We created two new application definitions: + + :ref:`NXmpes`: + A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. + +.. _MpesBC: + +Base Classes +############ + +We developed entirely new base classes: + + :ref:`NXelectronanalyser`: + A base class to describe electron kinetic energy analizers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following subclasses: + + :ref:`NXcollectioncolumn`: + Base class to describe the set of electronic lenses in the electron collection column (standard, PEEM, momentum-microscope, etc.). + + :ref:`NXenergydispersion`: + Base class to describe the energy dispersion sytem (hemispherical, time-of-flight, etc.). + + :ref:`NXspindispersion`: + Base class to describe the set of electronic lenses in the electron collection column. + + :ref:`NXmanipulator`: + A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, + cryogenic cooling and other advanced features. + +We developed three base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: + + :ref:`NXcalibration`: + A base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. + + :ref:`NXdistortion`: + A base class to describe the 2D distortion correction of an axis, with a matrix mapping a raw data image to a undistorted image. + + :ref:`NXregistration`: + A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. + +.. _MpesCommonBC: + +Common Base Classes +################### + +We developed two classes that are common to other techniques: + + :ref:`NXlens_em`: + A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. + + :ref:`NXdeflector` + A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. + +.. _MpesExtendedBC: + +Base Classes Extended in Application Definitions +################################################ + +We use existent base classes in application definitions and add descriptors: + + :ref:`NXaperture` + Added fileds to describe analyser apertures and slits. + + :ref:`NXbeam` + Adedd fields to describe utrafast laser beams. + + :ref:`NXdetector` + Added fields to describe electron detectors (MCP+Phospor screen, delay lines etc.). + + :ref:`NXentry` + Added fields to describe an experiment. + + :ref:`NXprocess` + Added subclasses and collective processing descriptors. + + :ref:`NXsample` + Added descriptors specific to photoemission experiments. + + :ref:`NXsource` + Added descriptors for laboratory sources (X-ray, UV lamps) but mostly for ultrafast lasers with complex time structures. + + :ref:`NXinstrument` + Added descriptors for the overall resolutions of the experiment (energy, momentum, angular, spatial, temporal). diff --git a/manual/source/classes/contributed_definitions/transport-structure.rst b/manual/source/classes/contributed_definitions/transport-structure.rst new file mode 100644 index 0000000000..8238b52196 --- /dev/null +++ b/manual/source/classes/contributed_definitions/transport-structure.rst @@ -0,0 +1,26 @@ +.. _Transport-Structure: + +=================== +Transport Phenomena +=================== + +.. index:: + IntroductionTransport + TransportAppDef + + +.. _IntroductionTransport: + +Introduction +############## + + +.. _TransportAppDef: + +Application Definitions +####################### + +Work on handshaking between EPICS-controlled experiments and NeXus resulted in one application definition for temperature dependent IV curve measurements. + + :ref:`NXiv_temp`: + Application definition for temperature dependent IV curve measurements. From 237eb59e59e246e3b0929397d1358ca6433ec803 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 22 Jun 2023 08:52:15 +0200 Subject: [PATCH 186/203] Initial fix to MPES structure on html page --- .../contributed_definitions/mpes-structure.rst | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/manual/source/classes/contributed_definitions/mpes-structure.rst b/manual/source/classes/contributed_definitions/mpes-structure.rst index a150b87de7..d7353a4fc5 100644 --- a/manual/source/classes/contributed_definitions/mpes-structure.rst +++ b/manual/source/classes/contributed_definitions/mpes-structure.rst @@ -19,7 +19,7 @@ Introduction Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) -and photoemission electron microscopy (PEEM). We also included descriptors for advanced specializations, such as spin-resolution, time resolution, +and photoemission electron microscopy (PEEM). Also includes descriptors for advanced specializations, such as spin-resolution, time resolution, near-ambient pressure conditions, dichroism etc. .. _MpesAppDef: @@ -27,18 +27,15 @@ near-ambient pressure conditions, dichroism etc. Application Definitions ####################### -We created two new application definitions: - - :ref:`NXmpes`: - A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. +:ref:`NXmpes`: + A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. .. _MpesBC: Base Classes ############ -We developed entirely new base classes: - +New base classes: :ref:`NXelectronanalyser`: A base class to describe electron kinetic energy analizers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following subclasses: @@ -55,7 +52,7 @@ We developed entirely new base classes: A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, cryogenic cooling and other advanced features. -We developed three base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: +Three base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: :ref:`NXcalibration`: A base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. @@ -71,7 +68,7 @@ We developed three base classes to describe data processing, which can be used a Common Base Classes ################### -We developed two classes that are common to other techniques: +There are two related base classes that are common to other techniques: :ref:`NXlens_em`: A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. @@ -84,7 +81,7 @@ We developed two classes that are common to other techniques: Base Classes Extended in Application Definitions ################################################ -We use existent base classes in application definitions and add descriptors: +The following existent base classes are used in application definitions (with added descriptors): :ref:`NXaperture` Added fileds to describe analyser apertures and slits. From 70f8d36c555a0a649bab8fe160851e3ee2f21a97 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 22 Jun 2023 08:59:48 +0200 Subject: [PATCH 187/203] Remove reference to already standardised definitions --- .../mpes-structure.rst | 56 ++++--------------- 1 file changed, 12 insertions(+), 44 deletions(-) diff --git a/manual/source/classes/contributed_definitions/mpes-structure.rst b/manual/source/classes/contributed_definitions/mpes-structure.rst index d7353a4fc5..1d37fdba67 100644 --- a/manual/source/classes/contributed_definitions/mpes-structure.rst +++ b/manual/source/classes/contributed_definitions/mpes-structure.rst @@ -35,22 +35,21 @@ Application Definitions Base Classes ############ -New base classes: - :ref:`NXelectronanalyser`: - A base class to describe electron kinetic energy analizers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following subclasses: +:ref:`NXelectronanalyser`: + A base class to describe electron kinetic energy analizers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following subclasses: - :ref:`NXcollectioncolumn`: - Base class to describe the set of electronic lenses in the electron collection column (standard, PEEM, momentum-microscope, etc.). + :ref:`NXcollectioncolumn`: + Base class to describe the set of electronic lenses in the electron collection column (standard, PEEM, momentum-microscope, etc.). - :ref:`NXenergydispersion`: - Base class to describe the energy dispersion sytem (hemispherical, time-of-flight, etc.). + :ref:`NXenergydispersion`: + Base class to describe the energy dispersion sytem (hemispherical, time-of-flight, etc.). - :ref:`NXspindispersion`: - Base class to describe the set of electronic lenses in the electron collection column. + :ref:`NXspindispersion`: + Base class to describe the set of electronic lenses in the electron collection column. - :ref:`NXmanipulator`: - A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, - cryogenic cooling and other advanced features. +:ref:`NXmanipulator`: + A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, + cryogenic cooling and other advanced features. Three base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: @@ -74,35 +73,4 @@ There are two related base classes that are common to other techniques: A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. :ref:`NXdeflector` - A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. - -.. _MpesExtendedBC: - -Base Classes Extended in Application Definitions -################################################ - -The following existent base classes are used in application definitions (with added descriptors): - - :ref:`NXaperture` - Added fileds to describe analyser apertures and slits. - - :ref:`NXbeam` - Adedd fields to describe utrafast laser beams. - - :ref:`NXdetector` - Added fields to describe electron detectors (MCP+Phospor screen, delay lines etc.). - - :ref:`NXentry` - Added fields to describe an experiment. - - :ref:`NXprocess` - Added subclasses and collective processing descriptors. - - :ref:`NXsample` - Added descriptors specific to photoemission experiments. - - :ref:`NXsource` - Added descriptors for laboratory sources (X-ray, UV lamps) but mostly for ultrafast lasers with complex time structures. - - :ref:`NXinstrument` - Added descriptors for the overall resolutions of the experiment (energy, momentum, angular, spatial, temporal). + A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. \ No newline at end of file From 8944cac08580e2663633a1ed3c43602c189dd0dd Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 22 Jun 2023 09:42:09 +0200 Subject: [PATCH 188/203] Updates manual page --- .../ellipsometry-structure.rst | 28 +++---------------- 1 file changed, 4 insertions(+), 24 deletions(-) diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index f0278abab8..7d42c33587 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -14,7 +14,9 @@ Optical Spectroscopy Ellipsometry ############## -Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. The measurements are based on determining how the polarization state of light changes upon transmission and reflection. Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. +Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. +The measurements are based on determining how the polarization state of light changes upon transmission and reflection. +Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. In the application definition we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. @@ -22,34 +24,12 @@ In the application definition we provide a minimum set of description elements a Application Definitions ----------------------- -We created a generic application definition for every kind of Optical Spectroscopy experiments, and also a specialisation for Ellipsometry: - :ref:`NXopt`: A generic application definition for optial spectorscopy measurements, including complex systems up to variable angle spectroscopic ellipsometry. :ref:`NXellipsometry`: - A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. - - - -Base Classes Extended in Application Definitions ------------------------------------------------- - -We use existent base classes in application definitions and add descriptors: - - :ref:`NXinstrument` - Added fields to add information that is important for an ellipsometry setup, such as the ellipsometer type, the light source, the type of the sample stage, or the angle(s) of incidence, as well as information on calibration, focussing probes, data correction etc. - - :ref:`NXdetector` - Added fields to describe spectroscopic detection with polarization (e.g. rotating analyzer). - - :ref:`NXaperture` - Added fields to define parameters that describe windows (e.g. windows of a UHV cryostat), such as the thickness and the orientation angle of the window, as well as reference data to calculate window effects. - - :ref:`NXsample` - Added fields to specify the sample and material properties, as well as the sample environment (e.g. refractive index of surrounding medium) and experimental conditions (e.g. temperature, pressure, pH value etc.). + An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. -.. _DispersiveMaterial: Dispersive Material From 2a5f8febde051ac024c2e992d0c65f11e81735df Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 22 Jun 2023 11:48:07 +0200 Subject: [PATCH 189/203] Editing of the sub-directory/technique-specific guiding documents for apm and em --- .../contributed_definitions/apm-structure.rst | 171 +++++++++--------- .../contributed_definitions/em-structure.rst | 75 +++----- 2 files changed, 113 insertions(+), 133 deletions(-) diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index ef53f99989..10e2c77c36 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -8,8 +8,6 @@ Atom-probe tomography IntroductionApm ApmAppDef ApmBC - ApmRemovedBC - IntroductionApmParaprobe WhatHasBeenAchieved ApmParaprobeAppDef ApmParaprobeNewBC @@ -27,87 +25,91 @@ Set of data storage objects to describe the acquisition/measurement side, the re .. _ApmAppDef: -Application Definitions -####################### +Application Definition +###################### -We created one new application definition whose intention is to serve both the description of atom probe tomography and field-ion microscopy measurements: +It is proposed to use one application definition to serve atom probe tomography +and field-ion microscopy measurements, i.e. the data collection with the instrument: :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). + A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. .. _ApmBC: Base Classes ############ -We developed new base classes to structure the application definition into lab experiment and computational steps: +The following base classes are proposed to support modularizing the storage of pieces of information: :ref:`NXchamber`: - A base class to describe a component of the instrument which houses other components. A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. + A base class to describe a component of the instrument which houses other components. + A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. :ref:`NXcoordinate_system_set` - A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. + A base class to describe different coordinate systems used and/or to be harmonized + or transformed into one another when interpreting the dataset. :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion + is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with + which all possible isotopes can be described. :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. + A base class to bundle manufacturer/technology-partner-specific details about a + component or device of an instrument. :ref:`NXpeak`: - A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + A base class to describe peaks mathematically to detail how peaks in + mass-to-charge-state ratio histograms (aka mass spectra) are + defined and labelled as iontypes. :ref:`NXpump`: - A base class to describe details about a pump in an instrument. + A base class to describe details about pump(s) of an instrument. :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. + A base class to describe the high-voltage and/or laser pulsing capabilities of + an atom probe microscope. :ref:`NXreflectron`: - A base class to describe a kinetic-energy-sensitive filtering device for time of flight (ToF). + A base class to describe a kinetic-energy-sensitive filtering device + for time of flight (ToF) mass spectrometry. :ref:`NXstage_lab`: - A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an - atom probe microscope or especially an electron microscope offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and one in an atom probe instrument, given that both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. - -Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually -a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. + A base class to describe the specimen fixture including the cryo-head. + Nowadays, these stages represent small-scale laboratory platforms. + Therefore, there is a need to define the characteristics of such stages in more detail, + especially in light of in-situ experiments. Many similarities exists between a stage + in an electron microscope and one in an atom probe instrument. Both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. -.. _ApmRemovedBC: - -.. Removed base classes -.. #################### +Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually to apply a set of data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. +Like every research community data processing steps are essential to transform measurements +into knowledge. These processing steps should be documented to enable reproducible research +and learn how pieces of information were connected. In what follows, an example is presented +how an open-source community software can be modified to use descriptions of these computational +steps. The respective research software here is the `paraprobe-toolbox `_ .. _IntroductionApmParaprobe: -Introduction -############## - -NORTH (the NOMAD Oasis Remote Tools Hub) is a NOMAD Oasis service which makes -preconfigured scientific software of different communities available and coupled -to Oasis and accessible via the webbrowser. This part of the proposal documents -examples for specific NeXus-related work to some of the tools and containers -available in NORTH. - - apmtools ######## One tool is the paraprobe-toolbox software package in the the apmtools container. The software is developed by `M. Kühbach et al. `_. -Here we show how NeXus is used to consistently define application definitions -for scientific software in the field of atom probe. In this community the paraprobe-toolbox is an example of an open-source parallelized -software for analyzing point cloud data, for assessing meshes in 3D continuum -space, and analyzing the effects of parameterization on descriptors -about the microstructure of materials which were studied with atom probe microscopy. +Here we show how NeXus is used to consistently define application definitions for scientific software +in the field of atom probe. In this community the paraprobe-toolbox is an example of an +open-source parallelized software for analyzing point cloud data, for assessing meshes in +3D continuum space, and for studying the effects of parameterization on descriptors +which describe the micro- and nanostructure of materials that are studied with +atom probe microscopy. -The need for a thorough documentation of the tools in not only the paraprobe-toolbox was motivated by several needs: +The need for a thorough documentation of the tools in not only the paraprobe-toolbox +was motivated by several needs: First, users of software would like to better understand and also be able to -study themselves which individual parameter and settings for each tool exist +study for themselves which individual parameters and settings for each tool exist and how configuring these affects their analyses quantitatively. Second, scientific software like the tools in the paraprobe-toolbox implement a @@ -115,10 +117,10 @@ numerical/algorithmical (computational) workflow whereby data from multiple inpu (like previous analysis results) are processed and carried through more involved analysis within several steps inside the tool. The tool then creates output as files. -Individual tools are developed in C/C++ and/or Python. Here, having a possibility -for provenance tracking is useful as it is one component and requirement for -making workflows exactly numerically reproducible and thus to empower scientists -to fullfill better the "R", i.e. reproducibility of daily FAIR research practices. +Individual tools of paraprobe-toolbox are developed in C/C++ and/or Python. +Provenance tracking is useful as it is one component and requirement for making +workflows exactly numerically reproducible and thereby empower scientists +to fulfill better the "R", i.e. reproducibility of their daily FAIR research practices. The paraprobe-toolbox is one example of a software which implements a workflow via a sequence of operations executed within a jupyter notebook @@ -138,17 +140,20 @@ files generated from each tool run using other software. What has been achieved so far? ############################## -This proposal summarizes both of the steps which we worked on between Q3/2022-Q1/2023 to change the interface and -file interaction in all tools of the paraprobe-toolbox to accept exclusively -well-defined configuration files and yield exclusively specific output. +This proposal summarizes work of members of the FAIRmat project, which is part +of the German National Research Data Infrastructure aimed at a change of the paraprobe-toolbox +and its interaction with files for all tools so that only well-defined configuration files +are accepted as input and results end up as specifically formatted output. For this +NeXus application definitions are used. Data and metadata between the tools are exchanged with NeXus/HDF5 files. Specifically, we created for each tool an application definition (see below) which details all possible settings and options for the configuration as to -guide users. The config(uration) files are HDF5 files, whose content matches -to the naming conventions of the respective `config` application definition for each tool. -As an example NXapm_paraprobe_config_surfacer specifies how a configuration file -for the paraprobe-surfacer tool should be formatted and which parameter it contains. +guide users. The config(uration) files are currently implemented as HDF5 files, +whose content matches to the naming conventions of the respective `config` application +definition for each tool. As an example NXapm_paraprobe_config_surfacer specifies +how a configuration file for the paraprobe-surfacer tool should be formatted +and which parameter it should and/or may contain. That is each config file uses a controlled vocabulary of terms. Furthermore, the config files store a SHA256 checksum for each input file. @@ -164,8 +169,7 @@ application definition. This results file and the reconstruction is imported by the spatial statistics tool which again keeps track of all files. This design makes it possible to rigorously trace which numerical results -were achieved with a specific chain of input and -settings using specifically-versioned tools. +were achieved with a specific input and settings using specifically-versioned tools. We understand that this additional handling of metadata and provenance tracking may not be at first glance super relevant for scientists or appears to be an @@ -181,7 +185,7 @@ automated provenance tracking which happens silently in the background. Application Definitions ####################### -Firstly, we define application definitions for the input side (configuration) of each tool. +Application definitions for the input side (configuration) of each tool were defined. :ref:`NXapm_paraprobe_config_transcoder`: Configuration of paraprobe-transcoder @@ -227,7 +231,7 @@ Firstly, we define application definitions for the input side (configuration) of Import cluster analysis results of IVAS/APSuite and perform clustering analyses in a Python ecosystem. -Secondly, we define application definitions for the output side (results) of each tool. +Application definitions for the output side (results) of each tool were defined. :ref:`NXapm_paraprobe_results_transcoder`: Results of paraprobe-transcoder @@ -279,41 +283,38 @@ Base Classes We envision that the above-mentioned definitions can be useful not only to take inspiration for other software tools in the field of atom probe but also to support a discussion towards a stronger standardization of the vocabulary used. -Therefore, we are happy for your comments and suggestions on this and the related -pages via the hypothesis web annotation service or as your issues posted on GitHub. - -We are convinced that the majority of data analyses in atom probe use -an in fact common set of operations and conditions on the input data -even though this might not be immediately evident. In particular this is not -the case for some community built tools with a very specific scope where oftentimes -the algorithms are hardcoded for specific material systems. A typical example is a -reseacher who implements a ranging tool and uses that all the examples are on a -specific material. We are convinced it is better to follow a much more generalized approach. - -In this spirit, we propose the following base classes and the above application -definitions as examples how very flexible constraints can be implemented which -restrict which ions in the dataset should be processed or not. We see that these -suggestions complement the proposal on computational geometry base classes: +Therefore, we are happy for comments and suggestions. + +The majority of data analyses in atom probe use a common set of operations and +conditions on the input data even though this might not be immediately evident +or might not have been so explicitly communicated in the literature. +Some tools have a specific scope because of which algorithms are hardcoded +to work for specific material systems. A typical example is a ranging tool +which exploits that all the examples it is used for apply to a specific material +and thus specific iontypes can be hardcoded. + +Instead, we are convinced it is better to follow a more generalized approach. +The following base classes and the above application definitions present examples +how one can use NeXus for this. :ref:`NXapm_input_reconstruction`: A description from which file the reconstructed ion positions are imported. :ref:`NXapm_input_ranging`: A description from which file the ranging definitions are imported. - The design of the ranging definitions is, thanks to :ref:`NXion` so - general that all possible nuclids can be considered, be they observationally stable, - be they radioactive or transuranium nuclids. + The design of the ranging definitions is, thanks to :ref:`NXion`, so + general that all possible nuclids can be considered, be they observationally + stable, be they radioactive or transuranium nuclids. -A detailed inspection of spatial and other type of filters used in atom probe microscopy -data analysis revealed that it is better to define atom probe agnostic, i.e. more -general filters: +A detailed inspection of spatial and other type of filters frequently used in +analysis of atom probe data revealed that it is better to define atom-probe-agnostic, +i.e. more general filters: :ref:`NXspatial_filter`: - A proposal how a point cloud can be spatial filtered in a very specific, - flexible, yet general manner. This base class takes advantage of - :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, and :ref:`NXcg_hexahedron_set` - to cater for all of the most commonly used geometric primitives in - atom probe. + A proposal how a point cloud can be spatially filtered in a specific yet general manner. + This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, + and :ref:`NXcg_hexahedron_set` to cater for all of the most commonly used + geometric primitives in atom probe. :ref:`NXsubsampling_filter`: A proposal for a filter that can also be used for specifying how entries @@ -323,9 +324,3 @@ general filters: A proposal for a filter that can also be used for specifying how entries like ions can be filtered based on their type (ion species) or hit multiplicity. - -In summary, we report with this proposal our experience made in an experimental -project that is about using NeXus for standardizing a set of non-trivial scientific software tools. -During the implementation we learned that for handling computational geometry -and microstructure-related terms many subtilities have to be considered which -makes a controlled vocabulary valuable not only to avoid a reimplementing of the wheel. diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 7036198bd7..f3acf66ef2 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -8,10 +8,7 @@ Electron microscopy IntroductionEm EmAppDef EmBC - EmCommonBC EmPartnerClasses - EmDeprecated - .. _IntroductionEm: @@ -19,18 +16,23 @@ Electron microscopy Introduction ############ -Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. Realizing that we need to start somewhere, though, we focus for now on the condensed-matter physics, chemical physics of solids, and materials science applications of electron microscopy. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. Partner consortia in the German National Research Data Infrastructure are here NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. +Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. In what follows the focus is on the usage of electron microscopy in condensed-matter physics, chemical physics of solids, and materials engineering applications. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. +Partner consortia in the German National Research Data Infrastructure are here e.g. +NFDI-BioImage, NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. -Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it additionally difficult to keep track of workflows and challenging to identify which specific quantities in the control software mean and represent in technical detail which physical quantity (and how these -quantities can be connected to the development of ontologies for electron microscopy experiments). +Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods are increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it difficult to keep track of workflows in a technology-partner-agnostic, +i.e. interdisciplinary manner. .. _EmAppDef: Application Definitions ####################### -We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet remains easy enough and useful across a variety of instruments, technology partners, and instrument use cases. Therefore, we conceptualized first the basic components of an electron microscope and the usual workflow how an electron microscope is used. That is scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments or prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. The session ends with the scientist removing -the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as session on the microscope. Next, we wrote base classes to describe these steps and events. +We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet not unnecessary complex and useful for application across a variety of instruments, technology partners, and instrument use cases. In what follows, the proposal conceptualizes first the basic components of an electron microscope and the usual workflow how an electron microscope is used for collecting data with detectors via probing radiation-specimen-matter interaction mechanisms. + +In summary, scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments, prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all of these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. + +A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as session on the microscope. Next, we wrote base classes to describe these steps and events. :ref:`NXem`: A general application definition which explores the possibilities of electron microscopes. @@ -40,8 +42,7 @@ the specimen from the instrument or parking it so that the next user can start a Base Classes ############ -We developed entirely new base classes. Some of them are also used for other techniques of this proposal but mentioned here for the sake of completeness: - +The following base classes are proposed to support modularizing the storage of pieces of information: :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: Base classes to describe procedures and values for the calibration of aberrations based on either CEOS or Nion. @@ -50,31 +51,37 @@ We developed entirely new base classes. Some of them are also used for other tec A base class to describe an aperture. :ref:`NXchamber`: - A base class to describe the chamber as a part of the microscope or storage unit for transferring specimens in-between or within an instrument. + A base class to describe the chamber as a part of the microscope or storage unit + for transferring specimens in between or within an instrument. :ref:`NXcoordinate_system_set`: - A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. + A base class to describe different coordinate systems used and/or to be harmonized + or transformed into one another when interpreting the dataset. :ref:`NXcorrector_cs`: - A base class to describe details about corrective lens or compound lens devices which reduce the aberration of an electron beam. + A base class to describe details about corrective lens or compound lens devices + which reduce the aberration of an electron beam. :ref:`NXebeam_column`: - A base class serving the possibility to group the components relevant for generating and shaping the electron beam in an electron microscope. + A base class serving the possibility to group the components relevant for generating + and shaping the electron beam. :ref:`NXevent_data_em`: - A base class representing a container to hold time-stamped and microscope-state-annotated data during a session at an electron microscope. + A base class representing a container to hold time-stamped and microscope-state- + annotated data during a session at an electron microscope. :ref:`NXevent_data_em_set`: A base class to group all :ref:`NXevent_data_em` instances. :ref:`NXibeam_column`: - A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused ion beam (milling) capabilities. + A base class serving the possibility to group the components relevant for generating + and shaping an ion beam of an instrument to offer focused-ion beam (milling) capabilities. :ref:`NXimage_set`: Base classes for storing acquisition details for individual images or stacks of images. Specialized versions can be defined and use controlled vocabulary terms for group name prefixes like **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction, **ronchigram** - convergent beam diffraction pattern, or **se** secondary electron. :ref:`NXinteraction_vol_em`: - A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. + A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen. :ref:`NXion`: A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. @@ -83,10 +90,12 @@ We developed entirely new base classes. Some of them are also used for other tec A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. + A base class to bundle manufacturer/technology-partner-specific details about + a component or device of an instrument. :ref:`NXoptical_system_em`: - A base class to store for now qualitative and quantitative values of frequent interest which are affected by the interplay of the components and state of an electron microscope. + A base class to store for now qualitative and quantitative values of frequent interest + which are affected by the interplay of the components and state of an electron microscope. Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. :ref:`NXpeak`: @@ -105,25 +114,13 @@ We developed entirely new base classes. Some of them are also used for other tec As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. -.. _EmCommonBC: - -Common Base Classes -################### - -We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em` and :ref:`NXxraylens` have similarities. -It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general -base class lenses. We understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. - -The first result of such consolidations is the NXem_ebsd partner application definition. - .. _EmPartnerClasses: Partner application definitions ############################### -A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize these pieces of information in an own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that the pattern are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. in post-processing of these data. These numerical and algorithmic steps define computational workflows were data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints trigger the need for having an own but almost similar application definition. For this reason we use the concept of partner application definition which have fields/links where specifically relevant sources of information are connected to e.g. NXem. - -The first partner application definition is NXem_ebsd. +A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize these pieces of information in an own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that (diffraction) patterns are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. through post-processing these data. These numerical and algorithmic steps define computational workflows were data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. For this reason, the concept of partner application definition which have fields/links where specifically relevant sources of information are connected to e.g. NXem. +More consolidation through the use of NXsubentry classes should be considered in the future. :ref:`NXem_ebsd`: Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- and four-dimensional case. @@ -135,15 +132,3 @@ Several new base classes are used by this application definition. :ref:`NXem_ebsd_crystal_structure_model`: A description of a crystalline phase/structure used for a forward simulation using kinetic or dynamic diffraction theory to generate simulated diffraction pattern against which measured pattern can be indexed. - - -.. _EmDeprecated: - -Deprecated -########## - -In April/May 2023, we refactored the design of the NXimage_set and NXspectrum set base classes. Therefore, the following base classes should not longer be used: -NXimage_set_em_bf, NXimage_set_em_bse, NXimage_set_em_chamber, NXimage_set_em_df, NXimage_set_em_diffrac, NXimage_set_em_ecci, NXimage_set_em_kikuchi, NXimage_set_em_ronchigram, NXimage_set_em_se, NXimage_set_em, NXspectrum_set_em_eels, NXspectrum_set_em_xray, NXspectrum_set_em_auger, NXspectrum_set_em_cathodolum. - -With the NeXus 2022.06 Code Camp, we refactored the NXem application definition. Therefore, the following base classes and application definitions should no longer be used: -NXem_nion (replaced by :ref:`NXem`), NXfib (replaced by :ref:`NXibeam_column`). From f3bc402d6c62b94fc6104ab5e8ac1d3da5ef3aa5 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 22 Jun 2023 12:20:48 +0200 Subject: [PATCH 190/203] Added guide to base classes and application definitions for computational-geometry-based microstructures --- dev_tools/docs/nxdl_index.py | 2 + .../cgms-structure.rst | 286 ++++++++++++++++++ 2 files changed, 288 insertions(+) create mode 100644 manual/source/classes/contributed_definitions/cgms-structure.rst diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 8ed3e3b429..10cd1d67ec 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -72,6 +72,8 @@ def nxdl_indices() -> Dict[str, dict]: rst_lines.append(f"{indentation}mpes-structure\n") rst_lines.append(f"{indentation}apm-structure\n") rst_lines.append(f"{indentation}transport-structure\n") + rst_lines.append(f"{indentation}cgms-structure\n") + for cname in sorted(classes): rst_lines.append(f"{indentation}{cname}\n") diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst new file mode 100644 index 0000000000..7bc1621393 --- /dev/null +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -0,0 +1,286 @@ +.. _CgmsFeatures-Structure: + +========================= +Geometry & Microstructure +========================= + +.. index:: + IntroductionCgms + PhysicsCgms + CgmsAppDef + CgmsBC + IcmeMsModels + + +.. _IntroductionCgms: + +Introduction +############ + +The computational-geometry/microstructure-modeling-based part of the proposal +has the following aims: + +First, we would like to contribute to efforts on standardizing a controlled +vocabulary, definitions for these terms, and relations between the terms, for +computational-geometry-based descriptions of the structure of materials and +atomic configurations used when characterizing materials in experiments +and computer simulations. + +As far as NeXus is concerned, the here proposed distinct sets of simple +geometric primitives and shapes offer a complementary alternative to the +already existent base classes in NeXus for constructive solid geometry +such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name but a few. + +Second, we would like to explore with this proposal how we can harmonize terms +frequently used by materials scientists in the field of condensed-matter physics +with definitions and terms offer by the NOMAD MetaInfo description. + +Third, the proposal should yield a substantiated set of arguments and suggestions +how descriptors for the structure and atomic architecture of materials can be +harmonized. With this we especially would like to reach out and intensify the +cooperation between the materials-science-related consortia of the German +National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, +NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. + +.. The proposal reaches out to our colleagues in the materials engineering-based +.. consortia to document that there is value in discussing about controlled vocabulary. + +.. _PhysicsCgms: + +Physics background +################## +Microstructural features or crystal defects are spatial arrangements of atoms. +Given their specific atomic arrangement and composition, such features have +specific constraints on the degrees of freedom how atoms can arrange. This causes +that these defects have specific properties. +Provided well-defined coarse-graining procedures are used and regions-of-interest +and/or regions-of-applicability are defined, microstructural features are often +characterized and modelled to have associated thermodynamic descriptors. + +Another motivation for the proposal was the observation that frequently the design +of file formats for simulation software in the computational materials science especially +those tools at the interface between condensed-matter physics and materials engineering +are frequently reimplementing the wheel (at least partly) when it comes to decide how to store +e.g. atom and feature positions or shape of regions-of-interest, grids, crystals, +grains, precipitates, and dislocations. + +Maybe this is a historical burden given the large set of technical terms and jargon +in place, which then motivated pragmatic solutions that resulted in many research groups +have developed similar formats using similar descriptions. + +We see this work on base classes and application definitions not primarily an +effort to improve and extend NeXus for now. Rather this part of the proposal +is an effort to support activities in materials science to work towards +common terminology and using controlled vocabularies more frequently. +These are the foundation for more sophisticated thoughts about practically +useful ontologies. + +Defining crystal defects is a question of how to coarse-grain a given spatio- +temporal set of atoms, each having a nuclid type and position/trajectory. +In most cases, such a coarse-graining is an ill-posed task because different +mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric defect +can be described and be spatio-temporally constrained through a geometrical model +with defined geometric primitives and associated coarser-scale properties. + +The key motivation to such coarse-graining is to reduce the complexity of the +description. On the one hand to support visualization and scientific analyses - not only +of crystal defect arrangements. On the other hand it is the hope that using descriptors +at a coarser level, i.e. nanometer, micrometer, and larger, it is still possible +to find sufficiently accurate and precise descriptors which avoid that one has +to account for the dynamics of each atom to predict or understand the properties +of defects and their dynamics. + +Nevertheless, experience has shown that computational-geometry-based descriptions +when combined with hierarchical clustering/labeling methods, applied on set of +atoms and features turn out to yield useful descriptors. Examples include point, +line, surface defects, such as vacancies, solute cluster, dislocations, +disconnections, interfaces to name but a few. + +.. _CgmsBC: + +Base Classes +############ + +The following base classes are defined to incentivize the use of NeXus for +using computational-geometry-based descriptions. In what follows, base classes +for frequently used shapes and geometric primitives are proposed: + + :ref:`NXcg_sphere_set`: + A description for a set of possibly dissimilar spheres. + + :ref:`NXcg_ellipsoid_set`: + A description for a set of possibly dissimilar rotated ellipsoids. + + :ref:`NXcg_cylinder_set`: + A description for a set of possibly dissimilar rotated cylinders. + + :ref:`NXcg_point_set`: + A collection of points with labels or mark data. + + :ref:`NXcg_polyline_set`: + A collection of lines and linearized segments. + + :ref:`NXcg_triangle_set`: + A collection (or soup) of triangles. + + :ref:`NXcg_parallelogram_set`: + A collection of possibly dissimilar parallelograms. + + :ref:`NXcg_triangulated_surface_mesh`: + A mesh of triangles. + + :ref:`NXcg_polygon_set`: + A collection (or soup) of polygons. + + :ref:`NXcg_polyhedron_set`: + A collection (or soup) of polyhedra. + + :ref:`NXcg_roi_set`: + A container to host a number of different types of primitives. + + :ref:`NXcg_tetrahedron_set`: + A collection (or soup) of tetrahedra. + + :ref:`NXcg_hexahedron_set`: + A collection (or soup) of hexahedra with capabilities to represent + also simpler (bounding) boxes for e.g. binary trees. + +These base classes make use of base classes which describe data structures: + + :ref:`NXcg_face_list_data_structure`: + In essence, the usual way how polygon/polyhedra data are reported: + Via a list of vertices and faces with identifier and properties. + + :ref:`NXcg_half_edge_data_structure`: + A half-edge data structure is a useful complementary descriptor for + polygon/polyhedra which enables topological analyses and traversal + of the graph how polygons and polyhedra can alternatively be described. + + :ref:`NXcg_unit_normal_set`: + As an additional structuring element especially for meshes, well-documented + normal information is crucial for distance computations. + + :ref:`NXcg_geodesic_mesh`: + Geodesic meshes are useful for all applications when meshing the surface + of a sphere. + + :ref:`NXcg_alpha_complex`: + Alpha shapes and alpha wrappings, specifically the special case of the + convex hull, are frequently used geometrical models for describing + a boundary or edge to a set of geometric primitives. + +Furthermore, a few base classes are defined for documenting the working with +discretized representations of material (area or volume) which can be useful +not only for stencil-based methods: + + :ref:`NXcg_grid`: + A grid of cells. + + :ref:`NXisocontour`: + A description for isocontour descriptions. + + :ref:`NXcg_marching_cubes`: + An approach to store metadata of a specific implementation of + the Marching Cubes algorithm, whose sensitivity to specific topological + configurations is known to result in different triangle soups. + + :ref:`NXdelocalization`: + An approach to document procedures whereby a scalar field + is smoothened in a controlled manner. + + :ref:`NXsimilarity_grouping`: + An alias for NXclustering. + + :ref:`NXclustering`: + A description for clustering of objects (such as atoms or features). + + :ref:`NXorientation_set`: + A set of rotations to describe the relative orientation of members of a set of features/objects. + + :ref:`NXslip_system_set`: + Metadata to a set of slip system/slip system family for + a given crystal structure. + + :ref:`NXms_feature_set`: + Generic base class to describe any nested set of features + of a microstructure at the continuum-, micron-, nano-scale, or + to represent a topology of molecules and atoms. + + :ref:`NXms_snapshot`: + A container to describe the state of microstructural features + at a given point in time. + + :ref:`NXms_snapshot_set`: + The corresponding class to hold a set of :ref:`NXms_snapshot` objects. + + :ref:`NXchemical_composition`: + (Chemical) composition of a sample or a set of things. + +Furthermore, it can be useful to have a set of base classes with +which software documents it state and gives a summary for users about the performance +and elapsed time measured while processing data. These utility classes include: + + :ref:`NXprogram`: + A named and version of a program of library/component. + + :ref:`NXcs_filter_boolean_mask`: + A boolean mask. + + :ref:`NXcs_prng`: + Metadata of a pseudo-random number generator (PRNG) algorithm. + + :ref:`NXcs_profiling`: + A structuring group holding a set of :ref:`NXcs_profiling_event` instances. + + :ref:`NXcs_profiling_event`: + Profiling/benchmark data to an event of + tracking an algorithm/computational step. + + :ref:`NXcs_computer`: + Metadata of a computer. + + :ref:`NXcs_cpu`: + Metadata of a central processing unit. + + :ref:`NXcs_gpu`: + Metadata of a graphical processing unit / accelerator. + + :ref:`NXcs_mm_sys`: + Metadata of the (main) memory (sub-)system. + + :ref:`NXcs_io_sys`: + Metadata of the input/output system. + + :ref:`NXcs_io_obj`: + Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. + +.. _IcmeMsModels: + +Application definitions for ICME models +####################################### + +It is important to embrace the large research community of materials engineers +as they are frequent users of electron microscopy and atom probe microscopy. +In this community frequently ICME microstructure models are used. ICME is an +abbreviation for Integrated Computational Materials Engineering, which is a +design strategy and workflow whereby physics-based modelling of microstructure +evolution at the mesoscopic scale is used to understand the relations between +the microstructure and technological relevant descriptors for the properties +of materials. + +The following application definitions are proposed to support the discussion +how materials engineering-specific data models and connect to or be mapped on +concepts which are equally modellable with NeXus: + + :ref:`NXms`: + An application definition for arbitrary spatiotemporally resolved simulations. + + :ref:`NXms_score_config`: + A specific example how :ref:`NXapm_paraprobe_config_ranger` can be + specialized for documenting the configuration of a computer simulation + with the static recrystallization cellular automata model SCORE. + + :ref:`NXms_score_results`: + A specific example how :ref:`NXms` can be specialized for documenting + results of computer simulations with the static recrystallization + cellular automata model SCORE. From 1711aa691c7313afbd3d9402ecb4255ee4790bf6 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 22 Jun 2023 15:51:09 +0200 Subject: [PATCH 191/203] Readds anchor --- .../classes/contributed_definitions/ellipsometry-structure.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index 7d42c33587..85cf5b5bed 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -32,6 +32,8 @@ Application Definitions +.. _DispersiveMaterial: + Dispersive Material ################### From 0c00b1b25b84396c70273a6818e5adc91aa54f28 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 22 Jun 2023 17:06:30 +0200 Subject: [PATCH 192/203] Adds base classes for NXopt --- .../ellipsometry-structure.rst | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index 85cf5b5bed..87309d4339 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -31,6 +31,38 @@ Application Definitions An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. +Base Classes +------------ + +There is a set of base classes for describing an optical experiment. + + :ref:`NXbeam_path` + A beam path consisting of one or more optical elements. + + NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement + of optical elements between the excitation source and the sample, or between + the sample and the detector unit. + + :ref:`NXbeam_splitter` + A beam splitter, i.e. a device splitting the light into two or more beams. + + Use two or more NXbeam_paths to describe the beam paths after the beam + splitter. In the dependency chain of the new beam paths, the first elements + each point to this beam splitter, as this is the previous element. + + :ref:`NXfiber` + An optical fiber, e.g. glass fiber. + + :ref:`NXlens_opt` + Description of an optical lens. + + :ref:`NXpolarizer_opt` + A spin polarizer. + + :ref:`NXwaveplate` + A waveplate or retarder. + + .. _DispersiveMaterial: From 1a6c6f58194782baa8f538e5a750878ac3cf84a5 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 22 Jun 2023 17:10:57 +0200 Subject: [PATCH 193/203] Adds NXenvironment to NXopt docs --- .../contributed_definitions/ellipsometry-structure.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index 87309d4339..40173f3b39 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -62,6 +62,11 @@ There is a set of base classes for describing an optical experiment. :ref:`NXwaveplate` A waveplate or retarder. + :ref:`NXenvironment` + Specify external parameters that have influenced the sample, + such as the surrounding medium, and varied parameters e.g. + temperature, pressure, pH value, optical excitation etc. + .. _DispersiveMaterial: From 33daf0fe0e8ca11816fff2cacc9281962d2878c3 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Tue, 18 Jul 2023 11:53:33 +0200 Subject: [PATCH 194/203] including CGMS section to the page of Contibuted Definitions --- dev_tools/docs/nxdl_index.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 10cd1d67ec..a580d57a9d 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -170,6 +170,8 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: :ref:`Transport Measurements ` + :ref:`Geomerty and Microstructures ` + and others are simply listed here: From d4f9327a977ad7eef6bc563b37c2494f7b3e0ba0 Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 18 Jul 2023 17:21:52 +0200 Subject: [PATCH 195/203] Remove Nxopt yaml --- contributed_definitions/nyaml/NXopt.yaml | 703 ----------------------- 1 file changed, 703 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXopt.yaml diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml deleted file mode 100644 index 15289ceb79..0000000000 --- a/contributed_definitions/nyaml/NXopt.yaml +++ /dev/null @@ -1,703 +0,0 @@ -# 05/2023 -# Draft of a NeXus application definition which serves as a template for various -# optical spectroscopy experiments - -# To do: -# [ ] Check base classes (NXbeam_path + base classes used by it) -# [ ] Harmonize NXopt and NXellipsometry -# [ ] Fix dimensions and ranks - -category: application -doc: | - An application definition for optical spectroscopy experiments. -symbols: - doc: Variables used throughout the document, e.g. dimensions or parameters. - N_spectrum: | - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - N_sensors: | - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. - N_measurements: | - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - N_detection_angles: | - Number of detection angles of the beam reflected or scattered off the - sample. - N_incident_angles: Number of angles of incidence of the incident beam. - N_observables: | - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - -NXopt: - (NXentry): - doc: | - An application definition template for optical spectroscopy experiments. - - A general optical experiment consists of a light or excitation source, a - beam path, a sample + its stage + its environment, and a detection unit. - Examples are reflection or transmission measurements, photoluminescence, - Raman spectroscopy, ellipsometry etc. - - definition: - doc: An application definition describing a general optical experiment. - \@version: - doc: | - Version number to identify which definition of this application - definition was used for this entry/data. - \@url: - doc: | - URL where to find further material (documentation, examples) relevant - to the application definition. - enumeration: [NXopt] - experiment_identifier: - doc: | - A (globally persistent) unique identifier of the experiment. - (i) The identifier is usually defined by the facility or principle - investigator. - (ii) The identifier enables to link experiments to e.g. proposals. - experiment_description: - exists: optional - doc: | - An optional free-text description of the experiment. - - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description. - experiment_type: - doc: Specify the type of the optical experiment. - start_time(NX_DATE_TIME): - doc: Start time of the experiment. UTC offset should be specified. - (NXuser): - doc: | - Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users, if relevant, is recommended. - name(NX_CHAR): - doc: Name of the user. - affiliation(NX_CHAR): - exists: recommended - doc: | - Name of the affiliation of the user at the point in time when the - experiment was performed. - address(NX_CHAR): - exists: recommended - doc: Street address of the user's affiliation. - email(NX_CHAR): - doc: Email address of the user. - orcid(NX_CHAR): - exists: recommended - doc: Author ID defined by https://orcid.org/. - telephone_number(NX_CHAR): - exists: recommended - doc: Telephone number of the user. - - (NXinstrument): - doc: | - Properties of the experimental setup. This includes general information - about the instrument (such as model, company etc.), information about - the calibration of the instrument, elements of the beam path including - the excitation or light source and the detector unit, the sample stage - (plus the sample environment, which also includes sensors used to - monitor external conditions) and elements of the beam path. - - Meta data describing the sample should be specified in ENTRY/SAMPLE - outside of ENTRY/INSTRUMENT. - model: - doc: The name of the instrument. - \@version: - doc: | - The used version of the hardware if available. If not a commercial - instrument use date of completion of the hardware. - company: - exists: optional - doc: Name of the company which build the instrument. - construction_year(NX_DATE_TIME): - exists: optional - doc: | - ISO8601 date when the instrument was constructed. - UTC offset should be specified. - software(NXprocess): - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to measure the data, i.e. the software used to start and - record the measured data and/or metadata. - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@url: - exists: optional - doc: Website of the software. - firmware(NXprogram): - exists: recommended - doc: | - Commercial or otherwise defined name of the firmware that was used - for the measurement - if available. - \@version: - doc: | - Version and build number or commit hash of the software source code. - \@url: - exists: optional - doc: Website of the software. - calibration_status(NX_CHAR): - doc: | - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. - enumeration: - [ - calibration time provided, - no calibration, - within 1 hour, - within 1 day, - within 1 week, - ] - calibration(NXsubentry): - exists: recommended - doc: The calibration data and metadata should be described in a - separate NeXus file with the link provided in 'calibration_link'. - calibration_time(NX_DATE_TIME): - exists: optional - doc: | - If calibtration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. - calibration_data_link: - doc: | - Link to the NeXus file containing the calibration data and metadata. - (NXbeam_path): - doc: | - Describes an arrangement of optical or other elements, e.g. the beam - path between the light source and the sample, or between the sample - and the detector unit (including the sources and detectors - themselves). - - If a beam splitter (i.e. a device that splits the incoming beam into - two or more beams) is part of the beam path, two or more NXbeam_path - fields may be needed to fully describe the beam paths and the correct - sequence of the beam path elements. - Use as many beam paths as needed to describe the setup. - angle_of_incidence(NX_NUMBER): - doc: | - Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, N_incident_angles]] - \@units: - detection_angle(NX_NUMBER): - exists: optional - doc: | - Detection angle(s) of the beam reflected or scattered off the sample - vs. the normal of the bottom reflective (substrate) surface in the - sample if not equal to the angle(s) of incidence. - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, N_detection_angles]] - sample_stage(NXsubentry): - doc: | - Sample stage, holding the sample at a specific position in X,Y,Z - (Cartesian) coordinate system and at an orientation defined - by three Euler angles (alpha, beta, gamma). - stage_type: - doc: Specify the type of the sample stage. - enumeration: - [ - manual stage, - scanning stage, - liquid stage, - gas cell, - cryostat - ] - alternative: - exists: optional - doc: | - If there is no motorized stage, we should at least qualify where - the beam hits the sample and in what direction the sample stands - in a free-text description, e.g. 'center of sample, long edge - parallel to the plane of incidence'. - environment_conditions(NXenvironment): - doc: | - Specify external parameters that have influenced the sample, such - as the surrounding medium, and varied parameters e.g. temperature, - pressure, pH value, optical excitation etc. - medium: - doc: | - Describe what was the medium above or around the sample. The - common model is built up from the substrate to the medium on the - other side. Both boundaries are assumed infinite in the model. - Here, define the name of the medium (e.g. water, air, UHV, etc.). - medium_refractive_indices(NX_FLOAT): - exists: optional - doc: | - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: - [ - [1, 2], - [2, N_spectrum] - ] - PARAMETER(NXsensor): - exists: optional - doc: | - A sensor used to monitor an external condition influencing the - sample, such as temperature or pressure. It is suggested to - replace 'PARAMETER' by the type of the varied parameter defined - in 'parameter_type'. - The measured parameter values should be provided in 'values'. - For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. - In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. - parameter_type: - doc: | - Indicates which parameter was changed. Its definition must exist - below. The specified variable has to be N_measurements long, - providing the parameters for each data set. If you vary more than - one parameter simultaneously. - If the measured parameter is not contained in the list `other` - should be specified and the `parameter_type_name` should be provided. - enumeration: - [ - conductivity, - detection_angle, - electric_field, - flow, - incident_angle, - magnetic_field, - optical_excitation, - pH, - pressure, - resistance, - shear, - stage_positions, - strain, - stress, - surface_pressure, - temperature, - voltage, - other, - ] - parameter_type_name: - doc: | - If the parameter_type is `other` a name should be specified here. - exists: optional - number_of_parameters(NX_POSINT): - doc: | - Number of different parameter values at which the measurement - was performed. For example, if the measurement was performed at - temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - unit: NX_UNITLESS - values(NX_FLOAT): - unit: NX_ANY - doc: | - Vector containing the values of the varied parameter. Its - length is equal to N_measurements. The order of the values - should be as follows: - - * Order the sensors according to number_of_parameters starting - with the lowest number. If number_of_parameters is equal for - two sensors order them alphabetically (sensor/parameter name). - * The first sensor's j parameters should be ordered in the - following way. The first N_measurements/number_of_parameters - entries of the vector contain the first parameter (a1), the - second N_measurements/number_of_parameters contain the second - parameter (a2) etc., so the vector looks like: - [ - a1,a1,...,a1, - a2,a2,...,a2, - ... - aj,aj,...aj - ] - * The kth sensor's m parameters should be ordered in the - following way: - [ - p1,...p1,p2,...,p2,...pm,...,pm, - p1,...p1,p2,...,p2,...pm,...,pm, - ... - p1,...p1,p2,...,p2,...pm,...,pm - ] - * The last sensor's n parameters should be ordered in the - following way: - [ - z1,z2,...,zn, - z1,z2,...,zn, - ... - z1,z2,...,zn] - - For example, if the experiment was performed at three different - temperatures (T1, T2, T3), two different pressures (p1, p2) and - two different angles of incidence (a1, a2), then - N_measurements = 12 and the order of the values for the various - parameter vectors is: - - * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] - * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] - * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] - - dimensions: - rank: 1 - dim: [[1, N_measurements]] - WINDOW(NXaperture): - exists: optional - doc: | - For environmental measurements, the environment (liquid, vapor - etc.) is enclosed in a cell, which has windows both in the - direction of the source (entry window) and the detector (exit - window) (looking from the sample). In case that the entry and exit - windows are not the same type and do not have the same properties, - use a second 'WINDOW(MXaperture)' field. - - The windows also add a phase shift to the light altering the - measured signal. This shift has to be corrected based on measuring - a known sample (reference sample) or the actual sample of interest - in the environmental cell. State if a window correction has been - performed in 'window_effects_corrected'. Reference data should be - considered as a separate experiment, and a link to the NeXus file - should be added in reference_data_link in measured_data. - - The window is considered to be a part of the sample stage but also - beam path. Hence, its position within the beam path should be - defined by the 'depends_on' field. - depends_on: - exists: recommended - doc: | - Specify the position of the window in the beam path by pointing - to the preceding element in the sequence of beam path elements. - window_effects_corrected(NX_BOOLEAN): - doc: | - Was a window correction performed? If 'True' describe the window - correction procedure in 'window_correction/procedure'. - window_correction(NXprocess): - exists: optional - doc: | - Was a window correction performed? If 'True' describe the - window correction procedure in '' - procedure: - doc: | - Describe when (before or after the main measurement + time - stamp in 'date') and how the window effects have been - corrected, i.e. either mathematically or by performing a - reference measurement. In the latter case, provide the link to - to the reference data in 'reference_data_link'. - reference_data_link: - exists: optional - doc: | - Link to the NeXus file which describes the reference data if a - reference measurement for window correction was performed. - Ideally, the reference measurement was performed on a reference - sample and on the same sample, and using the same conditions as - for the actual measurement with and without windows. It should - have been conducted as close in time to the actual measurement - as possible. - material(NX_CHAR): - doc: The material of the window. - enumeration: - [ - quartz, - diamond, - calcium fluoride, - zinc selenide, - thallium bromoiodide, - alkali halide compound, - Mylar, - other, - ] - other_material(NX_CHAR): - exists: optional - doc: | - If you specified 'other' as material, decsribe here what it is. - thickness(NX_FLOAT): - doc: Thickness of the window. - unit: NX_LENGTH - orientation_angle(NX_FLOAT): - doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - unit: NX_ANGLE - - (NXsample): - doc: | - Properties of the sample, such as sample type, layer structure, - chemical formula, atom types, its history etc. - Information about the sample stage and sample environment should be - described in ENTRY/INSTRUMENT/sample_stage. - sample_name: - doc: Descriptive name of the sample - sample_type: - doc: | - Specify the type of sample, e.g. thin film, single crystal etc. - enumeration: - [ - 'thin film', - 'single crystal', - 'poly crystal', - 'single layer', - 'multi layer' - ] - layer_structure: - doc: | - Qualitative description of the layer structure for the sample, - starting with the top layer (i.e. the one on the front surface, on - which the light incident), e.g. native oxide/bulk substrate, or - Si/native oxide/thermal oxide/polymer/peptide. - chemical_formula: - doc: | - Chemical formula of the sample. Use the Hill system (explained here: - https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write - the chemical formula. In case the sample consists of several layers, - this should be a list of the chemical formulas of the individual - layers, where the first entry is the chemical formula of the top - layer (the one on the front surface, on which the light incident). - The order must be consistent with layer_structure - atom_types: - doc: | - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - 'atom_types'. - sample_history: - doc: | - Ideally, a reference to the location or a unique (globally - persistent) identifier (e.g.) of e.g. another file which gives - as many as possible details of the material, its microstructure, - and its thermo-chemo-mechanical processing/preparation history. - In the case that such a detailed history of the sample is not - available, use this field as a free-text description to specify - details of the sample and its preparation. - preparation_date(NX_DATE_TIME): - exists: recommended - doc: ISO8601 date with time zone (UTC offset) specified. - substrate: - exists: recommended - doc: Description of the substrate. - sample_orientation: - exists: optional - doc: Specify the sample orientation. - - data_collection(NXprocess): - doc: | - Measured data, data errors, and varied parameters. If reference data - were measured they should be considered a separate experiment and a - link to its NeXus file should be added in reference_data_link. - data_identifier(NX_NUMBER): - doc: | - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0-N. - data_type: - doc: | - Select which type of data was recorded, for example intensity, - reflectivity, transmittance, Psi and Delta etc. - It is possible to have multiple selections. The enumeration list - depends on the type of experiment and may differ for different - application definitions. - enumeration: - [ - intensity, - reflectivity, - transmittance, - Psi/Delta, - tan(Psi)/cos(Delta), - Mueller matrix, - Jones matrix, - N/C/S, - raw data, - ] - NAME_spectrum(NX_FLOAT): - # This should be a required field, but is set to 'optional' for the moment - exists: optional - doc: | - Spectral values (e.g. wavelength or energy) used for the measurement. - An array of 1 or more elements. Length defines N_spectrum. Replace - 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, N_spectrum]] - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - measured_data(NX_FLOAT): - doc: | - Resulting data from the measurement, described by 'data_type'. - - The first dimension is defined by the number of measurements taken, - (N_measurements). The instructions on how to order the values - contained in the parameter vectors given in the doc string of - INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, - define the N_measurements parameter sets. For example, if the - experiment was performed at three different temperatures - (T1, T2, T3), two different pressures (p1, p2) and two different - angles of incidence (a1, a2), the first measurement was taken at the - parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. - unit: NX_ANY - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, N_observables], # 2 for Psi and Delta, 16 for Mueller matrix etc - [3, N_spectrum] - ] - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - measured_data_errors(NX_FLOAT): - exists: optional - doc: | - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. - unit: NX_ANY - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, N_observables], # 2 for Psi and Delta, 16 for Mueller matrix etc - [3, N_spectrum] - ] - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - varied_parameter_link: - exists: optional - doc: | - List of links to the values of the sensors. Add a link for each - varied parameter (i.e. for each sensor). - dimensions: - rank: 1 - dim: [[1, N_sensors]] - reference_data_link: - exists: optional - doc: | - Link to the NeXus file which describes the reference data if a - reference measurement was performed. Ideally, the reference - measurement was performed using the same conditions as the actual - measurement and should be as close in time to the actual measurement - as possible. - data_software(NXprocess): - exists: optional - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and/or - metadata (in most cases, this is the same as INSTRUMENT/software). - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@url: - exists: optional - doc: Website of the software. - (NXdata): - exists: optional - doc: | - A plot of the multi-dimensional data array provided in - ENTRY/data/measured_data. - \@axes: - doc: Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - - derived_parameters(NXprocess): - exists: optional - doc: Parameters that are derived from the measured data. - depolarization(NX_NUMBER): - exists: optional - doc: Light loss due to depolarization as a value in [0-1]. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, 1], - [3, N_spectrum] - ] - Jones_quality_factor(NX_NUMBER): - exists: optional - doc: Jones quality factor. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, 1], - [3, N_spectrum] - ] - reflectivity(NX_NUMBER): - exists: optional - doc: Reflectivity. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, 1], - [3, N_spectrum] - ] - transmittance(NX_NUMBER): - exists: optional - doc: Transmittance. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_measurements], - [2, 1], - [3, N_spectrum] - ] - ANALYSIS_program(NXprocess): - exists: optional - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to generate or calculate the derived parameters. - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - plot(NXdata): - doc: | - A default view of the data provided in ENTRY/data_collection/measured_data. This - should be the part of the data set which provides the most suitable - representation of the data. - \@axes: - doc: Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) From 36d4c0e94291b50fcff71f31757d8296d2abd9a3 Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Tue, 21 Nov 2023 09:46:48 +0100 Subject: [PATCH 196/203] fixing typo as suggested --- dev_tools/docs/nxdl_index.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index a580d57a9d..310c9c20f1 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -159,7 +159,7 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: definitions and provide feedback to the authors before ratification and acceptance as either a base class or application definition. -Some contributions are groupped together: +Some contributions are grouped together: :ref:`Optical Spectroscopy ` :ref:`Multi-dimensional Photoemission Spectroscopy ` From 0e6dd1a0428843a6e6224ba0d3ba50f506508cbd Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Tue, 21 Nov 2023 09:47:50 +0100 Subject: [PATCH 197/203] fixing typo as requested --- dev_tools/docs/nxdl_index.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 310c9c20f1..0ede704ac4 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -164,7 +164,7 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: :ref:`Multi-dimensional Photoemission Spectroscopy ` - :ref:`Atomprobe Microscopy ` + :ref:`Atom Probe Microscopy ` :ref:`Electron Microscopy ` From 5efcc1af962d3629b72dc7ef387439dd06bb2d42 Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Tue, 21 Nov 2023 18:51:19 +0100 Subject: [PATCH 198/203] typo fixed as suggested --- dev_tools/docs/nxdl_index.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 0ede704ac4..bcb8ac666b 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -170,7 +170,7 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: :ref:`Transport Measurements ` - :ref:`Geomerty and Microstructures ` + :ref:`Geometry and Microstructures ` and others are simply listed here: From eac06573c0e4a16b901efacad20036e21e2c178f Mon Sep 17 00:00:00 2001 From: atomprobe-tc Date: Tue, 5 Dec 2023 12:12:43 +0100 Subject: [PATCH 199/203] Implementing reviewer suggestions of @prjemian, @phyy-nx, and @PeterC-DLS --- contributed_definitions/NXem.nxdl.xml | 46 +++++++------------ .../cgms-structure.rst | 43 +++++++++-------- .../ellipsometry-structure.rst | 4 +- .../contributed_definitions/em-structure.rst | 19 ++++---- 4 files changed, 49 insertions(+), 63 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 5b2eceb134..508d808cdb 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -60,12 +60,12 @@ that it is required--> Multiple specimens have to be described with multiple :ref:`NXentry` instances. - **Electron microscopes motivate the development of an embracing data schema:** + **Electron microscopes motivate the development of a comprehensive data schema:** There are research groups who use an EM in a manner where it is exclusively operated by a single, instrument-responsible scientists or a team of scientists. These users may perform analyses for other users as a service task, especially in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process maybe even control + cutting-edge instruments, the scientists guide the process and maybe even control the microscope. Instruments are usually controlled on-premises but also more and more functionalities for remote control have become available. Scientists oftentimes can ask technicians for support. In all cases, @@ -91,7 +91,7 @@ that it is required--> radiation/specimen interactions. Often these detectors have a similar design and technology or are even used both in SEMs and TEMs. - **An embracing schema instead of specific SEM or TEM schemas**: + **A comprehensive schema instead of specific SEM or TEM schemas**: Given these physical and technical differences, different instruments have been developed. This led to a coexistence of two broad interacting communities: SEM and TEM users. From a data science perspective, we @@ -110,16 +110,8 @@ that it is required--> schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and especially vocabulary in use with implementations of these - into many data and file formats. There is nothing which prevents the communities - to make these schemas open and interoperable. Open here means not that all - data stored according to such schemas have to end up in the open-source domain. - There can be embargo periods first of all. - - Open means that the metadata and associated schemata are documented in a manner - that as many details are open as possible in the sense that others can understand - what the (meta)data mean conceptually. Instead of trying of maintain a zoo - of eventually difficult to make interoperable formats and schema we would like + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ should guide all decisions how data and metadata should be stored. @@ -181,10 +173,7 @@ that it is required--> analysis needs. Consumers can be again specific software tools, like vendor software for controlling the instrument or a scientific software for doing artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. Strictly speaking an application definition can only be - fully general if it does not make a single entry required, in which case however - it would also not offer much value as even empty datasets would be compliant - with such a schema. + to new versions. **Verification of constraints and conditions**: Tools like NeXus so far do not avoid or protect against all such possible @@ -343,29 +332,26 @@ that it is required--> These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, file storage, or even other formats, although HDF5 is often used. * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional XDMF fields which support additional plotting of - the data with visualization software like Paraview or Blender. + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. * Consumable results of EM characterization tasks are usually a sub-set of data artifacts, as there is not an infinite amount of possible electron/ion beam-specimen interactions. - * Images of electron counts detected in specific operation modes (bright - field, dark field in TEM, secondary/back-scattered, Kikuchi). - * Spectra (X-ray quanta or Auger electron counts) + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. * These data are in virtually all cases a result of some numerical processing. These data and processing steps are modelled as instances of :ref:`NXprocess` which use terms from a controlled vocabulary e.g. SE (secondary electron), BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. To this end the schema here makes no - specific assumptions, not even that all the fields/group of a schema instance - have to be stored at all into a single file. Instead, the schema specifies the - relations between metadata, some of the constraints and conditions on how the - data should be formatted, what the data conceptually represent, and which terms - (controlled vocabulary) is practical to store to index specific quantities. + should be stored (in memory or on disk)**. - In effect, the application definition is a graph which describes how - numerical data and (meta)data for EM research are related to one another. + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. Electron microscopy experiments are usually controlled/performed via commercial integrated acquisition and instrument control software. diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index 7bc1621393..f58017fc14 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -26,10 +26,10 @@ computational-geometry-based descriptions of the structure of materials and atomic configurations used when characterizing materials in experiments and computer simulations. -As far as NeXus is concerned, the here proposed distinct sets of simple -geometric primitives and shapes offer a complementary alternative to the -already existent base classes in NeXus for constructive solid geometry -such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name but a few. +As far as NeXus is concerned, this proposed set of simple geometric primitives +and shapes offer a complementary alternative to the current set of base classes in +NeXus for constructive solid geometry such as :ref:`NXcsg`, :ref:`NXoff_geometry`, +or :ref:`NXquadric` to name but a few. Second, we would like to explore with this proposal how we can harmonize terms frequently used by materials scientists in the field of condensed-matter physics @@ -52,7 +52,7 @@ Physics background Microstructural features or crystal defects are spatial arrangements of atoms. Given their specific atomic arrangement and composition, such features have specific constraints on the degrees of freedom how atoms can arrange. This causes -that these defects have specific properties. +these defects to have specific properties. Provided well-defined coarse-graining procedures are used and regions-of-interest and/or regions-of-applicability are defined, microstructural features are often characterized and modelled to have associated thermodynamic descriptors. @@ -75,12 +75,12 @@ common terminology and using controlled vocabularies more frequently. These are the foundation for more sophisticated thoughts about practically useful ontologies. -Defining crystal defects is a question of how to coarse-grain a given spatio- -temporal set of atoms, each having a nuclid type and position/trajectory. -In most cases, such a coarse-graining is an ill-posed task because different -mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric defect -can be described and be spatio-temporally constrained through a geometrical model -with defined geometric primitives and associated coarser-scale properties. +Defining crystal defects is a question of how to coarse-grain a given spatiotemporal +set of atoms, each having a nuclide type and position/trajectory. Different mathematical/geometrical +methods exists to coarse-grain and thus determine how a point, a line, a surface, or +a volumetric defect can be described and be spatiotemporally constrained through +a geometrical model with defined geometric primitives and associated (materials) +properties at a coarser-scale. The key motivation to such coarse-graining is to reduce the complexity of the description. On the one hand to support visualization and scientific analyses - not only @@ -216,9 +216,8 @@ not only for stencil-based methods: :ref:`NXchemical_composition`: (Chemical) composition of a sample or a set of things. -Furthermore, it can be useful to have a set of base classes with -which software documents it state and gives a summary for users about the performance -and elapsed time measured while processing data. These utility classes include: +Finally, the following base classes allow data processing software to document its input +parameters and to summarize its performance statistics: :ref:`NXprogram`: A named and version of a program of library/component. @@ -261,26 +260,26 @@ Application definitions for ICME models It is important to embrace the large research community of materials engineers as they are frequent users of electron microscopy and atom probe microscopy. -In this community frequently ICME microstructure models are used. ICME is an -abbreviation for Integrated Computational Materials Engineering, which is a -design strategy and workflow whereby physics-based modelling of microstructure -evolution at the mesoscopic scale is used to understand the relations between +In this community frequently ICME (Integrated Computational Materials Engineering) +microstructure models are used. These models are derived from a design strategy +and workflow whereby physics-based modelling of microstructure evolution, typically +at the mesoscopic scale, is used to understand the relations between the microstructure and technological relevant descriptors for the properties of materials. -The following application definitions are proposed to support the discussion -how materials engineering-specific data models and connect to or be mapped on +The following application definitions are proposed to support discussion on +how materials engineering-specific data models connect to or can be mapped on concepts which are equally modellable with NeXus: :ref:`NXms`: An application definition for arbitrary spatiotemporally resolved simulations. :ref:`NXms_score_config`: - A specific example how :ref:`NXapm_paraprobe_config_ranger` can be + A specific example of how :ref:`NXapm_paraprobe_config_ranger` can be specialized for documenting the configuration of a computer simulation with the static recrystallization cellular automata model SCORE. :ref:`NXms_score_results`: - A specific example how :ref:`NXms` can be specialized for documenting + A specific example of how :ref:`NXms` can be specialized for documenting results of computer simulations with the static recrystallization cellular automata model SCORE. diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index 40173f3b39..15be0dab80 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -25,7 +25,7 @@ Application Definitions ----------------------- :ref:`NXopt`: - A generic application definition for optial spectorscopy measurements, including complex systems up to variable angle spectroscopic ellipsometry. + A generic application definition for optical spectroscopy measurements, including complex systems up to variable angle spectroscopic ellipsometry. :ref:`NXellipsometry`: An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. @@ -34,7 +34,7 @@ Application Definitions Base Classes ------------ -There is a set of base classes for describing an optical experiment. +This is the set of base classes for describing an optical experiment. :ref:`NXbeam_path` A beam path consisting of one or more optical elements. diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index f3acf66ef2..ab45ab4b54 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -16,11 +16,11 @@ Electron microscopy Introduction ############ -Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. In what follows the focus is on the usage of electron microscopy in condensed-matter physics, chemical physics of solids, and materials engineering applications. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. + Partner consortia in the German National Research Data Infrastructure are here e.g. -NFDI-BioImage, NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. +NFDI-MatWerk, NFDI4Ing, NFDI-BioImage, NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. -Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods are increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it difficult to keep track of workflows in a technology-partner-agnostic, +Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods are increasingly used and are becoming more closely interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it difficult to keep track of workflows in a technology-partner-agnostic, i.e. interdisciplinary manner. .. _EmAppDef: @@ -28,11 +28,11 @@ i.e. interdisciplinary manner. Application Definitions ####################### -We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet not unnecessary complex and useful for application across a variety of instruments, technology partners, and instrument use cases. In what follows, the proposal conceptualizes first the basic components of an electron microscope and the usual workflow how an electron microscope is used for collecting data with detectors via probing radiation-specimen-matter interaction mechanisms. +We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet not unnecessarily complex and useful for applications across a variety of instruments, technology partners, and instrument use cases. In what follows, the proposal conceptualizes first the basic components of an electron microscope and the usual workflow of how an electron microscope is used for collecting data with detectors via probing radiation-specimen-matter interaction mechanisms. -In summary, scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments, prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all of these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. +In summary, scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, and may perform experiments, prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all of these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. -A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as session on the microscope. Next, we wrote base classes to describe these steps and events. +A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as a session on the microscope. We have provided base classes to describe these steps and events and an application definition for electron microscopy. :ref:`NXem`: A general application definition which explores the possibilities of electron microscopes. @@ -116,10 +116,11 @@ The following base classes are proposed to support modularizing the storage of p .. _EmPartnerClasses: -Partner application definitions -############################### +Method-specific concepts and their usage in application definitions +################################################################### + +It became clear during the design of the electron microscopy specific additions to NeXus that there are sets of pieces of information (data and metadata) which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow of processing these data into knowledge, motivating the granularization of these pieces of information in their own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that (diffraction) patterns are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. through post-processing these data. These numerical and algorithmic steps define computational workflows where data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints would demand having their own but almost similar application definition. For this reason, the concept of method-specific concepts which have fields/links where specifically relevant sources of information are connected to them e.g. NXem. -A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize these pieces of information in an own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that (diffraction) patterns are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. through post-processing these data. These numerical and algorithmic steps define computational workflows were data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. For this reason, the concept of partner application definition which have fields/links where specifically relevant sources of information are connected to e.g. NXem. More consolidation through the use of NXsubentry classes should be considered in the future. :ref:`NXem_ebsd`: From 73314b668f4795eb771fcca7638d26fb542a372c Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 18 Dec 2023 11:44:48 +0100 Subject: [PATCH 200/203] Addresses review comments --- .../contributed_definitions/ellipsometry-structure.rst | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index 15be0dab80..cb690fac4f 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -114,7 +114,7 @@ There is a set of base classes for describing a dispersion. ``A`` and ``B`` are repeated parameters in the formula above. :ref:`NXdispersion_table` - This describes a tabular dispersion where the dielectric function is an array versus wavelength or energy. + This describes a tabular dispersion where the permittivity is an array versus wavelength or energy. Formula Grammar --------------- @@ -122,6 +122,12 @@ Formula Grammar Below you find a grammar to which the formula should adhere and which can be used to parse and evaluate the dispersion function. The terms ``single_param_name`` and ``param_name`` should be filled with the respective single and repeated params from the stored data. +The grammer is written in the `EBNF `_ dialect +of `Lark `_, which is a parsing toolkit for python. +It is easily translatable to general EBNF and other parser generator dialects. +`Here `_ is a reference implementation in Rust/Python with a +`grammar `_ +written in `lalrpop `_. .. code-block:: From 80051e2ea11941694af72db49bd3e5d1a8aa3627 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 15 Jan 2024 15:36:40 +0100 Subject: [PATCH 201/203] Providing feedback to hidden conversations --- contributed_definitions/NXem.nxdl.xml | 39 ++++++-------- .../cgms-structure.rst | 53 +++++++++---------- .../contributed_definitions/em-structure.rst | 6 +-- .../transport-structure.rst | 10 +++- 4 files changed, 50 insertions(+), 58 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 508d808cdb..fd980b67b2 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -176,9 +176,9 @@ that it is required--> to new versions. **Verification of constraints and conditions**: - Tools like NeXus so far do not avoid or protect against all such possible - inconsistencies; however NeXus offers a mechanism and toolset, through which - schemas can be documented and defined. In effect, having an openly documented + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented (at a case-specific level of technical detail) schema is a necessary but alone not a sufficient step to take EM research on a route of machine-actionable and interoperable FAIR data. @@ -269,17 +269,11 @@ that it is required--> **This application definition has the following components at the top-level:** - * Generic experimental details (time-zone-aware timestamp, identifiers, name); - conceptually these are session details. A session at a microscope may - involve the characterization of multiple specimens. For each specimen - an instance of an (NXentry) is created. Details of the instrument have to - be stored at least in an entry. Other entries should refer to these - metadata via links to reduce redundancies. * Each signal, such as a spectrum or image taken at the microscope, should have an associated time-zone-aware time stamp and report of the specific settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have an own em_lab section. - The reason is that EMs can be highly dynamic, be used to illuminate the specimen + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen differently or show drift during signal acquisition, to name but a few effects. What constitutes a single EM experiment/measurement? This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), @@ -294,25 +288,25 @@ that it is required--> relevant for documenting as exactly as practically possible settings when images and spectra were taken. * :ref:`NXinstrument`; - conceptually this is a container to store arbitrary level of detail of the + conceptually this is a container to store an arbitrary level of detail of the technical components of the microscope as a device and the lab in which the microscope is operated. * :ref:`NXuser`; conceptually, this is a set with at least one NXuser instance which details who operated or performed the measurement. Additional NXusers can be referred to in an NXevent_data_em instance to store - individualized details who executed an event of data acquisition or processing. + individualized details of who executed an event of data acquisition or processing. * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; each NXevent_data_em instance is a container to group specific details about the state of the microscope when a measurement was taken and relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, conceptually, this is a place for documenting - available default plottable data. A default plottable can be useful for - research data management systems to show a visual representation of some + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some aspect of the content of the EM session. - Default plottables not intended to serve every possible analysis and - visualization demand but be a preview. We made this choice because what - constitutes a useful default plot is often a matter of interpretation, + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, somewhat of personal taste, and community standards. In effect, default plottables are case- and method-specific. @@ -326,11 +320,8 @@ that it is required--> * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` instances to hold data at the earliest possible step in the computational processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables to - display image and spectra with web technology visualization software. - NeXus specifies only the data model, i.e. the terms and their relations. - These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, - file storage, or even other formats, although HDF5 is often used. + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. * When two- and three-dimensional geometric primitive data are stored, it is useful to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ fields which support additional plotting of the data with visualization software. diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index f58017fc14..6190f0a30d 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -85,10 +85,10 @@ properties at a coarser-scale. The key motivation to such coarse-graining is to reduce the complexity of the description. On the one hand to support visualization and scientific analyses - not only of crystal defect arrangements. On the other hand it is the hope that using descriptors -at a coarser level, i.e. nanometer, micrometer, and larger, it is still possible -to find sufficiently accurate and precise descriptors which avoid that one has -to account for the dynamics of each atom to predict or understand the properties -of defects and their dynamics. +at a coarser level, i.e. nanometre, micrometre, and larger, it is still possible +to find sufficiently accurate and precise descriptors that avoid one having to account +for the dynamics of each atom to predict or understand the properties of defects +and their dynamics. Nevertheless, experience has shown that computational-geometry-based descriptions when combined with hierarchical clustering/labeling methods, applied on set of @@ -109,19 +109,19 @@ for frequently used shapes and geometric primitives are proposed: A description for a set of possibly dissimilar spheres. :ref:`NXcg_ellipsoid_set`: - A description for a set of possibly dissimilar rotated ellipsoids. + A description for a set of possibly dissimilar oriented ellipsoids. :ref:`NXcg_cylinder_set`: - A description for a set of possibly dissimilar rotated cylinders. + A description for a set of possibly dissimilar oriented cylinders. :ref:`NXcg_point_set`: - A collection of points with labels or mark data. + A collection of points with labels. :ref:`NXcg_polyline_set`: - A collection of lines and linearized segments. + A collection of lines and linear segments. :ref:`NXcg_triangle_set`: - A collection (or soup) of triangles. + A collection of triangles. :ref:`NXcg_parallelogram_set`: A collection of possibly dissimilar parallelograms. @@ -130,31 +130,32 @@ for frequently used shapes and geometric primitives are proposed: A mesh of triangles. :ref:`NXcg_polygon_set`: - A collection (or soup) of polygons. + A collection of polygons. :ref:`NXcg_polyhedron_set`: - A collection (or soup) of polyhedra. + A collection of polyhedra. :ref:`NXcg_roi_set`: A container to host a number of different types of primitives. :ref:`NXcg_tetrahedron_set`: - A collection (or soup) of tetrahedra. + A collection of tetrahedra. :ref:`NXcg_hexahedron_set`: - A collection (or soup) of hexahedra with capabilities to represent + A collection of hexahedra with capabilities to represent also simpler (bounding) boxes for e.g. binary trees. -These base classes make use of base classes which describe data structures: +These base classes describe data structures used for more complex geometries: :ref:`NXcg_face_list_data_structure`: In essence, the usual way how polygon/polyhedra data are reported: - Via a list of vertices and faces with identifier and properties. + A list of vertices and faces with identifier and properties. :ref:`NXcg_half_edge_data_structure`: - A half-edge data structure is a useful complementary descriptor for - polygon/polyhedra which enables topological analyses and traversal - of the graph how polygons and polyhedra can alternatively be described. + A half-edge data structure (also known as a doubly connected edge list) + is a useful complementary descriptor for polygon/polyhedra which enables + topological analyses and traversal of the graph of how polygons and + polyhedra are connected. :ref:`NXcg_unit_normal_set`: As an additional structuring element especially for meshes, well-documented @@ -169,9 +170,8 @@ These base classes make use of base classes which describe data structures: convex hull, are frequently used geometrical models for describing a boundary or edge to a set of geometric primitives. -Furthermore, a few base classes are defined for documenting the working with -discretized representations of material (area or volume) which can be useful -not only for stencil-based methods: +Next, a few base classes are defined for documenting discretized representations +of material (area or volume) which can be useful not only for stencil-based methods: :ref:`NXcg_grid`: A grid of cells. @@ -182,24 +182,23 @@ not only for stencil-based methods: :ref:`NXcg_marching_cubes`: An approach to store metadata of a specific implementation of the Marching Cubes algorithm, whose sensitivity to specific topological - configurations is known to result in different triangle soups. + configurations is known to result in different triangle collections. :ref:`NXdelocalization`: An approach to document procedures whereby a scalar field - is smoothened in a controlled manner. + is smoothed in a controlled manner. :ref:`NXsimilarity_grouping`: - An alias for NXclustering. + An alternative for NXclustering. :ref:`NXclustering`: A description for clustering of objects (such as atoms or features). :ref:`NXorientation_set`: - A set of rotations to describe the relative orientation of members of a set of features/objects. + A set of parameters to describe the relative orientation of members of a set of features/objects. :ref:`NXslip_system_set`: - Metadata to a set of slip system/slip system family for - a given crystal structure. + Metadata for a set of slip systems in a given crystal structure. :ref:`NXms_feature_set`: Generic base class to describe any nested set of features diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index ab45ab4b54..6f011c62fa 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -8,7 +8,6 @@ Electron microscopy IntroductionEm EmAppDef EmBC - EmPartnerClasses .. _IntroductionEm: @@ -113,13 +112,10 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXstage_lab`: As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. - -.. _EmPartnerClasses: - Method-specific concepts and their usage in application definitions ################################################################### -It became clear during the design of the electron microscopy specific additions to NeXus that there are sets of pieces of information (data and metadata) which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow of processing these data into knowledge, motivating the granularization of these pieces of information in their own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that (diffraction) patterns are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. through post-processing these data. These numerical and algorithmic steps define computational workflows where data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints would demand having their own but almost similar application definition. For this reason, the concept of method-specific concepts which have fields/links where specifically relevant sources of information are connected to them e.g. NXem. +It became clear during the design of the electron-microscopy-specific additions to NeXus that there are sets of pieces of information (data and metadata) which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow of processing these data into knowledge, motivating the granularization of these pieces of information in their own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that (diffraction) patterns are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. through post-processing these data. These numerical and algorithmic steps define computational workflows where data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints would demand having their own but almost similar application definition. For this reason, we propose to define the following base classes: More consolidation through the use of NXsubentry classes should be considered in the future. diff --git a/manual/source/classes/contributed_definitions/transport-structure.rst b/manual/source/classes/contributed_definitions/transport-structure.rst index 8238b52196..6aaf6844e5 100644 --- a/manual/source/classes/contributed_definitions/transport-structure.rst +++ b/manual/source/classes/contributed_definitions/transport-structure.rst @@ -20,7 +20,13 @@ Introduction Application Definitions ####################### -Work on handshaking between EPICS-controlled experiments and NeXus resulted in one application definition for temperature dependent IV curve measurements. +We realize that many experiments in condensed-matter physics and materials engineering belong to the category +of measurements of transparent phenomena. A possible example of such experiments are temperature-dependent +current-voltage (IV) curve measurements (or JV for engineers) measurements. In this case, electrical charge is transported +and the temperature-dependent current response as a function of applied voltage is recorded. + +Below is an example for such an application definition for an experiment. This application definition has exemplar parts +which show how such an experiment can be controlled with the `EPICS system `_: :ref:`NXiv_temp`: - Application definition for temperature dependent IV curve measurements. + Application definition for temperature-dependent current-voltage (IV) curve measurements. From f973995191548540dddcfe30381370d43aa67205 Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 16 Jan 2024 14:51:38 +0100 Subject: [PATCH 202/203] Adds provenance information --- contributed_definitions/NXdispersive_material.nxdl.xml | 9 +++++++++ .../contributed_definitions/ellipsometry-structure.rst | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index 452c384824..9748c78c4b 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -46,6 +46,15 @@ + + Name of the program used for creating this dispersion + + + Version of the program used + + + Date and time of creating this dispersion. + diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index cb690fac4f..1f3ddbfafc 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -57,7 +57,7 @@ This is the set of base classes for describing an optical experiment. Description of an optical lens. :ref:`NXpolarizer_opt` - A spin polarizer. + An optical polarizer. :ref:`NXwaveplate` A waveplate or retarder. From 6cf8e565fc4a4656e9fbffc0d5ea517b5e3b85ab Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 16 Jan 2024 14:52:43 +0100 Subject: [PATCH 203/203] Make provenance fields recommended --- contributed_definitions/NXdispersive_material.nxdl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index 9748c78c4b..7efc959b9d 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -46,13 +46,13 @@ - + Name of the program used for creating this dispersion - + Version of the program used - + Date and time of creating this dispersion.

yZj4a z+&Sp*Aa2!ph6crB)@h1>vb*{8)k7m%G`F~$i&PBD)HnyI}%JeO1C57J8z zf%F1G^LT$~hhee=afXy$sk0e_`V&n+rBL9L58F)-RKkI5ye^aL;O3lNaD*=`{MTa1 z1urur5Wm4nuY>57V5$;lhLnc!r3MaG;ouK3!!L~jjyckxN#)?Uy%`Q%({eOMJr8(h zZWm`(H;Nwh>n1FN;Bd5RNxgAoQXlG_unHUo9K$Y!0_#wdQ6E}Wd1^488HuL1AOg#R zev@GrwWMqA@CWK`NVk6O1q_NbMFD>AEkem1_GJu#gz65BERwn<5I0 OdyC(8-{OtzqyGX}z-~YQ literal 0 HcmV?d00001 diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst new file mode 100644 index 0000000000..fc2d4c428b --- /dev/null +++ b/manual/source/mpes-structure.rst @@ -0,0 +1,111 @@ +.. _Mpes-Structure: + +======================= +MPES Structure +======================= + +.. index:: + IntroductionMPES + NewAppDef + NewBC + NewCommonBC + ExtendedBC + + +.. _IntroductionMPES: + +Introduction +############## + +Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), +hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) +and photoemission electron microscopy (PEEM). We also included descriptors for advanced specializations, such as spin-resolution, time resolution, +near-ambient pressure conditions, dichroism etc. + +.. _NewAppDef: + +New Application Definitions +############################ + +We created two new application definitions: + + :ref:`NXmpes`: + A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. + + :ref:`NXmpes_ARPES`: + A specialized appdef with metadata parameters to describe all ARPES experiments. + +.. _NewBC: + +New Base Classes +################# + +We developed entirely new base classes: + + :ref:`NXelectronanalyser`: + A base class to describe electron kinetic energy analizers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following subclasses: + + :ref:`NXcollectioncolumn`: + Base class to describe the set of electronic lenses in the electron collection column (standard, PEEM, momentum-microscope, etc.). + + :ref:`NXenergydispersion`: + Base class to describe the energy dispersion sytem (hemispherical, time-of-flight, etc.). + + :ref:`NXspindispersion`: + Base class to describe the set of electronic lenses in the electron collection column. + + :ref:`NXmanipulator`: + A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, + cryogenic cooling and other advanced features. + +We developed three base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: + + :ref:`NXcalibration`: + A base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. + + :ref:`NXdistortion`: + A base class to describe the 2D distortion correction of an axis, with a matrix mapping a raw data image to a undistorted image. + + :ref:`NXregistration`: + A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. + +.. _NewCommonBC: + +New Common Base Classes +####################### + +We developed two classes that are common to other techniques: + + :ref:`NXlens`: + A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. + + :ref:`NXdeflector` + A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. + +.. _ExtendedBC: + +Extended Base Classes +####################### + +We added descriptors to existing NeXus base classes: + + :ref:`NXaperture` + Added fileds to describe analyser apertures and slits. + + :ref:`NXbeam` + Adedd fields to describe utrafast laser beams. + + :ref:`NXdetector` + Added fields to describe electron detectors (MCP+Phospor screen, delay lines etc.). + + :ref:`NXentry` + Added fields to describe an experiment. + + :ref:`NXprocess` + Added subclasses and collective processing descriptors. + + :ref:`NXsample` + Added descriptors specific to photoemission experiments. + + :ref:`NXsource` + Added descriptors for laboratory sources (X-ray, UV lamps) but mostly for ultrafat lasers with complex time structures. diff --git a/manual/source/nexus-index.rst b/manual/source/nexus-index.rst new file mode 100644 index 0000000000..1e9bf529ac --- /dev/null +++ b/manual/source/nexus-index.rst @@ -0,0 +1,20 @@ +.. _NexusIndex: + +======================================= +NeXus Documentation +======================================= + +Welcome to the user manual of the NeXus. + +https://www.nexusformat.org/ + +.. toctree:: + :maxdepth: 2 + + user_manual + examples/index + ref_doc + community + installation + utilities + docs_about \ No newline at end of file diff --git a/manual/source/sed/entry-page.html b/manual/source/sed/entry-page.html new file mode 100644 index 0000000000..b7c84946c2 --- /dev/null +++ b/manual/source/sed/entry-page.html @@ -0,0 +1,6 @@ + + + + + + \ No newline at end of file diff --git a/manual/source/sed/landing-page.rst b/manual/source/sed/landing-page.rst new file mode 100644 index 0000000000..ae13e6a5a3 --- /dev/null +++ b/manual/source/sed/landing-page.rst @@ -0,0 +1,58 @@ +======================================= +User Manual and Reference Documentation +======================================= + +Welcome to the user manual of the NeXus for FAIRmat project. + +https://www.nexusformat.org/ + +.. toctree:: + :maxdepth: 2 + + fairmat-cover + nexus-index + mpes-structure + ellipsometry-structure + em-structure + apm-structure + + +----------- + +.. rubric:: Publishing Information + +| This commit time code <>. +| This commit identifier <>. +| This manual built |today|. + + +.. seealso:: + + The extended NeXus documentation: + + :HTML: + https://manual.nexusformat.org/ + + :PDF: + https://manual.nexusformat.org/pdf/NeXusManual.pdf + + A very brief overview (title: *NeXus for the Impatient*) + is also available (separate from the manual). + + :HTML: + https://manual.nexusformat.org/impatient/ + + :PDF: + https://manual.nexusformat.org/pdf/NXImpatient.pdf + + FAIRmat website: + + ``_ + + NOMAD website: + + ``_ + + + + From d122a69ce0c953805e60a662e9580ee2c4a6fae7 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Tue, 1 Mar 2022 12:12:37 +0100 Subject: [PATCH 017/203] Fixed ellipsometry, appdefs and makefile --- Makefile | 23 ++++----- applications/NXellipsometry.nxdl.xml | 23 +++------ base_classes/NXscanbox_em.nxdl.xml | 3 +- manual/source/apm-structure.rst | 4 +- manual/source/classes/applications/index.rst | 6 ++- manual/source/classes/base_classes/index.rst | 18 ++++++- .../classes/contributed_definitions/index.rst | 2 +- manual/source/ellipsometry-structure.rst | 10 ++-- manual/source/em-structure.rst | 18 +++---- manual/source/fairmat-cover.rst | 19 ++++---- manual/source/index.rst | 48 ++++++++++--------- 11 files changed, 93 insertions(+), 81 deletions(-) diff --git a/Makefile b/Makefile index edf95ec5a4..a101de541f 100644 --- a/Makefile +++ b/Makefile @@ -18,18 +18,19 @@ manual :: nxdl2rst $(MAKE) html -C $@ all :: - $(MAKE) rmbuilddir builddir - $(MAKE) impatient-guide manual -C build - # expect next make (PDF) to fail (thus exit 0) since nexus.ind not found first time - # extra option needed to satisfy "levels nested too deeply" error - ($(MAKE) latexpdf LATEXOPTS="--interaction=nonstopmode" -C build/manual || exit 0) - # make that missing file - makeindex build/manual/build/latex/nexus.idx - # build the PDF, still a failure will be noted but we can ignore it without problem - ($(MAKE) latexpdf LATEXOPTS="--interaction=nonstopmode" -C build/manual || exit 0) - # finally, report what was built +# $(MAKE) rmbuilddir builddir + $(MAKE) impatient-guide manual +# -C build +# # expect next make (PDF) to fail (thus exit 0) since nexus.ind not found first time +# # extra option needed to satisfy "levels nested too deeply" error +# ($(MAKE) latexpdf LATEXOPTS="--interaction=nonstopmode" -C build/manual || exit 0) +# # make that missing file +# makeindex build/manual/build/latex/nexus.idx +# # build the PDF, still a failure will be noted but we can ignore it without problem +# ($(MAKE) latexpdf LATEXOPTS="--interaction=nonstopmode" -C build/manual || exit 0) +# # finally, report what was built @echo "HTML built: `ls -lAFgh build/manual/build/html/index.html`" - @echo "PDF built: `ls -lAFgh build/manual/build/latex/nexus.pdf`" +# @echo "PDF built: `ls -lAFgh build/manual/build/latex/nexus.pdf`" impatient-guide :: $(MAKE) html -C $@ diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml index 62465fb2a6..2d40762da9 100644 --- a/applications/NXellipsometry.nxdl.xml +++ b/applications/NXellipsometry.nxdl.xml @@ -8,7 +8,7 @@ Size of the energy / wavelength vector used - How many variables are saved in a measurement (e.g. Psi and Delta, Mueller matrix) + How many variables are saved in a measurement (e.g. Psi and Delta, Mueller matrix. Number of incident angles used @@ -21,9 +21,7 @@ - This is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. - -The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description + "This is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description" An application definition for ellipsometry. @@ -150,8 +148,7 @@ The application definition defines: - elements of the experimental instrument - - The wavelength or equivalent values (which are inter-convertible). The importer should convert all to one unit, and make the others accessible. Historically, energy is used in eV, but for visible spectroscopy wavelength is more common, for IR wave numbers in 1/cm units. -Possibly use the same type of data as for the measurement! + The wavelength or equivalent values (which are inter-convertible). The importer should convert all to one unit, and make the others accessible. Historically, energy is used in eV, but for visible spectroscopy wavelength is more common, for IR wave numbers in 1/cm units. Possibly use the same type of data as for the measurement! @@ -186,10 +183,7 @@ Possibly use the same type of data as for the measurement! - The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). -This transformation brings us from the NEXUS coordinates to the stage coordinates. -Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) -Last, provide the rotations of the sample + The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). This transformation brings us from the NEXUS coordinates to the stage coordinates. Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) Last, provide the rotations of the sample If there is no motorized stage, we should at least qualify where the beam hits the sample and in what direction the sample stands in a free-text description, e.g. 'center of sample, long edge parallel to plane of incidence'. @@ -300,15 +294,13 @@ Last, provide the rotations of the sample - Wavelength value(s) used for the measurement. - An array of 1 or more elements. Length defines N_wavelength + Wavelength value(s) used for the measurement. An array of 1 or more elements. Length defines N_wavelength - Resulting data from the measurement, described by data type. - Minimum two columns containing Psi and delta, or for the normalized Mueller matrix, it may be 16 (or 15 if 1,1 is all 1). + Resulting data from the measurement, described by data type. Minimum two columns containing Psi and delta, or for the normalized Mueller matrix, it may be 16 (or 15 if 1,1 is all 1). @@ -362,8 +354,7 @@ Last, provide the rotations of the sample Specify the source for the external excitation - Wavelength value(s) or the range used for excitation. - In cases of continuous laser radiation a value or a set of values may do but for other illumination types, such as pulsed lasers, or lamps, a range may describe the source better. + Wavelength value(s) or the range used for excitation. In cases of continuous laser radiation a value or a set of values may do but for other illumination types, such as pulsed lasers, or lamps, a range may describe the source better. Specify the FWHM of the excitation diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml index 0a6b374c5a..ca571fc4d1 100644 --- a/base_classes/NXscanbox_em.nxdl.xml +++ b/base_classes/NXscanbox_em.nxdl.xml @@ -1,14 +1,13 @@ - Class for describing the scan box of an electron microscope. + Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. - Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. Commercial or otherwise given name to the program which was used to execute this analysis. diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 5376b6d4bb..f448de8fc8 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -1,8 +1,8 @@ .. _Apm-Structure: -======================================== +================================= Atom Probe Microscopy Structure -======================================== +================================= .. index:: IntroductionAPM diff --git a/manual/source/classes/applications/index.rst b/manual/source/classes/applications/index.rst index 40a7034d5b..ec1cdad251 100644 --- a/manual/source/classes/applications/index.rst +++ b/manual/source/classes/applications/index.rst @@ -1,6 +1,6 @@ .. do NOT edit this file - automatically generated by script /home/mkuehbach/SPRINT06-GITPAGES-TOMMASO/definitions/manual/source/classes/applications/../../../../utils/nxdl_summary.py + automatically generated by script /home/mkuehbach/XXXX/nexus_definitions/manual/source/classes/applications/../../../../utils/nxdl_summary.py .. index:: @@ -45,6 +45,9 @@ from the location(s) defined in the relevant application definition. :ref:`NXdirecttof` This is a application definition for raw data from a direct geometry TOF spectrometer +:ref:`NXellipsometry` + Draft application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. In this application definition, times should be specified always together with a UTC offset. + :ref:`NXem_nion` Template for creating draft application definitions for storing data and metadata for experiments with scanning transmission electron microscopy with a Nion instrument. @@ -152,6 +155,7 @@ from the location(s) defined in the relevant application definition. NXarpes NXcanSAS NXdirecttof + NXellipsometry NXem_nion NXfluo NXindirecttof diff --git a/manual/source/classes/base_classes/index.rst b/manual/source/classes/base_classes/index.rst index 7840e46345..91436712a7 100644 --- a/manual/source/classes/base_classes/index.rst +++ b/manual/source/classes/base_classes/index.rst @@ -1,6 +1,6 @@ .. do NOT edit this file - automatically generated by script /home/mkuehbach/SPRINT06-GITPAGES-TOMMASO/definitions/manual/source/classes/base_classes/../../../../utils/nxdl_summary.py + automatically generated by script /home/mkuehbach/XXXX/nexus_definitions/manual/source/classes/base_classes/../../../../utils/nxdl_summary.py .. index:: @@ -52,6 +52,9 @@ that are used to construct a data file. :ref:`NXcollimator` A beamline collimator. +:ref:`NXcorrector_cs` + Draft of a base class for a device in a (transmission) electron microscope which corrects for spherical aberrations. The device consists of multiple NXlens_em instances and other components. + :ref:`NXcrystal` A crystal monochromator or analyzer. @@ -97,6 +100,9 @@ that are used to construct a data file. :ref:`NXfermi_chopper` A Fermi chopper, possibly with curved slits. +:ref:`NXfib` + Draft of a base class for describing focused-ion beam capabilities of an instrument. The class is designed to be used as an additional component of e.g. an electron microscope to describe sample/specimen preparation and the collecting of data and metadata for (scanning) electron microscope/focused-ion beam, (S)EM/FIB instruments. + :ref:`NXfilter` For band pass beam filters. @@ -169,6 +175,9 @@ that are used to construct a data file. :ref:`NXpdb` A NeXus transliteration of a PDB file, to be validated only as a PDB +:ref:`NXpeak` + Proposal for storing mathematical models of peaks, their functional form or at least their measured support. + :ref:`NXpinhole` A simple pinhole. @@ -199,6 +208,9 @@ that are used to construct a data file. :ref:`NXsample_component` One group like this per component can be recorded For a sample consisting of multiple components. +:ref:`NXscanbox_em` + Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. + :ref:`NXsensor` A sensor used to monitor an external condition @@ -249,6 +261,7 @@ that are used to construct a data file. NXcollection NXcollectioncolumn NXcollimator + NXcorrector_cs NXcrystal NXcylindrical_geometry NXdata @@ -264,6 +277,7 @@ that are used to construct a data file. NXenvironment NXevent_data NXfermi_chopper + NXfib NXfilter NXflipper NXfresnel_zone_plate @@ -288,6 +302,7 @@ that are used to construct a data file. NXorientation NXparameters NXpdb + NXpeak NXpinhole NXpolarizer NXpositioner @@ -298,6 +313,7 @@ that are used to construct a data file. NXroot NXsample NXsample_component + NXscanbox_em NXsensor NXshape NXslit diff --git a/manual/source/classes/contributed_definitions/index.rst b/manual/source/classes/contributed_definitions/index.rst index ca7bd979fe..ee98bcac65 100644 --- a/manual/source/classes/contributed_definitions/index.rst +++ b/manual/source/classes/contributed_definitions/index.rst @@ -1,6 +1,6 @@ .. do NOT edit this file - automatically generated by script /home/mkuehbach/SPRINT06-GITPAGES-TOMMASO/definitions/manual/source/classes/contributed_definitions/../../../../utils/nxdl_summary.py + automatically generated by script /home/mkuehbach/XXXX/nexus_definitions/manual/source/classes/contributed_definitions/../../../../utils/nxdl_summary.py .. index:: diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst index c40326e189..e099ce7be3 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/ellipsometry-structure.rst @@ -6,8 +6,8 @@ Ellipsometry Structure .. index:: IntroductionEllipsometry - NewAppDef - ExtendedBC + EllNewAppDef + EllExtendedBC .. _IntroductionEllipsometry: @@ -19,7 +19,7 @@ Ellipsometry is an optical characterization method to describe optical propertie In the application definition we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. -.. _NewAppDef: +.. _EllNewAppDef: New Application Definitions ############################ @@ -31,8 +31,8 @@ We created one application definition: .. .. _NewBC: -.. New Base Classes -.. ################# +.. EllNew Base Classes +.. #################### .. We developed entirely new base classes: diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index ab773ebc6d..3350f69d43 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -1,14 +1,14 @@ .. _Em-Structure: -======================= -Electron Microscopy (EM) Structure -======================= +================================== +Electron Microscopy Structure +================================== .. index:: IntroductionEM - NewAppDef - NewBC - NewCommonBC + EmNewAppDef + EmNewBC + EmNewCommonBC @@ -21,7 +21,7 @@ Set of data storage objects to describe components of an electron microscope and Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with those classical instrument control and data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software, which makes it additionally difficult to keep track of workflows and identify what conceptually the specific quantities in the control software display represent and how these can be connected to the development of ontologies for electron microscopy experiments. -.. _NewAppDef: +.. _EmNewAppDef: New Application Definitions ############################ @@ -31,7 +31,7 @@ We acknowledge that it can be difficult to agree on a single application definit :ref:`NXem_nion`: A general application definition which explores the possibilities of scanning transmission electron microscopes that use an open instrument control and analysis software. Specifically, we draft the application for users of Nion microscopes. An extension to supporting multi-signal sources is currently explored and will be implemented with the next release of the application definition. -.. _NewBC: +.. _EmNewBC: New Base Classes ################# @@ -53,7 +53,7 @@ We developed entirely new base classes: :ref:`NXstage_lab`: As it was mentioned for atom probe microscopy this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. -.. _NewCommonBC: +.. _EmNewCommonBC: New Common Base Classes ####################### diff --git a/manual/source/fairmat-cover.rst b/manual/source/fairmat-cover.rst index c625a2c6fe..86a2199cf1 100644 --- a/manual/source/fairmat-cover.rst +++ b/manual/source/fairmat-cover.rst @@ -24,11 +24,11 @@ Experimentalists face the challenge that these pieces of information come at dif of granularity and format, of which many need to be better documented. You have very likely experienced yourself how file and data formats are routinely encountered tasks to master in your daily research practice and you might have questioned how these formats are currently handled -when you want to produce FAIR research data and publications. +when you want to produce FAIR research data and publications. The NeXus-FAIRmat proposal is an interdisciplinary data science activity initiated by scientists of the condensed-matter physics community which strives to develop community-maintained open file and data formats - for describing specific experimental techniques, their numerical data and metadata, +for describing specific experimental techniques, their numerical data and metadata, and strategies how to exchange these pieces of information. .. _IntroductionCover: @@ -164,14 +164,14 @@ for the following macro-areas of experimental physics :ref:`NXsource` :ref:`Ellipsometry `: - Set of data storage objects to describe .. Carola, Tamas. + Set of data storage objects to describe ellipsometry, follow the link for a more extensive description. New application definitions: :ref:`NXellipsometry` - New base classes: - Extended base classes: + .. New base classes: + .. Extended base classes: :ref:`Electron Microscopy `: - Set of data storage objects to describe electron microscopy experiments, follow the link for a more extensive description. + Set of data storage objects to describe electron microscopy experiments, follow the link for a more extensive description. New application definitions: :ref:`NXem_nion` New base classes: @@ -180,10 +180,10 @@ for the following macro-areas of experimental physics :ref:`NXlens_em` :ref:`NXscanbox_em` :ref:`NXstage_lab` - Extended base classes: + .. Extended base classes: :ref:`Atom Probe Microscopy `: - Set of data storage objects to describe atom probe tomography and field-ion microscopy experiments, follow the link for a more extensive description. + Set of data storage objects to describe atom probe tomography and field-ion microscopy experiments, follow the link for a more extensive description. New application definitions: :ref:`NXapm` New base classes: @@ -192,6 +192,5 @@ for the following macro-areas of experimental physics :ref:`NXpeak` :ref:`NXpulser_apm` :ref:`NXstage_lab` - Extended base classes: - + .. Extended base classes: diff --git a/manual/source/index.rst b/manual/source/index.rst index 27daa651d5..ae13e6a5a3 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -1,35 +1,34 @@ -.. image:: img/NeXus.png - :width: 40% - ======================================= User Manual and Reference Documentation ======================================= +Welcome to the user manual of the NeXus for FAIRmat project. + https://www.nexusformat.org/ .. toctree:: :maxdepth: 2 - :numbered: 4 - - user_manual - examples/index - ref_doc - napi - community - installation - utilities - history - docs_about + + fairmat-cover + nexus-index + mpes-structure + ellipsometry-structure + em-structure + apm-structure + ----------- .. rubric:: Publishing Information -This manual built |today|. +| This commit time code <>. +| This commit identifier <>. +| This manual built |today|. + .. seealso:: - This document is available in these formats online: + The extended NeXus documentation: :HTML: https://manual.nexusformat.org/ @@ -46,11 +45,14 @@ This manual built |today|. :PDF: https://manual.nexusformat.org/pdf/NXImpatient.pdf -.. Suggestions for adding to this manual: + FAIRmat website: + + ``_ + + NOMAD website: + + ``_ + + + - Look for some other "section" such as "introduction.rst" and act similarly. - Any examples go as text files in the examples/ subdirectory and are pulled into - Sphinx inside a :directive:`literalcode` directive. Look for the pattern - or wing it. If you are ambitious, add index entries. Many examples of the - constructs you might use are already in the manual. - From 1d46b94dc36a42225ad247cc763277a47dcd30d4 Mon Sep 17 00:00:00 2001 From: Laurenz Rettig Date: Tue, 22 Mar 2022 22:43:11 +0100 Subject: [PATCH 018/203] updates to NXmpes and related base classes, including manually merged extentions to existing base classes --- applications/NXmpes.nxdl.xml | 481 ++++++++++++----------- base_classes/NXaperture.nxdl.xml | 6 + base_classes/NXbeam.nxdl.xml | 65 ++- base_classes/NXcalibration.nxdl.xml | 19 +- base_classes/NXcollectioncolumn.nxdl.xml | 10 +- base_classes/NXdetector.nxdl.xml | 30 ++ base_classes/NXdistortion.nxdl.xml | 35 +- base_classes/NXelectronanalyser.nxdl.xml | 12 +- base_classes/NXentry.nxdl.xml | 20 +- base_classes/NXlens.nxdl.xml | 2 +- base_classes/NXmanipulator.nxdl.xml | 18 +- base_classes/NXprocess.nxdl.xml | 9 + base_classes/NXsample.nxdl.xml | 51 +++ base_classes/NXsource.nxdl.xml | 24 ++ 14 files changed, 511 insertions(+), 271 deletions(-) diff --git a/applications/NXmpes.nxdl.xml b/applications/NXmpes.nxdl.xml index 0744cc478b..cabf2a37ec 100644 --- a/applications/NXmpes.nxdl.xml +++ b/applications/NXmpes.nxdl.xml @@ -1,233 +1,248 @@ - - - - This is the most general application definition for multidimensional photoelectron spectroscopy. - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - - - - - Title describing the entry. - - - ISO8601 formatted date time of the start of the measurement. - - - Official NeXus NXDL schema to which this file conforms. - - - - - Version specifier enabling to document modification of the schema. - - - - - - Type of source. Any of these values: - Synchrotron X-ray Source - Rotating Anode X-ray - Fixed Tube X-ray - UV Laser - Free-Electron Laser - Optical Laser - UV Plasma Source - Metal Jet X-ray - - - - - - - - - - - - - Free text name of the source. - - - Type of probe. In photoemission it's always photons, any of these values: - x-ray - ultraviolet - visible light - - - - - - - - - Properties of the beam at the sample. - - Distance of the point of evaluation of the beam from the sample. - - - Incident photon energy. - - - FWHM energy linewidth of the incident photons. - - - Incident polarization specified as a Stokes vector. - - - - - - - - Free text description of the type of detector. - - - Energy resolution of the analyser with the current setting. - - - List of the axes that are acquired symultaneously by the detector. - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. - - - - - - - Scheme of the electron collection column. - - - - - - - - - Labelling of the lens setting in use. - - - The space projected in the angularly dispersive directions, i.e. real or reciprocal. - - - - - - - - - Energy dispersion scheme employed. - - - - - - - - - - energy of the electrons on the mean path of the analyser. - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - - Type of electron amplifier. - - - - - - - Description of the detector type. - - - - - - - - - - - - - - Calibrated energy axis - - - - - - - Has an energy calibration been applied? - - - - - - Simple and descriptive name of the sample. - - - Chemical formula of the sample. - - - Ideally, a reference to the location or a unique identifier or other metadata file. In the case that is not available, free-text description. - - - ISO 8601 date of preparation of the sample for the ARPES experiment (i.e. cleaving, last annealing). - - - Free-text surface preparation technique for the ARPES experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. - - - Temperature of the sample. - - - - Residual gas pressure at the sample. - - - - - Processed plottable data. - - - - + + + + + Most general application definition for multidimensional photoelectron spectroscopy. + + It can be used for ARPES, XPS, etc. More specialized application definitions are derived from it. + + The symbols used in the schema to specify e.g. dimensions of arrays + + Number of fast axes (acquired simutaneously) e.g. emission angle, kinetic energy + + + Number of slow axes (acquired scanning a physical quantity) e.g. lens voltage, spin direction + + + + + NeXus convention is to use "entry1", "entry2", for analysis software to locate each entry. + + + Default plottable NX data object. + + + + ISO8601 formatted date time of the start of the measurement. + + + + + + + + + + The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + In the case of a monchromatic beam this is the scalar energy. Several other use cases are permitted, depending on the presence of other incident_energy_X fields. In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. Here, incident_energy_weights and incident_energy_spread are not set. In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_energy_weights as a 2D array. In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + + + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in the energy spread, this is a 2D array of dimension nP by m (slow to fast) of the spreads of the corresponding energy in incident_energy. + + + In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding energies in incident_energy. In the case of a polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np by m (slow to fast) of the relative weights of the corresponding energies in incident_energy. + + + Incident polarization specified as a Stokes vector. + + The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: 'farad' for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. Here: SI units are 'V2/m2'. + + + + + + + + + Free text description of the type of detector. + + + Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. + + + List of the axes that are acquired symultaneously by the detector. These refer only to the experimental variables recorded by the electron analyser. Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. Examples: Hemispherical in ARPES mode: fast_axes: [energy,kx] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] Tof: fast_axes: [energy, kx, ky] Momentum microscope, spin-resolved: fast_axes: [energy, kx, ky] slow_axes: [spin up-down, spin left-right] axes can be less abstract than this, i.e. [detector_x, detector_y] If energy_scan_mode=sweep, fast_axes: [energy, kx]; slow_axes: [energy] is allowed. + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples. + + + + + + + Scheme of the electron collection column. + + + + + + + + + Labelling of the lens setting in use. + + + The space projected in the angularly dispersive directions, i.e. real or reciprocal. + + + + + + + + + Energy dispersion scheme employed. + + + + + + + + + + + energy of the electrons on the mean path of the analyser. Pass energy for hemispherics, drift energy for tofs. + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + Aperture generating the momentum and/or energy filtering. + + Type of aperture inserted in the beam. + + + + + + + + Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc. + + + + + + + + + + + + The relevant dimension for the aperture (slit width, pinhole diameter etc). + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Calibrated energy axis. + + + + + + + Has an energy calibration been applied? + + + + + + + + A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. Ideally, a full report of the previous operations, in any format (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. + + + ISO 8601 date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). + + + Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report of the previous operations, in any format(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. + + + In the case of a fixed temperature measurement this is the scalar temperature of the sample. In the case of an experiment in which the temperature is changed and recoded, this is an array of length m of temperatures. + + + + In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures. + + + + + + + + + + Processed plottable data. + + + + diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index d6fd308a50..c90dd7fdd1 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -52,6 +52,12 @@ Description of aperture + + Shape of the aperture, i.e. straight or curved for slits, circle, square hexagon, octagon, bladed for pinholes and irises. + + + The relevant dimension for the aperture, i.e. slit width, pinhole and iris diameter + describe any additional information in a note* diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 11ff397bb2..82482c2164 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -37,15 +37,27 @@ to specify the beam profile, time distribution etc. at each beamline component. Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron scattering by the sample, e.g., energy transfer, polarizations. + + The symbols used in the schema to specify e.g. dimensions of arrays + + Number of pixels of the frequency axis of a FROG trace + + Distance from sample - Energy on entering beamline component + In the case of a monchromatic beam this is the scalar energy. Several other use cases are permitted, depending on the presence of other incident_energy_X fields. In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. Here, incident_energy_weights and incident_energy_spread are not set. In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_energy_weights as a 2D array. In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + + The wavelength spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in the energy spread, this is a 2D array of dimension nP by m (slow to fast) of the spreads of the corresponding wavelength in incident_wavelength. + + + In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding energies in incident_energy. In the case of a polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np by m (slow to fast) of the relative weights of the corresponding energies in incident_energy. + Energy on leaving beamline component @@ -59,7 +71,7 @@ - Wavelength on entering beamline component + In the case of a monchromatic beam this is the scalar wavelength. Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. In the case of a polychromatic beam this is an array of length m of wavelengths, with the relative weights in incident_wavelength_weights. In the case of a monochromatic beam that varies shot-to-shot, this is an array of wavelengths, one for each recorded shot. Here, incident_wavelength_weights and incident_wavelength_spread are not set. In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value wavelength value is available along with the original spectrum from which it was calibrated. @@ -91,11 +103,13 @@ - Polarization vector on entering beamline component - - - + Incident polarization as a Stokes vector + + + + The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using ''NX_ANY''. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: ''T'' for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: ''farad'' for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) ''1/(s.mm2.mrad2)''. Here: SI units are ''V2/m2''. + Polarization vector on leaving beamline component @@ -123,6 +137,45 @@ + + Energy of a single pulse at the diagnostic point + + + Average power at the diagnostic point + + + Incident fluence at the diagnostic point + + Here: SI units are ''J/m2'', customary ''mJ/cm2''. + + + + FWHM duration of the pulses at the diagnostic point + + + FROG trace of the pulse. + + + + + + Horizontal axis of a FROG trace, i.e. delay. + + + + + + Vertical axis of a FROG trace, i.e. frequency. + + + + + + The type of chirp implemented + + + Group delay dispersion of the pulse for linear chirp + Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml index 437fd90bce..a70c0ca630 100644 --- a/base_classes/NXcalibration.nxdl.xml +++ b/base_classes/NXcalibration.nxdl.xml @@ -4,9 +4,15 @@ Draft subclass of NXprocess to describe post-processing calibrations. 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 + Has the calibration been applied? @@ -32,10 +38,9 @@ - - 2 vectors, representing how the raw points get mapped on the calibrated axis. - - + + Vector containing the data coordinates in the original uncalibrated axis + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml index de5095c8a1..63fce0cd86 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/base_classes/NXcollectioncolumn.nxdl.xml @@ -4,7 +4,9 @@ Draft subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. The symbols used in the schema to specify e.g. dimensions of arrays - + + Number of lenses in the collection column + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum microscope, etc. @@ -42,10 +44,10 @@ The size and postion of the contrast aperture inserted in the column. - - deflectors in the collection column section + + Deflectors in the collection column section - + Individual lenses in the collection column section diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index 4ce4343bb1..1039bc8944 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -817,4 +817,34 @@ for a summary of the discussion. + + Type of electron amplifier, MCP, channeltron, etc. + + + Description of the detector type, DLD, Phosphor+CCD, CMOS. + + + Voltage applied to detector. + + + Voltage applied to the amplifier. + + + The low voltage of the amplifier migh not be the ground. + + + Size of each imaging sensor chip on the detector. + + + Number of imaging sensor chips on the detector. + + + Physical size of the pixels of the imaging chip on the detector. + + + Number of raw active elements in each dimension. Important for swept scans. + + + raw data output from the detector + diff --git a/base_classes/NXdistortion.nxdl.xml b/base_classes/NXdistortion.nxdl.xml index 4b7bcf97f1..62d393fd15 100644 --- a/base_classes/NXdistortion.nxdl.xml +++ b/base_classes/NXdistortion.nxdl.xml @@ -4,9 +4,15 @@ Draft subclass of NXprocess to describe post-processing distortion correction. The symbols used in the schema to specify e.g. dimensions of arrays - - - + + Number of symmetry points used for distortion correction + + + Number of points of the matrix distortion field (x direction) + + + Number of points of the matrix distortion field (y direction) + Has the distortion correction been applied? @@ -21,15 +27,24 @@ - For symmetry-guided distortion correction. Here we record coordinates of the relevant symmetry points. - - + For symmetry-guided distortion correction. Here we record the coordinates of the relevant symmetry points. + + + - - For general non-rigid distortion corrections. 2D matrix mapping the original distorted field in the undistorted one. - - + + Column deformation field for general non-rigid distortion corrections. 2D matrix holding the column information of the mapping of each original coordinate. + + + + + + + Row deformation field for general non-rigid distortion corrections. 2D matrix holding the row information of the mapping of each original coordinate. + + + diff --git a/base_classes/NXelectronanalyser.nxdl.xml b/base_classes/NXelectronanalyser.nxdl.xml index 08ade2d91c..20a233d95a 100644 --- a/base_classes/NXelectronanalyser.nxdl.xml +++ b/base_classes/NXelectronanalyser.nxdl.xml @@ -4,8 +4,12 @@ Draft subclass of NXinstrument to describe a photoelectron analyser. The symbols used in the schema to specify e.g. dimensions of arrays - - + + Number of fast axes (axes acquired symultaneously, without scanning a pysical quantity) + + + Number of slow axes (axes acquired scanning a pysical quantity) + Free text description of the type of the detector @@ -53,9 +57,9 @@ class to describe the electron detector - deflectors in the collection column section + Deflectors outside the main optics ensambles described by the subclasses - Individual lenses in the collection column section + Individual lenses outside the main optics ensambles described by the subclasses diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml index b235591b60..b82738c816 100644 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -190,7 +190,25 @@ which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. - + + + City and country where ex. Took place + + + Start date and time of ex. in ISO 8601 format, ideally including UTC offset. + + + Start date and time of ex. in ISO 8601 format, ideally including UTC offset. + + + Name of the institution hosting the facility + + + Name of the experimental facility + + + Name of the laboratory or beamline + Notes describing entry diff --git a/base_classes/NXlens.nxdl.xml b/base_classes/NXlens.nxdl.xml index 060ead8678..efa6162e45 100644 --- a/base_classes/NXlens.nxdl.xml +++ b/base_classes/NXlens.nxdl.xml @@ -18,7 +18,7 @@ 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. diff --git a/base_classes/NXmanipulator.nxdl.xml b/base_classes/NXmanipulator.nxdl.xml index e5061b10f3..4c276652b3 100644 --- a/base_classes/NXmanipulator.nxdl.xml +++ b/base_classes/NXmanipulator.nxdl.xml @@ -4,9 +4,15 @@ Draft extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. The symbols used in the schema to specify e.g. dimensions of arrays - - - + + Number of linear coordinates used to describe the manipulator position + + + Number of angular coordinates used to describe the manipulator position + + + Number of positions assumed by the manipulator during the measurement (differing even by just one coordinate or angle) + Name @@ -32,13 +38,15 @@ Effective positions assumed by the manipulator during the measurement. - + + Effective angles assumed by the manipulator during the measurement. - + + diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index 9e042e873e..b66a58cae9 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -43,6 +43,15 @@ Date and time of processing. + + Class to describe the operations of image registration + + + class to describe the operations of image distrortion correction + + + class to describe the operations of calibration + The note will contain information about how the data was processed diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 5f93cab22a..0db7283442 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -328,6 +328,57 @@ sample thickness + + Identification number or signatures of the sample used. + + + A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. Ideally, a full report of the previous operations, in any format (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 + + + Physical state of the sample + + + Chemical purity of the sample + + + Surface termination of the sample (if crystalline) + + + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + + + Full chemical name of the sample + + + CAS registry number of the sample chemical content. + + + Gases might be fluxed on the surface for various reasons. Chemical designation, or residual. + + + Element of evaporated surface dopant such as alkali or other + + + Nominal thickness of the evaporated dopant + + + Voltage applied to sample and sample holder. + + + Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition etc.) + + + Name of the sample vendor (company or research group) + + + Material of the substrate in direct contact with the sample. + + + Physical state of the substrate, similar options to sample_state + + + Further notes. + As a function of Wavelength diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index f612e28bd5..9572f77e96 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -27,6 +27,12 @@ name="NXsource" type="group" extends="NXobject"> The neutron or x-ray storage ring/facility. + + The symbols used in the schema to specify e.g. dimensions of arrays + + Number of points in a spectrum + + Effective distance from sample @@ -163,6 +169,24 @@ For storage rings, the current at the end of the most recent injection. date and time of the most recent injection. + + The center photon energy of the source, before it is monochromatized or converted + + + The center wavelength of the source, before it is monochromatized or converted + + + For pulsed sources, the energy of a single pulse + + + For pulsed sources, the pulse energy divided by the pulse duration + + + Some facilities tag each bunch. First bunch of the measurement + + + Last bunch of the measurement + "Engineering" location of source From f8bde29aad41dfd3cdfb82c8cbe67ec679f45b4f Mon Sep 17 00:00:00 2001 From: aalbino2 Date: Wed, 30 Mar 2022 11:03:40 +0200 Subject: [PATCH 019/203] __init__.py files added --- __init__.py | 0 applications/__init__.py | 0 base_classes/__init__.py | 0 contributed_definitions/__init__.py | 0 4 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 __init__.py create mode 100644 applications/__init__.py create mode 100644 base_classes/__init__.py create mode 100644 contributed_definitions/__init__.py diff --git a/__init__.py b/__init__.py new file mode 100644 index 0000000000..e69de29bb2 diff --git a/applications/__init__.py b/applications/__init__.py new file mode 100644 index 0000000000..e69de29bb2 diff --git a/base_classes/__init__.py b/base_classes/__init__.py new file mode 100644 index 0000000000..e69de29bb2 diff --git a/contributed_definitions/__init__.py b/contributed_definitions/__init__.py new file mode 100644 index 0000000000..e69de29bb2 From aa4914db2d92188f8336188f1d35cfdd36a788f8 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Thu, 31 Mar 2022 14:54:20 +0200 Subject: [PATCH 020/203] Moved all FAIRmat-related base and appdefs to contributed_defs, replaced NXellipsometry block selector for plain rich text, file ending yaml should be changed in the future, FAIRmat-related NXDLs were updated having now a single-line docstring --- applications/NXapm.nxdl.xml | 573 ----------- applications/NXem_nion.nxdl.xml | 380 ------- base_classes/NXcorrector_cs.nxdl.xml | 27 - base_classes/NXdeflector.nxdl.xml | 46 - base_classes/NXfib.nxdl.xml | 53 - base_classes/NXion.nxdl.xml | 32 - base_classes/NXlens_apm.nxdl.xml | 26 - base_classes/NXlens_em.nxdl.xml | 33 - base_classes/NXpeak.nxdl.xml | 35 - base_classes/NXpulser_apm.nxdl.xml | 70 -- base_classes/NXscanbox_em.nxdl.xml | 47 - base_classes/NXstage_lab.nxdl.xml | 41 - contributed_definitions/NXapm.nxdl.xml | 967 ++++++++++++++++++ .../NXcalibration.nxdl.xml | 0 contributed_definitions/NXchamber.nxdl.xml | 22 + .../NXcollectioncolumn.nxdl.xml | 0 .../NXcorrector_cs.nxdl.xml | 35 + .../NXdistortion.nxdl.xml | 0 .../NXelectronanalyser.nxdl.xml | 0 .../NXellipsometry.nxdl.xml | 85 +- contributed_definitions/NXem_nion.nxdl.xml | 577 +++++++++++ .../NXenergydispersion.nxdl.xml | 0 contributed_definitions/NXfib.nxdl.xml | 67 ++ contributed_definitions/NXion.nxdl.xml | 59 ++ .../NXlens.nxdl.xml | 0 contributed_definitions/NXlens_em.nxdl.xml | 44 + .../NXmanipulator.nxdl.xml | 0 .../NXmpes.nxdl.xml | 0 .../NXmpes_ARPES.nxdl.xml | 0 contributed_definitions/NXpeak.nxdl.xml | 45 + contributed_definitions/NXpulser_apm.nxdl.xml | 89 ++ contributed_definitions/NXpump.nxdl.xml | 15 + contributed_definitions/NXreflectron.nxdl.xml | 31 + .../NXregistration.nxdl.xml | 0 contributed_definitions/NXscanbox_em.nxdl.xml | 64 ++ .../NXspindispersion.nxdl.xml | 0 contributed_definitions/NXstage_lab.nxdl.xml | 87 ++ manual/source/apm-structure.rst | 15 +- manual/source/ellipsometry-structure.rst | 6 +- manual/source/mpes-structure.rst | 6 +- 40 files changed, 2159 insertions(+), 1418 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXem_nion.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXdeflector.nxdl.xml delete mode 100644 base_classes/NXfib.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_apm.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXpeak.nxdl.xml delete mode 100644 base_classes/NXpulser_apm.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/NXapm.nxdl.xml rename {base_classes => contributed_definitions}/NXcalibration.nxdl.xml (100%) create mode 100644 contributed_definitions/NXchamber.nxdl.xml rename {base_classes => contributed_definitions}/NXcollectioncolumn.nxdl.xml (100%) create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml rename {base_classes => contributed_definitions}/NXdistortion.nxdl.xml (100%) rename {base_classes => contributed_definitions}/NXelectronanalyser.nxdl.xml (100%) rename {applications => contributed_definitions}/NXellipsometry.nxdl.xml (86%) create mode 100644 contributed_definitions/NXem_nion.nxdl.xml rename {base_classes => contributed_definitions}/NXenergydispersion.nxdl.xml (100%) create mode 100644 contributed_definitions/NXfib.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml rename {base_classes => contributed_definitions}/NXlens.nxdl.xml (100%) create mode 100644 contributed_definitions/NXlens_em.nxdl.xml rename {base_classes => contributed_definitions}/NXmanipulator.nxdl.xml (100%) rename {applications => contributed_definitions}/NXmpes.nxdl.xml (100%) rename {applications => contributed_definitions}/NXmpes_ARPES.nxdl.xml (100%) create mode 100644 contributed_definitions/NXpeak.nxdl.xml create mode 100644 contributed_definitions/NXpulser_apm.nxdl.xml create mode 100644 contributed_definitions/NXpump.nxdl.xml create mode 100644 contributed_definitions/NXreflectron.nxdl.xml rename {base_classes => contributed_definitions}/NXregistration.nxdl.xml (100%) create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml rename {base_classes => contributed_definitions}/NXspindispersion.nxdl.xml (100%) create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 0cf0fe6f05..0000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,573 +0,0 @@ - - - - Draft application definition for atom probe tomography and related field-ion microscopy, all summarized as atom probe microscopy experiments. - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - - Official NeXus NXDL schema to which this entry conforms. - - Version specifier which enables documentation of modifications to the schema. - - - - Ideally, a (globally persistent) unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. - - - Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in prose into this field. - - - ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant - this start time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and interpretation of the experiment. The user should be aware that even with having both time instances specified it may not be advisable to infer how long the experiment took or for how long data were acquired. More detailed timing data over the course of the experiment have to be collected. - - - ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended. - - - Commercial or otherwise given name to the program that was used to acquire/measure the dataset. Atom probe microscopy experiments are nowadays still in most cases controlled via commercial software. These are often designed as integrated acquisition and instrument control software. For AMETEK/Cameca local electrode atom probe (LEAP) instruments the least processed (rawest) numerical results and metadata are stored in so-called RHIT and HITS files, which are proprietary. Supplementary metadata are kept in a database which is connected to the control software. RHIT and HITS are proprietary binary file formats whose content must not be accessed with software other than of AMETEK (IVAS/AP Suite). In effect, RHIT and HITS store the experiment in a closed manner that is practically useless for users unless they have access to the commercial software. To arrive at a state that atom probe microscopy delivers a dataset with which one can study reconstructed atomic position and do e.g. composition analyses or other post-processing analysis tasks, these raw data have to be processed. Therefore, it is necessary that for an application definition to be useful details about the physical acquisition of the raw data and all its processing steps have to be stored to arrive at derived quantities like ion hit positions (on the detector), calibrated time-of-flight data, and from these results obtain calibrated mass-to-charge-state ratios, and finally the tomographically reconstructed atomic positions. In many cases cases, an APM dataset is useful only if it gets post-processed via so-called ranging. Ranging defines a set of rules how to map between time-of-flight and mass-to-charge data on ion types with which in turn one can decode elemental identities and resolve isotopes. All these steps are in most cases performed using commercial software. Frequently, though, ranging and post-processing is also performed with (open-source) research software. Therefore, there is strictly speaking not a single program used in atom probe to arrive at a useful reconstructed and ranged dataset. Hence, the reason to design the application definition with the acquisition and key post-processing steps. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is numerically recreatable in the same deterministic manner. - - - - Not the specimen name or the experiment identifier but the identifier through which the experiment is referred to in the control software. For LEAP instruments it is recommended to use the IVAS/AP Suite run number. For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, or the instruments in Rouen, use the identifier that is closest in meaning to the LEAP run number. As a destructive microscopy method, a run can be performed only once. It is possible, however, to interrupt a run and restart, still all using the same specimen. In this case, each evaporation run needs to be distinguished with different run numbers. # This is how most atom probe groups handle it across the globe. - - - Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip archive ...). - - - A small image that is representative of the entry. For reconstructed datasets it is recommended to display the reconstruction as a 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories. - - - - What type of atom probe microscope experiment is performed. This field can be used e.g. by materials database systems to qualitatively filter experiments. - - - - - - - - - Contact information of at least the user of the instrument who measured this specimen or the principal investigator who performed this experiment. Adding multiple users if relevant is recommended. - - Given (first) name and surname of the user. - - - Name of the affiliation of the user at the point in time when the experiment was performed. - - - Postal address of the affiliation. - - - Email address of the user at the point in time when the experiment was performed. Given the most permanently used email is recommended. - - - Globally unique identifier of the user as offers by services like ORCID or Researcher ID. - - - (Business) (tele)phone number of the user at the point in time when the experiment was performed. - - - Which role does the user have in the place, and at the point in time when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principal investigator, guest ...). - - - - - Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen on e.g. the microtip array was taken. The user is advised to store the details how specimens were cut/prepared from samples in the sample history. - - - Ideally, a reference to the location of or a (globally persistent) unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. - - - ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these temporal details in the sample_history. - - - Possibility to give an abbreviation of the specimen name field. - - - Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus considered relevant from a scientific point. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history. - - - - Hard link to a location/locations in the hierarchy of the NeXus file where the data for default plotting are stored. - - - Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. An atom probe microscope (experiment) is different compared to a large-scale facility accelerator or an electron microscope in at least two ways. First, ionized atoms and molecular ion(s fragments) (in the case of atom probe tomography) and (primarily) imaging gas ions (in the case of field ion microscopy) are accelerated towards a position-sensitive and time-of-flight taking detector system. Hence, there is no real probe/beam. Second, the specimen is the lens of an atom probe microscope. Therefore, the reference coordinate system that is usually referred to in NeXus (McStas coordinate system) is modified when using this application definition. Specifically, the reference coordinate system is defined such that it represents the specimen coordinate system. To be consistent with accelerator and microscopy techniques we define that the positive z-axis points outwards from the apex of the specimen into the vacuum, i.e. towards the detector. The coordinate system remains/is a right-handed one. Clockwise rotations are considered positive rotations. - - Given name of the microscope, e.g Raptor, Oxcart, One atom at a time. - - - Geographic coordinates of the lab or the place where the instrument is installed using GEOREF geocodes ideally. - - - Manufacturer of the entire instrument (e.g. AMETEK/Cameca) to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model and instrument_capabilities. - - - Manufacturer brand/model to enable e.g. queries about microscope models (e.g. LEAP3000XS). - - - Hardware name/serial number or hash identifier given by the manufacturer to identify the instrument. - - - Free-text list possibly multiple terms of functionalities which the instrument provides. - - - The space inside the atom probe that ions pass through when they leave the specimen and travel to the detector. - - - - - - - - - - - - An (ideally globally persistent) unique identifier, link, or text which gives further details. - - - - - Details about the detector which is used to collect raw time-of-flight data and ion/hit impact positions. - - Description of the detector type. Specify if the detector is not the usual type of delay-line detectors. - - - - - - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Affine transformation which aligns the Cartesian right-handed coordinate system which defines the detector space with the specimen space. In atom probe microscopy a frequently used choice is to discuss the so-called detector space image (stack). This is a stack of two-dimensional histograms of detected ions within a predefined evaporation ID interval. Typically, the set of ion evaporation sequence IDs is grouped into chunks. For each chunk a histogram of the ion hit positions on the detector is computed. This leaves the possibility for inconsistency between the so-called detector coordinate system and a specimen-affixed coordinate system. The transformation here resolves this ambiguity by specifying how the positive z-axes of either coordinate systems can be oriented. - - - Amplitude of the signal detected on the multi-channel plate (MCP). This field should be used for storing the signal amplitude quantity of within historic the ATO-formatted files. The ATO file format is used primarily by the atom probe groups in Rouen, France. - - - - - - - - - - - - - - - Given name. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. base temperature, during the measurement. - - - - The majority of atom probe microscopes come from a single commercial manufacturer AMETEK (formerly Cameca). Their instruments are controlled via an(/a set) of integrated instrument control system(s) (APSuite/IVAS/DAVis). By contrast, instruments which were built by individual research groups such as of the French (GPM, Rouen, France), the Schmitz (Inspico, Stuttgart, Germany), the Felfer (Oxcart, Erlangen, Germany), or the PNNL group (Pacific Northwest National Laborary, Portland, Oregon, U.S.) have individual solutions to control the instrument. Some of which are modularized and open, some of which realize also integrated control units with portions of eventually undisclosed source code and (so far) lacking (support of)/open APIs. Currently, the is no community-specific API for getting finely granularized access to such control settings. This motivates the current design of the application definition via an NXcollection. Holding heterogeneous, not yet standardized but relevant pieces of information is the purpose of this collection. - - Track time-dependent settings over the course of the measurement about the environment in the analysis chamber such as gas pressure values etc. - - Average pressure in the analysis chamber. - - - - - A place where details about the initial shape of the specimen can be stored. Ideally, here also data about the shape evolution of the specimen can be stored. There are currently few techniques to measure the shape evolution: One is via correlative electron microscopy but this usually evolves an interrupted experiment in which the specimen is transferred, an image taken, and a new evaporation sequence initiated. Another, less accurate method, though, is to monitor the specimen evolution via the in-built camera system (if available) in the instrument. Another method is to use correlated scanning force microscopy methods (pioneered by the imec group, Belgium). A continuous monitoring of the specimen in an correlative electron microscopy/atom probe experiment is planned to be developed by the Jülich group. - - Ideally measured or best elaborated guess of the initial radius of the specimen. - - - Ideally measured or best elaborated guess of the shank angle. This is a measure of the specimen taper. Define it in such a way that the base of the specimen is modelled as a conical frustrum so that the shank angle is the (shortest) angle between the specimen space z-axis and a vector on the lateral surface of the cone. - - - - This group in the hierarchy should be used to store the ion hit positions. Data post-processing step of analog-to-digital conversion of the detector signals into ion hit positions. For AMETEK LEAP instruments this processing takes place partly in the control unit of the detector and is instructed and monitored/supervised by the acquisition/instrument control software (IVAS/APSuite/DAVis). The exact details are, at least in the case of AMETEK instruments (the large majority of installations worldwide) kept proprietary and inaccessible. For instruments like Oxcart individual timing data from the delay-line detector are open and thus community software can be used to decode these data into ion impact positions. - - Symbols used in the schema to specify e.g. dimensions of arrays. - - - - Given name of the program that was used to perform this computation. Although, for LEAP from AMETEK this is often the same software as one would specify under program_name for the NXentry (usually IVAS or AP Suite), the field is required because in cases where data are post-processed with different software inconsistencies can occur. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Three-dimensional array of raw readings from the analog-to-digital-converter timing circuits of the detector wires. - - - - - - - - Evaluated ion impact coordinates at the detector (either as computed from the arrival time pairs or as reported as the result of a not further specified processing from commercial control software). - - - - - - - Average detection rate over the course of the experiment. - - - - Data post-processing step which is, like the impact position analyses also usually executed in the integrated control software. This processing yields how many ions where detected during the pulse as it is possible that multiple ions evaporate and hit the same detector pixel, which forms the foundation to analyses of the so-called multiplicity of the ion. Multiplicity must not be confused with how many atoms of the same element or isotope, respectively, built a molecular ion. - - Given name of the program that was used to perform this computation. Similar comments as to ion_impact_positions apply. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Number of pulses since the last detected ion pulse. For multi-hit records, after the first record, this is zero. - - - - - - Hit multiplicity. - - - - - - Number of pulses since the start of the atom probe run/evaporation sequence. - - - - - - - Like impact position and hit multiplicity computation ion filtering and are data post-processing steps for identifying which of the detected ions should be included in the voltage-and-bowl correction. - - Given name of the program that was used to perform this computation. Similar comments as to hit_multiplicity apply. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Bitmask which is set to true if the ion is considered and false otherwise. - - - - - - - Data post-processing step to correct for ion impact position flight path differences, detector biases, and nonlinearities. Also this step is usually performed with commercial software. - - Given name of the program that was used to perform this computation. Similar comments as to ion_filtering apply. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Raw time-of-flight data as read-out from the acquisition software if these are available. - - - - - - Calibrated time-of-flight. - - - - - - The key idea and algorithm of the voltage-and-bowl correction is qualitatively similar for instruments of different manufacturers or research groups but different specific calibration models exists. In the first draft of the application definition we do not wish to resolve or generalize these differences. Rather the purpose of this collection is to provide a container where model specific parameters and calibration models can be stored if users know these for sure. For AMETEK LEAP systems this should be the place for storing initial calibration values. These values are accessible normally only by AMETEK service engineers and used by them for calibrating for the detector and instrument. Furthermore, one could then also store here the iteratively identified calibrations which scientists will get displayed in e.g. AP Suite while executing the voltage-and-bowl correction as part of the reconstruction pipeline. - - - - Data post-processing step in which calibrated time-of-flight data (tof) are interpreted into mass-to-charge state ratios. - - Given name of the program that was used to perform this computation. Similar comments as voltage_and_bowl_correction apply. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Like for the voltage-and-bowl correction this collection should be used for storing vendor-specific calibration models if available. - - - Mass-to-charge-state ratios - - - - - - - Data post-processing step to create a tomographic reconstruction of the specimen based on selected calibrated ion hit positions, the evaporation sequence, and voltage curve data. Very often scientists use own software scripts according to published, so-called reconstruction protocols, i.e. numerical recipes how to compute x, y, z atomic positions. - - Given name of the program that was used to perform this computation. Similar comments as voltage_and_bowl_correction apply. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Qualitative statement about which algorithmic approach, i.e. reconstruction protocol was used. - - - - - - - - - - - - Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space. - - - - - - - Different models and associated algorithms, i.e. (numerical) protocols exist to reconstruct atom probe data. Although these approaches are qualitatively similar, each protocol uses different parameters (and interprets these differently). The source code to IVAS/APSuite is not open. For now we store the reconstruction parameter in a collection. - - - To get a first overview of the reconstructed dataset, the format conversion computes a simple 3d histogram of the ion density using one nanometer cubic bins an no smoothing of the histogram. - - Given name of the program that was used to perform this computation. Similar comments as voltage_and_bowl_correction apply. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - - - - - - A default three-dimensional histogram of the total number of ions in each bin. - - Which is the dependent signal to plot, here the counts. - - - Which axes are plotted, here the three principal coordinate directions. - - - Array of counts for each bin. - - - - - - - - Bin positions along the x axis. - - - - Bin edge end along x. - - - Bin positions along the y axis. - - - - Bin edge end along y. - - - Bin positions along the z axis. - - - - Bin edge end along z. - - - Title of the diagram. - - - - - - Data post-processing step in which elemental, isotopic, and/or molecular identities are assigned to the ions. The documentation of these steps is based on ideas described in the literature (M. K"uhbach et al. 2021, Microsc. Microanal.). - - Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step there have been a number of open-source tools been designed for this task. Therefore, it is essential to document which tool was used. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - How many ion types are distinguished - - - Assumed maximum value that suffices to store all relevant molecular ions even the most complicated ones. Usually a value of 32 suffices well. - - - Specifies the computation of the mass-to-charge histogram. Usually mass-to-charge values are studied as an ensemble quantity and binned so document here settings related to (eventual) binning. - - Given name of the program that was used to perform this binning. If the computation is a integrated into the ranging tool, type . - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type . - - - - Smallest and largest mass-to-charge value. - - - - - - Binning width - - - A default histogram aka mass spectrum of the mass-to-charge-state ratio values. - - - - - Which is the dependent signal to plot. - - - Which axes are plotted, here counts over bins. - - - Array of counts for each bin. - - - - - - End of mass-to-charge-state ratio bin. - - - - Label of the mass-to-charge-state ratio bin axis. - - - Title of the diagram. - - - - - Details of the background model which was used to correct the total counts per bin into used counts. - - Given name of the program that was used to perform the background quantification. If the computation is a integrated into the ranging tool, type . - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type . - - - - - How where peaks in the background-corrected mass-to-charge histogram identified. - - Given name of the program that was used to search and detect peaks. If the computation is a integrated into the ranging tool type . - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type . - - - - List of peaks. - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - - - - - - - - - - - - - - - - - - Placeholder for additional details and mathematical models used. - - - - - Details about how peaks, with taking into account error models, were interpreted as an iontype or not. - - Given name of the program that was used to perform identify peaks. If the computation is a integrated into the ranging tool, type . - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type . - - - - The individual ions and their set of mass-to-charge intervals (ranges). If ranging was performed as a computational step then the NeXus-writing software needs to assure that there is always a default ion type which is the unknown ion type. By definition this unknown type has 0 as the id and a default associated mass-to-charge-state ratio interval of [0, 0.001] Da. - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - - - - - - - - - - - - - - - - - - - diff --git a/applications/NXem_nion.nxdl.xml b/applications/NXem_nion.nxdl.xml deleted file mode 100644 index 7b794a18ce..0000000000 --- a/applications/NXem_nion.nxdl.xml +++ /dev/null @@ -1,380 +0,0 @@ - - - - Template for creating draft application definitions for storing data and metadata for experiments with scanning transmission electron microscopy with a Nion instrument. - - - Official NeXus NXDL schema to which this entry conforms. - - Version specifier which enables documentation of modifications to the schema. - - - - Ideally, a (globally persistent) unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. - - - Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in prose into this field. - - - ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant - this start time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and interpretation of the experiment. The user should be aware that even with having both time instances specified it may not be advisable to infer how long the experiment took or for how long data were acquired. More detailed timing data over the course of the experiment have to be collected. - - - ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended. - - - Commercial or otherwise given name to the program which was used to acquire/measure the dataset. Electron microscopy experiments are usually controlled/performed via commercial integrated acquisition and instrument control software. In many cases, an EM dataset is useful only if gets post-processed already during the acquisition or shortly thereafter, i.e. while the scientists is still sitting at the microscope. Many of these processes are automated, if not they virtually involve GUI interactions with the control software. Examples include collecting of diffraction pattern and on-the-fly indexing of these. These situations and tools are realized with individual NXprocess groups which can hold more details and numerical data to these processing steps. Frequently, some of these NXprocess groups are performed with (open-source) research software. Therefore, there is strictly speaking not a single program used in electron microscopy, and thus each NXprocess has its own program name and description." - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is numerically recreatable in the same deterministic manner. - - - - Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip archive ...). - - - A small image that is representative of the entry. This can be an image from the dataset or a thumbnail of a spectrum. Either way it is recommended to use 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories. - - - - Contact information of at least the user of the instrument who measured this specimen or the principal investigator who performed this experiment. Adding multiple users if relevant is recommended. - - Given (first) name and surname of the user. - - - Name of the affiliation of the user at the point in time when the experiment was performed. - - - Postal address of the affiliation. - - - Email address of the user at the point in time when the experiment was performed. Given the most permanently used email is recommended. - - - Globally unique identifier of the user as offers by services like ORCID or Researcher ID. - - - (Business) (tele)phone number of the user at the point in time when the experiment was performed. - - - Which role does the user have in the place, and at the point in time when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principal investigator, guest ...). - - - - - Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen was investigated and is represented by this NXentry. The user is advised to store the details how specimens were cut/prepared from samples in the sample history. - - - Ideally, a reference to the location of or a (globally persistent) unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. - - - ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these temporal details in the sample_history. - - - Possibility to give an abbreviation of the specimen name field. - - - Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus relevant from a scientific point. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history. - - - (Measured) sample thickness - - - - Hard link to a location/locations in the hierarchy of the NeXus file where the data for default plotting are stored. - - - Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. - - Given name of the microscope, e.g. NionHermes. - - - Geographic coordinates of the lab or the place where the instrument is installed using GEOREF geocodes ideally. - - - Manufacturer of the entire instrument to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model and instrument_capabilities. - - - Manufacturer brand/model to enable e.g. queries about microscope models. See comments on instrument_manufacturer on how to provide further specification. - - - Hardware name/serial number or hash identifier given by the manufacturer to identify the instrument. - - - Free-text list possibly multiple terms of functionalities which the instrument provides. - - - The source creating the electron beam. - - Voltage relevant to compute the energy of the electrons immediately after they left the gun. - - - Type of radiation. - - - - - - Emitter type used to create the beam. - - - - - - - - Ideally a reference to (another) file (ideally formatted using also an application definition) via a link, name, or a (globally persistent) unique identifier to give further details about the electron gun. - - - - Details to individual apertures in the instrument. - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Relevant value from the control software as this is not always just the diameter of (not even in the case) of a circular aperture but a rather a value from a list of predefined ones in the control software. Which actual settings are behind these should be Details which choice was made should be explained under description. - - - An (ideally globally persistent) unique identifier, link, or text which gives further details. - - - Affine transformations and geometrical descriptions which detail how the aperture is placed and arranged in the microscope relative to the optical axis and beam path. - - - - Details to individual lenses in the microscope. - - Which type describes the type of the lens closest? - - - - - - - - - - - - - - - - - Details about an eventual device which corrects spherical aberrations. - - Does the microscope have a spherical aberration correction unit and was it used? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Stage tilt A. Exact definition as understood by HU colleagues remains to be communicated. - - - Stage tilt B. Exact definition as understood by HU colleagues remains to be communicated. - - - StageOutX, Y, Z. Exact definition as understood by HU colleagues remains to be communicated. - - - - - - - - - Description of the type of the detector e.g. CCD, scintillator, direct electron, image plate, CMOS. - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - - - - - - - - - Free text option to write further details about the detector. - - - - - Exact definition as understood by HU colleagues remains to be communicated. - - - Exact definition as understood by HU colleagues remains to be communicated. - - - Exact definition as understood by HU colleagues and Nion remains to be communicated. - - - Details how computed needs to be confirmed by Nion. - - - - - Container for reporting individually processed images with the HAADF detector ? - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - HAADF annulus inner half angle ? - - - HAADF annulus outer half angle ? - - - - - - - - - Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. - - Commercial or otherwise given name to the program which was used to execute this analysis. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Remains to be discussed with colleagues which suggestions to put as enumerations. - - - - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Detailed settings of an internal board(s) in the scanbox device. Further information exchange/discussions with Nion is needs to elucidate what these are. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Container for holding an image (stack) taken with the HA(A) ? DF detector. - - - - - - Image intensity values. - - - - - - - Label for the y axis. - - - Pixel barycenter position x-coordinates. - - - - - - Pixel barycenter position y-coordinates. - - - - - - - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index dd005aa7af..0000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,27 +0,0 @@ - - - - Draft of a base class for a device in a (transmission) electron microscope which corrects for spherical aberrations. The device consists of multiple NXlens_em instances and other components. - - Does the microscope have a spherical aberration correction unit and was it used? - - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Ideally an identifier, link, or free-text which gives further details about the component. - - - Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin of the coordinate system is placed in the center of the gun pinhole as the virtual point-like assumed source of the electron beam. A right-handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. The translation actively brings the coordinate system under depends_on into registration with the reference coordinate system in the gun. - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml deleted file mode 100644 index bd69b407bd..0000000000 --- a/base_classes/NXdeflector.nxdl.xml +++ /dev/null @@ -1,46 +0,0 @@ - - - - Draft class definition for electro-static deflectors as they are used e.g. in an electron analyser. - - Qualitative type of lens with respect to the number of pole pieces - - - - - - - - - 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. - - - Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin of the coordinate system is placed in the center of the gun pinhole as the virtual point-like assumed source of the electron beam. A right-handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. - - - Following transformation_type argument of NXtranslations but allowed value is only translation. - - - Following vector argument of NXtranslations. The translation actively brings the coordinate system under depends_on into registration with a coordinate system in the center of the lens. - - - Enter the path where the reference coordinate system for the instrument is defined. - - - - diff --git a/base_classes/NXfib.nxdl.xml b/base_classes/NXfib.nxdl.xml deleted file mode 100644 index 0fa0bede64..0000000000 --- a/base_classes/NXfib.nxdl.xml +++ /dev/null @@ -1,53 +0,0 @@ - - - - Draft of a base class for describing focused-ion beam capabilities of an instrument. The class is designed to be used as an additional component of e.g. an electron microscope to describe sample/specimen preparation and the collecting of data and metadata for (scanning) electron microscope/focused-ion beam, (S)EM/FIB instruments. - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Ideally a reference to persistent documentation which specifies further details for the device. If this is not available, add a free-text description to deliver further details about the focused-ion unit. - - - - The type of source which creates the ion beam. - - - - - - - - Which ionized elements or molecule are ionized to form the beam that sputters material. Examples a gallium, helium, neon, argon, krypton, or xenon, O2+. - - - Average/nominal (discuss further with colleagues) brightness of the ion beam (at which location?). - - - Ion flux - - - Charge current - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - Needs further discussion with colleagues how this should be defined. - - - - A right-handed Cartesian coordinate system is used whose positive z-axis points in the direction of the ion beam, i.e. towards the sample. For modelling ion milling it is relevant to document the illumination vector. NXtransformations offers a place to store how the ion gun coordinate system has to be rotated to align its positive z-axis with the positive z-axis of e.g. the electron beam and ion beam respectively. - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index 41d61f7143..0000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,32 +0,0 @@ - - - - Atomic architecture of a (molecular) ion (fragment) which can be used for example to label charged molecule ions identified from mass-to-charge histogram data as appearing as signal in e.g. time-resolved mass spectrometry techniques like atom probe or secondary ion mass spectrometry. - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - Ion type aka ion species identifier. The identifier zero is reserved for the special ion type unknown ion type. - - - A vector of ordered isotope hash values. The values have to be arranged in the array 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. Hashvalue = Z + N*256 where Z is the number of protons and N the number of neutrons of the isotope. Z and N have to be 8-bit unsigned integers for this hash function to work. - - - - - - Signed charge of the ion in multiples of the elementary 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 the charge state is not recoverable explicitly, the value should be set to zero. This is for example the case when using classical range file formats (RNG, RRNG) because for atom probe microscopy these files do not document the charge state explicitly but report just a integer fraction of the theoretical mass-to-charge-state-ratios. - - - Human-readable ion type name (e.g. Al3+), i.e. ASCII UTF-8 character array, ideally using LaTeX notation to specify the ion and charge state. Examples 12C+, Al3+ or H+. Although human-readable and intuitive, parsing such names becomes impractical for more complicated cases. Therefore, the isotope_vector is the preferred machine-readable format. - - - Lower (mqmin) and upper (mqmax) bounds of a mass-to-charge interval [mqmin, mqmax] (boundaries included) where assigned signal for the respective ion is labelled as this ion. - - - - - - diff --git a/base_classes/NXlens_apm.nxdl.xml b/base_classes/NXlens_apm.nxdl.xml deleted file mode 100644 index 9405a342b3..0000000000 --- a/base_classes/NXlens_apm.nxdl.xml +++ /dev/null @@ -1,26 +0,0 @@ - - - - Draft class definition for a component of an atom probe instrument which details an eventually available reflectron device whose purpose is to deflect the flight paths of the ions to realize what is effectively an energy compensation. - - Specifier if the instrument has a reflectron (true) or not (false). - - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Free-text field to specify further details about the reflectron. - - - Affine transformation(s) which detail where the reflectron is located relative to e.g. the origin of the specimen space reference coordinate system. This group can also be used for specifying how the reflectron is rotated to the specimen axis. The purpose of these more detailed instrument descriptions is to support the creation of a digital twin of the instrument for computational science. - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index b107d10ce5..0000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - Draft base class definition for electro-magnetic lenses as they are used e.g. in an electron microscope or reflectron device in a local electrode atom probe microscope. - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Ideally an identifier, persistent link, or free text which gives further details about the lens. - - - Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin of the coordinate system is placed in the center of the gun pinhole as the virtual point-like assumed source of the electron beam. A right-handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. The translation actively brings the coordinate system under depends_on into registration with a coordinate system in the center of the lens. - - diff --git a/base_classes/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml deleted file mode 100644 index c471da5652..0000000000 --- a/base_classes/NXpeak.nxdl.xml +++ /dev/null @@ -1,35 +0,0 @@ - - - - Proposal for storing mathematical models of peaks, their functional form or at least their measured support. - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Human-readable identifier to specify which concept/entity the peak identifies. - - - Is the peak described analytically or empirically via intensity/counts as a function of an independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, this array holds the positions were independent variable values were taken. - - - - - - 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 this group can be used to hold parameter of the functional form. For example in the case of Gaussian peaks mu, sigma, and cut-off values and background intensity. - - diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml deleted file mode 100644 index 64c542da86..0000000000 --- a/base_classes/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,70 +0,0 @@ - - - - Draft for a class which can be used for representing a coarse-grained description of all those components of an atom probe microscope which realize the pulsing capabilities, whether it be for the laser or the high-voltage pulser, which trigger the removal of ions (atom probe tomography) or the excitation of gas ions (field-ion microscopy). - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - How evaporation is physically triggered. - - - - - - - Atom probe microscopes use controlled either voltage or laser pulsing to trigger a sequence of field evaporation events. Many microscopes have a laser installed enabling measurements of poorly conductive specimens. - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Nominal wavelength of the laser radiation. - - - Average power of the laser source while illuminating the specimen. - - - Average (??) energy of the laser at peak of (each) ?? pulse. - - - Set of transformations which describe the geometry between how the laser focusing optics/pinhole-attached coordinate system is defined, how it has to be transformed so that it aligns with the specimen coordinate system. A right-handed Cartesian coordinate system, the so-called laser space, should be assumed whose positive z-axis points into the direction of the propagating laser beam. - - - - Details about specific positions along the focused laser beam which for atom probe illuminates the specimen. - - Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - - - Track time-dependent settings over the course of the measurement where the laser hits the specimen. - - - - Frequency with which the high voltage or laser gets pulsed. - - - Fraction of the pulse_voltage that is applied in addition to the standing_voltage at peak voltage of a pulse. - - - NEED TO DISCUSS WITH APM COLLEAGUES IN DETAIL WHAT THIS IS SPECIFICALLY! - - - - - - Direct current voltage between the specimen and the (local electrode) in the case of a LEAP instrument. - - - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index ca571fc4d1..0000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. - - - - - - - - Commercial or otherwise given name to the program which was used to execute this analysis. - - Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - - - - Remains to be discussed with colleagues which suggestions to put as enumerations. - - - - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - - Remains to be discussed with colleagues how to use and interpret this. - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index fe635a3f67..0000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,41 +0,0 @@ - - - - Candidate class for a component or a set of components which is coarse-grained into one logical unit. The role of the stage in an experiment is to hold/align/orient the sample/specimen and eventually offer a controlled environment and further devices to apply stimuli. Having an own candidate class is justified as contemporary specimen/sample stages are such multi-purpose/-functional tools with multiple actuators, sensors, components, and thus also the need to store the various (meta)data that are generated with manipulating the sample. Modern stages realize a hierarchy of components for achieving these tasks. For example the specimen might be mounted on a multi-axial tilt rotation holders which itself is fixed in the support unit that connects to the microscope. In other examples, taken from atom probe microscopy for instance, researchers may work with wire samples which are clipped into a larger fixing unit for convenience. This unit is known in atom probe jargon as a stub. Stubs in turn are positioned on pucks. Pucks are then loaded onto carousels. This NXstage class reflects two layers of this hierarchy. 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. Applied to examples, a nanoparticle is attached on a copper grid. The copper grid is the holder. The grid itself is fixed to the stage. An atom probe specimen is fixed in a stub, in this case the stub can be considered as the holder, while the cryostat temperature control unit reads more as the stage. A microtip on a microtip array is an example of a three-layer hierarchy commonly employed for efficient sequential processing of atom probe experiments. For a single experiment though only one microtip of the array at a time can be measured. Therefore, the microtip is the specimen, the array the holder and the remaining mounting unit that is attached to the cryo-controller the stage. To cover for an as flexible design of these complex lab-like modern stages users should nest NXstage_lab objects for reflect the differences between e.g. a holder and a stage. - - Principal design of the stage. - - - - - - - - - - - - - - - - - Given name. - - - Given brand or model name by the manufacturer. - - - Given hardware name/serial number or hash identifier issued by the manufacturer. - - - Given name of the manufacturer. - - - Ideally a link to a (globally persistent) unique identifier which documents or can be used to infer further details of the component. If not available use this field for a free text description to give further details to the stage. - - - Set of transformations which describe how the stage-affixed coordinate system is defined and how it has to be transformed so that it aligns with the specimen coordinate system. - - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 0000000000..c51c2a40dd --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,967 @@ + + + + Atom probe tomography and field-ion microscopy experiments. + + The symbols used in the schema to specify e.g. dimensions of arrays + + Total number of ions collected + + + Total number of independent wires in the delay-line detector. + + + Number of support points for e.g. modeling peaks in the mass-to-charge-state ratio histogram. + + + Maximum number of allowed atoms per (molecular) ion (fragment). Needs to match maximum_number_of_atoms_per_molecular_ion. + + + Number of mass-to-charge-state-ratio range intervals mapped on this ion type. + + + + + Official NeXus NXDL schema to which this entry conforms. + + Version specifier which enables documentation of modifications to the + schema. + + + + Ideally, a (globally) persistent unique identifier for referring to + this experiment. The identifier is usually defined/issued by the + facility, laboratory, or the principle investigator. The identifier + enables to link experiments to e.g. proposals. + + + Possibility for leaving a free-text description about the experiment. + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than writing these details in + prose into this field here. + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the experiment started. If the application + demands that time codes in this section of the application definition + should only be used for specifying when the experiment was performed - + and the exact duration of the experiment is not relevant - this start + time field should be used. Often though it is useful to specify a time + interval, i.e. start_time and end_time, to allow for more detailed + bookkeeping and interpretation of the experiment. The user should be + aware that even with having both time instances specified it may not + be advisable to infer how long the experiment took or for how long + data were acquired. More detailed timing data over the course of the + experiment have to be collected for such a detailed bookkeeping. + + + ISO 8601-formatted time code with local time zone offset to UTC + included when the experiment ended. + + + Commercial or otherwise given name to the program that was used to + acquire/measure the dataset. Atom probe microscopy experiments are + nowadays still in most cases controlled via commercial software. These + are often designed as integrated acquisition and instrument control + software. For AMETEK/Cameca local electrode atom probe (LEAP) + instruments the least processed (rawest) numerical results and + metadata are stored in so-called RHIT and HITS files, which are + proprietary. Supplementary metadata are kept in a database which is + connected to the control software. RHIT and HITS are proprietary + binary file formats whose content must not be accessed with software + other than of AMETEK (IVAS/AP Suite). In effect, RHIT and HITS store + the experiment in a closed manner that is practically useless for + users unless they have access to the commercial software. To arrive at + a state that atom probe microscopy delivers a dataset with which one + can study reconstructed atomic position and do e.g. composition + analyses or other post-processing analysis tasks, these raw data have + to be processed. Therefore, it is necessary that for an application + definition to be useful, details about the physical acquisition of the + raw data and all its processing steps have to be stored. With this a + user can create derived quantities like ion hit positions (on the + detector), calibrated time-of-flight data. These derived quantities + are also need to obtain calibrated mass-to-charge-state ratios, and + finally the tomographically reconstructed atomic positions. In many + cases cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines a set of rules how one map + between time-of-flight and mass-to-charge data on ion types, i.e. + labels. In turn, these labels decode elemental identities and resolve + isotopes. All these steps are in most cases performed using commercial + software. Frequently, though, ranging and post-processing is also + performed with (open-source) research software. Therefore, there is + strictly speaking not a single program used in atom probe not even for + the early data acquisition and processing stages until one arrives at + a useful reconstructed and ranged dataset. Therefore, the application + definition documents not only the measurement but also these key post- + processing steps. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result file is + numerically recreatable in the same deterministic manner. + + + + Not the specimen name or the experiment identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/AP Suite run + number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments in Rouen, use the identifier + that is closest in meaning to the LEAP run number. As a destructive + microscopy method, a run can be performed only once. It is possible, + however, to interrupt a run and restart data acquisition while still + using the same specimen. In this case, each evaporation run needs to + be distinguished with different run numbers. # This is how most atom + probe groups handle it across the globe. + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold e.g. a ppt, pdf, latex, txt, image, or zip + archive ...). + + + A small image that is representative of the entry. For reconstructed + datasets it is recommended to display the reconstruction as a 640x480 + pixel jpeg image. Adding a scale bar to that image is recommended but + not required as the main purpose of the thumbnail is to provide e.g. + thumbnail images for displaying them in data repositories. + + + + What type of atom probe microscope experiment is performed. This field + can be used e.g. by materials database systems to qualitatively filter + experiments. + + + + + + + + + Contact information of at least the user of the instrument who + measured this specimen or the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + Given (first) name and surname of the user. + + + Name of the affiliation of the user at the point in time when the + experiment was performed. + + + Postal address of the affiliation. + + + Email address of the user at the point in time when the experiment was + performed. Giving the most permanently used email is recommended. + + + Globally unique identifier of the user as offers by services like + ORCID or ResearcherID. + + + (Business) (tele)phone number of the user at the point in time when + the experiment was performed. + + + Which role does the user have in the place, or did the user hold when, + the experiment was performed (e.g. technician operating the + microscope, student, postdoc, principle investigator, guest ...). + + + + + Descriptive name or identifier with which to distinguish the specimen + from all others and especially the parts from where it was cut. In + cases where the specimen was e.g. site-specifically cut from samples + or in cases of an instrument session during which multiple specimens + are loaded, the name has to be descriptive enough to resolve which + specimen on e.g. the microtip array was taken. The user is advised to + store the details how specimens were cut/prepared from samples in the + sample history. + + + Ideally, a reference to the location of or a (globally persistent) + unique identifier of e.g. another file which should document ideally + as many details as possible of the material, its microstructure, and + its thermo-chemo-mechanical processing/preparation history. In the + case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a sub- + set of the entire sample history, i.e. what you would consider being + the key steps and relevant information about the specimen, its + material, microstructure, thermo-chemo-mechanical processing state and + details of the preparation. + + + ISO8601 date and time with local time zone offset to UTC included when + the specimen was prepared. Ideally report the end of the preparation, + i.e. the last known time the measured specimen surface was actively + prepared. Knowing when the specimen was exposed to e.g. specific + atmosphere is especially required for environmentally sensitive + material such as hydrogen-charged specimens or experiments including + tracers with a short half-time. The user is advised to include these + temporal details in the sample_history. + + + Possibility to give an abbreviation of the specimen name field. + + + Use Hill's system for listing elements of the periodic table which are + inside or attached to the surface of the specimen and thus considered + relevant from a scientific point. The purpose of the field is to offer + materials database systems an opportunity to parse the relevant + elements without having to interpret these from the sample history. + + + + Hard link to a location/locations in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + Metadata and numerical data of not only the microscope but also the + lab in which this microscope is located. An atom probe microscope + (experiment) is different compared to a large-scale facility + accelerator or an electron microscope in at least two ways. First, + ionized atoms and molecular ion(s fragments) (in the case of atom + probe tomography) and (primarily) imaging gas ions (in the case of + field ion microscopy) are accelerated towards a position-sensitive and + time-of-flight taking detector system. Hence, there is no real + probe/beam. Second, the specimen is the lens of an atom probe + microscope. Therefore, the reference coordinate system that is usually + referred to in NeXus (McStas coordinate system) is modified when using + this application definition. Specifically, the reference coordinate + system is defined such that it represents the specimen coordinate + system. To be consistent with accelerator and microscopy techniques we + define that the positive z-axis points outwards from the apex of the + specimen into the vacuum, i.e. towards the detector. The coordinate + system remains/is a right-handed one. Clockwise rotations are + considered positive rotations. + + Given name of the microscope, e.g Raptor, Oxcart, One atom at a time. + + + Geographic coordinates of the lab or the place where the instrument is + installed using GEOREF geocodes ideally. + + + Manufacturer of the entire instrument (e.g. AMETEK/Cameca) to enable + e.g. queries in materials database systems for instrument + manufacturers. Usually more technical details are needed though to + specify the instrument, these should be written into instrument_model + and instrument_capabilities. + + + Manufacturer brand/model to enable e.g. queries about microscope + models (e.g. LEAP3000XS). + + + Hardware name/serial number or hash identifier given by the + manufacturer to identify the instrument. + + + Free-text list possibly multiple terms of functionalities which the + instrument provides. + + + The space inside the atom probe that ions pass through when they leave + the specimen and travel to the detector. + + + + + + + + + + Device for reducing flight time differences of ions in ToF + experiments. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Free-text field to specify further details about the reflectron. The + quantity can inform for instance if the reflectron is flat or curved. + + + Affine transformation(s) which detail where the reflectron is located + relative to e.g. the origin of the specimen space reference coordinate + system. This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. The purpose of these more + detailed instrument descriptions is to support the creation of a + digital twin of the instrument for computational science. + + + + NEED FOR FURTHER DISCUSSIONS WITH APM COLLEAGUES WHAT IS RELEVANT + HERE. + + + + An (ideally globally persistent) unique identifier, link, or text + which gives further details. + + + + Details about the detector which is used to collect raw time-of-flight + data and ion/hit impact positions. + + Description of the detector type. Specify if the detector is not the + usual type of delay-line detectors. + + + + + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Amplitude of the signal detected on the multi-channel plate (MCP). + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the atom + probe groups in Rouen, France. + + + + + + Affine transformation which aligns the Cartesian right-handed + coordinate system which defines the detector space with the specimen + space. In atom probe microscopy a frequently used choice is to discuss + the so-called detector space image (stack). This is a stack of two- + dimensional histograms of detected ions within a predefined + evaporation ID interval. Typically, the set of ion evaporation + sequence IDs is grouped into chunks. For each chunk a histogram of the + ion hit positions on the detector is computed. This leaves the + possibility for inconsistency between the so-called detector + coordinate system and a specimen-affixed coordinate system. The + transformation here resolves this ambiguity by specifying how the + positive z-axes of either coordinate systems can be oriented. + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a combination + of pulsing strategies to trigger the excitation and eventual field + evaporation/emission of an ion in an atom probe microscopy experiment. + # Many microscopes have a laser installed which enables measurements + also with poorly conductive specimens. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Nominal wavelength of the laser radiation. + + + Average power of the laser source while illuminating the specimen. + + + Average (??) energy of the laser at peak of (each) ?? pulse. + + + Set of transformations which describe the geometry between how the + laser focusing optics/pinhole-attached coordinate system is defined, + how it has to be transformed so that it aligns with the specimen + coordinate system. A right-handed Cartesian coordinate system, the so- + called laser space, should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + Details about specific positions along the focused laser beam which + illuminates the atom probe specimen. + + Track time-dependent settings over the course of the measurement where + the laser beam exits the focusing optics. + + + Track time-dependent settings over the course of the measurement where + the laser hits the specimen. + + + + Frequency with which the high voltage or laser pulser fires. + + + Fraction of the pulse_voltage that is applied in addition to the + standing_voltage at peak voltage of a pulse. + + + NEED TO DISCUSS WITH APM COLLEAGUES IN MORE DETAIL WHAT THIS IS + SPECIFICALLY! + + + + + + Direct current voltage between the specimen and the (local electrode) + in the case of a LEAP instrument. + + + + + + + + Principal design of the stage. + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Ideally a link to a (globally persistent) unique identifier which + documents or can be used to infer further details of the component. If + such a resource is not available, use this field for a free-text + description and describe further details to the stage. + + + Set of transformations which describe how the stage-affixed coordinate + system is defined and how it has to be transformed so that it aligns + with the specimen coordinate system. + + + + Average temperature at the specimen base, i.e. base temperature, + during the measurement. + + + + The majority of atom probe microscopes come from a single commercial + manufacturer AMETEK (formerly Cameca). Their instruments are + controlled via an(/a set) of integrated instrument control system(s) + (APSuite/IVAS/DAVis). By contrast, instruments which were built by + individual research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), the Felfer (Oxcart, + Erlangen, Germany), the Northwestern (D. Isheim, Seidman group et + al.), or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have individual solutions to control the + instrument. Some of which are modularized and open, some of which + realize also integrated control units with portions of eventually + undisclosed source code and (so far) lacking (support of)/open APIs. + Currently, there is no accepted/implemented community-specific API for + getting finely granularized access to such control settings. This + motivates the current design of the application definition which + stores quantities to begin with via an NXcollection. Holding + heterogeneous, not yet standardized, but relevant pieces of + information is the purpose of this collection. + + Track time-dependent settings over the course of the measurement about + the environment in the analysis chamber such as gas pressure values + etc. + + Average pressure in the analysis chamber. + + + + + A place where details about the initial shape of the specimen can be + stored. Ideally, here also data about the shape evolution of the + specimen can be stored. There are currently very few techniques only + to measure the shape evolution: One is via correlative electron + microscopy but this usually evolves an interrupted experiment in which + the specimen is transferred, an image taken, and a new evaporation + sequence initiated. Another, less accurate method, though, is to + monitor the specimen evolution via the in-built camera system (if + available) in the instrument. Another method is to use correlated + scanning force microscopy methods (pioneered by the imec group, + Belgium). A continuous monitoring of the specimen in an correlative + electron microscopy/atom probe experiment is planned to be developed + by the Jülich group (Dunin-Borkowski/Gault). + + Ideally measured or best elaborated guess of the initial radius of the + specimen. + + + Ideally measured or best elaborated guess of the shank angle. This is + a measure of the specimen taper. Define it in such a way that the base + of the specimen is modelled as a conical frustrum so that the shank + angle is the (shortest) angle between the specimen space z-axis and a + vector on the lateral surface of the cone. + + + + This group in the hierarchy should be used to store the ion hit + positions. Data post-processing step of analog-to-digital conversion + of the detector signals into ion hit positions. For AMETEK LEAP + instruments this processing takes place partly in the control unit of + the detector partly in the software. The process is controlled by the + acquisition/instrument control software (IVAS/APSuite/DAVis). The + exact details are, at least in the case of AMETEK instruments, which + applies to the majority of atom probe microscopes, kept proprietary + and inaccessible. For instruments build by individual research groups, + like the Oxcart instrument, individual timing data from the delay-line + detector are openly accessible. + + Given name of the program that was used to perform this computation. + Although for LEAP instruments this program is often the same software + as one would specify under program for the NXentry (usually IVAS or AP + Suite), the field is required because in cases where data is post- + processed with different software it would not be possible to + distinguish which portions of the dataset were computed with which + software. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + Three-dimensional array of raw readings from the analog-to-digital- + converter timing circuits of the detector wires. + + + + + + + + Evaluated ion impact coordinates at the detector (either as computed + from the arrival time data or as reported as the result of a not + necessarily further specified processing within commercial control + software. + + + + + + + Average detection rate over the course of the experiment. + + + + Data post-processing step which is, like the impact position analyses, + also usually executed in the integrated control software. This + processing yields how many ions were detected with each pulse. In + fact, it is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. These data form + the basis to analyses of the so-called (hit) multiplicity of an ion. + Multiplicity must not be confused with how many atoms of the same + element or isotope, respectively, a molecular ion contains. By + contrast, this latter multiplicity is encoded in the (isotope_vector) + field within in a (NXion) instance. + + Given name of the program that was used to perform this computation. + Similar comments as for ion_impact_positions apply. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + Number of pulses since the last detected ion pulse. For multi-hit + records, after the first record, this is zero. + + + + + + Hit multiplicity. + + + + + + Number of pulses since the start of the atom probe run/evaporation + sequence. + + + + + + + Like impact position and hit multiplicity computations, ion filtering + is a data post-processing step when users identify which of the + detected ions should be included in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction in the + reconstruction pipeline of commercial analysis software like + IVAS/APSuite. + + Given name of the program that was used to perform this computation. + Similar comments as to hit_multiplicity apply. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + Bitmask which is set to true if the ion is considered and false + otherwise. + + + + + + + Data post-processing step to correct for ion impact position flight + path differences, detector biases, and nonlinearities. Also this step + is usually performed with commercial software. + + Given name of the program that was used to perform this computation. + Similar comments as to ion_filtering apply. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + Raw time-of-flight data as read-out from the acquisition software if + these data are or accessible. + + + + + + Calibrated time-of-flight. + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers or + research groups. Specific differences exists though in the form of + different calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection is + to provide a container where model-specific parameters and calibration + models can be stored if users know these for sure. For AMETEK LEAP + systems this should be the place for storing initial calibration + values. These values are accessible normally only by AMETEK service + engineers and used by them for calibrating for the detector and + instrument. Furthermore, one could then also store here the + iteratively identified calibrations which scientists will get + displayed in e.g. AP Suite while executing the voltage-and-bowl + correction as part of the reconstruction pipeline. + + + + Data post-processing step in which calibrated time-of-flight data + (tof) are interpreted into mass-to-charge-state ratios. + + Given name of the program that was used to perform this computation. + Similar comments as voltage_and_bowl_correction apply. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + Like for the voltage-and-bowl correction, this collection should be + used for storing vendor-specific calibration models if these are + available. + + + Mass-to-charge-state ratios + + + + + + + Data post-processing step to create a tomographic reconstruction of + the specimen based on selected calibrated ion hit positions, the + evaporation sequence, and voltage curve data. Very often scientists + use own software scripts according to published, so-called + reconstruction protocols, i.e. numerical recipes how to compute x, y, + z atomic positions from the input data. + + Given name of the program that was used to perform this computation. + Similar comments as voltage_and_bowl_correction apply. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + Qualitative statement about which algorithmic approach, i.e. + reconstruction protocol was used. + + + + + + + + + + + + Three-dimensional reconstructed positions of the ions. Interleaved + array of x, y, z positions in the specimen space. + + + + + + + Different models and associated algorithms, i.e. (numerical) protocols + exist to reconstruct atom probe data. Although these approaches are + qualitatively similar, each protocol uses different parameters (and + interprets these differently). The source code to IVAS/APSuite is not + open. For now we store the reconstruction parameter in a collection. + + + + Data post-processing step in which elemental, isotopic, and/or + molecular identities are assigned to the ions. The documentation of + these steps is based on ideas described in the literature (M. K"uhbach + et al. 2021, Microsc. Microanal.). + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools been + designed for executing this task. Therefore, it is essential to + document which tool was used. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + How many ion types are distinguished. + + + Assumed maximum value that suffices to store all relevant molecular + ions, even the most complicated ones. Currently a value of 32 is used. + + + Specifies the computation of the mass-to-charge histogram. Usually + mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. The (NXprocess) stores the + settings of this binning. + + Given name of the program that was used to perform this binning. If + the computation is a integrated into the ranging tool, type . + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + If the version is the same as for the ranging tool, type . + + + + Smallest and largest mass-to-charge value. + + + + + + Binning width + + + + Details of the background model which was used to correct the total + counts per bin into used counts. + + Given name of the program that was used to perform the background + quantification. If the computation is a integrated into the ranging + tool, type . + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + If the version is the same as for the ranging tool, type . + + + + + How where peaks in the background-corrected mass-to-charge histogram + identified. + + Given name of the program that was used to search and detect peaks. If + the computation is a integrated into the ranging tool type . + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + If the version is the same as for the ranging tool, type . + + + + List of peaks. + + Human-readable identifier to specify which concept/entity the peak + identifies. + + + Is the peak described analytically via a functional form or is it + described empirically via measured/reported intensity/counts as a + function of an independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the positions were independent variable values were + taken. + + + + + + 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 this group can be used to + hold parameter of the functional form. For example in the case of + Gaussian peaks mu, sigma, and cut-off values and background intensity. + + + + + Details about how peaks, with taking into account error models, were + interpreted as an iontype or not. + + Given name of the program that was used to perform identify peaks. If + the computation is a integrated into the ranging tool, type . + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + If the version is the same as for the ranging tool, type . + + + + The individual ions and their set of mass-to-charge intervals + (ranges). If ranging was performed as a computational step then the + NeXus-writing software needs to assure that there is always a default + ion type which is the unknown ion type. By definition this unknown + type has 0 as the id and a default associated mass-to-charge-state + ratio interval of [0, 0.001] Da. + + 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 a + decreasingly sorted array. The array is filled with zero hash values + indicating unused places. The individual hash values are built with + the following hash function: Hashvalue = Z + N*256 with Z the number + of protons and N the number of neutrons of the isotope respectively. Z + and N have to be 8-bit unsigned integers. + + + + + + Signed charge state of the ion in multiples of the elementary 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. 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 but report an integer with the atom type which can be used + to compute the charge state via the theoretically-known mass-to- + charge-state-ratios of the elements. + + + Human-readable ion type name (e.g. Al +++), i.e. ASCII UTF-8 character + array, ideally using LaTeX notation to specify the ion 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, the isotope_vector should be the + preferred machine-readable format in 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 labelled as an ion of the here referred to + ion_type. + + + + + + + + + + + diff --git a/base_classes/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml similarity index 100% rename from base_classes/NXcalibration.nxdl.xml rename to contributed_definitions/NXcalibration.nxdl.xml diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml new file mode 100644 index 0000000000..e3e2cf1a49 --- /dev/null +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -0,0 +1,22 @@ + + + + Component of an instrument to store or place objects and specimens. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Describe details about the chamber, for instance out of which material + it was built. + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml similarity index 100% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXcollectioncolumn.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 0000000000..415e29a39f --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,35 @@ + + + + Device for correcting spherical aberrations in an electron microscope. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Ideally an identifier, link, or free-text which gives further details + about the component. + + + Collection of axis-based translations and rotations to describe the + location and geometry of the corrector as a component in the + instrument. Conventions from the NXtransformations base class are + used. In principle, the McStas coordinate system is used. The origin + of the coordinate system is placed in the center of the gun pinhole as + the virtual point-like assumed source of the electron beam. A right- + handed coordinate system is assumed whose positive z-axis points in + the direction of the propagating electron beam. The translation + actively brings the coordinate system under depends_on into + registration with the reference coordinate system in the gun. + + + diff --git a/base_classes/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml similarity index 100% rename from base_classes/NXdistortion.nxdl.xml rename to contributed_definitions/NXdistortion.nxdl.xml diff --git a/base_classes/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml similarity index 100% rename from base_classes/NXelectronanalyser.nxdl.xml rename to contributed_definitions/NXelectronanalyser.nxdl.xml diff --git a/applications/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml similarity index 86% rename from applications/NXellipsometry.nxdl.xml rename to contributed_definitions/NXellipsometry.nxdl.xml index 2d40762da9..f7e69dbbe8 100644 --- a/applications/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -1,46 +1,24 @@ - Draft application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. In this application definition, times should be specified always together with a UTC offset. + Draft application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. Variables used throughout the document, e.g. dimensions and important parameters - - Size of the energy / wavelength vector used - - - How many variables are saved in a measurement (e.g. Psi and Delta, Mueller matrix. - - - Number of incident angles used - - - Number of sample parameters scanned - - - Number of time points measured - + + + + + - "This is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description" - - An application definition for ellipsometry. - - Version number to identify which definition of this application definition was used for this entry/data. - - - URL where to find further material (documentation, examples) relevant to the application definition - - - - - + This is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. + +The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description Unique identifier of the experiment, such as a (globally persistent) unique identifier. - The identifier is usually defined by the facility or principle investigator. - The identifier enables to link experiments to e.g. proposals. - - UTC offset should be specifiec. - + Commercial or otherwise defined given name to the program that was used to generate the results file(s) with measured data and metadata (or a link to the instrument software). @@ -50,6 +28,15 @@ Website of the software. + + FAIRmat-specific candidate proposal for an application definition exemplifying ellipsometry. For example: https://gitlab.mpcdf.mpg.de/nomad-lab/areab-appdef/-/blob/spectroscopic-ellipsometry-consolidation/optical_spectroscopy + + Ideally version with build number are commit hash of the application definition. If not available a free-text description. + + + URL where to find further material (documentation, examples) relevant to the application definition + + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -73,7 +60,7 @@ Name of the company which build the instrument - ISO8601 date when the instrument was constructed. UTC offset should be specifiec. + ISO8601 date when the instrument was constructed Name (e.g. commercial) of the software that was used for the measurement @@ -127,7 +114,7 @@ Ellipsometers require regular calibration to adjust the hardware parameters for proper zero values and background light compensation. - ISO8601 datum when calibration was last performed before this measurement. UTC offset should be specifiec. + ISO8601 datum when calibration was last performed before this measurement Arrays which provide the measured calibration data. Multiple sets are possible, e.g. Psi and delta measured on an e.g. silicon calibration waver, and the straight-through data. We recommend to provide data that is measured under the same settings as the measurement was performed, that is if Psi and delta are measured for your data, also provide Psi and delta here. And use the same wavelenghts as there. @@ -148,7 +135,8 @@ - The wavelength or equivalent values (which are inter-convertible). The importer should convert all to one unit, and make the others accessible. Historically, energy is used in eV, but for visible spectroscopy wavelength is more common, for IR wave numbers in 1/cm units. Possibly use the same type of data as for the measurement! + The wavelength or equivalent values (which are inter-convertible). The importer should convert all to one unit, and make the others accessible. Historically, energy is used in eV, but for visible spectroscopy wavelength is more common, for IR wave numbers in 1/cm units. +Possibly use the same type of data as for the measurement! @@ -183,7 +171,10 @@ - The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). This transformation brings us from the NEXUS coordinates to the stage coordinates. Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) Last, provide the rotations of the sample + The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). +This transformation brings us from the NEXUS coordinates to the stage coordinates. +Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) +Last, provide the rotations of the sample If there is no motorized stage, we should at least qualify where the beam hits the sample and in what direction the sample stands in a free-text description, e.g. 'center of sample, long edge parallel to plane of incidence'. @@ -274,7 +265,7 @@ Ideally, a reference to the location or a unique (globally persistent) identifier (e.g.) of e.g. another file which gives as many as possible details of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample is not available, use this field as a free-text description to specify details of the sample and its preparation. - ISO 8601 date with time zone specified. UTC offset should be specifiec. + ISO 8601 date with time zone specified. Qualitative description of the layer structure for the sample. For example: Si/native oxide/thermal oxide/polymer/peptide @@ -294,13 +285,15 @@ - Wavelength value(s) used for the measurement. An array of 1 or more elements. Length defines N_wavelength + Wavelength value(s) used for the measurement. + An array of 1 or more elements. Length defines N_wavelength - Resulting data from the measurement, described by data type. Minimum two columns containing Psi and delta, or for the normalized Mueller matrix, it may be 16 (or 15 if 1,1 is all 1). + Resulting data from the measurement, described by data type. + Minimum two columns containing Psi and delta, or for the normalized Mueller matrix, it may be 16 (or 15 if 1,1 is all 1). @@ -325,7 +318,7 @@ Describe what was the medium above or around the sample. The common model is built up from substrate to the medium on the other side. Both boundaries are assumed infinite in the model. Here define the name of the material (e.g. water, air, etc.). - + Array of pairs of complex refractive indices of the medium for every measured wavelength. Only necessary if the measurement was performed not in air, or something very well known, e.g. high purity water. Specify the complex refractive index: n + ik @@ -354,7 +347,8 @@ Specify the source for the external excitation - Wavelength value(s) or the range used for excitation. In cases of continuous laser radiation a value or a set of values may do but for other illumination types, such as pulsed lasers, or lamps, a range may describe the source better. + Wavelength value(s) or the range used for excitation. + In cases of continuous laser radiation a value or a set of values may do but for other illumination types, such as pulsed lasers, or lamps, a range may describe the source better. Specify the FWHM of the excitation @@ -395,11 +389,8 @@ light loss due to depolarization as a value in [0-1] - - A default view of the data, in this case wavelength vs. Psi and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. - - We recommend to use wavelength as a default attribute, but it can be replaced in the case of not full spectral ellipsometry to any suitable parameter along the X-axis. - - + + + A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. diff --git a/contributed_definitions/NXem_nion.nxdl.xml b/contributed_definitions/NXem_nion.nxdl.xml new file mode 100644 index 0000000000..e602a1d6ca --- /dev/null +++ b/contributed_definitions/NXem_nion.nxdl.xml @@ -0,0 +1,577 @@ + + + + (Scanning) transmission electron microscopy with a Nion instrument. + + + Number of pixel in the x direction + + + Number of pixel in the y direction + + + Physical size of a pixel in x direction + + + Physical size of a pixel in y direction + + + + + Official NeXus NXDL schema to which this entry conforms. + + Version specifier which enables documentation of modifications to the + schema. + + + + Ideally, a (globally) persistent unique identifier for referring to + this experiment. The identifier is usually defined/issued by the + facility, laboratory, or the principle investigator. The identifier + enables to link experiments to e.g. proposals. + + + Possibility for leaving a free-text description about the experiment. + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than writing these details in + prose into this field. + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the experiment started. If the application + demands that time codes in this section of the application definition + should only be used for specifying when the experiment was performed - + and the exact duration is not relevant - this start time field should + be used. Often though it is useful to specify a time interval with + specifying both start_time and end_time to allow for more detailed + bookkeeping and interpretation of the experiment. The user should be + aware that even with having both time instances specified, it may not + be possible to infer how long the experiment took or for how long data + were acquired. More detailed timing data over the course of the + experiment have to be collected to compute this. + + + ISO 8601-formatted time code with local time zone offset to UTC + included when the experiment ended. + + + Commercial or otherwise given name to the program which was used to + acquire/measure the dataset. Electron microscopy experiments are + usually controlled/performed via commercial integrated acquisition and + instrument control software. In many cases, an EM dataset is useful + only if gets post-processed already during the acquisition or shortly + thereafter, i.e. while the scientists is still sitting at the + microscope. Many of these processes are automated, if not they + virtually involve GUI interactions with the control software. Examples + include collecting of diffraction pattern and on-the-fly indexing of + these. These situations and tools are realized with individual + NXprocess groups which can hold more details and numerical data to + these processing steps. Frequently, some of these NXprocess groups are + performed with (open-source) research software. Therefore, there is + strictly speaking not a single program used in electron microscopy, + and thus each NXprocess needs its own program, with version and + description." + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result file is + numerically recreatable in the same deterministic manner. + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold e.g. a ppt, pdf, latex, txt, image, or zip + archive ...). + + + A small image that is representative of the entry. This can be an + image from the dataset or a thumbnail of a spectrum. Either way it is + recommended to use 640x480 pixel jpeg image. Adding a scale bar to + that image is recommended but not required as the main purpose of the + thumbnail is to provide e.g. thumbnail images for displaying them in + data repositories. + + + + Contact information of at least the user of the instrument who + measured this specimen or the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + Given (first) name and surname of the user. + + + Name of the affiliation of the user at the point in time when the + experiment was performed. + + + Postal address of the affiliation. + + + Email address of the user at the point in time when the experiment was + performed. Given the most permanently used email is recommended. + + + Globally unique identifier of the user as offers by services like + ORCID or ResearcherID. + + + (Business) (tele)phone number of the user at the point in time when + the experiment was performed. + + + Which role does the user have in the place, and at the point in time + when, the experiment was performed (e.g. technician operating the + microscope, student, postdoc, principle investigator, guest ...). + + + + + Descriptive name or identifier with which to distinguish the specimen + from all others and especially the parts from where it was cut. In + cases where the specimen was e.g. site-specifically cut from a sample + or in cases of an instrument session during which multiple specimens + are loaded, the name has to be descriptive enough to resolve which + specimen was investigated and is represented by this NXentry. The user + is advised to store the details how specimens were cut/prepared from + samples in the sample history. + + + Ideally, a reference to the location of or a (globally) persistent + unique identifier of e.g. another file which should document ideally + as many details as possible of the material, its microstructure, and + its thermo-chemo-mechanical processing/preparation history. In the + case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a sub- + set of the entire sample history, i.e. what you would consider being + the key steps and relevant information about the specimen, its + material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + + ISO8601 date and time with local time zone offset to UTC included when + the specimen was prepared. Ideally report the end of the preparation, + i.e. the last known time the measured specimen surface was actively + prepared. Knowing when the specimen was exposed to e.g. specific + atmosphere is especially required for environmentally sensitive + material such as hydrogen-charged specimens or experiments including + tracers with a short half-time. The user is advised to include these + temporal details in the sample_history. + + + Possibility to give an abbreviation of the specimen name field. + + + Use Hill's system for listing elements of the periodic table which are + inside or attached to the surface of the specimen and thus relevant + from a scientific point of view. The purpose of the field is to offer + materials database systems an opportunity to parse the relevant + elements without having to interpret these from the sample history. + + + (Measured) sample thickness + + + + Hard link to a location/locations in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + Metadata and numerical data of not only the microscope but also the + lab in which this microscope is located. + + Given name of the microscope, e.g. NionHermes. + + + Geographic coordinates of the lab or the place where the instrument is + installed using GEOREF geocodes ideally. + + + Manufacturer of the entire instrument to enable e.g. queries in + materials database systems for instrument manufacturers. Usually more + technical details are needed though to specify the instrument, these + should be written into instrument_model and instrument_capabilities. + + + Manufacturer brand/model to enable e.g. queries about microscope + models. See comments on instrument_manufacturer on how to provide + further specification. + + + Hardware name/serial number or hash identifier given by the + manufacturer to identify the instrument. + + + Free-text list possibly multiple terms of functionalities which the + instrument provides. + + + The source which creates the electron beam. + + Voltage relevant to compute the energy of the electrons immediately + after they left the gun. + + + Type of radiation. + + + + + + Emitter type used to create the beam. + + + + + + + + Ideally a reference to (another) file (ideally formatted using also an + application definition) via a link, name, or a (globally) persistent + unique identifier to give further details about the electron gun. + + + + Details of individual apertures in the instrument. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Relevant value from the control software. This is not always just the + diameter of (not even in the case) of a circular aperture but rather a + value from a list of predefined aperture settings which somebody + defined in the control software. Which actual settings are behind + these should be defined for now in the description field. + + + Ideally, a (globally) persistent unique identifier, link, or text to a + resource which gives further details. + + + Affine transformations and geometrical descriptions which detail how + the aperture is placed and arranged in the microscope relative to the + optical axis and beam path. + + + + Details to individual lenses in the microscope. + + Which type describes the type of the lens closest? + + + + + + + + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Ideally an identifier, persistent link, or free text which gives + further details about the lens. + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Conventions from the NXtransformations base class are used. In + principle, the McStas coordinate system is used. The origin of the + coordinate system is placed in the center of the gun pinhole as the + virtual point-like assumed source of the electron beam. A right-handed + coordinate system is assumed whose positive z-axis points in the + direction of the propagating electron beam. The translation actively + brings the coordinate system under depends_on into registration with a + coordinate system in the center of the lens. + + + + Does the microscope have a spherical aberration correction unit and + was it used? + + + Details about an eventual device which corrects spherical aberrations. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Ideally an identifier, link, or free-text which gives further details + about the component. + + + + + + + + + + + + + + + + + + + Principal design of the stage. + + + + + + + + + + + + + + + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Ideally a link to a (globally persistent) unique identifier which + documents or can be used to infer further details of the component. If + such a resource is not available, use this field for a free-text + description and describe further details to the stage. + + + STAGE TILT A. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS + TO BE COMMUNICATED. + + + STAGE TILT B. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS + TO BE COMMUNICATED. + + + STAGEOUTX, Y, Z. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES + REMAINS TO BE COMMUNICATED. + + + + + + + + + Description of the type of the detector e.g. CCD, scintillator, direct + electron, image plate, CMOS. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + + + + + + + + + Free text option to write further details about the detector. + + + + + EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS TO BE + COMMUNICATED. + + + EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS TO BE + COMMUNICATED. + + + EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES AND NION REMAINS TO BE + COMMUNICATED. + + + DETAILS HOW COMPUTED NEEDS TO BE CONFIRMED BY NION. + + + + + Container for reporting individually processed images with the HAADF + detector ? + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + HAADF annulus inner half angle ? + + + HAADF annulus outer half angle ? + + + Description of the scan box which is instructed by the microscope + control software to direct the probe to controlled locations according + to a scan scheme and plan. + + Commercial or otherwise given name to the program which was used to + execute this analysis. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES WHICH SUGGESTIONS TO PUT AS + ENUMERATIONS. + + + + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + Detailed settings of an internal board(s) in the scanbox device. + FURTHER INFORMATION EXCHANGE/DISCUSSIONS WITH NION IS NEEDED TO + ELUCIDATE WHAT THESE ARE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Container for holding an image (stack) taken with the HA(A) ? DF + detector. + + + + + + Image intensity values. + + + + + + + Label for the y axis. + + + Pixel barycenter position x-coordinates. + + + + + + Pixel barycenter position y-coordinates. + + + + + + + + + diff --git a/base_classes/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml similarity index 100% rename from base_classes/NXenergydispersion.nxdl.xml rename to contributed_definitions/NXenergydispersion.nxdl.xml diff --git a/contributed_definitions/NXfib.nxdl.xml b/contributed_definitions/NXfib.nxdl.xml new file mode 100644 index 0000000000..0b602b93bc --- /dev/null +++ b/contributed_definitions/NXfib.nxdl.xml @@ -0,0 +1,67 @@ + + + + Set of devices adding focused-ion beam capabilities to an instrument. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Ideally a reference to persistent documentation which specifies + further details for the device. If this is not available, add a free- + text description to deliver further details about the focused-ion + unit. + + + + The type of source which creates the ion beam. + + + + + + + + Which ionized elements or molecules are ionized to form the beam which + is used to probe or sputter the specimen. Examples are gallium, + helium, neon, argon, krypton, or xenon, O2+. + + + Average/nominal (DISCUSS FURTHER WITH COLLEAGUES) brightness of the + ion beam (at which location?). + + + Ion flux + + + Charge current + + + Ion acceleration voltage upon source exit and entering the vacuum + flight path. + + + NEEDS FURTHER DISCUSSION WITH COLLEAGUES HOW THIS SHOULD BE DEFINED. + + + + A right-handed Cartesian coordinate system is used whose positive + z-axis points in the direction of the ion beam, i.e. towards the + sample. For modelling ion milling it is relevant to document the + illumination vector. NXtransformations offers a place to store how the + ion gun coordinate system has to be rotated to align its positive + z-axis with the positive z-axis of e.g. the electron beam and ion beam + respectively. + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 0000000000..55a699afeb --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,59 @@ + + + + Set of atoms of a molecular ion or fragment in ToF mass spectrometry. + + The symbols used in the schema to specify e.g. dimensions of arrays. + + Maximum number of allowed atoms per (molecular) ion (fragment). + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + 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 a + decreasingly sorted array. The array is filled with zero hash values + indicating unused places. The individual hash values are built with + the following hash function: Hashvalue = Z + N*256 with Z the number + of protons and N the number of neutrons of the isotope respectively. Z + and N have to be 8-bit unsigned integers. + + + + + + Signed charge state of the ion in multiples of the elementary 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. 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 but report an integer with the atom type which can be used + to compute the charge state via the theoretically-known mass-to- + charge-state-ratios of the elements. + + + Human-readable ion type name (e.g. Al +++), i.e. ASCII UTF-8 character + array, ideally using LaTeX notation to specify the ion 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, the isotope_vector should be the + preferred machine-readable format in 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 labelled as an ion of the here referred to + ion_type. + + + + + + diff --git a/base_classes/NXlens.nxdl.xml b/contributed_definitions/NXlens.nxdl.xml similarity index 100% rename from base_classes/NXlens.nxdl.xml rename to contributed_definitions/NXlens.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 0000000000..20c8e90d1e --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,44 @@ + + + + An electro-magnetic lens. + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Ideally an identifier, persistent link, or free text which gives + further details about the lens. + + + Collection of axis-based translations and rotations to describe the + location and geometry of the corrector as a component in the + instrument. Conventions from the NXtransformations base class are + used. In principle, the McStas coordinate system is used. The origin + of the coordinate system is placed in the center of the gun pinhole as + the virtual point-like assumed source of the electron beam. A right- + handed coordinate system is assumed whose positive z-axis points in + the direction of the propagating electron beam. The translation + actively brings the coordinate system under depends_on into + registration with a coordinate system in the center of the lens. + + diff --git a/base_classes/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml similarity index 100% rename from base_classes/NXmanipulator.nxdl.xml rename to contributed_definitions/NXmanipulator.nxdl.xml diff --git a/applications/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml similarity index 100% rename from applications/NXmpes.nxdl.xml rename to contributed_definitions/NXmpes.nxdl.xml diff --git a/applications/NXmpes_ARPES.nxdl.xml b/contributed_definitions/NXmpes_ARPES.nxdl.xml similarity index 100% rename from applications/NXmpes_ARPES.nxdl.xml rename to contributed_definitions/NXmpes_ARPES.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml new file mode 100644 index 0000000000..8942cb0f43 --- /dev/null +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -0,0 +1,45 @@ + + + + Description of peaks, their functional form or measured support. + + The symbols used in the schema to specify e.g. dimensions of arrays. + + Number of support points + + + + Human-readable identifier to specify which concept/entity the peak + identifies. + + + Is the peak described analytically via a functional form or is it + described empirically via measured/reported intensity/counts as a + function of an independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the positions were independent variable values were + taken. + + + + + + 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 this group can be used to + hold parameter of the functional form. For example in the case of + Gaussian peaks mu, sigma, and cut-off values and background intensity. + + diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml new file mode 100644 index 0000000000..201525edef --- /dev/null +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -0,0 +1,89 @@ + + + + Laser-, voltage-, or combined- pulsing to trigger field evaporation. + + The symbols used in the schema to specify e.g. dimensions of arrays. + + Total number of ions collected. + + + + How evaporation is physically triggered. + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a combination + of pulsing strategies to trigger the excitation and eventual field + evaporation/emission of an ion in an atom probe microscopy experiment. + # Many microscopes have a laser installed which enables measurements + also with poorly conductive specimens. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Nominal wavelength of the laser radiation. + + + Average power of the laser source while illuminating the specimen. + + + Average (??) energy of the laser at peak of (each) ?? pulse. + + + Set of transformations which describe the geometry between how the + laser focusing optics/pinhole-attached coordinate system is defined, + how it has to be transformed so that it aligns with the specimen + coordinate system. A right-handed Cartesian coordinate system, the so- + called laser space, should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + Details about specific positions along the focused laser beam which + illuminates the atom probe specimen. + + Track time-dependent settings over the course of the measurement where + the laser beam exits the focusing optics. + + + Track time-dependent settings over the course of the measurement where + the laser hits the specimen. + + + + Frequency with which the high voltage or laser pulser fires. + + + Fraction of the pulse_voltage that is applied in addition to the + standing_voltage at peak voltage of a pulse. + + + NEED TO DISCUSS WITH APM COLLEAGUES IN MORE DETAIL WHAT THIS IS + SPECIFICALLY! + + + + + + Direct current voltage between the specimen and the (local electrode) + in the case of a LEAP instrument. + + + + + diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml new file mode 100644 index 0000000000..1c531d5471 --- /dev/null +++ b/contributed_definitions/NXpump.nxdl.xml @@ -0,0 +1,15 @@ + + + + Device to create reduce an atmosphere to a controlled remaining + pressure level. + + Principle type of the pump. + + + + + + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 0000000000..56faa37d96 --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,31 @@ + + + + Device for reducing flight time differences of ions in ToF + experiments. + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Free-text field to specify further details about the reflectron. The + quantity can inform for instance if the reflectron is flat or curved. + + + Affine transformation(s) which detail where the reflectron is located + relative to e.g. the origin of the specimen space reference coordinate + system. This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. The purpose of these more + detailed instrument descriptions is to support the creation of a + digital twin of the instrument for computational science. + + diff --git a/base_classes/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 100% rename from base_classes/NXregistration.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml new file mode 100644 index 0000000000..ababf47534 --- /dev/null +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -0,0 +1,64 @@ + + + + Scan unit in an electron microscope which controls the electron beam. + + + Number of pixel in the x direction + + + Number of pixel in the y direction + + + Physical size of a pixel in x direction + + + Physical size of a pixel in y direction + + + Description of the scan box which is instructed by the microscope + control software to direct the probe controlled locations according to + a scan scheme. + + Commercial or otherwise given name to the program which was used to + execute this analysis. + + Ideally program version plus build number, or commit hash or + description of ever persistent resources where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this + computational process is recreatable in the same deterministic manner. + + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES WHICH SUGGESTIONS TO PUT AS + ENUMERATIONS. + + + + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + diff --git a/base_classes/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml similarity index 100% rename from base_classes/NXspindispersion.nxdl.xml rename to contributed_definitions/NXspindispersion.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 0000000000..6fd8c7936c --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,87 @@ + + + + Device which holds, aligns, orients, and imposes stimuli on a + specimen. Modern stages are multi-functional devices. Many of which + offer a controlled environment around (a part) of the specimen and + enable experimentalists to apply stimuli. Having an own candidate + class is justified as contemporary specimen/sample stages are such + multi-purpose/-functional tools with multiple actuators, sensors, + components. With such stages comes the need for storing various + (meta)data that are generated with 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 for + instance, researchers may work with wire samples which are clipped + into a larger fixing unit for convenience and 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. The + NXstage_lab class here reflects two layers of this hierarchy. 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. Applied to examples, a nanoparticle + is attached on a copper grid. The copper grid is the holder. The grid + itself is fixed to the stage. An atom probe specimen is fixed in a + stub. In this case the stub can be considered as the holder, while the + cryostat temperature control unit reads more as the stage. A microtip + on a microtip array is an example of a three-layer hierarchy commonly + employed for efficient sequential processing of atom probe + experiments. For a single experiment though only one microtip of the + array at a time can be measured. Therefore, the microtip is the + specimen, the array the holder and the remaining mounting unit that is + attached to the cryo-controller the stage. To cover for an as flexible + design of these complex lab-like modern 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 the stage. Similar complex situations are common in advanced + electron microscopy. Samples are placed on chips with read-out + electronics which act 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. + + Principal design of the stage. + + + + + + + + + + + + + + + + + Given name. + + + Given brand or model name by the manufacturer. + + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + + + Given name of the manufacturer. + + + Ideally a link to a (globally persistent) unique identifier which + documents or can be used to infer further details of the component. If + such a resource is not available, use this field for a free-text + description and describe further details to the stage. + + + Set of transformations which describe how the stage-affixed coordinate + system is defined and how it has to be transformed so that it aligns + with the specimen coordinate system. + + + diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index f448de8fc8..66c18d93fd 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -8,6 +8,7 @@ Atom Probe Microscopy Structure IntroductionAPM ApmNewAppDef ApmNewBC + ApmRemovedBC @@ -38,8 +39,8 @@ We developed new base classes to structure the application definition into lab e :ref:`NXion`: A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described.: - :ref:`NXlens_apm`: - A base class to describe an eventual reflectron device that influences the flight path of evaporated ions. + :ref:`NXreflectron`: + A base class to describe an optional reflectron device that influences the flight path of evaporated ions. :ref:`NXpeak`: A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. @@ -51,9 +52,19 @@ We developed new base classes to structure the application definition into lab e A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage` base class is insufficiently detailed to represent the functionalities which modern stages of an atom probe microscope or especially an electron microscopy offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and in an atom probe, given that both offer fixture functionalities and additional components such as for applying stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. + :ref:`NXchamber`: + A base class to describe a component of the instrument which houses other components. A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. + + :ref:`NXpump`: + A base class to describe a component which reduce the partial/total pressure in a chamber to some controlled value so that an experiment can be performed. Most commonly this class can be used for representing and storing details of e.g. the vacuum pumping system. + Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. +Removed base classes +###################### + +We have removed the NXlens_apm base class and replaced it by NXreflectron. .. https://stackoverflow.com/questions/4783814/how-to-comment-a-string-in-restructured-text \ No newline at end of file diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst index e099ce7be3..bf92e3d3f8 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/ellipsometry-structure.rst @@ -50,10 +50,10 @@ We created one application definition: .. _ExtendedBC: -Extended Base Classes -####################### +Base Classes Extended in Application Definitions +################################################### -We added descriptors to existing NeXus base classes: +We use existent base classes in application definitions and add descriptors: :ref:`NXinstrument` Added fields to add information that is important for an ellipsometry setup, such as the ellipsometer type, the light source, the type of the sample stage, or the angle(s) of incidence, as well as information on calibration, focussing probes, data correction etc. diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index fc2d4c428b..31dbb72541 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -84,10 +84,10 @@ We developed two classes that are common to other techniques: .. _ExtendedBC: -Extended Base Classes -####################### +Base Classes Extended in Application Definitions +################################################### -We added descriptors to existing NeXus base classes: +We use existent base classes in application definitions and add descriptors: :ref:`NXaperture` Added fileds to describe analyser apertures and slits. From bf7fcf061ab9ece6f95da032536ebc234c3a36f4 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Thu, 31 Mar 2022 16:46:43 +0200 Subject: [PATCH 021/203] Fixed single line docstring scanbox and stage_lab --- contributed_definitions/NXscanbox_em.nxdl.xml | 3 - contributed_definitions/NXstage_lab.nxdl.xml | 97 ++++++++++--------- 2 files changed, 49 insertions(+), 51 deletions(-) diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index ababf47534..4198a3c34c 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -16,9 +16,6 @@ Physical size of a pixel in y direction - Description of the scan box which is instructed by the microscope - control software to direct the probe controlled locations according to - a scan scheme. Commercial or otherwise given name to the program which was used to execute this analysis. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 6fd8c7936c..57df7fd08f 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -1,49 +1,44 @@ - Device which holds, aligns, orients, and imposes stimuli on a - specimen. Modern stages are multi-functional devices. Many of which - offer a controlled environment around (a part) of the specimen and - enable experimentalists to apply stimuli. Having an own candidate - class is justified as contemporary specimen/sample stages are such - multi-purpose/-functional tools with multiple actuators, sensors, - components. With such stages comes the need for storing various - (meta)data that are generated with 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 for - instance, researchers may work with wire samples which are clipped - into a larger fixing unit for convenience and 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. The - NXstage_lab class here reflects two layers of this hierarchy. 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. Applied to examples, a nanoparticle - is attached on a copper grid. The copper grid is the holder. The grid - itself is fixed to the stage. An atom probe specimen is fixed in a - stub. In this case the stub can be considered as the holder, while the - cryostat temperature control unit reads more as the stage. A microtip - on a microtip array is an example of a three-layer hierarchy commonly - employed for efficient sequential processing of atom probe - experiments. For a single experiment though only one microtip of the - array at a time can be measured. Therefore, the microtip is the - specimen, the array the holder and the remaining mounting unit that is - attached to the cryo-controller the stage. To cover for an as flexible - design of these complex lab-like modern 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 the stage. Similar complex situations are common in advanced - electron microscopy. Samples are placed on chips with read-out - electronics which act 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. + + Device which holds, aligns, orients, stimulates a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled environment + around (a part) of the specimen and enable experimentalists to apply stimuli. Having an + own candidate class is justified as contemporary specimen/sample stages are such multi- + purpose/-functional tools with multiple actuators, sensors, components. With such stages + comes the need for storing various (meta)data that are generated with 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 for instance, researchers may work with wire samples which are + clipped into a larger fixing unit for convenience and 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. carousel is a carrier unit with which + eventually entire sets of specimens can be moved in between parts of the microscope. The + NXstage_lab class here reflects two layers of this hierarchy. 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. Applied to examples, a + nanoparticle is attached on a copper grid. The copper grid is the holder. The grid itself + is fixed to the stage. An atom probe specimen is fixed in a stub. In this case the stub + can be considered as the holder, while the cryostat temperature control unit reads more as + the stage. A microtip on a microtip array is an example of a three-layer hierarchy + commonly employed for efficient sequential processing of atom probe experiments. For a + single experiment though only one microtip of the array at a time can be measured. + Therefore, the microtip is the specimen, the array the holder and the remaining mounting + unit that is attached to the cryo-controller the stage. To cover for an as flexible design + of these complex lab-like modern 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 the stage. Similar complex situations are common in + advanced electron microscopy. Samples are placed on chips with read-out electronics which + act 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. + - Principal design of the stage. + Principal design of the stage. + @@ -60,28 +55,34 @@ - Given name. + Given name. + - Given brand or model name by the manufacturer. + Given brand or model name by the manufacturer. + Given hardware name/serial number or hash identifier issued by the - manufacturer. + manufacturer. + - Given name of the manufacturer. + Given name of the manufacturer. + Ideally a link to a (globally persistent) unique identifier which documents or can be used to infer further details of the component. If such a resource is not available, use this field for a free-text - description and describe further details to the stage. + description and describe further details to the stage. + Set of transformations which describe how the stage-affixed coordinate system is defined and how it has to be transformed so that it aligns - with the specimen coordinate system. + with the specimen coordinate system. + From 09ae1f0a196d55f8b51847cd2647cded359ac1c4 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Thu, 31 Mar 2022 20:23:31 +0200 Subject: [PATCH 022/203] Recovered NXdeflector, edited structure.rst from FAIRmat hunted for NXsample, NXmirror --- contributed_definitions/NXapm.nxdl.xml | 839 +++++++++---- contributed_definitions/NXchamber.nxdl.xml | 28 +- .../NXcorrector_cs.nxdl.xml | 34 +- contributed_definitions/NXdeflector.nxdl.xml | 86 ++ .../NXellipsometry.nxdl.xml | 1087 +++++++++++------ contributed_definitions/NXem_nion.nxdl.xml | 536 +++++--- contributed_definitions/NXfib.nxdl.xml | 68 +- contributed_definitions/NXion.nxdl.xml | 46 +- contributed_definitions/NXlens_em.nxdl.xml | 38 +- contributed_definitions/NXpeak.nxdl.xml | 42 +- contributed_definitions/NXpulser_apm.nxdl.xml | 98 +- contributed_definitions/NXpump.nxdl.xml | 9 +- contributed_definitions/NXreflectron.nxdl.xml | 35 +- contributed_definitions/NXscanbox_em.nxdl.xml | 70 +- contributed_definitions/NXstage_lab.nxdl.xml | 21 +- manual/source/apm-structure.rst | 7 +- manual/source/em-structure.rst | 2 +- manual/source/mpes-structure.rst | 2 +- 18 files changed, 2078 insertions(+), 970 deletions(-) create mode 100644 contributed_definitions/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index c51c2a40dd..e11d65c8a0 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -1,48 +1,74 @@ - Atom probe tomography and field-ion microscopy experiments. + + Atom probe tomography and field-ion microscopy experiments. + - The symbols used in the schema to specify e.g. dimensions of arrays + + The symbols used in the schema to specify e.g. dimensions of arrays + - Total number of ions collected + + Total number of ions collected + - Total number of independent wires in the delay-line detector. + + Total number of independent wires in the delay-line detector. + - Number of support points for e.g. modeling peaks in the mass-to-charge-state ratio histogram. + + Number of support points for e.g. modeling peaks in the mass-to- + charge-state ratio histogram. + - Maximum number of allowed atoms per (molecular) ion (fragment). Needs to match maximum_number_of_atoms_per_molecular_ion. + + Maximum number of allowed atoms per (molecular) ion (fragment). Needs + to match maximum_number_of_atoms_per_molecular_ion. + - Number of mass-to-charge-state-ratio range intervals mapped on this ion type. + + Number of mass-to-charge-state-ratio range intervals mapped on this + ion type. + - Official NeXus NXDL schema to which this entry conforms. + + Official NeXus NXDL schema to which this entry conforms. + - Version specifier which enables documentation of modifications to the - schema. + + Version specifier which enables documentation of modifications to the + schema. + - Ideally, a (globally) persistent unique identifier for referring to + + Ideally, a (globally) persistent unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier - enables to link experiments to e.g. proposals. + enables to link experiments to e.g. proposals. + - Possibility for leaving a free-text description about the experiment. + + Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in - prose into this field here. + prose into this field here. + - ISO 8601 formatted time code with local time zone offset to UTC + + ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - @@ -53,14 +79,18 @@ aware that even with having both time instances specified it may not be advisable to infer how long the experiment took or for how long data were acquired. More detailed timing data over the course of the - experiment have to be collected for such a detailed bookkeeping. + experiment have to be collected for such a detailed bookkeeping. + - ISO 8601-formatted time code with local time zone offset to UTC - included when the experiment ended. + + ISO 8601-formatted time code with local time zone offset to UTC + included when the experiment ended. + - Commercial or otherwise given name to the program that was used to + + Commercial or otherwise given name to the program that was used to acquire/measure the dataset. Atom probe microscopy experiments are nowadays still in most cases controlled via commercial software. These are often designed as integrated acquisition and instrument control @@ -94,17 +124,21 @@ the early data acquisition and processing stages until one arrives at a useful reconstructed and ranged dataset. Therefore, the application definition documents not only the measurement but also these key post- - processing steps. + processing steps. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is - numerically recreatable in the same deterministic manner. + numerically recreatable in the same deterministic manner. + - Not the specimen name or the experiment identifier but the identifier + + Not the specimen name or the experiment identifier but the identifier through which the experiment is referred to in the control software. For LEAP instruments it is recommended to use the IVAS/AP Suite run number. For other instruments, such as the one from Stuttgart or @@ -114,26 +148,33 @@ however, to interrupt a run and restart data acquisition while still using the same specimen. In this case, each evaporation run needs to be distinguished with different run numbers. # This is how most atom - probe groups handle it across the globe. + probe groups handle it across the globe. + - Binary container for a file or a compressed collection of files which + + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip - archive ...). + archive ...). + - A small image that is representative of the entry. For reconstructed + + A small image that is representative of the entry. For reconstructed datasets it is recommended to display the reconstruction as a 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. - thumbnail images for displaying them in data repositories. + thumbnail images for displaying them in data repositories. + - What type of atom probe microscope experiment is performed. This field + + What type of atom probe microscope experiment is performed. This field can be used e.g. by materials database systems to qualitatively filter - experiments. + experiments. + @@ -142,50 +183,69 @@ - Contact information of at least the user of the instrument who + + Contact information of at least the user of the instrument who measured this specimen or the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. + this experiment. Adding multiple users if relevant is recommended. + - Given (first) name and surname of the user. + + Given (first) name and surname of the user. + - Name of the affiliation of the user at the point in time when the - experiment was performed. + + Name of the affiliation of the user at the point in time when the + experiment was performed. + - Postal address of the affiliation. + + Postal address of the affiliation. + - Email address of the user at the point in time when the experiment was - performed. Giving the most permanently used email is recommended. + + Email address of the user at the point in time when the experiment was + performed. Giving the most permanently used email is recommended. + - Globally unique identifier of the user as offers by services like - ORCID or ResearcherID. + + Globally unique identifier of the user as offers by services like + ORCID or ResearcherID. + - (Business) (tele)phone number of the user at the point in time when - the experiment was performed. + + (Business) (tele)phone number of the user at the point in time when + the experiment was performed. + - Which role does the user have in the place, or did the user hold when, + + Which role does the user have in the place, or did the user hold when, the experiment was performed (e.g. technician operating the - microscope, student, postdoc, principle investigator, guest ...). + microscope, student, postdoc, principle investigator, guest ...). + - Descriptive name or identifier with which to distinguish the specimen + + Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen on e.g. the microtip array was taken. The user is advised to store the details how specimens were cut/prepared from samples in the - sample history. + sample history. + - Ideally, a reference to the location of or a (globally persistent) + + Ideally, a reference to the location of or a (globally persistent) unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the @@ -194,35 +254,45 @@ set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and - details of the preparation. + details of the preparation. + - ISO8601 date and time with local time zone offset to UTC included when + + ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these - temporal details in the sample_history. + temporal details in the sample_history. + - Possibility to give an abbreviation of the specimen name field. + + Possibility to give an abbreviation of the specimen name field. + - Use Hill's system for listing elements of the periodic table which are + + Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus considered relevant from a scientific point. The purpose of the field is to offer materials database systems an opportunity to parse the relevant - elements without having to interpret these from the sample history. + elements without having to interpret these from the sample history. + - Hard link to a location/locations in the hierarchy of the NeXus file - where the data for default plotting are stored. + + Hard link to a location/locations in the hierarchy of the NeXus file + where the data for default plotting are stored. + - Metadata and numerical data of not only the microscope but also the + + Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. An atom probe microscope (experiment) is different compared to a large-scale facility accelerator or an electron microscope in at least two ways. First, @@ -239,36 +309,51 @@ define that the positive z-axis points outwards from the apex of the specimen into the vacuum, i.e. towards the detector. The coordinate system remains/is a right-handed one. Clockwise rotations are - considered positive rotations. + considered positive rotations. + - Given name of the microscope, e.g Raptor, Oxcart, One atom at a time. + + Given name of the microscope, e.g Raptor, Oxcart, One atom at a time. + - Geographic coordinates of the lab or the place where the instrument is - installed using GEOREF geocodes ideally. + + Geographic coordinates of the lab or the place where the instrument is + installed using GEOREF geocodes ideally. + - Manufacturer of the entire instrument (e.g. AMETEK/Cameca) to enable + + Manufacturer of the entire instrument (e.g. AMETEK/Cameca) to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model - and instrument_capabilities. + and instrument_capabilities. + - Manufacturer brand/model to enable e.g. queries about microscope - models (e.g. LEAP3000XS). + + Manufacturer brand/model to enable e.g. queries about microscope + models (e.g. LEAP3000XS). + - Hardware name/serial number or hash identifier given by the - manufacturer to identify the instrument. + + Hardware name/serial number or hash identifier given by the + manufacturer to identify the instrument. + - Free-text list possibly multiple terms of functionalities which the - instrument provides. + + Free-text list possibly multiple terms of functionalities which the + instrument provides. + - The space inside the atom probe that ions pass through when they leave - the specimen and travel to the detector. + + The space inside the atom probe that ions pass through when they leave + the specimen and travel to the detector. + @@ -278,79 +363,112 @@ - Device for reducing flight time differences of ions in ToF - experiments. + + Device for reducing flight time differences of ions in ToF + experiments. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Free-text field to specify further details about the reflectron. The - quantity can inform for instance if the reflectron is flat or curved. + + Free-text field to specify further details about the reflectron. The + quantity can inform for instance if the reflectron is flat or curved. + - Affine transformation(s) which detail where the reflectron is located + + Affine transformation(s) which detail where the reflectron is located relative to e.g. the origin of the specimen space reference coordinate system. This group can also be used for specifying how the reflectron is rotated relative to the specimen axis. The purpose of these more detailed instrument descriptions is to support the creation of a - digital twin of the instrument for computational science. + digital twin of the instrument for computational science. + - NEED FOR FURTHER DISCUSSIONS WITH APM COLLEAGUES WHAT IS RELEVANT - HERE. + + NEED FOR FURTHER DISCUSSIONS WITH APM COLLEAGUES WHAT IS RELEVANT + HERE. + - An (ideally globally persistent) unique identifier, link, or text - which gives further details. + + An (ideally globally persistent) unique identifier, link, or text + which gives further details. + - Details about the detector which is used to collect raw time-of-flight - data and ion/hit impact positions. + + Details about the detector which is used to collect raw time-of-flight + data and ion/hit impact positions. + - Description of the detector type. Specify if the detector is not the - usual type of delay-line detectors. + + Description of the detector type. Specify if the detector is not the + usual type of delay-line detectors. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Amplitude of the signal detected on the multi-channel plate (MCP). + + Amplitude of the signal detected on the multi-channel plate (MCP). This field should be used for storing the signal amplitude quantity within ATO files. The ATO file format is used primarily by the atom - probe groups in Rouen, France. + probe groups in Rouen, France. + - Affine transformation which aligns the Cartesian right-handed + + Affine transformation which aligns the Cartesian right-handed coordinate system which defines the detector space with the specimen space. In atom probe microscopy a frequently used choice is to discuss the so-called detector space image (stack). This is a stack of two- @@ -361,7 +479,8 @@ possibility for inconsistency between the so-called detector coordinate system and a specimen-affixed coordinate system. The transformation here resolves this ambiguity by specifying how the - positive z-axes of either coordinate systems can be oriented. + positive z-axes of either coordinate systems can be oriented. + @@ -373,71 +492,103 @@ - Atom probe microscopes use controlled laser, voltage, or a combination + + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the excitation and eventual field evaporation/emission of an ion in an atom probe microscopy experiment. # Many microscopes have a laser installed which enables measurements - also with poorly conductive specimens. + also with poorly conductive specimens. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Nominal wavelength of the laser radiation. + + Nominal wavelength of the laser radiation. + - Average power of the laser source while illuminating the specimen. + + Average power of the laser source while illuminating the specimen. + - Average (??) energy of the laser at peak of (each) ?? pulse. + + Average (??) energy of the laser at peak of (each) ?? pulse. + - Set of transformations which describe the geometry between how the + + Set of transformations which describe the geometry between how the laser focusing optics/pinhole-attached coordinate system is defined, how it has to be transformed so that it aligns with the specimen coordinate system. A right-handed Cartesian coordinate system, the so- called laser space, should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. + into the direction of the propagating laser beam. + - Details about specific positions along the focused laser beam which - illuminates the atom probe specimen. + + Details about specific positions along the focused laser beam which + illuminates the atom probe specimen. + - Track time-dependent settings over the course of the measurement where - the laser beam exits the focusing optics. + + Track time-dependent settings over the course of the measurement where + the laser beam exits the focusing optics. + - Track time-dependent settings over the course of the measurement where - the laser hits the specimen. + + Track time-dependent settings over the course of the measurement where + the laser hits the specimen. + - Frequency with which the high voltage or laser pulser fires. + + Frequency with which the high voltage or laser pulser fires. + - Fraction of the pulse_voltage that is applied in addition to the - standing_voltage at peak voltage of a pulse. + + Fraction of the pulse_voltage that is applied in addition to the + standing_voltage at peak voltage of a pulse. + - NEED TO DISCUSS WITH APM COLLEAGUES IN MORE DETAIL WHAT THIS IS - SPECIFICALLY! + + NEED TO DISCUSS WITH APM COLLEAGUES IN MORE DETAIL WHAT THIS IS + SPECIFICALLY! + - Direct current voltage between the specimen and the (local electrode) - in the case of a LEAP instrument. + + Direct current voltage between the specimen and the (local electrode) + in the case of a LEAP instrument. + @@ -445,40 +596,57 @@ - Principal design of the stage. + + Principal design of the stage. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Ideally a link to a (globally persistent) unique identifier which + + Ideally a link to a (globally persistent) unique identifier which documents or can be used to infer further details of the component. If such a resource is not available, use this field for a free-text - description and describe further details to the stage. + description and describe further details to the stage. + - Set of transformations which describe how the stage-affixed coordinate + + Set of transformations which describe how the stage-affixed coordinate system is defined and how it has to be transformed so that it aligns - with the specimen coordinate system. + with the specimen coordinate system. + - Average temperature at the specimen base, i.e. base temperature, - during the measurement. + + Average temperature at the specimen base, i.e. base temperature, + during the measurement. + - The majority of atom probe microscopes come from a single commercial + + The majority of atom probe microscopes come from a single commercial manufacturer AMETEK (formerly Cameca). Their instruments are controlled via an(/a set) of integrated instrument control system(s) (APSuite/IVAS/DAVis). By contrast, instruments which were built by @@ -495,18 +663,24 @@ motivates the current design of the application definition which stores quantities to begin with via an NXcollection. Holding heterogeneous, not yet standardized, but relevant pieces of - information is the purpose of this collection. + information is the purpose of this collection. + - Track time-dependent settings over the course of the measurement about + + Track time-dependent settings over the course of the measurement about the environment in the analysis chamber such as gas pressure values - etc. + etc. + - Average pressure in the analysis chamber. + + Average pressure in the analysis chamber. + - A place where details about the initial shape of the specimen can be + + A place where details about the initial shape of the specimen can be stored. Ideally, here also data about the shape evolution of the specimen can be stored. There are currently very few techniques only to measure the shape evolution: One is via correlative electron @@ -518,21 +692,27 @@ scanning force microscopy methods (pioneered by the imec group, Belgium). A continuous monitoring of the specimen in an correlative electron microscopy/atom probe experiment is planned to be developed - by the Jülich group (Dunin-Borkowski/Gault). + by the Jülich group (Dunin-Borkowski/Gault). + - Ideally measured or best elaborated guess of the initial radius of the - specimen. + + Ideally measured or best elaborated guess of the initial radius of the + specimen. + - Ideally measured or best elaborated guess of the shank angle. This is + + Ideally measured or best elaborated guess of the shank angle. This is a measure of the specimen taper. Define it in such a way that the base of the specimen is modelled as a conical frustrum so that the shank angle is the (shortest) angle between the specimen space z-axis and a - vector on the lateral surface of the cone. + vector on the lateral surface of the cone. + - This group in the hierarchy should be used to store the ion hit + + This group in the hierarchy should be used to store the ion hit positions. Data post-processing step of analog-to-digital conversion of the detector signals into ion hit positions. For AMETEK LEAP instruments this processing takes place partly in the control unit of @@ -542,26 +722,33 @@ applies to the majority of atom probe microscopes, kept proprietary and inaccessible. For instruments build by individual research groups, like the Oxcart instrument, individual timing data from the delay-line - detector are openly accessible. + detector are openly accessible. + - Given name of the program that was used to perform this computation. + + Given name of the program that was used to perform this computation. Although for LEAP instruments this program is often the same software as one would specify under program for the NXentry (usually IVAS or AP Suite), the field is required because in cases where data is post- processed with different software it would not be possible to distinguish which portions of the dataset were computed with which - software. + software. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - Three-dimensional array of raw readings from the analog-to-digital- - converter timing circuits of the detector wires. + + Three-dimensional array of raw readings from the analog-to-digital- + converter timing circuits of the detector wires. + @@ -569,21 +756,26 @@ - Evaluated ion impact coordinates at the detector (either as computed + + Evaluated ion impact coordinates at the detector (either as computed from the arrival time data or as reported as the result of a not necessarily further specified processing within commercial control - software. + software. + - Average detection rate over the course of the experiment. + + Average detection rate over the course of the experiment. + - Data post-processing step which is, like the impact position analyses, + + Data post-processing step which is, like the impact position analyses, also usually executed in the integrated control software. This processing yields how many ions were detected with each pulse. In fact, it is possible that multiple ions evaporate and hit the same or @@ -592,95 +784,125 @@ Multiplicity must not be confused with how many atoms of the same element or isotope, respectively, a molecular ion contains. By contrast, this latter multiplicity is encoded in the (isotope_vector) - field within in a (NXion) instance. + field within in a (NXion) instance. + - Given name of the program that was used to perform this computation. - Similar comments as for ion_impact_positions apply. + + Given name of the program that was used to perform this computation. + Similar comments as for ion_impact_positions apply. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - Number of pulses since the last detected ion pulse. For multi-hit - records, after the first record, this is zero. + + Number of pulses since the last detected ion pulse. For multi-hit + records, after the first record, this is zero. + - Hit multiplicity. + + Hit multiplicity. + - Number of pulses since the start of the atom probe run/evaporation - sequence. + + Number of pulses since the start of the atom probe run/evaporation + sequence. + - Like impact position and hit multiplicity computations, ion filtering + + Like impact position and hit multiplicity computations, ion filtering is a data post-processing step when users identify which of the detected ions should be included in the voltage-and-bowl correction. This post-processing is usually performed via GUI interaction in the reconstruction pipeline of commercial analysis software like - IVAS/APSuite. + IVAS/APSuite. + - Given name of the program that was used to perform this computation. - Similar comments as to hit_multiplicity apply. + + Given name of the program that was used to perform this computation. + Similar comments as to hit_multiplicity apply. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - Bitmask which is set to true if the ion is considered and false - otherwise. + + Bitmask which is set to true if the ion is considered and false + otherwise. + - Data post-processing step to correct for ion impact position flight + + Data post-processing step to correct for ion impact position flight path differences, detector biases, and nonlinearities. Also this step - is usually performed with commercial software. + is usually performed with commercial software. + - Given name of the program that was used to perform this computation. - Similar comments as to ion_filtering apply. + + Given name of the program that was used to perform this computation. + Similar comments as to ion_filtering apply. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - Raw time-of-flight data as read-out from the acquisition software if - these data are or accessible. + + Raw time-of-flight data as read-out from the acquisition software if + these data are or accessible. + - Calibrated time-of-flight. + + Calibrated time-of-flight. + - The key idea and algorithm of the voltage-and-bowl correction is + + The key idea and algorithm of the voltage-and-bowl correction is qualitatively similar for instruments of different manufacturers or research groups. Specific differences exists though in the form of different calibration models. For now we do not wish to resolve or @@ -693,56 +915,75 @@ instrument. Furthermore, one could then also store here the iteratively identified calibrations which scientists will get displayed in e.g. AP Suite while executing the voltage-and-bowl - correction as part of the reconstruction pipeline. + correction as part of the reconstruction pipeline. + - Data post-processing step in which calibrated time-of-flight data - (tof) are interpreted into mass-to-charge-state ratios. + + Data post-processing step in which calibrated time-of-flight data + (tof) are interpreted into mass-to-charge-state ratios. + - Given name of the program that was used to perform this computation. - Similar comments as voltage_and_bowl_correction apply. + + Given name of the program that was used to perform this computation. + Similar comments as voltage_and_bowl_correction apply. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - Like for the voltage-and-bowl correction, this collection should be + + Like for the voltage-and-bowl correction, this collection should be used for storing vendor-specific calibration models if these are - available. + available. + - Mass-to-charge-state ratios + + Mass-to-charge-state ratios + - Data post-processing step to create a tomographic reconstruction of + + Data post-processing step to create a tomographic reconstruction of the specimen based on selected calibrated ion hit positions, the evaporation sequence, and voltage curve data. Very often scientists use own software scripts according to published, so-called reconstruction protocols, i.e. numerical recipes how to compute x, y, - z atomic positions from the input data. + z atomic positions from the input data. + - Given name of the program that was used to perform this computation. - Similar comments as voltage_and_bowl_correction apply. + + Given name of the program that was used to perform this computation. + Similar comments as voltage_and_bowl_correction apply. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - Qualitative statement about which algorithmic approach, i.e. - reconstruction protocol was used. + + Qualitative statement about which algorithmic approach, i.e. + reconstruction protocol was used. + @@ -754,116 +995,158 @@ - Three-dimensional reconstructed positions of the ions. Interleaved - array of x, y, z positions in the specimen space. + + Three-dimensional reconstructed positions of the ions. Interleaved + array of x, y, z positions in the specimen space. + - Different models and associated algorithms, i.e. (numerical) protocols + + Different models and associated algorithms, i.e. (numerical) protocols exist to reconstruct atom probe data. Although these approaches are qualitatively similar, each protocol uses different parameters (and interprets these differently). The source code to IVAS/APSuite is not - open. For now we store the reconstruction parameter in a collection. + open. For now we store the reconstruction parameter in a collection. + - Data post-processing step in which elemental, isotopic, and/or + + Data post-processing step in which elemental, isotopic, and/or molecular identities are assigned to the ions. The documentation of these steps is based on ideas described in the literature (M. K"uhbach - et al. 2021, Microsc. Microanal.). + et al. 2021, Microsc. Microanal.). + - Given name of the program that was used to perform this computation. + + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools been designed for executing this task. Therefore, it is essential to - document which tool was used. + document which tool was used. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - How many ion types are distinguished. + + How many ion types are distinguished. + - Assumed maximum value that suffices to store all relevant molecular - ions, even the most complicated ones. Currently a value of 32 is used. + + Assumed maximum value that suffices to store all relevant molecular + ions, even the most complicated ones. Currently a value of 32 is used. + - Specifies the computation of the mass-to-charge histogram. Usually + + Specifies the computation of the mass-to-charge histogram. Usually mass-to-charge values are studied as an ensemble quantity, specifically these values are binned. The (NXprocess) stores the - settings of this binning. + settings of this binning. + - Given name of the program that was used to perform this binning. If - the computation is a integrated into the ranging tool, type . + + Given name of the program that was used to perform this binning. If + the computation is a integrated into the ranging tool, type . + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - If the version is the same as for the ranging tool, type . + If the version is the same as for the ranging tool, type . + - Smallest and largest mass-to-charge value. + + Smallest and largest mass-to-charge value. + - Binning width + + Binning width + - Details of the background model which was used to correct the total - counts per bin into used counts. + + Details of the background model which was used to correct the total + counts per bin into used counts. + - Given name of the program that was used to perform the background + + Given name of the program that was used to perform the background quantification. If the computation is a integrated into the ranging - tool, type . + tool, type . + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - If the version is the same as for the ranging tool, type . + If the version is the same as for the ranging tool, type . + - How where peaks in the background-corrected mass-to-charge histogram - identified. + + How where peaks in the background-corrected mass-to-charge histogram + identified. + - Given name of the program that was used to search and detect peaks. If - the computation is a integrated into the ranging tool type . + + Given name of the program that was used to search and detect peaks. If + the computation is a integrated into the ranging tool type . + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - If the version is the same as for the ranging tool, type . + If the version is the same as for the ranging tool, type . + - List of peaks. + + List of peaks. + - Human-readable identifier to specify which concept/entity the peak - identifies. + + Human-readable identifier to specify which concept/entity the peak + identifies. + - Is the peak described analytically via a functional form or is it + + Is the peak described analytically via a functional form or is it described empirically via measured/reported intensity/counts as a - function of an independent variable. + function of an independent variable. + @@ -871,66 +1154,85 @@ - In the case of an empirical description of the peak and its shoulders, + + In the case of an empirical description of the peak and its shoulders, this array holds the positions were independent variable values were - taken. + taken. + - 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 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 this group can be used to + + In the case of an analytical description this group can be used to hold parameter of the functional form. For example in the case of - Gaussian peaks mu, sigma, and cut-off values and background intensity. + Gaussian peaks mu, sigma, and cut-off values and background intensity. + - Details about how peaks, with taking into account error models, were - interpreted as an iontype or not. + + Details about how peaks, with taking into account error models, were + interpreted as an iontype or not. + - Given name of the program that was used to perform identify peaks. If - the computation is a integrated into the ranging tool, type . + + Given name of the program that was used to perform identify peaks. If + the computation is a integrated into the ranging tool, type . + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. - If the version is the same as for the ranging tool, type . + If the version is the same as for the ranging tool, type . + - The individual ions and their set of mass-to-charge intervals + + The individual ions and their set of mass-to-charge intervals (ranges). If ranging was performed as a computational step then the NeXus-writing software needs to assure that there is always a default ion type which is the unknown ion type. By definition this unknown type has 0 as the id and a default associated mass-to-charge-state - ratio interval of [0, 0.001] Da. + ratio interval of [0, 0.001] Da. + - Ion type (ion species) identifier. The identifier zero is reserved for - the special unknown ion type. + + 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 a + + A vector of isotope hash values. These values have to be stored in a decreasingly sorted array. The array is filled with zero hash values indicating unused places. The individual hash values are built with the following hash function: Hashvalue = Z + N*256 with Z the number of protons and N the number of neutrons of the isotope respectively. Z - and N have to be 8-bit unsigned integers. + and N have to be 8-bit unsigned integers. + - Signed charge state of the ion in multiples of the elementary electron + + Signed charge state of the ion in multiples of the elementary 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 @@ -939,21 +1241,26 @@ probe data. These file formats do not document the charge state explicitly but report an integer with the atom type which can be used to compute the charge state via the theoretically-known mass-to- - charge-state-ratios of the elements. + charge-state-ratios of the elements. + - Human-readable ion type name (e.g. Al +++), i.e. ASCII UTF-8 character + + Human-readable ion type name (e.g. Al +++), i.e. ASCII UTF-8 character array, ideally using LaTeX notation to specify the ion 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, the isotope_vector should be the - preferred machine-readable format in use. + preferred machine-readable format in use. + - Associated lower (mqmin) and upper (mqmax) bounds of mass-to-charge- + + 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 labelled as an ion of the here referred to - ion_type. + ion_type. + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml index e3e2cf1a49..c7fbbdf134 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -1,22 +1,34 @@ - Component of an instrument to store or place objects and specimens. + + Component of an instrument to store or place objects and specimens. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Describe details about the chamber, for instance out of which material - it was built. + + Describe details about the chamber, for instance out of which material + it was built. + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 415e29a39f..e3d65fa2ba 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -1,26 +1,39 @@ - Device for correcting spherical aberrations in an electron microscope. + + Device for correcting spherical aberrations in an electron microscope. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Ideally an identifier, link, or free-text which gives further details - about the component. + + Ideally an identifier, link, or free-text which gives further details + about the component. + - Collection of axis-based translations and rotations to describe the + + Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin @@ -29,7 +42,8 @@ handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. The translation actively brings the coordinate system under depends_on into - registration with the reference coordinate system in the gun. + registration with the reference coordinate system in the gun. + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml new file mode 100644 index 0000000000..78bee2f44f --- /dev/null +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -0,0 +1,86 @@ + + + + + Electro-static deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of lens with respect to the number of pole pieces + + + + + + + + + + + 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. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the corrector as a component in the + instrument. Conventions from the NXtransformations base class are + used. In principle, the McStas coordinate system is used. The origin + of the coordinate system is placed in the center of the gun pinhole as + the virtual point-like assumed source of the electron beam. A right- + handed coordinate system is assumed whose positive z-axis points in + the direction of the propagating electron beam. + + + + + Following transformation_type argument of NXtranslations but allowed + value is only translation. + + + + + Following vector argument of NXtranslations. The translation actively + brings the coordinate system under depends_on into registration with a + coordinate system in the center of the lens. + + + + + Enter the path where the reference coordinate system for the + instrument is defined. + + + + + diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index f7e69dbbe8..c43de1e65a 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -1,396 +1,697 @@ - - Draft application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. - - Variables used throughout the document, e.g. dimensions and important parameters - - - - - - - - This is the application definition describing ellipsometry experiments. Such experiments may be as simple as identifying how a reflected beam of light with a single wavelength changes its polarization state, to a variable angle spectroscopic ellipsometry experiment. - -The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description - - Unique identifier of the experiment, such as a (globally persistent) unique identifier. - The identifier is usually defined by the facility or principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Commercial or otherwise defined given name to the program that was used to generate the results file(s) with measured data and metadata (or a link to the instrument software). - - Either version with build number, commit hash, or description of a (online) repository where the source code of the program and build instructions can be found so that the program can be configured in such a way that result files can be created ideally in a deterministic manner. - - - Website of the software. - - - - FAIRmat-specific candidate proposal for an application definition exemplifying ellipsometry. For example: https://gitlab.mpcdf.mpg.de/nomad-lab/areab-appdef/-/blob/spectroscopic-ellipsometry-consolidation/optical_spectroscopy - - Ideally version with build number are commit hash of the application definition. If not available a free-text description. - - - URL where to find further material (documentation, examples) relevant to the application definition - - - - Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. - - - Name of the affiliation of the user at the point in time when the experiment was performed. - - - - - - - - General properties of the ellipsometry equipment - - The name of the instrument - - The used version of the hardware if available. If not a commercial instrument use date of completion of the hardware. - - - - Name of the company which build the instrument - - - ISO8601 date when the instrument was constructed - - - Name (e.g. commercial) of the software that was used for the measurement - - Version and build number or commit hash of the software source code - - - Website of the software. - - - - Specify the used light source. Multiple selection possible. - - - - - - - - - - - If you specified 'other' as light source type, please write down what it is. - - - Were focussing probes (lenses) used or not? - - - Were the recorded data corrected by the window effects of the lenses or not? - - - Specify the angular spread caused by the focussing probes - - - What type of ellipsometry was used? See Fujiwara Table 4.2 - - - - - - - - - - - - - - - - - Ellipsometers require regular calibration to adjust the hardware parameters for proper zero values and background light compensation. - - ISO8601 datum when calibration was last performed before this measurement - - - Arrays which provide the measured calibration data. Multiple sets are possible, e.g. Psi and delta measured on an e.g. silicon calibration waver, and the straight-through data. We recommend to provide data that is measured under the same settings as the measurement was performed, that is if Psi and delta are measured for your data, also provide Psi and delta here. And use the same wavelenghts as there. - - What data was recorded for the calibration, The number of variables (N_variables) have to be set to the number of provided data columns accordingly, e.g. psi/delta -> N_variables= 2, Jones vector: N_variables = 4, Mueller martix -> N_variables= 16, etc. - - - - - - - - - - angle(s) of incidence used during the calibration measurement (excluding straight through mode) - - - - - - The wavelength or equivalent values (which are inter-convertible). The importer should convert all to one unit, and make the others accessible. Historically, energy is used in eV, but for visible spectroscopy wavelength is more common, for IR wave numbers in 1/cm units. -Possibly use the same type of data as for the measurement! - - - - - - Calibration is performed on a reference surface (usually silicon wafer with well defined oxide layer) at a number of angles, then in a straight through mode (transmission in air). - - - - - - - - - Free-text to describe which sample was used for calibration, e.g. silicon wafer with 25 nm thermal oxide layer. - - - - Incident angle of the beam vs. the normal of the bottom reflective (substrate) surface in the sample - - - - - - Sample stage, holding the sample at a specific position in X,Y,Z (Cartesian) coordinate system and at an orientation defined by three Euler angles (alpha, beta, gamma). The stage may be motorized or manual, special for liquids or gas environment. - - - - - - - - - - The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). -This transformation brings us from the NEXUS coordinates to the stage coordinates. -Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) -Last, provide the rotations of the sample - - If there is no motorized stage, we should at least qualify where the beam hits the sample and in what direction the sample stands in a free-text description, e.g. 'center of sample, long edge parallel to plane of incidence'. - - - - - For environmental measurements, the environment (liquid, vapor etc.) is enclosed in a cell, which has windows both in the direction of the source and the detector (looking from the sample). These windows also add a phase shift to the light altering the measured signal. This shift has to be corrected based on measuring a known sample in the environmental cell. - - the material of the window - - - Thickness of the window - - - Angle of the window normal (outer) vs. the substrate normal (similar to the angle of incidence). - - - Recorded data that can be used to calculate the window effect. Typically this is the substrate (e.g. silicon with thermal oxide layer) in air without window and in a known medium with the window. - - What sample was used to estimate the window effect. - - - Use the same wavelengths at which all other measurements are recorded - - - - - - Recorded data of a reference surface with and without window / medium. - - - - - - - - - - - Which type of detector was used, and what is known about it? A detector can be a photomultiplier (PMT), a CCD in a camera, an array in a spectrometer. If so, the whole detector unit goes in here. - - What kind of detector module is used, e.g. CCD-spectrometer, CCD camera, PMT, photodiode, etc. - - - - - - - - - - - If you specified 'other' as detector type, please write down what it is. - - - Integration time for the measurement. Single number or array if it was varied. - - - Define how many rotations of the rotating element were taken into account per spectrum. - - - Define which elements rotates, e.g. polarizer or analyzer. - - - - - - - - - rotation rate, if the revolution does not change during the measurement. - - - Specify maximum and minimum values for the revolution. - - - - - - - - Properties of the sample, its history, the sample environment and experimental conditions (e.g. surrounding medium, temperature, pressure etc.), along with the data (data type, wavelength array, measured data). - - Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus relevant from a scientific point. The purpose of this field is to allow materials database to parse the relevant elements without having to interpret the sample history or other fields. - - - - Ideally, a reference to the location or a unique (globally persistent) identifier (e.g.) of e.g. another file which gives as many as possible details of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the case that such a detailed history of the sample is not available, use this field as a free-text description to specify details of the sample and its preparation. - - - ISO 8601 date with time zone specified. - - - Qualitative description of the layer structure for the sample. For example: Si/native oxide/thermal oxide/polymer/peptide - - - A identifier to correlate data to the experimental conditions, if several were used in this measurement; typically an index of 0 - N - - - Select which type of data was recorded, for example Psi and Delta (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It is possible to have multiple selections. Data types may also be converted to each other, e.g. a Mueller matrix contains N,C,S data as well. This selection defines how many columns (N_variables) are stored in the data array. - - - - - - - - - - - Wavelength value(s) used for the measurement. - An array of 1 or more elements. Length defines N_wavelength - - - - - - Resulting data from the measurement, described by data type. - Minimum two columns containing Psi and delta, or for the normalized Mueller matrix, it may be 16 (or 15 if 1,1 is all 1). - - - - - - - - - - Specified uncertainties (errors) of the data described by data type. The structure is the same as for the measured data. - - - - - - - - - - An array of relative time points if a time series was recorded - - - Describe what was the medium above or around the sample. The common model is built up from substrate to the medium on the other side. Both boundaries are assumed infinite in the model. Here define the name of the material (e.g. water, air, etc.). - - - Array of pairs of complex refractive indices of the medium for every measured wavelength. Only necessary if the measurement was performed not in air, or something very well known, e.g. high purity water. Specify the complex refractive index: n + ik - - - - - - External parameters that have influenced the sample. - - - How many measurements were done varying the parameters? This forms an extra dimension beyond incident angle, time points and energy / wavelength (this is the length of the 4th dimension of the data). Defaults to 1. - - - Indicates which parameter was changed. Its definition must exist below. The specified variable has to be number_of_runs long, providing the parameters for each data set. - - - - - - - - - - - Was the sample modified using an optical source? Describe in this group the parameters of the optical excitation used. - - Specify the source for the external excitation - - - Wavelength value(s) or the range used for excitation. - In cases of continuous laser radiation a value or a set of values may do but for other illumination types, such as pulsed lasers, or lamps, a range may describe the source better. - - - Specify the FWHM of the excitation - - - CW or pulsed excitation - - - - - - - - - How long was the sample excited. - - - The integrated energy of light pulse. - - - - - Specify the voltage if the spectra were taken under bias - - - Temperature of the sample (sample holder, medium) - - - pH of medium (measured or set) - - - Pressure of the environment of the sample. - - - - What parameters are derived from the above data - - light loss due to depolarization as a value in [0-1] - - - - - A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Müller matrix elements, such as N, C and S. - + + + Ellipsometry, complex systems, up to variable angle spectroscopy. + + + + Variables used throughout the document, e.g. dimensions and important + parameters + + + + Size of the energy / wavelength vector used + + + + + How many variables are saved in a measurement (e.g. Psi and Delta, + Mueller matrix) + + + + + Number of incident angles used + + + + + Number of sample parameters scanned + + + + + Number of time points measured + + + + + + This is the application definition describing ellipsometry + experiments. Such experiments may be as simple as identifying how a + reflected beam of light with a single wavelength changes its + polarization state, to a variable angle spectroscopic ellipsometry + experiment. The application definition defines: - elements of the + experimental instrument - calibration information if available - + parameters used to tune the state of the sample - sample description + + + + FAIRmat-specific candidate proposal for an application definition + exemplifying ellipsometry. For example: + https://gitlab.mpcdf.mpg.de/nomad-lab/areab- + appdef/-/blob/spectroscopic-ellipsometry- + consolidation/optical_spectroscopy + + + + Ideally version with build number are commit hash of the application + definition. If not available a free-text description. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition + + + + + + Unique identifier of the experiment, such as a (globally persistent) + unique identifier. i) The identifier is usually defined by the + facility or principle investigator. ii) The identifier enables to link + experiments to e.g. proposals. + + + + + + + Commercial or otherwise defined given name to the program that was + used to generate the results file(s) with measured data and metadata + (or a link to the instrument software). + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a deterministic + manner. + + + + + Website of the software. + + + + + + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. + + + + + Name of the affiliation of the user at the point in time when the + experiment was performed. + + + + + + + + + + General properties of the ellipsometry equipment + + + + The name of the instrument + + + + The used version of the hardware if available. If not a commercial + instrument use date of completion of the hardware. + + + + + + Name of the company which build the instrument + + + + + ISO8601 date when the instrument was constructed + + + + + Name (e.g. commercial) of the software that was used for the + measurement + + + + Version and build number or commit hash of the software source code + + + + + Website of the software. + + + + + + Specify the used light source. Multiple selection possible. + + + + + + + + + + + + + If you specified 'other' as light source type, please write down what + it is. + + + + + Were focussing probes (lenses) used or not? + + + + + Were the recorded data corrected by the window effects of the lenses + or not? + + + + + Specify the angular spread caused by the focussing probes + + + + + What type of ellipsometry was used? See Fujiwara Table 4.2 + + + + + + + + + + + + + + + + + + + Ellipsometers require regular calibration to adjust the hardware + parameters for proper zero values and background light compensation. + + + + ISO8601 datum when calibration was last performed before this + measurement + + + + + Arrays which provide the measured calibration data. Multiple sets are + possible, e.g. Psi and delta measured on an e.g. silicon calibration + waver, and the straight-through data. We recommend to provide data + that is measured under the same settings as the measurement was + performed, that is if Psi and delta are measured for your data, also + provide Psi and delta here. And use the same wavelenghts as there. + + + + What data was recorded for the calibration, The number of variables + (N_variables) have to be set to the number of provided data columns + accordingly, e.g. psi/delta -> N_variables= 2, Jones vector: + N_variables = 4, Mueller martix -> N_variables= 16, etc. + + + + + + + + + + + + angle(s) of incidence used during the calibration measurement + (excluding straight through mode) + + + + + + + + The wavelength or equivalent values (which are inter-convertible). The + importer should convert all to one unit, and make the others + accessible. Historically, energy is used in eV, but for visible + spectroscopy wavelength is more common, for IR wave numbers in 1/cm + units. Possibly use the same type of data as for the measurement! + + + + + + + + Calibration is performed on a reference surface (usually silicon wafer + with well defined oxide layer) at a number of angles, then in a + straight through mode (transmission in air). + + + + + + + + + + + Free-text to describe which sample was used for calibration, e.g. + silicon wafer with 25 nm thermal oxide layer. + + + + + + Incident angle of the beam vs. the normal of the bottom reflective + (substrate) surface in the sample + + + + + + + + Sample stage, holding the sample at a specific position in X,Y,Z + (Cartesian) coordinate system and at an orientation defined by three + Euler angles (alpha, beta, gamma). The stage may be motorized or + manual, special for liquids or gas environment. + + + + + + + + + + + + The stage coordinate system vs. the incident beam. The Z-axis of the + stage is considered to point along the normal of the substrate (bottom + reflecting surface) from the stage towards the general direction of + the light source. The beam comes with angle of incidence towards this + Z-axis, but in opposite direction, thus they are connected with a + rotation of 180 - angle of incidence (in degrees). This transformation + brings us from the NEXUS coordinates to the stage coordinates. Then + provide the set of translations (if there are any). These all have a + vector defining their relative direction in the current coordinate + system. (This current coordinate system changes with every + transformation if you set the parameter 'depends' to the name of the + previous step.) Last, provide the rotations of the sample + + + + If there is no motorized stage, we should at least qualify where the + beam hits the sample and in what direction the sample stands in a + free-text description, e.g. 'center of sample, long edge parallel to + plane of incidence'. + + + + + + + For environmental measurements, the environment (liquid, vapor etc.) + is enclosed in a cell, which has windows both in the direction of the + source and the detector (looking from the sample). These windows also + add a phase shift to the light altering the measured signal. This + shift has to be corrected based on measuring a known sample in the + environmental cell. + + + + the material of the window + + + + + Thickness of the window + + + + + Angle of the window normal (outer) vs. the substrate normal (similar + to the angle of incidence). + + + + + Recorded data that can be used to calculate the window effect. + Typically this is the substrate (e.g. silicon with thermal oxide + layer) in air without window and in a known medium with the window. + + + + What sample was used to estimate the window effect. + + + + + Use the same wavelengths at which all other measurements are recorded + + + + + + + + Recorded data of a reference surface with and without window / medium. + + + + + + + + + + + + + Which type of detector was used, and what is known about it? A + detector can be a photomultiplier (PMT), a CCD in a camera, an array + in a spectrometer. If so, the whole detector unit goes in here. + + + + What kind of detector module is used, e.g. CCD-spectrometer, CCD + camera, PMT, photodiode, etc. + + + + + + + + + + + + + If you specified 'other' as detector type, please write down what it + is. + + + + + Integration time for the measurement. Single number or array if it was + varied. + + + + + Define how many rotations of the rotating element were taken into + account per spectrum. + + + + + Define which elements rotates, e.g. polarizer or analyzer. + + + + + + + + + + + rotation rate, if the revolution does not change during the + measurement. + + + + + Specify maximum and minimum values for the revolution. + + + + + + + + + + Properties of the sample, its history, the sample environment and + experimental conditions (e.g. surrounding medium, temperature, + pressure etc.), along with the data (data type, wavelength array, + measured data). + + + + Use Hill's system for listing elements of the periodic table which are + inside or attached to the surface of the specimen and thus relevant + from a scientific point. The purpose of this field is to allow + materials database to parse the relevant elements without having to + interpret the sample history or other fields. + + + + + + Ideally, a reference to the location or a unique (globally persistent) + identifier (e.g.) of e.g. another file which gives as many as possible + details of the material, its microstructure, and its thermo-chemo- + mechanical processing/preparation history. In the case that such a + detailed history of the sample is not available, use this field as a + free-text description to specify details of the sample and its + preparation. + + + + + ISO 8601 date with time zone specified. + + + + + Qualitative description of the layer structure for the sample. For + example: Si/native oxide/thermal oxide/polymer/peptide + + + + + A identifier to correlate data to the experimental conditions, if + several were used in this measurement; typically an index of 0 - N + + + + + Select which type of data was recorded, for example Psi and Delta + (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It + is possible to have multiple selections. Data types may also be + converted to each other, e.g. a Mueller matrix contains N,C,S data as + well. This selection defines how many columns (N_variables) are stored + in the data array. + + + + + + + + + + + + + Wavelength value(s) used for the measurement. An array of 1 or more + elements. Length defines N_wavelength + + + + + + + + Resulting data from the measurement, described by data type. Minimum + two columns containing Psi and delta, or for the normalized Mueller + matrix, it may be 16 (or 15 if 1,1 is all 1). + + + + + + + + + + + + Specified uncertainties (errors) of the data described by data type. + The structure is the same as for the measured data. + + + + + + + + + + + + An array of relative time points if a time series was recorded + + + + + Describe what was the medium above or around the sample. The common + model is built up from substrate to the medium on the other side. Both + boundaries are assumed infinite in the model. Here define the name of + the material (e.g. water, air, etc.). + + + + + Array of pairs of complex refractive indices of the medium for every + measured wavelength. Only necessary if the measurement was performed + not in air, or something very well known, e.g. high purity water. + Specify the complex refractive index: n + ik + + + + + + + + External parameters that have influenced the sample. + + + + + How many measurements were done varying the parameters? This forms an + extra dimension beyond incident angle, time points and energy / + wavelength (this is the length of the 4th dimension of the data). + Defaults to 1. + + + + + Indicates which parameter was changed. Its definition must exist + below. The specified variable has to be number_of_runs long, providing + the parameters for each data set. + + + + + + + + + + + + + Was the sample modified using an optical source? Describe in this + group the parameters of the optical excitation used. + + + + Specify the source for the external excitation + + + + + Wavelength value(s) or the range used for excitation. In cases of + continuous laser radiation a value or a set of values may do but for + other illumination types, such as pulsed lasers, or lamps, a range may + describe the source better. + + + + + Specify the FWHM of the excitation + + + + + CW or pulsed excitation + + + + + + + + + + + How long was the sample excited. + + + + + The integrated energy of light pulse. + + + + + + + Specify the voltage if the spectra were taken under bias + + + + + Temperature of the sample (sample holder, medium) + + + + + pH of medium (measured or set) + + + + + Pressure of the environment of the sample. + + + + + + What parameters are derived from the above data + + + + light loss due to depolarization as a value in [0-1] + + + + + + A default view of the data, in this case Psi vs. wavelength and the + angles of incidence. If Psi does not exist, use other Müller matrix + elements, such as N, C and S. + + + diff --git a/contributed_definitions/NXem_nion.nxdl.xml b/contributed_definitions/NXem_nion.nxdl.xml index e602a1d6ca..d44a5f9c8f 100644 --- a/contributed_definitions/NXem_nion.nxdl.xml +++ b/contributed_definitions/NXem_nion.nxdl.xml @@ -1,44 +1,63 @@ - (Scanning) transmission electron microscopy with a Nion instrument. + + (Scanning) transmission electron microscopy with a Nion instrument. + - Number of pixel in the x direction + + Number of pixel in the x direction + - Number of pixel in the y direction + + Number of pixel in the y direction + - Physical size of a pixel in x direction + + Physical size of a pixel in x direction + - Physical size of a pixel in y direction + + Physical size of a pixel in y direction + - Official NeXus NXDL schema to which this entry conforms. + + Official NeXus NXDL schema to which this entry conforms. + - Version specifier which enables documentation of modifications to the - schema. + + Version specifier which enables documentation of modifications to the + schema. + - Ideally, a (globally) persistent unique identifier for referring to + + Ideally, a (globally) persistent unique identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier - enables to link experiments to e.g. proposals. + enables to link experiments to e.g. proposals. + - Possibility for leaving a free-text description about the experiment. + + Possibility for leaving a free-text description about the experiment. Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than writing these details in - prose into this field. + prose into this field. + - ISO 8601 formatted time code with local time zone offset to UTC + + ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - @@ -49,14 +68,18 @@ aware that even with having both time instances specified, it may not be possible to infer how long the experiment took or for how long data were acquired. More detailed timing data over the course of the - experiment have to be collected to compute this. + experiment have to be collected to compute this. + - ISO 8601-formatted time code with local time zone offset to UTC - included when the experiment ended. + + ISO 8601-formatted time code with local time zone offset to UTC + included when the experiment ended. + - Commercial or otherwise given name to the program which was used to + + Commercial or otherwise given name to the program which was used to acquire/measure the dataset. Electron microscopy experiments are usually controlled/performed via commercial integrated acquisition and instrument control software. In many cases, an EM dataset is useful @@ -71,75 +94,101 @@ performed with (open-source) research software. Therefore, there is strictly speaking not a single program used in electron microscopy, and thus each NXprocess needs its own program, with version and - description." + description." + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is - numerically recreatable in the same deterministic manner. + numerically recreatable in the same deterministic manner. + - Binary container for a file or a compressed collection of files which + + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold e.g. a ppt, pdf, latex, txt, image, or zip - archive ...). + archive ...). + - A small image that is representative of the entry. This can be an + + A small image that is representative of the entry. This can be an image from the dataset or a thumbnail of a spectrum. Either way it is recommended to use 640x480 pixel jpeg image. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in - data repositories. + data repositories. + - Contact information of at least the user of the instrument who + + Contact information of at least the user of the instrument who measured this specimen or the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. + this experiment. Adding multiple users if relevant is recommended. + - Given (first) name and surname of the user. + + Given (first) name and surname of the user. + - Name of the affiliation of the user at the point in time when the - experiment was performed. + + Name of the affiliation of the user at the point in time when the + experiment was performed. + - Postal address of the affiliation. + + Postal address of the affiliation. + - Email address of the user at the point in time when the experiment was - performed. Given the most permanently used email is recommended. + + Email address of the user at the point in time when the experiment was + performed. Given the most permanently used email is recommended. + - Globally unique identifier of the user as offers by services like - ORCID or ResearcherID. + + Globally unique identifier of the user as offers by services like + ORCID or ResearcherID. + - (Business) (tele)phone number of the user at the point in time when - the experiment was performed. + + (Business) (tele)phone number of the user at the point in time when + the experiment was performed. + - Which role does the user have in the place, and at the point in time + + Which role does the user have in the place, and at the point in time when, the experiment was performed (e.g. technician operating the - microscope, student, postdoc, principle investigator, guest ...). + microscope, student, postdoc, principle investigator, guest ...). + - Descriptive name or identifier with which to distinguish the specimen + + Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it was cut. In cases where the specimen was e.g. site-specifically cut from a sample or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen was investigated and is represented by this NXentry. The user is advised to store the details how specimens were cut/prepared from - samples in the sample history. + samples in the sample history. + - Ideally, a reference to the location of or a (globally) persistent + + Ideally, a reference to the location of or a (globally) persistent unique identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history. In the @@ -148,79 +197,112 @@ set of the entire sample history, i.e. what you would consider being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. + and the details of the preparation. + - ISO8601 date and time with local time zone offset to UTC included when + + ISO8601 date and time with local time zone offset to UTC included when the specimen was prepared. Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen-charged specimens or experiments including tracers with a short half-time. The user is advised to include these - temporal details in the sample_history. + temporal details in the sample_history. + - Possibility to give an abbreviation of the specimen name field. + + Possibility to give an abbreviation of the specimen name field. + - Use Hill's system for listing elements of the periodic table which are + + Use Hill's system for listing elements of the periodic table which are inside or attached to the surface of the specimen and thus relevant from a scientific point of view. The purpose of the field is to offer materials database systems an opportunity to parse the relevant - elements without having to interpret these from the sample history. + elements without having to interpret these from the sample history. + - (Measured) sample thickness + + (Measured) sample thickness + - Hard link to a location/locations in the hierarchy of the NeXus file - where the data for default plotting are stored. + + Hard link to a location/locations in the hierarchy of the NeXus file + where the data for default plotting are stored. + - Metadata and numerical data of not only the microscope but also the - lab in which this microscope is located. + + Metadata and numerical data of not only the microscope but also the + lab in which this microscope is located. + - Given name of the microscope, e.g. NionHermes. + + Given name of the microscope, e.g. NionHermes. + - Geographic coordinates of the lab or the place where the instrument is - installed using GEOREF geocodes ideally. + + Geographic coordinates of the lab or the place where the instrument is + installed using GEOREF geocodes ideally. + - Manufacturer of the entire instrument to enable e.g. queries in + + Manufacturer of the entire instrument to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these - should be written into instrument_model and instrument_capabilities. + should be written into instrument_model and instrument_capabilities. + - Manufacturer brand/model to enable e.g. queries about microscope + + Manufacturer brand/model to enable e.g. queries about microscope models. See comments on instrument_manufacturer on how to provide - further specification. + further specification. + - Hardware name/serial number or hash identifier given by the - manufacturer to identify the instrument. + + Hardware name/serial number or hash identifier given by the + manufacturer to identify the instrument. + - Free-text list possibly multiple terms of functionalities which the - instrument provides. + + Free-text list possibly multiple terms of functionalities which the + instrument provides. + - The source which creates the electron beam. + + The source which creates the electron beam. + - Voltage relevant to compute the energy of the electrons immediately - after they left the gun. + + Voltage relevant to compute the energy of the electrons immediately + after they left the gun. + - Type of radiation. + + Type of radiation. + - Emitter type used to create the beam. + + Emitter type used to create the beam. + @@ -228,47 +310,69 @@ - Ideally a reference to (another) file (ideally formatted using also an + + Ideally a reference to (another) file (ideally formatted using also an application definition) via a link, name, or a (globally) persistent - unique identifier to give further details about the electron gun. + unique identifier to give further details about the electron gun. + - Details of individual apertures in the instrument. + + Details of individual apertures in the instrument. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Relevant value from the control software. This is not always just the + + Relevant value from the control software. This is not always just the diameter of (not even in the case) of a circular aperture but rather a value from a list of predefined aperture settings which somebody defined in the control software. Which actual settings are behind - these should be defined for now in the description field. + these should be defined for now in the description field. + - Ideally, a (globally) persistent unique identifier, link, or text to a - resource which gives further details. + + Ideally, a (globally) persistent unique identifier, link, or text to a + resource which gives further details. + - Affine transformations and geometrical descriptions which detail how + + Affine transformations and geometrical descriptions which detail how the aperture is placed and arranged in the microscope relative to the - optical axis and beam path. + optical axis and beam path. + - Details to individual lenses in the microscope. + + Details to individual lenses in the microscope. + - Which type describes the type of the lens closest? + + Which type describes the type of the lens closest? + @@ -278,24 +382,35 @@ - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Ideally an identifier, persistent link, or free text which gives - further details about the lens. + + Ideally an identifier, persistent link, or free text which gives + further details about the lens. + - Collection of axis-based translations and rotations to describe the + + Collection of axis-based translations and rotations to describe the location and geometry of the lens as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin of the @@ -304,31 +419,46 @@ coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. The translation actively brings the coordinate system under depends_on into registration with a - coordinate system in the center of the lens. + coordinate system in the center of the lens. + - Does the microscope have a spherical aberration correction unit and - was it used? + + Does the microscope have a spherical aberration correction unit and + was it used? + - Details about an eventual device which corrects spherical aberrations. + + Details about an eventual device which corrects spherical aberrations. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Ideally an identifier, link, or free-text which gives further details - about the component. + + Ideally an identifier, link, or free-text which gives further details + about the component. + @@ -347,7 +477,9 @@ - Principal design of the stage. + + Principal design of the stage. + @@ -364,35 +496,51 @@ - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Ideally a link to a (globally persistent) unique identifier which + + Ideally a link to a (globally persistent) unique identifier which documents or can be used to infer further details of the component. If such a resource is not available, use this field for a free-text - description and describe further details to the stage. + description and describe further details to the stage. + - STAGE TILT A. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS - TO BE COMMUNICATED. + + STAGE TILT A. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS + TO BE COMMUNICATED. + - STAGE TILT B. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS - TO BE COMMUNICATED. + + STAGE TILT B. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS + TO BE COMMUNICATED. + - STAGEOUTX, Y, Z. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES - REMAINS TO BE COMMUNICATED. + + STAGEOUTX, Y, Z. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES + REMAINS TO BE COMMUNICATED. + @@ -401,20 +549,30 @@ - Description of the type of the detector e.g. CCD, scintillator, direct - electron, image plate, CMOS. + + Description of the type of the detector e.g. CCD, scintillator, direct + electron, image plate, CMOS. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + @@ -425,94 +583,138 @@ - Free text option to write further details about the detector. + + Free text option to write further details about the detector. + - EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS TO BE - COMMUNICATED. + + EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS TO BE + COMMUNICATED. + - EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS TO BE - COMMUNICATED. + + EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS TO BE + COMMUNICATED. + - EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES AND NION REMAINS TO BE - COMMUNICATED. + + EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES AND NION REMAINS TO BE + COMMUNICATED. + - DETAILS HOW COMPUTED NEEDS TO BE CONFIRMED BY NION. + + DETAILS HOW COMPUTED NEEDS TO BE CONFIRMED BY NION. + - Container for reporting individually processed images with the HAADF - detector ? + + Container for reporting individually processed images with the HAADF + detector ? + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - HAADF annulus inner half angle ? + + HAADF annulus inner half angle ? + - HAADF annulus outer half angle ? + + HAADF annulus outer half angle ? + - Description of the scan box which is instructed by the microscope + + Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according - to a scan scheme and plan. + to a scan scheme and plan. + - Commercial or otherwise given name to the program which was used to - execute this analysis. + + Commercial or otherwise given name to the program which was used to + execute this analysis. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES WHICH SUGGESTIONS TO PUT AS - ENUMERATIONS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES WHICH SUGGESTIONS TO PUT AS + ENUMERATIONS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - Detailed settings of an internal board(s) in the scanbox device. + + Detailed settings of an internal board(s) in the scanbox device. FURTHER INFORMATION EXCHANGE/DISCUSSIONS WITH NION IS NEEDED TO - ELUCIDATE WHAT THESE ARE. + ELUCIDATE WHAT THESE ARE. + @@ -542,30 +744,40 @@ - Container for holding an image (stack) taken with the HA(A) ? DF - detector. + + Container for holding an image (stack) taken with the HA(A) ? DF + detector. + - Image intensity values. + + Image intensity values. + - Label for the y axis. + + Label for the y axis. + - Pixel barycenter position x-coordinates. + + Pixel barycenter position x-coordinates. + - Pixel barycenter position y-coordinates. + + Pixel barycenter position y-coordinates. + diff --git a/contributed_definitions/NXfib.nxdl.xml b/contributed_definitions/NXfib.nxdl.xml index 0b602b93bc..d784f95dab 100644 --- a/contributed_definitions/NXfib.nxdl.xml +++ b/contributed_definitions/NXfib.nxdl.xml @@ -1,29 +1,43 @@ - Set of devices adding focused-ion beam capabilities to an instrument. + + Set of devices adding focused-ion beam capabilities to an instrument. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Ideally a reference to persistent documentation which specifies + + Ideally a reference to persistent documentation which specifies further details for the device. If this is not available, add a free- text description to deliver further details about the focused-ion - unit. + unit. + - The type of source which creates the ion beam. + + The type of source which creates the ion beam. + @@ -31,36 +45,50 @@ - Which ionized elements or molecules are ionized to form the beam which + + Which ionized elements or molecules are ionized to form the beam which is used to probe or sputter the specimen. Examples are gallium, - helium, neon, argon, krypton, or xenon, O2+. + helium, neon, argon, krypton, or xenon, O2+. + - Average/nominal (DISCUSS FURTHER WITH COLLEAGUES) brightness of the - ion beam (at which location?). + + Average/nominal (DISCUSS FURTHER WITH COLLEAGUES) brightness of the + ion beam (at which location?). + - Ion flux + + Ion flux + - Charge current + + Charge current + - Ion acceleration voltage upon source exit and entering the vacuum - flight path. + + Ion acceleration voltage upon source exit and entering the vacuum + flight path. + - NEEDS FURTHER DISCUSSION WITH COLLEAGUES HOW THIS SHOULD BE DEFINED. + + NEEDS FURTHER DISCUSSION WITH COLLEAGUES HOW THIS SHOULD BE DEFINED. + - A right-handed Cartesian coordinate system is used whose positive + + A right-handed Cartesian coordinate system is used whose positive z-axis points in the direction of the ion beam, i.e. towards the sample. For modelling ion milling it is relevant to document the illumination vector. NXtransformations offers a place to store how the ion gun coordinate system has to be rotated to align its positive z-axis with the positive z-axis of e.g. the electron beam and ion beam - respectively. + respectively. + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 55a699afeb..7bad29a55e 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -1,33 +1,46 @@ - Set of atoms of a molecular ion or fragment in ToF mass spectrometry. + + Set of atoms of a molecular ion or fragment in ToF mass spectrometry. + - The symbols used in the schema to specify e.g. dimensions of arrays. + + The symbols used in the schema to specify e.g. dimensions of arrays. + - Maximum number of allowed atoms per (molecular) ion (fragment). + + Maximum number of allowed atoms per (molecular) ion (fragment). + - Number of mass-to-charge-state-ratio range intervals for ion type. + + Number of mass-to-charge-state-ratio range intervals for ion type. + - Ion type (ion species) identifier. The identifier zero is reserved for - the special unknown ion type. + + 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 a + + A vector of isotope hash values. These values have to be stored in a decreasingly sorted array. The array is filled with zero hash values indicating unused places. The individual hash values are built with the following hash function: Hashvalue = Z + N*256 with Z the number of protons and N the number of neutrons of the isotope respectively. Z - and N have to be 8-bit unsigned integers. + and N have to be 8-bit unsigned integers. + - Signed charge state of the ion in multiples of the elementary electron + + Signed charge state of the ion in multiples of the elementary 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 @@ -36,21 +49,26 @@ probe data. These file formats do not document the charge state explicitly but report an integer with the atom type which can be used to compute the charge state via the theoretically-known mass-to- - charge-state-ratios of the elements. + charge-state-ratios of the elements. + - Human-readable ion type name (e.g. Al +++), i.e. ASCII UTF-8 character + + Human-readable ion type name (e.g. Al +++), i.e. ASCII UTF-8 character array, ideally using LaTeX notation to specify the ion 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, the isotope_vector should be the - preferred machine-readable format in use. + preferred machine-readable format in use. + - Associated lower (mqmin) and upper (mqmax) bounds of mass-to-charge- + + 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 labelled as an ion of the here referred to - ion_type. + ion_type. + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 20c8e90d1e..53c512775d 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -1,9 +1,13 @@ - An electro-magnetic lens. + + An electro-magnetic lens. + - Qualitative type of lens with respect to the number of pole pieces. + + Qualitative type of lens with respect to the number of pole pieces. + @@ -13,24 +17,35 @@ - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Ideally an identifier, persistent link, or free text which gives - further details about the lens. + + Ideally an identifier, persistent link, or free text which gives + further details about the lens. + - Collection of axis-based translations and rotations to describe the + + Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin @@ -39,6 +54,7 @@ handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. The translation actively brings the coordinate system under depends_on into - registration with a coordinate system in the center of the lens. + registration with a coordinate system in the center of the lens. + diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 8942cb0f43..0272321dad 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -1,21 +1,31 @@ - Description of peaks, their functional form or measured support. + + Description of peaks, their functional form or measured support. + - The symbols used in the schema to specify e.g. dimensions of arrays. + + The symbols used in the schema to specify e.g. dimensions of arrays. + - Number of support points + + Number of support points + - Human-readable identifier to specify which concept/entity the peak - identifies. + + Human-readable identifier to specify which concept/entity the peak + identifies. + - Is the peak described analytically via a functional form or is it + + Is the peak described analytically via a functional form or is it described empirically via measured/reported intensity/counts as a - function of an independent variable. + function of an independent variable. + @@ -23,23 +33,29 @@ - In the case of an empirical description of the peak and its shoulders, + + In the case of an empirical description of the peak and its shoulders, this array holds the positions were independent variable values were - taken. + taken. + - 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 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 this group can be used to + + In the case of an analytical description this group can be used to hold parameter of the functional form. For example in the case of - Gaussian peaks mu, sigma, and cut-off values and background intensity. + Gaussian peaks mu, sigma, and cut-off values and background intensity. + diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index 201525edef..a8159da6e0 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -1,15 +1,23 @@ - Laser-, voltage-, or combined- pulsing to trigger field evaporation. + + Laser-, voltage-, or combined- pulsing to trigger field evaporation. + - The symbols used in the schema to specify e.g. dimensions of arrays. + + The symbols used in the schema to specify e.g. dimensions of arrays. + - Total number of ions collected. + + Total number of ions collected. + - How evaporation is physically triggered. + + How evaporation is physically triggered. + @@ -17,71 +25,103 @@ - Atom probe microscopes use controlled laser, voltage, or a combination + + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the excitation and eventual field evaporation/emission of an ion in an atom probe microscopy experiment. # Many microscopes have a laser installed which enables measurements - also with poorly conductive specimens. + also with poorly conductive specimens. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Nominal wavelength of the laser radiation. + + Nominal wavelength of the laser radiation. + - Average power of the laser source while illuminating the specimen. + + Average power of the laser source while illuminating the specimen. + - Average (??) energy of the laser at peak of (each) ?? pulse. + + Average (??) energy of the laser at peak of (each) ?? pulse. + - Set of transformations which describe the geometry between how the + + Set of transformations which describe the geometry between how the laser focusing optics/pinhole-attached coordinate system is defined, how it has to be transformed so that it aligns with the specimen coordinate system. A right-handed Cartesian coordinate system, the so- called laser space, should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. + into the direction of the propagating laser beam. + - Details about specific positions along the focused laser beam which - illuminates the atom probe specimen. + + Details about specific positions along the focused laser beam which + illuminates the atom probe specimen. + - Track time-dependent settings over the course of the measurement where - the laser beam exits the focusing optics. + + Track time-dependent settings over the course of the measurement where + the laser beam exits the focusing optics. + - Track time-dependent settings over the course of the measurement where - the laser hits the specimen. + + Track time-dependent settings over the course of the measurement where + the laser hits the specimen. + - Frequency with which the high voltage or laser pulser fires. + + Frequency with which the high voltage or laser pulser fires. + - Fraction of the pulse_voltage that is applied in addition to the - standing_voltage at peak voltage of a pulse. + + Fraction of the pulse_voltage that is applied in addition to the + standing_voltage at peak voltage of a pulse. + - NEED TO DISCUSS WITH APM COLLEAGUES IN MORE DETAIL WHAT THIS IS - SPECIFICALLY! + + NEED TO DISCUSS WITH APM COLLEAGUES IN MORE DETAIL WHAT THIS IS + SPECIFICALLY! + - Direct current voltage between the specimen and the (local electrode) - in the case of a LEAP instrument. + + Direct current voltage between the specimen and the (local electrode) + in the case of a LEAP instrument. + diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index 1c531d5471..24de539b52 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -1,10 +1,13 @@ - Device to create reduce an atmosphere to a controlled remaining - pressure level. + + Device to create reduce an atmosphere to a controlled remaining pressure level. + - Principle type of the pump. + + Principle type of the pump. + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml index 56faa37d96..936f2f5ae2 100644 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -1,31 +1,44 @@ - Device for reducing flight time differences of ions in ToF - experiments. + + Device for reducing flight time differences of ions in ToF experiments. + - Given name. + + Given name. + - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + + Given hardware name/serial number or hash identifier issued by the + manufacturer. + - Given name of the manufacturer. + + Given name of the manufacturer. + - Free-text field to specify further details about the reflectron. The - quantity can inform for instance if the reflectron is flat or curved. + + Free-text field to specify further details about the reflectron. The + quantity can inform for instance if the reflectron is flat or curved. + - Affine transformation(s) which detail where the reflectron is located + + Affine transformation(s) which detail where the reflectron is located relative to e.g. the origin of the specimen space reference coordinate system. This group can also be used for specifying how the reflectron is rotated relative to the specimen axis. The purpose of these more detailed instrument descriptions is to support the creation of a - digital twin of the instrument for computational science. + digital twin of the instrument for computational science. + diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 4198a3c34c..196b963422 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -1,61 +1,93 @@ - Scan unit in an electron microscope which controls the electron beam. + + Scan unit in an electron microscope which controls the electron beam. + - Number of pixel in the x direction + + Number of pixel in the x direction + - Number of pixel in the y direction + + Number of pixel in the y direction + - Physical size of a pixel in x direction + + Physical size of a pixel in x direction + - Physical size of a pixel in y direction + + Physical size of a pixel in y direction + - Commercial or otherwise given name to the program which was used to - execute this analysis. + + Commercial or otherwise given name to the program which was used to + execute this analysis. + - Ideally program version plus build number, or commit hash or + + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. + computational process is recreatable in the same deterministic manner. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES WHICH SUGGESTIONS TO PUT AS - ENUMERATIONS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES WHICH SUGGESTIONS TO PUT AS + ENUMERATIONS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + + REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 57df7fd08f..f4ab8d8431 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -37,7 +37,8 @@ tensile testing machines which are mounted on the specimen holder. - Principal design of the stage. + + Principal design of the stage. @@ -55,31 +56,37 @@ - Given name. + + Given name. - Given brand or model name by the manufacturer. + + Given brand or model name by the manufacturer. - Given hardware name/serial number or hash identifier issued by the + + Given hardware name/serial number or hash identifier issued by the manufacturer. - Given name of the manufacturer. + + Given name of the manufacturer. - Ideally a link to a (globally persistent) unique identifier which + + Ideally a link to a (globally persistent) unique identifier which documents or can be used to infer further details of the component. If such a resource is not available, use this field for a free-text description and describe further details to the stage. - Set of transformations which describe how the stage-affixed coordinate + + Set of transformations which describe how the stage-affixed coordinate system is defined and how it has to be transformed so that it aligns with the specimen coordinate system. diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 66c18d93fd..15958e4e25 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -49,7 +49,7 @@ We developed new base classes to structure the application definition into lab e A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. :ref:`NXstage_lab`: - A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage` base class is insufficiently detailed to represent the functionalities which modern stages of an + A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an atom probe microscope or especially an electron microscopy offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and in an atom probe, given that both offer fixture functionalities and additional components such as for applying stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. :ref:`NXchamber`: @@ -58,13 +58,16 @@ We developed new base classes to structure the application definition into lab e :ref:`NXpump`: A base class to describe a component which reduce the partial/total pressure in a chamber to some controlled value so that an experiment can be performed. Most commonly this class can be used for representing and storing details of e.g. the vacuum pumping system. + :ref:`NXreflectron`: + A base class to describe a kinetic energy sensitive filtering device for ToF. + Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. Removed base classes ###################### -We have removed the NXlens_apm base class and replaced it by NXreflectron. +We have removed the NXlens_apm base class and replaced it by :ref:`NXreflectron`. .. https://stackoverflow.com/questions/4783814/how-to-comment-a-string-in-restructured-text \ No newline at end of file diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 3350f69d43..2a127fc40c 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -58,4 +58,4 @@ We developed entirely new base classes: New Common Base Classes ####################### -We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em`, :ref:`NXlens`, and :ref:`NXxraylens have similarities. It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general base class lenses. +We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em`, :ref:`NXlens`, and :ref:`NXxraylens` have similarities. It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general base class lenses. diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index 31dbb72541..fd2b625e3d 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -106,6 +106,6 @@ We use existent base classes in application definitions and add descriptors: :ref:`NXsample` Added descriptors specific to photoemission experiments. - + :ref:`NXsource` Added descriptors for laboratory sources (X-ray, UV lamps) but mostly for ultrafat lasers with complex time structures. From 17ca677fc8e9a7cd62f5d6a5f2837cc678d6c1bd Mon Sep 17 00:00:00 2001 From: domna Date: Fri, 17 Jun 2022 15:47:42 +0200 Subject: [PATCH 023/203] Updated arpes definitions for fairmat-pages --- base_classes/NXaperture.nxdl.xml | 6 - base_classes/NXbeam.nxdl.xml | 65 +- base_classes/NXdetector.nxdl.xml | 30 - base_classes/NXentry.nxdl.xml | 20 +- base_classes/NXprocess.nxdl.xml | 9 - base_classes/NXsample.nxdl.xml | 51 -- base_classes/NXsource.nxdl.xml | 24 - contributed_definitions/NXaperture.nxdl.xml | 87 ++ contributed_definitions/NXbeam.nxdl.xml | 285 +++++++ .../NXcalibration.nxdl.xml | 132 ++- .../NXcollectioncolumn.nxdl.xml | 128 +-- contributed_definitions/NXdeflector.nxdl.xml | 63 +- contributed_definitions/NXdetector.nxdl.xml | 801 ++++++++++++++++++ contributed_definitions/NXdistortion.nxdl.xml | 135 +-- .../NXelectronanalyser.nxdl.xml | 193 +++-- .../NXenergydispersion.nxdl.xml | 99 ++- contributed_definitions/NXentry.nxdl.xml | 270 ++++++ contributed_definitions/NXinstrument.nxdl.xml | 82 ++ contributed_definitions/NXlens.nxdl.xml | 47 - contributed_definitions/NXlens_em.nxdl.xml | 63 +- .../NXmanipulator.nxdl.xml | 147 ++-- contributed_definitions/NXmpes.nxdl.xml | 538 ++++++------ contributed_definitions/NXmpes_ARPES.nxdl.xml | 274 ------ contributed_definitions/NXprocess.nxdl.xml | 64 ++ .../NXregistration.nxdl.xml | 58 +- contributed_definitions/NXsample.nxdl.xml | 599 +++++++++++++ contributed_definitions/NXsource.nxdl.xml | 274 ++++++ .../NXspindispersion.nxdl.xml | 103 ++- manual/source/mpes-structure.rst | 10 +- 29 files changed, 3456 insertions(+), 1201 deletions(-) create mode 100644 contributed_definitions/NXaperture.nxdl.xml create mode 100644 contributed_definitions/NXbeam.nxdl.xml create mode 100644 contributed_definitions/NXdetector.nxdl.xml create mode 100644 contributed_definitions/NXentry.nxdl.xml create mode 100644 contributed_definitions/NXinstrument.nxdl.xml delete mode 100644 contributed_definitions/NXlens.nxdl.xml delete mode 100644 contributed_definitions/NXmpes_ARPES.nxdl.xml create mode 100644 contributed_definitions/NXprocess.nxdl.xml create mode 100644 contributed_definitions/NXsample.nxdl.xml create mode 100644 contributed_definitions/NXsource.nxdl.xml diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index c90dd7fdd1..d6fd308a50 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -52,12 +52,6 @@ Description of aperture - - Shape of the aperture, i.e. straight or curved for slits, circle, square hexagon, octagon, bladed for pinholes and irises. - - - The relevant dimension for the aperture, i.e. slit width, pinhole and iris diameter - describe any additional information in a note* diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 82482c2164..11ff397bb2 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -37,27 +37,15 @@ to specify the beam profile, time distribution etc. at each beamline component. Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron scattering by the sample, e.g., energy transfer, polarizations. - - The symbols used in the schema to specify e.g. dimensions of arrays - - Number of pixels of the frequency axis of a FROG trace - - Distance from sample - In the case of a monchromatic beam this is the scalar energy. Several other use cases are permitted, depending on the presence of other incident_energy_X fields. In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. Here, incident_energy_weights and incident_energy_spread are not set. In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_energy_weights as a 2D array. In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + Energy on entering beamline component - - The wavelength spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in the energy spread, this is a 2D array of dimension nP by m (slow to fast) of the spreads of the corresponding wavelength in incident_wavelength. - - - In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding energies in incident_energy. In the case of a polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np by m (slow to fast) of the relative weights of the corresponding energies in incident_energy. - Energy on leaving beamline component @@ -71,7 +59,7 @@ - In the case of a monchromatic beam this is the scalar wavelength. Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. In the case of a polychromatic beam this is an array of length m of wavelengths, with the relative weights in incident_wavelength_weights. In the case of a monochromatic beam that varies shot-to-shot, this is an array of wavelengths, one for each recorded shot. Here, incident_wavelength_weights and incident_wavelength_spread are not set. In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value wavelength value is available along with the original spectrum from which it was calibrated. + Wavelength on entering beamline component @@ -103,13 +91,11 @@ - Incident polarization as a Stokes vector - - + Polarization vector on entering beamline component + + + - - The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using ''NX_ANY''. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: ''T'' for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: ''farad'' for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) ''1/(s.mm2.mrad2)''. Here: SI units are ''V2/m2''. - Polarization vector on leaving beamline component @@ -137,45 +123,6 @@ - - Energy of a single pulse at the diagnostic point - - - Average power at the diagnostic point - - - Incident fluence at the diagnostic point - - Here: SI units are ''J/m2'', customary ''mJ/cm2''. - - - - FWHM duration of the pulses at the diagnostic point - - - FROG trace of the pulse. - - - - - - Horizontal axis of a FROG trace, i.e. delay. - - - - - - Vertical axis of a FROG trace, i.e. frequency. - - - - - - The type of chirp implemented - - - Group delay dispersion of the pulse for linear chirp - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index 1039bc8944..4ce4343bb1 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -817,34 +817,4 @@ for a summary of the discussion. - - Type of electron amplifier, MCP, channeltron, etc. - - - Description of the detector type, DLD, Phosphor+CCD, CMOS. - - - Voltage applied to detector. - - - Voltage applied to the amplifier. - - - The low voltage of the amplifier migh not be the ground. - - - Size of each imaging sensor chip on the detector. - - - Number of imaging sensor chips on the detector. - - - Physical size of the pixels of the imaging chip on the detector. - - - Number of raw active elements in each dimension. Important for swept scans. - - - raw data output from the detector - diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml index b82738c816..b235591b60 100644 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -190,25 +190,7 @@ which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. - - - City and country where ex. Took place - - - Start date and time of ex. in ISO 8601 format, ideally including UTC offset. - - - Start date and time of ex. in ISO 8601 format, ideally including UTC offset. - - - Name of the institution hosting the facility - - - Name of the experimental facility - - - Name of the laboratory or beamline - + Notes describing entry diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index b66a58cae9..9e042e873e 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -43,15 +43,6 @@ Date and time of processing. - - Class to describe the operations of image registration - - - class to describe the operations of image distrortion correction - - - class to describe the operations of calibration - The note will contain information about how the data was processed diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 0db7283442..5f93cab22a 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -328,57 +328,6 @@ sample thickness - - Identification number or signatures of the sample used. - - - A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. Ideally, a full report of the previous operations, in any format (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 - - - Physical state of the sample - - - Chemical purity of the sample - - - Surface termination of the sample (if crystalline) - - - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - - - Full chemical name of the sample - - - CAS registry number of the sample chemical content. - - - Gases might be fluxed on the surface for various reasons. Chemical designation, or residual. - - - Element of evaporated surface dopant such as alkali or other - - - Nominal thickness of the evaporated dopant - - - Voltage applied to sample and sample holder. - - - Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition etc.) - - - Name of the sample vendor (company or research group) - - - Material of the substrate in direct contact with the sample. - - - Physical state of the substrate, similar options to sample_state - - - Further notes. - As a function of Wavelength diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 9572f77e96..f612e28bd5 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -27,12 +27,6 @@ name="NXsource" type="group" extends="NXobject"> The neutron or x-ray storage ring/facility. - - The symbols used in the schema to specify e.g. dimensions of arrays - - Number of points in a spectrum - - Effective distance from sample @@ -169,24 +163,6 @@ For storage rings, the current at the end of the most recent injection. date and time of the most recent injection. - - The center photon energy of the source, before it is monochromatized or converted - - - The center wavelength of the source, before it is monochromatized or converted - - - For pulsed sources, the energy of a single pulse - - - For pulsed sources, the pulse energy divided by the pulse duration - - - Some facilities tag each bunch. First bunch of the measurement - - - Last bunch of the measurement - "Engineering" location of source diff --git a/contributed_definitions/NXaperture.nxdl.xml b/contributed_definitions/NXaperture.nxdl.xml new file mode 100644 index 0000000000..ce104d6500 --- /dev/null +++ b/contributed_definitions/NXaperture.nxdl.xml @@ -0,0 +1,87 @@ + + + + + A beamline aperture + + + + 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. + + + + + Absorbing material of the aperture. + + + + + Description of the aperture. + + + + + Shape of the aperture. + + + + + + + + + + + + + + + + + The relevant dimension for the aperture, i.e. slit width, pinhole and iris + diameter + + + + + Specifies the position of the aperture 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 + 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. + + + + + Stores the raw positions of aperture motors. + + + + + Location and shape of the aperture. + + + + + Location and shape of each blade. + + + + + Describes any additional information. + + + diff --git a/contributed_definitions/NXbeam.nxdl.xml b/contributed_definitions/NXbeam.nxdl.xml new file mode 100644 index 0000000000..0aa3caefac --- /dev/null +++ b/contributed_definitions/NXbeam.nxdl.xml @@ -0,0 +1,285 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of pixels of the horizontal axis (e.g. delay) of a FROG trace + + + + + Number of pixels of the vertical axis (e.g. frequency) of a FROG trace + + + + + Properties of the neutron or X-ray beam at a given location. + + It will be referenced by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. + Note that variables such as the incident energy could be scalar values or arrays. + This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, + time distribution etc. at each beamline component. + Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. + + + + Distance from sample + + + + + In the case of a monchromatic beam this is the scalar energy. + Several other use cases are permitted, depending on the presence of other incident_energy_X fields. + + * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + Here, incident_energy_weights and incident_energy_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_energy_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + + + + + + + + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In + the case of shot-to-shot variation in the energy spread, this is a 2D array of + dimension nP by m (slow to fast) of the spreads of the corresponding wavelength + in incident_wavelength. + + + + + In the case of a polychromatic beam this is an array of length m of the relative + weights of the corresponding energies in incident_energy. In the case of a + polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np + by m (slow to fast) of the relative weights of the corresponding energies in + incident_energy. + + + + + Energy on leaving beamline component + + + + + + + + Energy change caused by beamline component + + + + + + + + In the case of a monchromatic beam this is the scalar wavelength. + Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. + + * In the case of a polychromatic beam this is an array of length m of wavelengths, + with the relative weights in incident_wavelength_weights. + * In the case of a monochromatic beam that varies shot-to-shot, + this is an array of wavelengths, one for each recorded shot. + Here, incident_wavelength_weights and incident_wavelength_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, + single-value wavelength value is available along with the original spectrum from which it was calibrated. + + + + + + + + Wavelength spread FWHM on entering component + + + + + + + + Divergence of beam entering this component + + + + + + + + + Size of the beam entering this component + + + + + + + + + Wavelength on leaving beamline component + + + + + + + + Incident polarization as a Stokes vector + + + + + + + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. + Correct parsing can still be implemented by using this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: 'farad' for capacitance). + * A string describing the units according to unidata unit operation notation, + if the unit is a complex combination of named units and does not have a name. + + Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. + Here: SI units are 'V2/m2'. + + + + + + Polarization as Stokes vector on leaving beamline component + + + + + + + Here: SI units are 'V2/m2'. + + + + + + Wavelength spread FWHM of beam leaving this component + + + + + + + + Divergence FWHM of beam leaving this component + + + + + + + + + flux incident on beam plane area + + + + + + + + Energy of a single pulse at the diagnostic point + + + + + Average power at the diagnostic point + + + + + Incident fluence at the diagnostic point + + + + Here: SI units are ''J/m2'', customary ''mJ/cm2''. + + + + + + FWHM duration of the pulses at the diagnostic point + + + + + FROG trace of the pulse. + + + + + + + + Horizontal axis of a FROG trace, i.e. delay. + + + + + + + + Vertical axis of a FROG trace, i.e. frequency. + + + + + + + + The type of chirp implemented + + + + + Group delay dispersion of the pulse for linear chirp + + + + + Distribution of beam with respect to relevant variable e.g. wavelength. This is + mainly useful for simulations which need to store plottable information at each + beamline component. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index a70c0ca630..f965a19b0a 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -1,50 +1,90 @@ - Draft subclass of NXprocess to describe post-processing calibrations. - - 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 - - - - 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. - - - 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 - - - - - - Class to describe freely the procedures employed. - + + + 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/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 63fce0cd86..ca712ae686 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -1,53 +1,83 @@ - Draft subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. - - The symbols used in the schema to specify e.g. dimensions of arrays - - Number of lenses in the collection column - - - - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum microscope, etc. - - - Voltage applied to the extractor lens - - - Indicating leakage, field emission or arc currents to the extractor lens - - - Distance between sample and detector entrance - - - Set of names of electron optic lenses - - - - - - Array of corresponding voltages - - - - - - The space projected in the angularly dispersive directions, real or reciprocal - - - The magnification of the projected image in the angularly dispersive direction - - - The size and position of the field aperture inserted in the column - - - The size and postion of the contrast aperture inserted in the column. - - - Deflectors in the collection column section - - - Individual lenses in the collection column section - + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn 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 + 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. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml index 78bee2f44f..5da6ac0702 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -1,12 +1,12 @@ - + - Electro-static deflectors as they are used e.g. in an electron analyser. + Deflectors as they are used e.g. in an electron analyser. - Qualitative type of lens with respect to the number of pole pieces + Qualitative type of deflector with respect to the number of pole pieces @@ -17,70 +17,55 @@ - Colloquial or short name for the lens. For manufacturer names and + Colloquial or short name for the deflector. For manufacturer names and identifiers use respective manufacturer fields. - Name of the manufacturer who built/constructed the lens. + Name of the manufacturer who built/constructed the deflector. Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. + manufacturer to identify the deflector. - Ideally an identifier, persistent link, or free text which gives - further details about the lens. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - Excitation voltage of the lens. For dipoles it is a single number. For + Excitation voltage of the deflector. 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 + Excitation current of the deflector. For dipoles it is a single number. For higher orders, it is an array. + + + 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 corrector as a component in the - instrument. Conventions from the NXtransformations base class are - used. In principle, the McStas coordinate system is used. The origin - of the coordinate system is placed in the center of the gun pinhole as - the virtual point-like assumed source of the electron beam. A right- - handed coordinate system is assumed whose positive z-axis points in - the direction of the propagating electron beam. + 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 + 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. - - - - Following transformation_type argument of NXtranslations but allowed - value is only translation. - - - - - Following vector argument of NXtranslations. The translation actively - brings the coordinate system under depends_on into registration with a - coordinate system in the center of the lens. - - - - - Enter the path where the reference coordinate system for the - instrument is defined. - - - diff --git a/contributed_definitions/NXdetector.nxdl.xml b/contributed_definitions/NXdetector.nxdl.xml new file mode 100644 index 0000000000..92184395e8 --- /dev/null +++ b/contributed_definitions/NXdetector.nxdl.xml @@ -0,0 +1,801 @@ + + + + + + These symbols will be used below to coordinate datasets with the same + shape. + + + + number of scan points (only present in scanning measurements) + + + + + number of detector pixels in the first (slowest) direction + + + + + number of detector pixels in the second (faster) direction + + + + + number of detector pixels in the third (if necessary, fastest) + direction + + + + + number of bins in the time-of-flight histogram + + + + + A detector, detector bank, or multidetector. + + + + Total time of flight + + + + + + + + + + + + + + + + + Total time of flight + + + + + + In DAQ clock pulses + + + + + + + Clock frequency in Hz + + + + + + Identifier for detector (pixels) Can be multidimensional, if needed + + + + + Data values from the detector. + + + + + + + + + + Title of measurement + + + + + Integral of data as check of data integrity + + + + + + The best estimate of the uncertainty in the data value. Where possible, this + should be the standard deviation, which has the same units as the data. The form + data_error is deprecated. + + + + + + + + + + + Offset from the detector center in x-direction. Can be multidimensional when + needed. + + + + + + + + + + + + + + x-axis offset from detector center + + + + + + Offset from the detector center in the y-direction. Can be multidimensional when + different values are required for each pixel. + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + Offset from the detector center in the z-direction. Can be multidimensional when + different values are required for each pixel. + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + This is the distance to the previous component in the instrument; most often the + sample. The usage depends on the nature of the detector: Most often it is the + distance of the detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + + + + + + + + + This is the polar angle of the detector towards the previous component in the + instrument; most often the sample. The usage depends on the nature of the + detector. Most often it is the polar_angle of the detector assembly. But there + are irregular detectors. In this case, the polar_angle must be specified for + each detector pixel. + + + + + + + + + + This is the azimuthal angle angle of the detector towards the previous component + in the instrument; most often the sample. The usage depends on the nature of the + detector. Most often it is the azimuthal_angle of the detector assembly. But + there are irregular detectors. In this case, the azimuthal_angle must be + specified for each detector pixel. + + + + + + + + + + name/manufacturer/model/etc. information + + + + + Serial number for the detector + + + + + Local name for the detector + + + + + Position and orientation of detector + + + + + Solid angle subtended by the detector at the sample + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size. + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size + + + + + + + + + Detector dead time + + + + + + + + + + Detector gas pressure + + + + + + + + + maximum drift space dimension + + + + + Crate number of detector + + + + + + + + Equivalent local term + + + + + + Slot number of detector + + + + + + + + Equivalent local term + + + + + + Input number of detector + + + + + + + + Equivalent local term + + + + + + Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission + chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, ... + + + + + Spectral efficiency of detector with respect to e.g. wavelength + + + + + + + + + + + + + + + + + + + + + + + efficiency of the detector + + + + + + + + + + This field can be two things: + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + + + + + + + + + + + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + + + + + + + + + + Start time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + stop time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + date of last calibration (geometry and/or efficiency) measurements + + + + + summary of conversion of array data to pixels (e.g. polynomial approximations) + and location of details of the calibrations + + + + + How the detector is represented + + + + + + + + + + Elapsed actual counting time + + + + + + + + + Use this group to provide other data related to this NXdetector group. + + + + + In order to properly sort the order of the images taken in (for example) a + tomography experiment, a sequence number is stored with each image. + + + + + + + + This is the x position where the direct beam would hit the detector. This is a + length and can be outside of the actual detector. The length can be in physical + units or pixels as documented by the units attribute. + + + + + This is the y position where the direct beam would hit the detector. This is a + length and can be outside of the actual detector. The length can be in physical + units or pixels as documented by the units attribute. + + + + + This is the start number of the first frame of a scan. In PX one often scans a + couple of frames on a give sample, then does something else, then returns to the + same sample and scans some more frames. Each time with a new data file. This + number helps concatenating such measurements. + + + + + The diameter of a cylindrical detector + + + + + The acquisition mode of the detector. + + + + + + + + + + + + + True when the angular calibration has been applied in the electronics, false + otherwise. + + + + + Angular calibration data. + + + + + + + + + True when the flat field correction has been applied in the electronics, false + otherwise. + + + + + Flat field correction data. + + + + + + + + + Errors of the flat field correction data. The form flatfield_error is + deprecated. + + + + + + + + + True when the pixel mask correction has been applied in the electronics, false + otherwise. + + + + + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + + + + + + + + + True when a count-rate correction has already been applied in the electronics, + false otherwise. + + + + + How many bits the electronics reads per pixel. With CCD's and single photon + counting detectors, this must not align with traditional integer sizes. This can + be 4, 8, 12, 14, 16, ... + + + + + Time it takes to read the detector (typically milliseconds). This is important + to know for time resolved experiments. + + + + + Time it takes to start exposure after a trigger signal has been received. This + is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set + delay.. This is important to know for time resolved experiments. + + + + + User-specified trigger delay. + + + + + Time it takes to start exposure after a trigger signal has been received. This + is the reaction time of the detector hardware after receiving the trigger signal + to when the detector starts to acquire the exposure. It forms the lower boundary + of the trigger_delay_time when the user does not request an additional delay. + + + + + Time during which no new trigger signal can be accepted. Typically this is the + trigger_delay_time + exposure_time + readout_time. This is important to know for + time resolved experiments. + + + + + This is time for each frame. This is exposure_time + readout time. + + + + + + + + The gain setting of the detector. This influences background etc. + + + + + + + + + + + The value at which the detector goes into saturation. Especially common to CCD + detectors, the data is known to be invalid above this value. For example, given + a saturation_value and an underload_value, the valid pixels are those less than + or equal to the saturation_value and greater than or equal to the + underload_value. + + + + + The lowest value at which pixels for this detector would be reasonably measured. + The data is known to be invalid below this value. For example, given a + saturation_value and an underload_value, the valid pixels are those less than or + equal to the saturation_value and greater than or equal to the underload_value. + + + + + CCD images are sometimes constructed by summing together multiple short + exposures in the electronics. This reduces background etc. This is the number of + short exposures used to sum images for an image. + + + + + At times, radiation is not directly sensed by the detector. Rather, the detector + might sense the output from some converter like a scintillator. This is the name + of this converter material. + + + + + At times, radiation is not directly sensed by the detector. Rather, the detector + might sense the output from some converter like a scintillator. This is the + thickness of this converter material. + + + + + Single photon counter detectors can be adjusted for a certain energy range in + which they work optimally. This is the energy setting for this. + + + + + For use in special cases where the data in NXdetector is represented in several + parts, each with a separate geometry. Use one or more instances of the + NXdetector_module group to declare regions of interest or some other subdivision + of a detector. + + + + Shape description of the whole detector. Use only if pixels in the detector are + not of uniform shape. + + + + + Shape description of the whole detector. Use only if pixels in the detector are + not of uniform shape and require being described by cylinders. + + + + + + .. 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. + + + + + Type of electron amplifier, MCP, channeltron, etc. + + + + + Description of the detector type, DLD, Phosphor+CCD, CMOS. + + + + + Voltage applied to detector. + + + + + Voltage applied to the amplifier. + + + + + The low voltage of the amplifier migh not be the ground. + + + + + Size of each imaging sensor chip on the detector. + + + + + Number of imaging sensor chips on the detector. + + + + + Physical size of the pixels of the imaging chip on the detector. + + + + + Number of raw active elements in each dimension. Important for swept scans. + + + + + raw data output from the detector + + + diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml index 62d393fd15..80413635c1 100644 --- a/contributed_definitions/NXdistortion.nxdl.xml +++ b/contributed_definitions/NXdistortion.nxdl.xml @@ -1,53 +1,90 @@ - Draft subclass of NXprocess to describe post-processing distortion correction. - - The symbols used in the schema to specify e.g. dimensions of arrays - - Number of symmetry points used for distortion correction - - - Number of points of the matrix distortion field (x direction) - - - Number of points of the matrix distortion field (y direction) - - - - Has the distortion correction been applied? - - - For symmetry-guided distortion correction (https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub), where a pattern of features is mapped to the regular geometric structure expected from the symmetry. Here we record the number of elementary symmetry operations. - - - For symmetry-guided distortion correction. Here we record the coordinates of the symmetry centre point. - - - - - - For symmetry-guided distortion correction. Here we record the coordinates of the relevant symmetry points. - - - - - - - Column deformation field for general non-rigid distortion corrections. 2D matrix holding the column information of the mapping of each original coordinate. - - - - - - - Row deformation field for general non-rigid distortion corrections. 2D matrix holding the row information of the mapping of each original coordinate. - - - - - - - Class to describe freely the procedures employed. - + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of symmetry points used for distortion correction + + + + + Number of points of the matrix distortion field (x direction) + + + + + Number of points of the matrix distortion field (y direction) + + + + + Subclass of NXprocess to describe post-processing distortion correction. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the distortion correction been applied? + + + + + For symmetry-guided distortion correction + (https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub), + where a pattern of features is mapped to the regular geometric structure + expected from the symmetry. Here we record the number of elementary symmetry + operations. + + + + + For symmetry-guided distortion correction. Here we record the coordinates of the + symmetry centre point. + + + + + + + + For symmetry-guided distortion correction. Here we record the coordinates of the + relevant symmetry points. + + + + + + + + + Column deformation field for general non-rigid distortion corrections. 2D matrix + holding the column information of the mapping of each original coordinate. + + + + + + + + + Row deformation field for general non-rigid distortion corrections. 2D matrix + holding the row information of the mapping of each original coordinate. + + + + + + + + + Description of the procedures employed. + + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 20a233d95a..100cf4455e 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -1,65 +1,136 @@ - Draft subclass of NXinstrument to describe a photoelectron analyser. - - The symbols used in the schema to specify e.g. dimensions of arrays - - Number of fast axes (axes acquired symultaneously, without scanning a pysical quantity) - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - Free text description of the type of the detector - - - Name or model of the equipment - - Acronym or other shorthand name - - - - Overall energy resolution (FWHM of gaussian broadening) - - - Overall momentum resolution (FWHM) - - - Overall angular resolution (FWHM) - - - Overall spatial resolution (Airy disk radius) - - - List of the axes that are acquired symultaneously by the detector. These refer only to the experimental variables recorded by the electron analyser. Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. Examples. Hemispherical in ARPES mode: fast_axes: [energy,kx] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] Tof: fast_axes: [energy, kx, ky] Momentum microscope, spin-resolved: fast_axes: [energy, kx, ky] slow_axes: [spin up-down, spin left-right] axes can be less abstract than this, i.e. [detector_x, detector_y]. If energy_scan_mode=sweep, fast_axes: [energy, kx]; slow_axes: [energy] is allowed. - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples. - - - - - - class to describe the electron collection (spatial and momentum imaging) column - - - class to describe the energy dispersion section - - - class to describe the spin dispersion section - - - class to describe the electron detector - - - Deflectors outside the main optics ensambles described by the subclasses - - - Individual lenses outside the main optics ensambles described by the subclasses - + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a + pysical quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + | Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + 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. + + + + + class to describe the electron collection (spatial and momentum imaging) column + + + + + class to describe the energy dispersion section + + + + + class to describe the spin dispersion section + + + + + class to describe the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 74897e91a1..7797a07080 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -1,38 +1,69 @@ - Draft subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. - - tof, hemispherical, cylindrical, mirror, retarding grid, etc. - - - Pass energy in dispersive electrodes - - - Center of the energy window - - - The interval of transmitted energies. It can be two different things depending on whether the scan is fixed or swept. With a fixed scan it is a 2 vector containing the extrema of the transmitted energy window (smaller number first). With a swept scan of m steps it is a 2xm array of windows one for each measurement point. - - - Size, position and shape of the entrance slits in dispersive analyzers - - - Size, position and shape of the exit slits in dispersive analyzer - - - Diameter of the dispersive orbit - - - fixed or sweep - - - Length of the tof drift electrode - - - deflectors in the energy dispersive section - - - Individual lenses in the energy dispersive section - + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + diff --git a/contributed_definitions/NXentry.nxdl.xml b/contributed_definitions/NXentry.nxdl.xml new file mode 100644 index 0000000000..804af5d1e4 --- /dev/null +++ b/contributed_definitions/NXentry.nxdl.xml @@ -0,0 +1,270 @@ + + + + + (**required**) :ref:`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. + + + + .. index:: plotting + + Declares which :ref:`NXdata` (or :ref:`NXsubentry`) group + contains the data to be shown by default. + It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. + The value is the name of the default :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. + + .. [#] NIAC2014 discussion summary: + https://www.nexusformat.org/2014_How_to_find_default_data.html + + + + + The data group + + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 + + + + + ISIS Muon IDF_Version + + + + + Extended title for entry + + + + + Unique identifier for the experiment, defined by the facility, possibly linked + to the proposals + + + + + Brief summary of the experiment, including key objectives. + + + + + Description of the full experiment (document in pdf, latex, ...) + + + + + User or Data Acquisition defined group of NeXus files or NXentry + + + + + Brief summary of the collection, including grouping criteria. + + + + + Unique identifier for the measurement, defined by the facility. + + + + + UUID identifier for the measurement. + + + + Version of UUID used + + + + + + Reserved for future use by NIAC. See + https://github.com/nexusformat/definitions/issues/382 + + + + + (alternate use: see same field in :ref:`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms. + This field is provided so that :ref:`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Local NXDL schema extended from the entry specified in the ``definition`` field. + This contains any locally-defined, additional fields in the entry. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Starting time of measurement + + + + + Ending time of measurement + + + + + Duration of measurement + + + + + Time transpired actually collecting data i.e. taking out time when collection + was suspended due to e.g. temperature out of range + + + + + Such as '2007-3'. Some user facilities organize their beam time into run cycles. + + + + + Name of program used to generate this file + + + + Program version number + + + + + configuration of the program + + + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a + chopper, by the moderator or the source itself. In other words: it the distance + to the component which gives the T0 signal to the detector electronics. If + another component in the NXinstrument hierarchy provides this information, this + should be a link. + + + + + City and country where the experiment took place + + + + + Start time of experimental run that includes the current measurement, for + example a beam time. + + + + + End time of experimental run that includes the current measurement, for example + a beam time. + + + + + Name of the institution hosting the facility + + + + + Name of the experimental facility + + + + + Name of the laboratory or beamline + + + + + Notes describing entry + + + + + A small image that is representative of the entry. An example of this is a + 640x480 jpeg image automatically produced by a low resolution plot of the + NXdata. + + + + The mime type should be an ``image/*`` + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXinstrument.nxdl.xml b/contributed_definitions/NXinstrument.nxdl.xml new file mode 100644 index 0000000000..2675763fd9 --- /dev/null +++ b/contributed_definitions/NXinstrument.nxdl.xml @@ -0,0 +1,82 @@ + + + + + Collection of the components of the instrument or beamline. Template of + instrument descriptions comprising various beamline components. Each component + will also be a NeXus group defined by its distance from the sample. Negative + distances represent beamline components that are before the sample while + positive distances represent components that are after the sample. This device + allows the unique identification of beamline components in a way that is valid + for both reactor and pulsed instrumentation. + + + + Name of instrument + + + + short name for instrument, perhaps the acronym + + + + + + Energy resolution of the experiment (FWHM or gaussian broadening) + + + + + Momentum resolution of the experiment (FWHM) + + + + + Angular resolution of the experiment (FWHM) + + + + + Spatial resolution of the experiment (Airy disk radius) + + + + + Temporal resolution of the experiment (FWHM) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + .. 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/NXlens.nxdl.xml b/contributed_definitions/NXlens.nxdl.xml deleted file mode 100644 index efa6162e45..0000000000 --- a/contributed_definitions/NXlens.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - Draft class definition for electro-static lenses as they are used e.g. in an electron analyser. - - Qualitative type of lens with respect to the number of pole pieces - - - - - - - - - - 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. - - - Collection of axis-based translations and rotations to describe the location and geometry of the corrector as a component in the instrument. Conventions from the NXtransformations base class are used. In principle, the McStas coordinate system is used. The origin of the coordinate system is placed in the center of the gun pinhole as the virtual point-like assumed source of the electron beam. A right-handed coordinate system is assumed whose positive z-axis points in the direction of the propagating electron beam. - - - Following transformation_type argument of NXtranslations but allowed value is only translation. - - - Following vector argument of NXtranslations. The translation actively brings the coordinate system under depends_on into registration with a coordinate system in the center of the lens. - - - Enter the path where the reference coordinate system for the instrument is defined. - - - - diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 53c512775d..3c4fbe65e7 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -1,60 +1,75 @@ - + - An electro-magnetic lens. + Description of an electro-magnetic lens or a compound lens. + + Details of an [electro-magnetic lens](https://dx.doi.org/10.1007/978-3-540-38967-5). + + 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. - Qualitative type of lens with respect to the number of pole pieces. + Qualitative type of lens with respect to the number of pole pieces - + - Given name. + 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. + + + - Given brand or model name by the manufacturer. + 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. - + - Given hardware name/serial number or hash identifier issued by the - manufacturer. + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. - + - Given name of the manufacturer. + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. - + - Ideally an identifier, persistent link, or free text which gives - further details about the lens. + 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 corrector as a component in the - instrument. Conventions from the NXtransformations base class are - used. In principle, the McStas coordinate system is used. The origin - of the coordinate system is placed in the center of the gun pinhole as - the virtual point-like assumed source of the electron beam. A right- - handed coordinate system is assumed whose positive z-axis points in - the direction of the propagating electron beam. The translation - actively brings the coordinate system under depends_on into - registration with a coordinate system in the center of the lens. + 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 index 4c276652b3..8329af427e 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -1,76 +1,79 @@ - Draft extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. - - The symbols used in the schema to specify e.g. dimensions of arrays - - Number of linear coordinates used to describe the manipulator position - - - Number of angular coordinates used to describe the manipulator position - - - Number of positions assumed by the manipulator during the measurement (differing even by just one coordinate or angle) - - - - Name - - - Description - - - Type of manipulator, Hexapod, Rod, etc. - - - Coordinates of the manipulator position (x,y,z) - - - - - - Angles of the manipulator orientation (polar,tilt,azimuth) - - - - - - Effective positions assumed by the manipulator during the measurement. - - - - - - - Effective angles assumed by the manipulator during the measurement. - - - - - - - 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 - - - Current to neutralize the photoemission current - - - Possible bias of the sample with trespect to analyser ground - - - class to describe the motors that are used in the manipulator - - - class to describe the transformations used. - + + 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/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index cabf2a37ec..4a312fe70c 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -1,248 +1,298 @@ - - Most general application definition for multidimensional photoelectron spectroscopy. - - It can be used for ARPES, XPS, etc. More specialized application definitions are derived from it. - - The symbols used in the schema to specify e.g. dimensions of arrays - - Number of fast axes (acquired simutaneously) e.g. emission angle, kinetic energy - - - Number of slow axes (acquired scanning a physical quantity) e.g. lens voltage, spin direction - - - - - NeXus convention is to use "entry1", "entry2", for analysis software to locate each entry. - - - Default plottable NX data object. - - - - ISO8601 formatted date time of the start of the measurement. - - - - - - - - - - The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - In the case of a monchromatic beam this is the scalar energy. Several other use cases are permitted, depending on the presence of other incident_energy_X fields. In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. Here, incident_energy_weights and incident_energy_spread are not set. In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_energy_weights as a 2D array. In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - - - The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in the energy spread, this is a 2D array of dimension nP by m (slow to fast) of the spreads of the corresponding energy in incident_energy. - - - In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding energies in incident_energy. In the case of a polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np by m (slow to fast) of the relative weights of the corresponding energies in incident_energy. - - - Incident polarization specified as a Stokes vector. - - The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: 'farad' for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. Here: SI units are 'V2/m2'. - - - - - - - - - Free text description of the type of detector. - - - Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. - - - List of the axes that are acquired symultaneously by the detector. These refer only to the experimental variables recorded by the electron analyser. Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. Examples: Hemispherical in ARPES mode: fast_axes: [energy,kx] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] Tof: fast_axes: [energy, kx, ky] Momentum microscope, spin-resolved: fast_axes: [energy, kx, ky] slow_axes: [spin up-down, spin left-right] axes can be less abstract than this, i.e. [detector_x, detector_y] If energy_scan_mode=sweep, fast_axes: [energy, kx]; slow_axes: [energy] is allowed. - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples. - - - - - - - Scheme of the electron collection column. - - - - - - - - - Labelling of the lens setting in use. - - - The space projected in the angularly dispersive directions, i.e. real or reciprocal. - - - - - - - - - Energy dispersion scheme employed. - - - - - - - - - - - energy of the electrons on the mean path of the analyser. Pass energy for hemispherics, drift energy for tofs. - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - Aperture generating the momentum and/or energy filtering. - - Type of aperture inserted in the beam. - - - - - - - - Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc. - - - - - - - - - - - - The relevant dimension for the aperture (slit width, pinhole diameter etc). - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Calibrated energy axis. - - - - - - - Has an energy calibration been applied? - - - - - - - - A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. Ideally, a full report of the previous operations, in any format (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. - - - ISO 8601 date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). - - - Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report of the previous operations, in any format(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. - - - In the case of a fixed temperature measurement this is the scalar temperature of the sample. In the case of an experiment in which the temperature is changed and recoded, this is an array of length m of temperatures. - - - - In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures. - - - - - - - - - - Processed plottable data. - - - + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + ISO8601 formatted date time of the start of the measurement. + + + + + + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of Nxcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (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. + + + + + ISO 8601 date of preparation of the sample for the XPS experiment (i.e. + cleaving, last annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(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. + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + diff --git a/contributed_definitions/NXmpes_ARPES.nxdl.xml b/contributed_definitions/NXmpes_ARPES.nxdl.xml deleted file mode 100644 index da5a52086e..0000000000 --- a/contributed_definitions/NXmpes_ARPES.nxdl.xml +++ /dev/null @@ -1,274 +0,0 @@ - - - - This is the most general application definition for multidimensional ARPES. - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - - - - - NeXus convention is to use "entry1", "entry2", for analysis software to locate each entry. - - - - - ISO8601 formatted date time of the start of the measurement. - - - - - - - - - - - The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - In the case of a monchromatic beam this is the scalar energy. Several other use cases are permitted, depending on the presence of other incident_energy_X fields. In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. Here, incident_energy_weights and incident_energy_spread are not set. In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_energy_weights as a 2D array. In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - - - The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in the energy spread, this is a 2D array of dimension nP by m (slow to fast) of the spreads of the corresponding energy in incident_energy. - - - In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding energies in incident_energy. In the case of a polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np by m (slow to fast) of the relative weights of the corresponding energies in incident_energy. - - - Incident polarization specified as a Stokes vector. - - The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: 'farad' for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. Here: SI units are 'V2/m2'. - - - - - - - - - Free text description of the type of detector. - - - Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. - - - Angular resolution of the analyser with the current setting. May be linked from a NXcalibration. - - - List of the axes that are acquired symultaneously by the detector. These refer only to the experimental variables recorded by the electron analyser. Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. Examples: Hemispherical in ARPES mode: fast_axes: [energy,kx] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] Tof: fast_axes: [energy, kx, ky] Momentum microscope, spin-resolved: fast_axes: [energy, kx, ky] slow_axes: [spin up-down, spin left-right] axes can be less abstract than this, i.e. [detector_x, detector_y] If energy_scan_mode=sweep, fast_axes: [energy, kx]; slow_axes: [energy] is allowed. - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples. - - - - - - - Scheme of the electron collection column. - - - - - - - - - Labelling of the lens setting in use. - - - The space projected in the angularly dispersive directions, i.e. real or reciprocal. - - - - - - - - - Energy dispersion scheme employed. - - - - - - - - - - - energy of the electrons on the mean path of the analyser. Pass energy for hemispherics, drift energy for tofs. - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - Aperture generating the momentum and/or energy filtering. - - Type of aperture inserted in the beam. - - - - - - - - Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc. - - - - - - - - - - - - The relevant dimension for the aperture (slit width, pinhole diameter etc). - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Calibrated kx momentum axis. - - - - - - Calibrated energy axis. - - - - - - - Has a distortion correction been applied? - - - - - Has an energy calibration been applied? - - - - - Has a momentum calibration been applied? - - - - - - - - A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. Ideally, a full report of the previous operations, in any format (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. - - - ISO 8601 date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). - - - Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report of the previous operations, in any format(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. - - - In the case of a fixed temperature measurement this is the scalar temperature of the sample. In the case of an experiment in which the temperature is changed and recoded, this is an array of length m of temperatures. - - - - In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures. - - - - - - - - - - - - - - - - - Processed plottable data. - - - Data containing the energy axis - - - Data containing the k parallel axis - - - - diff --git a/contributed_definitions/NXprocess.nxdl.xml b/contributed_definitions/NXprocess.nxdl.xml new file mode 100644 index 0000000000..d68e5cd3a7 --- /dev/null +++ b/contributed_definitions/NXprocess.nxdl.xml @@ -0,0 +1,64 @@ + + + + + Document an event of data processing, reconstruction, or analysis for this data. + + + + Name of the program used + + + + + Sequence index of processing, for determining the order of multiple + **NXprocess** steps. Starts with 1. + + + + + Version of the program used + + + + + Date and time of processing. + + + + + Describes the operations of image registration + + + + + Describes the operations of image distortion correction + + + + + Describes the operations of calibration procedures, e.g. axis calibrations. + + + + + Notes contain information about how the data was processed or anything about the + data provenance. The contents of the note can be anything that the processing + code can understand, or simple text. The name will be numbered to allow for + ordering of steps. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + diff --git a/contributed_definitions/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml index 812f66e37d..7ca7e404f9 100644 --- a/contributed_definitions/NXregistration.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,32 +1,34 @@ - Draft extension of NXobject to include fields to describe image registration procedures. - - Has the registration been applied? - - - Coordinates of the new centre point. - - - - - - Coordinates of the rotation centre. - - - - - - Scaling factor to compensate shrinking from distortion correction. - - - - - - To describe the operations of image registration (combinations of rigid translations and rotations) - - - Class to describe freely the procedures employed. - + + Describes image registration procedures. + + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + + + Description of the procedures employed. + + diff --git a/contributed_definitions/NXsample.nxdl.xml b/contributed_definitions/NXsample.nxdl.xml new file mode 100644 index 0000000000..742c3a0cd2 --- /dev/null +++ b/contributed_definitions/NXsample.nxdl.xml @@ -0,0 +1,599 @@ + + + + + + symbolic array lengths to be coordinated between various fields + + + + number of compositions + + + + + number of temperatures + + + + + number of values in applied electric field + + + + + number of values in applied magnetic field + + + + + number of values in applied pressure field + + + + + number of values in applied stress field + + + + + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + + + + Descriptive name of sample + + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * 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. + * This is the *Hill* system used by Chemical Abstracts. + + + + + Sample temperature. This could be a scanned variable + + + + + + + + Applied electric field + + + + + + + + + + + + + + + Applied magnetic field + + + + + + + + + + + + + + + Applied external stress field + + + + + + + + + + + + + + + Applied pressure + + + + + + + + Sample changer position + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Unit cell parameters (lengths and angles) + + + + + + + + + Volume of the unit cell + + + + + + + + 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. + + + + + + + + + + Mass of sample + + + + + + + + Density of sample + + + + + + + + Relative Molecular Mass of sample + + + + + + + + + + + + + + + + + + + + + + The atmosphere will be one of the components, which is where its details will be + stored; the relevant components will be indicated by the entry in the + sample_component member. + + + + + + + + + + + + + + Description of the sample + + + + + Date of preparation of the sample + + + + + The position and orientation of the center of mass of the sample + + + + + Details of beam incident on sample - used to calculate sample/beam interaction + point + + + + + One group per sample component This is the perferred way of recording per + component information over the n_comp arrays + + + + + Details of the component of the sample and/or can + + + + + + + + Type of component + + + + + + + + + + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + + + + + + Crystallographic point group, deprecated if space_group present + + + + + + + + Path length through sample/can for simple case when it does not vary with + scattering direction + + + + + Thickness of a beam entry/exit window on the can (mm). It is assumed to be the + same for entry and exit + + + + + sample thickness + + + + + Identification number or signatures of the sample used. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (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 + + + + + Physical state of the sample + + + + + Chemical purity of the sample + + + + + Surface termination of the sample (if crystalline) + + + + + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + + + + + Full chemical name of the sample + + + + + CAS registry number of the sample chemical content. + + + + + Gases might be fluxed on the surface for various reasons. Chemical designation, + or residual. + + + + + In the case of a fixed pressure measurement this is the scalar pressure. In the + case of an experiment in which pressure changes, or anyway is recorded, this is + an array of length m of pressures. + + + + + Element of evaporated surface dopant such as alkali or other + + + + + Nominal thickness of the evaporated dopant + + + + + Voltage applied to sample and sample holder. + + + + + Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition + etc.) + + + + + Name of the sample vendor (company or research group) + + + + + Material of the substrate in direct contact with the sample. + + + + + Physical state of the substrate, similar options to sample_state + + + + + Current to neutralize the photoemission current. This field may also be found in + NXmanpulator if present. + + + + + Possible bias of the sample with respect to analyser ground. This field may also + be found as sample_bias in NXmanipulator if present. + + + + + Further notes. + + + + + As a function of Wavelength + + + + + temperature.value is a link to e.g. temperature_env.sensor1.value + + + + + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + + + + + Additional sample temperature environment information + + + + + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + + + + + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value + + + + + Additional sample magnetic environment information + + + + + value sent to user's sample setup + + + + + logged value (or logic state) read from user's setup + + + + + 20 character fixed length sample description for legends + + + + + Optional rotation angle for the case when the powder diagram has been obtained + through an omega-2theta scan like from a traditional single detector powder + diffractometer + + + + + Translation of the sample along the X-direction of the laboratory coordinate + system + + + + + Translation of the sample along the Z-direction of the laboratory coordinate + system + + + + + Any positioner (motor, PZT, ...) used to locate the sample + + + + + 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/contributed_definitions/NXsource.nxdl.xml b/contributed_definitions/NXsource.nxdl.xml new file mode 100644 index 0000000000..b5874dde61 --- /dev/null +++ b/contributed_definitions/NXsource.nxdl.xml @@ -0,0 +1,274 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of points in a spectrum + + + + + The neutron or x-ray storage ring/facility. + + + + Effective distance from sample Distance as seen by radiation from sample. This + number should be negative to signify that it is upstream of the sample. + + + + + Name of source + + + + short name for source, perhaps the acronym + + + + + + Type of radiation source (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + + + + + + + + + Type of radiation probe (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + Source power + + + + + Source emittance (nm-rad) in X (horizontal) direction. + + + + + Source emittance (nm-rad) in Y (horizontal) direction. + + + + + Particle beam size in x + + + + + Particle beam size in y + + + + + Source intensity/area (example: s-1 cm-2) + + + + + Source energy. For storage rings, this would be the particle beam energy. For + X-ray tubes, this would be the excitation voltage. + + + + + Accelerator, X-ray tube, or storage ring current + + + + + Accelerator voltage + + + + + Frequency of pulsed source + + + + + Period of pulsed source + + + + + Pulsed source target material or other material used to generate light, e.g. He, + Ar gas for lasers, Xe or Hg/Cd vapor for arc lamps, etc. + + + + + + + + + + + + + + + + + + + Any source/facility related messages/events that occurred during the experiment + + + + + For storage rings, description of the bunch pattern. This is useful to describe + irregular bunch patterns. + + + + name of the bunch pattern + + + + + + For storage rings, the number of bunches in use. + + + + + For storage rings, temporal length of the bunch + + + + + For storage rings, time between bunches + + + + + Temporal width of source pulse + + + + + Source pulse shape + + + + + Source operating mode + + + + + For storage rings + + + + + For storage rings + + + + + + + Is the synchrotron operating in top_up mode? + + + + + For storage rings, the current at the end of the most recent injection. + + + + Date and time of the most recent injection. + + + + + + The center photon energy of the source, before it is monochromatized or + converted + + + + + The center wavelength of the source, before it is monochromatized or converted + + + + + For pulsed sources, the energy of a single pulse + + + + + For pulsed sources, the pulse energy divided by the pulse duration + + + + + Some facilities tag each bunch. First bunch of the measurement + + + + + Last bunch of the measurement + + + + + 'Engineering' location of source + + + + + The wavelength or energy distribution of the source + + + + + .. 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/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index d7477993ed..92230c1310 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -1,35 +1,76 @@ - Draft subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. - - Type of spin detector, VLEED, SPLEED, Mott, etc. - - - Figure of merit of the spin detector - - - Effective Shermann function, calibrated spin selectivity factor - - - Energy of the spin-selective scattering - - - Angle of the spin-selective scattering - - - Name of the target - - - Preparation procedure of the spin target - - - Date of last preparation of the spin target - - - deflectors in the spin dispersive section - - - Individual lenses in the spin dispersive section - + + Subclass of NXelectronanalyser to describe the spin filters in photoemission + experiments. + + + + Type of spin detector, VLEED, SPLEED, Mott, etc. + + + + + Figure of merit of the spin detector + + + + + Effective Shermann function, calibrated spin selectivity factor + + + + + Energy of the spin-selective scattering + + + + + Angle of the spin-selective scattering + + + + + Name of the target + + + + + Preparation procedure of the spin target + + + + + Date of last preparation of the spin target + + + + + 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 deflector 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. + + + + + Deflectors in the spin dispersive section + + + + + Individual lenses in the spin dispersive section + + diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index fd2b625e3d..5e75584c89 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -32,9 +32,6 @@ We created two new application definitions: :ref:`NXmpes`: A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. - :ref:`NXmpes_ARPES`: - A specialized appdef with metadata parameters to describe all ARPES experiments. - .. _NewBC: New Base Classes @@ -76,7 +73,7 @@ New Common Base Classes We developed two classes that are common to other techniques: - :ref:`NXlens`: + :ref:`NXlens_em`: A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. :ref:`NXdeflector` @@ -108,4 +105,7 @@ We use existent base classes in application definitions and add descriptors: Added descriptors specific to photoemission experiments. :ref:`NXsource` - Added descriptors for laboratory sources (X-ray, UV lamps) but mostly for ultrafat lasers with complex time structures. + Added descriptors for laboratory sources (X-ray, UV lamps) but mostly for ultrafast lasers with complex time structures. + + :ref:`NXinstrument` + Added descriptors for the overall resolutions of the experiment (energy, momentum, angular, spatial, temporal). From dd9fd8c2c6ad87609fd6435313cc1b87d9883ab5 Mon Sep 17 00:00:00 2001 From: domna Date: Fri, 17 Jun 2022 17:30:08 +0200 Subject: [PATCH 024/203] Fixes pipe error --- contributed_definitions/NXelectronanalyser.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 100cf4455e..93c0e2e69e 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -69,7 +69,7 @@ "Tof", "['energy', 'kx', 'ky']","" "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - | Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. From 87017dfbcdbdfa2db2fd68285b291bac37649eba Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 20 Jun 2022 08:23:38 +0200 Subject: [PATCH 025/203] Renams spindispersion fields + small docstring corrections --- contributed_definitions/NXdistortion.nxdl.xml | 4 ++-- contributed_definitions/NXmpes.nxdl.xml | 2 +- .../NXspindispersion.nxdl.xml | 16 ++++++++-------- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml index 80413635c1..ddad8fd782 100644 --- a/contributed_definitions/NXdistortion.nxdl.xml +++ b/contributed_definitions/NXdistortion.nxdl.xml @@ -36,11 +36,11 @@ - For symmetry-guided distortion correction - (https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub), + For `symmetry-guided distortion correction`_, where a pattern of features is mapped to the regular geometric structure expected from the symmetry. Here we record the number of elementary symmetry operations. + .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 4a312fe70c..f377f7fb10 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -98,7 +98,7 @@ The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of Nxcollectioncolumn. + additional or other apertures use the APERTURE group of NXcollectioncolumn. diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index 92230c1310..e0d39d0c98 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -5,42 +5,42 @@ Subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. - + Type of spin detector, VLEED, SPLEED, Mott, etc. - + Figure of merit of the spin detector - + Effective Shermann function, calibrated spin selectivity factor - + Energy of the spin-selective scattering - + Angle of the spin-selective scattering - + Name of the target - + Preparation procedure of the spin target - + Date of last preparation of the spin target From 621ea623de04cd22095bb4a9b563a12d7d9f1b74 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 20 Jun 2022 10:18:31 +0200 Subject: [PATCH 026/203] Fixes some rst formattings for proper html output --- contributed_definitions/NXcalibration.nxdl.xml | 4 ++-- contributed_definitions/NXelectronanalyser.nxdl.xml | 8 ++++---- contributed_definitions/NXlens_em.nxdl.xml | 4 +++- contributed_definitions/NXmpes.nxdl.xml | 4 ++-- 4 files changed, 11 insertions(+), 9 deletions(-) diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index f965a19b0a..85a30259c6 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -46,14 +46,14 @@ - "For non-linear energy calibrations. Here we can store the formula of the + 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." + The formula should be numpy compliant. diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 93c0e2e69e..0d8910a161 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -105,22 +105,22 @@ - class to describe the electron collection (spatial and momentum imaging) column + Describes the electron collection (spatial and momentum imaging) column - class to describe the energy dispersion section + Describes the energy dispersion section - class to describe the spin dispersion section + Describes the spin dispersion section - class to describe the electron detector + Describes the electron detector diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 3c4fbe65e7..e877fea90c 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -4,11 +4,13 @@ Description of an electro-magnetic lens or a compound lens. - Details of an [electro-magnetic lens](https://dx.doi.org/10.1007/978-3-540-38967-5). + Details of an `electro-magnetic 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. + + .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index f377f7fb10..dde69ad412 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -9,7 +9,7 @@ - ISO8601 formatted date time of the start of the measurement. + Datetime of the start of the measurement. @@ -248,7 +248,7 @@ - ISO 8601 date of preparation of the sample for the XPS experiment (i.e. + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). From 415cc5d51e158bb4d51903ca76e4bcf51ca81a7d Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 20 Jun 2022 22:51:19 +0200 Subject: [PATCH 027/203] Additional naming symplification in NXspindisperision --- contributed_definitions/NXspindispersion.nxdl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index e0d39d0c98..9b2df6668f 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -5,17 +5,17 @@ Subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. - + Type of spin detector, VLEED, SPLEED, Mott, etc. - + Figure of merit of the spin detector - + Effective Shermann function, calibrated spin selectivity factor From 9224acbd587b6693c552c056112c51de89845b03 Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 21 Jun 2022 09:55:19 +0200 Subject: [PATCH 028/203] Updates xsi:schemaLocation --- contributed_definitions/NXaperture.nxdl.xml | 2 +- contributed_definitions/NXapm.nxdl.xml | 2 +- contributed_definitions/NXbeam.nxdl.xml | 2 +- contributed_definitions/NXcalibration.nxdl.xml | 2 +- contributed_definitions/NXchamber.nxdl.xml | 2 +- contributed_definitions/NXcollectioncolumn.nxdl.xml | 2 +- contributed_definitions/NXcorrector_cs.nxdl.xml | 2 +- contributed_definitions/NXdeflector.nxdl.xml | 2 +- contributed_definitions/NXdetector.nxdl.xml | 2 +- contributed_definitions/NXdistortion.nxdl.xml | 2 +- contributed_definitions/NXelectronanalyser.nxdl.xml | 2 +- contributed_definitions/NXellipsometry.nxdl.xml | 2 +- contributed_definitions/NXem_nion.nxdl.xml | 2 +- contributed_definitions/NXenergydispersion.nxdl.xml | 2 +- contributed_definitions/NXentry.nxdl.xml | 2 +- contributed_definitions/NXfib.nxdl.xml | 2 +- contributed_definitions/NXinstrument.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 2 +- contributed_definitions/NXlens_em.nxdl.xml | 2 +- contributed_definitions/NXmanipulator.nxdl.xml | 2 +- contributed_definitions/NXmpes.nxdl.xml | 2 +- contributed_definitions/NXpeak.nxdl.xml | 2 +- contributed_definitions/NXprocess.nxdl.xml | 2 +- contributed_definitions/NXpulser_apm.nxdl.xml | 2 +- contributed_definitions/NXpump.nxdl.xml | 2 +- contributed_definitions/NXreflectron.nxdl.xml | 2 +- contributed_definitions/NXregistration.nxdl.xml | 2 +- contributed_definitions/NXsample.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 2 +- contributed_definitions/NXsource.nxdl.xml | 2 +- contributed_definitions/NXspindispersion.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- 32 files changed, 32 insertions(+), 32 deletions(-) diff --git a/contributed_definitions/NXaperture.nxdl.xml b/contributed_definitions/NXaperture.nxdl.xml index ce104d6500..6877dc01a6 100644 --- a/contributed_definitions/NXaperture.nxdl.xml +++ b/contributed_definitions/NXaperture.nxdl.xml @@ -1,6 +1,6 @@ - + A beamline aperture diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index e11d65c8a0..649700719a 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -1,6 +1,6 @@ - + Atom probe tomography and field-ion microscopy experiments. diff --git a/contributed_definitions/NXbeam.nxdl.xml b/contributed_definitions/NXbeam.nxdl.xml index 0aa3caefac..dac93f7faf 100644 --- a/contributed_definitions/NXbeam.nxdl.xml +++ b/contributed_definitions/NXbeam.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 85a30259c6..16e54bd054 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml index c7fbbdf134..5f2b76370c 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -1,6 +1,6 @@ - + Component of an instrument to store or place objects and specimens. diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index ca712ae686..13e0d213f3 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -1,6 +1,6 @@ - + Subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index e3d65fa2ba..4c80693b80 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -1,6 +1,6 @@ - + Device for correcting spherical aberrations in an electron microscope. diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml index 5da6ac0702..1af741055d 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -1,6 +1,6 @@ - + Deflectors as they are used e.g. in an electron analyser. diff --git a/contributed_definitions/NXdetector.nxdl.xml b/contributed_definitions/NXdetector.nxdl.xml index 92184395e8..d5df7c8c66 100644 --- a/contributed_definitions/NXdetector.nxdl.xml +++ b/contributed_definitions/NXdetector.nxdl.xml @@ -1,6 +1,6 @@ - + These symbols will be used below to coordinate datasets with the same diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml index ddad8fd782..5a8b02b788 100644 --- a/contributed_definitions/NXdistortion.nxdl.xml +++ b/contributed_definitions/NXdistortion.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 0d8910a161..c08d6649f7 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index c43de1e65a..ed529d4e89 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -1,6 +1,6 @@ - + Ellipsometry, complex systems, up to variable angle spectroscopy. diff --git a/contributed_definitions/NXem_nion.nxdl.xml b/contributed_definitions/NXem_nion.nxdl.xml index d44a5f9c8f..bcd7f2ab11 100644 --- a/contributed_definitions/NXem_nion.nxdl.xml +++ b/contributed_definitions/NXem_nion.nxdl.xml @@ -1,6 +1,6 @@ - + (Scanning) transmission electron microscopy with a Nion instrument. diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 7797a07080..def450232e 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -1,6 +1,6 @@ - + Subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. diff --git a/contributed_definitions/NXentry.nxdl.xml b/contributed_definitions/NXentry.nxdl.xml index 804af5d1e4..b062a10d3d 100644 --- a/contributed_definitions/NXentry.nxdl.xml +++ b/contributed_definitions/NXentry.nxdl.xml @@ -1,6 +1,6 @@ - + (**required**) :ref:`NXentry` describes the measurement. diff --git a/contributed_definitions/NXfib.nxdl.xml b/contributed_definitions/NXfib.nxdl.xml index d784f95dab..d80f12ce7a 100644 --- a/contributed_definitions/NXfib.nxdl.xml +++ b/contributed_definitions/NXfib.nxdl.xml @@ -1,6 +1,6 @@ - + Set of devices adding focused-ion beam capabilities to an instrument. diff --git a/contributed_definitions/NXinstrument.nxdl.xml b/contributed_definitions/NXinstrument.nxdl.xml index 2675763fd9..bec81c7a30 100644 --- a/contributed_definitions/NXinstrument.nxdl.xml +++ b/contributed_definitions/NXinstrument.nxdl.xml @@ -1,6 +1,6 @@ - + Collection of the components of the instrument or beamline. Template of instrument descriptions comprising various beamline components. Each component diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 7bad29a55e..94138eee26 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -1,6 +1,6 @@ - + Set of atoms of a molecular ion or fragment in ToF mass spectrometry. diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index e877fea90c..607b4a8b65 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -1,6 +1,6 @@ - + Description of an electro-magnetic lens or a compound lens. diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index 8329af427e..d961e331bc 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -1,6 +1,6 @@ - + Extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index dde69ad412..8f20886ee0 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -1,6 +1,6 @@ - + This is the most general application definition for multidimensional photoelectron spectroscopy. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 0272321dad..1b502fe69f 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -1,6 +1,6 @@ - + Description of peaks, their functional form or measured support. diff --git a/contributed_definitions/NXprocess.nxdl.xml b/contributed_definitions/NXprocess.nxdl.xml index d68e5cd3a7..5b12ff4776 100644 --- a/contributed_definitions/NXprocess.nxdl.xml +++ b/contributed_definitions/NXprocess.nxdl.xml @@ -1,6 +1,6 @@ - + Document an event of data processing, reconstruction, or analysis for this data. diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index a8159da6e0..e8036d8553 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -1,6 +1,6 @@ - + Laser-, voltage-, or combined- pulsing to trigger field evaporation. diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index 24de539b52..c0c2accd58 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -1,6 +1,6 @@ - + Device to create reduce an atmosphere to a controlled remaining pressure level. diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml index 936f2f5ae2..e47db3f78f 100644 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -1,6 +1,6 @@ - + Device for reducing flight time differences of ions in ToF experiments. diff --git a/contributed_definitions/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml index 7ca7e404f9..8ddd155260 100644 --- a/contributed_definitions/NXregistration.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,6 +1,6 @@ - + Describes image registration procedures. diff --git a/contributed_definitions/NXsample.nxdl.xml b/contributed_definitions/NXsample.nxdl.xml index 742c3a0cd2..5dac64b788 100644 --- a/contributed_definitions/NXsample.nxdl.xml +++ b/contributed_definitions/NXsample.nxdl.xml @@ -1,6 +1,6 @@ - + symbolic array lengths to be coordinated between various fields diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 196b963422..8b05733062 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -1,6 +1,6 @@ - + Scan unit in an electron microscope which controls the electron beam. diff --git a/contributed_definitions/NXsource.nxdl.xml b/contributed_definitions/NXsource.nxdl.xml index b5874dde61..ae24b92e00 100644 --- a/contributed_definitions/NXsource.nxdl.xml +++ b/contributed_definitions/NXsource.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index 9b2df6668f..71668a6480 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -1,6 +1,6 @@ - + Subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index f4ab8d8431..6a68c30c76 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -1,6 +1,6 @@ - + Device which holds, aligns, orients, stimulates a specimen. From c421d29f08a07f58d2cb5c3043aede5ab711e3ff Mon Sep 17 00:00:00 2001 From: sanbrock Date: Thu, 30 Jun 2022 16:42:38 +0200 Subject: [PATCH 029/203] added Appdef for IV_temp --- contributed_definitions/NXIVtemp.nxdl.xml | 189 ++++++++++++++++++++++ 1 file changed, 189 insertions(+) create mode 100644 contributed_definitions/NXIVtemp.nxdl.xml diff --git a/contributed_definitions/NXIVtemp.nxdl.xml b/contributed_definitions/NXIVtemp.nxdl.xml new file mode 100644 index 0000000000..b67a4cc436 --- /dev/null +++ b/contributed_definitions/NXIVtemp.nxdl.xml @@ -0,0 +1,189 @@ + + + + Draft application definition for temperature dependent IV curve measurements. In this application definition, times should be specified always together with a UTC offset. + + Variables used throughout the document, e.g. dimensions and important parameters + + Number of elements in the scanned voltage array + + + Number of additional variables that are changed with the temperature (can be understood as columns next to the temperature) + + + Number of different temperatures that are set + + + + This is the application definition describing temperature dependent IV curve measurements. For this a temperature is set. After reaching the temperature a voltage sweep is performed and for each voltage a current is measured. Then the next desired temperature is set and an IV measurement is performed. + +The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description + + An application definition for temperature dependent IV curve measurements. + + Version number to identify which definition of this application definition was used for this entry/data. + + + URL where to find further material (documentation, examples) relevant to the application definition + + + + Unique identifier of the experiment, such as a (globally persistent) unique identifier. - The identifier is usually defined by the facility or principle investigator. - The identifier enables to link experiments to e.g. proposals. + + + Description of the exact experiment performed. + + + UTC offset should be specifiec. + + + Define the program that was used to generate the results file(s) with measured data and metadata. + + Commercial or otherwise defined given name of the program (or a link to the instrument software). + + + Either version with build number, commit hash, or description of a (online) repository where the source code of the program and build instructions can be found so that the program can be configured in such a way that result files can be created ideally in a deterministic manner. + + + Website of the software. + + + + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. + + Name of the user. + + + Name of the affiliation of the user at the point in time when the experiment was performed. + + + Full address (street, street number, ZIP, city, country) of the user's affiliation. + + + Email address of the user. + + + Author ID defined by https://orcid.org/. + + + Official telephone number of the user. + + + + General properties of the temperature dependent IV curve measurements equipment + + Specify the used voltage source used in the voltage sweep for the IV measurement. + + Free-text desribing the model and make of the voltage source which is used for the IV sweep measurement + + + Custom name of the voltage source for the IV sweep given by the user/institution + + + Free-text describing the measurement performed in a few words + + + Free-text describing the type of voltage setting: an internal sweep using the functionality of the voltage supply, or a set/wait/read/repeat mechanism. + + + + Specify the used current source used in the voltage sweep for the IV measurement. + + Free-text desribing the model and make of the current source which is used for the IV sweep measurement + + + Custom name of the current source for the IV sweep given by the user/institution + + + Free-text describing the measurement performed in a few words + + + Free-text describing the type of current measuring: an internal sweep using the functionality of the voltage supply, or a set/wait/read/repeat mechanism. + + + + Calibration of the temperature sensor is possible + + ISO8601 datum when calibration was last performed before this measurement. UTC offset should be specifiec. + + + + Describes the system for controlling the temperature if temperature control was used. + + What kind of temperature control was used? PID, custom temp control? + + + Specify the settings of the PID temperature controller: K_p, K_i, and K_d values used for the temperature control + + 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 contribution from the integral term is proportional to both the magnitude of the error and the duration of the error. The integral in a PID controller is the sum of the instantaneous error over time and gives the accumulated offset that should have been corrected previously. The accumulated error is then multiplied by the integral gain (Ki) and added to the controller output + + + The derivative of the process error is calculated by determining the slope of the error over time and multiplying this rate of change by the derivative gain K_d. The magnitude of the contribution of the derivative term to the overall control action is termed the derivative gain, K_d + + + + Specify the temperature sensor that was used + + + + + + + + + If you specified 'other' as temperature sensor, please write down what it is. + + + + + + Data of the most principal measurement of the temperature. For example resistance of a Pt1000. + + + Algebraic function that is used to determine temperature from the raw_temp_data. All values should be given in SI units. + + + + + Properties of the sample, its history, the sample environment and experimental conditions (e.g. surrounding medium, temperature, pressure etc.), along with the data (data type, wavelength array, measured data). + + Descriptive name of the sample + + + Ideally, a reference to the location or a unique (globally persistent) identifier (e.g.) of e.g. another file which gives as many as possible details of the material, its microstructure. In the case that such a detailed history of the sample is not available, use this field as a free-text description to specify details of the sample and its preparation. + + + ISO 8601 date with time zone specified. UTC offset should be specifiec. + + + An identifier to correlate data to the experimental conditions, if several were used in this measurement; typically an index of 0 - N + + + Resulting data from the measurement, described by data type. + + + + + + + + Information about external parameters that have influenced the sample. + + + Indicates which parameter was changed. Its definition must exist below. The specified variable has to be number_of_runs long, providing the parameters for each data set. + + + + + + + A default view of the data. The current (y-axis) should be plotted against the voltage (x-axis) with color coding for the temperature of each IV-curve + + We recommend to use voltage as a default attribute + + + + From d774dc9d91a4493504bafe4580187aab96899208 Mon Sep 17 00:00:00 2001 From: sanbrock Date: Fri, 1 Jul 2022 10:26:01 +0200 Subject: [PATCH 030/203] fix type=NX_DIMENSIONLESS in NXxpcs --- contributed_definitions/NXxpcs.nxdl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXxpcs.nxdl.xml b/contributed_definitions/NXxpcs.nxdl.xml index 3f7019d417..3024dd7d1c 100644 --- a/contributed_definitions/NXxpcs.nxdl.xml +++ b/contributed_definitions/NXxpcs.nxdl.xml @@ -485,7 +485,7 @@ development of new NeXus definitions for GI-SAXS or other reciprocal space intensity mapping. - + roi index array or labeled array @@ -521,7 +521,7 @@ List order is determined by the index value of the associated roi map starting at ``1``. - + roi index array. From a44ea9b708d3d988017b8373ba1bbb8e4203c132 Mon Sep 17 00:00:00 2001 From: sanbrock Date: Wed, 6 Jul 2022 17:19:46 +0200 Subject: [PATCH 031/203] local fix for bad use of NXtransformations in NXcxi_ptycho --- contributed_definitions/NXcxi_ptycho.nxdl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXcxi_ptycho.nxdl.xml b/contributed_definitions/NXcxi_ptycho.nxdl.xml index 2a6a02174a..e0f9c0efcc 100644 --- a/contributed_definitions/NXcxi_ptycho.nxdl.xml +++ b/contributed_definitions/NXcxi_ptycho.nxdl.xml @@ -213,7 +213,7 @@ - + This must contain two fields with the x and y motors that are linked via the dependency tree according to the real-life motor layout dependency. @@ -222,7 +222,7 @@ An attribute with the units for each motor is required. - + From 8061df7ebfd14be1b9b8dd1185b36b4894fae319 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Thu, 7 Jul 2022 20:49:25 +0200 Subject: [PATCH 032/203] Updated introductory sections for the mainpage, em, and apm of the proposal guiding to appdefs and base classes --- manual/source/apm-structure.rst | 30 +++--- manual/source/em-structure.rst | 96 ++++++++++++++++--- manual/source/fairmat-cover.rst | 157 ++++++++++++++++++++------------ 3 files changed, 203 insertions(+), 80 deletions(-) diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 15958e4e25..44446d92f7 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -36,31 +36,37 @@ New Base Classes We developed new base classes to structure the application definition into lab experiment and computational steps: + :ref:`NXchamber`: + A base class to describe a component of the instrument which houses other components. A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. + + :ref:`NXcoordinate_system_set` + A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. + :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described.: + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. - :ref:`NXreflectron`: - A base class to describe an optional reflectron device that influences the flight path of evaporated ions. + :ref:`NXmanufacturer`: + A base class to bundle manufacturer/vendor-specific details about a component or device of an instrument. :ref:`NXpeak`: A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + :ref:`NXpump`: + A base class to describe details about a pump in an instrument. + :ref:`NXpulser_apm`: A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. - :ref:`NXstage_lab`: - A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an - atom probe microscope or especially an electron microscopy offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and in an atom probe, given that both offer fixture functionalities and additional components such as for applying stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. - - :ref:`NXchamber`: - A base class to describe a component of the instrument which houses other components. A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. - - :ref:`NXpump`: - A base class to describe a component which reduce the partial/total pressure in a chamber to some controlled value so that an experiment can be performed. Most commonly this class can be used for representing and storing details of e.g. the vacuum pumping system. + :ref:`NXreflectron`: + A base class to describe an optional reflectron device that influences the flight path of evaporated ions. :ref:`NXreflectron`: A base class to describe a kinetic energy sensitive filtering device for ToF. + :ref:`NXstage_lab`: + A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an + atom probe microscope or especially an electron microscopy offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and in an atom probe, given that both offer fixture functionalities and additional components such as for applying stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. + Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 2a127fc40c..9f2185e095 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -17,45 +17,119 @@ Electron Microscopy Structure Introduction ############## -Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. Realizing that we need to start somewhere, though, we focus for now on the condensed-matter physics, chemical physics of solids, and materials science applications of electron microscopy. As many of the components of the electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident the here presented data storage objects can also inspire discussion and exchange with the bio-materials community in the future. +Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. Realizing that we need to start somewhere, though, we focus for now on the condensed-matter physics, chemical physics of solids, and materials science applications of electron microscopy. As many of the components of the electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. -Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with those classical instrument control and data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software, which makes it additionally difficult to keep track of workflows and identify what conceptually the specific quantities in the control software display represent and how these can be connected to the development of ontologies for electron microscopy experiments. +Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with those classical instrument control and data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software, which makes it additionally difficult to keep track of workflows and identify. Not only this it is also often challenging to identify what specific quantities in the control software mean and represent in technical detail and how these +quantities can be connected to the development of ontologies for electron microscopy experiments. .. _EmNewAppDef: New Application Definitions ############################ -We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet remains easy enough and useful across a variety of instruments, vendors, and instrument use cases. Therefore, we conceptualized first the basic components of an electron microscope. Next, we wrote base classes to describe these and then started to work on two fronts to arrive at specific application definitions. For now we focus on NXem_nion: +We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet remains easy enough and useful across a variety of instruments, vendors, and instrument use cases. Therefore, we conceptualized first the basic components of an electron microscope and the usual workflow how an electron microscope is used. That is scientists place a specimen/sample into the microscope calibrate the instrument take measurements, may perform experiments or prepare their specimens with a focused ion beam, calibrate again and take other measurements. In between virtually all these steps data are being collected which come from different detectors probing different physical mechanisms of the interaction between electrons with the material of the specimen. The session ends with the scientist removing +the specimen from the instrument or parking it so that the next user can take its time at the instrument. Next, we wrote base classes to describe these steps and events. - :ref:`NXem_nion`: - A general application definition which explores the possibilities of scanning transmission electron microscopes that use an open instrument control and analysis software. Specifically, we draft the application for users of Nion microscopes. An extension to supporting multi-signal sources is currently explored and will be implemented with the next release of the application definition. + :ref:`NXem`: + A general application definition which explores the possibilities of electron microscopes. .. _EmNewBC: New Base Classes ################# -We developed entirely new base classes: +We developed entirely new base classes. Some of them are also used for other techniques of this proposal but mentioned here for completeness: - :ref:`NXcorrector_cs`: - A base class to describe the instrument components which correct spherical distortions. - :ref:`NXfib`: - A base class which represents the components of a focused-ion beam column of an electron microscope as well as serves as a place for storing details of the control software. We envision this base class to be used as an add-on to customize an application definition for an (electron) microscope with focused-ion beam capabilities. + :ref:`NXaberration`: + A base class to describe detailed parameters of optical models for the aberrations of the microscope. + + :ref:`NXaperture_em`: + A base class to describe an aperture. + + :ref:`NXchamber`: + A base class to describe the chamber as a part of the microscope or storage unit for transferring specimens in-between or within an instrument. + + :ref:`NXcoordinate_system_set`: + A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. + + :ref:`NXcorrector_cs`: + A base class to describe details about corrective lens or compound lens devices which reduce the aberration of an electron beam. + + :ref:`NXebeam_column`: + A base class serving the possibility to group the components relevant for generating and shaping the electron beam in an electron microscope. + + :ref:`NXevent_data_em`: + A base class representing a container to hold time-stamped and microscope-state annotated data during a session at an electron microscope. + + :ref:`NXevent_data_em_set`: + A base class to group all `NXevent_data_em` instances. + + :ref:`NXibeam_column`: + A base class serving the possibility to group the components relevant for generating and shape an ion beam of an instrument with focused ion beam capabilities. + + :ref:`NXimage_set_em_adf`: + :ref:`NXimage_set_em_bf`: + :ref:`NXimage_set_em_bse`: + :ref:`NXimage_set_em_chamber`: + :ref:`NXimage_set_em_df`: + :ref:`NXimage_set_em_diffrac`: + :ref:`NXimage_set_em_ecci`: + :ref:`NXimage_set_em_kikuchi`: + :ref:`NXimage_set_em_ronchigram`: + :ref:`NXimage_set_em_se`: + Base classes for storing acquisition details for individual images or stacks images in different imaging modes. + Adf - annular dark field + Bf - bright filed + Bse - backscattered electron + Chamber - TV camera to monitor the stage and chamber (e. g. to assure that the specimen does not collides with components in the instrument) + Df - darkfield + Diffrac - diffraction image + Ecci - electron channel contrast imaging + Kikuchi - Kikuchi diffraction images for electron backscattered electron diffraction (EBSD) for orientation microscopy + Ronchigram - convergent beam diffraction pattern + Se - secondary electron + + :ref:`NXinteraction_volume_em`: + A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. + + :ref:`NXion`: + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. :ref:`NXlens_em`: A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. The idea of this base class is to use it in an application definition. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tool which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collect for a lens as a component so that developers of application definitions can take immediate advantage of this work. + :ref:`NXmanufacturer`: + A base class to bundle manufacturer/vendor-specific details about a component or device of an instrument. + + :ref:`NXoptical_system_em`: + A base class to store for now qualitative and quantitative values of frequent interest which are affected by the interplay of the components and state of an electron microscopy. + Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. + + :ref:`NXpeak`: + A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + + :ref:`NXpump`: + A base class to describe details about a pump in an instrument. + :ref:`NXscanbox_em`: A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. + :ref:`NXspectrum_set_em_auger`: + :ref:`NXspectrum_set_em_cathodolum`: + :ref:`NXspectrum_set_em_eels`: + :ref:`NXspectrum_set_em_xray`: + A base classes comparable to NXimage_set_em but for different techniques resulting in spectra like Auger spectroscopy, cathodoluminescence, electron energy loss spectroscopy and X-ray spectroscopy. + :ref:`NXstage_lab`: As it was mentioned for atom probe microscopy this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. + .. _EmNewCommonBC: New Common Base Classes ####################### -We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em`, :ref:`NXlens`, and :ref:`NXxraylens` have similarities. It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general base class lenses. +We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em`, :ref:`NXlens`, and :ref:`NXxraylens` have similarities. +It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general +base class lenses. We see understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. diff --git a/manual/source/fairmat-cover.rst b/manual/source/fairmat-cover.rst index 86a2199cf1..d4664d0001 100644 --- a/manual/source/fairmat-cover.rst +++ b/manual/source/fairmat-cover.rst @@ -14,87 +14,94 @@ FAIRmat-NeXus Proposal Aim ######################### -Experiments nowadays create a set of very often voluminous and diverse numerical data and metadata. -These pieces of information represent entities of what is effectively a graph of materials data. -This graph can have a very large number of nodes and of edges, which represent the large variety of -relations which scientists ideally want to identify and master +Experiments nowadays create a set of very often voluminous and diverse numerical data and metadata. +These pieces of information represent entities of what is effectively a graph of materials data. +This graph can have a very large number of nodes and edges representing the large variety of +relations which scientists ideally want to identify and master when transforming experimental research into knowledge. -Experimentalists face the challenge that these pieces of information come at different levels -of granularity and format, of which many need to be better documented. You have very likely experienced -yourself how file and data formats are routinely encountered tasks to master in your daily -research practice and you might have questioned how these formats are currently handled +Experimentalists face the challenge that these pieces of information come at different levels +of granularity and format, of which many need to be better documented. You have very likely experienced +yourself how file and data formats are routinely encountered tasks to master in your daily +research practice and you might have questioned how these formats are currently handled when you want to produce FAIR research data and publications. -The NeXus-FAIRmat proposal is an interdisciplinary data science activity initiated by scientists of the +The NeXus-FAIRmat proposal is an interdisciplinary data science activity initiated by scientists of the condensed-matter physics community which strives to develop community-maintained open file and data formats -for describing specific experimental techniques, their numerical data and metadata, +for describing specific experimental techniques, their numerical data and metadata, and strategies how to exchange these pieces of information. .. _IntroductionCover: The FAIRmat proposal to NeXus is an effort by the community of scientists of the `FAIRmat consortium `_ -to refine and expand the structure of NeXus. As a project which aims at creating an infrastructure -for experimental data to be findable, accessible, interoperable, and reusable (FAIR) in the fields of condensed-matter physics -and the chemical physics of solids, FAIRmat has adopted NeXus as the common format. +to refine and expand the structure of NeXus. As a project which aims at creating an infrastructure +for experimental data to be findable, accessible, interoperable, and reusable (FAIR) in the fields of +condensed-matter physics and the chemical physics of solids, FAIRmat has adopted NeXus as the common format. -`NeXus `_ is a common data exchange format which has its origin in the community of +`NeXus `_ is a common data exchange format which has its origin in the community of scientists performing neutron, x-ray, and muon experiments. The development of NeXus is coordinated by the NeXus International Advisory Committee (NIAC). -The format is built on top of the Hierarchical Data Format (HDF5) data model and format to which NeXus adds -domain-specific rules for organizing data within HDF5 files (:ref:`application.definitions`) and defining a -dictionary of well-defined domain-specific field names (:ref:`base.class.definitions`). -The meta- and numerical data in a NeXus file represent a hierarchical graph which encodes a specifically -granularized representation of relevant pieces of information and results that should be stored with an experiment. - -Base classes and application definitions are two key components of the NeXus data model. -A base class represents a set of numerical data and metadata which specify details about +NeXus defines a schema of data entries with a controlled vocabulary and defined relations between the entries. +NeXus offers not only tools to document these schema definitions in a version-controlled manner but +also tools to check and verify how and if specific instances of NeXus schemata comply with the intended +schema definition when the data are written to files. Although, the Hierarchical Data Format (HDF5) is the +most commonly used file format to write NeXus file to, NeXus can also be used with other file formats. + +NeXus defines domain-specific rules for organizing data in e.g. HDF5 files (:ref:`application.definitions`) +and defines a dictionary of well-defined domain-specific (a vocabulary) of terms (:ref:`base.class.definitions`). +The meta- and numerical data in a NeXus file represent a hierarchical graph which encodes a specifically +granularized representation of relevant pieces of information and results that should be stored with +an experiment. + +Base classes and application definitions are two key components of the NeXus data model. +A base class represents a set of numerical data and metadata which specify details about scientists, projects, instruments, and other physical devices, including the numerical data and metadata which are deemed relevant for their description and the associated -computational analyses. Application definitions are constructed from combining such experiment- +computational analyses. Application definitions are constructed from combining such experiment- and research-question-specifically customized base classes. In this combination, an application definition is a data contract between a producer and a consumer of these scientific data. +This design has sufficient flexibility to cover any experimental technique and instrumentation, while +ensuring rigorous, application-specific structures that can be processed in an automated manner. -This design has sufficient flexibility to cover any experimental technique and instrumentation, -while ensuring rigorous, application-specific structures that can be processed in an automated manner. +In cases where base classes or application definitions have not yet been proposed advantage of NeXus can be taken +if the respective scientific community explicitly designs, implements, uses, and continuously evolves +these classes and definitions. Here the role of the NIAC is to support the community with +data modeling and data science technical expertise, thus taking an important role of +cross-disciplinary review. -In cases where base classes or application definitions have not yet been proposed advantage of NeXus can be taken -if the respective scientific community explicitly designs, implements, uses, and continuously evolves -these classes and definitions. - -The NeXus-FAIRmat proposal represents the results of this development for experiments and use cases which have not yet used NeXus. +The NeXus-FAIRmat proposal represents the results of this development for experiments and use cases which have not yet used NeXus. Specifically, the proposal includes cases in the materials-science-branch of electron microscopy (EM), photo-emission spectroscopy, -ellipsometry, and the field of atom probe tomography and related field-ion, here jointly referred to as atom probe microscopy. +ellipsometry, and the field of atom probe tomography and related field-ion microscopy, here jointly referred to as atom probe microscopy. -The documentation available here includes part of the contents of the NeXus User Manual -(also available `here `_), reported here for the -convenience of the user, but is restricted to the parts most pertinent to our proposal. +The documentation available here includes parts of the contents of the NeXus User Manual (also available `here `_), +reported here for the convenience of the user, but is restricted to the parts most pertinent to the our proposal. -For more extensive information, please visit the original manual. +For more extensive information, please visit the original manual. .. _OurScope: Our scope and perspective ######################### -Thanks to a cooperative approach across a wide variety of experimental -techniques, the NeXus-FAIRmat proposal of the FAIRmat project has an opportunity -to expand the set of data/metadata accurately described via NeXus. +Thanks to a cooperative approach across a wide variety of experimental techniques, +the NeXus-FAIRmat proposal of the FAIRmat project has an opportunity +to expand the set of data/metadata accurately described via NeXus. With a closely-connected team of domain experts, we will develop such expansion while at the same time maintaining a consistent structure across different techniques and methods, striving for the maximum simplicity of use. Achieving a standardized and FAIR data structure has a wide spectrum of advantages, ranging from radical progress in scientific transparency to the development of new, far-reaching tools that can be shared across -the whole scientific community. The convenience of such tools can range from guaranteeing data reusability within a single lab, -to enabling open-source availability of ready-to-use advanced analysis software. Perhaps the greatest resource, however, -is the inclusion of experimental datasets in the `NOMAD Laboratory `_: -a data infrastructure that already hosts the largest computational material science repository in the world, -a homogeneous and machine-readable archive, a human-accessible encyclopedia of materials data +the whole scientific community. The convenience of such tools can range from guaranteeing data reusability within +a single lab, to enabling open-source availability of ready-to-use advanced analysis software. + +Perhaps the greatest resource, however, is the inclusion of experimental datasets in the `NOMAD Laboratory `_: +a data infrastructure that already hosts the largest computational material science repository in the world, representing a +homogeneous and machine-readable archive, a human-accessible encyclopedia of materials data with tools for automated artificial intelligence analyses and data access. .. _Outreach: @@ -102,17 +109,19 @@ with tools for automated artificial intelligence analyses and data access. Outreach to the community ########################## -A data infrastructure is not effective if it does not integrate seamlessly in the day-to-day workflow -of a laboratory. For this reason, we approach our newly developed NeXus proposal as a community-driven development. -We have drafted an accurate and consistent expansion of NeXus capabilities for a number of lab-based techniques, but need extensive -testing and tweaking of its characteristics by the community. +A data infrastructure is not effective if it does not integrate seamlessly in the day-to-day workflow of a laboratory. +For this reason, we approach our newly developed NeXus proposal as a community-driven development. +We have drafted an accurate and consistent expansion of NeXus capabilities for a number of lab-based techniques, +but need extensive testing and tweaking of its characteristics by the community. + +If your data is generated with these techniques and you are interested in producing FAIR data and accessing the FAIRmat tools, we +invite you to try out our proposed structure. If you find any conflicts or inconsistencies, please raise them to us using the +comment section. These comments are implemented with `Hypothesis `_, a modern web annotation +tool from the journalism community. The commenting function for each page of the proposal enable you to contribute to the +creation of a more consistent and practical NeXus structure which, in our firm belief, can serve your community and beyond. -If your data is generated with these techniques and you are interested in producing FAIR data and accessing the FAIRmat tools, -we invite you to try out our proposed structure. If you find any conflicts or inconsistencies, please raise them to us using the -comment section. Thereby, you will contribute to the creation of a more consistent and practical NeXus structure which, in our firm belief, -can serve your community and beyond. -If you do not find your specific experimental technique but would be interested in participating in the development -of a standard using NeXus, feel also very much invited to contact us directly at (?). +If you do not find your specific experimental technique but would be interested in participating in the development +of a standard using NeXus, feel also very much invited to contact us directly at the `FAIRmat-Team `_. .. _WhichData: @@ -171,14 +180,44 @@ for the following macro-areas of experimental physics .. Extended base classes: :ref:`Electron Microscopy `: - Set of data storage objects to describe electron microscopy experiments, follow the link for a more extensive description. + Set of data storage objects to describe electron microscopy experiments using an event-based paradigm, follow the link for a more extensive description. New application definitions: - :ref:`NXem_nion` + :ref:`NXem` + NXem substantially generalizes our earlier candidate proposal NXem_nion. + New base classes: + :ref:`NXaberration` + :ref:`NXaperture_em` + :ref:`NXchamber` + :ref:`NXcoordinate_system_set` :ref:`NXcorrector_cs` - :ref:`NXfib` + :ref:`NXdeflector` + :ref:`NXebeam_column` + :ref:`NXevent_data_em` + :ref:`NXevent_data_em_set` + :ref:`NXibeam_column` + :ref:`NXimage_set_em_adf` + :ref:`NXimage_set_em_bf` + :ref:`NXimage_set_em_bse` + :ref:`NXimage_set_em_chamber` + :ref:`NXimage_set_em_df` + :ref:`NXimage_set_em_diffrac` + :ref:`NXimage_set_em_ecci` + :ref:`NXimage_set_em_kikuchi` + :ref:`NXimage_set_em_ronchigram` + :ref:`NXimage_set_em_se` + :ref:`NXinteraction_volume_em` + :ref:`NXion` :ref:`NXlens_em` + :ref:`NXmanufacturer` + :ref:`NXoptical_system_em + :ref:`NXpeak` + :ref:`NXpump` :ref:`NXscanbox_em` + :ref:`NXspectrum_set_em_auger` + :ref:`NXspectrum_set_em_cathodolum` + :ref:`NXspectrum_set_em_eels` + :ref:`NXspectrum_set_em_xray` :ref:`NXstage_lab` .. Extended base classes: @@ -187,10 +226,14 @@ for the following macro-areas of experimental physics New application definitions: :ref:`NXapm` New base classes: + :ref:`NXchamber` + :ref:`NXcoordinate_system_set` :ref:`NXion` - :ref:`NXlens_apm` + :ref:`NXmanufacturer` :ref:`NXpeak` + :ref:`NXpump` :ref:`NXpulser_apm` + :ref:`NXreflectron :ref:`NXstage_lab` .. Extended base classes: From b8288fe760d0b9730a65f41975fc9a4e5401ac87 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Thu, 7 Jul 2022 20:50:20 +0200 Subject: [PATCH 033/203] Updated mainpage proposal --- manual/source/fairmat-cover.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/manual/source/fairmat-cover.rst b/manual/source/fairmat-cover.rst index d4664d0001..1c1536fa5d 100644 --- a/manual/source/fairmat-cover.rst +++ b/manual/source/fairmat-cover.rst @@ -191,7 +191,6 @@ for the following macro-areas of experimental physics :ref:`NXchamber` :ref:`NXcoordinate_system_set` :ref:`NXcorrector_cs` - :ref:`NXdeflector` :ref:`NXebeam_column` :ref:`NXevent_data_em` :ref:`NXevent_data_em_set` From 2b326acd179b2c1b783ada7fef1488a45cdfb394 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Mon, 11 Jul 2022 12:22:09 +0200 Subject: [PATCH 034/203] Reference to deprecated EM classes, and added template for IVtemp curves appdef --- manual/source/em-structure.rst | 15 ++++++++++++ manual/source/epics-structure.rst | 40 +++++++++++++++++++++++++++++++ manual/source/index.rst | 1 + 3 files changed, 56 insertions(+) create mode 100644 manual/source/epics-structure.rst diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 9f2185e095..60aa7ae3d7 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -9,6 +9,7 @@ Electron Microscopy Structure EmNewAppDef EmNewBC EmNewCommonBC + EmDeprecated @@ -133,3 +134,17 @@ New Common Base Classes We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em`, :ref:`NXlens`, and :ref:`NXxraylens` have similarities. It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general base class lenses. We see understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. + + +.. _EmDeprecated: + +Deprecated +########## + +With the results of the NeXus 2022.06 Code Camp the following base classes and application definitions are considered deprecated. +Their functionalities has been extended and is replaced specifically as follows: + + :ref:`NXem_nion`: + An application definition specific for Nion (transmission) electron microscopes. This is replaced by the substantially more general :ref:`NXem` application definition. + :ref:`NXfib`: + A base class to describe focused-ion beam capabilities of an (electron) microscope. The base class is replaced by :ref:`NXibeam_column`. \ No newline at end of file diff --git a/manual/source/epics-structure.rst b/manual/source/epics-structure.rst new file mode 100644 index 0000000000..5403123e76 --- /dev/null +++ b/manual/source/epics-structure.rst @@ -0,0 +1,40 @@ +.. _Epics-Structure: + +================================== +EPICS Structure +================================== + +.. index:: + IntroductionEpics + EpicsNewAppDef + EpicsNewBC + EpicsNewCommonBC + + +.. _IntroductionEpics: + +Introduction +############## + + +.. _EpicsNewAppDef: + +New Application Definitions +############################ + +Work on handshaking between EPICS-controlled experiments and NeXus resulted in one application definition for temperature dependent IV curve measurements. + + :ref:`NXIVtemp`: + Application definition for temperature dependent IV curve measurements. + +.. _EpicsNewBC: + +New Base Classes +################# + + +.. _EpicsNewCommonBC: + +New Common Base Classes +####################### + diff --git a/manual/source/index.rst b/manual/source/index.rst index 69cadf996b..7a7ba06426 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -15,6 +15,7 @@ https://www.nexusformat.org/ ellipsometry-structure em-structure apm-structure + epics-structure ----------- From 4469fe482705442112ded00f2b2dbfce2588062e Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Mon, 11 Jul 2022 17:27:40 +0200 Subject: [PATCH 035/203] Fixed dimensions index nx, ny issue in contributed/NXbeam, and edited NXIVtemp to enable addition of EPICS to proposal and recompile nexus-fairmat-proposal --- contributed_definitions/NXIVtemp.nxdl.xml | 189 --------- contributed_definitions/NXbeam.nxdl.xml | 3 +- contributed_definitions/NXiv_temp.nxdl.xml | 386 ++++++++++++++++++ manual/source/classes/applications/index.rst | 22 +- manual/source/classes/base_classes/index.rst | 82 +--- .../classes/contributed_definitions/index.rst | 246 ++++++++++- manual/source/em-structure.rst | 4 +- manual/source/epics-structure.rst | 2 +- manual/source/fairmat-cover.rst | 8 +- manual/source/sed/landing-page.rst | 1 + 10 files changed, 641 insertions(+), 302 deletions(-) delete mode 100644 contributed_definitions/NXIVtemp.nxdl.xml create mode 100644 contributed_definitions/NXiv_temp.nxdl.xml diff --git a/contributed_definitions/NXIVtemp.nxdl.xml b/contributed_definitions/NXIVtemp.nxdl.xml deleted file mode 100644 index b67a4cc436..0000000000 --- a/contributed_definitions/NXIVtemp.nxdl.xml +++ /dev/null @@ -1,189 +0,0 @@ - - - - Draft application definition for temperature dependent IV curve measurements. In this application definition, times should be specified always together with a UTC offset. - - Variables used throughout the document, e.g. dimensions and important parameters - - Number of elements in the scanned voltage array - - - Number of additional variables that are changed with the temperature (can be understood as columns next to the temperature) - - - Number of different temperatures that are set - - - - This is the application definition describing temperature dependent IV curve measurements. For this a temperature is set. After reaching the temperature a voltage sweep is performed and for each voltage a current is measured. Then the next desired temperature is set and an IV measurement is performed. - -The application definition defines: - elements of the experimental instrument - calibration information if available - parameters used to tune the state of the sample - sample description - - An application definition for temperature dependent IV curve measurements. - - Version number to identify which definition of this application definition was used for this entry/data. - - - URL where to find further material (documentation, examples) relevant to the application definition - - - - Unique identifier of the experiment, such as a (globally persistent) unique identifier. - The identifier is usually defined by the facility or principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - Description of the exact experiment performed. - - - UTC offset should be specifiec. - - - Define the program that was used to generate the results file(s) with measured data and metadata. - - Commercial or otherwise defined given name of the program (or a link to the instrument software). - - - Either version with build number, commit hash, or description of a (online) repository where the source code of the program and build instructions can be found so that the program can be configured in such a way that result files can be created ideally in a deterministic manner. - - - Website of the software. - - - - Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. - - Name of the user. - - - Name of the affiliation of the user at the point in time when the experiment was performed. - - - Full address (street, street number, ZIP, city, country) of the user's affiliation. - - - Email address of the user. - - - Author ID defined by https://orcid.org/. - - - Official telephone number of the user. - - - - General properties of the temperature dependent IV curve measurements equipment - - Specify the used voltage source used in the voltage sweep for the IV measurement. - - Free-text desribing the model and make of the voltage source which is used for the IV sweep measurement - - - Custom name of the voltage source for the IV sweep given by the user/institution - - - Free-text describing the measurement performed in a few words - - - Free-text describing the type of voltage setting: an internal sweep using the functionality of the voltage supply, or a set/wait/read/repeat mechanism. - - - - Specify the used current source used in the voltage sweep for the IV measurement. - - Free-text desribing the model and make of the current source which is used for the IV sweep measurement - - - Custom name of the current source for the IV sweep given by the user/institution - - - Free-text describing the measurement performed in a few words - - - Free-text describing the type of current measuring: an internal sweep using the functionality of the voltage supply, or a set/wait/read/repeat mechanism. - - - - Calibration of the temperature sensor is possible - - ISO8601 datum when calibration was last performed before this measurement. UTC offset should be specifiec. - - - - Describes the system for controlling the temperature if temperature control was used. - - What kind of temperature control was used? PID, custom temp control? - - - Specify the settings of the PID temperature controller: K_p, K_i, and K_d values used for the temperature control - - 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 contribution from the integral term is proportional to both the magnitude of the error and the duration of the error. The integral in a PID controller is the sum of the instantaneous error over time and gives the accumulated offset that should have been corrected previously. The accumulated error is then multiplied by the integral gain (Ki) and added to the controller output - - - The derivative of the process error is calculated by determining the slope of the error over time and multiplying this rate of change by the derivative gain K_d. The magnitude of the contribution of the derivative term to the overall control action is termed the derivative gain, K_d - - - - Specify the temperature sensor that was used - - - - - - - - - If you specified 'other' as temperature sensor, please write down what it is. - - - - - - Data of the most principal measurement of the temperature. For example resistance of a Pt1000. - - - Algebraic function that is used to determine temperature from the raw_temp_data. All values should be given in SI units. - - - - - Properties of the sample, its history, the sample environment and experimental conditions (e.g. surrounding medium, temperature, pressure etc.), along with the data (data type, wavelength array, measured data). - - Descriptive name of the sample - - - Ideally, a reference to the location or a unique (globally persistent) identifier (e.g.) of e.g. another file which gives as many as possible details of the material, its microstructure. In the case that such a detailed history of the sample is not available, use this field as a free-text description to specify details of the sample and its preparation. - - - ISO 8601 date with time zone specified. UTC offset should be specifiec. - - - An identifier to correlate data to the experimental conditions, if several were used in this measurement; typically an index of 0 - N - - - Resulting data from the measurement, described by data type. - - - - - - - - Information about external parameters that have influenced the sample. - - - Indicates which parameter was changed. Its definition must exist below. The specified variable has to be number_of_runs long, providing the parameters for each data set. - - - - - - - A default view of the data. The current (y-axis) should be plotted against the voltage (x-axis) with color coding for the temperature of each IV-curve - - We recommend to use voltage as a default attribute - - - - diff --git a/contributed_definitions/NXbeam.nxdl.xml b/contributed_definitions/NXbeam.nxdl.xml index dac93f7faf..ffbe10b857 100644 --- a/contributed_definitions/NXbeam.nxdl.xml +++ b/contributed_definitions/NXbeam.nxdl.xml @@ -233,7 +233,8 @@ FROG trace of the pulse. - + + diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml new file mode 100644 index 0000000000..5122b71e1a --- /dev/null +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -0,0 +1,386 @@ + + + + + + Variables used throughout the document, e.g. dimensions and important + parameters + + + + Number of elements in the scanned voltage array + + + + + Number of additional variables that are changed with the temperature + (can be understood as columns next to the temperature) + + + + + Number of different temperatures that are set + + + + + Application definition for temperature-dependent IV curve measurements. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature dependent IV curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + The application definition defines: + - elements of the experimental instrument + - calibration information if available + - parameters used to tune the state of the sample + - sample description + + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + URL where to find further material (documentation, examples) + relevant to the application definition + + + + + + Unique identifier of the experiment, such as a (globally persistent) + unique identifier. The identifier is usually defined by the + facility or principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Description of the exact experiment performed. + + + + + UTC offset should be specifiec. + + + + + Define the program that was used to generate the results file(s) + with measured data and metadata. + + + + Commercial or otherwise defined given name of the program + (or a link to the instrument software). + + + + Either version with build number, commit hash, or description of an + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when + the experiment was performed. + + + + + Full address (street, street number, ZIP, city, country) + of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + Official telephone number of the user. + + + + + + General properties of the temperature dependent IV curve + measurements equipment + + + + Specify the used voltage source used in the voltage + sweep for the IV measurement. + + + + Free-text desribing the model and make of the voltage source + which is used for the IV sweep measurement. + + + + + Custom name of the voltage source for the IV sweep given + by the user/institution. + + + + + Free-text describing the measurement performed in a few words. + + + + + Free-text describing the type of voltage setting: an internal sweep + using the functionality of the voltage supply, or a + set/wait/read/repeat mechanism. + + + + + + Specify the used current source used in the voltage sweep + for the IV measurement." + + + + Free-text desribing the model and make of the current source + which is used for the IV sweep measurement. + + + + + Custom name of the current source for the IV sweep given + by the user/institution + + + + + Free-text describing the measurement performed in a few words + + + + + Free-text describing the type of current measuring: an internal + sweep using the functionality of the voltage supply, + or a set/wait/read/repeat mechanism. + + + + + + Calibration of the temperature sensor is possible + + + + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. + + + + + + Describes the system for controlling the temperature + if temperature control was used. + + + + What kind of temperature control was used? + PID, custom temp control? + + + + + Specify the settings of the PID temperature controller: + K_p, K_i, and K_d values used for the temperature control + + + + 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 contribution from the integral term is proportional to both + the magnitude of the error and the duration of the error. + The integral in a PID controller is the sum of the instantaneous + error over time and gives the accumulated offset that should have + been corrected previously. The accumulated error is then + multiplied by the integral gain (Ki) and added to the + controller output. + + + + + The derivative of the process error is calculated by determining + the slope of the error over time and multiplying this rate of + change by the derivative gain K_d. The magnitude of the + contribution of the derivative term to the overall control + action is termed the derivative gain, K_d + + + + + + Specify the temperature sensor that was used + + + + + + + + + + + If you specified 'other' as temperature sensor, + please write down what it is. + + + + + Data of the most principal measurement of the temperature. + For example resistance of a Pt1000. + + + + + + + + Algebraic function that is used to determine temperature from the + raw_temp_data. All values should be given in SI units. + + + + + + + Properties of the sample, its history, the sample environment and + experimental conditions (e.g. surrounding medium, temperature, + pressure etc.), along with the data (data type, wavelength array, + measured data). + + + + Descriptive name of the sample + + + + + Ideally, a reference to the location or a unique (globally persistent) + identifier (e.g.) of e.g. another file which gives as many as possible + details of the material, its microstructure. In the case that such a + detailed history of the sample is not available, use this field as a + free-text description to specify details of the sample and its + preparation. + + + + + ISO 8601 date with time zone specified. UTC offset should be specified. + + + + + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0 - N + + + + + Resulting data from the measurement, described by data type. + + + + + + + + + + Information about external parameters that have influenced the sample. + + + + + Indicates which parameter was changed. Its definition must exist below. + The specified variable has to be number_of_runs long, + providing the parameters for each data set. + + + + + + + + + A default view of the data. The current (y-axis) should be plotted + against the voltage (x-axis) with color coding for the temperature + of each IV-curve. + + + + Array of voltage values on the independent axis supporting the curve. + + + + + + + + Array of current values on the dependent axis of the curve. + + + + + IV curve. + + + + + diff --git a/manual/source/classes/applications/index.rst b/manual/source/classes/applications/index.rst index ec1cdad251..2818863833 100644 --- a/manual/source/classes/applications/index.rst +++ b/manual/source/classes/applications/index.rst @@ -1,6 +1,6 @@ .. do NOT edit this file - automatically generated by script /home/mkuehbach/XXXX/nexus_definitions/manual/source/classes/applications/../../../../utils/nxdl_summary.py + automatically generated by script /home/mkuehbach/SPRINT-8/update_nexus_fairmat_proposal/nexus_definitions/manual/source/classes/applications/../../../../utils/nxdl_summary.py .. index:: @@ -30,9 +30,6 @@ write the raw data in the :ref:`NXinstrument` tree and then link to it from the location(s) defined in the relevant application definition. -:ref:`NXapm` - Draft application definition for atom probe tomography and related field-ion microscopy, all summarized as atom probe microscopy experiments. - :ref:`NXarchive` This is a definition for data to be archived by ICAT (http://www.icatproject.org/). @@ -45,12 +42,6 @@ from the location(s) defined in the relevant application definition. :ref:`NXdirecttof` This is a application definition for raw data from a direct geometry TOF spectrometer -:ref:`NXellipsometry` - Draft application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. In this application definition, times should be specified always together with a UTC offset. - -:ref:`NXem_nion` - Template for creating draft application definitions for storing data and metadata for experiments with scanning transmission electron microscopy with a Nion instrument. - :ref:`NXfluo` This is an application definition for raw data from an X-ray fluorescence experiment @@ -66,12 +57,6 @@ from the location(s) defined in the relevant application definition. :ref:`NXmonopd` Monochromatic Neutron and X-Ray Powder diffractometer -:ref:`NXmpes` - This is the most general application definition for multidimensional photoelectron spectroscopy. - -:ref:`NXmpes_ARPES` - This is the most general application definition for multidimensional ARPES. - :ref:`NXmx` functional application definition for macromolecular crystallography @@ -150,20 +135,15 @@ from the location(s) defined in the relevant application definition. .. toctree:: :hidden: - NXapm NXarchive NXarpes NXcanSAS NXdirecttof - NXellipsometry - NXem_nion NXfluo NXindirecttof NXiqproc NXlauetof NXmonopd - NXmpes - NXmpes_ARPES NXmx NXrefscan NXreftof diff --git a/manual/source/classes/base_classes/index.rst b/manual/source/classes/base_classes/index.rst index 91436712a7..5dbcbfa4f8 100644 --- a/manual/source/classes/base_classes/index.rst +++ b/manual/source/classes/base_classes/index.rst @@ -1,6 +1,6 @@ .. do NOT edit this file - automatically generated by script /home/mkuehbach/XXXX/nexus_definitions/manual/source/classes/base_classes/../../../../utils/nxdl_summary.py + automatically generated by script /home/mkuehbach/SPRINT-8/update_nexus_fairmat_proposal/nexus_definitions/manual/source/classes/base_classes/../../../../utils/nxdl_summary.py .. index:: @@ -20,7 +20,7 @@ that are used to construct a data file. :ref:`NXaperture` - A beamline aperture. + A beamline aperture. This group is deprecated, use NXslit instead. :ref:`NXattenuator` A device that reduces the intensity of a beam by attenuation. @@ -34,9 +34,6 @@ that are used to construct a data file. :ref:`NXbending_magnet` A bending magnet -:ref:`NXcalibration` - Draft subclass of NXprocess to describe post-processing calibrations. - :ref:`NXcapillary` A capillary lens to focus the X-ray beam. @@ -46,15 +43,9 @@ that are used to construct a data file. :ref:`NXcollection` An unvalidated set of terms, such as the description of a beam line. -:ref:`NXcollectioncolumn` - Draft subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. - :ref:`NXcollimator` A beamline collimator. -:ref:`NXcorrector_cs` - Draft of a base class for a device in a (transmission) electron microscope which corrects for spherical aberrations. The device consists of multiple NXlens_em instances and other components. - :ref:`NXcrystal` A crystal monochromator or analyzer. @@ -64,9 +55,6 @@ that are used to construct a data file. :ref:`NXdata` :ref:`NXdata` describes the plottable data and related dimension scales. -:ref:`NXdeflector` - Draft class definition for electro-static deflectors as they are used e.g. in an electron analyser. - :ref:`NXdetector` A detector, detector bank, or multidetector. @@ -79,17 +67,8 @@ that are used to construct a data file. :ref:`NXdisk_chopper` A device blocking the beam in a temporal periodic pattern. -:ref:`NXdistortion` - Draft subclass of NXprocess to describe post-processing distortion correction. - -:ref:`NXelectronanalyser` - Draft subclass of NXinstrument to describe a photoelectron analyser. - -:ref:`NXenergydispersion` - Draft subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. - :ref:`NXentry` - (**required**) :ref:`NXentry` describes the measurement. + (**required**) :ref:`NXentry` describes the measurement. :ref:`NXenvironment` Parameters for controlling external conditions @@ -100,9 +79,6 @@ that are used to construct a data file. :ref:`NXfermi_chopper` A Fermi chopper, possibly with curved slits. -:ref:`NXfib` - Draft of a base class for describing focused-ion beam capabilities of an instrument. The class is designed to be used as an additional component of e.g. an electron microscope to describe sample/specimen preparation and the collecting of data and metadata for (scanning) electron microscope/focused-ion beam, (S)EM/FIB instruments. - :ref:`NXfilter` For band pass beam filters. @@ -127,24 +103,9 @@ that are used to construct a data file. :ref:`NXinstrument` Collection of the components of the instrument or beamline. -:ref:`NXion` - Atomic architecture of a (molecular) ion (fragment) which can be used for example to label charged molecule ions identified from mass-to-charge histogram data as appearing as signal in e.g. time-resolved mass spectrometry techniques like atom probe or secondary ion mass spectrometry. - -:ref:`NXlens` - Draft class definition for electro-static lenses as they are used e.g. in an electron analyser. - -:ref:`NXlens_apm` - Draft class definition for a component of an atom probe instrument which details an eventually available reflectron device whose purpose is to deflect the flight paths of the ions to realize what is effectively an energy compensation. - -:ref:`NXlens_em` - Draft base class definition for electro-magnetic lenses as they are used e.g. in an electron microscope or reflectron device in a local electrode atom probe microscope. - :ref:`NXlog` Information recorded as a function of time. -:ref:`NXmanipulator` - Draft extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. - :ref:`NXmirror` A beamline mirror or supermirror. @@ -175,9 +136,6 @@ that are used to construct a data file. :ref:`NXpdb` A NeXus transliteration of a PDB file, to be validated only as a PDB -:ref:`NXpeak` - Proposal for storing mathematical models of peaks, their functional form or at least their measured support. - :ref:`NXpinhole` A simple pinhole. @@ -190,15 +148,9 @@ that are used to construct a data file. :ref:`NXprocess` Document an event of data processing, reconstruction, or analysis for this data. -:ref:`NXpulser_apm` - Draft for a class which can be used for representing a coarse-grained description of all those components of an atom probe microscope which realize the pulsing capabilities, whether it be for the laser or the high-voltage pulser, which trigger the removal of ions (atom probe tomography) or the excitation of gas ions (field-ion microscopy). - :ref:`NXreflections` Reflection data from diffraction experiments -:ref:`NXregistration` - Draft extension of NXobject to include fields to describe image registration procedures. - :ref:`NXroot` Definition of the root NeXus group. @@ -208,9 +160,6 @@ that are used to construct a data file. :ref:`NXsample_component` One group like this per component can be recorded For a sample consisting of multiple components. -:ref:`NXscanbox_em` - Description of the scan box which is instructed by the microscope control software to direct the probe to controlled locations according to a scan scheme and plan. - :ref:`NXsensor` A sensor used to monitor an external condition @@ -223,12 +172,6 @@ that are used to construct a data file. :ref:`NXsource` The neutron or x-ray storage ring/facility. -:ref:`NXspindispersion` - Draft subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. - -:ref:`NXstage_lab` - Candidate class for a component or a set of components which is coarse-grained into one logical unit. The role of the stage in an experiment is to hold/align/orient the sample/specimen and eventually offer a controlled environment and further devices to apply stimuli. Having an own candidate class is justified as contemporary specimen/sample stages are such multi-purpose/-functional tools with multiple actuators, sensors, components, and thus also the need to store the various (meta)data that are generated with manipulating the sample. Modern stages realize a hierarchy of components for achieving these tasks. For example the specimen might be mounted on a multi-axial tilt rotation holders which itself is fixed in the support unit that connects to the microscope. In other examples, taken from atom probe microscopy for instance, researchers may work with wire samples which are clipped into a larger fixing unit for convenience. This unit is known in atom probe jargon as a stub. Stubs in turn are positioned on pucks. Pucks are then loaded onto carousels. This NXstage class reflects two layers of this hierarchy. 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. Applied to examples, a nanoparticle is attached on a copper grid. The copper grid is the holder. The grid itself is fixed to the stage. An atom probe specimen is fixed in a stub, in this case the stub can be considered as the holder, while the cryostat temperature control unit reads more as the stage. A microtip on a microtip array is an example of a three-layer hierarchy commonly employed for efficient sequential processing of atom probe experiments. For a single experiment though only one microtip of the array at a time can be measured. Therefore, the microtip is the specimen, the array the holder and the remaining mounting unit that is attached to the cryo-controller the stage. To cover for an as flexible design of these complex lab-like modern stages users should nest NXstage_lab objects for reflect the differences between e.g. a holder and a stage. - :ref:`NXsubentry` Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. @@ -255,29 +198,21 @@ that are used to construct a data file. NXbeam NXbeam_stop NXbending_magnet - NXcalibration NXcapillary NXcite NXcollection - NXcollectioncolumn NXcollimator - NXcorrector_cs NXcrystal NXcylindrical_geometry NXdata - NXdeflector NXdetector NXdetector_group NXdetector_module NXdisk_chopper - NXdistortion - NXelectronanalyser - NXenergydispersion NXentry NXenvironment NXevent_data NXfermi_chopper - NXfib NXfilter NXflipper NXfresnel_zone_plate @@ -286,12 +221,7 @@ that are used to construct a data file. NXguide NXinsertion_device NXinstrument - NXion - NXlens - NXlens_apm - NXlens_em NXlog - NXmanipulator NXmirror NXmoderator NXmonitor @@ -302,24 +232,18 @@ that are used to construct a data file. NXorientation NXparameters NXpdb - NXpeak NXpinhole NXpolarizer NXpositioner NXprocess - NXpulser_apm NXreflections - NXregistration NXroot NXsample NXsample_component - NXscanbox_em NXsensor NXshape NXslit NXsource - NXspindispersion - NXstage_lab NXsubentry NXtransformations NXtranslation diff --git a/manual/source/classes/contributed_definitions/index.rst b/manual/source/classes/contributed_definitions/index.rst index ee98bcac65..9307f44c8b 100644 --- a/manual/source/classes/contributed_definitions/index.rst +++ b/manual/source/classes/contributed_definitions/index.rst @@ -1,6 +1,6 @@ .. do NOT edit this file - automatically generated by script /home/mkuehbach/XXXX/nexus_definitions/manual/source/classes/contributed_definitions/../../../../utils/nxdl_summary.py + automatically generated by script /home/mkuehbach/SPRINT-8/update_nexus_fairmat_proposal/nexus_definitions/manual/source/classes/contributed_definitions/../../../../utils/nxdl_summary.py .. index:: @@ -22,27 +22,183 @@ definitions and provide feedback to the authors before ratification and acceptance as either a base class or application definition. +:ref:`NXaberration` + Models for aberrations of electro-magnetic lenses in electron microscopy. + +:ref:`NXaperture` + A beamline aperture + +:ref:`NXaperture_em` + Details of an individual aperture for electron beams. + +:ref:`NXapm` + Application definition for atom probe microscopy experiments. + +:ref:`NXbeam` + Properties of the neutron or X-ray beam at a given location. + +:ref:`NXcalibration` + Subclass of NXprocess to describe post-processing calibrations. + +:ref:`NXchamber` + Component of an instrument to store or place objects and specimens. + +:ref:`NXcollectioncolumn` + Subclass of NXelectronanalyser to describe the electron collection column of a + :ref:`NXcontainer` State of a container holding the sample under investigation. +:ref:`NXcoordinate_system_set` + Container to hold different coordinate systems conventions. + +:ref:`NXcorrector_cs` + Corrector for aberrations in an electron microscope. + :ref:`NXcsg` - constructive solid geometry NeXus class, using :ref:`NXquadric` + Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` :ref:`NXcxi_ptycho` Application definition for a ptychography experiment, compatible with CXI from version 1.6. +:ref:`NXdeflector` + Deflectors as they are used e.g. in an electron analyser. + +:ref:`NXdetector` + A detector, detector bank, or multidetector. + +:ref:`NXdistortion` + Subclass of NXprocess to describe post-processing distortion correction. + +:ref:`NXebeam_column` + Container for components to form a controlled electron beam. + +:ref:`NXelectronanalyser` + Subclass of NXinstrument to describe a photoelectron analyser. + :ref:`NXelectrostatic_kicker` definition for a electrostatic kicker. +:ref:`NXellipsometry` + Ellipsometry, complex systems, up to variable angle spectroscopy. + +:ref:`NXem` + Characterization and session with one sample in an electron microscope. + +:ref:`NXem_nion` + (Scanning) transmission electron microscopy with a Nion instrument. + +:ref:`NXenergydispersion` + Subclass of NXelectronanalyser to describe the energy dispersion section of a + +:ref:`NXentry` + (**required**) :ref:`NXentry` describes the measurement. + +:ref:`NXevent_data_em` + Metadata and settings of an electron microscope for scans and images. + +:ref:`NXevent_data_em_set` + Container to hold NXevent_data_em instances of an electron microscope session. + +:ref:`NXfib` + Set of devices adding focused-ion beam capabilities to an instrument. + +:ref:`NXibeam_column` + Container for components of a focused-ion-beam (FIB) system. + +:ref:`NXimage_set_em_adf` + Container for reporting a set of annular dark field images. + +:ref:`NXimage_set_em_bf` + Container for reporting a set of images taken in bright field mode. + +:ref:`NXimage_set_em_bse` + Container for reporting a set of back-scattered electron images. + +:ref:`NXimage_set_em_chamber` + Container for images recorded with e.g. a TV camera in the microscope chamber. + +:ref:`NXimage_set_em_df` + Container for reporting a set of images taken in dark field mode. + +:ref:`NXimage_set_em_diffrac` + Container for reporting a set of diffraction images. + +:ref:`NXimage_set_em_ecci` + Container for reporting back-scattered electron channeling contrast images. + +:ref:`NXimage_set_em_kikuchi` + Electron backscatter diffraction (EBSD) Kikuchi pattern. + +:ref:`NXimage_set_em_ronchigram` + Container for reporting a set of images related to a ronchigram. + +:ref:`NXimage_set_em_se` + Container for reporting a set of secondary electron images. + +:ref:`NXinstrument` + Collection of the components of the instrument or beamline. Template of + +:ref:`NXinteraction_vol_em` + Base class for storing details about a modelled shape of interaction volume. + +:ref:`NXion` + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + +:ref:`NXiv_temp` + Application definition for temperature-dependent IV curve measurements. + +:ref:`NXlens_em` + Description of an electro-magnetic lens or a compound lens. + :ref:`NXmagnetic_kicker` definition for a magnetic kicker. +:ref:`NXmanipulator` + Extension of NXpositioner to include fields to describe the use of manipulators + +:ref:`NXmanufacturer` + Details about a component as defined by its manufacturer. + +:ref:`NXmpes` + This is the most general application definition for multidimensional + +:ref:`NXoptical_system_em` + A container for qualifying an electron optical system. + +:ref:`NXpeak` + Description of peaks, their functional form or measured support. + +:ref:`NXprocess` + Document an event of data processing, reconstruction, or analysis for this data. + +:ref:`NXpulser_apm` + Metadata for laser-, voltage-, or combined pulsing triggering field evaporation. + +:ref:`NXpump` + Device to reduce an atmosphere to a controlled remaining pressure level. + :ref:`NXquadric` definition of a quadric surface. :ref:`NXquadrupole_magnet` definition for a quadrupole magnet. +:ref:`NXreflectron` + Device for reducing flight time differences of ions in ToF experiments. + +:ref:`NXregion` + Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. + +:ref:`NXregistration` + Describes image registration procedures. + +:ref:`NXsample` + Any information on the sample. + +:ref:`NXscanbox_em` + Scan box and coils which deflect an electron beam in a controlled manner. + :ref:`NXseparator` definition for an electrostatic separator. @@ -58,26 +214,106 @@ and acceptance as either a base class or application definition. :ref:`NXsolid_geometry` the head node for constructively defined geometry -:ref:`NXspecdata` - DEPRECATED: This definition will be removed by 2022. Not for new use. +:ref:`NXsource` + The neutron or x-ray storage ring/facility. + +:ref:`NXspectrum_set_em_auger` + Container for reporting a set of auger electron energy spectra. + +:ref:`NXspectrum_set_em_cathodolum` + Container for reporting a set of cathodoluminescence spectra. + +:ref:`NXspectrum_set_em_eels` + Container for reporting a set of electron energy loss spectra. + +:ref:`NXspectrum_set_em_xray` + Container for reporting a set of energy-dispersive X-ray spectra. :ref:`NXspin_rotator` definition for a spin rotator. +:ref:`NXspindispersion` + Subclass of NXelectronanalyser to describe the spin filters in photoemission + +:ref:`NXstage_lab` + A stage lab can be used to hold, align, orient, and prepare a specimen. + +:ref:`NXxpcs` + X-ray Photon Correlation Spectroscopy (XPCS) data (results). + .. toctree:: :hidden: + NXaberration + NXaperture + NXaperture_em + NXapm + NXbeam + NXcalibration + NXchamber + NXcollectioncolumn NXcontainer + NXcoordinate_system_set + NXcorrector_cs NXcsg NXcxi_ptycho + NXdeflector + NXdetector + NXdistortion + NXebeam_column + NXelectronanalyser NXelectrostatic_kicker + NXellipsometry + NXem + NXem_nion + NXenergydispersion + NXentry + NXevent_data_em + NXevent_data_em_set + NXfib + NXibeam_column + NXimage_set_em_adf + NXimage_set_em_bf + NXimage_set_em_bse + NXimage_set_em_chamber + NXimage_set_em_df + NXimage_set_em_diffrac + NXimage_set_em_ecci + NXimage_set_em_kikuchi + NXimage_set_em_ronchigram + NXimage_set_em_se + NXinstrument + NXinteraction_vol_em + NXion + NXiv_temp + NXlens_em NXmagnetic_kicker + NXmanipulator + NXmanufacturer + NXmpes + NXoptical_system_em + NXpeak + NXprocess + NXpulser_apm + NXpump NXquadric NXquadrupole_magnet + NXreflectron + NXregion + NXregistration + NXsample + NXscanbox_em NXseparator NXsnsevent NXsnshisto NXsolenoid_magnet NXsolid_geometry - NXspecdata + NXsource + NXspectrum_set_em_auger + NXspectrum_set_em_cathodolum + NXspectrum_set_em_eels + NXspectrum_set_em_xray NXspin_rotator + NXspindispersion + NXstage_lab + NXxpcs diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 60aa7ae3d7..469d5b36fe 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -91,7 +91,7 @@ We developed entirely new base classes. Some of them are also used for other tec Ronchigram - convergent beam diffraction pattern Se - secondary electron - :ref:`NXinteraction_volume_em`: + :ref:`NXinteraction_vol_em`: A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. :ref:`NXion`: @@ -131,7 +131,7 @@ We developed entirely new base classes. Some of them are also used for other tec New Common Base Classes ####################### -We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em`, :ref:`NXlens`, and :ref:`NXxraylens` have similarities. +We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em` and :ref:`NXxraylens` have similarities. It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general base class lenses. We see understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. diff --git a/manual/source/epics-structure.rst b/manual/source/epics-structure.rst index 5403123e76..1323d4320b 100644 --- a/manual/source/epics-structure.rst +++ b/manual/source/epics-structure.rst @@ -24,7 +24,7 @@ New Application Definitions Work on handshaking between EPICS-controlled experiments and NeXus resulted in one application definition for temperature dependent IV curve measurements. - :ref:`NXIVtemp`: + :ref:`NXiv_temp`: Application definition for temperature dependent IV curve measurements. .. _EpicsNewBC: diff --git a/manual/source/fairmat-cover.rst b/manual/source/fairmat-cover.rst index 1c1536fa5d..42ff35491b 100644 --- a/manual/source/fairmat-cover.rst +++ b/manual/source/fairmat-cover.rst @@ -162,7 +162,7 @@ for the following macro-areas of experimental physics :ref:`NXdistortion` :ref:`NXregistration` :ref:`NXlens` - :ref:`NXdeflector` + :ref:`NXdeflector` Extended base classes: :ref:`NXaperture` :ref:`NXbeam` @@ -205,11 +205,11 @@ for the following macro-areas of experimental physics :ref:`NXimage_set_em_kikuchi` :ref:`NXimage_set_em_ronchigram` :ref:`NXimage_set_em_se` - :ref:`NXinteraction_volume_em` + :ref:`NXinteraction_vol_em` :ref:`NXion` :ref:`NXlens_em` :ref:`NXmanufacturer` - :ref:`NXoptical_system_em + :ref:`NXoptical_system_em` :ref:`NXpeak` :ref:`NXpump` :ref:`NXscanbox_em` @@ -232,7 +232,7 @@ for the following macro-areas of experimental physics :ref:`NXpeak` :ref:`NXpump` :ref:`NXpulser_apm` - :ref:`NXreflectron + :ref:`NXreflectron` :ref:`NXstage_lab` .. Extended base classes: diff --git a/manual/source/sed/landing-page.rst b/manual/source/sed/landing-page.rst index ae13e6a5a3..a79f1b131a 100644 --- a/manual/source/sed/landing-page.rst +++ b/manual/source/sed/landing-page.rst @@ -15,6 +15,7 @@ https://www.nexusformat.org/ ellipsometry-structure em-structure apm-structure + epics-structure ----------- From 50433d9039b3f33299bab338998acb5335cd8951 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Mon, 11 Jul 2022 20:15:09 +0200 Subject: [PATCH 036/203] Deactivated line in Makefile that became dysfunctional with NeXus Code Camp 202206 changes --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index e8e0b265f0..0fc868a148 100644 --- a/Makefile +++ b/Makefile @@ -27,7 +27,7 @@ all :: # # build the PDF, still a failure will be noted but we can ignore it without problem # ($(MAKE) latexpdf LATEXOPTS="--interaction=nonstopmode" -C build/manual || exit 0) # # finally, report what was built - @echo "HTML built: `ls -lAFgh build/manual/build/html/index.html`" +# @echo "HTML built: `ls -lAFgh build/manual/build/html/index.html`" # @echo "PDF built: `ls -lAFgh build/manual/build/latex/nexus.pdf`" impatient-guide :: From cded2c74de16f2ce7c772799039d1a7357e5b933 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Aug 2022 18:01:38 +0200 Subject: [PATCH 037/203] Adds transmission appdef --- .../NXtransmission.nxdl.xml | 198 ++++++++++++++++++ 1 file changed, 198 insertions(+) create mode 100644 contributed_definitions/NXtransmission.nxdl.xml diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml new file mode 100644 index 0000000000..ea753ea035 --- /dev/null +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -0,0 +1,198 @@ + + + + + + Variables used throughout the experiment + + + + Number of wavelength points + + + + + Number of sample parameters scanned + + + + + Number of time points scanned + + + + + Application definition for transmission experiments + + + + This application definition + + + + An application definition for transmission. + + + + Version number to identify which definition of this application definition was + used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant to the + application definition. + + + + + + + + + Start time of the experiment. + + + + + + Common beam mask to shape the incident beam + + + + + + If true, the incident beam is depolarized. + + + + + Polarizer value inside the beam path + + + + + Attenuator in the reference beam + + + + + + Attenuator in the sample beam + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Street address of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + Telephone number of the user. + + + + + + + Wavelength range in which this monochromator was used + + + + + + + + + + Wavelength range in which this detector was used + + + + + + + + Response time of the detector + + + + + Detector gain + + + + + + The lamp used for illumination + + + + The type of lamp, e.g. halogen, D2 etc. + + + + + The spectrum of the lamp used + + + + + + + + Wavelength range in which the lamp was used + + + + + + + + Slit setting used for measurement with this detector + + + + + + + + + + + + + Properties of the sample measured + + + + + + From 3800107b6cf5a48f56dc8ab40068b40cfb1ed574 Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 9 Aug 2022 11:47:41 +0200 Subject: [PATCH 038/203] Updates NXtransmission --- .../NXtransmission.nxdl.xml | 243 ++++++++++++++---- 1 file changed, 186 insertions(+), 57 deletions(-) diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index ea753ea035..b1592feb75 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -10,14 +10,9 @@ Number of wavelength points - + - Number of sample parameters scanned - - - - - Number of time points scanned + Number of scans @@ -53,12 +48,94 @@ Start time of the experiment. + + + Unique identifier of the experiment, such as a (globally persistent) + unique identifier. + + * The identifier is usually defined by the facility or principle + investigator. + * The identifier enables to link experiments to e.g. proposals. + + + + + An optional free-text description of the experiment. However, details of the + experiment should be defined in the specific fields of this application + definition rather than in this experiment description. + + + + + + Commercial or otherwise defined given name to the program that was + used to generate the result file(s) with measured data and metadata. + + + + + Version number of the program that was used to generate the result + file(s) with measured data and metadata. + + + + + Website of the software + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Street address of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). + + + + + Telephone number of the user. + + + + + + Manufacturer of the instrument. + + Common beam mask to shape the incident beam - + + + The height of the common beam in percentage of the beam + + @@ -82,61 +159,77 @@ - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Street address of the user's affiliation. - - - + + - Email address of the user. + Wavelength value(s) used for the measurement. + An array of 1 or more elements. Length defines N_wavelenghts + + + - + - Author ID defined by https://orcid.org/. + Overall spectral resolution of this spectrometer. + If several gratings are employed the spectral resoultion + should rather be specified for each grating inside the + NXgrating group of this spectrometer. - + - Telephone number of the user. + Diffraction grating, as could be used in a monochromator. + If two or more gratings were used, define the angular + dispersion and the wavelength range (min/max wavelength) + for each grating and make sure that the wavelength ranges + do not overlap. The dispersion should be defined for the + entire wavelength range of the experiment. - + + + Dispersion of the grating in nm/mm used. + + + + + The blaze wavelength of the grating used. + + + + + Overall spectral resolution of the instrument + when this grating is used. + + + + + Wavelength range in which this grating was used + + + + + + - + - Wavelength range in which this monochromator was used + Wavelength range in which this detector was used - - - + - Wavelength range in which this detector was used + Detector type - - - + + + + + @@ -148,7 +241,39 @@ Detector gain + + + Slit setting used for measurement with this detector + + + + + + + + + + + An array of relative scan start time points. + + + + + + + + Resulting data from the measurement. + The length of the 2nd dimension is + the number of time points. + If it has length one the time_points + may be empty. + + + + + + The lamp used for illumination @@ -157,6 +282,10 @@ The type of lamp, e.g. halogen, D2 etc. + + + + @@ -174,17 +303,6 @@ - - - Slit setting used for measurement with this detector - - - - - - - - @@ -193,6 +311,17 @@ - + + + A default view of the data emitted intensity vs. wavelength. + From measured_data plot intensity and wavelength. + + + + We recommend to use wavelength as a default attribute, but it can be + replaced by any suitable parameter along the X-axis. + + + From 17e04b6a595ca2e5b5ba19d4346996477c9a54d1 Mon Sep 17 00:00:00 2001 From: domna Date: Fri, 12 Aug 2022 17:22:11 +0200 Subject: [PATCH 039/203] Updates NXmpes with correct path for NXmanipulator --- contributed_definitions/NXmpes.nxdl.xml | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 8f20886ee0..182a7300fc 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -164,14 +164,14 @@ - - - Manipulator for positioning of the sample. - - - - - + + + + Manipulator for positioning of the sample. + + + + @@ -248,8 +248,8 @@ - Date of preparation of the sample for the XPS experiment (i.e. - cleaving, last annealing). + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). @@ -295,4 +295,4 @@ - + \ No newline at end of file From 298b4b0c1dd49305e3c16108066487f3faf1d950 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 15 Aug 2022 15:26:40 +0200 Subject: [PATCH 040/203] Updates NXmpes appdef --- contributed_definitions/NXmpes.nxdl.xml | 26 ++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 182a7300fc..2ed73fd70f 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -19,7 +19,7 @@ - + The source used to generate the primary photons. Properties refer strictly to @@ -54,18 +54,18 @@ - + Distance of the point of evaluation of the beam from the sample surface. - - - + + + - + Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. @@ -113,7 +113,7 @@ - + @@ -169,9 +169,9 @@ Manipulator for positioning of the sample. - - - + + + @@ -277,7 +277,7 @@ - + @@ -285,7 +285,7 @@ - + Represents a measure of one- or more-dimensional photoemission counts, where the varied axis may be for example energy, momentum, spatial coordinate, pump-probe @@ -295,4 +295,4 @@ - \ No newline at end of file + From 406bf862ebdb0d7513a2d30f36b8445664095be9 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 29 Aug 2022 14:19:05 +0200 Subject: [PATCH 041/203] Allows recommended for attributes --- nxdl.xsd | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/nxdl.xsd b/nxdl.xsd index 2d0b9fa926..8a51f27fa2 100755 --- a/nxdl.xsd +++ b/nxdl.xsd @@ -997,6 +997,14 @@ + + + + A synonym for optional, but with the recommendation that this + attribute be specified. + + + From 50d25b50da0cee1a167e6056b398a83b0765b333 Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Thu, 1 Sep 2022 15:08:08 +0200 Subject: [PATCH 042/203] Added latest NXiv_temp to contributed --- contributed_definitions/NXiv_temp.nxdl.xml | 59 ++++++++-------------- 1 file changed, 22 insertions(+), 37 deletions(-) diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 5122b71e1a..88a7a3be22 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -6,14 +6,15 @@ Variables used throughout the document, e.g. dimensions and important parameters - + - Number of elements in the scanned voltage array + Number of elements in the scanned voltage array that were set during + the measurement - Number of additional variables that are changed with the temperature + Number of additional variables read that are changed with the temperature (can be understood as columns next to the temperature) @@ -25,10 +26,10 @@ Application definition for temperature-dependent IV curve measurements. - + In this application definition, times should be specified always together with an UTC offset. - + This is the application definition describing temperature dependent IV curve measurements. For this a temperature is set. After reaching the temperature, a voltage sweep is performed. For each voltage a current is measured. @@ -50,21 +51,21 @@ NeXus NXDL schema to which this file conforms. - - - URL where to find further material (documentation, examples) relevant to the application definition + + + Unique identifier of the experiment, such as a (globally persistent) - unique identifier. The identifier is usually defined by the - facility or principle investigator. The identifier enables to link + unique identifier. The identifier is usually defined by the + facility or principle investigator. The identifier enables to link experiments to e.g. proposals. @@ -117,13 +118,13 @@ - Name of the affiliation of the user at the point in time when + Name of the affiliation of the user at the point in time when the experiment was performed. - Full address (street, street number, ZIP, city, country) + Full address (street, street number, ZIP, city, country) of the user's affiliation. @@ -161,7 +162,7 @@ - Custom name of the voltage source for the IV sweep given + Custom name of the voltage source for the IV sweep given by the user/institution. @@ -180,7 +181,7 @@ - Specify the used current source used in the voltage sweep + Specify the used current source used in the voltage sweep for the IV measurement." @@ -277,7 +278,7 @@ - If you specified 'other' as temperature sensor, + If you specified 'other' as temperature sensor, please write down what it is. @@ -314,8 +315,8 @@ Ideally, a reference to the location or a unique (globally persistent) identifier (e.g.) of e.g. another file which gives as many as possible - details of the material, its microstructure. In the case that such a - detailed history of the sample is not available, use this field as a + details of the material, its microstructure. In the case that such a + detailed history of the sample is not available, use this field as a free-text description to specify details of the sample and its preparation. @@ -336,9 +337,9 @@ Resulting data from the measurement, described by data type. - - - + + + @@ -363,23 +364,7 @@ against the voltage (x-axis) with color coding for the temperature of each IV-curve. - - - Array of voltage values on the independent axis supporting the curve. - - - - - - - - Array of current values on the dependent axis of the curve. - - - - - IV curve. - + From f58f1c2dd34044f3057ac0373dc7069e2874caeb Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Fri, 2 Sep 2022 11:17:48 +0200 Subject: [PATCH 043/203] Updated operator to be open to be named as user prefers --- contributed_definitions/NXiv_temp.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 88a7a3be22..dd3abf5e47 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -105,7 +105,7 @@ - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if From 0baa6e6ffd2e7b0005a97a24499959e15f455604 Mon Sep 17 00:00:00 2001 From: domna Date: Fri, 2 Sep 2022 12:03:04 +0200 Subject: [PATCH 044/203] Adds NXuser to NXmpes --- contributed_definitions/NXmpes.nxdl.xml | 33 +++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 2ed73fd70f..1711826f5f 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -18,6 +18,39 @@ + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + From 94e36787c5dbcbd96e6988c8856b1f80e3156bff Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Fri, 2 Sep 2022 13:39:33 +0200 Subject: [PATCH 045/203] Added extra metadata fields to NXiv_temp --- contributed_definitions/NXiv_temp.nxdl.xml | 28 +++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index dd3abf5e47..1c185274e3 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -178,6 +178,15 @@ set/wait/read/repeat mechanism. + + + An array of voltages that were set using this controller for every + data point recorded. + + + + + @@ -288,7 +297,7 @@ For example resistance of a Pt1000. - + @@ -297,6 +306,15 @@ raw_temp_data. All values should be given in SI units. + + + An array of temperatures that were set using this controller for every + data point recorded. + + + + + @@ -335,12 +353,20 @@ Resulting data from the measurement, described by data type. + + [Temp,Temp_raw,Current,Timestamp] + + + An array of strings to list all the variables in the data + in order of appearance in the last index of the 3D array. + + From d53d094fd171188128d6031aeb6f12face5cebd5 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Fri, 2 Sep 2022 14:02:03 +0200 Subject: [PATCH 046/203] Sprint9 shape and geometry, updated NXem, and paraprobe application definitions and base classes collected, and tested with make local --- contributed_definitions/NXapm.nxdl.xml | 414 ++++--- .../NXapm_evaporation_id_filter.nxdl.xml | 27 + .../NXapm_hitmultiplicity_filter.nxdl.xml | 42 + .../NXapm_input_ranging.nxdl.xml | 35 + .../NXapm_input_reconstruction.nxdl.xml | 37 + .../NXapm_iontype_filter.nxdl.xml | 41 + .../NXapm_paraprobe_config_distancer.nxdl.xml | 209 ++++ ...Xapm_paraprobe_config_intersector.nxdl.xml | 387 +++++++ .../NXapm_paraprobe_config_nanochem.nxdl.xml | 1010 +++++++++++++++++ .../NXapm_paraprobe_config_ranger.nxdl.xml | 270 +++++ .../NXapm_paraprobe_config_surfacer.nxdl.xml | 227 ++++ ...Xapm_paraprobe_config_tessellator.nxdl.xml | 188 +++ ...NXapm_paraprobe_config_transcoder.nxdl.xml | 95 ++ .../NXapm_paraprobe_results_ranger.nxdl.xml | 293 +++++ ...Xapm_paraprobe_results_transcoder.nxdl.xml | 209 ++++ .../NXapm_spatial_filter.nxdl.xml | 64 ++ .../NXcg_alpha_shape.nxdl.xml | 98 ++ .../NXcg_cylinder_set.nxdl.xml | 132 +++ .../NXcg_ellipsoid_set.nxdl.xml | 112 ++ .../NXcg_face_list_data_structure.nxdl.xml | 219 ++++ .../NXcg_geodesic_mesh.nxdl.xml | 35 + contributed_definitions/NXcg_grid.nxdl.xml | 151 +++ .../NXcg_half_edge_data_structure.nxdl.xml | 147 +++ .../NXcg_hexahedron_set.nxdl.xml | 207 ++++ .../NXcg_isocontour.nxdl.xml | 43 + .../NXcg_marching_cubes.nxdl.xml | 50 + .../NXcg_parallelogram_set.nxdl.xml | 156 +++ .../NXcg_point_set.nxdl.xml | 77 ++ .../NXcg_polygon_set.nxdl.xml | 135 +++ .../NXcg_polyhedron_set.nxdl.xml | 150 +++ .../NXcg_polyline_set.nxdl.xml | 153 +++ contributed_definitions/NXcg_roi_set.nxdl.xml | 16 + .../NXcg_sphere_set.nxdl.xml | 98 ++ .../NXcg_tetrahedron_set.nxdl.xml | 132 +++ .../NXcg_triangle_set.nxdl.xml | 107 ++ .../NXcg_triangulated_surface_mesh.nxdl.xml | 22 + .../NXcg_unit_normal_set.nxdl.xml | 46 + contributed_definitions/NXclustering.nxdl.xml | 100 ++ .../NXcs_computer.nxdl.xml | 58 + contributed_definitions/NXcs_cpu.nxdl.xml | 18 + .../NXcs_filter_boolean_mask.nxdl.xml | 83 ++ contributed_definitions/NXcs_gpu.nxdl.xml | 18 + contributed_definitions/NXcs_io_obj.nxdl.xml | 33 + contributed_definitions/NXcs_io_sys.nxdl.xml | 13 + contributed_definitions/NXcs_mm_sys.nxdl.xml | 17 + contributed_definitions/NXcs_prng.nxdl.xml | 61 + .../NXcs_profiling.nxdl.xml | 114 ++ .../NXcs_profiling_event.nxdl.xml | 74 ++ contributed_definitions/NXem.nxdl.xml | 755 ++++++++---- contributed_definitions/NXem_nion.nxdl.xml | 789 ------------- .../NXevent_data_em.nxdl.xml | 138 ++- contributed_definitions/NXfib.nxdl.xml | 95 -- .../NXgraph_edge_set.nxdl.xml | 92 ++ .../NXgraph_node_set.nxdl.xml | 66 ++ contributed_definitions/NXgraph_root.nxdl.xml | 14 + .../NXimage_set_em_adf.nxdl.xml | 34 +- contributed_definitions/NXion.nxdl.xml | 19 + contributed_definitions/NXlens_em.nxdl.xml | 11 + .../NXmanufacturer.nxdl.xml | 8 +- .../NXms_atom_set.nxdl.xml | 17 + .../NXms_crystal_set.nxdl.xml | 123 ++ .../NXms_delocalization.nxdl.xml | 109 ++ .../NXms_orientation_set.nxdl.xml | 94 ++ .../NXms_slip_system_set.nxdl.xml | 56 + .../NXms_snapshot.nxdl.xml | 32 + .../NXms_snapshot_set.nxdl.xml | 35 + .../NXoptical_system_em.nxdl.xml | 12 + contributed_definitions/NXpulser_apm.nxdl.xml | 8 +- contributed_definitions/NXpump.nxdl.xml | 1 + contributed_definitions/NXscanbox_em.nxdl.xml | 1 + .../NXspectrum_set_em_eels.nxdl.xml | 152 ++- .../NXspectrum_set_em_xray.nxdl.xml | 80 +- .../NXtransmission.nxdl.xml | 2 +- manual/source/apm-structure.rst | 4 +- manual/source/cgms-structure.rst | 279 +++++ manual/source/em-structure.rst | 70 +- manual/source/index.rst | 2 + manual/source/north-structure.rst | 218 ++++ 78 files changed, 8414 insertions(+), 1325 deletions(-) create mode 100644 contributed_definitions/NXapm_evaporation_id_filter.nxdl.xml create mode 100644 contributed_definitions/NXapm_hitmultiplicity_filter.nxdl.xml create mode 100644 contributed_definitions/NXapm_input_ranging.nxdl.xml create mode 100644 contributed_definitions/NXapm_input_reconstruction.nxdl.xml create mode 100644 contributed_definitions/NXapm_iontype_filter.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml create mode 100644 contributed_definitions/NXapm_spatial_filter.nxdl.xml create mode 100644 contributed_definitions/NXcg_alpha_shape.nxdl.xml create mode 100644 contributed_definitions/NXcg_cylinder_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_geodesic_mesh.nxdl.xml create mode 100644 contributed_definitions/NXcg_grid.nxdl.xml create mode 100644 contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_isocontour.nxdl.xml create mode 100644 contributed_definitions/NXcg_marching_cubes.nxdl.xml create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyline_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_roi_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml create mode 100644 contributed_definitions/NXcg_unit_normal_set.nxdl.xml create mode 100644 contributed_definitions/NXclustering.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_cpu.nxdl.xml create mode 100644 contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu.nxdl.xml create mode 100644 contributed_definitions/NXcs_io_obj.nxdl.xml create mode 100644 contributed_definitions/NXcs_io_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_mm_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/NXcs_profiling_event.nxdl.xml delete mode 100644 contributed_definitions/NXem_nion.nxdl.xml delete mode 100644 contributed_definitions/NXfib.nxdl.xml create mode 100644 contributed_definitions/NXgraph_edge_set.nxdl.xml create mode 100644 contributed_definitions/NXgraph_node_set.nxdl.xml create mode 100644 contributed_definitions/NXgraph_root.nxdl.xml create mode 100644 contributed_definitions/NXms_atom_set.nxdl.xml create mode 100644 contributed_definitions/NXms_crystal_set.nxdl.xml create mode 100644 contributed_definitions/NXms_delocalization.nxdl.xml create mode 100644 contributed_definitions/NXms_orientation_set.nxdl.xml create mode 100644 contributed_definitions/NXms_slip_system_set.nxdl.xml create mode 100644 contributed_definitions/NXms_snapshot.nxdl.xml create mode 100644 contributed_definitions/NXms_snapshot_set.nxdl.xml create mode 100644 manual/source/cgms-structure.rst create mode 100644 manual/source/north-structure.rst diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 53c790b417..24fbcd18f0 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -3,11 +3,11 @@ - The symbols used in the schema to specify e.g. dimensions of arrays + The symbols used in the schema to specify e.g. dimensions of arrays. - Total number of ions collected + Total number of ions collected. @@ -28,8 +28,8 @@ - Number of mass-to-charge-state-ratio range intervals mapped on this - ion type. + Number of mass-to-charge-state-ratio intervals mapped on this ion + type. @@ -54,7 +54,7 @@ - Application definition for atom probe microscopy experiments. + Application definition for atom probe and field ion microscopy experiments. @@ -73,11 +73,11 @@ - Ideally, a (globally) unique persistent identifier + Ideally, a (globally) unique persistent identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link + or the principle investigator. The identifier enables to link experiments to e.g. proposals. @@ -91,7 +91,7 @@ experiment into this free-text description field. - + ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. @@ -103,14 +103,12 @@ Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and interpretation of the experiment. The user should be aware that - even with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data - were acquired. + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. More detailed timing data over the course of the experiment have to be - collected to compute this. These computations can take advantage of - individual time stamps in NXevent_em instances to provide - additional pieces of information. + collected to compute this event chain during the experiment. @@ -122,23 +120,27 @@ Commercial or otherwise given name to the program which was used - to create the file. Atom probe microscopy experiments are nowadays - in most cases controlled via commercial software. These are often - designed as integrated acquisition and instrument control software - solutions. + to create the original results file of the atom probe experiment. + This file and program should not be confused with downstream + processing operations and file format conversion tasks. + + Atom probe microscopy experiments are except for still very much cases + controlled via commercial software. Such software is designed as an + integrated acquisition and instrument control software. + For AMETEK/Cameca local electrode atom probe (LEAP) instruments the least processed (rawest) numerical results and metadata are stored in so-called RHIT and HITS files, which are proprietary and the specifications of which are not publicly documented. Supplementary metadata are kept in a database which is connected - to the instrument control software. RHIT and HITS are proprietary - binary file formats whose content must not be accessed with software - other than of AMETEK (IVAS/AP Suite). In effect, RHIT and HITS files - store the experiment in a closed manner that is practically useless - for users unless they have access to the commercial software. + to the instrument control software and synced with the experiment + while signal is being detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. - To arrive at a state that atom probe microscopy with LEAP instruments + To arrive at a state that atom probe microscopy (APM) with LEAP instruments delivers a dataset with which users can study reconstructed atomic position and do e.g. composition analyses or other post-processing analysis tasks, these raw data have to be processed. Therefore, it is @@ -147,26 +149,33 @@ processing steps have to be stored. With this a user can create derived quantities like ion hit positions - (on the detector), calibrated time-of-flight data. These derived + (on the detector) and calibrated time-of-flight data. These derived quantities are also needed to obtain calibrated mass-to-charge-state ratios, and finally the tomographic reconstruction of the ion positions. In most cases, an APM dataset is useful only if it gets post-processed via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. In turn, these - labels decode elemental identities and can often also be used to - resolve isotopes. All these steps are in most cases performed using - commercial software. + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also to resolve isotopes. + All these steps are in most cases performed using commercial software. Frequently, though, ranging and post-processing is also performed with (open-source) research software. Therefore, there is strictly speaking not a single program used throughout an atom probe analysis not even - for the early data acquisition and processing stages to obtain a useful - reconstructed and ranged dataset. + for the early stage data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. - Therefore, the application definition documents not only the measurement + Therefore, this application definition documents not only the measurement but also the key post-processing steps which transform the proprietary data into a tomographic reconstruction with ranging definitions. + + Future guidance by the vendors could improve this description to cover + a substantial larger number of eventually metadata that so far + are not publicly documented and accessible in an open-source manner. @@ -180,29 +189,37 @@ - Not the specimen name or the experiment identifier but the identifier + Neither the specimen_name nor the experiment_identifier but the identifier through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/AP Suite + For LEAP instruments it is recommended to use the IVAS/APSuite run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments in Rouen, use the + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the identifier which is closest in meaning to the LEAP run number. - As a destructive microscopy method, a run can be performed only once. + As a destructive microscopy technique, a run can be performed only once. It is possible, however, to interrupt a run and restart data acquisition while still using the same specimen. In this case, each evaporation run - needs to be distinguished with - different run numbers. We follow this habit of most atom probe groups. + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow to store the + entire set of such interrupted runs to be stored and covered. However, + this is not because of a technical limitation within NeXus but + because we have not seen a covering use case based on which we could + have implemented and conceptualized this. Atom probers are invited to + contact the respective people in the FAIRmat team to fix this. - Binary container for a file or a compressed collection of files which + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold a compressed archive. Required for operation_mode apt_fim or other to give further details. Users should not abuse this field to provide free-text information. - Instead, these should be mapped to respective groups and sections. + Instead, these pieces of information should be mapped to + respective groups and sections. @@ -218,15 +235,17 @@ - What type of atom probe microscope experiment is performed. - This field can be used e.g. by materials database systems to - qualitatively filter experiments. - APT are experiments where the analysis_chamber has no imaging gas. - For FIM analyses an imaging gas is used, which should be specified - with the atmosphere in the analysis_chamber group. - Combinations of the two imaging modes are possible. For these apt_fim - or other operation_mode the user should specify details in the - experiment_documentation field. + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. @@ -235,7 +254,7 @@ - + Contact information and eventually details of at least one person involved in the taking of the microscope session. This can be the @@ -249,8 +268,8 @@ - Name of the affiliation of the user at the point in time when the experiment was - performed. + Name of the affiliation of the user at the point in time + when the experiment was performed. @@ -258,25 +277,31 @@ Postal address of the affiliation. - + - Email address of the user at the point in time when the experiment was - performed. Writing the most permanently used email is recommended. + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. - Globally unique identifier of the user as offered by services like ORCID or - ResearcherID. + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. - (Business) (tele)phone number of the user at the point in time when the - experiment was performed. + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. - + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating @@ -291,8 +316,8 @@ - Name of the social media platform where the account under social_media_name is - registered. + Name of the social media platform where the account + under social_media_name is registered. @@ -305,34 +330,33 @@ In cases where the specimen was e.g. site-specifically cut from samples or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve - which specimen on e.g. the microtip array was taken. + which specimen on e.g. the microtip array was taken. - The user is advised to store the details how specimens were - cut/prepared from samples in the sample history. - This field must not be used for an alias of the specimen. - Instead, use short_title. + The user is advised to store the details how specimens were + cut/prepared from samples in the sample history. This field must + not be used for an alias of the specimen. Instead, use short_title. In cases where multiple specimens have been loaded into the microscope the name has to be the specific one, whose results are stored by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. + the characterization of a single specimen in a single continuous run. - Details about the specimen preparation should be stored in the + Details about the specimen preparation should be stored in the sample history. Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/preparation - history. + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider - being the key steps and relevant information about the specimen, + as being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. @@ -342,7 +366,7 @@ ISO 8601 time code with local time zone offset to UTC information when the specimen was prepared. - Ideally report the end of the preparation, i.e. the last known time + Ideally, report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Usually this should be a part of the sample history, i.e. the sample is imagined handed over for the analysis. At the point it enters the microscope @@ -363,22 +387,22 @@ Use Hill's system for listing elements of the periodic table which - are inside or attached to the surface of the specimen and thus + are inside or attached to the surface of the specimen, and thus relevant from a scientific point of view. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret - these from the sample history. + these from the sample history or from other data sources. - Discouraged free-text field in case properly designed records for the - sample_history are not available. + Discouraged free-text field in case properly designed records + for the sample_history are not available. - + Hard link to a location in the hierarchy of the NeXus file where the data for default plotting are stored. @@ -390,9 +414,9 @@ For the specific idea and conventions to use with the NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. - Specific details for application in atom probe microscopy follow. In this research field scientists distinguish usually several Euclidean coordinate systems (CS): @@ -400,16 +424,18 @@ a CS specifying the room where the instrument is located in or a physical landmark on the instrument, e.g. the direction of the transfer rod where positive is the direction how the rod - pushes into the instrument. + has to be pushed during loading a specimen into the instrument. * The specimen space; a CS affixed to either the base or the initial apex of the specimen, whose z axis points towards the detector. * The detector space; - a CS affixed whose xy plane is usually in the detector and whose - z axis points towards the specimen. + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. * The reconstruction space; - a CS associated with the tomographic reconstruction. - Its orientation depends on the commercial software used. + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. * Eventually further coordinate systems attached to the flight path of individual ions might be defined. @@ -431,6 +457,7 @@ Consult the work of A. J. Breen and B. Gault and team for further details. + @@ -447,11 +474,11 @@ microscopy) are accelerated towards a position-sensitive and time-of-flight taking detector system. Hence, there is no real probe/beam. - * Second, the specimen is the lens of an atom probe microscope. + * Second, the specimen is the lens of the microscope. - Given name of the atom probe at the hosting institution. This is an + Given name of the atom probe at the hosting institution. This is an alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, etc. @@ -462,26 +489,99 @@ Using GEOREF is preferred. - + + + + + + - The space inside the atom probe that ions pass through nominally when they leave - the specimen and travel to the detector. + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Was the reflectron used? + + + + + + + + @@ -492,7 +592,16 @@ Identifier of the local_electrode in an e.g. database. - + + + + + + + + + + @@ -547,6 +656,36 @@ + + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + If pulse_mode is laser or laser_and_high_voltage + having the group/section laser_gun the following fields + have to be filled also and are not optional: + + * name + * wavelength + * power + + + + + + + + + + + @@ -609,8 +748,9 @@ but this usually takes an interrupted experiment in which the specimen is transferred, an image taken, and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another, less accurate method, though, is to monitor + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor the specimen evolution via the in-built camera system (if available) in the instrument. * Another method is to use correlated scanning force microscopy @@ -618,10 +758,13 @@ * A continuous monitoring of the specimen in a correlative electron microscopy/atom probe experiment is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. - Ideally measured or best elaborated guess of the initial radius of the specimen. + Ideally measured or best elaborated guess of the + initial radius of the specimen. @@ -693,18 +836,19 @@ - Data post-processing step which is, like the impact position analyses, - also usually executed in the integrated control software. - This processing yields how many ions were detected with each pulse. + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - Multiplicity must not be confused with how many - atoms of the same element or isotope, respectively, - a molecular ion contains (which is encoded with the - isotope_vector field of each NXion instance. + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). @@ -750,7 +894,7 @@ - Like impact position and hit multiplicity computations, + Like impact position and hit multiplicity computations, ion filtering is a data post-processing step with which users identify which of the detected ions should be included in the voltage-and-bowl correction. @@ -784,8 +928,8 @@ - Data post-processing step to correct for ion impact - position flight path differences, detector biases, + Data post-processing step to correct for ion impact + position flight path differences, detector biases, and nonlinearities. This step is usually performed with commercial software. @@ -807,8 +951,8 @@ - Raw time-of-flight data as read out from the acquisition software if these data - are available and accessible. + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. @@ -824,25 +968,25 @@ - The key idea and algorithm of the voltage-and-bowl correction - is qualitatively similar for instruments of different manufacturers + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers or research groups. Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or + calibration models. For now we do not wish to resolve or generalize these differences. Rather the purpose of this collection is to provide a container where model-specific parameters and calibration models can be stored if users know these for sure. - For AMETEK LEAP atom probes this should be the place for + For AMETEK LEAP instruments this should be the place for storing initial calibration values. These values are accessible normally only by AMETEK service engineers. They use these for calibrating the detector and instrument. Users can also use this NXcollection for storing the iteratively identified calibrations which scientists - will get displayed in e.g. AP Suite while they execute + will see displayed in e.g. APSuite while they execute the voltage-and-bowl correction as a part of the reconstruction pipeline in APSuite. @@ -876,7 +1020,7 @@ - Mass-to-charge-state ratios + Mass-to-charge-state ratio values. @@ -1032,12 +1176,14 @@ How many ion types are distinguished. If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. + molecular ions, even the most complicated ones. Currently a value of 32 is used. @@ -1046,7 +1192,7 @@ Specifies the computation of the mass-to-charge histogram. Usually mass-to-charge values are studied as an ensemble quantity, specifically these values are binned. - The (NXprocess) stores the settings of this binning. + This (NXprocess) stores the settings of this binning. @@ -1066,7 +1212,7 @@ - Smallest and largest mass-to-charge value. + Smallest and largest mass-to-charge-state ratio value. @@ -1074,7 +1220,7 @@ - Binning width + Binning width of the mass-to-charge-state ratio values. @@ -1092,7 +1238,7 @@ - End of mass-to-charge-state ratio bin. + End of value for each mass-to-charge-state ratio bin. @@ -1126,8 +1272,8 @@ - How where peaks in the background-corrected - mass-to-charge histogram identified? + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? @@ -1145,7 +1291,10 @@ - + + + + @@ -1170,6 +1319,7 @@ + diff --git a/contributed_definitions/NXapm_evaporation_id_filter.nxdl.xml b/contributed_definitions/NXapm_evaporation_id_filter.nxdl.xml new file mode 100644 index 0000000000..4a5f4e66d6 --- /dev/null +++ b/contributed_definitions/NXapm_evaporation_id_filter.nxdl.xml @@ -0,0 +1,27 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Settings for a filter to select ions based on their evaporation (sequence) ID. + + + + Triplet of the minimum, increment, and maximum evaporation ID which will + be included in the analysis. + The increment controls which n-th ion to take. + + Take as an example a dataset with 100 ions and the filter set to 0, 1, 99. + This will process each ion. 0, 2, 99 will take each second ion. + 90, 3, 99 will take only each third ion beginning from evaporation ID (90 + up to 99. + + + + + + diff --git a/contributed_definitions/NXapm_hitmultiplicity_filter.nxdl.xml b/contributed_definitions/NXapm_hitmultiplicity_filter.nxdl.xml new file mode 100644 index 0000000000..9be956dc8f --- /dev/null +++ b/contributed_definitions/NXapm_hitmultiplicity_filter.nxdl.xml @@ -0,0 +1,42 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many different multiplicity values does the filter specify. + + + + + Settings for a filter to select ions based on their hit multiplicity. + + + + Meaning of the filter: + Whitelist specifies which ions with said hit multiplicity to include. + Ions with all other hit multiplicity will be filtered out. + + Blacklist specifies which ions with said hit multiplicity to exclude. + Ions of all other hit multiplicity will be included. + + + + + + + + + Array of hit multiplicity values to filter according to method. + For example if the filter specifies [1, 5, 6] and method is whitelist, + only ions with hit multiplicity 1, 5 or 6 will be processed and all + other ions will be filtered out. + + + + + + diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml new file mode 100644 index 0000000000..34ea718cb3 --- /dev/null +++ b/contributed_definitions/NXapm_input_ranging.nxdl.xml @@ -0,0 +1,35 @@ + + + + + Metadata to ranging definitions made for an atom probe dataset. + + + + Name of (NeXus)/HDF5 file which stores ranging definitions which define + how mass-to-charge-state ratios map to iontypes and which iontypes are + distinguished. The UNKNOWNTYPE iontype (unranged) is the default iontype. + The ID of this special iontype is always reserved as 0. Each ion + is assigned to the UNKNOWNTYPE by default. Iontypes are assigned + by checking if the mass-to-charge-state ratio of an ion matches + to any of the defined mass-to-charge-state ratio intervals. + + + + Version identifier of the file (representing an at least SHA256) hash + which documents the binary state of the file to add an additional layer + of reproducibility for tracking provenance. + + + + + + Name of the group (prefix to the individual ranging definitions) + inside the HDF5 file which refers to the ranging definition to use. + A HDF5 file can store multiple ranging definitions. Using an ID is + the mechanism to distinguish which specific ranging (version) will + be processed. Reconstruction and ranging IDs can differ. + They specify different IDs. + + + diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml new file mode 100644 index 0000000000..3a59fe1242 --- /dev/null +++ b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Metadata to a reconstructed dataset. + + + + Name of the (NeXus)/HDF5 file which stores reconstructed ion position + and mass-to-charge-state ratios. Such an HDF5 file can store multiple + reconstructions. Using an identifier (ID) is the mechanism which + paraprobe uses to distinguish which specific reconstruction will + be processed. With this design it is possible that the same HDF5 + file stores multiple versions of a reconstruction of e.g. the same + or different measured datasets, respectively. + + + + Version identifier of the file (representing an at least SHA256) hash + which documents the binary state of the file to add an additional layer + of reproducibility for tracking provenance. + + + + + + Name of the dataset inside the HDF5 file which refers to the + specific reconstructed ion positions to use for this analysis. + + + + + Name of the dataset inside the HDF5 file which refers to the + specific mass-to-charge-state ratios to use for this analysis. + + + diff --git a/contributed_definitions/NXapm_iontype_filter.nxdl.xml b/contributed_definitions/NXapm_iontype_filter.nxdl.xml new file mode 100644 index 0000000000..30bdabc143 --- /dev/null +++ b/contributed_definitions/NXapm_iontype_filter.nxdl.xml @@ -0,0 +1,41 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many iontypes does the iontypes_filter specify. + + + + + Settings for a filter to select ions based on their iontype. + + + + Meaning of the filter: + Whitelist specifies which iontypes to include. + Ions of all other types will be filtered out. + + Blacklist specifies which iontypes to exclude. + Ions of all other types will be included. + + + + + + + + + Array of iontypes to filter according to method. + For example if the candidates are [0, 3] only ions of the type + unrange/unknown and the third ion type are used. + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml new file mode 100644 index 0000000000..06697398ba --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -0,0 +1,209 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration/settings of a paraprobe-distancer software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many individual analyses should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Paraprobe-distancer enables the computation of the Euclidean shortest + distance for each member of a set of points against a set of triangles. + In contrast to comparable methods used in atom probe the here computed + distance is not simply the projected distance to one of the triangles + but the more costly but robust computation of the distance between + a point and a triangle. + + The triangles can represent for instance the facets of a triangulated + surface mesh of a model for the edge of the dataset. Such a model can + be computed with paraprobe-surfacer. Alternatively, the triangles can + be those from the set of all facets for a set of convex hulls, alpha-shapes, + or alpha wrappings about three-dimensional objects like precipitates + (computed with e.g. paraprobe-nanochem). + + Currently, the tool does not check if the respectively specified + triangle sets are consistent, what their topology is, or whether or + not they are consistently oriented. + Each dataset that is referred to in the list_of _dataset_names_vertices + should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred + to in the list_of_dataset_names_facet_indices should be an + (Nfacets, 3) array of NX_UINT. + Facet indices refer to vertex indices. These need to start at zero + and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and vertices are indexed thus implicitly. + + + + How many triangle sets to consider. + + + + + List of triangle sets. This design allows users to combine + multiple triangle sets. + + + + Name of the HDF5 file(s) which contain(s) vertex coordinates + and facet indices to describe the desired set of triangles. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility. + + + + + + Absolute HDF5 path to the dataset which + specifies the array of vertex positions. + + + + + Absolute HDF5 path to the dataset which + specifies the array of facet indices. + + + + + + + + Specifies for which ions/points the tool will compute distances. + The purpose of this setting is to avoid unnecessary computations + when the user requests to only compute distances of ions within a + threshold distance to the triangle soup. + + By default the distances are computed for all ions; however + the setting skin enables to compute distances only for those + ions which are not farther away located to a triangle + than threshold_distance. + + + + + + + + + Maximum distance for which distances are computed when method is skin. + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml new file mode 100644 index 0000000000..b43ea444d0 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml @@ -0,0 +1,387 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many elements to use for computing a composition. + + + + + Configuration/settings of a paraprobe-intersector software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + + + + + Specifies the method to use which decides if two objects intersect. + For reasons which are detailed in the supplementary material of + `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by + default assumes that two objects intersect if they share at least one + ion with the same evaporation ID + (shared_ion). Alternatively, with specifying tetrahedra_intersections, + the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks + for at least one pair of intersecting tetrahedra to identify if two objects + intersect or not. + + However, we found that these geometrical analyses can result in corner + cases which the currently used library (TetGen) was not unable to + tetrahedralize successfully. These cases were virtually always + associated with complicated non-convex polyhedra + which had portions of the mesh that were connected by almost point like + tubes of triangles. + + + + + + + + + Specifies if the tool should load the volume of each object + (if existent in the input file) to characterize the evolution of the + objects' volume as a function of set identifier (e.g. time). + + This and the has_object_composition option enables to activate + computations in the code which correlate the spatio-temporal tracking + with an object's properties. This is useful to explore/understand how + the object descriptor values evolve as a function of the parameterization + of the object. To arrive at a detailed understanding and quantification + of the differences of a given object as a function of delocalization and + e.g. iso-surfacing settings. + + The point made in M. Kühbach et al. 2022, is that this functionality + can be used to track for instance how the accumulated volume and + composition of an object depends on its segmentation via iso-surfaces. + The benefit of such computations is that users can inspect the + parameter sensitivity of an objects representation rigorously. + + + + + Specifies if the tool should load the composition of each object + (if existent in the input file) to characterize the evolution of the + object's composition as a function of set identifier. See the description + of has_object_volume for further details. In M. Kühbach et al. 2022, both + has_object options were used to characterize e.g. the parameter + sensitivity of computed composition, volume, and shape specifically, + for a carbide that was segmented via different carbon iso-composition + values. + + + + + List of np.uint16 elements, via their proton number. The whitelist is + evaluated to compute the composition of an object during tracking + when has_object_composition is set to true. + + + + + + + + For now a support field for the tool to identify how many individual + analyses the tool should execute as part of the analysis. + + + + + + For now a support field for the tool to identify how many individual + analyses (i. e. individual current_to_next mappings) the tool should + perform as part of the high-throughput analysis. + + + + + Tracking is the process of building logical relations between objects + based on proximity and mesh intersections. For each time step pairs + of sets are compared: members of a current_set and a next_set. + Members have to be objects and eventually can in addition be so-called + proxies. Objects and proxies are non-degenerated closed polyhedra which + are not necessarily convex. Proxies are doppelganger/replacement + meshes of objects which would otherwise be impossible to describe + with a closed mesh. + + + + Current set stores a set of object geometries that should be checked + for proximity and/or intersection with member of the next_set. + + + + This identifier can be used to label the current set. The label + effectively represents the time/iteration step when the current + set was taken. As it is detailed in M. Kühbach et al. 2022, + this identifier takes the role of the time variable k. + + + + + Name of the HDF5 file which contain geometry (vertex coordinates, + facet indices) and properties (ions, composition) of polyhedra + (l objects) which should be included in the current set. + The user has to ensure that the datasets under list_of_dataset_names + (vertices, facet_indices, ions) exist and are formatted consistently. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Paraprobe-intersector loads triangulated surface mesh data of a + set of objects. For each object its mesh is expected to have + three-dimensional position data of the unique vertices and a + matrix of vertex indices which describe the faces. + As each object has to be a polyhedron/closed surface mesh, this + matrix has as many rows as faces, i.e. triangles and three columns. + Vertex indices have to start at zero. + + + + + The default intersection detection method uses shared ions. + Therefore, it is necessary to specify where the results from the + paraprobe-nanochem tool run are located which document which ions + (with their evaporation IDs) are inside or on the surface of each + object. This field points the tool to these evaporation IDs. + + + + + In order to correlate object properties like volume and composition + with tracking data, it is necessary to specify where the results + (object properties) from the paraprobe-nanochem tool run are located. + This field instructs the tool where to load these object property data + from. + + + + + Paraprobe-intersector does not just compare two objects but a set + of sets of objects. This field instructs the tool where to load + the identifiers (names) of each object in a current_set or next_set + respectively from. + + + + + Like groupname_object_geometry_data but for the proxies. + Triangulated surface meshes of proxies have to be formatted + in the same manner as objects. + + + + + Like groupname_proxy_supplementary_data but for the interior proxies. + Leave an empty string if proxies should not be used. + + + + + Like groupname_proxy_supplementary_data but for the exterior proxies. + Leave an empty string if proxies should not be used. + + + + + + Next set stores a set of object geometries that should be checked + for proximity and/or intersection with (each) member(s) of the + current_set. + + + + This identifier can be used to label the next set. Like for the current_set + the identifier is effectively the time/iteration step when the next set was taken. + As it is detailed in M. Kühbach et al. 2022, this identifier + takes the role of the time variable k+1. + + + + + Name of the HDF5 file which contain geometry (vertex coordinates, + facet indices) and properties (ions, composition) of + polyhedra(l objects) which should be included in the current set. + The user has to ensure that the datasets that are referred to + under list_of_dataset_names (vertices, facet_indices, ions). + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Paraprobe-intersector loads triangulated surface mesh data of a + set of objects. For each object its mesh is expected to have + three-dimensional position data of the unique vertices and a + matrix of vertex indices which describe the faces. + As each object has to be a polyhedron/closed surface mesh + this matrix has as many rows as faces, i.e. triangles and + three columns. Vertex indices have to start at zero. + + + + + The default intersection detection method uses shared ions. + Therefore, it is necessary to specify where the results from the + paraprobe-nanochem tool run are located which document which ions + (with their identifiers) are inside or on the surface of each object. + This field instructs the tool where to load these + ion evaporation ids from. + + + + + In order to correlate object properties like volume and composition + with tracking data, it is necessary to specify where the results + (object properties) from the paraprobe-nanochem tool run are located. + This field instructs the tool where to load these object property + data from. + + + + + Paraprobe-intersector does not just compare two objects but a set + of sets of objects. This field instructs the tool where to load + the identifiers (names) of each object in a current or next set + respectively from. + + + + + Like groupname_object_geometry_data but for the proxies. + Triangulated surface meshes of proxies have to be formatted + in the same manner. Leave an empty string if proxies should not + be used. + + + + + Like groupname_proxy_supplementary_data but for the interior proxies. + Leave an empty string if proxies should not be used. + + + + + Like groupname_proxy_supplementary_data but for the exterior proxies. + Leave an empty string if proxies should not be used. + + + + + + Specifies if, in the case of small finite datasets, objects which are + located at the edge of the dataset should be accounted for or not. + If these so-called proxy/doppelganger objects are accounted for, the + respective groupname_proxy and dataset_proxy fields have to be + filled to tell the tool where to load which proxy meshes from. + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) intersect volumetrically. + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) lie closer to one another than the + threshold_proximity. + + + + + Specifies if the tool evaluates, ones all tracking tasks were + successfully completed, how intersecting or proximity related + objects build sub-graphs. This is the feature which enabled + M. Kühbach et al. 2022 the high-throughput analyses of how many + objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order. For these analyses to work + has_object_volume needs to be activated. + + + + + The maximum Euclidean distance between two objects below which + both objects are still considered within proximity. + + + + + Specifies if the tool stores the so-called forward relations between + nodes representing members of the current_set to nodes representing + members of the next_set. + + + + + Specifies if the tool stores the so-called backward relations between + nodes representing members of the next_set to nodes representing + members of the current_set. + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml new file mode 100644 index 0000000000..beef622e76 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -0,0 +1,1010 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many iontypes does the delocalization filter specify. + + + + + How many disjoint control points are defined. + + + + + How many iontypes does the interface meshing iontype filter specify. + + + + + How many DCOM iterations. + + + + + Maximum number of atoms per molecular ion. + + + + + Configuration/settings of a paraprobe-nanochem software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + + + + + How many individual analyses should the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject a previously computed triangle soup or + triangulated surface mesh representing a model (of the surface) of + the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + + + + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the edge of the dataset. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + + + + + + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + For now a support field for the tool to identify how many individual + delocalization analyses for the above-mentioned dataset and supplementary + files are executed as part of the high-throughput analysis. + + + + + Discretization of the ion point cloud on a three-dimensional grid. + + + + Delocalization in the field of atom probe microscopy is the process + of discretizing a point cloud. By default the tool computes a full + kernel density estimation of decomposed ions to create one discretized + field for each element. + + Although, this uses an efficient multithreaded algorithm, + the computation is costly. Therefore, it can be advantageous for users + to load an already computed delocalization. This can be achieved with + the load_existent option. + When using this option the user is responsible to assure that the + settings which were used for computing this already existent delocalization + are specified in the same manner as they were. + + + + + + + + + Matrix of isotope vectors representing iontypes. + The filter specifies a matrix of isotope_vectors which is the most + general approach to define if and how many times an ion is counted. + Currently, paraprobe_nanochem performs a so-called atomic decomposition + of all iontypes. Specifically, the tool interprets of how many + elements/atoms a molecular ion is composed; and thus determines the + atoms multiplicity with respect to the iontype. + + Let's take the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore in an atomic + decomposition computation of the iso-surface each H3O+ ion adds + three hydrogen counts. This is a practical solution which accepts + the situation that during an atom probe experiment not each bond + of each ion/a group of neighboring atoms is broken but molecular + ions get detected. The exact ab-initio details depend on the local + field conditions and thus also the detailed spatial arrangement + of the atoms and their own electronic state and that of the neighbors + before and upon launch. + Being able to measure the information for such sites only as + molecular ions causes an inherent information loss with respect to the + detailed spatial arrangement. This information loss is more relevant + for local electrode atom probe than for field ion microscopy setting + how precisely the atomic positions can be reconstructed. + Accounting for multiplicities assures that at least the + compositional information is analyzed. + + + + + + + + + List of individual grid resolutions to analyse. + Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with + an edge length of values in gridresolutions. + + + + + Half the width of a (2n+1)^3 cubic kernel of voxel beyond + which the Gaussian Ansatz function will be truncated. + Intensity beyond the kernel is refactored into the kernel via + a normalization procedure. + + + + + Variance of the Gaussian Ansatz kernel sigma_x = sigma_y = 2*sigma_z. + + + + + How should the results of the kernel-density estimation be computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + + + + + + + + + + + Specifies if the tool should report the delocalization 3D field values. + + + + + Optional computation of iso-surfaces after each computed delocalization + to identify for instance objects in the microstructure + (line features, interfaces, precipitates). + + + + As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., + the handling of triangles at the edge of the dataset requires + special attention. Especially for composition-normalized + delocalization it is possible that the composition increases + towards the edge of the dataset because the quotient of two numbers + which are both smaller than one is larger instead of smaller than + the counter. By default, the tool uses a modified marching cubes + algorithm of Lewiner et al. which detects if voxels face such a + situation. In this case, no triangles are generated for such voxels. + Alternatively, (via setting keep_edge_triangles) the user can + instruct the tool to not remove these triangles at the cost of bias. + + Specifically, in this case the user should understand that all + objects/microstructural features in contact with the edge of the + dataset get usually artificial enlarged and their surface mesh + often closed during the marching. This closure however is artificial! + It can result in biased shape analyses for those objects. + The reason why this should in general be avoided is a similar + argument as when one analyzes grain shapes in orientation microscopy + via e.g. SEM/EBSD. Namely, these grains, here the objects at the + edge of the dataset, were not fully captured during e.g. limited + field of view. + Therefore, it is questionable if one would like to make + substantiated quantitative statements about them. + + Thanks to collaboration with the V. V. Rielli and S. Primig, though, + paraprobe-nanochem implements a complete pipeline to + process even these objects at the edge of the dataset. Specifically, + the objects are replaced by so-called proxies, i.e. replacement + objects whose holes on the surface mesh have been closed if possible + via iterative mesh and hole-filling procedures with fairing operations. + In the results of each paraprobe-nanochem run, these proxy objects + are listed separately to allow users to quantify and analyze in + detail the differences when accounting for these objects or not. + Especially this is relevant in atom probe microscopy are small + in the sense that they contain few (many a few dozen) objects. + Even though such a dataset may give statistically significant + results for compositions this does not mean it necessarily yields + also statistically significant and unbiased results for three-dimensional + object analyses. Being able to quantify these effects and making + atom probers aware of these subtleties was one of the main reasons + why the paraprobe-nanochem tool was implemented. + + + + + + + + + The ion-to-edge-distance that is used in the analyses of objects + (and proxies) to identify whether these are inside the dataset or + close to the edge of the dataset. If an object has at least one ion + with an ion-to-edge-distance below this threshold, the object is + considered as one which lies close to the edge of the dataset. + This implements essentially a distance-based approach to solve + the in general complicated and involved treatment of computing + volumetric intersections between not-necessarily convex + closed 2-manifolds. In fact, such computational geometry analyses + can face numerical robustness issues as a consequence of which a + mesh can be detected as lying completely inside a dataset although + in reality it is epsilon-close only, i.e. almost touching only + the edge (e.g. from inside). + Practically, humans would state in such case that the object is + close to the edge of the dataset; however mathematically the object + is indeed completely inside. + In short, a distance-based approach is rigorous and more flexible. + + + + + Array of iso-contour values. For each value the tool computes + an iso-surface and performs subsequent analyses. + The unit depends on the choice for the normalization of the + accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + + + + + Specifies if the tool should report the triangle soup which represents + each triangle of the iso-surface complex. + Each triangle is reported with an ID specifying to which triangle + cluster (with IDs starting at zero) the triangle belongs. + The clustering is performed with a modified DBScan algorithm. + + + + + Specifies if the tool should analyze for each cluster of triangles + how they can be combinatorially processed to describe a closed + polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In fact, inaccuracies in the + reconstructed positions cause inaccuracies in all downstream + processing operations. Especially the effect on one-dimensional + spatial statistics like nearest neighbor correlation functions these + effects were discussed in the literature + `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_ + In continuation of these thoughts this applies also to reconstructed + objects. A well-known example is the discussion of shape deviations + of Al3Sc precipitates in aluminium alloys which in reconstructions + can appear as ellipsoids although they should be almost spherical, + depending on their size. + + + + + Specifies if the tool should report a triangulated surface mesh + for each identified closed polyhedron. It is common that a + marching cubes algorithm creates iso-surfaces with a fraction of very + small sub-complexes (e.g. small isolated tetrahedra). + + These can be for instance be small tetrahedra/polyhedra about the + center of a voxel of the support grid on which marching cubes operates. + When these objects are small, it is possible that they contain no ion; + especially when considering that delocalization procedures smoothen + the positions of the ions. Although these small objects are interesting + from a numerical point of view, scientists may argue they are not worth + to be reported: + Physically a microstructural feature should contain at least a few + atoms to become relevant. Therefore, paraprobe-nanochem by default + does not report closed objects which bound not at least one ion. + + + + + Specifies if the tool should report properties of each closed + polyhedron, such as volume and other details. + + + + + Specifies if the tool should report for each closed polyhedron an + approximately optimal bounding box fitted to all triangles of the + surface mesh of the object and ion positions inside or on the + surface of the mesh. + This bounding box informs about the closed object's shape + (aspect ratios). + + + + + Specifies if the tool should report for each closed polyhedron + all evaporation IDs of those ions which lie inside or on the + boundary of the polyhedron. This information can be used e.g. + in the paraprobe-intersector tool to infer if two objects share + common ions, which can be interpreted as an argument to assume + that the two objects intersect. + + Users should be aware that two arbitrarily closed polyhedra + in three-dimensional space can intersect but not share a common ion. + In fact, the volume bounded by the polyhedron has sharp edges. + When taking two objects, an edge of one object may for instance + pierce into the surface of another object. In this case the + objects partially overlap / intersect volumetrically; + however this piercing might be so small or happening in the volume + between two ion positions and thus sharing ions is a sufficient + but not a necessary condition for object intersections. + + Paraprobe-intersector implements a rigorous alternative to handle + such intersections using a tetrahedralization of closed objects. + However, in many practical cases, we found through examples that there + are polyhedra (especially when they are non-convex and have almost + point-like) connected channels, where tetrahedralization libraries + have challenges dealing with. In this case checking intersections + via shared_ions is a more practical alternative. + + + + + Specifies if the tool should report if a (closed) object has + contact with the edge of the dataset. For this the tool currently + inspects if the shortest distance between the set of triangles of the + surface mesh and the triangles of the edge model is larger than the + edge_threshold. If this is the case, the object is assumed to be + deeply embedded in the interior of the dataset. Otherwise, the object + is considered to have an edge contact, i.e. it is likely affected + by the fact that the dataset is finite. + + + + + Specifies if the tool should analyze a doppelganger/proxy mesh for + each cluster of triangles whose combinatorial analysis according + to has_object showed that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, + and fairing operations. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In most cases objects, + like precipitates in atom probe end up as open objects because + they have been clipped by the edge of the dataset. Using a proxy is + then a strategy to still be able to account for these objects. + Nevertheless users should make themselves familiar with the + potential consequences and biases which this can introduce + into the analysis. + + + + + Like has_object_geometry but for the proxies. + + + + + Like has_object_properties but for the proxies. + + + + + Like has_object_obb but for the proxies. + + + + + Like has_object_ions but for the proxies. + + + + + Like has_object_edge_contact but for the proxies. + + + + + Specifies if the tool should report for each closed object a + (cylindrical) region of interest placed, centered, and align + with the local normal for each triangle of the object. + + + + + Specifies if the tool should report for each ROI that was placed + at a triangle of each object if this ROI intersects the edge of + the dataset. Currently paraprobe-nanochem supports cylindrical + ROIs. A possible intersection of these with the edge of the + dataset, i.e. the triangulated surface mesh model for the edge + is performed. This test checks if the cylinder intersects with + a triangle of the surface mesh. If this is the case, the ROI is + assumed to make edge contact, else, the ROI is assumed to have + no edge contact. + + This approach does not work if the ROI would be completely + outside the dataset. Also in this case there would be + no intersection. For atom probe this case is practically + irrelevant because for such a ROI there would also be no ion + laying inside the ROI. Clearly it has thus to be assumed that + the edge model culls the entire dataset. Instead, if one would + cut a portion of the dataset, compute an edge model for this + point cloud, it might make sense to place a ROI but in this + case the edge contact detection is not expected to work properly. + + + + + + Analyses of interfacial excess. + + + + Interfacial excess computations are performed for local regions-of-interests + (ROIs) at selected facets or interface patch. + For instance many scientist compute the interfacial excess for + selected triangle facets of a created iso-surface. In this case, + computed iso-surfaces of paraprobe could be used. An example are triangle + facet sets about closed polyhedra, for instance to compute interfacial + excess related to phase boundaries of second-phase precipitates. + + Another example are free-standing triangle patches of the iso- + surfaces which paraprobe creates. These could be characterized + for interfacial excess. The sub-routines during iso-surface + computations already include a procedure to automatically align + local triangle normals based on the gradients of e.g. composition + fields. In this case, these triangulated surface patches + could also be used as a source for computing interfacial + excess. + + Often scientists face situations, though, in which there is no + immediately evident composition gradient across the interface + (grain or phase boundary) and orientation information about the + adjoining crystal is neither available nor reliable enough. + + In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method + to manually place control points and run an automated tessellation-based + algorithm to create a triangulated surface patch, i.e. a model of the + location of the interface. In a post-processing step this triangle + set can then be used to compute again interfacial excess in an + automated manner by placing ROIs and aligning them with + consistently precomputed triangle normals. + + A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ + They used first a deep-learning method to locate planar triangulated + grain boundary patches. These are eventually processed further + with manual editing of the mesh via tools like Blender. + Once the user is satisfied with the mesh, the computations of interfacial + excess reduce again to an automated placing of ROIs, computations + of the distributing of ions to respective ROIs and + reporting the findings via plotting. + + Yet another approach for constructing an triangulated surface patch + of an interface is to use point cloud processing methods which have + been proposed in the laser-scanning, geoinformatics, and CAD community. + Different computational geometry methods are available for fitting + a parameterized surface to a set of points, using e.g. non-uniform + rational B-splines (NURBS) and triangulating these according + to prescribed mesh quality demands. + + The advantage of these methods is that they can be automated and + pick up curved interface segments. The disadvantage is their often + strong sensitivity to parameterization. As a result also such methods + can be post-processed to yield a triangulated surface patch, + and thus enable to run again automated ROI placement methods. + For example like these which were explored for the use case of + iso-surfaces with closed objects and free-standing + surface patches that delineate regions of the dataset with a + pronounced composition gradient normal to the interface. + + This summary of the situations which atom probers can face when + requesting for interfacial excess computations, substantiates there + exists a common set of settings which can describe all of these methods + and, specifically, as here exemplified, the automated placing + and alignment functionalities for ROIs that is an important + step all these workflows. + + Specifically, paraprobe-nanochem operates on an already existent + triangle set. + + + + + + + + + The interface model is the result of a previous (set of) processing + steps as a result of which the user has created a triangulated + surface mesh (or a set of, eventually connected such meshes). + These interface models are useful, if not required, in cases when + there is no other independent approach to locate an interface. + + These are cases when insufficient crystallographic latent + information is available and also no consistent concentration + gradient detectable across the interface. It is then the users' + responsibility to deliver a triangle mesh of the interface model. + + + + Filename to HDF5 file which contain vertex coordinates, facet indices, + facet unit normals. The user is responsible for the triangle + and winding order to be consistent. + Input is expected as a matrix of the coordinates for all disjoint + vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. + Input is expected to include also a matrix of facet indices + referring to these disjoint vertices. This matrix should be a + (Nfacets, 3)-shaped array of NX_UINT. Further required input + is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit + normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed + vertex unit normals. Vertex indices need to start at zero and + must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data." + + + + + + Absolute HDF5 path to the dataset which specifies the + array of vertex positions. + + + + + Absolute HDF5 path to the dataset which specifies the + array of facet indices. + + + + + Absolute HDF5 path to the dataset which specifies the + array of facet signed unit normals. + + + + + Absolute HDF5 path to the dataset which specifies the + array of vertex signed unit normals. + + Users should be aware that triangulated surface meshes are + only approximations to a given complex, eventually curved shape. + Consequently, computations of normals show differences between + the vertex and facet normals. Vertex normals have to be + interpolated from normals of neighboring facets. Consequently, + these normals are affected by the underlying parameterization + and curvature estimation algorithms, irrespective of how + contributions from neighboring facets are weighted. By contrast, + facet normals are clearly defined by the associated triangle. + Their disadvantage is that they the normal field has discontinuities + at the edges. In general the coarser an object is triangulated + the more significant the difference becomes between computations + based on facet or vertex normals. + Paraprobe-nanochem works with facet normals as it can use + parts of the numerical performance gained by using cutting + edge libraries to work rather with finer meshes. + + + + + + + + Create a simple principle component analysis (PCA) to mesh a + free-standing interface patch through a point cloud of decorating solutes. + These models can be useful for quantification of Gibbsian + interfacial excess for interfaces where iso-surface based methods + may fail or closed objects from iso-surfaces are not desired or + when e.g. there are no substantial or consistently oriented + concentration gradients across the interface patch. + + The interface_meshing functionality of paraprobe-nanochem can be useful + when there is also insufficient latent crystallographic information + available that could otherwise support modelling the interface, + via e.g. ion density traces in field-desorption maps, as were used and + discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ + or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ + + It is noteworthy that the method here used is conceptually very similar + in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ + Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. + However, both of these previous works neither discuss in detail + nor implement inspection functionalities which enable a detection of + potential geometric inconsistencies or self-interactions of the + resulting DCOM mesh. This is what paraprobe-nanochem implements + via the Computational Geometry Algorithms Library. + + + + Method how to initialize the PCA: + + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. + + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ + to create a control_point_file which can be parsed by paraprobe-parmsetup + to match the here required formatting in control_points. + + + + + + + + + The name of the control point file to use. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + X, Y, Z coordinates of disjoint control point read from + an HDF5 file named according to control_point_file. + + + + + + + + + Method used for identifying and refining the location of the + interface. Currently, paraprobe-nanochem implements a PCA followed + by an iterative loop of isotropic mesh refinement and DCOM step(s), + paired with self-intersection detection in a more robust + implementation. + + + + + + + + Specify the types of those ions which decorate the interface and + can thus be assumed as markers for locating the interface and + refining its local curvature. + + + + Array of iontypes to filter. The list is interpreted as a whitelist, + i.e. ions of these types are considered the decorating species (solutes). + + + + + + + + + How many times should the DCOM and mesh refinement be applied? + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. + + + + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within + which the DCOM algorithm decides for each vertex how the vertex will + be eventually relocated. The larger the DCOM radius is relative to + the target_edge_length the more likely it is that vertices will be + relocated so substantially that eventually triangle self-intersections + can occur. + + + + + + + + Array of integers which specify for each DCOM step how many times + the mesh should be iteratively smoothened. + + Users should be aware the three array target_edge_length, + target_dcom_radius, and target_smoothing_step are interpreted in the + same sequence, i.e. the zeroth entry of each array specifies the + values to be used in the first DCOM iteration. The first entry of + each array those for the second DCOM iteration and so on and so forth. + + + + + + + + + Functionalities for placing regions-of-interest (ROIs) in the dataset + or at specific microstructural features to characterize composition + profiles and cumulated profiles for quantification of interfacial excess. + Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed + across the triangulated surface of a user-defined mesh. + ROIs are placed at the barycenter of the triangular facet. + + The tool can be instructed to orient the profile for each ROIs with + the positive normal of the triangle facet normals. Profiles are + computed for each ROI and facet triangle. The code will test which + ROIs are completely embedded in the dataset. + Specifically, in this test the tool evaluates if the ROI cuts at least + one triangle of the triangulated surface mesh of the edge of the dataset. + If this is the case the ROI will be considered close to the edge + (of the dataset) and not analyzed further; else the ROI will be + processed further. + Users should be aware that the latter intersection analysis is strictly + speaking not a volumetric intersection analysis as such one is much + more involved because the edge model can be a closed non-convex polyhedron + in which case one would have to test robustly if the cylinder piercing + or laying completely inside the polyhedron. For this the polyhedron has + to be tessellated into convex polyhedra as otherwise tests like the + Gilbert-Johnson-Keerthi algorithm would not be applicable. + + Specifically, the tool computes atomically decomposed profiles. + This means molecular ions are split into atoms/isotopes with respective + multiplicity. As an example an H3O+ molecular ion contains three + hydrogen and one oxygen atom respectively. The tool then evaluates + how many ions are located inside the ROI or on the surface of the + ROI respectively. All atom types and the unranged ions are distinguished. + As a result, the analyses yield for each ROI a set of sorted lists of + signed distance values. Currently, the distance is the projected + distance of the ion position to the barycenter of the triangle + and triangle plane. + + This will return a one-dimensional profile. Post-processing the set + of atom-type-specific profiles into cumulated profiles enable the + classical Krakauer/Seidman-style interfacial excess analyses. + Furthermore, the tool can be instructed to compute for each + (or a selected sub-set of facet) a set of differently oriented profiles. + + + + The feature mesh enables the injection of previously computed triangle + soup or mesh data. Such a mesh can be the model for a grain- or phase + boundary patch (from e.g. interface_meshing) jobs. + + + + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the feature. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details consistently oriented facet + normals of the facets. + + + + + + The tool enables to inject precomputed distance information for each + point which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains ion distances. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically contains + these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + Which type of distance should be reported for the profile. + + + + + + + + In which directions should the tool probe for each ROI. + + + + + + + + For each ROI, how high (projected on the cylinder axis) + should the cylindrical ROI be. + + + + + For each ROI, how wide (radius) should the cylindrical ROI be. + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml new file mode 100644 index 0000000000..97056a3dc0 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -0,0 +1,270 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of isotopes to consider as building blocks for searching + molecular ions. + + + + + The number of compositions to consider for molecular ion search tasks. + + + + + Configuration/settings of a paraprobe-ranger software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. + + + + + How many molecular_ion_search processes should + the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A list of pairs of number of protons and either the value 0 (per row) + or the mass number for all those isotopes which are assumed present + in a virtual specimen. + The purpose of this field is to compute also composition-weighted + products to yield a simple estimation which could potentially help + scientists to judge if certain molecular ions are to be expected. + The corresponding setting store_composition_weighted_product should be + activated. + + + + + + + + + A list of atomic (at.-%) ! percent values for the composition of each + isotope in the virtual specimen following the sequence of + assumed_composition_isotopes. + + + + + + + + A list of pairs of number of protons and mass number for all isotopes + to consider that can be composed into (molecular) ions, during the + recursive molecular_ion_search. + + + + + + + + + The mass-to-charge-state ratio interval in which + all molecular ions are searched. + + + + + + + + The maximum charge that a molecular ion should have. + + + + + The maximum number of isotopes of which the molecular ion + should be composed. Currently this must not be larger than 32. + + Users should be warned that the larger the maximum_charge and + especially the larger the maximum_number_of_isotopes is chosen, + the eventually orders of magnitude more costly the search becomes. + + This is because paraprobe-ranger computes really all (at least) + theoretically possible combinations that would have likely a + mass-to-charge-state ratio in the specified mass_to_charge_interval. + It is the challenge in atom probe to judge which of these (molecular) + ions are feasible and also practically possible. This tool does not + answer this question. + + Namely, which specific molecular ion will evaporate, remain stable + during flight and becomes detected is a complicated and in many cases + not yet in detail understood phenomenon. The ab-initio conditions + before and during launch, the local environment, arrangement and field + as well as the flight phase in an evacuated but not analysis chamber + with a complex electrical field, eventual laser pulsing in place, + temperature and remaining atoms or molecules all can have an effect + which iontypes are really physically evaporating and detected. + + + + + Report the accumulated atomic mass from each isotope building the ion. + Accounts for each identified ion. + Relatistic effects are not accounted for. + + + + + Report the product of the natural abundances from each isotope building + the ion. Accounts for each identified ion. + + The value zero indicates it is not possible to build such molecular ion + from nuclids which are all observationally stable. + Very small values can give an idea/about how likely such a molecular ion + is expected to form assuming equal probabilities. + + However in atom probe experiments this product has to be modified + by the (spatially-correlated) local composition in the region from + which the ions launch because the formation of a molecular ion depends + as summarized under maximum_number_of_isotopes on the specific + quantum-mechanical configuration and field state upon launch + or/and (early state) of flight respectively. + We are aware that this modified product can have a substantially + different value than the natural_abundance_product. + + Natural abundancies folded with the estimated compositions of the + specimen can differ by orders of magnitude. + + + + + Report the product of the composition from each isotope building the + ion. This sets strong constraints on the molecular ions which are + expected to have at all a noteworthy product value. + It should not be forgotten though the computation relies on assumptions: + + * The composition is homogeneous within the virtual specimen. + * It is a priori know which nuclids the specimen is build of. + + + + + Report the charge state of the ions. + + + + + Report if identified ions should be characterized + wrt to their number of disjoint isotopes. + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml new file mode 100644 index 0000000000..6c827ed70b --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -0,0 +1,227 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of alpha values (and offset values) to probe. + + + + + Configuration/settings of a paraprobe-surfacer software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + For now a support field for the tool to identify how many individual + analyses the tool should executed as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies the method that is used to preprocess the point cloud. + The main purpose of this setting is to specify whether the point + cloud should be segmented or not during the preprocessing + to identify which points are more likely lying close to the edge + of the point cloud. These points could be more relevant than the + interior points for certain alpha-shape constructions. + + By default no such filtering is used during pre-processing. + By contrast, the option kuehbach activates a preprocessing + during which a Hoshen-Kopelman percolation analysis is used + to identify which points are closer to the edge of the dataset. + This can reduce the number of points in the alpha-shape + computation and thus improve performance substantially. + Details about the methods are reported in + `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. + + + + + + + + + When using the kuehbach preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. + + + + + Specifies which method to use to define the alpha value. + By default, the tool uses a fast specialized algorithm for + computing only the convex hull. + + The value smallest_solid instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value cgal_optimal instructs the library to choose a value + which the library considers as an optimal value. Details are + define in the respective section of the CGAL library on 3D alpha + shapes. + + The value set_of_values instructs to compute a list of + alpha-shapes for the specified alpha-values. + + The value set_of_alpha_wrappings instructs the library to generate + a set of so-called alpha wrappings. These are a method + which is similar to alpha shapes but provide additional guarantees + though such as watertightness and proximity constraints on the + resulting wrapping. + + + + + + + + + + + + Array of alpha values to use when alpha_value_choice is set_of_values + or when alpha_value_choice is set_of_alpha_wrappings. + + + + + + + + Array of offset values to use when alpha_value_choice is + set_of_alpha_wrappings. The array of alpha_values and offset_values + define a sequence of (alpha and offset value). + + + + + + + + Specifies if the tool should compute the set of exterior triangle + facets for each alpha complex (for convex hull, alpha shapes, and wrappings) + + + + + Specifies if the tool should check if the alpha complex of exterior + triangular facets is a closed polyhedron. + + + + + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml new file mode 100644 index 0000000000..56694ac64a --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -0,0 +1,188 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration/settings of a paraprobe-tessellator software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many individual analyses should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distance information for + each point which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + Users are responsible this file and referred to dataset under + dataset_name have an ion_distance value for each ion. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional layer of + reproducibility. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + + Specifies for which points the tool will compute the tessellation. + By default, a Voronoi tessellation is computed for all ions in the + filtered point cloud. + + + + + + + + Specifies if the tool should report the volume of each cell. + + + + + Specifies if the tool should report the first-order neighbors of each cell. + + + + + Specifies if the tool should report the facets and vertices of each cell. + + + + + Specifies if the tool should report if the cell makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + by the presence of the boundary. + + + + + Maximum distance for which cells are eroded. + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml new file mode 100644 index 0000000000..0641b5af8c --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration/settings of a paraprobe-transcoder software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + + + The absolute path and name of the vendor or community file from which + to read the reconstructed ion positions. Currently POS, ePOS, and APT + files from APSuite are supported. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + + + The absolute path and name of the vendor or community file from which + to read the ranging definitions, i.e. how to map mass-to-charge-state + ratios on iontypes. Currently RRNG and RNG files are supported. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml new file mode 100644 index 0000000000..d5c5d425ad --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml @@ -0,0 +1,293 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The maximum number of atoms per molecular ion type. + + + + + Results of a paraprobe-ranger software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which used. + fields should be prefixed with a prefix taken from an + enumeration which details the individual coordinate systems: + + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on none, the + ion is considered of the default unknown type with a 0 as its + respective value in the iontypes array. + + + + + + + The iontype ID for each ion in the + order of the evaporation sequence ID. + + + + + + + + + Paraprobe-ranger performs a combinatorial search over + all possible or a reduced set of nuclids to identify + into which ions these can be composed. + + + + The main result is the list of molecular ions, here formatted + according to the definitions of a set of isotope_vectors + as detailed in :ref:`NXion`. + + + + + + + + + The mass-to-charge-state ratio of each molecular ion + without considering relativistic or quantum effects. + + + + + + + + The mass of each molecular ion without + considering relativistic or quantum effects. + + + + + + + + The charge_state of each molecular ion. + + + + + + + + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + + + + + + + + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + + + + + + + + The number of disjoint nuclids for each molecular ion. + + + + + + + + The number of nuclids for each molecular ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml new file mode 100644 index 0000000000..abd732d3fe --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -0,0 +1,209 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Results of a paraprobe-transcoder software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which used. + fields should be prefixed with a prefix taken from an + enumeration which details the individual coordinate systems: + + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + Paraprobe-transcoder prepares the data in POS, ePOS, APT files from + APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can + be used with the tools of the paraprobe-toolbox. + + + + + + + + + + + This is the collection of iontypes distinguished. + The default unknown iontype always has to map to 0. + Its non-physical mass_to_charge_state_ratio is [0., 0.001] Da. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_spatial_filter.nxdl.xml b/contributed_definitions/NXapm_spatial_filter.nxdl.xml new file mode 100644 index 0000000000..e732a50b85 --- /dev/null +++ b/contributed_definitions/NXapm_spatial_filter.nxdl.xml @@ -0,0 +1,64 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of ellipsoids. + + + + + Number of hexahedra. + + + + + Number of cylinders. + + + + + Settings for a spatial filter to define a region-of-interest. + + By default the paraprobe processes the entire reconstructed dataset/point cloud. + If this filter is added, the user can specify which ions to include. + + + + Qualitative statement which specifies which spatial filtering with respective + geometric primitives or bitmask is used. These settings are possible: + + * entire_dataset, no filter is applied, the entire dataset is used. + * union_of_primitives, a filter with (rotated) geometric primitives. + All ions in or on the surface of the primitives are considered + while all other ions are ignored. + * bitmasked_points, a boolean array whose bits encode with 1 + which ions should be included. Those ions whose bit is set to 0 + will be excluded. Users of python can use the bitfield operations + of the numpy package to define such bitfields. + + Conditions: + In the case that windowing_method is it is possible to specify none + or all types of primitives (ellipsoids, cylinder, hexahedra). + In the first case the entire dataset is processed. + In the second case ions in the union of the specified primitives + will be processed if primitives are defined; if not the entire dataset + will be processed. + In the alternative case that windowing_method is bitmasked_points, + the bitmask has to be defined; otherwise the entire dataset is processed. + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_alpha_shape.nxdl.xml b/contributed_definitions/NXcg_alpha_shape.nxdl.xml new file mode 100644 index 0000000000..3cd4eda061 --- /dev/null +++ b/contributed_definitions/NXcg_alpha_shape.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the alpha shape, for now 2 or 3. + + + + + The number of edges. + + + + + The number of faces. + + + + + The number of cells. + + + + + Base class documenting an alpha shape or alpha wrapping to a primitive set. + + For details see: + + * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, + * https://dx.doi.org/10.1145/174462.156635 for 3D, + * https://dl.acm.org/doi/10.5555/871114 for weighted, and + * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap + + in CGAL, the Computational Geometry Algorithms Library. + As a starting point, we follow the conventions of the CGAL library. + + + + + + + + + + Specify which general type of alpha shape is computed. + Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. + Alpha_wrapping means meshes created using alpha wrapping procedures. + + + + + + + + + Specifically when computed with the CGAL, the mode specifies if singular + faces are removed (regularized) of the alpha complex. + + + + + + + + + The alpha, (radius of the alpha-sphere) parameter to be used for alpha + shapes and alpha wrappings. + + + + + The offset distance parameter to be used in addition to alpha + in the case of alpha_wrapping. + + + + + Point cloud for which the alpha shape or wrapping should be computed. + + + + + Triangle soup for which the alpha wrapping should be computed. + + + + + A meshed representation of the resulting shape. + + + + diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml new file mode 100644 index 0000000000..a9814005c0 --- /dev/null +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of cylinders or cones. + + + + + Set of cylinders or (truncated cones) in Euclidean space. + + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish members for explicit indexing. + + + + + + + + The geometric center of each member. + + + + + + + + + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. + + + + + + + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Interior volume of each cylinder + + + + + + + + Lateral surface area + + + + + + + + Area of the upper and the lower cap of each cylinder respectively. + + + + + + + + + Cap and lateral surface area for each cylinder. + + + + + + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml new file mode 100644 index 0000000000..ae4e52787a --- /dev/null +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -0,0 +1,112 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or + ellipsoids. + + + + + Set of (d-dimensional) ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 0000000000..6ca4653e14 --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,219 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Simple class for storing vertices and face lists for geometric primitives. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml new file mode 100644 index 0000000000..e469a9a695 --- /dev/null +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -0,0 +1,35 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Metadata and data about a geodesic mesh. + + People from geodesic/surveyors will likely have specific demands and + different views about what should be included in such a base class, given + that nested geodesic meshes are a key component of climate modelling tools. + For now we propose to use this base class as a container to organize metadata + and data related to geodesic meshes. + + Specifically an instance of this base class should detail the rule set how + how the geodesic (surface) mesh was instantiated as there are many + possibilities. A geodesic surface mesh is in this sense a triangulated + surface mesh with metadata. For additional details as an introduction + into the topic see e.g.: + + * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ + + Here, especially the section on subdivision schemes is relevant. + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml new file mode 100644 index 0000000000..b09543c532 --- /dev/null +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -0,0 +1,151 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the grid. + + + + + The cardinality or total number of cells/grid points. + + + + + Number of boundaries of the bounding box or primitive to the grid. + + + + + A d-dimensional grid of Wigner-Seitz cells in Euclidean space. + + Frequently convenient three-dimensional grids with cubic cells are used. + Exemplar applications are spectral-solver based crystal plasticity + and stencil methods like phase-field or cellular automata. + + + + + + + + + + + + + + + + + The symmetry of the lattice defining the shape of the unit cell. + + + + + + + + The unit cell dimensions using crystallographic notation. + + + + + + + + Number of unit cells along each of the d unit vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for cells. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish cells for explicit indexing. + + + + + + + + Position of each cell in Euclidean space. + + + + + + + + + Coordinate of each cell with respect to the discrete grid. + + + + + + + + + A tight bounding box or sphere or bounding primitive about the grid. + + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml new file mode 100644 index 0000000000..5844ab2447 --- /dev/null +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -0,0 +1,147 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of faces. + + + + + The number of half-edges. + + + + + Half-edge data structure for polygon meshes in Euclidean space. + + Such a data structure can be used to efficiently circulate around faces + and iterate over vertices of a planar graph. + + + + + + + + In this half-edge data structure vertex identifiers start at 1. + Vertices are identified with consecutive integers up to number_of_vertices. + This field can be used to document which constant integer has to be + added to another set of vertex_identifier to assure that these other + identifiers also start at 1. + + + + + In this half-edge data structure face identifiers start at 1. + Faces are identified with consecutive integers up to number_of_faces. + This field can be used to document which constant integer has to be + added to another set of face_identifier to assure that these other + identifiers also start at 1. + + The face identifier zero is reserved for the NULL face ! + + + + + In this half-edge data structure half-edge identifiers start at 1. + Half-edges are identified with consecutive integers up to number_of_half_edges. + This field can be used to document which constant integer has to be + added to another set of half_edge_identifier to assure that these other + identifiers also start at 1. + + + + + The position of the vertices. + + + + + + + + + Identifier of the incident half-edge. + + + + + + + + Identifier of the (starting)/associated half-edge of the face. + + + + + + + + The identifier of the vertex from which this half-edge is outwards pointing. + + + + + + + + Identifier of the associated oppositely pointing half-edge. + + + + + + + + If the half-edge is a boundary half-edge the + incident face identifier is NULL, i.e. 0. + + + + + + + + Identifier of the next half-edge. + + + + + + + + Identifier of the previous half-edge. + + + + + + + + Users are referred to the literature for the background of L. Weinberg's + work about topological characterization of planar graphs: + + * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ + * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ + * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ + + and how this work can e.g. be applied in space-filling tessellations + of microstructural objects like crystals/grains. + + + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 0000000000..07ac124084 --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,207 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + A set of hexahedra in 3D Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_isocontour.nxdl.xml b/contributed_definitions/NXcg_isocontour.nxdl.xml new file mode 100644 index 0000000000..04db89a8ad --- /dev/null +++ b/contributed_definitions/NXcg_isocontour.nxdl.xml @@ -0,0 +1,43 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the description. + + + + + Data/metadata of isocontouring/phase-fields in discretized Euclidean space. + + Iso-contouring algorithms such as MarchingCubes and others are frequently + used to segment d-dimensional regions into regions where intensities are + lower or higher than a threshold value, the so-called isovalue. + + Frequently in computational materials science phase-field methods are + used which generate data on discretized grids. Isocontour algorithms + are often used in such context to pinpoint the locations of microstructural + features from this implicit phase-field-variable-based description. + + One of the key intentions of this base class is to provide a starting point + for scientists from the phase-field community (condensed matter physicists, + and materials engineers) to incentivize that also phase-field simulation + data could be described with NeXus, provided base classes such as the this one + get further extend according to the liking of the phase-field community. + + + + + The discretized grid on which the iso-contour algorithm operates. + + + + + The threshold or iso-contour value. + + + diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml new file mode 100644 index 0000000000..354913182c --- /dev/null +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -0,0 +1,50 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Metadata and data for a specifically used marching cubes algorithm. + + Documenting which specific version was used can help to understand how robust + the results are with respect to the topology of the triangulation. + + + + Reference/link to and/or details of the grid on which a specific + marching cubes algorithm implementation is operating. + + + + + Reference to the specific implementation of marching cubes used. + + See for example the following papers for details about how to identify a + DOI which specifies the implementation used: + + * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ + * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ + + The value placed here should be a DOI. If there are no specific DOI or + details write not_further_specified, or give at least a free-text + description. + + + + + Commercial or otherwise given name to the program which was used. + + + + Program 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. + + + + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 0000000000..17aee16ee4 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,156 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + A set of parallelograms in 2D Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + Disentangled representations of the mesh of specific parallelograms. + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 0000000000..30454ada3c --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,77 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + A set of points or point-like objects in d-dimensional Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 0000000000..55a95b5e1c --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,135 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + The total number of vertices when visiting every polygon. + + + + + A set of d-dimensional polygons arranged in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 0000000000..5e5d2efb1e --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,150 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + A set of polyhedra in 3D Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml new file mode 100644 index 0000000000..8e8d889f1e --- /dev/null +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -0,0 +1,153 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of polylines. + + + + + The number of vertices, supporting the polylines. + + + + + The total number of vertices traversed when visiting every polyline. + + + + + A set of polylines in d-dimensional Euclidean space. + + Each polyline is built from a sequence of vertices (points with identifiers). + Each polyline must have a start and an end point. + The sequence describes the positive traversal along the polyline when walking + from the start vertex to the end/last vertex. + + + + + + The total number of vertices, irrespective of their eventual uniqueness, + i.e. the total number of vertices that have to be visited when walking + along each polyline. + + + + + Array which specifies of how many vertices each polyline is built. + The number of vertices represent the total number of vertices for + each polyline, irrespectively whether vertices are shared or not. + See the docstring for polylines for further details about how + a set with different polyline members should be stored. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and polyline data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + polylines. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polylines for explicit indexing. + + + + + + + + Positions of the vertices which support the members of the polyline set. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + If true indicates that the vertices are all placed at different + positions and have different identifiers, i.e. no points overlap + or are counted twice. + + + + + Sequence of vertex identifiers which describe each polyline. + + A trivial example is a set with two polylines with three vertices each. + If the polylines meet in a junction, say the second vertex is shared + and marking the junction between the two polylines, it is possible that + there are only five unique positions suggesting five unique vertices. + + A non-trivial example is a set with several polylines, each of which with + eventually different number of vertices. The array stores the vertex + identifiers in the order how the polylines are visited: + + The first entry is the identifier of the start vertex of the first polyline, + followed by the second vertex of the first polyline, until the last vertex + of the polyline. Thereafter, the start vertex of the second polyline, and + so on and so forth. Using the (cumulated) counts in number_of_vertices, + the vertices of the n-th polyline can be accessed on the following + array index interval: + :math:`$[\sum_i = 0}^{i = N-1}, \sum_{i=0}^{i=N}]$`. + + + + + + + + The length of each polyline. + + + + + + + + If true specifies that a polyline is closed, i.e. + its end point is connected to the start point. + + + + + + + + diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml new file mode 100644 index 0000000000..cdfae6d912 --- /dev/null +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -0,0 +1,16 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A base class to hold geometric primitives. + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 0000000000..b36035a2b4 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Set of d-dimensional circles/spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 0000000000..013996c9bf --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + A set of tetrahedra (possibly differently sized) in 3D Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 0000000000..cb28371c10 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,107 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + A set of d-dimensional triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml new file mode 100644 index 0000000000..923198343e --- /dev/null +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -0,0 +1,22 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A mesh of triangles. + + The mesh may be self-intersecting and have holes but the + triangles must not be degenerated. + + + + + A graph-based approach to describe the mesh when it is also desired + to perform topological processing or analyses on the mesh. + + + diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml new file mode 100644 index 0000000000..bea52e9d29 --- /dev/null +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -0,0 +1,46 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of unit normals. + + + + + A set of (oriented) unit normal vectors. + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml new file mode 100644 index 0000000000..475b21e477 --- /dev/null +++ b/contributed_definitions/NXclustering.nxdl.xml @@ -0,0 +1,100 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of numeral labels per object. + + + + + Number of categorical labels per object. + + + + + Total number of clusters detected. + + + + + Metadata to the results of a clustering analysis. + + Clustering algorithms are routine tools to segment a set of objects/primitives + into groups, objects of different type. A plethora of algorithms have been + proposed for geometric primitives as objects, such as points, triangles, + or (abstract) objects. + + This base class considers metadata and results of one clustering + applied to a set in which objects are either categorized as noise + or belonging to a cluster, specifically here only one cluster. + + + + How many numeric labels does each object have. + + + + + How many categorical labels does each object have. + + + + + Reference to a set of objects investigated in a cluster analysis. + Objects must have clear integer identifier. + + + + + Reference to numeric attribute data for each object. + + + + + Reference to categorical attribute data for each object. + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + + + + + Total number of objects categorized as unassigned. + + + + + Total number of objects categorized as noise. + + + + + Total number of clusters (excluding noise and unassigned). + + + + + Number of objects associated to each cluster. The labels are implicit, + meaning the zeroth/first entry in the array belongs to the first cluster, + the second entry to the second cluster and so on and so forth. + The first cluster has the value of identifier_offset as its identifier. + The second cluster has identifier_offset + 1, and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml new file mode 100644 index 0000000000..75c67c6e89 --- /dev/null +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -0,0 +1,58 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster 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. + + + + + 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/NXcs_cpu.nxdl.xml b/contributed_definitions/NXcs_cpu.nxdl.xml new file mode 100644 index 0000000000..fbf57956e0 --- /dev/null +++ b/contributed_definitions/NXcs_cpu.nxdl.xml @@ -0,0 +1,18 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class representing a central processing unit (CPU) of a computer. + + + + Given name of the CPU. Users should be as specific as possible. + + + + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml new file mode 100644 index 0000000000..f3486dab78 --- /dev/null +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -0,0 +1,83 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + A base class to represent a description for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml new file mode 100644 index 0000000000..538791d1a9 --- /dev/null +++ b/contributed_definitions/NXcs_gpu.nxdl.xml @@ -0,0 +1,18 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class representing a graphic processing unit (GPU) of a computer. + + + + Given name of the GPU. Users should be as specific as possible. + + + + diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml new file mode 100644 index 0000000000..c15e9d5526 --- /dev/null +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A component of an input/output sub-system which can store binary data. + + + + Qualifier for the type of storage medium used. + + + + + + + + + + Total amount of data which the medium can hold. + + + + + Given name to the I/O unit. + + + + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml new file mode 100644 index 0000000000..1321f6ec41 --- /dev/null +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -0,0 +1,13 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class for an input/output sub-system of a computer. + + + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml new file mode 100644 index 0000000000..bd0b7fa406 --- /dev/null +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -0,0 +1,17 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class representing a main memory sub-system of a computer. + + + + How much physical memory does the system provide. + + + diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml new file mode 100644 index 0000000000..bff1df5322 --- /dev/null +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -0,0 +1,61 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A base class to represent metadata of an pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml new file mode 100644 index 0000000000..11983320ee --- /dev/null +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -0,0 +1,114 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Storage for performance/profiling data which an app collects at runtime. + + 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 + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and working together with + eventually multiple computers, especially when these have to exchange + information across a network. + + 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. + + 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 + 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. + + This base class cannot and should not replace these specific solutions. + 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 + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + 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. + + + + + 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. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + + + + + Qualifier with how many nominal threads were accessible to the app at + runtime. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml new file mode 100644 index 0000000000..224fd00b3f --- /dev/null +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,74 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + A record of profiling data as measured via e.g. sampling. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + 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. + 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. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index d7567ab3c9..9bbd85c4cc 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -5,55 +5,65 @@ Characterization and session with one sample in an electron microscope. **The idea and aim of NXem**: - Electron microscopes (EM), whether it be a scanning electron microscope (SEM) - or a transmission electron microscope (TEM), are versatile tools for preparing - and characterizing samples and specimens. The term specimen is here understood - as a synonym for a sample. A specimen is a physical portion of material that - is studied/characterize in the microscope session, eventually in different - places on the specimen surface. + Electron microscopy (EM), whether it be with scanning electron microscope (SEM) + or transmission electron microscope (TEM) instruments, are versatile tools for + preparing and characterizing samples and specimens. The term specimen is considered + a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating either the surface layers or shining through thin specimens. These places are named regions of interest (ROIs). Fundamentally, an EM is an electron accelerator. Experimentalists use an EM in sessions during which they characterize as well as prepare specimens. This application definition describes data and metadata about processes and - characterization tasks applied to one specimen. + characterization tasks applied to one specimen. The application definition + focuses on the usage of EM in materials research. The application definition + design makes it in principle applicable also in cryo-EM on biomaterials. Multiple specimens have to be described with multiple NXentry instances. There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of - (staff) scientists. These users perform analyses for other users as a service - task. Oftentimes, though, and especially for cutting-edge instruments, - the scientists and their team guide the process while operating the - microscope. Oftentimes the scientists operate the instrument themselves + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process maybe even operating + the microscope. Oftentimes the scientists operate the instrument themselves either on-site or remotely and can ask technicians for support. In all cases, these people are considered users. Users might have different roles though. - The rational behind a common EM schema rather than separate SEM or TEM - schemata are primarily the key similarities of SEM and TEM instruments: - Both have electro-magnetic lenses. These lens may differ in design, alignment, - number, and level of corrected-for aberrations. As an obvious difference, - a TEM is used mainly to measure the transmitted electron beam. - This demands thinner specimens as in SEM but offers capabilities for probing - of additional physical mechanisms of electron-matter interaction. + The rational behind a common EM schema rather than making separate application + definitions for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is used mainly to measure the + transmitted electron beam. This calls for using a different lens setup and + relative placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to illuminate + through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. Compared to SEMs, TEMs have a different relative arrangement between the lenses and the specimen which is most obvious by the different relative arrangement of the objective lens versus the specimen. Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate though from the same set of - radiation/specimen interactions. Consequently, detectors can also be similar. + measure different types of signals that originate from the same set of + radiation/specimen interactions. Consequently, detectors can also be similar + if not exactly the same. + **An embracing schema instead of specific SEM or TEM schemes**: Given these physical and technical differences, different instruments have been developed. This led to a coexistence of two broad interacting communities: SEM and TEM users. From a data science perspective, we acknowledge that the more specific a research question is and the narrower - the addressed user base is which develops or uses schemata for - research data management with EM, the more understandable it is - that scientists of either community (or sub-community) ask for - method-specific schemata. + the addressed user base is which develops or uses schemes for research data + management (RDM) with EM, the more understandable it is that scientists of + either community (or sub-community) ask for method-specific schemes. Researchers who have a single (main) microscope of some vendor in their lab, may argue they need an NXem_vendor_name schema or an NXem_microscope_name or @@ -62,105 +72,120 @@ (X-rays, electrons) may argue they wish to be pragmatic and store only what is immediately relevant for their particular technique and research questions. In effect, they may advocate for method-specific - schemata such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - The development in the past has shown that these activities led to a zoo of - schemata and implementations of these into many data and file formats. - There is nothing which prevents the communities to make these schemata - open and interoperable. Open here means specifically not that all data are - compliant with/or use the schema and have to end up in the open-source domain. - There can be embargo periods first of all. Open means that the metadata and - associated schemata are documented in a manner that as many details as - possible are open in the sense that others can understand what the - (meta)data mean conceptually. - The `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ guide all - decisions how data and metadata should be stored. + schemes such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the development in the past has shown that these activities led to + a zoo of schemes and especially vocabulary in use with implementations of these + into many data and file formats. There is nothing which prevents the communities + to make these schemes open and interoperable. Open here means specifically not + that all data are compliant with/or use the schema and have to end up in the + open-source domain. There can be embargo periods first of all. + + Open means that the metadata and associated schemata are documented in a manner + that as many details as possible are open in the sense that others can understand + what the (meta)data mean conceptually. Instead of trying of maintain a zoo + of eventually difficult to make interoperable formats and schema we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different - schemata with associated representations of data and metadata in EM: - Each combination of schemata or an interoperable-made handshake between two + there is a key challenge and inconvenience with having many different + schemes with associated representations of data and metadata in EM: + Each combination of schemes or an interoperable-made handshake between two file formats or software packages has to be maintained by software developers. This counts especially when data should be processed interoperably between software packages. This brings two problems: Many software tools and parsers for the handshaking - between tools to maintain. This can result in usage of different terminology. - Which in turn results in representations and connections made between - different data representations and workflows that are not machine-actionable. + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - A common vocabulary can serve interoperability as developers of schemata - and scientists can take for instance then these terms as closely as possible. - Ideally, they specialize the application definition only for the few very + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemes and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very specific additional quantities of their instruments and techniques. This is better than reimplementing the wheel for descriptions of EM instruments. This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemata. + removes the necessity for having to maintain a very large number of schemes. - Aiming for more standardization, i.e. a lower number of schemata rather than + Aiming for more standardization, i.e. a lower number of schemes rather than a single standard for electron microscopy is a compromise that can serve academia as it enables the EM community to focus their software development - efforts on those schemata, on fixing and discussing them, and on harmonize + efforts on those schemes, on fixing and discussing them, and on harmonizing their common vocabulary. These activities can be specifically relevant also for vendors of EM hard- and software as it improves the longevity of certain - schema and thus can help to incentivize vendors to support the community with - implementing support for such schemata into their proprietary applications. + schema; and thus can help to incentivize vendors to support the community with + implementing support for such schemes into their proprietary applications. In effect, everybody can gain from this as it will likely reduce the cases in which scientists have to fix bugs in making their own tools compliant and interoperable with tools of their colleagues and the wider community. The here proposed NXem application definition offers modular components - (EM-research specific base classes) for using NeXus to define schemata for - electron microscopy research. Working towards a common vocabulary is a - community activity that profits from everybody reflecting in detail whether - certain terms they have used are not eventually conceptually similar if not - the same as what this application definition and its base classes provide. + (EM-research specific base classes) for defining schemes for EM research. + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. - We are happy for receiving your feedback. - - It is noteworthy to understand that (not only for) NeXus, schema differ + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemes differ already if at least one field is required in one version of the schema, - but it is set optional in another version. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemata can - become inconsistent. An application definition here serves as a contract - between a data provider and a data consumer. These two can be software tools - (like the vendor software to drive the instrument or a scientific software - for doing artificial intelligence with EM data). - Such changes of a schema lead to new versions. - - Tools like NeXus do not avoid or protect against inconsistencies; however - NeXus offers a mechanism and toolset, through which schemata can be - documented and defined. In effect, having an openly documented + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemes can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be software from specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions and strictly speaking an application definition can only be + really general if it does not make a single entry required, in which case however + it would also not offer much value as even empty datasets would be compliant. + + **Verification of constraints and conditions**: + Tools like NeXus so far do not avoid or protect against all such possible + inconsistencies; however NeXus offers a mechanism and toolset, through which + schemes can be documented and defined. In effect, having an openly documented (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable + not a sufficient step to take EM research on a route of machine-actionable and interoperable FAIR data. - A common vocabulary and a machine-actionable knowledge representation/engine - is also required. Essentially when the docstrings are no longer needed - but can be replaced by a connection to an automated tool which understands - what a specific field represents conceptually, EM data have become more - generally interoperable EM data. - This application definition takes a key step into this direction. + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + This application definition takes a key step towards standardization of EM data. It offers a controlled vocabulary and relation between concepts and data relevant for research with electron microscopes. To be most efficient and offering reusability, the application definition should be understood as a template that one should ideally use as is. This application definition - is called NXem. It can be considered a base for more specialized definitions - (ideally prefixed with NXem) *method*. + is called NXem. NXem can be considered a base for designing more specialized + definitions (ideally prefixed with NXem) *method*. **The use of NXem should be as follows:** Offspring application definitions should not remove groups but make - them optional or, even better, propose changes in the application definition. + them optional or, even better, propose changes in this NXem application definition. A particular challenge with electron microscopes as physical instruments are their dynamics. To make EM data understandable, repeatable, and eventually corresponding experiments reproducible in general requires a documentation of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: For most commercial systems there is a specific accessibility beyond which detailed settings like lens excitations and low-level hardware settings - may not be retrievable. + may not be retrievable as vendors also have a relevant interest in finding + a compromise between being open to their user and securing their business. EM experiments by design illuminate the specimen with electrons as a consequence of which the specimen changes if not may get destroyed. @@ -171,86 +196,96 @@ geometry of the lens system and its excitations during the course of the experiment, it is difficult to fully abstract the technical details of the hardware into a set of names for fields and groups that make for a compromise - between clarity and being vendor-agnostic. Settings of apertures are an - example where aperture modes are aliases behind which there is a set of - settings. These settings are difficult to retrieve, often undocumented in - detail. This serves users and makes EM experiments easier understandable and - conveniently executable for a broader user base. The opportunities for - application definitions to offer an abstraction layer are limited. + between clarity but being vendor-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + often undocumented in detail by vendors. This serves users and makes EM + experiments easier understandable and conveniently executable for a broad + user base. On the flipside these subtilities limit the opportunities for + making application definitions too general. Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - the application definition and base classes is that there are numerous + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous (technical) details about an EM which may warrant a very detailed technical disentangling of settings and reflection of numerous settings as deeply nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however at the cost of generality. + place to hold these nested representations; however as discussed + at the cost of generality. Which specific details matter for answering scientific research questions is a difficult question to answer by a single team of scientists, especially if the application definition is to speak for a number of vendors. What makes - it especially challenging if the application definition is expected to hold - all data that might be of relevance for future questions. + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. - We are skeptical if there is one representation that can fulfill all these - aims, while remaining at the same time approachable and executable by a large - number of scientists in a community. With this application definition we - would like to motivate the community to work towards such aim. While doing + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemes. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what are metadata in EM. While doing so we found that existent terminology can be encoded into a more controlled vocabulary. We have concluded that despite all these details of current EM research with SEM, TEM, and focused-ion beam instruments, there a clearly identifiable common components and generalizable settings of EM research use cases. + Therefore, **This application definition has the following components at the top-level:** - * Generic experimental details (timestamp, identifiers, name); + * Generic experimental details (time-zone-aware timestamp, identifiers, name); conceptually these are session details. A session at a microscope may involve the characterization of multiple specimens. For each specimen an instance of an (NXentry) is created. Details of the instrument have to be stored at least in an entry. Other entries should refer to these metadata via links to reduce redundancies. * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time stamp and report of the specific settings at that - point in time when the image was taken. The reason is that EMs can be - highly dynamic, be used to illuminate the specimen differently - or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? This can be the - collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set - of EBSD line scan and surface mappings in an SEM, or ion-beam-milling of a - specimen in preparation for an atom probe experiment. + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of NXevent_data_em have an own em_lab section. + The reason is that EMs can be highly dynamic, be used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. * NXmonitor; instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. Alternatively - NXevent_data_em instances can be used to store timestamp states of the - components, which is relevant to document the exact settings when images - and spectra were taken. + pertaining to specific components of the instrument. Alternatively, NXevent_data_em + instances can be used to store time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. * NXinstrument; conceptually this is a container to store arbitrary level of detail of the technical components of the microscope as a device and the lab in which - it is operated. + the microscope is operated. * NXuser; conceptually, this is a set with at least one NXuser instance which details who operated or performed the measurement. Additional NXusers can be referred to in an NXevent_data_em instance to store - individualized details who executed an event. + individualized details who executed an event of data acquisition or processing. * NXevent_data_em instances as an NXevent_data_em_set; each NXevent_data_em instance is a container to group specific details about the state of the microscope when a measurement was taken and relevant data and eventual processing steps were taken (on-the-fly). - * NXdata; a the top-level, conceptually, this is a place for documenting + * NXdata; at the top-level, conceptually, this is a place for documenting available default plottable data. A default plottable can be useful for research data management systems to show a visual representation of some aspect of the content of the EM session. - It is clear that what constitutes a useful default plot is a matter of - interpretation, somewhat of personal taste, and community standards. + Default plottables not intended to serve every possible analysis and + visualization demand but be a preview. We made this choice because what constitutes + a useful default plot is often a matter of interpretation, somewhat of personal taste, + and community standards. In effect, default plottables are case- and method-specific. - In effect, default plottables are case- and method-specific. Usually a session at a microscope is used to collect multiple signals and - images. Examples for possible default plottables could be an arbitrarily - taken: secondary, back-scattered, electron image, diffraction pattern, + images. Examples for possible default plottables could be arbitrarily + taken secondary, back-scattered, electron image, diffraction pattern, EELS spectra, composition, or orientation mappings to name but a few. **There are a few design choices to consider with sub-ordinate groups:** @@ -261,28 +296,28 @@ the data are stored. NeXus specifies only the data model, i.e. the terms and their relations. These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, file storage, or even other formats, although - HDF5 is the most commonly used. + HDF5 is often used. * Consumable results of EM characterization tasks are usually a sub-set of data artifacts, as there is not an infinite amount of possible electron/ion beam-specimen interactions. * Images of electron counts detected in specific operation modes (bright field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) - * Spectra (X-ray quanta or auger electron counts) - * These data are in virtually all cases a result of some numerical - processing. It makes sense to name them with a controlled vocabulary, + * Spectra (X-ray quanta or Auger electron counts) + * These data are in virtually all cases a result of some numerical processing. + It makes sense to name these data and processing tasks with a controlled vocabulary, e.g. SE (secondary electron), BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence) etc. A key question often asked with EM experiments is how the actual (meta)data should be stored (in memory or on disk). To this end the schema, here makes no specific assumptions, not even that all the fields/group of a schema instance - have to be stored into a single file. Instead, the schema specifies the - relations between metadata, constraints on how they should be formatted, what - they conceptually represent and which terms (controlled vocabulary) is - practical to store with the data. + have to be stored at all into a single file. Instead, the schema specifies the + relations between metadata, some of the constraints and conditions on how the data + should be formatted, what the data conceptually represent, and which terms + (controlled vocabulary) is practical to store to index specific quantities. In effect, the application definition is a graph which describes how - (meta)data are related to one another. + numerical data and (meta)data for EM research are related to one another. @@ -319,7 +354,7 @@ into this free-text description field. - + ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. If the application demands that time @@ -339,7 +374,7 @@ provide additional pieces of information. - + ISO 8601 time code with local time zone offset to UTC included when the microscope session ended. @@ -395,7 +430,7 @@ - + Contact information and eventually details of at least one person involved in the taking of the microscope session. This can be the @@ -409,8 +444,8 @@ - Name of the affiliation of the user at the point in time when the experiment was - performed. + Name of the affiliation of the user at the point in time + when the experiment was performed. @@ -418,25 +453,31 @@ Postal address of the affiliation. - + - Email address of the user at the point in time when the experiment was - performed. Writing the most permanently used email is recommended. + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. - Globally unique identifier of the user as offered by services like ORCID or - ResearcherID. + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. - (Business) (tele)phone number of the user at the point in time when the - experiment was performed. + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. - + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating @@ -451,34 +492,34 @@ - Name of the social media platform where the account under social_media_name is - registered. + Name of the social media platform where the account + under social_media_name is registered. - + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + - A qualifier whether the sample is a real one or a virtual one (in a computer - simulation) + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) - + - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially - the predecessor/origin from where the specimen was cut. + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. This field must not be used for an alias of the sample. - Instead, use short_title. + Instead, use short_title for this, more convenient alias name. In cases where multiple specimens have been loaded into the microscope the name has to identify the specific one, whose results are stored @@ -491,36 +532,43 @@ - Ideally, a reference to a (globally) unique persistent identifier, representing a data - artifact which documents ideally as many details of the material, its microstructure, - and its thermo-chemo-mechanical processing/preparation history as possible. + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. - The sample_history is the record what happened before the specimen was placed into the - microscope at the beginning of the session. + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. - In the case that such a detailed history of the sample/specimen is not available, use this field as - a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider - are the key steps and relevant information about the specimen, its material, microstructure, + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a sub-set + of the entire sample history, i.e. what you would consider are the key steps + and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state, and the details of the preparation. - Specific details about eventual physically-connected material like embedding resin should be - documented ideally also in the sample_history. If all fails, the description field - can be used but it is strongly discouraged because it leads to eventually non-machine-actionable + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly discouraged + because it leads to eventually non-machine-actionable data. - ISO 8601 time code with local time zone offset to UTC information when the specimen was prepared. + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. - Ideally report the end of the preparation, i.e. the last known time the measured specimen surface - was actively prepared. Usually this should be a part of the sample history, i.e. the sample - is imagined handed over for the analysis. At the point it enters the microscope the session starts. + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over for + the analysis. At the point it enters the microscope the session starts. - Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for - environmentally sensitive material such as hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. @@ -541,23 +589,41 @@ (Measured) sample thickness. The information is recorded to qualify if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. - Discouraged free-text field in case properly designed records for the - sample_history are not available. + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an NXinteraction_vol_em for + individual NXevent_data_em instances can provide a much better description + of the relevant details why one would otherwise ask to store the density + of the specimen. - + Hard link to a location in the hierarchy of the NeXus file where the data for default plotting are stored. - - + + + + Metadata and numerical data of the microscope and the lab in which it stands. @@ -599,12 +665,145 @@ Using GEOREF is preferred. - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. @@ -613,33 +812,53 @@ Different technologies are in use like CCD, scintillator, direct electron, CMOS, or image plate to name but a few. - - + Free text option to write further details about the detector. + + + + + + + + + + + + + + + + + + + + - A container to structure a set of NXevent_em instances. + A container to structure a set of NXevent_data_em instances. - An event is a time point/interval during which the microscope + An event is a time point/time interval during which the microscope was configured in a specific way and the microscope was used - to take a measurement. + to take a measurement. The microscope is considered stable during this + interval. - Each NXevent_em holds an acquisition task with the microscope. + Each NXevent_data_em instance holds an acquisition task with the microscope. For instance the capturing of a secondary electron, backscattered electron, diffraction image, or spectrum. - An NXevent_em_data instance holds specific details about how raw data - from a detector were processed into consumable data like images, spectra, + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed into consumable data like images, spectra, etc. These on-the-fly data processing tasks are usually performed by the control software, eventually realized with custom scripts. - Furthermore, NXevent_em_state instances can document specific values + Furthermore, NXevent_dat_em instances can document specific values and settings of the microscope during the snapshot/event. @@ -669,16 +888,67 @@ were constant over the entire course of microscope session and thus all relevant metadata inside the NXinstrument groups are sufficient to understand the session. + + So far there is no vendor-overarching standard according to which + electron microscope data are documented and stored. Therefore, it is + still a frequently the case that vendor-specific files have many fields + that cannot be safely mapped. Therefore, users are always adviced to + keep the vendor files. Working however with these vendor files inside + specific software, like materials databases, demands for parsers which + extract pieces of information from the vendor representation (numerical + data and metadata) and map them on a schema with which the database + and its associated software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented dynamically, coveringly enough in our opinion so that it is + safe to assume all vendor field names are known, logically understood, + interpretable, and thus mappable on a common schema using a controlled + common vocabulary. + + Therefore we encourage user for now to store for each image_set_em + or spectra_set_em instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain like numerical data and metadata were copied into an instance + of this schema for the purpose of working with the data in e.g. tools + offered by the materials database. + + During work on implementing file format/metadata parsers and developing + this application definition we realized that several software tools + currently do not consistently track time-zone-aware timestamps of + events associated with the data, processing, and during the microscope + session. This is in partly a consequence of vendor which store + detailed time data in different formats. We would like to encourage the + community and especially the vendors to work towards a standardization, + or at least a open documentation of the way how time-zone-aware time + data are collected and stored how and where during a microscope session + and how they end up in files and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. - - - + + + Reference to a specific state and setting of the microscope components. - - + + The detector or set of detectors that was used to collect this signal. The name of the detector has to match one of the names of available @@ -689,24 +959,95 @@ - - + + - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_nion.nxdl.xml b/contributed_definitions/NXem_nion.nxdl.xml deleted file mode 100644 index bcd7f2ab11..0000000000 --- a/contributed_definitions/NXem_nion.nxdl.xml +++ /dev/null @@ -1,789 +0,0 @@ - - - - - (Scanning) transmission electron microscopy with a Nion instrument. - - - - - Number of pixel in the x direction - - - - - Number of pixel in the y direction - - - - - Physical size of a pixel in x direction - - - - - Physical size of a pixel in y direction - - - - - - - Official NeXus NXDL schema to which this entry conforms. - - - - Version specifier which enables documentation of modifications to the - schema. - - - - - - Ideally, a (globally) persistent unique identifier for referring to - this experiment. The identifier is usually defined/issued by the - facility, laboratory, or the principle investigator. The identifier - enables to link experiments to e.g. proposals. - - - - - Possibility for leaving a free-text description about the experiment. - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than writing these details in - prose into this field. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the experiment started. If the application - demands that time codes in this section of the application definition - should only be used for specifying when the experiment was performed - - and the exact duration is not relevant - this start time field should - be used. Often though it is useful to specify a time interval with - specifying both start_time and end_time to allow for more detailed - bookkeeping and interpretation of the experiment. The user should be - aware that even with having both time instances specified, it may not - be possible to infer how long the experiment took or for how long data - were acquired. More detailed timing data over the course of the - experiment have to be collected to compute this. - - - - - ISO 8601-formatted time code with local time zone offset to UTC - included when the experiment ended. - - - - - Commercial or otherwise given name to the program which was used to - acquire/measure the dataset. Electron microscopy experiments are - usually controlled/performed via commercial integrated acquisition and - instrument control software. In many cases, an EM dataset is useful - only if gets post-processed already during the acquisition or shortly - thereafter, i.e. while the scientists is still sitting at the - microscope. Many of these processes are automated, if not they - virtually involve GUI interactions with the control software. Examples - include collecting of diffraction pattern and on-the-fly indexing of - these. These situations and tools are realized with individual - NXprocess groups which can hold more details and numerical data to - these processing steps. Frequently, some of these NXprocess groups are - performed with (open-source) research software. Therefore, there is - strictly speaking not a single program used in electron microscopy, - and thus each NXprocess needs its own program, with version and - description." - - - - Ideally program version plus build number, or commit hash or - description of ever persistent resources where the source code of the - program and build instructions can be found so that the program can be - configured ideally in such a manner that the result file is - numerically recreatable in the same deterministic manner. - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold e.g. a ppt, pdf, latex, txt, image, or zip - archive ...). - - - - - A small image that is representative of the entry. This can be an - image from the dataset or a thumbnail of a spectrum. Either way it is - recommended to use 640x480 pixel jpeg image. Adding a scale bar to - that image is recommended but not required as the main purpose of the - thumbnail is to provide e.g. thumbnail images for displaying them in - data repositories. - - - - - - Contact information of at least the user of the instrument who - measured this specimen or the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time when the - experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment was - performed. Given the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offers by services like - ORCID or ResearcherID. - - - - - (Business) (tele)phone number of the user at the point in time when - the experiment was performed. - - - - - Which role does the user have in the place, and at the point in time - when, the experiment was performed (e.g. technician operating the - microscope, student, postdoc, principle investigator, guest ...). - - - - - - - Descriptive name or identifier with which to distinguish the specimen - from all others and especially the parts from where it was cut. In - cases where the specimen was e.g. site-specifically cut from a sample - or in cases of an instrument session during which multiple specimens - are loaded, the name has to be descriptive enough to resolve which - specimen was investigated and is represented by this NXentry. The user - is advised to store the details how specimens were cut/prepared from - samples in the sample history. - - - - - Ideally, a reference to the location of or a (globally) persistent - unique identifier of e.g. another file which should document ideally - as many details as possible of the material, its microstructure, and - its thermo-chemo-mechanical processing/preparation history. In the - case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a sub- - set of the entire sample history, i.e. what you would consider being - the key steps and relevant information about the specimen, its - material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - - - - ISO8601 date and time with local time zone offset to UTC included when - the specimen was prepared. Ideally report the end of the preparation, - i.e. the last known time the measured specimen surface was actively - prepared. Knowing when the specimen was exposed to e.g. specific - atmosphere is especially required for environmentally sensitive - material such as hydrogen-charged specimens or experiments including - tracers with a short half-time. The user is advised to include these - temporal details in the sample_history. - - - - - Possibility to give an abbreviation of the specimen name field. - - - - - Use Hill's system for listing elements of the periodic table which are - inside or attached to the surface of the specimen and thus relevant - from a scientific point of view. The purpose of the field is to offer - materials database systems an opportunity to parse the relevant - elements without having to interpret these from the sample history. - - - - - (Measured) sample thickness - - - - - - Hard link to a location/locations in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Metadata and numerical data of not only the microscope but also the - lab in which this microscope is located. - - - - Given name of the microscope, e.g. NionHermes. - - - - - Geographic coordinates of the lab or the place where the instrument is - installed using GEOREF geocodes ideally. - - - - - Manufacturer of the entire instrument to enable e.g. queries in - materials database systems for instrument manufacturers. Usually more - technical details are needed though to specify the instrument, these - should be written into instrument_model and instrument_capabilities. - - - - - Manufacturer brand/model to enable e.g. queries about microscope - models. See comments on instrument_manufacturer on how to provide - further specification. - - - - - Hardware name/serial number or hash identifier given by the - manufacturer to identify the instrument. - - - - - Free-text list possibly multiple terms of functionalities which the - instrument provides. - - - - - The source which creates the electron beam. - - - - Voltage relevant to compute the energy of the electrons immediately - after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - - - - - - - - - Ideally a reference to (another) file (ideally formatted using also an - application definition) via a link, name, or a (globally) persistent - unique identifier to give further details about the electron gun. - - - - - - Details of individual apertures in the instrument. - - - - Given name. - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier issued by the - manufacturer. - - - - - Given name of the manufacturer. - - - - - Relevant value from the control software. This is not always just the - diameter of (not even in the case) of a circular aperture but rather a - value from a list of predefined aperture settings which somebody - defined in the control software. Which actual settings are behind - these should be defined for now in the description field. - - - - - Ideally, a (globally) persistent unique identifier, link, or text to a - resource which gives further details. - - - - - Affine transformations and geometrical descriptions which detail how - the aperture is placed and arranged in the microscope relative to the - optical axis and beam path. - - - - - - Details to individual lenses in the microscope. - - - - Which type describes the type of the lens closest? - - - - - - - - - - - - Given name. - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier issued by the - manufacturer. - - - - - Given name of the manufacturer. - - - - - Ideally an identifier, persistent link, or free text which gives - further details about the lens. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Conventions from the NXtransformations base class are used. In - principle, the McStas coordinate system is used. The origin of the - coordinate system is placed in the center of the gun pinhole as the - virtual point-like assumed source of the electron beam. A right-handed - coordinate system is assumed whose positive z-axis points in the - direction of the propagating electron beam. The translation actively - brings the coordinate system under depends_on into registration with a - coordinate system in the center of the lens. - - - - - - Does the microscope have a spherical aberration correction unit and - was it used? - - - - - Details about an eventual device which corrects spherical aberrations. - - - - Given name. - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier issued by the - manufacturer. - - - - - Given name of the manufacturer. - - - - - Ideally an identifier, link, or free-text which gives further details - about the component. - - - - - - - - - - - - - - - - - - - - - Principal design of the stage. - - - - - - - - - - - - - - - - - - - Given name. - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier issued by the - manufacturer. - - - - - Given name of the manufacturer. - - - - - Ideally a link to a (globally persistent) unique identifier which - documents or can be used to infer further details of the component. If - such a resource is not available, use this field for a free-text - description and describe further details to the stage. - - - - - STAGE TILT A. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS - TO BE COMMUNICATED. - - - - - STAGE TILT B. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS - TO BE COMMUNICATED. - - - - - STAGEOUTX, Y, Z. EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES - REMAINS TO BE COMMUNICATED. - - - - - - - - - - - Description of the type of the detector e.g. CCD, scintillator, direct - electron, image plate, CMOS. - - - - Given name. - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier issued by the - manufacturer. - - - - - Given name of the manufacturer. - - - - - - - - - - - - - Free text option to write further details about the detector. - - - - - - - EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS TO BE - COMMUNICATED. - - - - - EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES REMAINS TO BE - COMMUNICATED. - - - - - EXACT DEFINITION AS UNDERSTOOD BY HU COLLEAGUES AND NION REMAINS TO BE - COMMUNICATED. - - - - - DETAILS HOW COMPUTED NEEDS TO BE CONFIRMED BY NION. - - - - - - - Container for reporting individually processed images with the HAADF - detector ? - - - - Ideally program version plus build number, or commit hash or - description of ever persistent resources where the source code of the - program and build instructions can be found so that the program can be - configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. - - - - - - HAADF annulus inner half angle ? - - - - - HAADF annulus outer half angle ? - - - - - Description of the scan box which is instructed by the microscope - control software to direct the probe to controlled locations according - to a scan scheme and plan. - - - - Commercial or otherwise given name to the program which was used to - execute this analysis. - - - - Ideally program version plus build number, or commit hash or - description of ever persistent resources where the source code of the - program and build instructions can be found so that the program can be - configured ideally in such a manner that the result of this - computational process is recreatable in the same deterministic manner. - - - - - - REMAINS TO BE DISCUSSED WITH COLLEAGUES WHICH SUGGESTIONS TO PUT AS - ENUMERATIONS. - - - - - - - - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. - - - - - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. - - - - - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. - - - - - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. - - - - - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. - - - - - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. - - - - - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. - - - - - REMAINS TO BE DISCUSSED WITH COLLEAGUES HOW TO USE AND INTERPRET THIS. - - - - - Detailed settings of an internal board(s) in the scanbox device. - FURTHER INFORMATION EXCHANGE/DISCUSSIONS WITH NION IS NEEDED TO - ELUCIDATE WHAT THESE ARE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Container for holding an image (stack) taken with the HA(A) ? DF - detector. - - - - - - - - Image intensity values. - - - - - - - - - Label for the y axis. - - - - - Pixel barycenter position x-coordinates. - - - - - - - - Pixel barycenter position y-coordinates. - - - - - - - - - - diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index f650af3648..9ef6743f68 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -5,42 +5,42 @@ Metadata and settings of an electron microscope for scans and images. The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data - (images, spectra, etc.) can be collected. Users may wish to take only - a single scan or image and complete their microscope session; however + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however - frequently users spend much longer at the microscope, recalibrate, - and take multiple data items (scans, images, spectra) each coming - with own detector and on-the-fly processing settings and calibration. + frequently users are much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and on-the-fly processing settings and calibrations. - For the single data item use case one may argue that the need for additional + For the single data item use case one may argue that the need for an additional grouping is redundant. Instead, the metadata could equally be stored inside the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image it would also not + On the flip side, even for a session with a single image, it would also not harm to nest the data. - In fact, oftentimes scientists feel that there is a need to store details + In fact, oftentimes scientists feel that there is a need to store details about eventual drift of the specimen in its holder (if such data is available) or record changes to the lens excitations caused or apertures used. Although current microscopes are usually equipped with stabilization systems for many of the individual components, it can still be useful to store time-dependent data in detail. - Another reason if not a need for more finely granularizable options for + Another reason if not a need for having more finely granularizable options for storing time-dependent data, is that over the course of a session one may reconfigure the microscope. What is a reconfiguration? This could be the change of an aperture mode because a scientist may first collect an image - with some aperture and then choose a different one. As the aperture affects + with some aperture and then choose a different value. As the aperture affects the electron beam it will affect the system. Let aside for a moment the technology and business models, an EM could be monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of objects - and eventually applied stimuli and positioning of the specimen. + spatio-temporal details about its components, locations of objects, + and eventually (externally) applied stimuli and positioning of the specimen. - Some snapshot or integrated data from this stream are relevant for - understanding signal genesis and electron/ion beam paths. In such a generic + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic case it might be necessary to sync these streaming data with those intervals in time when specific measurements are taken (spectra collected, images taken, diffraction images indexed on-the-fly). @@ -49,20 +49,53 @@ Scientists often report or feel (difficult to quantify) observations that microscopes *perform differently* across sessions, without sometimes being able to identify clear root causes. Users of the instrument may consider - such conditions impractical and thus either abort their session or try to - bring the microscope first into a state where conditions are considered - stable and of high enough quality for collecting data. + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + stable and of high enough quality to reuse data collection. In all these cases it is practical to store time-dependent data of the instrument state not in the respective instrument component groups of the top-level NXinstrument but in a sort of a log of event data. This is the idea behind the NXevent_data_em snapshot containers. - The base class requires a start time and an optional end time. - The end time should be added to represent a time interval - (remind the idea of the instrument state stream) during which the - scientist considered the microscope (especially ebeam and specimen) - as stable enough. + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + But does this warrant to document the microscope state at an even finer + and impractical in-between one collects signal time intervals? + + This is a question of how finely does one granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and illuminates a portion of the material, i.e. + the interaction volume, whose signal contributions are then counted by the + detector(s) as per pixel- or per voxel signal in the region-of-interest. + In principle this application definition allows for such doing so. + However, in most cases such a fine granularization would demand the collection + of data which are as of now hardly retrievable with commercial instruments + nor of primary interest. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. Which warrant an own + consideration in the future. A more detailed overview of such computational + steps to cope with scan distortions is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ For specific simulation purposes, mainly in an effort to digitally repeat or simulate the experiment, it is tempting to consider dynamics of the @@ -80,32 +113,35 @@ In this case one should better go for a customized application definition with a functional property description inside members (fields or groups) - in NXevent_data_em instances or resort to a specific application definition - which documents metadata for tracking explicitly electrons + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons (with ray-tracing based descriptors/computational geometry descriptors) or tracking of wave bundles. - This perspective on more subtle time-dependent considerations of electron + This perspective on much more subtle time-dependent considerations of electron microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with instrument. + additional components that are coupled to and/or synced with a microscope. Examples include cutting-edge experiments where the electron beam gets coupled/excited by e.g. lasers. In this case, the laser unit should be registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective groups of the NXinstrument. + details could be stored inside respective groups of the NXinstrument though + inside instances of here detailed NXevent_data_em. - ISO 8601 time code with local time zone offset to UTC information included when the snapshot time interval started. - If the user wishes to specify an interval of time that the snapshot should represent during which the - instrument was stable and configured using specific settings and calibrations, the start_time is the - start (left bound of the time interval) while the end_time specifies the end (right bound) of the time interval. + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. - ISO 8601 time code with local time zone offset to UTC included when the snapshot time interval ended. - If the user does not wish to specify a time interval, end_time should have the same value as start_time. + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. @@ -156,10 +192,30 @@ - - - - - - + + + A group where specific settings of the instrument during the + event can be captured. This is the preferred way to keep track of + different settings of the microscope during the session. + For instance, a user may first take an overview image with different + magnification and settings and then start a spectrum analyses. + These should be stored as two NXevent_data_em instances in an + application definition. Each storing the specific settings. + + NXmanufacturer relevant details should not be repeated because + we assume that the session is with the same microscope. + Namely, it is hopefully not happening that someone builds out a + component of the microscope while is taking a measurement with it. + For this reason the specialized NXinstrument here contains no NXmanufacturer + groups. + + + + + + + + + + diff --git a/contributed_definitions/NXfib.nxdl.xml b/contributed_definitions/NXfib.nxdl.xml deleted file mode 100644 index d80f12ce7a..0000000000 --- a/contributed_definitions/NXfib.nxdl.xml +++ /dev/null @@ -1,95 +0,0 @@ - - - - - Set of devices adding focused-ion beam capabilities to an instrument. - - - - Given name. - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier issued by the - manufacturer. - - - - - Given name of the manufacturer. - - - - - Ideally a reference to persistent documentation which specifies - further details for the device. If this is not available, add a free- - text description to deliver further details about the focused-ion - unit. - - - - - - The type of source which creates the ion beam. - - - - - - - - - - Which ionized elements or molecules are ionized to form the beam which - is used to probe or sputter the specimen. Examples are gallium, - helium, neon, argon, krypton, or xenon, O2+. - - - - - Average/nominal (DISCUSS FURTHER WITH COLLEAGUES) brightness of the - ion beam (at which location?). - - - - - Ion flux - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum - flight path. - - - - - NEEDS FURTHER DISCUSSION WITH COLLEAGUES HOW THIS SHOULD BE DEFINED. - - - - - - A right-handed Cartesian coordinate system is used whose positive - z-axis points in the direction of the ion beam, i.e. towards the - sample. For modelling ion milling it is relevant to document the - illumination vector. NXtransformations offers a place to store how the - ion gun coordinate system has to be rotated to align its positive - z-axis with the positive z-axis of e.g. the electron beam and ion beam - respectively. - - - - - diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml new file mode 100644 index 0000000000..e140483346 --- /dev/null +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of edges. + + + + + A set of (eventually directed) edges which connect nodes/vertices of a graph. + + + + Total number of edges, counting eventual bidirectional edges only once. + + + + + Integer which specifies the first index to be used for distinguishing + edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish edges for explicit indexing. + + + + + + + + Specifier whether each edge is non-directional, one-directional, + or bidirectional. Use the smallest available binary representation + which can store three different states: + + * 0 / state 0x00 is non-directional + * 1 / state 0x01 is one-directional + * 2 / state 0x02 is bi-directional + + + + + + + + Pairs of node/vertex identifier. Each pair represents the connection + between two nodes. + + In the case that the edge is non- or bi-directional + node identifier should be stored in ascending order is preferred. + + In the case of one-directional, for each pair the identifier of the source + node is the first entry in the pair. The identifier of the target is the + second entry in the pair, i.e. the pair encodes the information as + if one traverses the edge from the source node walking to the target node. + + + + + + + + + A human-readable qualifier which type or e.g. class instance the + edge is an instance of. + + + + + + + + A human-readable label/caption/tag for the edge. + + + + + + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml new file mode 100644 index 0000000000..85b26b99ed --- /dev/null +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -0,0 +1,66 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the graph. Eventually use one for categorical. + + + + + The cardinality of the set, i.e. the number of nodes/vertices of the + graph. + + + + + A set of nodes/vertices in space representing members of a graph. + + + + + + Integer which specifies the first index to be used for distinguishing + nodes. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish nodes for explicit indexing. + + + + + + + + A human-readable qualifier which type or e.g. class instance the + node is an instance of. As e.g. a NeXus application definition is a + graph, more specifically a hierarchical directed labelled property graph, + instances which are groups like NXgraph_node_set could have an is_a + qualifier reading NXgraph_node_set. + + + + + + + + A human-readable label/caption/tag of the graph. + + + + + + diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml new file mode 100644 index 0000000000..169cd51519 --- /dev/null +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -0,0 +1,14 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + An instance of a graph. + + + + diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index a9658fe2a9..5bf3f42f7c 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -4,27 +4,49 @@ - Number of images + Number of images in the stack. - Number of pixel per image in the slow direction + Number of pixel per image in the slow direction. - Number of pixel per image in the fast direction + Number of pixel per image in the fast direction. Container for reporting a set of annular dark field images. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. - Details about how the images were processed from the detector readings. + Details how (HA)ADF images were processed from the detector readings. + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXimage_set_em_adf were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + Commercial or otherwise given name to the program which was used @@ -51,9 +73,9 @@ - + - Annular dark field images. + Annular dark field image stack. diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index a066144821..c3a70793c3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -44,6 +44,25 @@ + + + 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, 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 should be filled with zero. + + + + + + Signed charge state of the ion in multiples of electron charge. diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 1fdfbb4e41..69ac99297c 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -59,6 +59,17 @@ 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 diff --git a/contributed_definitions/NXmanufacturer.nxdl.xml b/contributed_definitions/NXmanufacturer.nxdl.xml index 54f1c8fd22..e202343331 100644 --- a/contributed_definitions/NXmanufacturer.nxdl.xml +++ b/contributed_definitions/NXmanufacturer.nxdl.xml @@ -16,14 +16,14 @@ - Ideally, (globally) unique persistent identifier, i.e. a serial number or hash - identifier of the component. + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. - Free-text list with eventually multiple terms of functionalities which the - component offers. + Free-text list with eventually multiple terms of + functionalities which the component offers. diff --git a/contributed_definitions/NXms_atom_set.nxdl.xml b/contributed_definitions/NXms_atom_set.nxdl.xml new file mode 100644 index 0000000000..d0c09c1ec4 --- /dev/null +++ b/contributed_definitions/NXms_atom_set.nxdl.xml @@ -0,0 +1,17 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A base class to wrap details about a spatial configuration of atoms. + + + + Atom positions. + + + diff --git a/contributed_definitions/NXms_crystal_set.nxdl.xml b/contributed_definitions/NXms_crystal_set.nxdl.xml new file mode 100644 index 0000000000..26022fd385 --- /dev/null +++ b/contributed_definitions/NXms_crystal_set.nxdl.xml @@ -0,0 +1,123 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the description. + + + + + The number of objects, which can be crystals, grains, phases or phase + field regions. + + + + + A base class to wrap details about a set of crystals (grains, precipitates). + + Both experiments and computer simulations support that atoms organize into regions + which are often separated and interconnected by different types of crystal defects. + Crystalline regions show a long-range periodic arrangement (compared to the + length scale of nearest neighbor distances). + Although the group of atoms forming a crystal is virtually never static, due + to diffusive in- and outflux of atoms and thermal fluctuations of the atoms + about their equilibrium positions, crystals are relevant persistent features + in microstructures. The size of crystals can span orders of magnitude from + meters to nanometers. + + There are two different and (somewhat extremal) views on crystals and how to + describe their eventually very rich variety of internal defects. Either + crystals can be coarse-grained into continuum objects or not. In the second case + they need a more advanced internal description of defects inside the grains + which convinces many that eventually a grain has to be viewed from its + individual atoms, its material points, and the hierarchy of structural motifs + local arrangements in the crystal. + + Despite these details, identifying crystals is foremost a labeling task. + Atoms are clustered into structural motifs and (noise) and these motifs + are again clustered into crystals. + + There are two main approaches how crystals are described in mesoscale + microstructure evolution simulations. Assuming for now transformations in the + solid state, precipitates, phase regions, sub-grains or grains are examples + of crystals: + + * Objects are either tracked explicitly in the sense that their shape will + be resolved through the crystal interfaces using e.g. a phase-field, + level-set, grid, or finite element mesh based models and implementations. + These simulations may keep track of explicit crystal/grain/object-related + quantities. Such models can treat the interface network implicitly while + still focusing their description on the explicit crystals. + During such simulations the interface is often analyzed on-the-fly, + because of technical demands (like in level-set implementations) or to + trigger specific situations where it is relevant to resolve the + position of the interfaces explicitly (like for placing seeds for phases, + recrystallizing grains etc, or for visualization purposes), demand a + description of interfaces between crystals. + For explicitly tracking simulations this base class can be applied as is. + * Objects are tracked implicitly in the sense that the computational domain + is discretized into an ensemble of what one can call material points. + Such models can be described at different length scale: On the one hand + where atom dynamics are (whether the assumption is substantiated or not) + homogenized/-able already or not. Each material point is assumed to have + at least one associated constitutive phase. + Such simulations usually do not/cannot resolve crystal-related quantities + without executing an on-the-fly post-processing of snapshot data from + which the spatial representation of the crystal is recovered. + An important case are large-strain formalism crystal plasticity methods. + Here the initial configuration represents most frequently material points + on a regular grid. Within the course of the simulation this grid gets + deformed implicitly. The code internally keeps no track of how the cells/ + material points of what is essentially a Voronoi tessellation, are deformed. + Only in the case when one would like to visualize the deformed configuration, + a post-processing of the simulation snapshot data is executed which + recovers the positions of the material points in the deformed configuration + in the laboratory coordinate system from which one can then extract a + representation of grains/precipitates, i.e. crystals. + It is a signature of such simulations that quantities like orientation + are defined as material point quantities. This means what constitutes the grain + needs to be extracted by cluster analyses. + In this regard, such simulation are essentially matching the representation and + case of molecular dynamics simulations, with the important difference + that these track atoms, from whose configuration + in a snapshot a description has to be computed what are most likely the + atoms that belong to the volume of the crystal or the interface/defect + network. + + + + + + Integer which specifies the first index to be used for distinguishing + objects. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish objects for explicit indexing. + + + + + + + + Depending on the value of dimensionality, the area or volume of each object. + + + + + + diff --git a/contributed_definitions/NXms_delocalization.nxdl.xml b/contributed_definitions/NXms_delocalization.nxdl.xml new file mode 100644 index 0000000000..160857e2e2 --- /dev/null +++ b/contributed_definitions/NXms_delocalization.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of points/objects. + + + + + Number of mark data per point/object. + + + + + Number of atoms in the whitelist. + + + + + Number of isotopes in the whitelist. + + + + + Base class to describe the delocalization of point-like objects on a grid. + + Such a procedure is for instance used in image processing and e.g. atom probe + microscopy (APM) to discretize a point cloud onto a grid to enable e.g. + computing of point density, composition, or concentration values, obtain + scalar fields, and compute gradients of these fields. + + + + Reference or link to the grid on which the delocalization is applied. + + + + + Reference or link to the points which are delocalized on the grid. + + + + + The weighting model specifies how mark data are mapped to a weight per point. + For atom probe microscopy (APM) as an example, different models are used which + account differently for the multiplicity of an ion/atom: + + * default, points all get the same weight 1.; + for APM this is equivalent to ion species + * atomic_decomposition, points get as much weight as they have atoms + of a type in element_whitelist, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotope_whitelist. + + This description shows an example that could be reinterpreted for + similar such data processing steps in other fields of science. + + + + + + + + + + A list of elements (via proton number) to consider for the atomic_decomposition + weighting model. Elements must exist in the periodic table of elements." + + + + + + + + A list of isotopes to consider for the isotope_decomposition weighting model. + Isotopes must exist in the nuclid table. Entries in the fastest changing + dimension should be the pair of proton (first entry) and neutron number + (second entry). + + + + + + + + + Attribute data for each member of the point cloud. For APM these are the + ion species labels generated via ranging. The number of mark data per + point is 1 in the case for atom probe. + + + + + + + + + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point. For APM the weight are positive + integer values, specifically the multiplicity of the ion, + according to the details of the weighting_model. + + + diff --git a/contributed_definitions/NXms_orientation_set.nxdl.xml b/contributed_definitions/NXms_orientation_set.nxdl.xml new file mode 100644 index 0000000000..d77249b60e --- /dev/null +++ b/contributed_definitions/NXms_orientation_set.nxdl.xml @@ -0,0 +1,94 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the reference space/coordinate system. + + + + + The cardinality of the set, i.e. the number of orientations. + + + + + Number of parameters for the chosen parameterization. + + + + + Details about individual orientations of a set of objects. + + For a more detailed insight into the discussion of parameterizing + orientations in materials science see: + + * https://doi.org/10.1016/j.matchar.2016.04.008 + * https://doi.org/10.1088/0965-0393/23/8/083501 + * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations + * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge + + + + Reference to or definition of a coordinate system with + which the definitions are interpretable. + + + + + + + + + + + A link or reference to the objects whose identifier are referred to in + identifier to resolve which row tuple is the orientation of each object + by reading orientations. + + + + + Integer which specifies which orientation (row of array orientation) matches + to which object.e first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish how a row in orientation describes a specific + object with an explicit identifier that can be queried via inspecting the + list of available objects in objects. + + The rational behind having such a more complicated pattern is that not + all objects referred when following the link in objects may still exists + or are still tracked when the orientation set was characterized. + + This design enables to also use NXms_orientation_set in situations where + the orientation of objects change as a function in time. + + + + + + + + Parameterized orientations. + + + + + + + diff --git a/contributed_definitions/NXms_slip_system_set.nxdl.xml b/contributed_definitions/NXms_slip_system_set.nxdl.xml new file mode 100644 index 0000000000..6959ce5d4e --- /dev/null +++ b/contributed_definitions/NXms_slip_system_set.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of slip systems. + + + + + Base class for describing a set of crystallographic slip systems. + + + + + + + + + + + + + + + Array of Miller indices which describe the crystallographic plane. + + + + + + + + + Array of Miller indices which describe the crystallographic direction. + + + + + + + + + For each slip system a marker whether the specified Miller indices + refer to the specific slip system or the set of crystallographic equivalent + slip systems of the respective family of slip systems. + + + + + + diff --git a/contributed_definitions/NXms_snapshot.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml new file mode 100644 index 0000000000..3ca0fcb2af --- /dev/null +++ b/contributed_definitions/NXms_snapshot.nxdl.xml @@ -0,0 +1,32 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class wrapping data of a system characterized at a specific time/iteration. + + + + Is this time for a measurement or a simulation. + + + + + + + + + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Iteration or increment counter. + + + diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml new file mode 100644 index 0000000000..5198b90af0 --- /dev/null +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -0,0 +1,35 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A collection of spatiotemporal microstructure data. + + + + Is this set describing a measurement or a simulation? + + + + + + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 22db765166..f1f1b75279 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -10,4 +10,16 @@ + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index cacd80e283..f1f7ad30bf 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -14,6 +14,7 @@ Metadata for laser-, voltage-, or combined pulsing triggering field evaporation. + How is field evaporation physically triggered. @@ -29,13 +30,16 @@ Frequency with which the high voltage or laser pulser fires. - + Fraction of the pulse_voltage that is applied in addition to the standing_voltage at peak voltage of a pulse. + + TO BE IMPROVED + @@ -55,7 +59,7 @@ Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the excitation and eventual field evaporation/emission of - an ion during an atom probe microscopy experiment. + an ion during an experiment. diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index 3982438b55..32bdb644ef 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -4,6 +4,7 @@ Device to reduce an atmosphere to a controlled remaining pressure level. + Principle type of the pump. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 0af3ac4f8f..e9f639aecc 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -16,4 +16,5 @@ + diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml index 7e44d1f118..4952128e6e 100644 --- a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -1,9 +1,155 @@ + + + + Number of pixel per EELS mapping in the slow direction. + + + + + Number of pixel per EELS mapping in the fast direction. + + + + + Number of electron energy loss bins. + + + - Container for reporting a set of electron energy loss spectra. + Container for reporting a set of electron energy loss (EELS) spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + + The latter pattern is the most frequently used. + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. - - + + + Details how EELS spectra were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_eels were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the EELS spectra stack and summary. + + + + Program 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. + + + + + + + Collected EELS spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + + EELS counts + + + + + Pixel center of mass position y-coordinates. + + + + + + + Label for the y axis. + + + + + + Pixel center of mass position x-coordinates. + + + + + + + Label for the x axis. + + + + + + Pixel center of mass energy loss bins. + + + + + + + Label for the energy loss axis. + + + + + + + Accumulated EELS spectrum over all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + Counts for specific energy losses. + + + + + + + + Counts electrons with an energy loss within binned range. + + + + + Pixel center of mass energy loss bins. + + + + + + + Energy loss + + + + diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml index 916f1376a3..95ddca359a 100644 --- a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -2,19 +2,14 @@ - - - Number of scan points - - - Number of pixel per Kikuchi pattern in the slow direction + Number of pixel per X-ray mapping in the slow direction - Number of pixel per Kikuchi pattern in the fast direction + Number of pixel per X-ray mapping in the fast direction @@ -42,16 +37,49 @@ such as single point, line profiles, or (rectangular) surface mappings. The latter pattern is the most frequently used. - For now the base class provides for scans where the settings, + For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ + should be used. - + + + Details how X-ray spectra were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_xray were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the X-ray spectra stack and summary. + + + + Program 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. + + + + + - Collected X-ray counts chunked based on rectangular images. - - This representation supports only rectangular scan pattern. + Collected X-ray spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. @@ -96,6 +124,32 @@ + + + Accumulated X-ray spectrum over all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + X-ray photon counts + + + + + + + + + X-ray energy + + + + Details about computational steps how peaks were indexed as elements. diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index b1592feb75..2a9a7810eb 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -236,7 +236,7 @@ Response time of the detector - + Detector gain diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 44446d92f7..74ab65c161 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -11,7 +11,6 @@ Atom Probe Microscopy Structure ApmRemovedBC - .. _IntroductionAPM: Introduction @@ -75,5 +74,4 @@ Removed base classes We have removed the NXlens_apm base class and replaced it by :ref:`NXreflectron`. -.. - https://stackoverflow.com/questions/4783814/how-to-comment-a-string-in-restructured-text \ No newline at end of file + diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst new file mode 100644 index 0000000000..b318b8d062 --- /dev/null +++ b/manual/source/cgms-structure.rst @@ -0,0 +1,279 @@ +.. _CGMSFeatures-Structure: + +=============================================================================== +Computational-Geometry-Based Descriptions of Structural Features in Materials +=============================================================================== + +.. index:: + IntroductionCGMS + PhysicsCGMS + CGMSNewAppDef + CGMSNewBC +.. CGMSNewCommonBC + + +.. _IntroductionCGMS: + +Introduction +############## + +The computational-geometry/microstructure-modeling-based part of the proposal +has the following aims: + +First, we would like to contribute to efforts on standardizing a controlled +vocabulary, definitions for these terms, and relations between the terms, for +computational-geometry-based descriptions of the microstructure of materials +and atomic configurations used when characterizing materials in experiments +and computer simulations. + +As far as NeXus is concerned, the here proposed distinct sets of simple +geometric primitives and shapes offer a complementary alternative to the +already existent base classes in NeXus for constructive solid geometry +such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name a few. + +Second, we would like to explore with this proposal how we can harmonize terms +frequently used by materials scientists in the condensed-matter physics with the +NOMAD MetaInfo description. + +Third, the proposal should yield a substantiated set of arguments and suggestions +how descriptors for the structure and atomic architecture of materials can be +harmonize. With this we especially would like to reach out and intensify the +cooperation between the materials-science-related consortia of the German +National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, +and NFDI4Chem + +.. The proposal reaches out to our colleagues in the materials engineering-based +.. consortia to document that there is value in discussing about controlled vocabulary. + +.. _PhysicsCGMS: + +Physics background +################### +Microstructural features or crystal defects are spatial arrangements of atoms. +Given their specific atomic arrangement and composition, such features have +specific constraints on the degrees of freedom how atoms can arrange. This causes +that these defects have specific properties. +Provided well-defined coarse-graining procedures are used and regions-of-interest +and/or regions-of-applicability are defined, microstructural features are often +characterized and modelled to have associated thermodynamic descriptors. + +Another motivation for the proposal was the observation that frequently the design +of file formats for simulation software in the computational materials science especially +those tools at the interface between condensed-matter physics and materials engineering +are frequently reimplementing the wheel (at least partly) when it comes to decide how to store +e.g. atom and feature positions or shape of regions-of-interest, grids, crystals, +grains, precipitates, and dislocations. + +Maybe this is a historical burden given the large set of technical terms and jargon +in place, which then motivated pragmatic solutions that resulted in many research groups +have developed similar formats using similar descriptions. + +We see this work on base classes and application definitions not primarily an +effort to improve and extend NeXus for now. Rather this part of the proposal +is an effort to support activities in materials science to work towards +common terminology and using controlled vocabularies more frequently. +These are the foundation for more sophisticated thoughts about practically +useful ontologies. + +Defining crystal defects is a question of how to coarse-grain a given spatio- +temporal set of atoms, each having a nuclid type and position/trajectory. +In most cases, such a coarse-graining is an ill-posed task because different +mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric defect +can be described and be spatio-temporally constrained through a geometrical model +with defined geometric primitives and associated coarser-scale properties of the defect. + +The key motivation to such coarse-graining is to reduce the complexity of the +description. On the one hand to support visualization and scientific analyses - not only +of crystal defect arrangements - and on the other hand it is the hope that using descriptors +at a coarser level, i.e. nanometer, micrometer, and larger, still sufficiently +accurate and precise descriptors can be found without having to dynamics of each +atom to predict or understand the properties of defects and their dynamics. + +Nevertheless, experience has shown that computational-geometry-based descriptions +when combined with hierarchical clustering/labeling methods, applied on the set of +atoms, turn out to yield useful descriptors. Examples include point, line, surface defects, +such as vacancies, solute cluster, dislocations, disconnections, interfaces to name but a few. + +.. _CGMSNewAppDef: + +.. New Application Definitions +.. ############################ + +.. Work on handshaking between EPICS-controlled experiments and NeXus resulted +.. in one application definition for temperature dependent IV curve measurements. + +.. :ref:`NXiv_temp`: +.. Application definition for temperature dependent IV curve measurements. + +.. _CGMSNewBC: + +New Base Classes +################# + +We propose the following base classes, starting with a set of descriptors +for frequently used shapes and geometric primitives: + + :ref:`NXcg_sphere_set`: + A description for a set of possibly dissimilar spheres. + + :ref:`NXcg_ellipsoid_set`: + A description for a set of possibly dissimilar rotated ellipsoids. + + :ref:`NXcg_cylinder_set`: + A description for a set of possibly dissimilar rotated cylinders. + + :ref:`NXcg_point_set`: + A collection of points with labels or mark data. + + :ref:`NXcg_polyline_set`: + A collection of lines and linearized segments. + + :ref:`NXcg_triangle_set`: + A collection (or soup) of triangles. + + :ref:`NXcg_parallelogram_set`: + A collection of possibly dissimilar parallelograms. + + :ref:`NXcg_triangulated_surface_mesh`: + A mesh of triangles. + + :ref:`NXcg_polygon_set`: + A collection (or soup) of polygons. + + :ref:`NXcg_polyhedron_set`: + A collection (or soup) of polyhedra. + + :ref:`NXcg_roi_set`: + A container to host a number of different type of primitives. + + :ref:`NXcg_tetrahedron_set`: + A collection (or soup) of tetrahedra. + + :ref:`NXcg_hexahedron_set`: + A collection (or soup) of hexahedra with capabilities to represent + also simpler (bounding) boxes for e.g. binary trees. + + +These base classes make use of new base classes which describe data structures: + + :ref:`NXcg_face_list_data_structure`: + In essence, the usual way how polygon/polyhedra data are reported: + Via a list of vertices and faces with identifier and properties. + + :ref:`NXcg_half_edge_data_structure`: + A half-edge data structure is a useful complementary descriptor for + polygon/polyhedra which enables topological analyses and traversal + of the graph how polygons and polyhedra can be described. + + :ref:`NXcg_unit_normal_set`: + As an additional structuring element especially for meshes well-documented + normal information is crucial for distance computations + + :ref:`NXcg_geodesic_mesh`: + Geodesic meshes are useful for all applications when meshing the surface + of a sphere. + + :ref:`NXcg_alpha_shape`: + Alpha shapes and alpha wrappings, specifically the special case of the + convex hull, are frequently used geometrical models for describing + a boundary or edge to a set of geometric primitives. + + +Furthermore, we propose a few base classes for operations when working with +discretized representations of material (area or volume) which can be useful +not only for stencil-based methods: + + :ref:`NXcg_grid`: + A grid of cells. + + :ref:`NXcg_isocontour`: + A description for isocontour descriptions. + + :ref:`NXcg_marching_cubes`: + An approach to store metadata of a specific implementation of + the Marching Cubes algorithm, whose sensitivity to specific topological + configurations is known to result in different triangle soups. + + :ref:`NXms_delocalization`: + An approach to document procedures in which a scalar field + is smoothened in a controlled manner. + +Assuming that these base classes can serve as building blocks, we would like +to test with the proposal also how these base classes can be applied in base +classes for specific types of microstructural features and/or utility classes +to hold metadata for these features: + + :ref:`NXclustering`: + A description for clustering of objects (such as atoms or features). + + :ref:`NXms_atom_set`: + A set of atoms. + + :ref:`NXms_orientation_set`: + A set of rotations to describe the relative orientation of + of members of a set of features/objects. + + :ref:`NXms_slip_system_set`: + Metadata to a set of slip system/slip system family for + a given crystal structure. + +.. :ref:`NXms_point_defect_set`: +.. Metadata to a set of point defects. + +.. :ref:`NXms_dislocation_set`: +.. Metadata of a set of dislocation/disconnection (line) defects. + +.. :ref:`NXms_interface_set`: +.. Metadata to a set of interfaces between crystals. + + :ref:`NXms_crystal_set`: + A set of crystals, for e.g. a polycrystal, phases, + grains, precipitates. + + :ref:`NXms_snapshot`: + A container to describe the state of microstructural features + at a given point in time. + + :ref:`NXms_snapshot_set`: + The corresponding class to hold a set of :ref:`NXms_snapshot` objects. + +Furthermore, we found that it can be useful to have a set of base classes with +which software documents state and gives a summary for users about the performance +and elapsed time measured while processing data. These utility classes include: + + :ref:`NXcs_filter_boolean_mask`: + A boolean mask. + + :ref:`NXcs_prng`: + Metadata of a pseudo-random number generator (PRNG) algorithm. + + :ref:`NXcs_profiling`: + A structuring group holding a set of :ref:`NXcs_profiling_event` instances. + + :ref:`NXcs_profiling_event`: + Profiling/benchmark data to an event of + tracking an algorithm/computational step. + + :ref:`NXcs_computer`: + Metadata of a computer. + + :ref:`NXcs_cpu`: + Metadata of a central processing unit. + + :ref:`NXcs_gpu`: + Metadata of a graphical processing unit / accelerator. + + :ref:`NXcs_mm_sys`: + Metadata of the (main) memory (sub-)system. + + :ref:`NXcs_io_sys`: + Metadata of the input/output system. + + :ref:`NXcs_io_obj`: + Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. + + +.. _CGMSNewCommonBC: +.. New Common Base Classes +.. ####################### + diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 469d5b36fe..c83c0c2604 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -32,7 +32,7 @@ We acknowledge that it can be difficult to agree on a single application definit the specimen from the instrument or parking it so that the next user can take its time at the instrument. Next, we wrote base classes to describe these steps and events. :ref:`NXem`: - A general application definition which explores the possibilities of electron microscopes. + A general application definition which explores the possibilities of electron microscopes. .. _EmNewBC: @@ -69,27 +69,29 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXibeam_column`: A base class serving the possibility to group the components relevant for generating and shape an ion beam of an instrument with focused ion beam capabilities. - :ref:`NXimage_set_em_adf`: - :ref:`NXimage_set_em_bf`: - :ref:`NXimage_set_em_bse`: - :ref:`NXimage_set_em_chamber`: - :ref:`NXimage_set_em_df`: - :ref:`NXimage_set_em_diffrac`: - :ref:`NXimage_set_em_ecci`: - :ref:`NXimage_set_em_kikuchi`: - :ref:`NXimage_set_em_ronchigram`: + :ref:`NXimage_set_em_adf` + :ref:`NXimage_set_em_bf` + :ref:`NXimage_set_em_bse` + :ref:`NXimage_set_em_chamber` + :ref:`NXimage_set_em_df` + :ref:`NXimage_set_em_diffrac` + :ref:`NXimage_set_em_ecci` + :ref:`NXimage_set_em_kikuchi` + :ref:`NXimage_set_em_ronchigram` :ref:`NXimage_set_em_se`: - Base classes for storing acquisition details for individual images or stacks images in different imaging modes. - Adf - annular dark field - Bf - bright filed - Bse - backscattered electron - Chamber - TV camera to monitor the stage and chamber (e. g. to assure that the specimen does not collides with components in the instrument) - Df - darkfield - Diffrac - diffraction image - Ecci - electron channel contrast imaging - Kikuchi - Kikuchi diffraction images for electron backscattered electron diffraction (EBSD) for orientation microscopy - Ronchigram - convergent beam diffraction pattern - Se - secondary electron + Base classes for storing acquisition details for individual images + or stacks of images collected via using e.g. different imaging modes. + + * Adf - annular dark field + * Bf - bright filed + * Bse - backscattered electron + * Chamber - TV camera to monitor the stage and chamber + * Df - darkfield + * Diffrac - diffraction image + * Ecci - electron channel contrast imaging + * Kikuchi - electron backscatter diffraction (EBSD) + * Ronchigram - convergent beam diffraction pattern + * Se - secondary electron :ref:`NXinteraction_vol_em`: A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. @@ -116,11 +118,18 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXscanbox_em`: A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. - :ref:`NXspectrum_set_em_auger`: + :ref:`NXspectrum_set_em_eels` + :ref:`NXspectrum_set_em_xray` + :ref:`NXspectrum_set_em_auger` :ref:`NXspectrum_set_em_cathodolum`: - :ref:`NXspectrum_set_em_eels`: - :ref:`NXspectrum_set_em_xray`: - A base classes comparable to NXimage_set_em but for different techniques resulting in spectra like Auger spectroscopy, cathodoluminescence, electron energy loss spectroscopy and X-ray spectroscopy. + Base classes comparable to NXimage_set_em but for + different techniques resulting in spectra. + + * Auger spectroscopy + * Cathodoluminescence + * Electron energy loss spectroscopy (EELS) + * X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS) + :ref:`NXstage_lab`: As it was mentioned for atom probe microscopy this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. @@ -144,7 +153,10 @@ Deprecated With the results of the NeXus 2022.06 Code Camp the following base classes and application definitions are considered deprecated. Their functionalities has been extended and is replaced specifically as follows: - :ref:`NXem_nion`: - An application definition specific for Nion (transmission) electron microscopes. This is replaced by the substantially more general :ref:`NXem` application definition. - :ref:`NXfib`: - A base class to describe focused-ion beam capabilities of an (electron) microscope. The base class is replaced by :ref:`NXibeam_column`. \ No newline at end of file + **NXem_nion** was an application definition specific for Nion (transmission) electron microscopes. + We consider this application definition as deprecated. Instead, users + should use the substantially more general :ref:`NXem` application definition. + + **NXfib** was a base class which described focused-ion beam capabilities of an + (electron) microscope. Considered deprecated, users should use the more specific + :ref:`NXibeam_column` base class instead. diff --git a/manual/source/index.rst b/manual/source/index.rst index 7a7ba06426..d1f5066d3e 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -16,6 +16,8 @@ https://www.nexusformat.org/ em-structure apm-structure epics-structure + cgms-structure + north-structure ----------- diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst new file mode 100644 index 0000000000..ea859e6dd0 --- /dev/null +++ b/manual/source/north-structure.rst @@ -0,0 +1,218 @@ +.. _North-Structure: + +=============================================================================== +NeXus Application Definitions for Third-Party Tools of NORTH +=============================================================================== + + +.. index:: + IntroductionApmParaprobe + WhatHasBeenAchieved + ApmParaprobeAppDef + ApmParaprobeNewBC + NextStep + + +.. _IntroductionApmParaprobe: + +Introduction +############## + +NORTH (the NOMAD OASIS Remote Tools Hub) is a NOMAD OASIS service which makes +preconfigured scientific software of different communities available coupled +to the OASIS and accessible via the webbrowser. This part of the proposal documents +examples for specific NeXus-related work to some of the tools and containers +available in NORTH. + +One tool is the paraprobe-toolbox software package in the the apm tools container. +The software is developed by `M. Kühbach et al. `_. + +Here we show how NeXus is used to consistently define application definitions +for scientific software in the field of atom probe. + +In this community the paraprobe-toolbox is an example of an open-source parallelized +software for analyzing point cloud data, for assessing meshes in 3D continuum +space, and analyzing the effects of parameterization on descriptors +about the microstructure of materials which were studied with atom probe microscopy. + +The need for a thorough documentation of the tools in not only the paraprobe-toolbox +was motivated by several needs: + +First, users of software would like to better understand and also be able to +study themselves which individual parameter and settings for each tool exists +and configuring these affects their analyses quantitatively. + +Second, scientific software like those of the paraprobe-toolbox implement a +numerical workflow where multiple data sources and previous analysis results +are processed and carried through more involved analysis with several steps. + +Individual tools are developed in C/C++ and/or Python. Here, having a possibility +for provenance tracking is useful as it is one component and requirement for +making workflows exactly numerically reproducible and thus to empower scientists +to fullfill better the "R", i.e. reproducibility of daily FAIR research practices. + +The paraprobe-toolbox is one example of a software which implements a workflow +via a sequence of operations executed within a jupyter notebook +(or Python script respectively). Specifically, individual tools are chained +and convenience function are available to create well-defined input/configuration +files for each tool. These config files instruct the tool upon processing. + +In this design, each workflow step (with a tool) is in fact a pair (or triple) of +at least two sub-steps: i) the creation of a configuration file, +ii) the actual analysis using the Python/or C/C++ tools, +iii) the optional of the results in the HDF5 file from each tool run with +other software in Python or Matlab for instance. + + +.. _WhatHasBeenAchieved: + +What has been achieved so far? +############################## + +This proposal summarizes the first (of two) steps which change the interface and +file interaction in all tools of the paraprobe-toolbox to accept exclusively +well-defined configuration files and yield specific output. + +Data and metadata between the tools are exchanged with HDF5/NeXus files. +Specifically, we created for each tool an application definition (see below) +which details all possible settings and options for the configuration as to +guide users. The config(uration) files are HDF5 files, whose content matches +to the naming conventions of the respective application definition for each tool. +As an example NXapm_paraprobe_config_surfacer specifies how a configuration file +for the paraprobe-surfacer tool should be formatted and which parameter it contains. + +That is each config file uses a controlled vocabulary of terms. Furthermore, +the config files store a SHA256 checksum for each input file. +This implements a full provenance tracking on the input files along the +processing chain/workflow. + +As an example, a user may first range their reconstruction and then compute +correlation functions. The config file for the ranging tool stores the files +which hold the reconstructed ion position and ranging definitions. +The ranging tool generates a results file with the ion type labels stored. + +This results file and the reconstruction is imported by the spatial statistics +tool which again keeps track of all files. This makes it possible to rigorously +trace which numerical results were achieved with a specific chain of input and +settings using specifically-versioned tools. + +We understand that this additional handling of metadata and provenance tracking +may not be at first glance super relevant for scientists or appear and unnecessary +feature. There is indeed an additional layer of work for the development +and maintenance of the software. + +However, we are convinced that this is the preferred way of performing software +development and data analyses as it enables users to take advantage of a completely +automated provenance tracking which happens silently in the background. + +.. _ApmParaprobeAppDef: + +New Application Definitions +############################ + + :ref:`NXapm_paraprobe_config_transcoder`: + Configuration of paraprobe-transcoder + Load POS, ePOS, APSuite APT, RRNG, RNG, and NXapm HDF5 files. + + :ref:`NXapm_paraprobe_config_ranger`: + Configuration of paraprobe-ranger + Apply ranging definitions and explore possible molecular ions. + + :ref:`NXapm_paraprobe_config_surfacer`: + Configuration of paraprobe-surfacer + Create a model for the edge of a point cloud via convex hulls, alpha shapes. + + :ref:`NXapm_paraprobe_config_distancer`: + Configuration of paraprobe-distancer + Compute analytical distances between ions to a set of triangles. + + :ref:`NXapm_paraprobe_config_tessellator`: + Configuration of paraprobe-tessellator + Compute Voronoi cells for if desired all ions in a dataset. + + :ref:`NXapm_paraprobe_config_nanochem`: + Configuration of paraprobe-nanochem + Compute delocalization, iso-surfaces, analyze 3D objects, and composition profiles. + + :ref:`NXapm_paraprobe_config_intersector`: + Configuration of paraprobe-intersector + Assess intersections and proximity of 3D triangulated surface meshes in + continuum space to study the effect the parameterization of surface + extraction algorithms on the resulting shape, spatial arrangement, + and colocation of 3D objects via graph-based techniques. + +.. _ApmParaprobeNewBC: + +New Base Classes +################# + +We envision that the above-mentioned definitions can be useful not only to take +inspiration for other software tools in the field of atom probe but also to support +a discussion towards a stronger standardization of the vocabulary used. +Therefore, we are happy for your comments and suggestions on this and the related +pages via the hypothesis web annotation service. + +We are convinced that the majority of data analyses in atom probe use +an in fact common set of operations and conditions on the input data +even though this might not be immediately evident. In particular this is not +the case for some community build tools with a very specific scope where oftentimes +the algorithms hardcoded. A typically example is a reseacher who implements a +ranging tool and uses that all the examples are on a specific material. +We are convinced it is better to follow a much more generalized approach. + +In this spirit, we propose the following base classes as examples how very +flexible constraints can be implemented which restrict which ions in the dataset +should be processed or not. We see that these suggestion complement the +proposal on computational geometry base classes: + + :ref:`NXapm_input_reconstruction`: + A description from which file the reconstructed ion positions are imported. + + :ref:`NXapm_input_ranging`: + A description from which file the ranging definitions are imported. + The design of the ranging definitions is, thanks to :ref:`NXion` so + general that all possible nuclids be they observationally stable + or radioactive can be considered. + + :ref:`NXapm_spatial_filter`: + A proposal how a point cloud can be spatial filtered in a very specific, + flexible, yet general manner. This base class takes advantage of + :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, and :ref:`NXcg_hexahedron_set` + to cater for all of the most commonly used geometric primitives in + atom probe. + + :ref:`NXapm_evaporation_id_filter`: + A proposal to describe how ions are filtered based on their evaporation + sequence ID. + + :ref:`NXapm_iontype_filter`: + A proposal to describe how ions are filtered based on their + ion type (ion species). + + :ref:`NXapm_hitmultiplicity_filter`: + A proposal to describe how ions are filtered based on their + hit multiplicity. + +In summary, we report with this proposal our experience made in an experimental +project that is about using NeXus for standardizing a certain scientific software. +During the implementation we learned that for handling computational geometry +and microstructure-related terms many subtilities have to be considered which +makes a controlled vocabulary valuable not only to avoid reimplementing the wheel. + + +.. NextStep: + +Next Step +#################### + +This also makes us confident to take the next step which will be to change also +the results file of each tool. The following two application definition are +not yet implemented in the tools' source code but give an idea for development +purposes how such application definitions and description of created files could +look like. + + :ref:`NXapm_paraprobe_results_transcoder`: + + :ref:`NXapm_paraprobe_results_ranger`: + + From a59bc2510938334149527496f7c590d4c42bb618 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Sat, 3 Sep 2022 13:40:42 +0200 Subject: [PATCH 047/203] Made short title for sections on the front page shorter and better matching the FAIRmat proposal names --- manual/source/apm-structure.rst | 6 +++--- manual/source/cgms-structure.rst | 6 +++--- manual/source/ellipsometry-structure.rst | 6 +++--- manual/source/em-structure.rst | 6 +++--- manual/source/index.rst | 4 ++-- manual/source/mpes-structure.rst | 6 +++--- manual/source/north-structure.rst | 6 +++--- .../source/{epics-structure.rst => transport-structure.rst} | 6 +++--- 8 files changed, 23 insertions(+), 23 deletions(-) rename manual/source/{epics-structure.rst => transport-structure.rst} (87%) diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 74ab65c161..18fc499f74 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -1,8 +1,8 @@ .. _Apm-Structure: -================================= -Atom Probe Microscopy Structure -================================= +========================= +B5: Atom-probe tomography +========================= .. index:: IntroductionAPM diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index b318b8d062..71d0211c5a 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -1,8 +1,8 @@ .. _CGMSFeatures-Structure: -=============================================================================== -Computational-Geometry-Based Descriptions of Structural Features in Materials -=============================================================================== +================================= +Shape, geometry & microstructures +================================= .. index:: IntroductionCGMS diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst index bf92e3d3f8..4fc29edc3b 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/ellipsometry-structure.rst @@ -1,8 +1,8 @@ .. _Ellipsometry-Structure: -======================= -Ellipsometry Structure -======================= +======================== +B4: Optical spectroscopy +======================== .. index:: IntroductionEllipsometry diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index c83c0c2604..163013403b 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -1,8 +1,8 @@ .. _Em-Structure: -================================== -Electron Microscopy Structure -================================== +======================= +B1: Electron microscopy +======================= .. index:: IntroductionEM diff --git a/manual/source/index.rst b/manual/source/index.rst index d1f5066d3e..c9a24b313a 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -11,11 +11,11 @@ https://www.nexusformat.org/ fairmat-cover nexus-index + em-structure mpes-structure ellipsometry-structure - em-structure apm-structure - epics-structure + transport-structure cgms-structure north-structure diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index 5e75584c89..5cff20336a 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -1,8 +1,8 @@ .. _Mpes-Structure: -======================= -MPES Structure -======================= +=================================== +B2/B3: Photoemission & spectroscopy +=================================== .. index:: IntroductionMPES diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst index ea859e6dd0..8ac0aa96d3 100644 --- a/manual/source/north-structure.rst +++ b/manual/source/north-structure.rst @@ -1,8 +1,8 @@ .. _North-Structure: -=============================================================================== -NeXus Application Definitions for Third-Party Tools of NORTH -=============================================================================== +============================== +Nomad Remote Tools Hub (NORTH) +============================== .. index:: diff --git a/manual/source/epics-structure.rst b/manual/source/transport-structure.rst similarity index 87% rename from manual/source/epics-structure.rst rename to manual/source/transport-structure.rst index 1323d4320b..10abb9da85 100644 --- a/manual/source/epics-structure.rst +++ b/manual/source/transport-structure.rst @@ -1,8 +1,8 @@ .. _Epics-Structure: -================================== -EPICS Structure -================================== +=================== +Transport Phenomena +=================== .. index:: IntroductionEpics From ca195efa2f233f60fdeb03981fa45a707ab31a64 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Sat, 3 Sep 2022 14:13:15 +0200 Subject: [PATCH 048/203] Small edits on proposed titles --- manual/source/cgms-structure.rst | 6 ++--- manual/source/em-structure.rst | 42 +++++++++++++++----------------- manual/source/mpes-structure.rst | 6 ++--- 3 files changed, 26 insertions(+), 28 deletions(-) diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index 71d0211c5a..e6040817ec 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -1,8 +1,8 @@ .. _CGMSFeatures-Structure: -================================= -Shape, geometry & microstructures -================================= +========================= +Geometry & microstructure +========================= .. index:: IntroductionCGMS diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 163013403b..a42ed586d9 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -79,20 +79,19 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXimage_set_em_kikuchi` :ref:`NXimage_set_em_ronchigram` :ref:`NXimage_set_em_se`: - Base classes for storing acquisition details for individual images - or stacks of images collected via using e.g. different imaging modes. - - * Adf - annular dark field - * Bf - bright filed - * Bse - backscattered electron - * Chamber - TV camera to monitor the stage and chamber - * Df - darkfield - * Diffrac - diffraction image - * Ecci - electron channel contrast imaging - * Kikuchi - electron backscatter diffraction (EBSD) - * Ronchigram - convergent beam diffraction pattern - * Se - secondary electron - + Base classes for storing acquisition details for individual images or stacks of images collected via using e.g. different imaging modes. + + * Adf - annular dark field + * Bf - bright filed + * Bse - backscattered electron + * Chamber - TV camera to monitor the stage and chamber + * Df - darkfield + * Diffrac - diffraction image + * Ecci - electron channel contrast imaging + * Kikuchi - electron backscatter diffraction (EBSD) + * Ronchigram - convergent beam diffraction pattern + * Se - secondary electron + :ref:`NXinteraction_vol_em`: A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. @@ -122,14 +121,13 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXspectrum_set_em_xray` :ref:`NXspectrum_set_em_auger` :ref:`NXspectrum_set_em_cathodolum`: - Base classes comparable to NXimage_set_em but for - different techniques resulting in spectra. - - * Auger spectroscopy - * Cathodoluminescence - * Electron energy loss spectroscopy (EELS) - * X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS) - + Base classes comparable to NXimage_set_em but for different techniques resulting in spectra. + + * Auger spectroscopy + * Cathodoluminescence + * Electron energy loss spectroscopy (EELS) + * X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS) + :ref:`NXstage_lab`: As it was mentioned for atom probe microscopy this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index 5cff20336a..e2a0e91f01 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -1,8 +1,8 @@ .. _Mpes-Structure: -=================================== -B2/B3: Photoemission & spectroscopy -=================================== +============================================== +B2/B3: Photoemission & core-level spectroscopy +============================================== .. index:: IntroductionMPES From 3a16d795492c2d63e6d59cc162d1e76598d8d1ec Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Sun, 4 Sep 2022 02:00:41 +0200 Subject: [PATCH 049/203] Fixed NXapm, NXion, and NXpulser_apm to reflect changes in apm parser for sprint9 --- contributed_definitions/NXapm.nxdl.xml | 449 ++++++++++-------- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXpulser_apm.nxdl.xml | 15 +- 3 files changed, 254 insertions(+), 214 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 24fbcd18f0..33a178e52b 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -81,7 +81,7 @@ experiments to e.g. proposals. - + Free-text description about the experiment. @@ -91,7 +91,7 @@ experiment into this free-text description field. - + ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. @@ -111,7 +111,7 @@ collected to compute this event chain during the experiment. - + ISO 8601 time code with local time zone offset to UTC included when the microscope session ended. @@ -210,7 +210,7 @@ contact the respective people in the FAIRmat team to fix this. - + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. @@ -222,7 +222,7 @@ respective groups and sections. - + A small image that is representative of the entry; this can be an image taken from the dataset like a thumbnail of a spectrum. @@ -254,7 +254,7 @@ - + Contact information and eventually details of at least one person involved in the taking of the microscope session. This can be the @@ -266,42 +266,42 @@ Given (first) name and surname of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Postal address of the affiliation. - + Email address of the user at the point in time when the experiment was performed. Writing the most permanently used email is recommended. - + Globally unique identifier of the user as offered by services like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform - + Name of the OrcID or ResearcherID where the account under orcid is registered. - + (Business) (tele)phone number of the user at the point in time when the experiment was performed. - + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating @@ -309,12 +309,12 @@ are common examples. - + Account name that is associated with the user in social media platforms. - + Name of the social media platform where the account under social_media_name is registered. @@ -379,7 +379,7 @@ better be placed in resources which describe the sample_history. - + Possibility to give an abbreviation of the specimen name field. @@ -395,20 +395,20 @@ these from the sample history or from other data sources. - + Discouraged free-text field in case properly designed records for the sample_history are not available. - + Hard link to a location in the hierarchy of the NeXus file where the data for default plotting are stored. - + Container to hold different coordinate systems conventions. @@ -457,9 +457,9 @@ Consult the work of A. J. Breen and B. Gault and team for further details. - + - + Metadata and numerical data of the atom probe and the lab in which it @@ -483,7 +483,7 @@ etc. - + Location of the lab or place where the instrument is installed. Using GEOREF is preferred. @@ -492,8 +492,8 @@ - - + + @@ -503,7 +503,7 @@ THIS DOCSTRING NEEDS CLARIFICATION. - + The nominal diameter of the specimen ROI which is measured in the experiment. It is important to mention that the physical specimen @@ -511,77 +511,35 @@ detected or hit elsewhere in the analysis_chamber. - - - + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + Average pressure in the analysis chamber. + + - + - Was the reflectron used? + Is a reflectron installed and was it used? - - + + - - + + - + @@ -592,15 +550,15 @@ Identifier of the local_electrode in an e.g. database. - - - + + + - - + + - + @@ -618,27 +576,27 @@ the detector type via free-text. - + Given name/alias. - + Given brand or model name by the manufacturer. - + Given hardware name/serial number or hash identifier issued by the manufacturer. - + Given name of the manufacturer. - + Amplitude of the signal detected on the multi-channel plate (MCP). @@ -653,91 +611,106 @@ - - - - - - - - - - + + + + + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the excitation and eventual field evaporation/emission of an ion during an experiment. - If pulse_mode is laser or laser_and_high_voltage - having the group/section laser_gun the following fields - have to be filled also and are not optional: + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: * name * wavelength - * power + * energy - + - - + + - - + + + + + + + - + - Average temperature at the specimen base, i.e. base temperature, during the - measurement. + Average temperature at the specimen base, i.e. + base_temperature during the measurement. - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - + + + + + + + + + + - Track time-dependent settings over the course of the measurement about the - environment in the analysis chamber such as gas pressure values etc. + Average pressure in the load_lock_chamber. - - - Average pressure in the analysis chamber. - - + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + + + + - + + + + + + + + + + A place where details about the initial shape of the specimen can be stored. Ideally, here also data about the shape evolution @@ -776,8 +749,77 @@ space z-axis and a vector on the lateral surface of the cone. + + + Average detection rate over the course of the experiment. + + - + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + Name of the control software of the microscope + used during acquisition (e.g. IVAS/APSuite). + + + + Program 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. + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + Details about where ions hit the ion_detector and data processing steps related to analog-to-digital conversion of detector signals @@ -806,7 +848,7 @@ - + Raw readings from the analog-to-digital-converter timing circuits of the detector wires. @@ -828,13 +870,8 @@ - - - Average detection rate over the course of the experiment. - - - + Data post-processing step which is, like the impact position analyses, usually executed in the integrated control software. This processing @@ -866,7 +903,7 @@ - + Number of pulses since the last detected ion pulse. For multi-hit records, after the first record, this is zero. @@ -875,7 +912,7 @@ - + Hit multiplicity. @@ -883,7 +920,7 @@ - + Number of pulses since the start of the atom probe run/evaporation sequence. @@ -892,7 +929,7 @@ - + Like impact position and hit multiplicity computations, ion filtering is a data post-processing step with which users @@ -926,7 +963,7 @@ - + Data post-processing step to correct for ion impact position flight path differences, detector biases, @@ -949,7 +986,7 @@ - + Raw time-of-flight data as read out from the acquisition software if these data are available and accessible. @@ -966,7 +1003,7 @@ - + The key idea and algorithm of the voltage-and-bowl correction is qualitatively similar for instruments of different manufacturers @@ -992,7 +1029,7 @@ - + Data post-processing step in which calibrated time-of-flight data (ToF) are interpreted into mass-to-charge-state ratios. @@ -1013,7 +1050,7 @@ - + Store vendor-specific calibration models here (if available). @@ -1027,7 +1064,7 @@ - + Data post-processing step to create a tomographic reconstruction of the specimen based on selected calibrated ion hit positions, @@ -1052,20 +1089,36 @@ - + Qualitative statement about which reconstruction protocol was used. - - + - - + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + Three-dimensional reconstructed positions of the ions. @@ -1076,15 +1129,6 @@ - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - To get a first overview of the reconstructed dataset, @@ -1145,7 +1189,7 @@ - + Data post-processing step in which elemental, isotopic, and/or molecular identities are assigned to the ions. @@ -1187,7 +1231,7 @@ Currently a value of 32 is used. - + Specifies the computation of the mass-to-charge histogram. Usually mass-to-charge values are studied as an ensemble quantity, @@ -1248,7 +1292,7 @@ - + Details of the background model which was used to correct the total counts per bin into counts. @@ -1270,7 +1314,7 @@ - + How where peaks in the background-corrected in the histogram of mass-to-charge-state ratio values identified? @@ -1291,12 +1335,12 @@ - - + + - + Details about how peaks, with taking into account error models, were interpreted as ion types or not. @@ -1319,14 +1363,9 @@ - - - - - - - - + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index c3a70793c3..110c8f4049 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -63,7 +63,7 @@ - + Signed charge state of the ion in multiples of electron charge. diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index f1f7ad30bf..f2fe3cbedc 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -21,16 +21,16 @@ - - + + - + Frequency with which the high voltage or laser pulser fires. - + Fraction of the pulse_voltage that is applied in addition to the standing_voltage at peak voltage of a pulse. @@ -38,7 +38,8 @@ - TO BE IMPROVED + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. @@ -74,7 +75,7 @@ - Average power of the laser source while illuminating the specimen. + Nominal power of the laser source while illuminating the specimen. From 3a3c35deb297a88a206f1084cfc9db06be8e03ee Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 5 Sep 2022 09:32:37 +0200 Subject: [PATCH 050/203] Updates NXellipsometry to use NXuser group instead of operator field --- contributed_definitions/NXellipsometry.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 7e04bc5cf8..3a4df7cb89 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -152,7 +152,7 @@ - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. From b0fe6458373e030549d3c89d4ef932e4796486c9 Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Mon, 5 Sep 2022 17:06:08 +0200 Subject: [PATCH 051/203] Renamed NXiv_temp to NXtransport. Added NXpid and other changes to base classes --- base_classes/NXinstrument.nxdl.xml | 1 + base_classes/NXsensor.nxdl.xml | 3 +- contributed_definitions/NXiv_temp.nxdl.xml | 397 ------------------- contributed_definitions/NXpid.nxdl.xml | 63 +++ contributed_definitions/NXtransport.nxdl.xml | 155 ++++++++ 5 files changed, 221 insertions(+), 398 deletions(-) delete mode 100644 contributed_definitions/NXiv_temp.nxdl.xml create mode 100644 contributed_definitions/NXpid.nxdl.xml create mode 100644 contributed_definitions/NXtransport.nxdl.xml diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index e385f3671d..249cbeda82 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -69,6 +69,7 @@ + .. index:: plotting diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index cdfc11ab04..4eaf594e7b 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -58,6 +58,7 @@ + @@ -72,7 +73,7 @@ Examples (suggestions but not restrictions): :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe + J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe :pH: Hg/Hg2Cl2 | Ag/AgCl | ISFET :Ion selective electrode: diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml deleted file mode 100644 index 1c185274e3..0000000000 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ /dev/null @@ -1,397 +0,0 @@ - - - - - - Variables used throughout the document, e.g. dimensions and important - parameters - - - - Number of elements in the scanned voltage array that were set during - the measurement - - - - - Number of additional variables read that are changed with the temperature - (can be understood as columns next to the temperature) - - - - - Number of different temperatures that are set - - - - - Application definition for temperature-dependent IV curve measurements. - - In this application definition, times should be specified always together - with an UTC offset. - - This is the application definition describing temperature dependent IV curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. - The application definition defines: - - elements of the experimental instrument - - calibration information if available - - parameters used to tune the state of the sample - - sample description - - - - - Version number to identify which definition of this application - definition was used for this entry/data. - - - - - NeXus NXDL schema to which this file conforms. - - - - URL where to find further material (documentation, examples) - relevant to the application definition - - - - - - - - - Unique identifier of the experiment, such as a (globally persistent) - unique identifier. The identifier is usually defined by the - facility or principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Description of the exact experiment performed. - - - - - UTC offset should be specifiec. - - - - - Define the program that was used to generate the results file(s) - with measured data and metadata. - - - - Commercial or otherwise defined given name of the program - (or a link to the instrument software). - - - - Either version with build number, commit hash, or description of an - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - Website of the software. - - - - - - - Contact information of at least the user of the instrument or the - investigator who performed this experiment. Adding multiple users if - relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when - the experiment was performed. - - - - - Full address (street, street number, ZIP, city, country) - of the user's affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - Official telephone number of the user. - - - - - - General properties of the temperature dependent IV curve - measurements equipment - - - - Specify the used voltage source used in the voltage - sweep for the IV measurement. - - - - Free-text desribing the model and make of the voltage source - which is used for the IV sweep measurement. - - - - - Custom name of the voltage source for the IV sweep given - by the user/institution. - - - - - Free-text describing the measurement performed in a few words. - - - - - Free-text describing the type of voltage setting: an internal sweep - using the functionality of the voltage supply, or a - set/wait/read/repeat mechanism. - - - - - An array of voltages that were set using this controller for every - data point recorded. - - - - - - - - - Specify the used current source used in the voltage sweep - for the IV measurement." - - - - Free-text desribing the model and make of the current source - which is used for the IV sweep measurement. - - - - - Custom name of the current source for the IV sweep given - by the user/institution - - - - - Free-text describing the measurement performed in a few words - - - - - Free-text describing the type of current measuring: an internal - sweep using the functionality of the voltage supply, - or a set/wait/read/repeat mechanism. - - - - - - Calibration of the temperature sensor is possible - - - - ISO8601 datum when calibration was last performed - before this measurement. UTC offset should be specified. - - - - - - Describes the system for controlling the temperature - if temperature control was used. - - - - What kind of temperature control was used? - PID, custom temp control? - - - - - Specify the settings of the PID temperature controller: - K_p, K_i, and K_d values used for the temperature control - - - - 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 contribution from the integral term is proportional to both - the magnitude of the error and the duration of the error. - The integral in a PID controller is the sum of the instantaneous - error over time and gives the accumulated offset that should have - been corrected previously. The accumulated error is then - multiplied by the integral gain (Ki) and added to the - controller output. - - - - - The derivative of the process error is calculated by determining - the slope of the error over time and multiplying this rate of - change by the derivative gain K_d. The magnitude of the - contribution of the derivative term to the overall control - action is termed the derivative gain, K_d - - - - - - Specify the temperature sensor that was used - - - - - - - - - - - If you specified 'other' as temperature sensor, - please write down what it is. - - - - - Data of the most principal measurement of the temperature. - For example resistance of a Pt1000. - - - - - - - - Algebraic function that is used to determine temperature from the - raw_temp_data. All values should be given in SI units. - - - - - An array of temperatures that were set using this controller for every - data point recorded. - - - - - - - - - - Properties of the sample, its history, the sample environment and - experimental conditions (e.g. surrounding medium, temperature, - pressure etc.), along with the data (data type, wavelength array, - measured data). - - - - Descriptive name of the sample - - - - - Ideally, a reference to the location or a unique (globally persistent) - identifier (e.g.) of e.g. another file which gives as many as possible - details of the material, its microstructure. In the case that such a - detailed history of the sample is not available, use this field as a - free-text description to specify details of the sample and its - preparation. - - - - - ISO 8601 date with time zone specified. UTC offset should be specified. - - - - - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0 - N - - - - - Resulting data from the measurement, described by data type. - - [Temp,Temp_raw,Current,Timestamp] - - - - - - - - - An array of strings to list all the variables in the data - in order of appearance in the last index of the 3D array. - - - - - - Information about external parameters that have influenced the sample. - - - - - Indicates which parameter was changed. Its definition must exist below. - The specified variable has to be number_of_runs long, - providing the parameters for each data set. - - - - - - - - - A default view of the data. The current (y-axis) should be plotted - against the voltage (x-axis) with color coding for the temperature - of each IV-curve. - - - - - - diff --git a/contributed_definitions/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml new file mode 100644 index 0000000000..2b74593996 --- /dev/null +++ b/contributed_definitions/NXpid.nxdl.xml @@ -0,0 +1,63 @@ + + + + + Contains the settings of a PID controller. + + + + Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. + + For example, a set of sensors could be averaged over before feeding it back into the loop. + + + + + The sensor representing the Process Value used in the feedback loop for the PID. + + In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. + + + + + The actual timeseries data fed back to the PID loop. + + + + + + + The Setpoint(s) used as an input for the PID controller. + + It can also be a link to an NXsensor.value field. + + + + + 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 contribution from the integral term is proportional to both + the magnitude of the error and the duration of the error. + The integral in a PID controller is the sum of the instantaneous + error over time and gives the accumulated offset that should have + been corrected previously. The accumulated error is then + multiplied by the integral gain (Ki) and added to the + controller output. + + + + + The derivative of the process error is calculated by determining + the slope of the error over time and multiplying this rate of + change by the derivative gain K_d. The magnitude of the + contribution of the derivative term to the overall control + action is termed the derivative gain, K_d + + + diff --git a/contributed_definitions/NXtransport.nxdl.xml b/contributed_definitions/NXtransport.nxdl.xml new file mode 100644 index 0000000000..fa959fa958 --- /dev/null +++ b/contributed_definitions/NXtransport.nxdl.xml @@ -0,0 +1,155 @@ + + + + + Application definition for temperature-dependent IV curve measurements. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature dependent IV curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + The application definition defines: + - elements of the experimental instrument + - calibration information if available + - parameters used to tune the state of the sample + - sample description + + + + + + + + + + + + + + Define the program that was used to generate the results file(s) + with measured data and metadata. + + + + Commercial or otherwise defined given name of the program + (or a link to the instrument software). + + + + Either version with build number, commit hash, or description of an + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when + the experiment was performed. + + + + + Full address (street, street number, ZIP, city, country) + of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + Official telephone number of the user. + + + + + + + Describes an environment setup for the experiment. + + All the setting values of the independently scanned controllers are listed under corresponding + NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each + measurement sensor. + + For example, in a temperature-dependent IV measurement, the temperature and voltage must be + present as independently scanned controllers and the current sensor must also be present with + its readings. + + + + + nominal setpoint or average value + - need [n] as may be a vector + + For each point in the scan space, either the nominal setpoint of an independently scanned controller or a representative average value of a measurement sensor is registered. + In case of a full multi-dimensional scan, the length of the scan space [n] is the product of the number of setpoints along all independently scanned controllers. + + + + + + Free-text describing the data acquisition control: an internal + sweep using the built-in functionality of the controller device, + or a set/wait/read/repeat mechanism. + + + + + + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. + + + + + + + A list of names of NXsensor groups used as independently scanned controllers. + + + + + A list of names of NXsensor groups used as measurement sensors. + + + + + + + + + + + + + From 3f17ff0c54c4c031fcfa5d367f99d2e642f6e3fd Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Tue, 6 Sep 2022 09:27:47 +0200 Subject: [PATCH 052/203] Fix issue with NXtransport having two rec attributes --- contributed_definitions/NXtransport.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/NXtransport.nxdl.xml b/contributed_definitions/NXtransport.nxdl.xml index fa959fa958..fdb37ed42b 100644 --- a/contributed_definitions/NXtransport.nxdl.xml +++ b/contributed_definitions/NXtransport.nxdl.xml @@ -81,7 +81,7 @@ Email address of the user. - + Author ID defined by https://orcid.org/. From 99134900973228eb5062b5b06877c91ae61c0e1a Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Wed, 7 Sep 2022 13:31:45 +0200 Subject: [PATCH 053/203] Added NXsensor_scan and extended NXiv_temp from it --- contributed_definitions/NXiv_temp.nxdl.xml | 62 +++++++++++++++++++ ...nsport.nxdl.xml => NXsensor_scan.nxdl.xml} | 43 +++++++------ 2 files changed, 86 insertions(+), 19 deletions(-) create mode 100644 contributed_definitions/NXiv_temp.nxdl.xml rename contributed_definitions/{NXtransport.nxdl.xml => NXsensor_scan.nxdl.xml} (78%) diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml new file mode 100644 index 0000000000..2045744dd9 --- /dev/null +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -0,0 +1,62 @@ + + + + + + + Number of different temperature setpoints used in the experiment. + + + + + Number of different voltage setpoints used in the experiment. + + + + + Application definition for temperature-dependent IV curve measurements. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature dependent IV curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + + + + + + + + + + + Describes an environment setup for a temperature-dependent IV measurement experiment. + + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + + + + + + + + + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + + + + + + + + + + + diff --git a/contributed_definitions/NXtransport.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml similarity index 78% rename from contributed_definitions/NXtransport.nxdl.xml rename to contributed_definitions/NXsensor_scan.nxdl.xml index fdb37ed42b..bb47ed8f27 100644 --- a/contributed_definitions/NXtransport.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -1,32 +1,23 @@ - + - Application definition for temperature-dependent IV curve measurements. + Application definition for a generic scan using sensors. In this application definition, times should be specified always together with an UTC offset. - - This is the application definition describing temperature dependent IV curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. - The application definition defines: - - elements of the experimental instrument - - calibration information if available - - parameters used to tune the state of the sample - - sample description - + + Define the program that was used to generate the results file(s) @@ -106,13 +97,25 @@ its readings. + + + Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. + + - nominal setpoint or average value - - need [n] as may be a vector + For each point in the scan space, either the nominal setpoint of an independently scanned controller + or a representative average value of a measurement sensor is registered. + In case of a full multi-dimensional scan, the length of the scan space [n] is the product of the number + of setpoints along all independently scanned controllers. + + + + + Timestamp for when the values provided in the value field were registered. - For each point in the scan space, either the nominal setpoint of an independently scanned controller or a representative average value of a measurement sensor is registered. - In case of a full multi-dimensional scan, the length of the scan space [n] is the product of the number of setpoints along all independently scanned controllers. + Individual readings can be stored with their timestamps under value_log. This is to timestamp + the nominal setpoint or average reading values listed above in the value field. @@ -148,8 +151,10 @@ - - + + A scan specific representation of the measured signals as a function of the independently controlled environment settings. + Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. + From ff0c0c7f33f1c32860af36c497fc7b58c0124ab0 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Wed, 7 Sep 2022 14:20:43 +0200 Subject: [PATCH 054/203] consolidated sprint9 results for appdefs/base classes for apm, em, shape/geometry, microstructures, paraprobe --- .../NXaperture_em.nxdl.xml | 6 +- contributed_definitions/NXapm.nxdl.xml | 40 +- .../NXapm_evaporation_id_filter.nxdl.xml | 27 -- .../NXapm_hitmultiplicity_filter.nxdl.xml | 42 -- .../NXapm_input_ranging.nxdl.xml | 4 +- .../NXapm_input_reconstruction.nxdl.xml | 4 +- .../NXapm_iontype_filter.nxdl.xml | 41 -- .../NXapm_paraprobe_config_clusterer.nxdl.xml | 283 +++++++++++++ .../NXapm_paraprobe_config_distancer.nxdl.xml | 52 +-- ...Xapm_paraprobe_config_intersector.nxdl.xml | 24 +- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 51 ++- .../NXapm_paraprobe_config_ranger.nxdl.xml | 38 +- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 284 +++++++++++++ .../NXapm_paraprobe_config_surfacer.nxdl.xml | 34 +- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 36 +- ...NXapm_paraprobe_config_transcoder.nxdl.xml | 8 +- .../NXapm_paraprobe_results_ranger.nxdl.xml | 110 +++-- ...Xapm_paraprobe_results_transcoder.nxdl.xml | 102 +++-- ..._atom_set.nxdl.xml => NXatom_set.nxdl.xml} | 2 +- .../NXcg_alpha_shape.nxdl.xml | 4 +- .../NXcg_cylinder_set.nxdl.xml | 6 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 4 +- .../NXcg_geodesic_mesh.nxdl.xml | 4 +- contributed_definitions/NXcg_grid.nxdl.xml | 4 +- .../NXcg_half_edge_data_structure.nxdl.xml | 4 +- .../NXcg_hexahedron_set.nxdl.xml | 6 +- .../NXcg_isocontour.nxdl.xml | 4 +- .../NXcg_marching_cubes.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 6 +- .../NXcg_point_set.nxdl.xml | 4 +- .../NXcg_polygon_set.nxdl.xml | 4 +- .../NXcg_polyhedron_set.nxdl.xml | 4 +- .../NXcg_polyline_set.nxdl.xml | 4 +- contributed_definitions/NXcg_roi_set.nxdl.xml | 4 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 4 +- .../NXcg_unit_normal_set.nxdl.xml | 4 +- contributed_definitions/NXchamber.nxdl.xml | 4 +- contributed_definitions/NXclustering.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 2 +- .../NXcorrector_cs.nxdl.xml | 4 +- .../NXcs_computer.nxdl.xml | 5 +- contributed_definitions/NXcs_cpu.nxdl.xml | 6 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu.nxdl.xml | 6 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 6 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 4 +- contributed_definitions/NXcs_prng.nxdl.xml | 8 +- .../NXcs_profiling.nxdl.xml | 19 +- .../NXcs_profiling_event.nxdl.xml | 14 +- ...ion.nxdl.xml => NXdelocalization.nxdl.xml} | 4 +- .../NXebeam_column.nxdl.xml | 8 +- contributed_definitions/NXem.nxdl.xml | 390 ++++++++---------- .../NXevent_data_em.nxdl.xml | 8 +- .../NXevent_data_em_set.nxdl.xml | 2 +- ...cturer.nxdl.xml => NXfabrication.nxdl.xml} | 8 +- .../NXgraph_edge_set.nxdl.xml | 2 +- .../NXgraph_node_set.nxdl.xml | 2 +- contributed_definitions/NXgraph_root.nxdl.xml | 2 +- .../NXibeam_column.nxdl.xml | 4 +- .../NXimage_set_em_adf.nxdl.xml | 2 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- .../NXmatch_filter.nxdl.xml | 42 ++ .../NXms_crystal_set.nxdl.xml | 4 +- .../NXms_snapshot.nxdl.xml | 4 +- .../NXms_snapshot_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 44 +- ...et.nxdl.xml => NXorientation_set.nxdl.xml} | 4 +- contributed_definitions/NXpeak.nxdl.xml | 2 +- contributed_definitions/NXpulser_apm.nxdl.xml | 6 +- contributed_definitions/NXpump.nxdl.xml | 4 +- contributed_definitions/NXreflectron.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 4 +- ...et.nxdl.xml => NXslip_system_set.nxdl.xml} | 2 +- ...ter.nxdl.xml => NXspatial_filter.nxdl.xml} | 24 +- .../NXspectrum_set_em_eels.nxdl.xml | 2 +- .../NXspectrum_set_em_xray.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 4 +- .../NXsubsampling_filter.nxdl.xml | 26 ++ .../NXtransmission.nxdl.xml | 8 +- manual/source/apm-structure.rst | 8 +- manual/source/cgms-structure.rst | 10 +- manual/source/em-structure.rst | 25 +- manual/source/fairmat-cover.rst | 98 +---- manual/source/north-structure.rst | 32 +- 89 files changed, 1261 insertions(+), 902 deletions(-) delete mode 100644 contributed_definitions/NXapm_evaporation_id_filter.nxdl.xml delete mode 100644 contributed_definitions/NXapm_hitmultiplicity_filter.nxdl.xml delete mode 100644 contributed_definitions/NXapm_iontype_filter.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml rename contributed_definitions/{NXms_atom_set.nxdl.xml => NXatom_set.nxdl.xml} (62%) rename contributed_definitions/{NXms_delocalization.nxdl.xml => NXdelocalization.nxdl.xml} (93%) rename contributed_definitions/{NXmanufacturer.nxdl.xml => NXfabrication.nxdl.xml} (63%) create mode 100644 contributed_definitions/NXmatch_filter.nxdl.xml rename contributed_definitions/{NXms_orientation_set.nxdl.xml => NXorientation_set.nxdl.xml} (91%) rename contributed_definitions/{NXms_slip_system_set.nxdl.xml => NXslip_system_set.nxdl.xml} (87%) rename contributed_definitions/{NXapm_spatial_filter.nxdl.xml => NXspatial_filter.nxdl.xml} (61%) create mode 100644 contributed_definitions/NXsubsampling_filter.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 5fbae08d4d..20b4db8000 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -1,15 +1,14 @@ - + - Details of an individual aperture for electron beams. + Details of an individual aperture for beams in electron microscopy. Given name/alias of the aperture. - Relevant value from the control software. @@ -28,6 +27,7 @@ resource which gives further details. Alternatively a free-text field. + Affine transformation which detail the arrangement in the diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 33a178e52b..acbf7047d1 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -489,9 +489,7 @@ Using GEOREF is preferred. - - - + @@ -513,9 +511,7 @@ - - - + @@ -533,9 +529,7 @@ - - - + @@ -552,9 +546,7 @@ - - - + @@ -630,9 +622,7 @@ * energy - - - + @@ -655,9 +645,7 @@ - - - + @@ -670,9 +658,7 @@ - - - + @@ -685,27 +671,21 @@ - - - + - - - + - - - + diff --git a/contributed_definitions/NXapm_evaporation_id_filter.nxdl.xml b/contributed_definitions/NXapm_evaporation_id_filter.nxdl.xml deleted file mode 100644 index 4a5f4e66d6..0000000000 --- a/contributed_definitions/NXapm_evaporation_id_filter.nxdl.xml +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Settings for a filter to select ions based on their evaporation (sequence) ID. - - - - Triplet of the minimum, increment, and maximum evaporation ID which will - be included in the analysis. - The increment controls which n-th ion to take. - - Take as an example a dataset with 100 ions and the filter set to 0, 1, 99. - This will process each ion. 0, 2, 99 will take each second ion. - 90, 3, 99 will take only each third ion beginning from evaporation ID (90 - up to 99. - - - - - - diff --git a/contributed_definitions/NXapm_hitmultiplicity_filter.nxdl.xml b/contributed_definitions/NXapm_hitmultiplicity_filter.nxdl.xml deleted file mode 100644 index 9be956dc8f..0000000000 --- a/contributed_definitions/NXapm_hitmultiplicity_filter.nxdl.xml +++ /dev/null @@ -1,42 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - How many different multiplicity values does the filter specify. - - - - - Settings for a filter to select ions based on their hit multiplicity. - - - - Meaning of the filter: - Whitelist specifies which ions with said hit multiplicity to include. - Ions with all other hit multiplicity will be filtered out. - - Blacklist specifies which ions with said hit multiplicity to exclude. - Ions of all other hit multiplicity will be included. - - - - - - - - - Array of hit multiplicity values to filter according to method. - For example if the filter specifies [1, 5, 6] and method is whitelist, - only ions with hit multiplicity 1, 5 or 6 will be processed and all - other ions will be filtered out. - - - - - - diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml index 34ea718cb3..b45bc6a651 100644 --- a/contributed_definitions/NXapm_input_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_input_ranging.nxdl.xml @@ -1,8 +1,8 @@ - + - Metadata to ranging definitions made for an atom probe dataset. + Metadata to ranging definitions made for a dataset in atom probe microscopy. diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml index 3a59fe1242..95ee5ae096 100644 --- a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml @@ -1,8 +1,8 @@ - + - Metadata to a reconstructed dataset. + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. diff --git a/contributed_definitions/NXapm_iontype_filter.nxdl.xml b/contributed_definitions/NXapm_iontype_filter.nxdl.xml deleted file mode 100644 index 30bdabc143..0000000000 --- a/contributed_definitions/NXapm_iontype_filter.nxdl.xml +++ /dev/null @@ -1,41 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - How many iontypes does the iontypes_filter specify. - - - - - Settings for a filter to select ions based on their iontype. - - - - Meaning of the filter: - Whitelist specifies which iontypes to include. - Ions of all other types will be filtered out. - - Blacklist specifies which iontypes to exclude. - Ions of all other types will be included. - - - - - - - - - Array of iontypes to filter according to method. - For example if the candidates are [0, 3] only ions of the type - unrange/unknown and the third ion type are used. - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml new file mode 100644 index 0000000000..7c4189af85 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -0,0 +1,283 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of position values. + + + + + Number of disjoint cluster. + + + + + Configuration of a paraprobe-clusterer tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many clustering processes should the tool execute. + + + + + This process maps results from cluster analyses performed with IVAS/APSuite + into an interoperable representation. Specifically in this process + paraprobe-clusterer takes results from clustering methods from other tools + of the APM community, like IVAS/APSuite. These results are usually reported + in two ways. Either as an explicit list of reconstructed ion positions. + In the case of IVAS these positions are reported through a text file + with a cluster label for each position. + + Alternatively, the list of positions is reported, as it is the case for + AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly + only in the following way: The mass-to-charge-state ratio column of a + what is effectively a file formatted like POS is used to assign a hypothetical + mass-to-charge value which resolves a floating point representation + of the cluster ID. + + Another case can occur where all disjoint floating point values, + i.e. here cluster labels, are reported and then a dictionary is created + how each value matches to a cluster ID. + + In general the cluster ID zero is reserved for marking the dataset + as to not be assigned to any cluster. Therefore, indices of disjoint + clusters start at 1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Name of HDF5 file which stores reconstructed ion positions. + This file should have been generated by from the community or vendor format. + This file not necessarily contains all the of the dataset because + spatial filters might have been applied in commercial software prior + to executing the cluster analysis so that e.g. only positions within a + ROI are reported by the commercial software. + POS files from IVAS have to be converted first. + + + + + Name of the dataset inside the HDF5 file ion_position_filename + which refers to the specific positions to use for this analysis. + The referred to dataset has to be formatted as an array of shape + (n_positions, 3). + + + + + Name of the HDF5 file which stores mass-to-charge-state-ratio values + (in the case of IVAS/APSuite) or other numbers which can be interpreted + as cluster labels. + + + + + Name of the dataset inside the HDF5 file cluster_indices_filename + which refers to the specifically encoded cluster indices. + The referred to dataset has to be formatted as an array of shape + (n_positions, 1). + + + + + The list of all keywords of a dictionary which maps implicit cluster + indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + + + + + + + + The list of all values of a dictionary which maps implicit cluster + indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + The sequences of mapping_dictionary_keyword and mapping_dictionary_value + have to match. + + + + + + + + Specifies if the tool should try to recover for each position the closest + matching position from dataset/dataset_name_reconstruction (within + floating point accuracy). This can be useful for instance when users + wish to recover the original evaporation ID which IVAS/AP Suite drops + for instance when writing their *.indexed.* cluster results files. + + + + + Specifies if the tool should try to recover, after a recovery of the + evaporation IDs a bitmask which identifies which of the positions + in dataset/dataset/dataset_name_reconstruction where covered + by the IVAS/APSuite cluster analysis. This can be useful to recover + the region of interest. + + + + + + This process performs a cluster analysis on a reconstructed dataset + or a portion of the reconstruction. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Name of the algorithm. + + + + + A text representation like a JSON/YAML dictionary with the + parameter of the clustering_algorithm. + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml index 06697398ba..ca5c578680 100644 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -38,21 +38,21 @@ - + - Ideally, a (globally persistent) unique identifier for referring - to this analysis. + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. - + - Possibility for leaving a free-text description about this analysis. + Ideally, a (globally persistent) unique identifier for referring + to this analysis. - + - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. + Possibility for leaving a free-text description about this analysis. @@ -74,9 +74,9 @@ - - - + + + @@ -84,7 +84,7 @@ - + @@ -92,30 +92,22 @@ - + - + - - - - - - - - - - - + + + Paraprobe-distancer enables the computation of the Euclidean shortest @@ -142,6 +134,8 @@ Facet indices refer to vertex indices. These need to start at zero and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 and vertices are indexed thus implicitly. + Facet normal vectors have to be also an array + of shape (Nfacets, 3) of NX_FLOAT. @@ -178,6 +172,12 @@ specifies the array of facet indices. + + + Absolute HDF5 path to the dataset which + specifies the array of facet normal vectors. + + diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml index b43ea444d0..4175c48d4d 100644 --- a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,7 +12,7 @@ - Configuration/settings of a paraprobe-intersector software tool run. + Configuration of a paraprobe-intersector tool run in atom probe microscopy. @@ -43,13 +43,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -142,7 +142,7 @@ perform as part of the high-throughput analysis. - + Tracking is the process of building logical relations between objects based on proximity and mesh intersections. For each time step pairs @@ -219,20 +219,20 @@ respectively from. - + Like groupname_object_geometry_data but for the proxies. Triangulated surface meshes of proxies have to be formatted in the same manner as objects. - + Like groupname_proxy_supplementary_data but for the interior proxies. Leave an empty string if proxies should not be used. - + Like groupname_proxy_supplementary_data but for the exterior proxies. Leave an empty string if proxies should not be used. @@ -256,7 +256,7 @@ Name of the HDF5 file which contain geometry (vertex coordinates, - facet indices) and properties (ions, composition) of + facet indices) and properties (ions, composition) of polyhedra(l objects) which should be included in the current set. The user has to ensure that the datasets that are referred to under list_of_dataset_names (vertices, facet_indices, ions). @@ -307,7 +307,7 @@ respectively from. - + Like groupname_object_geometry_data but for the proxies. Triangulated surface meshes of proxies have to be formatted @@ -315,13 +315,13 @@ be used. - + Like groupname_proxy_supplementary_data but for the interior proxies. Leave an empty string if proxies should not be used. - + Like groupname_proxy_supplementary_data but for the exterior proxies. Leave an empty string if proxies should not be used. diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml index beef622e76..85a0af339e 100644 --- a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -32,7 +32,7 @@ - Configuration/settings of a paraprobe-nanochem software tool run. + Configuration of a paraprobe-nanochem tool run in atom probe microscopy. @@ -63,13 +63,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -99,9 +99,9 @@ - - - + + + @@ -109,7 +109,7 @@ - + @@ -117,30 +117,25 @@ - + - + - - - - - - - - + + - + + The tool enables to inject a previously computed triangle soup or @@ -175,7 +170,7 @@ - + The tool enables to inject precomputed distance information for each point/ion which can be used for further post-processing and analysis. @@ -205,7 +200,7 @@ files are executed as part of the high-throughput analysis. - + Discretization of the ion point cloud on a three-dimensional grid. @@ -303,7 +298,7 @@ Specifies if the tool should report the delocalization 3D field values. - + Optional computation of iso-surfaces after each computed delocalization to identify for instance objects in the microstructure @@ -570,7 +565,7 @@ - + Analyses of interfacial excess. @@ -648,7 +643,7 @@ - + The interface model is the result of a previous (set of) processing steps as a result of which the user has created a triangulated @@ -682,7 +677,7 @@ Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of reproducibility from which file specifically - contains these data." + contains these data. @@ -730,7 +725,7 @@ - + Create a simple principle component analysis (PCA) to mesh a free-standing interface patch through a point cloud of decorating solutes. @@ -870,7 +865,7 @@ - + Functionalities for placing regions-of-interest (ROIs) in the dataset or at specific microstructural features to characterize composition @@ -953,7 +948,7 @@ - + The tool enables to inject precomputed distance information for each point which can be used for further post-processing and analysis. diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml index 97056a3dc0..dff01815f1 100644 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -18,7 +18,7 @@ - Configuration/settings of a paraprobe-ranger software tool run. + Configuration of a paraprobe-ranger tool run in atom probe microscopy. @@ -49,13 +49,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -78,7 +78,7 @@ the tool execute as part of the analysis. - + @@ -92,9 +92,9 @@ - - - + + + @@ -102,7 +102,7 @@ - + @@ -110,32 +110,24 @@ - + - + - - - - - - - - - - - + + + - + A list of pairs of number of protons and either the value 0 (per row) diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml new file mode 100644 index 0000000000..a6ab596b15 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -0,0 +1,284 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of different sources iontypes to distinguish. + + + + + Number of different target iontypes to distinguish. + + + + + Configuration of a paraprobe-spatstat tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distances of each ion to a + representation of the edge of the dataset which can be used to + control and substantially reduce edge effects when computing spatial statistics. + + + + Name of an HDF5 file which contains ion-to-edge distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-edge distance values for each ion. + The shape of the distance values has to match the length + of the ion positions array in dataset/dataset_name_reconstruction + and dataset_name_mass_to_charge respectively. + + + + + + In addition to spatial filtering, and considering how far ions lie + to the edge of the dataset, it is possible to restrict the analyses + to a sub-set of ions within a distance not farther away to a feature than + a threshold value. + + + + Name of an HDF5 file which contains ion-to-feature distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-feature distance values for each ion. + + + + + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + + + + + + + + + + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + + + + + + + + + Specifies which spatial statistics to compute. + + + + Compute k-th nearest neighbour statistics. + + + + Order k. + + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml index 6c827ed70b..d145abafa3 100644 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,7 +12,7 @@ - Configuration/settings of a paraprobe-surfacer software tool run. + Configuration of a paraprobe-surfacer tool run in atom probe microscopy. @@ -43,13 +43,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -80,9 +80,9 @@ - - - + + + @@ -90,7 +90,7 @@ - + @@ -98,30 +98,22 @@ - + - + - - - - - - - - - - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml index 56694ac64a..80af129154 100644 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Configuration/settings of a paraprobe-tessellator software tool run. + Configuration of a paraprobe-tessellator tool run in atom probe microscopy. @@ -38,13 +38,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -74,9 +74,9 @@ - - - + + + @@ -84,7 +84,7 @@ - + @@ -92,31 +92,23 @@ - + - + - - - - - - - - - - - - + + + + The tool enables to inject precomputed distance information for each point which can be used for further post-processing and analysis. diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml index 0641b5af8c..16122838e5 100644 --- a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Configuration/settings of a paraprobe-transcoder software tool run. + Configurations of a paraprobe-transcoder tool run in atom probe microscopy. @@ -38,13 +38,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml index d5c5d425ad..285188b68c 100644 --- a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -17,7 +17,7 @@ - Results of a paraprobe-ranger software tool run. + Results of a paraprobe-ranger tool run in atom probe microscopy. @@ -48,13 +48,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -76,27 +76,27 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - + + + + + + + + + - + Details about the coordinate system conventions used. - + The individual coordinate systems which used. fields should be prefixed with a prefix taken from an @@ -112,7 +112,7 @@ - + Paraprobe-ranger loads the iontypes and evaluates for each ion on which iontype it matches. If it matches on none, the @@ -120,7 +120,7 @@ respective value in the iontypes array. - + @@ -132,7 +132,7 @@ - + Paraprobe-ranger performs a combinatorial search over all possible or a reduced set of nuclids to identify @@ -158,7 +158,7 @@ - + The mass of each molecular ion without considering relativistic or quantum effects. @@ -175,7 +175,7 @@ - + The product of the natural abundance of the isotopes building each molecular ion. Further details are available in @@ -185,7 +185,7 @@ - + The product of the natural abundance of the isotopes building each molecular ion. Further details are available in @@ -195,7 +195,7 @@ - + The number of disjoint nuclids for each molecular ion. @@ -203,7 +203,7 @@ - + The number of nuclids for each molecular ion. @@ -213,57 +213,51 @@ - - - - + + + + - - + + - - - - - - - - + + + + + + - - - - - - - + + + + + - + - - + + - - - - - - + + + + - - + + @@ -284,8 +278,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml index abd732d3fe..2a763afe73 100644 --- a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Results of a paraprobe-transcoder software tool run. + Results of a paraprobe-transcoder tool run in atom probe microscopy. @@ -38,13 +38,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -66,27 +66,27 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - + + + + + + + + + Details about the coordinate system conventions used. - + The individual coordinate systems which used. fields should be prefixed with a prefix taken from an @@ -101,7 +101,7 @@ - + Paraprobe-transcoder prepares the data in POS, ePOS, APT files from APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can @@ -114,72 +114,66 @@ - + This is the collection of iontypes distinguished. The default unknown iontype always has to map to 0. Its non-physical mass_to_charge_state_ratio is [0., 0.001] Da. - + - + - + - - - - + + + + - - + + - - - - - - - - + + + + + + - - - - - - - + + + + + - + - - + + - - - - - - + + + + - - + + @@ -200,8 +194,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/NXms_atom_set.nxdl.xml b/contributed_definitions/NXatom_set.nxdl.xml similarity index 62% rename from contributed_definitions/NXms_atom_set.nxdl.xml rename to contributed_definitions/NXatom_set.nxdl.xml index d0c09c1ec4..1585bb90c6 100644 --- a/contributed_definitions/NXms_atom_set.nxdl.xml +++ b/contributed_definitions/NXatom_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_alpha_shape.nxdl.xml b/contributed_definitions/NXcg_alpha_shape.nxdl.xml index 3cd4eda061..098047e716 100644 --- a/contributed_definitions/NXcg_alpha_shape.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_shape.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -27,7 +27,7 @@ - Base class documenting an alpha shape or alpha wrapping to a primitive set. + Computational geometry description of alpha shapes or wrappings to primitives. For details see: diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index a9814005c0..e1d2a5d2ee 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,7 +12,7 @@ - Set of cylinders or (truncated cones) in Euclidean space. + Computational geometry description of a set of cylinders in Euclidean space. The members of the set can have different size. For each member the position of the center and the height is mandatory. The radius can either be defined @@ -65,7 +65,7 @@ - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index ae4e52787a..1fdd2d6262 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -18,7 +18,7 @@ - Set of (d-dimensional) ellipsoids in Euclidean space. + Computational geometry description of a set of ellipsoids in Euclidean space. Individual ellipsoids can have different half axes. diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 6ca4653e14..523113eca2 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -37,7 +37,7 @@ - Simple class for storing vertices and face lists for geometric primitives. + Computational geometry description of geometric primitives via a face and edge list. Primitives must not be degenerated or self-intersect. Such descriptions of primitives are frequently used for triangles and polyhedra diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index e469a9a695..ad14400595 100644 --- a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Metadata and data about a geodesic mesh. + Computational geometry description of a geodesic mesh. People from geodesic/surveyors will likely have specific demands and different views about what should be included in such a base class, given diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index b09543c532..e6cf52dc6c 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -22,7 +22,7 @@ - A d-dimensional grid of Wigner-Seitz cells in Euclidean space. + Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. Frequently convenient three-dimensional grids with cubic cells are used. Exemplar applications are spectral-solver based crystal plasticity diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index 5844ab2447..b8fd46e631 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -27,7 +27,7 @@ - Half-edge data structure for polygon meshes in Euclidean space. + Computational geeometry description of a half-edge data structure. Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index 07ac124084..4a792fc9e0 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,7 +12,7 @@ - A set of hexahedra in 3D Euclidean space. + Computational geometry description of a set of hexahedra in Euclidean space. The hexahedra do not have to be connected, can have different size, can intersect, and be rotated. @@ -182,7 +182,7 @@ - + diff --git a/contributed_definitions/NXcg_isocontour.nxdl.xml b/contributed_definitions/NXcg_isocontour.nxdl.xml index 04db89a8ad..33c1b91785 100644 --- a/contributed_definitions/NXcg_isocontour.nxdl.xml +++ b/contributed_definitions/NXcg_isocontour.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,7 +12,7 @@ - Data/metadata of isocontouring/phase-fields in discretized Euclidean space. + Computational geometry description of isocontouring/phase-fields in Euclidean space. Iso-contouring algorithms such as MarchingCubes and others are frequently used to segment d-dimensional regions into regions where intensities are diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index 354913182c..8507bc65cf 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Metadata and data for a specifically used marching cubes algorithm. + Computational geometry description of the marching cubes algorithm. Documenting which specific version was used can help to understand how robust the results are with respect to the topology of the triangulation. diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index 17aee16ee4..16f9882592 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,7 +12,7 @@ - A set of parallelograms in 2D Euclidean space. + Computational geometry description of a set of parallelograms in Euclidean space. The parallelograms do not have to be connected, can have different size, can intersect, and be rotated. @@ -138,7 +138,7 @@ - + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml index 30454ada3c..00992a29e9 100644 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -17,7 +17,7 @@ - A set of points or point-like objects in d-dimensional Euclidean space. + Computational geometry description of a set of points in Euclidean space. The relevant coordinate system should be referred to in the NXtransformations instance. Points may have an associated time value; however users are advised diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 55a95b5e1c..a123688ad0 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -22,7 +22,7 @@ - A set of d-dimensional polygons arranged in Euclidean space. + Computational geometry description of a set of polygons in Euclidean space. Polygons are related are specialized polylines: diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 5e5d2efb1e..d4ba85531d 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -22,7 +22,7 @@ - A set of polyhedra in 3D Euclidean space. + Computational geometry description of a polyhedra in Euclidean space. Polyhedra, also so-called cells (especially in the convex of tessellations), here described have to be all non-degenerated, closed, built of and thus diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index 8e8d889f1e..994f46ba32 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -27,7 +27,7 @@ - A set of polylines in d-dimensional Euclidean space. + Computational geometry description of a set of polylines in Euclidean space. Each polyline is built from a sequence of vertices (points with identifiers). Each polyline must have a start and an end point. diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml index cdfae6d912..e6a865e20b 100644 --- a/contributed_definitions/NXcg_roi_set.nxdl.xml +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - A base class to hold geometric primitives. + Base class to hold geometric primitives. diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index b36035a2b4..845dd3a4d4 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -17,7 +17,7 @@ - Set of d-dimensional circles/spheres in Euclidean space. + Computational geometry description of a set of spheres in Euclidean space. Each sphere can have a different radius. diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 013996c9bf..878afc1e7c 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,7 +12,7 @@ - A set of tetrahedra (possibly differently sized) in 3D Euclidean space. + Computational geometry description of a set of tetrahedra in Euclidean space. The tetrahedra do not have to be connected. As tetrahedral elements they are among hexahedral elements one of the most diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index cb28371c10..4bf5b5fc6d 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -22,7 +22,7 @@ - A set of d-dimensional triangles in Euclidean space. + Computational geometry description of a set of triangles in Euclidean space. diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index 923198343e..b7da75a056 100644 --- a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - A mesh of triangles. + Computational geometry description of a mesh of triangles. The mesh may be self-intersecting and have holes but the triangles must not be degenerated. diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index bea52e9d29..4f28279b07 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -17,7 +17,7 @@ - A set of (oriented) unit normal vectors. + Computational geometry description of a set of (oriented) unit normal vectors. diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml index 4a6973cc81..303ef0c503 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -1,6 +1,6 @@ - + Component of an instrument to store or place objects and specimens. @@ -9,11 +9,11 @@ Given name/alias. - Free-text field for describing details about the chamber. For example out of which material was the chamber built. + diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml index 475b21e477..1fa70e8d1d 100644 --- a/contributed_definitions/NXclustering.nxdl.xml +++ b/contributed_definitions/NXclustering.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index 3e1d15e101..e3444193c1 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -1,6 +1,6 @@ - + Container to hold different coordinate systems conventions. diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 47e10cf9f7..3b9fe1d423 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -1,6 +1,6 @@ - + Corrector for aberrations in an electron microscope. @@ -26,7 +26,7 @@ Given name/alias. - + Ideally, a (globally) unique persistent identifier, link, diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index 75c67c6e89..260c33f6cb 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -1,14 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. + Computer science description of a set of computing nodes. diff --git a/contributed_definitions/NXcs_cpu.nxdl.xml b/contributed_definitions/NXcs_cpu.nxdl.xml index fbf57956e0..a9a1019b6c 100644 --- a/contributed_definitions/NXcs_cpu.nxdl.xml +++ b/contributed_definitions/NXcs_cpu.nxdl.xml @@ -1,18 +1,18 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Base class representing a central processing unit (CPU) of a computer. + Computer science description of a central processing unit (CPU) of a computer. Given name of the CPU. Users should be as specific as possible. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index f3486dab78..99104338ab 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -22,7 +22,7 @@ - A base class to represent a description for packing and unpacking booleans. + Computer science base class for packing and unpacking booleans. One use case is processing of object sets (like point cloud data). When one applies e.g. a spatial filter to a set of points to define which diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml index 538791d1a9..265052e84f 100644 --- a/contributed_definitions/NXcs_gpu.nxdl.xml +++ b/contributed_definitions/NXcs_gpu.nxdl.xml @@ -1,18 +1,18 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Base class representing a graphic processing unit (GPU) of a computer. + Computer science description of a graphic processing unit (GPU) of a computer. Given name of the GPU. Users should be as specific as possible. - + diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index c15e9d5526..9f66793b19 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - A component of an input/output sub-system which can store binary data. + Computer science description of a storage object in an input/output system. @@ -29,5 +29,5 @@ Given name to the I/O unit. - + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 1321f6ec41..f80109d43d 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Base class for an input/output sub-system of a computer. + Computer science description of system of a computer. diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index bd0b7fa406..d61664c8bd 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Base class representing a main memory sub-system of a computer. + Computer science description of a main memory system of a computer. diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml index bff1df5322..64f55e90b9 100644 --- a/contributed_definitions/NXcs_prng.nxdl.xml +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - A base class to represent metadata of an pseudo-random number generator. + Computer science description of pseudo-random number generator. The purpose of such metadata is to identify if exactly the same sequence can be reproduced, like for a PRNG or not (for a true physically random source). @@ -44,13 +44,13 @@ - + Parameter of the PRNG controlling its initialization and thus the specific sequence of numbers it generates. - + Number of initial draws from the PRNG which are discarded in an effort to equilibrate the sequence and make it thus to statistically more random. diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml index 11983320ee..6123ef1541 100644 --- a/contributed_definitions/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -1,22 +1,22 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Storage for performance/profiling data which an app collects at runtime. + Computer science description for summary performance/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 + can be asked at various levels of detail. In general, there are three main contributions to performance: * Hardware capabilities and configuration * Software configuration and capabilities - * Dynamic effects of the system in operation and working together with - eventually multiple computers, especially when these have to exchange + * 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. At the most basic level users may wish to document how long e.g. a data @@ -73,7 +73,7 @@ and thus demand 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 @@ -87,13 +87,14 @@ used though. - + Qualifier with how many nominal threads were accessible to the app at - runtime. + 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. diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 224fd00b3f..dbc8daaed2 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,7 +12,7 @@ - A record of profiling data as measured via e.g. sampling. + Computer science description of a profiling event. @@ -40,22 +40,22 @@ 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. - + Maximum amount of virtual memory allocated per process during the event. @@ -63,7 +63,7 @@ - + Maximum amount of resident memory allocated per process during the event. diff --git a/contributed_definitions/NXms_delocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml similarity index 93% rename from contributed_definitions/NXms_delocalization.nxdl.xml rename to contributed_definitions/NXdelocalization.nxdl.xml index 160857e2e2..103ad5fd01 100644 --- a/contributed_definitions/NXms_delocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -69,7 +69,7 @@ A list of elements (via proton number) to consider for the atomic_decomposition - weighting model. Elements must exist in the periodic table of elements." + weighting model. Elements must exist in the periodic table of elements. diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index c31a227224..29dc7a3b78 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -1,10 +1,10 @@ - + - Container for components to form a controlled electron beam. + Container for components to form a controlled beam in electron microscopy. - + The source which creates the electron beam. @@ -14,7 +14,7 @@ Given name/alias. - + Voltage relevant to compute the energy of the electrons diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 9bbd85c4cc..5e61a3c678 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1,6 +1,6 @@ - + Characterization and session with one sample in an electron microscope. @@ -319,7 +319,7 @@ In effect, the application definition is a graph which describes how numerical data and (meta)data for EM research are related to one another. - + An at least as strong as SHA256 hashvalue of the file @@ -344,7 +344,7 @@ The identifier enables to link experiments to e.g. proposals. - + Free-text description about the experiment. @@ -354,7 +354,7 @@ into this free-text description field. - + ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. If the application demands that time @@ -374,7 +374,7 @@ provide additional pieces of information. - + ISO 8601 time code with local time zone offset to UTC included when the microscope session ended. @@ -412,14 +412,14 @@ - + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold a compressed archive. - + A small image that is representative of the entry; this can be an image taken from the dataset like a thumbnail of a spectrum. @@ -430,7 +430,7 @@ - + Contact information and eventually details of at least one person involved in the taking of the microscope session. This can be the @@ -442,42 +442,42 @@ Given (first) name and surname of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Postal address of the affiliation. - + Email address of the user at the point in time when the experiment was performed. Writing the most permanently used email is recommended. - + Globally unique identifier of the user as offered by services like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform - + Name of the OrcID or ResearcherID where the account under orcid is registered. - + (Business) (tele)phone number of the user at the point in time when the experiment was performed. - + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating @@ -485,12 +485,12 @@ are common examples. - + Account name that is associated with the user in social media platforms. - + Name of the social media platform where the account under social_media_name is registered. @@ -571,7 +571,7 @@ describe the sample_history. - + Possibility to give an abbreviation or alias of the specimen name field. @@ -596,13 +596,13 @@ surface normal of the specimen is parallel to the optical axis. - + Discouraged free-text field in case properly designed records for the sample_history are not available. - + (Measured) density of the specimen. For multi-layered specimens this field should only be used to describe the density of the excited @@ -614,16 +614,16 @@ - + Hard link to a location in the hierarchy of the NeXus file where the data for default plotting are stored. - + - + Metadata and numerical data of the microscope and the lab in which it stands. @@ -659,152 +659,128 @@ Examples could be NionHermes, Titan, JEOL, Gemini, etc. - + Location of the lab or place where the instrument is installed. Using GEOREF is preferred. - - - - - + + + - - - - - + + + - - - - - + + + - - - - - + + + - + - + If the lens is described at least one of the fields voltage, current, or value should be defined. - - - - + + - - - + + + - + - - - - - + + + - - - - - - - - - - - - - - + + + + + + + + + + + + + + - - - - - + + + - - - - - + + + - + - - - - - + + + - + If the lens is described at least one of the fields voltage, current, or value should be defined. - - - - + + - - - + + + - - - - - + + + - + - - - - - + + + - - - - - - - - + + + + + + + + - + Description of the type of the detector. @@ -817,30 +793,26 @@ Free text option to write further details about the detector. - - - - + + - + - - - - - + + + - - - - - - + + + + + + - + A container to structure a set of NXevent_data_em instances. @@ -861,7 +833,7 @@ Furthermore, NXevent_dat_em instances can document specific values and settings of the microscope during the snapshot/event. - + A container holding a specific result of the measurement and eventually metadata how that result was obtained numerically. @@ -940,15 +912,15 @@ transcoded by some software tool(s) while storing the data in an instance of this schema. - - - + + + Reference to a specific state and setting of the microscope components. - - + + The detector or set of detectors that was used to collect this signal. The name of the detector has to match one of the names of available @@ -957,97 +929,97 @@ instance called ebsd_camera. - - - - - - - - - - - - - - + + + + + + + + + + + + + + - - + + - + - - - - + + + + - + - - - - - - - - - - - - - - + + + + + + + + + + + + + + - - - - - - + + + + + + - - + + - - + + - - - - + + + + - - + + - - - - - - - - - + + + + + + + + + - - + + - - - - + + + + - + - + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 9ef6743f68..db52ba3352 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -1,6 +1,6 @@ - + Metadata and settings of an electron microscope for scans and images. @@ -202,12 +202,12 @@ These should be stored as two NXevent_data_em instances in an application definition. Each storing the specific settings. - NXmanufacturer relevant details should not be repeated because + NXfabrication relevant details should not be repeated because we assume that the session is with the same microscope. Namely, it is hopefully not happening that someone builds out a component of the microscope while is taking a measurement with it. - For this reason the specialized NXinstrument here contains no NXmanufacturer - groups. + For this reason the specialized NXinstrument here contains no + NXfabrication group. diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml index 030f21c18c..6a34ac39be 100644 --- a/contributed_definitions/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,6 +1,6 @@ - + Container to hold NXevent_data_em instances of an electron microscope session. diff --git a/contributed_definitions/NXmanufacturer.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml similarity index 63% rename from contributed_definitions/NXmanufacturer.nxdl.xml rename to contributed_definitions/NXfabrication.nxdl.xml index e202343331..05ba232273 100644 --- a/contributed_definitions/NXmanufacturer.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,20 +1,20 @@ - + Details about a component as defined by its manufacturer. - + Company name of the manufacturer. - + Version or model of the component named by the manufacturer. - + Ideally, (globally) unique persistent identifier, i.e. a serial number or hash identifier of the component. diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index e140483346..ef52fe7743 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 85b26b99ed..dbff9584b0 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index 169cd51519..08d6a9e1de 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml index 43c53282ed..e4c5233b4d 100644 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -1,6 +1,6 @@ - + Container for components of a focused-ion-beam (FIB) system. @@ -24,7 +24,7 @@ * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - + The source which creates the ion beam. diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index 5bf3f42f7c..6d85eece6b 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 69ac99297c..31a830311c 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -1,6 +1,6 @@ - + Description of an electro-magnetic lens or a compound lens. @@ -34,7 +34,7 @@ Name of the manufacturer who built/constructed the lens. - + Hardware name, hash identifier, or serial number that was given by the diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml new file mode 100644 index 0000000000..0b71bae734 --- /dev/null +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -0,0 +1,42 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many different match values does the filter specify. + + + + + Settings of a filter to select or remove entries based on their value. + + + + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + + + + + + + + + Array of values to filter according to method. For example if the filter + specifies [1, 5, 6] and method is whitelist, only entries with values + matching 1, 5 or 6 will be processed. All other entries will be filtered + out. + + + + + + diff --git a/contributed_definitions/NXms_crystal_set.nxdl.xml b/contributed_definitions/NXms_crystal_set.nxdl.xml index 26022fd385..ad7cfd2eda 100644 --- a/contributed_definitions/NXms_crystal_set.nxdl.xml +++ b/contributed_definitions/NXms_crystal_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -18,7 +18,7 @@ - A base class to wrap details about a set of crystals (grains, precipitates). + Base class to describe data about observed crystals in microstructures. Both experiments and computer simulations support that atoms organize into regions which are often separated and interconnected by different types of crystal defects. diff --git a/contributed_definitions/NXms_snapshot.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml index 3ca0fcb2af..16d2b918db 100644 --- a/contributed_definitions/NXms_snapshot.nxdl.xml +++ b/contributed_definitions/NXms_snapshot.nxdl.xml @@ -1,13 +1,13 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. - Base class wrapping data of a system characterized at a specific time/iteration. + Base class for data on the state of the microstructure at a given time/iteration. diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml index 5198b90af0..2ddeddb4b8 100644 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index f1f1b75279..158325e8be 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -1,15 +1,45 @@ - + A container for qualifying an electron optical system. - - - - - - + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + Beam current as measured relevant for the illumination of the specimen. diff --git a/contributed_definitions/NXms_orientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml similarity index 91% rename from contributed_definitions/NXms_orientation_set.nxdl.xml rename to contributed_definitions/NXorientation_set.nxdl.xml index d77249b60e..9eb562442a 100644 --- a/contributed_definitions/NXms_orientation_set.nxdl.xml +++ b/contributed_definitions/NXorientation_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -75,7 +75,7 @@ all objects referred when following the link in objects may still exists or are still tracked when the orientation set was characterized. - This design enables to also use NXms_orientation_set in situations where + This design enables to also use NXorientation_set in situations where the orientation of objects change as a function in time. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 4eaffed5de..5978d27016 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index f2fe3cbedc..42e6d92c96 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -12,9 +12,9 @@ - Metadata for laser-, voltage-, or combined pulsing triggering field evaporation. + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - + How is field evaporation physically triggered. @@ -67,7 +67,7 @@ Given name/alias. - + Nominal wavelength of the laser radiation. diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index 32bdb644ef..a2783e9d72 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -1,10 +1,10 @@ - + Device to reduce an atmosphere to a controlled remaining pressure level. - + Principle type of the pump. diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml index 40723fa055..a1eb14dfd8 100644 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -1,6 +1,6 @@ - + Device for reducing flight time differences of ions in ToF experiments. @@ -9,7 +9,7 @@ Given name/alias. - + Free-text field to specify further details about the reflectron. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index e9f639aecc..ffea702947 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -1,6 +1,6 @@ - + Scan box and coils which deflect an electron beam in a controlled manner. @@ -16,5 +16,5 @@ - + diff --git a/contributed_definitions/NXms_slip_system_set.nxdl.xml b/contributed_definitions/NXslip_system_set.nxdl.xml similarity index 87% rename from contributed_definitions/NXms_slip_system_set.nxdl.xml rename to contributed_definitions/NXslip_system_set.nxdl.xml index 6959ce5d4e..b5ac02c4a1 100644 --- a/contributed_definitions/NXms_slip_system_set.nxdl.xml +++ b/contributed_definitions/NXslip_system_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXapm_spatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml similarity index 61% rename from contributed_definitions/NXapm_spatial_filter.nxdl.xml rename to contributed_definitions/NXspatial_filter.nxdl.xml index e732a50b85..b652d2cd29 100644 --- a/contributed_definitions/NXapm_spatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -22,10 +22,7 @@ - Settings for a spatial filter to define a region-of-interest. - - By default the paraprobe processes the entire reconstructed dataset/point cloud. - If this filter is added, the user can specify which ions to include. + Spatial filter to filter entries within a region-of-interest based on their position. @@ -42,19 +39,18 @@ of the numpy package to define such bitfields. Conditions: - In the case that windowing_method is it is possible to specify none - or all types of primitives (ellipsoids, cylinder, hexahedra). - In the first case the entire dataset is processed. - In the second case ions in the union of the specified primitives - will be processed if primitives are defined; if not the entire dataset - will be processed. - In the alternative case that windowing_method is bitmasked_points, - the bitmask has to be defined; otherwise the entire dataset is processed. + In the case that windowing_method is entire_dataset all entries are processed. + In the case that windowing_method is union_of_primitives, + it is possible to specify none or all types of primitives + (ellipsoids, cylinder, hexahedra). If no primitives are specified + the filter falls back to entire_dataset. + In the case that windowing_method is bitmask, the bitmask has to be defined; + otherwise the filter falls back to entire dataset. - + diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml index 4952128e6e..4ef7757a10 100644 --- a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml index 95ddca359a..7cbc9d7448 100644 --- a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 5aa4c431a2..fd1b88f47e 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -1,6 +1,6 @@ - + A stage lab can be used to hold, align, orient, and prepare a specimen. @@ -91,7 +91,7 @@ Given name/alias for the components making the stage. - + Ideally, a (globally) unique persistent identifier, link, diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml new file mode 100644 index 0000000000..c9337b7cac --- /dev/null +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -0,0 +1,26 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Settings of a filter to sample entries based on their value. + + + + Triplet of the minimum, increment, and maximum value which will + be included in the analysis. The increment controls which n-th entry to take. + + Take as an example a dataset with 100 entries (their indices start at zero) + and the filter set to 0, 1, 99. This will process each entry. + 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third + entry beginning from entry 90 up to 99. + + + + + + diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 2a9a7810eb..23898fe9e7 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -65,7 +65,7 @@ definition rather than in this experiment description. - + Commercial or otherwise defined given name to the program that was @@ -122,7 +122,7 @@ - + Manufacturer of the instrument. @@ -236,11 +236,11 @@ Response time of the detector - + Detector gain - + Slit setting used for measurement with this detector diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 18fc499f74..71c17933e6 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -44,7 +44,7 @@ We developed new base classes to structure the application definition into lab e :ref:`NXion`: A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. - :ref:`NXmanufacturer`: + :ref:`NXfabrication`: A base class to bundle manufacturer/vendor-specific details about a component or device of an instrument. :ref:`NXpeak`: @@ -56,9 +56,6 @@ We developed new base classes to structure the application definition into lab e :ref:`NXpulser_apm`: A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. - :ref:`NXreflectron`: - A base class to describe an optional reflectron device that influences the flight path of evaporated ions. - :ref:`NXreflectron`: A base class to describe a kinetic energy sensitive filtering device for ToF. @@ -73,5 +70,4 @@ Removed base classes ###################### We have removed the NXlens_apm base class and replaced it by :ref:`NXreflectron`. - - +We have renamed NXmanufacturer to NXfabrication. diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index e6040817ec..adfdb8d14a 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -194,7 +194,7 @@ not only for stencil-based methods: the Marching Cubes algorithm, whose sensitivity to specific topological configurations is known to result in different triangle soups. - :ref:`NXms_delocalization`: + :ref:`NXdelocalization`: An approach to document procedures in which a scalar field is smoothened in a controlled manner. @@ -206,21 +206,21 @@ to hold metadata for these features: :ref:`NXclustering`: A description for clustering of objects (such as atoms or features). - :ref:`NXms_atom_set`: + :ref:`NXatom_set`: A set of atoms. - :ref:`NXms_orientation_set`: + :ref:`NXorientation_set`: A set of rotations to describe the relative orientation of of members of a set of features/objects. - :ref:`NXms_slip_system_set`: + :ref:`NXslip_system_set`: Metadata to a set of slip system/slip system family for a given crystal structure. .. :ref:`NXms_point_defect_set`: .. Metadata to a set of point defects. -.. :ref:`NXms_dislocation_set`: +.. :ref:`NXms_dislocation_set`: .. Metadata of a set of dislocation/disconnection (line) defects. .. :ref:`NXms_interface_set`: diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index a42ed586d9..8b266f7d2a 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -79,19 +79,8 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXimage_set_em_kikuchi` :ref:`NXimage_set_em_ronchigram` :ref:`NXimage_set_em_se`: - Base classes for storing acquisition details for individual images or stacks of images collected via using e.g. different imaging modes. - - * Adf - annular dark field - * Bf - bright filed - * Bse - backscattered electron - * Chamber - TV camera to monitor the stage and chamber - * Df - darkfield - * Diffrac - diffraction image - * Ecci - electron channel contrast imaging - * Kikuchi - electron backscatter diffraction (EBSD) - * Ronchigram - convergent beam diffraction pattern - * Se - secondary electron - + Base classes for storing acquisition details for individual images or stacks of images collected via using e.g. different imaging modes. The suffixes specify **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction (EBSD), **ronchigram** - convergent beam diffraction pattern, and **se** secondary electron. + :ref:`NXinteraction_vol_em`: A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. @@ -101,7 +90,7 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXlens_em`: A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. The idea of this base class is to use it in an application definition. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tool which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collect for a lens as a component so that developers of application definitions can take immediate advantage of this work. - :ref:`NXmanufacturer`: + :ref:`NXfabrication`: A base class to bundle manufacturer/vendor-specific details about a component or device of an instrument. :ref:`NXoptical_system_em`: @@ -121,13 +110,7 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXspectrum_set_em_xray` :ref:`NXspectrum_set_em_auger` :ref:`NXspectrum_set_em_cathodolum`: - Base classes comparable to NXimage_set_em but for different techniques resulting in spectra. - - * Auger spectroscopy - * Cathodoluminescence - * Electron energy loss spectroscopy (EELS) - * X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS) - + Base classes comparable to NXimage_set_em but for different techniques resulting in spectra. The suffixes specify **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, and **cathodolum** cathodoluminescence. :ref:`NXstage_lab`: As it was mentioned for atom probe microscopy this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. diff --git a/manual/source/fairmat-cover.rst b/manual/source/fairmat-cover.rst index 42ff35491b..d86dd303ec 100644 --- a/manual/source/fairmat-cover.rst +++ b/manual/source/fairmat-cover.rst @@ -139,100 +139,8 @@ converting to NeXus much more sporadic than fairifying raw data, to the point th it guarantees full control on the data until publication. We are confident that if you take this approach, more appetite will come with eating, and you will be naturally inclined to gradually integrate FAIRmat structures and tools further in your workflow. -.. _WhatIsNew: -What is New? -############## - -We have developed new data storage objects (in the form of new application definitions, new base classes as well as updated existing base classes) -for the following macro-areas of experimental physics - -:ref:`Multidimensional Photoemission Spectroscopy `: - Set of data storage objects to describe photoemission experiments, follow the link for a more extensive description. - New application definitions: - :ref:`NXmpes` - :ref:`NXmpes_ARPES` - New base classes: - :ref:`NXelectronanalyser` - :ref:`NXcollectioncolumn` - :ref:`NXenergydispersion` - :ref:`NXspindispersion` - :ref:`NXmanipulator` - :ref:`NXcalibration` - :ref:`NXdistortion` - :ref:`NXregistration` - :ref:`NXlens` - :ref:`NXdeflector` - Extended base classes: - :ref:`NXaperture` - :ref:`NXbeam` - :ref:`NXdetector` - :ref:`NXentry` - :ref:`NXprocess` - :ref:`NXsample` - :ref:`NXsource` - -:ref:`Ellipsometry `: - Set of data storage objects to describe ellipsometry, follow the link for a more extensive description. - New application definitions: - :ref:`NXellipsometry` - .. New base classes: - .. Extended base classes: - -:ref:`Electron Microscopy `: - Set of data storage objects to describe electron microscopy experiments using an event-based paradigm, follow the link for a more extensive description. - New application definitions: - :ref:`NXem` - NXem substantially generalizes our earlier candidate proposal NXem_nion. - - New base classes: - :ref:`NXaberration` - :ref:`NXaperture_em` - :ref:`NXchamber` - :ref:`NXcoordinate_system_set` - :ref:`NXcorrector_cs` - :ref:`NXebeam_column` - :ref:`NXevent_data_em` - :ref:`NXevent_data_em_set` - :ref:`NXibeam_column` - :ref:`NXimage_set_em_adf` - :ref:`NXimage_set_em_bf` - :ref:`NXimage_set_em_bse` - :ref:`NXimage_set_em_chamber` - :ref:`NXimage_set_em_df` - :ref:`NXimage_set_em_diffrac` - :ref:`NXimage_set_em_ecci` - :ref:`NXimage_set_em_kikuchi` - :ref:`NXimage_set_em_ronchigram` - :ref:`NXimage_set_em_se` - :ref:`NXinteraction_vol_em` - :ref:`NXion` - :ref:`NXlens_em` - :ref:`NXmanufacturer` - :ref:`NXoptical_system_em` - :ref:`NXpeak` - :ref:`NXpump` - :ref:`NXscanbox_em` - :ref:`NXspectrum_set_em_auger` - :ref:`NXspectrum_set_em_cathodolum` - :ref:`NXspectrum_set_em_eels` - :ref:`NXspectrum_set_em_xray` - :ref:`NXstage_lab` - .. Extended base classes: - -:ref:`Atom Probe Microscopy `: - Set of data storage objects to describe atom probe tomography and field-ion microscopy experiments, follow the link for a more extensive description. - New application definitions: - :ref:`NXapm` - New base classes: - :ref:`NXchamber` - :ref:`NXcoordinate_system_set` - :ref:`NXion` - :ref:`NXmanufacturer` - :ref:`NXpeak` - :ref:`NXpump` - :ref:`NXpulser_apm` - :ref:`NXreflectron` - :ref:`NXstage_lab` - .. Extended base classes: +.. _WhatIsNew: +.. What is New? +.. ############## diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst index 8ac0aa96d3..77702588bf 100644 --- a/manual/source/north-structure.rst +++ b/manual/source/north-structure.rst @@ -141,6 +141,15 @@ New Application Definitions extraction algorithms on the resulting shape, spatial arrangement, and colocation of 3D objects via graph-based techniques. + :ref:`NXapm_paraprobe_config_spatstat`: + Configuration of paraprobe-spatstat + Spatial statistics on the entire or selected regions of the reconstructed dataset. + + :ref:`NXapm_paraprobe_config_clusterer`: + Configuration of paraprobe-clusterer + Import cluster analysis results of IVAS/APSuite and perform clustering + analyses in a Python ecosystem. + .. _ApmParaprobeNewBC: New Base Classes @@ -174,24 +183,25 @@ proposal on computational geometry base classes: general that all possible nuclids be they observationally stable or radioactive can be considered. - :ref:`NXapm_spatial_filter`: +A detailed inspection of spatial and other type of filters used in atom probe microscopy +data analysis revealed that it is better to define atom probe agnostic, i.e. more +general filters: + + :ref:`NXspatial_filter`: A proposal how a point cloud can be spatial filtered in a very specific, flexible, yet general manner. This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, and :ref:`NXcg_hexahedron_set` to cater for all of the most commonly used geometric primitives in atom probe. - :ref:`NXapm_evaporation_id_filter`: - A proposal to describe how ions are filtered based on their evaporation - sequence ID. - - :ref:`NXapm_iontype_filter`: - A proposal to describe how ions are filtered based on their - ion type (ion species). + :ref:`NXsubsampling_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered via sub-sampling. - :ref:`NXapm_hitmultiplicity_filter`: - A proposal to describe how ions are filtered based on their - hit multiplicity. + :ref:`NXmatch_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered based on their type (ion species) + or hit multiplicity. In summary, we report with this proposal our experience made in an experimental project that is about using NeXus for standardizing a certain scientific software. From ecf0146b0d6fb5a48e5883a81ba4a6012d3374a8 Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Wed, 7 Sep 2022 15:33:33 +0200 Subject: [PATCH 055/203] Fixed errors in new NXiv_temp and NXsensor_scan --- contributed_definitions/NXiv_temp.nxdl.xml | 6 +++--- contributed_definitions/NXsensor_scan.nxdl.xml | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 2045744dd9..7f9f2b1dbd 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -51,12 +51,12 @@ equal to the number of voltage setpoints. - + - + - + diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index bb47ed8f27..decdfa8480 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -9,10 +9,10 @@ + - From 9249b46bafc4ab59a893cb2ac7d9f880a36637fc Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Wed, 7 Sep 2022 15:43:03 +0200 Subject: [PATCH 056/203] Ran the NXiv_temp and NXsensor_scan through yaml2nxdl --- contributed_definitions/NXiv_temp.nxdl.xml | 44 +++++----- .../NXsensor_scan.nxdl.xml | 86 +++++++++---------- 2 files changed, 65 insertions(+), 65 deletions(-) diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 7f9f2b1dbd..79473d5837 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -1,6 +1,6 @@ - + @@ -14,15 +14,15 @@ - Application definition for temperature-dependent IV curve measurements. - - In this application definition, times should be specified always together - with an UTC offset. - - This is the application definition describing temperature dependent IV curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. + Application definition for temperature-dependent IV curve measurements. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature dependent IV curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. @@ -34,24 +34,24 @@ Describes an environment setup for a temperature-dependent IV measurement experiment. - + The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. + the current sensor must also be present with its readings. - - - + + + - + - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. - - + + diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index decdfa8480..817f308c49 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -3,22 +3,22 @@ Application definition for a generic scan using sensors. - + In this application definition, times should be specified always together with an UTC offset. - + - - - - - + + + + + Define the program that was used to generate the results file(s) with measured data and metadata. @@ -37,7 +37,7 @@ deterministic manner. - + Website of the software. @@ -55,19 +55,19 @@ Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. - + Email address of the user. @@ -77,7 +77,7 @@ Author ID defined by https://orcid.org/. - + Official telephone number of the user. @@ -87,73 +87,73 @@ Describes an environment setup for the experiment. - + All the setting values of the independently scanned controllers are listed under corresponding NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each measurement sensor. - + For example, in a temperature-dependent IV measurement, the temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with - its readings. + its readings. - Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. + Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. - For each point in the scan space, either the nominal setpoint of an independently scanned controller - or a representative average value of a measurement sensor is registered. - In case of a full multi-dimensional scan, the length of the scan space [n] is the product of the number - of setpoints along all independently scanned controllers. + For each point in the scan space, either the nominal setpoint of an independently scanned controller + or a representative average value of a measurement sensor is registered. + In case of a full multi-dimensional scan, the length of the scan space [n] is the product of the number + of setpoints along all independently scanned controllers. - Timestamp for when the values provided in the value field were registered. - - Individual readings can be stored with their timestamps under value_log. This is to timestamp - the nominal setpoint or average reading values listed above in the value field. + Timestamp for when the values provided in the value field were registered. + + Individual readings can be stored with their timestamps under value_log. This is to timestamp + the nominal setpoint or average reading values listed above in the value field. - - - Free-text describing the data acquisition control: an internal - sweep using the built-in functionality of the controller device, - or a set/wait/read/repeat mechanism. - + + + Free-text describing the data acquisition control: an internal + sweep using the built-in functionality of the controller device, + or a set/wait/read/repeat mechanism. + - - ISO8601 datum when calibration was last performed - before this measurement. UTC offset should be specified. - + + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. + - - + + - A list of names of NXsensor groups used as independently scanned controllers. + A list of names of NXsensor groups used as independently scanned controllers. - + - A list of names of NXsensor groups used as measurement sensors. + A list of names of NXsensor groups used as measurement sensors. - + - + - A scan specific representation of the measured signals as a function of the independently controlled environment settings. - Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. + A scan specific representation of the measured signals as a function of the independently controlled environment settings. + Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. From 3b25fe789854cd99b8ed6d38466be42ff5a904be Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Wed, 7 Sep 2022 15:46:04 +0200 Subject: [PATCH 057/203] Ran NXpid through yaml2nxdl --- contributed_definitions/NXpid.nxdl.xml | 68 +++++++++++++------------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/contributed_definitions/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml index 2b74593996..7e779c91ff 100644 --- a/contributed_definitions/NXpid.nxdl.xml +++ b/contributed_definitions/NXpid.nxdl.xml @@ -2,62 +2,62 @@ - Contains the settings of a PID controller. + Contains the settings of a PID controller. - + - Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. - - For example, a set of sensors could be averaged over before feeding it back into the loop. + Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. + + For example, a set of sensors could be averaged over before feeding it back into the loop. - The sensor representing the Process Value used in the feedback loop for the PID. - - In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. + The sensor representing the Process Value used in the feedback loop for the PID. + + In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. - - + + - The actual timeseries data fed back to the PID loop. + The actual timeseries data fed back to the PID loop. - + - The Setpoint(s) used as an input for the PID controller. - - It can also be a link to an NXsensor.value field. + The Setpoint(s) used as an input for the PID controller. + + It can also be a link to an NXsensor.value field. - + - 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. + 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 contribution from the integral term is proportional to both - the magnitude of the error and the duration of the error. - The integral in a PID controller is the sum of the instantaneous - error over time and gives the accumulated offset that should have - been corrected previously. The accumulated error is then - multiplied by the integral gain (Ki) and added to the - controller output. + The contribution from the integral term is proportional to both + the magnitude of the error and the duration of the error. + The integral in a PID controller is the sum of the instantaneous + error over time and gives the accumulated offset that should have + been corrected previously. The accumulated error is then + multiplied by the integral gain (Ki) and added to the + controller output. - + - The derivative of the process error is calculated by determining - the slope of the error over time and multiplying this rate of - change by the derivative gain K_d. The magnitude of the - contribution of the derivative term to the overall control - action is termed the derivative gain, K_d + The derivative of the process error is calculated by determining + the slope of the error over time and multiplying this rate of + change by the derivative gain K_d. The magnitude of the + contribution of the derivative term to the overall control + action is termed the derivative gain, K_d From d77d989af6d0aff82f2a6ecb7054bb2b73d00a42 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Tue, 13 Sep 2022 18:10:17 +0200 Subject: [PATCH 058/203] sprint9_dev_frozen_apm_em --- .../NXaperture_em.nxdl.xml | 2 +- contributed_definitions/NXapm.nxdl.xml | 2 +- .../NXapm_input_ranging.nxdl.xml | 2 +- .../NXapm_input_reconstruction.nxdl.xml | 2 +- .../NXapm_paraprobe_config_clusterer.nxdl.xml | 2 +- .../NXapm_paraprobe_config_distancer.nxdl.xml | 135 ++++--- ...Xapm_paraprobe_config_intersector.nxdl.xml | 2 +- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 2 +- .../NXapm_paraprobe_config_ranger.nxdl.xml | 364 +++++++++--------- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 2 +- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 14 +- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 2 +- ...NXapm_paraprobe_config_transcoder.nxdl.xml | 2 +- .../NXapm_paraprobe_results_ranger.nxdl.xml | 15 +- ...Xapm_paraprobe_results_transcoder.nxdl.xml | 195 ++++++++-- contributed_definitions/NXatom_set.nxdl.xml | 2 +- .../NXcg_alpha_shape.nxdl.xml | 2 +- .../NXcg_cylinder_set.nxdl.xml | 2 +- .../NXcg_ellipsoid_set.nxdl.xml | 2 +- .../NXcg_face_list_data_structure.nxdl.xml | 2 +- .../NXcg_geodesic_mesh.nxdl.xml | 2 +- contributed_definitions/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- .../NXcg_hexahedron_set.nxdl.xml | 2 +- .../NXcg_isocontour.nxdl.xml | 2 +- .../NXcg_marching_cubes.nxdl.xml | 2 +- .../NXcg_parallelogram_set.nxdl.xml | 2 +- .../NXcg_point_set.nxdl.xml | 2 +- .../NXcg_polygon_set.nxdl.xml | 2 +- .../NXcg_polyhedron_set.nxdl.xml | 2 +- .../NXcg_polyline_set.nxdl.xml | 2 +- contributed_definitions/NXcg_roi_set.nxdl.xml | 2 +- .../NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_tetrahedron_set.nxdl.xml | 2 +- .../NXcg_triangle_set.nxdl.xml | 2 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- .../NXcg_unit_normal_set.nxdl.xml | 2 +- contributed_definitions/NXchamber.nxdl.xml | 2 +- contributed_definitions/NXclustering.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 2 +- .../NXcorrector_cs.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 2 +- contributed_definitions/NXcs_gpu.nxdl.xml | 2 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 2 +- .../NXcs_profiling.nxdl.xml | 2 +- .../NXcs_profiling_event.nxdl.xml | 2 +- .../NXdelocalization.nxdl.xml | 2 +- .../NXebeam_column.nxdl.xml | 2 +- contributed_definitions/NXem.nxdl.xml | 2 +- .../NXevent_data_em.nxdl.xml | 2 +- .../NXevent_data_em_set.nxdl.xml | 2 +- .../NXfabrication.nxdl.xml | 2 +- .../NXgraph_edge_set.nxdl.xml | 2 +- .../NXgraph_node_set.nxdl.xml | 2 +- contributed_definitions/NXgraph_root.nxdl.xml | 2 +- .../NXibeam_column.nxdl.xml | 2 +- .../NXimage_set_em_adf.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 2 +- contributed_definitions/NXlens_em.nxdl.xml | 2 +- .../NXmatch_filter.nxdl.xml | 2 +- .../NXms_crystal_set.nxdl.xml | 2 +- .../NXms_snapshot.nxdl.xml | 2 +- .../NXms_snapshot_set.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 2 +- .../NXorientation_set.nxdl.xml | 2 +- contributed_definitions/NXpeak.nxdl.xml | 2 +- contributed_definitions/NXpulser_apm.nxdl.xml | 2 +- contributed_definitions/NXpump.nxdl.xml | 2 +- contributed_definitions/NXreflectron.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 2 +- .../NXslip_system_set.nxdl.xml | 2 +- .../NXspatial_filter.nxdl.xml | 2 +- .../NXspectrum_set_em_eels.nxdl.xml | 2 +- .../NXspectrum_set_em_xray.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- .../NXsubsampling_filter.nxdl.xml | 2 +- 81 files changed, 509 insertions(+), 366 deletions(-) diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 20b4db8000..0151ef8aff 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -1,6 +1,6 @@ - + Details of an individual aperture for beams in electron microscopy. diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index acbf7047d1..2723abeee6 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml index b45bc6a651..e08fe38a0e 100644 --- a/contributed_definitions/NXapm_input_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_input_ranging.nxdl.xml @@ -1,6 +1,6 @@ - + Metadata to ranging definitions made for a dataset in atom probe microscopy. diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml index 95ee5ae096..bd1b74d43e 100644 --- a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml @@ -1,6 +1,6 @@ - + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml index 7c4189af85..653fee81cb 100644 --- a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml index ca5c578680..3d4bff927a 100644 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -108,79 +108,86 @@ - + - Paraprobe-distancer enables the computation of the Euclidean shortest - distance for each member of a set of points against a set of triangles. - In contrast to comparable methods used in atom probe the here computed - distance is not simply the projected distance to one of the triangles - but the more costly but robust computation of the distance between - a point and a triangle. - - The triangles can represent for instance the facets of a triangulated - surface mesh of a model for the edge of the dataset. Such a model can - be computed with paraprobe-surfacer. Alternatively, the triangles can - be those from the set of all facets for a set of convex hulls, alpha-shapes, - or alpha wrappings about three-dimensional objects like precipitates - (computed with e.g. paraprobe-nanochem). - - Currently, the tool does not check if the respectively specified - triangle sets are consistent, what their topology is, or whether or - not they are consistently oriented. - Each dataset that is referred to in the list_of _dataset_names_vertices - should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred - to in the list_of_dataset_names_facet_indices should be an - (Nfacets, 3) array of NX_UINT. - Facet indices refer to vertex indices. These need to start at zero - and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and vertices are indexed thus implicitly. - Facet normal vectors have to be also an array - of shape (Nfacets, 3) of NX_FLOAT. + Compute for all filtered points, e.g. ions of the point set + the shortest Euclidean distance to the closest triangle of the + set of triangles. The triangles can formed a closed surface mesh. + Distances are not simple distances based on normal projections but + giving an exact solution. - + - How many triangle sets to consider. - - - - - List of triangle sets. This design allows users to combine - multiple triangle sets. + Paraprobe-distancer enables the computation of the Euclidean shortest + distance for each member of a set of points against a set of triangles. + In contrast to comparable methods used in atom probe the here computed + distance is not simply the projected distance to one of the triangles + but the more costly but robust computation of the distance between + a point and a triangle. + + The triangles can represent for instance the facets of a triangulated + surface mesh of a model for the edge of the dataset. Such a model can + be computed with paraprobe-surfacer. Alternatively, the triangles can + be those from the set of all facets for a set of convex hulls, alpha-shapes, + or alpha wrappings about three-dimensional objects like precipitates + (computed with e.g. paraprobe-nanochem). + + Currently, the tool does not check if the respectively specified + triangle sets are consistent, what their topology is, or whether or + not they are consistently oriented. + Each dataset that is referred to in the list_of _dataset_names_vertices + should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred + to in the list_of_dataset_names_facet_indices should be an + (Nfacets, 3) array of NX_UINT. + Facet indices refer to vertex indices. These need to start at zero + and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and vertices are indexed thus implicitly. + Facet normal vectors have to be also an array + of shape (Nfacets, 3) of NX_FLOAT. - - - Name of the HDF5 file(s) which contain(s) vertex coordinates - and facet indices to describe the desired set of triangles. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility. - - - - + - Absolute HDF5 path to the dataset which - specifies the array of vertex positions. + How many triangle sets to consider. - + - Absolute HDF5 path to the dataset which - specifies the array of facet indices. + List of triangle sets. This design allows users to combine + multiple triangle sets. - - - - Absolute HDF5 path to the dataset which - specifies the array of facet normal vectors. - - + + + Name of the HDF5 file(s) which contain(s) vertex coordinates + and facet indices to describe the desired set of triangles. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility. + + + + + + Absolute HDF5 path to the dataset which + specifies the array of vertex positions. + + + + + Absolute HDF5 path to the dataset which + specifies the array of facet indices. + + + + + Absolute HDF5 path to the dataset which + specifies the array of facet normal vectors. + + + - - Specifies for which ions/points the tool will compute distances. diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml index 4175c48d4d..1a678869c8 100644 --- a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml index 85a0af339e..9befaccc86 100644 --- a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml index dff01815f1..7752e4bf94 100644 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -49,6 +49,12 @@ + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + Ideally, a (globally persistent) unique identifier for referring @@ -60,203 +66,183 @@ Possibility for leaving a free-text description about this analysis. - + - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. + How many task to perform? - - - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - - - - - How many molecular_ion_search processes should - the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A list of pairs of number of protons and either the value 0 (per row) - or the mass number for all those isotopes which are assumed present - in a virtual specimen. - The purpose of this field is to compute also composition-weighted - products to yield a simple estimation which could potentially help - scientists to judge if certain molecular ions are to be expected. - The corresponding setting store_composition_weighted_product should be - activated. - - - - - - - - - A list of atomic (at.-%) ! percent values for the composition of each - isotope in the virtual specimen following the sequence of - assumed_composition_isotopes. - - - - - - - - A list of pairs of number of protons and mass number for all isotopes - to consider that can be composed into (molecular) ions, during the - recursive molecular_ion_search. - - - - - - - + + - The mass-to-charge-state ratio interval in which - all molecular ions are searched. + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. - - - - + - The maximum charge that a molecular ion should have. - - - - - The maximum number of isotopes of which the molecular ion - should be composed. Currently this must not be larger than 32. - - Users should be warned that the larger the maximum_charge and - especially the larger the maximum_number_of_isotopes is chosen, - the eventually orders of magnitude more costly the search becomes. - - This is because paraprobe-ranger computes really all (at least) - theoretically possible combinations that would have likely a - mass-to-charge-state ratio in the specified mass_to_charge_interval. - It is the challenge in atom probe to judge which of these (molecular) - ions are feasible and also practically possible. This tool does not - answer this question. - - Namely, which specific molecular ion will evaporate, remain stable - during flight and becomes detected is a complicated and in many cases - not yet in detail understood phenomenon. The ab-initio conditions - before and during launch, the local environment, arrangement and field - as well as the flight phase in an evacuated but not analysis chamber - with a complex electrical field, eventual laser pulsing in place, - temperature and remaining atoms or molecules all can have an effect - which iontypes are really physically evaporating and detected. - - - - - Report the accumulated atomic mass from each isotope building the ion. - Accounts for each identified ion. - Relatistic effects are not accounted for. - - - - - Report the product of the natural abundances from each isotope building - the ion. Accounts for each identified ion. - - The value zero indicates it is not possible to build such molecular ion - from nuclids which are all observationally stable. - Very small values can give an idea/about how likely such a molecular ion - is expected to form assuming equal probabilities. - - However in atom probe experiments this product has to be modified - by the (spatially-correlated) local composition in the region from - which the ions launch because the formation of a molecular ion depends - as summarized under maximum_number_of_isotopes on the specific - quantum-mechanical configuration and field state upon launch - or/and (early state) of flight respectively. - We are aware that this modified product can have a substantially - different value than the natural_abundance_product. - - Natural abundancies folded with the estimated compositions of the - specimen can differ by orders of magnitude. - - - - - Report the product of the composition from each isotope building the - ion. This sets strong constraints on the molecular ions which are - expected to have at all a noteworthy product value. - It should not be forgotten though the computation relies on assumptions: - - * The composition is homogeneous within the virtual specimen. - * It is a priori know which nuclids the specimen is build of. - - - - - Report the charge state of the ions. - - - - - Report if identified ions should be characterized - wrt to their number of disjoint isotopes. + How many molecular_ion_search processes should + the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A list of pairs of number of protons and either the value 0 (per row) + or the mass number for all those isotopes which are assumed present + in a virtual specimen. + The purpose of this field is to compute also composition-weighted + products to yield a simple estimation which could potentially help + scientists to judge if certain molecular ions are to be expected. + The corresponding setting store_composition_weighted_product should be + activated. + + + + + + + + + A list of pairs of number of protons and mass number for all isotopes + to consider that can be composed into (molecular) ions, during the + recursive molecular_ion_search. + + + + + + + + + The mass-to-charge-state ratio interval in which + all molecular ions are searched. + + + + + + + + The maximum charge that a molecular ion should have. + + + + + The maximum number of isotopes of which the molecular ion + should be composed. Currently this must not be larger than 32. + + Users should be warned that the larger the maximum_charge and + especially the larger the maximum_number_of_isotopes is chosen, + the eventually orders of magnitude more costly the search becomes. + + This is because paraprobe-ranger computes really all (at least) + theoretically possible combinations that would have likely a + mass-to-charge-state ratio in the specified mass_to_charge_interval. + It is the challenge in atom probe to judge which of these (molecular) + ions are feasible and also practically possible. This tool does not + answer this question. + + Namely, which specific molecular ion will evaporate, remain stable + during flight and becomes detected is a complicated and in many cases + not yet in detail understood phenomenon. The ab-initio conditions + before and during launch, the local environment, arrangement and field + as well as the flight phase in an evacuated but not analysis chamber + with a complex electrical field, eventual laser pulsing in place, + temperature and remaining atoms or molecules all can have an effect + which iontypes are really physically evaporating and detected. + + + + + Report the accumulated atomic mass from each isotope building the ion. + Accounts for each identified ion. + Relatistic effects are not accounted for. + + + + + Report the product of the natural abundances from each isotope building + the ion. Accounts for each identified ion. + + The value zero indicates it is not possible to build such molecular ion + from nuclids which are all observationally stable. + Very small values can give an idea/about how likely such a molecular ion + is expected to form assuming equal probabilities. + + However in atom probe experiments this product has to be modified + by the (spatially-correlated) local composition in the region from + which the ions launch because the formation of a molecular ion depends + as summarized under maximum_number_of_isotopes on the specific + quantum-mechanical configuration and field state upon launch + or/and (early state) of flight respectively. + We are aware that this modified product can have a substantially + different value than the natural_abundance_product. + + Natural abundancies folded with the estimated compositions of the + specimen can differ by orders of magnitude. + + + + + Report the charge state of the ions. + + + + + Report if identified ions should be characterized + wrt to their number of disjoint isotopes. + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml index a6ab596b15..32c1051c19 100644 --- a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml index d145abafa3..b73134ac33 100644 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,6 +43,12 @@ + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + Ideally, a (globally persistent) unique identifier for referring @@ -54,12 +60,6 @@ Possibility for leaving a free-text description about this analysis. - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - For now a support field for the tool to identify how many individual diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml index 80af129154..76357a0ed6 100644 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml index 16122838e5..d2f823505c 100644 --- a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml index 285188b68c..10a7ab1dfb 100644 --- a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -111,7 +111,7 @@ - + Paraprobe-ranger loads the iontypes and evaluates for each @@ -119,12 +119,15 @@ ion is considered of the default unknown type with a 0 as its respective value in the iontypes array. - - + + + + + - The iontype ID for each ion in the + The iontype ID for each ion that was best matching, stored in the order of the evaporation sequence ID. @@ -132,7 +135,7 @@ - + Paraprobe-ranger performs a combinatorial search over all possible or a reduced set of nuclids to identify diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml index 2a763afe73..12e9fdf3b6 100644 --- a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -1,10 +1,32 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. + + + Total number of ions collected. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). Needs + to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals mapped on this ion + type. + + + + + Total number of integers in the supplementary XDMF topology array. + + Results of a paraprobe-transcoder tool run in atom probe microscopy. @@ -88,10 +110,11 @@ - The individual coordinate systems which used. - fields should be prefixed with a prefix taken from an - enumeration which details the individual coordinate systems: + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + * paraprobe * lab * specimen * laser @@ -101,31 +124,155 @@ - + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + + + + + + + - Paraprobe-transcoder prepares the data in POS, ePOS, APT files from - APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can - be used with the tools of the paraprobe-toolbox. + On a mid term perspective we would like to evolve the paraprobe-toolbox + to an implementation stage where it works exclusively with completely + provenance-tracked formats for both the configuration of the workflow step + and/or analysis with each tool and also for the output of these analyses + in the form of so-called tool-specific results files. + Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. + + Different file formats can be used to inject reconstructed datasets and + ranging definitions into the toolbox. Traditionally, these are the POS, + ePOS, and APT files with the tomographic reconstruction and other metadata + and RNG and RRNG file formats for the ranging definitions how mass-to-charge + state-ratio values map on (molecular) ion types. Such input should be + injected via specific NeXus/HDF5 files which are documented + in compliance with the NXapm application definition. + + So far the paraprobe-toolbox was used as a standalone tool. Therefore, it + was not relevant during the development to focus on interoperability. + Essentially paraprobe-transcoder was used as a parser to transcode data + in the above-mentioned file formats into a paraprobe-specific + representation. This transcoding should become deprecated. + Here we describe steps we have taken into this direction. + + With the work in the FAIRmat project and the desire to make the paraprobe- + toolbox also accessible as a cloud-computing capable service in the Nomad + Remote Tools Hub (NORTH) the topic of interoperability became more important + and eventually the NXapm application definition was proposed. + NORTH is a GUI and related service in a NOMAD OASIS instance which allows + to spawn preconfigured docker containers via JupyterHub. + Currently, NORTH includes the so-called apm container. A container with + tools specific for analyzing data from atom probe microscopy as well as + processing of point cloud and mesh data. + + The NXapm application definition and related implementation work within + NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and + RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook + solutions directly into NOMAD OASIS via the uploads section. + The process is automated and yields an NXapm-compliant NeXus/HDF5 file + inside the uploads section in return. + + With these improvements made there is no longer a need for - at least the + users of a NOMAD OASIS and NORTH instance to use the deprecated + PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should + automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 + file and in response work with this file directly. + To remain compliant with users however who do not have or do not wish + to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is + as follows: + + Calling the configuration stage of paraprobe-transcoder is always mandatory. + It is always the first step of working with the toolbox. In this process + the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ + HDF5 file from e.g. the upload section, or such a file that was obtained from + a colleague with a NOMAD OASIS instance. + In all other cases, users can pass the reconstruction and ranging definitions + using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. + + Based on which input the user delivers, the parmsetup-transcoder tool then + creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and + informs the user whether the input was NeXus (and thus if all relevant + input is already available) or whether the paraprobe-transcoder tool needs + to be executed to convert the content of the vendor files first into a + format which paraprobe can provenance track and understand. + In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is + used to communicate to all subsequently used tools from which files + the tools can expect to find the reconstruction and ranging definitions. + + All subsequent analysis steps start also with a tool-specific configuration. + This configuration step reads in (among others) the + PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration + tool identifies automatically whether to read the reconstruction and ranging data + from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant + NeXus/HDF5 file that was created upon preparing the upload or the file shared + from a colleague. This design removes the need for unnecessary copies of the data. + Currently still though users should execute the transcoder step as it will + generate a supplementary XDMF topology field with which the data in either + the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. + Paraview. For this purpose XDMF is used. + + Of course ideally the APT community would at some point converge to use + a common data exchange file format. To this end, AMETEK/Cameca's APT file format + could be a good starting point but so far it is lacking a consistent way of + how to store generalized ranging definitions and post-processing results. + POS, ePOS, Rouen's ATO, as well as other so far used representations of data + like CSV or text files have, to the best of our current knowledge, no + concept of how to marry reconstruction and (optional) ranging data into + one self-descriptive format. + + This summarizes the rationale behind the current choices of the I/O for + paraprobe. Furthermore, this summarizes also why the fundamental design + of splitting an analysis always into steps of configuration (with parmsetup), + task execution (with the respective C/C++ or Python tool of the toolbox), + and post-processing (e.g. with autoreporter) is useful because it offers + a clear description of provenance tracking. This is a necessary step to make + atom probe microscopy data at all better aligned with the aims of the + FAIR principles. + + The internal organization of the data entries in the atom_probe group + in this application definition for paraprobe-transcoder results files + mirror the definitions of the NXapm for consistency reasons. - - - - - + + + + Mass-to-charge-state ratio values. + + + + + - - + + - This is the collection of iontypes distinguished. - The default unknown iontype always has to map to 0. - Its non-physical mass_to_charge_state_ratio is [0., 0.001] Da. + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. - - - - - - + + + + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + diff --git a/contributed_definitions/NXatom_set.nxdl.xml b/contributed_definitions/NXatom_set.nxdl.xml index 1585bb90c6..f49e5c4dc3 100644 --- a/contributed_definitions/NXatom_set.nxdl.xml +++ b/contributed_definitions/NXatom_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_alpha_shape.nxdl.xml b/contributed_definitions/NXcg_alpha_shape.nxdl.xml index 098047e716..2429e8e130 100644 --- a/contributed_definitions/NXcg_alpha_shape.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_shape.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index e1d2a5d2ee..5ff552a32e 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 1fdd2d6262..6875ba0f3f 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 523113eca2..5782567362 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index ad14400595..d6960c7a6e 100644 --- a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index e6cf52dc6c..0a42909c37 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index b8fd46e631..c05af5e868 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index 4a792fc9e0..efd4770c94 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_isocontour.nxdl.xml b/contributed_definitions/NXcg_isocontour.nxdl.xml index 33c1b91785..8796deb1d9 100644 --- a/contributed_definitions/NXcg_isocontour.nxdl.xml +++ b/contributed_definitions/NXcg_isocontour.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index 8507bc65cf..27c4eeacdc 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index 16f9882592..f43337b4fd 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml index 00992a29e9..cc39bbe4a7 100644 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index a123688ad0..5d2350bd5c 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index d4ba85531d..51be47e636 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index 994f46ba32..983f127c28 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml index e6a865e20b..8451c44d9a 100644 --- a/contributed_definitions/NXcg_roi_set.nxdl.xml +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 845dd3a4d4..31e3d41865 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 878afc1e7c..95ab5ed1d2 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 4bf5b5fc6d..b9e1ff78f0 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index b7da75a056..aad509f715 100644 --- a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index 4f28279b07..705e6fb0f8 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml index 303ef0c503..5411658cd0 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -1,6 +1,6 @@ - + Component of an instrument to store or place objects and specimens. diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml index 1fa70e8d1d..3d3d785819 100644 --- a/contributed_definitions/NXclustering.nxdl.xml +++ b/contributed_definitions/NXclustering.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index e3444193c1..91402c8229 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -1,6 +1,6 @@ - + Container to hold different coordinate systems conventions. diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 3b9fe1d423..e4585c9404 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -1,6 +1,6 @@ - + Corrector for aberrations in an electron microscope. diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index 260c33f6cb..316e4ca373 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_cpu.nxdl.xml b/contributed_definitions/NXcs_cpu.nxdl.xml index a9a1019b6c..7e9d153f88 100644 --- a/contributed_definitions/NXcs_cpu.nxdl.xml +++ b/contributed_definitions/NXcs_cpu.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 99104338ab..40700ebf98 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml index 265052e84f..e73dc05bd7 100644 --- a/contributed_definitions/NXcs_gpu.nxdl.xml +++ b/contributed_definitions/NXcs_gpu.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index 9f66793b19..c5a999dbec 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index f80109d43d..6d7dfaba0f 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index d61664c8bd..eb4bf12748 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml index 64f55e90b9..1b1e98f593 100644 --- a/contributed_definitions/NXcs_prng.nxdl.xml +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml index 6123ef1541..9fc5c53c2e 100644 --- a/contributed_definitions/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index dbc8daaed2..9c22dc560a 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 103ad5fd01..28e3d35f1e 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index 29dc7a3b78..de433ed732 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -1,6 +1,6 @@ - + Container for components to form a controlled beam in electron microscopy. diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 5e61a3c678..4ed1c9204a 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1,6 +1,6 @@ - + Characterization and session with one sample in an electron microscope. diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index db52ba3352..cbe764fe94 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -1,6 +1,6 @@ - + Metadata and settings of an electron microscope for scans and images. diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml index 6a34ac39be..f396f3c2a0 100644 --- a/contributed_definitions/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,6 +1,6 @@ - + Container to hold NXevent_data_em instances of an electron microscope session. diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index 05ba232273..f29254c3ca 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,6 +1,6 @@ - + Details about a component as defined by its manufacturer. diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index ef52fe7743..93472732e7 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index dbff9584b0..545343b83d 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index 08d6a9e1de..f355c0958c 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml index e4c5233b4d..58b594372a 100644 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -1,6 +1,6 @@ - + Container for components of a focused-ion-beam (FIB) system. diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index 6d85eece6b..0eda1ed99a 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 110c8f4049..713ca4e45c 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 31a830311c..5eca5ce343 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -1,6 +1,6 @@ - + Description of an electro-magnetic lens or a compound lens. diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index 0b71bae734..a48bed0c57 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXms_crystal_set.nxdl.xml b/contributed_definitions/NXms_crystal_set.nxdl.xml index ad7cfd2eda..ce7b59758c 100644 --- a/contributed_definitions/NXms_crystal_set.nxdl.xml +++ b/contributed_definitions/NXms_crystal_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXms_snapshot.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml index 16d2b918db..b9247097bf 100644 --- a/contributed_definitions/NXms_snapshot.nxdl.xml +++ b/contributed_definitions/NXms_snapshot.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml index 2ddeddb4b8..90d9ddc115 100644 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 158325e8be..1b0694612c 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -1,6 +1,6 @@ - + A container for qualifying an electron optical system. diff --git a/contributed_definitions/NXorientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml index 9eb562442a..ab86630eb9 100644 --- a/contributed_definitions/NXorientation_set.nxdl.xml +++ b/contributed_definitions/NXorientation_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 5978d27016..e4a04b81a4 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index 42e6d92c96..0e463008b3 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index a2783e9d72..8070c7f1e0 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -1,6 +1,6 @@ - + Device to reduce an atmosphere to a controlled remaining pressure level. diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml index a1eb14dfd8..8cc18002fa 100644 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -1,6 +1,6 @@ - + Device for reducing flight time differences of ions in ToF experiments. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index ffea702947..10140019b1 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -1,6 +1,6 @@ - + Scan box and coils which deflect an electron beam in a controlled manner. diff --git a/contributed_definitions/NXslip_system_set.nxdl.xml b/contributed_definitions/NXslip_system_set.nxdl.xml index b5ac02c4a1..62d159c03e 100644 --- a/contributed_definitions/NXslip_system_set.nxdl.xml +++ b/contributed_definitions/NXslip_system_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index b652d2cd29..dbb8694642 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml index 4ef7757a10..d94dbe0902 100644 --- a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml index 7cbc9d7448..9ac10fcbe5 100644 --- a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index fd1b88f47e..65eb616382 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -1,6 +1,6 @@ - + A stage lab can be used to hold, align, orient, and prepare a specimen. diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index c9337b7cac..b438e2d329 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. From dc903910a3f6d3d1b4082ad6ee90dd272992bb93 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Wed, 14 Sep 2022 11:04:06 +0200 Subject: [PATCH 059/203] added missing deps supporting syntax check workflows --- .github/env-workflow.yml | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/.github/env-workflow.yml b/.github/env-workflow.yml index 92aa682dd5..e3d58257eb 100644 --- a/.github/env-workflow.yml +++ b/.github/env-workflow.yml @@ -5,7 +5,9 @@ channels: - conda-forge dependencies: - - lxml - - pyyaml - - Sphinx - - six + - lxml==4.7.1 + - pyyaml==6.0 + - Sphinx==5.0.2 + - sphinx_comments==0.0.3 + - pyRestTable==2020.0.3 + - six==1.16.0 From a4b0e75f0211c4e7ffc2e7d61af212276646dc17 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Wed, 14 Sep 2022 11:31:59 +0200 Subject: [PATCH 060/203] added workflow dispatch option --- .github/workflows/syntax-checks.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index 38215237b7..32ef28d8a5 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -2,6 +2,7 @@ name: Syntax Checks on: # Triggers the workflow on push or pull request events but only for the main branch + workflow_dispatch: push: branches: - main From 3bfbce9552b84f1a5f2e1a8001cee1a5e328275b Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Wed, 14 Sep 2022 11:36:27 +0200 Subject: [PATCH 061/203] forcing action triggering on push for testing --- .github/workflows/syntax-checks.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index 32ef28d8a5..dae7034be7 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -1,8 +1,8 @@ name: Syntax Checks -on: +on: [push] # Triggers the workflow on push or pull request events but only for the main branch - workflow_dispatch: + # workflow_dispatch: push: branches: - main From 0946ba659037eab41d4de7a3cf12519cbc095132 Mon Sep 17 00:00:00 2001 From: kuehbachm Date: Wed, 14 Sep 2022 11:38:52 +0200 Subject: [PATCH 062/203] testing --- .github/workflows/syntax-checks.yml | 8 -------- 1 file changed, 8 deletions(-) diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index dae7034be7..48fa7b0f2c 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -1,14 +1,6 @@ name: Syntax Checks on: [push] - # Triggers the workflow on push or pull request events but only for the main branch - # workflow_dispatch: - push: - branches: - - main - pull_request: - branches: - - main jobs: build-linux: From 17a15fe5d24d527b07bf8bb80a2ce240bd39e166 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Sep 2022 11:55:32 +0200 Subject: [PATCH 063/203] Try env workflow w/o versions --- .github/env-workflow.yml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/.github/env-workflow.yml b/.github/env-workflow.yml index e3d58257eb..8a4fcaf279 100644 --- a/.github/env-workflow.yml +++ b/.github/env-workflow.yml @@ -5,9 +5,9 @@ channels: - conda-forge dependencies: - - lxml==4.7.1 - - pyyaml==6.0 - - Sphinx==5.0.2 - - sphinx_comments==0.0.3 - - pyRestTable==2020.0.3 - - six==1.16.0 + - lxml + - pyyaml + - Sphinx + - sphinx_comments + - pyRestTable + - six From c17634561b46d7055e3f37cde40dd3542782a696 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Sep 2022 12:01:03 +0200 Subject: [PATCH 064/203] Adds conda-forge to workflow --- .github/workflows/syntax-checks.yml | 103 ++++++++++++++-------------- 1 file changed, 51 insertions(+), 52 deletions(-) diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index 48fa7b0f2c..c71766c393 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -8,63 +8,62 @@ jobs: runs-on: ubuntu-latest strategy: matrix: - python-version: ['3.7', '3.8', '3.9', '3.10'] + python-version: ["3.7", "3.8", "3.9", "3.10"] max-parallel: 5 steps: - - uses: actions/checkout@v2 + - uses: actions/checkout@v2 - - name: Setup Miniconda - uses: conda-incubator/setup-miniconda@v2 - with: - activate-environment: - anaconda-test-env-py-${{ matrix.python-version }} - auto-update-conda: true - channel-priority: true - channels: defaults,conda-forge - mamba-version: "*" - python-version: ${{ matrix.python-version }} - use-only-tar-bz2: true # required for caching - - shell: bash -l {0} - run: | - conda info - conda list - conda config --show-sources - conda config --show - conda env list - printenv | sort + - name: Setup Miniconda + uses: conda-incubator/setup-miniconda@v2 + with: + activate-environment: anaconda-test-env-py-${{ matrix.python-version }} + auto-update-conda: true + channel-priority: true + channels: defaults,conda-forge + mamba-version: "*" + python-version: ${{ matrix.python-version }} + use-only-tar-bz2: true # required for caching + - shell: bash -l {0} + run: | + conda info + conda list + conda config --show-sources + conda config --show + conda env list + printenv | sort - # $CONDA is an environment variable pointing to the - # root of the miniconda directory + # $CONDA is an environment variable pointing to the + # root of the miniconda directory - - name: Install dependencies - run: | - $CONDA/bin/conda env update --file .github/env-workflow.yml --name $ENV_NAME - $CONDA/bin/conda list -r --name $ENV_NAME - env: - PY_VER: ${{ matrix.python-version }} - ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} + - name: Install dependencies + run: | + $CONDA/bin/conda env update -c conda-forge --file .github/env-workflow.yml --name $ENV_NAME + $CONDA/bin/conda list -r --name $ENV_NAME + env: + PY_VER: ${{ matrix.python-version }} + ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} - - name: Run tests - run: | - source $CONDA/bin/activate $ENV_NAME - # pytest -vvv ./utils/test_suite.py - python ./utils/test_suite.py - env: - PY_VER: ${{ matrix.python-version }} - ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} + - name: Run tests + run: | + source $CONDA/bin/activate $ENV_NAME + # pytest -vvv ./utils/test_suite.py + python ./utils/test_suite.py + env: + PY_VER: ${{ matrix.python-version }} + ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} - - name: Build the documentation - run: | - source $CONDA/bin/activate $ENV_NAME - make makebuilddir - pushd build/manual - # CI needs latexmk to execute next line - # make latexpdf && cp build/latex/nexus.pdf build/html/NeXusManual.pdf - cd build - tar czf ../../../docs.tar.gz html - popd - ls -lAGh - env: - PY_VER: ${{ matrix.python-version }} - ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} + - name: Build the documentation + run: | + source $CONDA/bin/activate $ENV_NAME + make makebuilddir + pushd build/manual + # CI needs latexmk to execute next line + # make latexpdf && cp build/latex/nexus.pdf build/html/NeXusManual.pdf + cd build + tar czf ../../../docs.tar.gz html + popd + ls -lAGh + env: + PY_VER: ${{ matrix.python-version }} + ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} From d84244c524a3b2c078ec4ebaf464372ae574d01e Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Sep 2022 12:05:14 +0200 Subject: [PATCH 065/203] Add conda-forge as channel --- .github/workflows/syntax-checks.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index c71766c393..89806b384a 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -38,7 +38,8 @@ jobs: - name: Install dependencies run: | - $CONDA/bin/conda env update -c conda-forge --file .github/env-workflow.yml --name $ENV_NAME + $CONDA/bin/conda config --add channels conda-forge + $CONDA/bin/conda env update --file .github/env-workflow.yml --name $ENV_NAME $CONDA/bin/conda list -r --name $ENV_NAME env: PY_VER: ${{ matrix.python-version }} From d6cfd399931f77974ff7b14c7d0dffbe1bccb0dd Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Sep 2022 12:09:54 +0200 Subject: [PATCH 066/203] Manually install sphinx_comment --- .github/env-workflow.yml | 1 - .github/workflows/syntax-checks.yml | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/.github/env-workflow.yml b/.github/env-workflow.yml index 8a4fcaf279..c1221eb557 100644 --- a/.github/env-workflow.yml +++ b/.github/env-workflow.yml @@ -8,6 +8,5 @@ dependencies: - lxml - pyyaml - Sphinx - - sphinx_comments - pyRestTable - six diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index 89806b384a..6de30b9da5 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -38,8 +38,8 @@ jobs: - name: Install dependencies run: | - $CONDA/bin/conda config --add channels conda-forge $CONDA/bin/conda env update --file .github/env-workflow.yml --name $ENV_NAME + $CONDA/bin/conda install -c conda-forge sphinx_comments $CONDA/bin/conda list -r --name $ENV_NAME env: PY_VER: ${{ matrix.python-version }} From f38ca6c1a1a34a4dae01f21ff6a53bbe534261d8 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Sep 2022 12:13:38 +0200 Subject: [PATCH 067/203] Install sphinx_comments via pip --- .github/workflows/syntax-checks.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index 6de30b9da5..242dc49669 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -39,7 +39,7 @@ jobs: - name: Install dependencies run: | $CONDA/bin/conda env update --file .github/env-workflow.yml --name $ENV_NAME - $CONDA/bin/conda install -c conda-forge sphinx_comments + pip install sphinx_comments $CONDA/bin/conda list -r --name $ENV_NAME env: PY_VER: ${{ matrix.python-version }} From 558368d8b0b5ad732252beb509186b6b3d64e6c1 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Sep 2022 13:41:45 +0200 Subject: [PATCH 068/203] Install sphinx-comments instead of sphinx_comments --- .github/env-workflow.yml | 1 + .github/workflows/syntax-checks.yml | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/env-workflow.yml b/.github/env-workflow.yml index c1221eb557..67116673fb 100644 --- a/.github/env-workflow.yml +++ b/.github/env-workflow.yml @@ -8,5 +8,6 @@ dependencies: - lxml - pyyaml - Sphinx + - sphinx-comments - pyRestTable - six diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index 242dc49669..cbed9e4fbc 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -39,7 +39,6 @@ jobs: - name: Install dependencies run: | $CONDA/bin/conda env update --file .github/env-workflow.yml --name $ENV_NAME - pip install sphinx_comments $CONDA/bin/conda list -r --name $ENV_NAME env: PY_VER: ${{ matrix.python-version }} From d119746515cb79c648db02623db38c68ba74b1f4 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Sep 2022 14:05:32 +0200 Subject: [PATCH 069/203] Reset github action to push, prs and manually --- .github/workflows/syntax-checks.yml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index cbed9e4fbc..997193f8c6 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -1,6 +1,13 @@ name: Syntax Checks -on: [push] +on: + workflow_dispatch: + push: + branches: + - main + pull_request: + branches: + - main jobs: build-linux: From 9708322926d9fd6dc830ef022667febd8c801acc Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Sep 2022 21:49:14 +0200 Subject: [PATCH 070/203] Resets syntax-check action to previous version --- .github/workflows/syntax-checks.yml | 105 ++++++++++++++-------------- 1 file changed, 53 insertions(+), 52 deletions(-) diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index 997193f8c6..1aec652238 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -1,7 +1,7 @@ name: Syntax Checks on: - workflow_dispatch: + # Triggers the workflow on push or pull request events but only for the main branch push: branches: - main @@ -15,62 +15,63 @@ jobs: runs-on: ubuntu-latest strategy: matrix: - python-version: ["3.7", "3.8", "3.9", "3.10"] + python-version: ['3.7', '3.8', '3.9', '3.10'] max-parallel: 5 steps: - - uses: actions/checkout@v2 + - uses: actions/checkout@v2 - - name: Setup Miniconda - uses: conda-incubator/setup-miniconda@v2 - with: - activate-environment: anaconda-test-env-py-${{ matrix.python-version }} - auto-update-conda: true - channel-priority: true - channels: defaults,conda-forge - mamba-version: "*" - python-version: ${{ matrix.python-version }} - use-only-tar-bz2: true # required for caching - - shell: bash -l {0} - run: | - conda info - conda list - conda config --show-sources - conda config --show - conda env list - printenv | sort + - name: Setup Miniconda + uses: conda-incubator/setup-miniconda@v2 + with: + activate-environment: + anaconda-test-env-py-${{ matrix.python-version }} + auto-update-conda: true + channel-priority: true + channels: defaults,conda-forge + mamba-version: "*" + python-version: ${{ matrix.python-version }} + use-only-tar-bz2: true # required for caching + - shell: bash -l {0} + run: | + conda info + conda list + conda config --show-sources + conda config --show + conda env list + printenv | sort - # $CONDA is an environment variable pointing to the - # root of the miniconda directory + # $CONDA is an environment variable pointing to the + # root of the miniconda directory - - name: Install dependencies - run: | - $CONDA/bin/conda env update --file .github/env-workflow.yml --name $ENV_NAME - $CONDA/bin/conda list -r --name $ENV_NAME - env: - PY_VER: ${{ matrix.python-version }} - ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} + - name: Install dependencies + run: | + $CONDA/bin/conda env update --file .github/env-workflow.yml --name $ENV_NAME + $CONDA/bin/conda list -r --name $ENV_NAME + env: + PY_VER: ${{ matrix.python-version }} + ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} - - name: Run tests - run: | - source $CONDA/bin/activate $ENV_NAME - # pytest -vvv ./utils/test_suite.py - python ./utils/test_suite.py - env: - PY_VER: ${{ matrix.python-version }} - ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} + - name: Run tests + run: | + source $CONDA/bin/activate $ENV_NAME + # pytest -vvv ./utils/test_suite.py + python ./utils/test_suite.py + env: + PY_VER: ${{ matrix.python-version }} + ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} - - name: Build the documentation - run: | - source $CONDA/bin/activate $ENV_NAME - make makebuilddir - pushd build/manual - # CI needs latexmk to execute next line - # make latexpdf && cp build/latex/nexus.pdf build/html/NeXusManual.pdf - cd build - tar czf ../../../docs.tar.gz html - popd - ls -lAGh - env: - PY_VER: ${{ matrix.python-version }} - ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} + - name: Build the documentation + run: | + source $CONDA/bin/activate $ENV_NAME + make makebuilddir + pushd build/manual + # CI needs latexmk to execute next line + # make latexpdf && cp build/latex/nexus.pdf build/html/NeXusManual.pdf + cd build + tar czf ../../../docs.tar.gz html + popd + ls -lAGh + env: + PY_VER: ${{ matrix.python-version }} + ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} \ No newline at end of file From d92992b279400c169b2f4df9e15063d003041607 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Sep 2022 21:51:09 +0200 Subject: [PATCH 071/203] Run syntax check on fairmat branch, too --- .github/workflows/syntax-checks.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml index 1aec652238..f421178cfe 100644 --- a/.github/workflows/syntax-checks.yml +++ b/.github/workflows/syntax-checks.yml @@ -5,9 +5,11 @@ on: push: branches: - main + - fairmat pull_request: branches: - main + - fairmat jobs: build-linux: From cb4218d9fdd8ebf286a633baa311a022653ab1ad Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Wed, 14 Sep 2022 22:23:33 +0200 Subject: [PATCH 072/203] Added extends to NXiv_temp --- contributed_definitions/NXiv_temp.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 79473d5837..261a0d91c6 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -1,6 +1,6 @@ - + From 7ca0338ede3bd27c2d67257fa47038349bcc10f5 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Dec 2022 14:15:10 +0100 Subject: [PATCH 073/203] fix NXxpcs units issue --- contributed_definitions/NXxpcs.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/NXxpcs.nxdl.xml b/contributed_definitions/NXxpcs.nxdl.xml index 3024dd7d1c..f3bc8a9ff0 100644 --- a/contributed_definitions/NXxpcs.nxdl.xml +++ b/contributed_definitions/NXxpcs.nxdl.xml @@ -175,7 +175,7 @@ - + delay_difference (also known as delay or lag step) From b31de72c49bebf6ec561201adaf5546fadadd7ab Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 27 Jan 2023 10:49:51 +0100 Subject: [PATCH 074/203] definitions update from NIAC --- applications/NXcanSAS.nxdl.xml | 2 +- applications/NXmx.nxdl.xml | 103 ++++++++-- applications/NXsas.nxdl.xml | 193 ++++++++++--------- applications/NXxas.nxdl.xml | 23 ++- base_classes/NXbeam.nxdl.xml | 203 ++++++++++++++++---- base_classes/NXdata.nxdl.xml | 80 ++++---- base_classes/NXdetector.nxdl.xml | 11 ++ base_classes/NXmonitor.nxdl.xml | 1 - base_classes/NXtransformations.nxdl.xml | 9 + contributed_definitions/NXregion.nxdl.xml | 2 +- contributed_definitions/NXsnsevent.nxdl.xml | 6 +- contributed_definitions/NXsnshisto.nxdl.xml | 6 +- contributed_definitions/NXxpcs.nxdl.xml | 23 ++- 13 files changed, 454 insertions(+), 208 deletions(-) diff --git a/applications/NXcanSAS.nxdl.xml b/applications/NXcanSAS.nxdl.xml index fb3d0ae6c1..e562257c4d 100644 --- a/applications/NXcanSAS.nxdl.xml +++ b/applications/NXcanSAS.nxdl.xml @@ -937,7 +937,7 @@ Description of the radiation source. - Name of the radiation used. diff --git a/applications/NXmx.nxdl.xml b/applications/NXmx.nxdl.xml index 3ba4dac728..0c71dab11f 100644 --- a/applications/NXmx.nxdl.xml +++ b/applications/NXmx.nxdl.xml @@ -348,6 +348,9 @@ a full data array, rather than with a hyperslab within a larger array, then a single module should be defined, spanning the entire array. + + Note, the pixel size is given as values in the array + fast_pixel_direction and slow_pixel_direction. @@ -454,7 +457,7 @@ Boolean to indicate if the distance is a derived, rather than a primary observation. If distance_derived true or is not specified, - the distance is assumed to be derived from delector axis + the distance is assumed to be derived from detector axis specifications. @@ -625,8 +628,35 @@ - True when a count-rate correction has already been applied in - the data recorded here, false otherwise. + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + + + + + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + + + + + + + + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. @@ -676,7 +706,7 @@ - + The value at which the detector goes into saturation. Data above this value is known to be invalid. @@ -687,7 +717,7 @@ - + The lowest value at which pixels for this detector would be reasonably be measured. @@ -736,6 +766,15 @@ + + + Which field contains the measured flux. One of ``flux``, + ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. + + Alternatively, the name being indicated could be a link + to a dataset in an NXmonitor group that records per shot beam data. + + @@ -825,9 +864,38 @@ - + - Flux incident on beam plane in photons per second. + Flux incident on beam plane in photons per second. In other words + this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` integrated + over area. + + Useful where spatial beam profiles are not known. + + In the case of a beam that varies in total flux shot-to-shot, + this is an array of values, one for each recorded shot. + + + + + + Flux density incident on beam plane area in photons + per unit area. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` + integrated over time. + + Useful where temporal beam profiles of flux are not known. + + In the case of a beam that varies in flux shot-to-shot, + this is an array of values, one for each recorded shot. + + + + + + Flux incident on beam plane in photons. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` + integrated over time and area. + + Useful where temporal beam profiles of flux are not known. In the case of a beam that varies in total flux shot-to-shot, this is an array of values, one for each recorded shot. @@ -858,9 +926,23 @@ - - - + + + Polarization vector on entering beamline + component using Stokes notation + + + + + + + + + Polarization vector on entering beamline + component using Stokes notation. See + incident_polarization_stokes in :ref:`NXbeam` + @@ -868,7 +950,6 @@ - The neutron or x-ray storage ring/facility. Note, the NXsource base class diff --git a/applications/NXsas.nxdl.xml b/applications/NXsas.nxdl.xml index aa9ceab24e..a9ffae2657 100644 --- a/applications/NXsas.nxdl.xml +++ b/applications/NXsas.nxdl.xml @@ -2,9 +2,9 @@ - - + + Beam crossfire in degrees parallel to the laboratory X axis + + The dimension **c** is a series of moments of that represent + the standard uncertainty (e.s.d.) of the directions of + of the beam. The first and second moments are in the XZ and YZ + planes around the mean source beam direction, respectively. + + Further moments in **c** characterize co-variance terms, so + the next moment is the product of the first two, and so on. + + + + - Size of the beam entering this component - - - + + Size of the beam entering this component. Note this represents + a rectangular beam aperture, and values represent FWHM + + + + Wavelength on leaving beamline component - + - + Polarization vector on entering beamline component - - - + + + - + Polarization vector on leaving beamline component - - - + + + + + + + + Polarization vector on entering beamline component using Stokes notation + + The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. + These are defined with the standard Nexus coordinate frame unless it is + overridden by an NXtransformations field pointed to by a depends_on attribute. + The last component, describing the circular polarization state, is positive + for a right-hand circular state - that is the electric field vector rotates + clockwise at the sample and over time when observed from the source. + + I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale + linearly with the total degree of polarization, and indicate the relative + magnitudes of the pure linear and circular orientation contributions. + + Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). + + U (S_2) is linearly polarized along the x==y axis (U > 0) or the + -x==y axis (U < 0). + + V (S_3) is circularly polarized. V > 0 when the electric field vector rotates + clockwise at the sample with respect to time when observed from the source; + V < 0 indicates the opposite rotation. + + + + + + + + + Polarization vector on leaving beamline component using Stokes notation + (see incident_polarization_stokes). + + + + Wavelength spread FWHM of beam leaving this component - + Divergence FWHM of beam leaving this component - - - + + + flux incident on beam plane area - + @@ -132,10 +251,10 @@ .. 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 diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index fe547ef693..774c653253 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -43,7 +43,7 @@ These symbols will be used below to coordinate fields with the same shape. rank of the ``DATA`` field - length of the ``VARIABLE`` field + length of the ``AXISNAME`` field length of the ``x`` field length of the ``y`` field length of the ``z`` field @@ -53,10 +53,11 @@ .. index:: plotting - Array of strings holding the names of additional signals to - be plotted with the default signal (specified by the - ``signal`` attribute). Each auxiliary signal needs to be of - the same shape as the default signal. + Array of strings holding the :ref:`names <validItemName>` of additional + signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. .. NIAC2018: https://www.nexusformat.org/NIAC2018Minutes.html @@ -69,9 +70,8 @@ .. index:: signal attribute value Declares which NeXus field is the default. - The value is the name of the NeXus field to be plotted. - (The value :ref:`names <validItemName>` an existing child - of this group. The child group must itself be a NeXus group.) + The value is the :ref:`name <validItemName>` of the data field to be plotted. + This field or link *must* exist and be a direct child of this NXdata group. It is recommended (as of NIAC2014) to use this attribute rather than adding a signal attribute to the field. @@ -83,16 +83,19 @@ .. index:: plotting - String array that defines the independent data fields used in - the default plot for all of the dimensions of the *signal* field - (the *signal* field is the field in this group that is named by - the ``signal`` attribute of this group). - One entry is provided for every dimension in the *signal* field. + Array of strings holding the :ref:`names <validItemName>` of + the independent data fields used in the default plot for all of + the dimensions of the :ref:`signal </NXdata@signal-attribute>` + as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. + + One name is provided for every dimension in the *signal* or *auxiliary signal* fields. - The field(s) named as values (known as "axes") of this attribute - *must* exist. An axis slice is specified using a field named - ``AXISNAME_indices`` as described below (where the text shown here - as ``AXISNAME`` is to be replaced by the actual field name). + The *axes* values are the names of fields or links that *must* exist and be direct + children of this NXdata group. + + An axis slice is specified using a field named ``AXISNAME_indices`` + as described below (where the text shown here as ``AXISNAME`` is to be + replaced by the actual field name). When no default axis is available for a particular dimension of the plottable data, use a "." in that position. @@ -100,8 +103,8 @@ @axes=["time", ".", "."] - Since there are three items in the list, the the *signal* field - must must be a three-dimensional array (rank=3). The first dimension + Since there are three items in the list, the *signal* field + must be a three-dimensional array (rank=3). The first dimension is described by the values of a one-dimensional array named ``time`` while the other two dimensions have no fields to be used as dimension scales. @@ -166,7 +169,7 @@ It is strongly recommended that there is at least one :ref:`NXdata` group in each :ref:`NXentry` group. - Note that the fields named ``VARIABLE`` and ``DATA`` + Note that the fields named ``AXISNAME`` and ``DATA`` can be defined with different names. (Upper case is used to indicate that the actual name is left to the user.) The ``signal`` and ``axes`` attributes of the @@ -270,7 +273,7 @@ but not to describe how the data is to be plotted. (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) - + Dimension scale defining an axis of the data. Client is responsible for defining the dimensions of the data. @@ -304,26 +307,15 @@ - + - "Errors" (actually *uncertainties*) associated with axis ``VARIABLE``. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances - but is matched with the *VARIABLE* field with ``_errors`` appended. - - This pattern of using ``VARIABLE_errors`` can be used - throughout a NeXus data file to associate uncertainties - with a field named ``VARIABLE``. This pattern also - applies to other relationships such as ``VARIABLE_resolutions`` - to connect additional data with a certain field. + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. - - - A dimension scale must have a rank of 1 and has length ``n``, - same as ``VARIABLE``. - - - @@ -342,7 +334,6 @@ ``1 <= dataRank <= NX_MAXRANK=32``. At least one ``dim`` must have length ``n``. - @@ -366,19 +357,15 @@ Do not use the ``axes`` attribute with the ``axis`` attribute. - data label - + Standard deviations of data values - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``data``. + The ``errors`` array must have the same dimensions as ``DATA``. Client is responsible for defining the dimensions of the data. @@ -388,7 +375,6 @@ as the ``data``. At least one ``dim`` must have length "n". - diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index 1b7b406aa5..a6bb0b8c68 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -743,6 +743,17 @@ + + + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + + How many bits the electronics reads per pixel. diff --git a/base_classes/NXmonitor.nxdl.xml b/base_classes/NXmonitor.nxdl.xml index 7723f8a50a..fce17418f2 100644 --- a/base_classes/NXmonitor.nxdl.xml +++ b/base_classes/NXmonitor.nxdl.xml @@ -96,7 +96,6 @@ ``1 <= dataRank <= NX_MAXRANK=32``. At least one ``dim`` must have length ``n``. - diff --git a/base_classes/NXtransformations.nxdl.xml b/base_classes/NXtransformations.nxdl.xml index ac68a084be..9be3577f26 100644 --- a/base_classes/NXtransformations.nxdl.xml +++ b/base_classes/NXtransformations.nxdl.xml @@ -173,6 +173,15 @@ depends or the string ".". + + + An arbitrary identifier of a component of the equipment to which + the transformation belongs, such as 'detector_arm' or 'detector_module'. + NXtransformations with the same equipment_component label form a logical + grouping which can be combined together into a single change-of-basis + operation. + + diff --git a/contributed_definitions/NXregion.nxdl.xml b/contributed_definitions/NXregion.nxdl.xml index 777954f899..bffff2da59 100644 --- a/contributed_definitions/NXregion.nxdl.xml +++ b/contributed_definitions/NXregion.nxdl.xml @@ -140,7 +140,7 @@ An optional field to define the block size used to copy or downsample data. In the - :math:`i`-th dimension, if :math:`\mathbf{block}[i] \lt \mathbf{stride}[i]` + :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` then the blocks are contiguous; otherwise the blocks overlap. If omitted then defined as an array of ones. diff --git a/contributed_definitions/NXsnsevent.nxdl.xml b/contributed_definitions/NXsnsevent.nxdl.xml index 822253b4fc..934ada4985 100644 --- a/contributed_definitions/NXsnsevent.nxdl.xml +++ b/contributed_definitions/NXsnsevent.nxdl.xml @@ -3,7 +3,7 @@ - - @@ -39,7 +39,7 @@ Motor logs from cvinfo file. - diff --git a/contributed_definitions/NXsnshisto.nxdl.xml b/contributed_definitions/NXsnshisto.nxdl.xml index 1321787f2f..2e94b7c71e 100644 --- a/contributed_definitions/NXsnshisto.nxdl.xml +++ b/contributed_definitions/NXsnshisto.nxdl.xml @@ -3,7 +3,7 @@ - - @@ -39,7 +39,7 @@ Motor logs from cvinfo file. - diff --git a/contributed_definitions/NXxpcs.nxdl.xml b/contributed_definitions/NXxpcs.nxdl.xml index f3bc8a9ff0..9839fbb2a9 100644 --- a/contributed_definitions/NXxpcs.nxdl.xml +++ b/contributed_definitions/NXxpcs.nxdl.xml @@ -57,15 +57,32 @@ - Unique identifier for the experiment. + **Locally** unique identifier for the experiment (a.k.a. run or scan). + + * For bluesky users, this is the run's `"scan_id"`. + * For SPEC users, this is the scan number (``SCAN_N``). (optional) UUID identifier for this entry. + + See the `UUID standard <https://www.rfc-editor.org/rfc/rfc4122.html>`__ (or + `wikipedia <https://en.wikipedia.org/wiki/Universally_unique_identifier>`__) + for more information. + + * For `bluesky <https://blueskyproject.io/>`__ users, this is the + run's `"uid"` and is expected for that application. + * Typically, `SPEC <https://certif.com/content/spec/>`__ users will + not use this field without further engineering. - + + Scan number (must be an integer). @@ -160,7 +177,7 @@ - + unnormalized intensity auto-correlation function. From 67f7a51fb0dcf6e16fd2bccfcdbc000ebff6d2ac Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Fri, 27 Jan 2023 15:01:31 +0100 Subject: [PATCH 075/203] Atom Types is included in mpes --- contributed_definitions/NXmpes.nxdl.xml | 80 +++++++++++++++++++------ 1 file changed, 61 insertions(+), 19 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 8f20886ee0..aace0f8271 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -18,8 +18,41 @@ + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + - + The source used to generate the primary photons. Properties refer strictly to @@ -54,18 +87,18 @@ - + Distance of the point of evaluation of the beam from the sample surface. - - - + + + - + Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. @@ -113,7 +146,7 @@ - + @@ -164,14 +197,14 @@ - - - Manipulator for positioning of the sample. - - - - - + + + + Manipulator for positioning of the sample. + + + + @@ -237,6 +270,15 @@ group in NXsample instead. + + + Use Hill's system for listing existing elements of periodic table which are + inside or attached to the surface of the specimen and thus relevant from a + scientific point. The purpose of this field is to allow material databases to + parse the relevant elements without having to interpret the sample history or + other fields. + + A descriptor to keep track of the treatment of the sample before entering the @@ -248,8 +290,8 @@ - Date of preparation of the sample for the XPS experiment (i.e. - cleaving, last annealing). + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). @@ -277,7 +319,7 @@ - + @@ -285,7 +327,7 @@ - + Represents a measure of one- or more-dimensional photoemission counts, where the varied axis may be for example energy, momentum, spatial coordinate, pump-probe From ceba1f2c7cb1cdd1fc97ed82801f63ab9e17bdc2 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Tue, 31 Jan 2023 11:45:40 +0100 Subject: [PATCH 076/203] Revert "Merge pull request #14 from FAIRmat-Experimental/IncludingAtomType" This reverts commit 7e162073f385a0470d0630635808997babbfbd10, reversing changes made to 9f5d9015788c3586ca300971ac8626bd771161cc. --- contributed_definitions/NXmpes.nxdl.xml | 80 ++++++------------------- 1 file changed, 19 insertions(+), 61 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index aace0f8271..8f20886ee0 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -18,41 +18,8 @@ - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - + The source used to generate the primary photons. Properties refer strictly to @@ -87,18 +54,18 @@ - + Distance of the point of evaluation of the beam from the sample surface. - - - + + + - + Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. @@ -146,7 +113,7 @@ - + @@ -197,14 +164,14 @@ - - - - Manipulator for positioning of the sample. - - - - + + + Manipulator for positioning of the sample. + + + + + @@ -270,15 +237,6 @@ group in NXsample instead. - - - Use Hill's system for listing existing elements of periodic table which are - inside or attached to the surface of the specimen and thus relevant from a - scientific point. The purpose of this field is to allow material databases to - parse the relevant elements without having to interpret the sample history or - other fields. - - A descriptor to keep track of the treatment of the sample before entering the @@ -290,8 +248,8 @@ - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). + Date of preparation of the sample for the XPS experiment (i.e. + cleaving, last annealing). @@ -319,7 +277,7 @@ - + @@ -327,7 +285,7 @@ - + Represents a measure of one- or more-dimensional photoemission counts, where the varied axis may be for example energy, momentum, spatial coordinate, pump-probe From 0a1fef0e5f6589769d11db599baea210a24452ce Mon Sep 17 00:00:00 2001 From: sanbrock Date: Tue, 31 Jan 2023 17:46:54 +0100 Subject: [PATCH 077/203] new CI --- .github/workflows/ci.yaml | 101 ++++++++++++++++++++++++++++ .github/workflows/syntax-checks.yml | 79 ---------------------- 2 files changed, 101 insertions(+), 79 deletions(-) create mode 100644 .github/workflows/ci.yaml delete mode 100644 .github/workflows/syntax-checks.yml diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml new file mode 100644 index 0000000000..1311c93fd0 --- /dev/null +++ b/.github/workflows/ci.yaml @@ -0,0 +1,101 @@ +name: CI + +on: + push: + branches: + - main # push commit to the main branch + - fairmat + pull_request: + branches: + - main # pull request to the main branch + - fairmat + workflow_dispatch: # allow manual triggering + inputs: + deploy: + description: 'Deploy documentation' + type: boolean + required: true + default: false + +defaults: + run: + shell: bash + +jobs: + build-linux: + name: CI py${{ matrix.python-version }} + runs-on: ubuntu-latest + strategy: + matrix: + python-version: ['3.7', '3.8', '3.9', '3.10'] + max-parallel: 5 + env: + python_version: ${{ matrix.python-version }} + + steps: + - name: Checkout Repository + uses: actions/checkout@v2 + with: + fetch-depth: 0 + + - name: Deploy Information + if: ${{ github.event.inputs.deploy && env.python_version == '3.7' }} + run: | + echo "The HTML NeXus User Manual will be pushed to" + echo " https://github.com/nexusformat/definitions/tree/gh-pages" + echo "The HTML NeXus User Manual will be deployed on" + echo " https://nexusformat.github.io/definitions/" + + - name: Install Requirements + run: | + python3 -m pip install --upgrade pip setuptools + make install + python3 -m pip list + + - name: Check Code Style + run: | + make style + + - name: Run Tests + run: | + make test + + - name: Install LaTeX + run: | + sudo apt-get update -y && \ + sudo apt-get install -y \ + latexmk \ + texlive-latex-recommended \ + texlive-latex-extra \ + texlive-fonts-recommended + + - name: Generate build files + run: | + make prepare + + - name: Build Impatient Guid + run: | + make impatient-guide + ls -lAFgh build/impatient-guide/build/html/index.html + ls -lAFgh build/impatient-guide/build/latex/NXImpatient.pdf + + - name: Build User Manual + run: | + make pdf + make html + ls -lAFgh build/manual/build/html/index.html + ls -lAFgh build/manual/build/latex/nexus.pdf + + - name: Build and Commit the User Manual + if: ${{ github.event.inputs.deploy && env.python_version == '3.7' }} + uses: sphinx-notes/pages@master + with: + # path to the conf.py directory + documentation_path: build/manual/source + + - name: Deploy the User Manual + if: ${{ github.event.inputs.deploy && env.python_version == '3.7' }} + uses: ad-m/github-push-action@master + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + branch: gh-pages diff --git a/.github/workflows/syntax-checks.yml b/.github/workflows/syntax-checks.yml deleted file mode 100644 index f421178cfe..0000000000 --- a/.github/workflows/syntax-checks.yml +++ /dev/null @@ -1,79 +0,0 @@ -name: Syntax Checks - -on: - # Triggers the workflow on push or pull request events but only for the main branch - push: - branches: - - main - - fairmat - pull_request: - branches: - - main - - fairmat - -jobs: - build-linux: - name: CI py${{ matrix.python-version }} - runs-on: ubuntu-latest - strategy: - matrix: - python-version: ['3.7', '3.8', '3.9', '3.10'] - max-parallel: 5 - - steps: - - uses: actions/checkout@v2 - - - name: Setup Miniconda - uses: conda-incubator/setup-miniconda@v2 - with: - activate-environment: - anaconda-test-env-py-${{ matrix.python-version }} - auto-update-conda: true - channel-priority: true - channels: defaults,conda-forge - mamba-version: "*" - python-version: ${{ matrix.python-version }} - use-only-tar-bz2: true # required for caching - - shell: bash -l {0} - run: | - conda info - conda list - conda config --show-sources - conda config --show - conda env list - printenv | sort - - # $CONDA is an environment variable pointing to the - # root of the miniconda directory - - - name: Install dependencies - run: | - $CONDA/bin/conda env update --file .github/env-workflow.yml --name $ENV_NAME - $CONDA/bin/conda list -r --name $ENV_NAME - env: - PY_VER: ${{ matrix.python-version }} - ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} - - - name: Run tests - run: | - source $CONDA/bin/activate $ENV_NAME - # pytest -vvv ./utils/test_suite.py - python ./utils/test_suite.py - env: - PY_VER: ${{ matrix.python-version }} - ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} - - - name: Build the documentation - run: | - source $CONDA/bin/activate $ENV_NAME - make makebuilddir - pushd build/manual - # CI needs latexmk to execute next line - # make latexpdf && cp build/latex/nexus.pdf build/html/NeXusManual.pdf - cd build - tar czf ../../../docs.tar.gz html - popd - ls -lAGh - env: - PY_VER: ${{ matrix.python-version }} - ENV_NAME: anaconda-test-env-py-${{ matrix.python-version }} \ No newline at end of file From 4c3cf3b0d55bb9e5cd79392367bf471f34169222 Mon Sep 17 00:00:00 2001 From: sanbrock Date: Tue, 31 Jan 2023 18:53:46 +0100 Subject: [PATCH 078/203] fix merge resolution --- nxdl.xsd | 298 +++++++++++++++++++++++++++---------------------------- 1 file changed, 145 insertions(+), 153 deletions(-) diff --git a/nxdl.xsd b/nxdl.xsd index b78a745c45..f5e733dd16 100755 --- a/nxdl.xsd +++ b/nxdl.xsd @@ -11,38 +11,38 @@ NeXus - Neutron and X-ray Common Data Format Copyright (C) 2008-2022 NeXus International Advisory Committee (NIAC) - + This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. - + This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. - + You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - + For further information, see http://www.nexusformat.org - + - + - Definitions of the basic data types and unit types + Definitions of the basic data types and unit types allowed in NXDL instance files. - + - + @@ -51,27 +51,27 @@ is the ``group`` at the root of every NXDL specification. It may *only* appear - at the root of an NXDL file and must only appear + at the root of an NXDL file and must only appear **once** for the NXDL to be *well-formed*. - + - + - Used for allowed names of elements and attributes. + Used for allowed names of elements and attributes. Note: No ``-`` characters (among others) are allowed and you cannot start or end with a period (``.``). - HDF4 had a 64 character limit on names - (possibly including NULL) and the NAPI enforces this - via the ``NX_MAXNAMELEN`` variable with + HDF4 had a 64 character limit on names + (possibly including NULL) and the NAPI enforces this + via the ``NX_MAXNAMELEN`` variable with a **64** character limit (which may be 63 on a practical basis if one considers a NULL terminating byte). - (This data type is used internally in the NXDL schema + (This data type is used internally in the NXDL schema to define a data type.) NOTE: In some languages, it may be necessary to add a ``^`` at the start and a ``$`` at the end of the regular @@ -83,49 +83,49 @@ - + Used for allowed names of NX class types (e.g. NXdetector). Note this is *not* the instance name (e.g. ``bank1``) which is covered by ``validItemName``. - (This data type is used internally in the NXDL schema + (This data type is used internally in the NXDL schema to define a data type.) - - + + - + This is a valid link target - currently it must be an absolute path made up of valid names with the ``/`` character delimiter. But we may want to consider allowing "``..``" (parent of directory) at some point. - If the ``name`` attribute is helpful, then use it in the path + If the ``name`` attribute is helpful, then use it in the path with the syntax of *name:type* as in these examples:: - + /NXentry/NXinstrument/analyzer:NXcrystal/ef /NXentry/NXinstrument/monochromator:NXcrystal/ei /NX_other - + Must also consider use of ``name`` attribute in resolving ``link`` targets. - (This data type is used internally in the NXDL schema + (This data type is used internally in the NXDL schema to define a data type.) - - + + From the HDF5 documentation: - - *Note that relative path names in HDF5 do not employ the ``../`` notation, + + *Note that relative path names in HDF5 do not employ the ``../`` notation, the UNIX notation indicating a parent directory, to indicate a parent group.* - - Thus, if we only consider the case of + + Thus, if we only consider the case of ``[name:]type``, the matching regular expression syntax is written: ``/[a-zA-Z_][\w_]*(:[a-zA-Z_][\w_]*)?)+``. Note that HDF5 also permits relative path names, such as: @@ -136,28 +136,28 @@ - + - + - The presence of the ``deprecated`` attribute + The presence of the ``deprecated`` attribute indicates to the data file validation process that an advisory message (specified as the content of the - ``deprecated`` attribute) will be reported. + ``deprecated`` attribute) will be reported. Future versions of the NXDL file might not define (or even re-use) the component marked with this attribute. - + The value of the attribute will be printed in the documentation. Make it descriptive (limited to no line breaks). For example:: - + deprecated="as of release MAJOR.MINOR" - - Note: because ``deprecated`` is an attribute, - the XML rules do not permit it to have any + + Note: because ``deprecated`` is an attribute, + the XML rules do not permit it to have any element content. @@ -173,25 +173,25 @@ A ``definition`` is the root element of every NXDL definition. - It may *only* appear at the root of an NXDL file and must only + It may *only* appear at the root of an NXDL file and must only appear **once** for the NXDL to be *well-formed*. - The ``definitionType`` defines the documentation, + The ``definitionType`` defines the documentation, attributes, fields, and groups that will be used as children of the ``definition`` element. Could contain these elements: - + * ``attribute`` * ``doc`` * ``field`` * ``group`` * ``link`` - Note that a ``definition`` element also includes the definitions of the + Note that a ``definition`` element also includes the definitions of the ``basicComponent`` data type. - (The ``definitionType`` data type is used internally in the NXDL schema + (The ``definitionType`` data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) - + Note that the first line of text in a ``doc`` element in a ``definition`` is used as a summary in the manual. Follow the pattern as shown in the base class NXDL files. @@ -201,7 +201,7 @@ - Use a ``symbols`` list + Use a ``symbols`` list to define each of the mnemonics that represent the length of each dimension in a vector or array. @@ -299,7 +299,7 @@ their definition in the NeXus base classes and application definitions. Any items found that do not match the definition in the NXDL will generate a warning message. - + The ``ignoreExtraGroups`` attribute should be used sparingly! @@ -315,7 +315,7 @@ their definition in the NeXus base classes and application definitions. Any items found that do not match the definition in the NXDL will generate a warning message. - + The ``ignoreExtraFields`` attribute should be used sparingly! @@ -331,14 +331,14 @@ against their definition in the NeXus base classes and application definitions. Any items found that do not match the definition in the NXDL will generate a warning message. - + The ``ignoreExtraAttributes`` attribute should be used sparingly! - + @@ -352,9 +352,9 @@ - + - + @@ -368,7 +368,7 @@ NeXus base class that could be used here. - The group will take the ``@name`` attribute + The group will take the ``@name`` attribute defined by the parent ``choice`` element so do not specify the ``@name`` attribute of the group here. @@ -380,32 +380,32 @@ - The name to be applied to the selected child group. - None of the child groups should define a + The name to be applied to the selected child group. + None of the child groups should define a ``@name`` attribute. - + - + - A group element refers to the definition of + A group element refers to the definition of an existing NX object or a locally-defined component. Could contain these elements: - + * ``attribute`` * ``doc`` * ``field`` * ``group`` * ``link`` - - Note that a ``group`` element also includes the definitions of the + + Note that a ``group`` element also includes the definitions of the ``basicComponent`` data type. - (The ``groupType`` data type is used internally in the NXDL schema + (The ``groupType`` data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) @@ -419,8 +419,8 @@ - The ``type`` attribute *must* - contain the name of a + The ``type`` attribute *must* + contain the name of a NeXus base class, application definition, or contributed definition. @@ -433,16 +433,16 @@ required to specify the ``name`` attribute in the NXDL file. It is suggested to always specify a ``name`` - to avoid ambiguity. It is also suggested to - derive the ``name`` from the + to avoid ambiguity. It is also suggested to + derive the ``name`` from the type, using an additional number suffix as necessary. - For example, consider a data file with only one - ``NXentry``. The suggested default + For example, consider a data file with only one + ``NXentry``. The suggested default ``name`` would be ``entry``. For a data file with two or more ``NXentry`` groups, the suggested names would be ``entry1``, ``entry2``, ... - Alternatively, a scientific application such as small-angle + Alternatively, a scientific application such as small-angle scattering might require a different naming procedure; two different ``NXaperture`` groups might be given the names ``beam_defining_slit`` @@ -491,7 +491,7 @@ - A ``groupGroup`` defines the allowed children of a + A ``groupGroup`` defines the allowed children of a ``group`` specification. @@ -499,12 +499,12 @@ - Describe the purpose of this ``group``. + Describe the purpose of this ``group``. This documentation will go into the manual. The first line should summarize as a complete sentence with no line break. (The automatic documentation will pick just the first line as a - summary.) Then a blank line should be added + summary.) Then a blank line should be added before any further documentation. Indentation should be consistent with rules for reStructured text. @@ -514,7 +514,7 @@ - Use an ``attribute`` if additional information + Use an ``attribute`` if additional information needs to be associated with a ``group``. @@ -544,7 +544,7 @@ - Use a ``link`` to refer locally to + Use a ``link`` to refer locally to information placed elsewhere else in the data storage hierarchy. The ``name`` attribute uniquely identifies the element in this ``group``. @@ -557,9 +557,9 @@ The value, as written in the NXDL file, will be a suggestion of the path to the source of the link. For example:: - + - + The value of ``target`` is written using the NeXus class names since this is a suggestion and does not actually use the element names from a particular data file. @@ -612,19 +612,19 @@ - + A ``field`` declares a new element in the component being defined. A ``field`` is synonymous with the HDF4 SDS (Scientific Data Set) and the HDF5 *dataset* terms. Could contain these elements: - + * ``attribute`` * ``dimensions`` * ``doc`` * ``enumeration`` - + Note that a ``field`` element also includes the definitions of the ``basicComponent`` data type. (The ``fieldType`` data type is used internally in the NXDL schema @@ -678,7 +678,7 @@ Presence of the ``signal`` attribute means this field is an ordinate. - + Integer marking this field as plottable data (ordinates). The value indicates the priority of selection or interest. Some facilities only use ``signal=1`` @@ -686,7 +686,7 @@ plottable data of secondary interest. Higher numbers are possible but not common and interpretation is not standard. - + A field with a ``signal`` attribute should not have an ``axis`` attribute. @@ -698,7 +698,7 @@ *field* is discouraged. It is for legacy support. You should use the ``axes`` group attribute (such as in NXdata) instead. - + This attribute contains a string array that defines the independent data fields used in the default plot for all of the dimensions @@ -722,28 +722,28 @@ NOTE: Use of this attribute is discouraged. It is for legacy support. You should use the ``axes`` group attribute (such as in NXdata) instead. - + Presence of the ``axis`` attribute means this field is an abscissa. - + The attribute value is an integer indicating this field as an axis that is part of the data set. The data set is a field with the attribute ``signal=1`` in the same group. The value can range from 1 up to the number of independent axes (abscissae) in the data set. - + A value of ``axis=1``" indicates that this field contains the data for the first independent axis. For example, the X axis in an XY data set. - + A value of ``axis=2`` indicates that this field contains the data for the second independent axis. For example, the Y axis in a 2-D data set. - + A value of ``axis=3`` indicates that this field contains the data for the third independent axis. For example, the Z axis in a 3-D data set. - + A field with an ``axis`` attribute should not have a ``signal`` attribute. @@ -754,7 +754,7 @@ Integer indicating the priority of selection of this field for plotting (or visualization) as an axis. - + Presence of the ``primary`` attribute means this field is an abscissa. @@ -807,11 +807,11 @@ The ``stride`` and ``data_offset`` attributes - are used together to index the array of data items in a + are used together to index the array of data items in a multi-dimensional array. They may be used as an alternative method to address a data array that is not stored in the standard NeXus method of "C" order. - + The ``stride`` list chooses array locations from the data array with each value in the ``stride`` list determining how many elements to move in each dimension. @@ -822,11 +822,11 @@ data array. A value in the ``stride`` list may be positive to move forward or negative to step backward. A value of zero will not step (and is of no particular use). - + See https://support.hdfgroup.org/HDF5/Tutor/phypereg.html or *4. Dataspace Selection Operations* in https://portal.hdfgroup.org/display/HDF5/Dataspaces - + The ``stride`` attribute contains a comma-separated list of integers. (In addition to the required comma delimiter, @@ -849,15 +849,15 @@ multi-dimensional array. They may be used as an alternative method to address a data array that is not stored in the standard NeXus method of "C" order. - + The ``data_offset`` attribute determines the starting coordinates of the data array for each dimension. - + See https://support.hdfgroup.org/HDF5/Tutor/phypereg.html or *4. Dataspace Selection Operations* in https://portal.hdfgroup.org/display/HDF5/Dataspaces - + The ``data_offset`` attribute contains a comma-separated list of integers. (In addition to the required comma delimiter, @@ -875,7 +875,7 @@ This instructs the consumer of the data what the last dimensions of the data are. It allows plotting software to work out the natural way of displaying the data. - + For example a single-element, energy-resolving, fluorescence detector with 512 bins should have ``interpretation="spectrum"``. If the detector is scanned over a 512 x 512 spatial grid, the data reported @@ -883,9 +883,9 @@ In this example, the initial plotting representation should default to data of the same dimensions of a 512 x 512 pixel ``image`` detector where the images where taken at 512 different pressure values. - + In simple terms, the allowed values mean: - + * ``scalar`` = 0-D data to be plotted * ``scaler`` = DEPRECATED, use ``scalar`` * ``spectrum`` = 1-D data to be plotted @@ -931,18 +931,18 @@ - + Any new group or field may expect or require some common attributes. - + .. Could contain these elements: - + * ``doc`` * ``enumeration`` - + (This data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) @@ -1005,14 +1005,6 @@ - - - - A synonym for optional, but with the recommendation that this - attribute be specified. - - - @@ -1038,7 +1030,7 @@ - + @@ -1054,24 +1046,24 @@ Declares the absolute HDF5 address of an existing field or group. - + The target attribute is added for NeXus to distinguish the HDF5 path to the original dataset. - + Could contain these elements: - + * ``doc`` - + Matching regular expression:: - + (/[a-zA-Z_][\w_]*(:[a-zA-Z_][\w_]*)?)+ - + For example, given a ``/entry/instrument/detector/polar_angle`` field, link it into the ``NXdata`` group (at ``/entry/data/polar_angle``). This would be the NeXus data file structure:: - + /: NeXus/HDF5 data file /entry:NXentry /data:NXdata @@ -1081,7 +1073,7 @@ /detector:NXdetector /polar_angle:NX_NUMBER @target="/entry/instrument/detector/polar_angle" - + @@ -1090,7 +1082,7 @@ Group attribute that provides a URL to a group in another file. More information is described in the *NeXus Programmers Reference*. - + http://manual.nexusformat.org/_static/NeXusIntern.pdf @@ -1098,7 +1090,7 @@ - + @@ -1111,17 +1103,17 @@ Descriptive name of sample - + This is suitable for basic descriptions that do not need extra formatting such as a bullet-list or a table. For more advanced control, use the rules of restructured text, such as in the :ref:`NXdetector` specification. Refer to examples in the NeXus base class NXDL files such as :ref:`NXdata`. Could contain these elements: - + * *any* - - (This data type is used internally in the NXDL schema + + (This data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) Note: @@ -1136,14 +1128,14 @@ - + Each ``symbol`` has a ``name`` and optional documentation. Please provide documentation that indicates what each symbol represents. For example:: - + number of reflecting surfaces number of wavelengths @@ -1191,7 +1183,7 @@ - + @@ -1199,15 +1191,15 @@ Each value is specified using an ``item`` element, such as: ``<item value="Synchrotron X-ray Source" />``. Could contain these elements: - + * ``doc`` * ``item`` - - (This data type is used internally in the NXDL schema + + (This data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) - + :: - + source operating mode @@ -1228,7 +1220,7 @@ Defines the value of one selection for an ``enumeration`` list. Each enumerated item must have a value (it cannot have an empty text node). - + @@ -1253,10 +1245,10 @@ - + - @@ -1283,10 +1275,10 @@ the ``rank`` of the array. For example, these terms describe a 2-D array with lengths (``nsurf``, ``nwl``): - + .. code-block:: xml :linenos: - + @@ -1322,9 +1314,9 @@ - Deprecated: 2016-11-23 telco + Deprecated: 2016-11-23 telco (https://github.com/nexusformat/definitions/issues/330) - + The dimension specification is the same as that in the ``ref`` field, specified either by a relative path, such as ``polar_angle`` or ``../Qvec`` or absolute path, such as @@ -1335,9 +1327,9 @@ - Deprecated: 2016-11-23 telco + Deprecated: 2016-11-23 telco (https://github.com/nexusformat/definitions/issues/330) - + The dimension specification is the same as the ``refindex`` axis within the ``ref`` field. Requires ``ref`` attribute to be present. @@ -1347,9 +1339,9 @@ - Deprecated: 2016-11-23 telco + Deprecated: 2016-11-23 telco (https://github.com/nexusformat/definitions/issues/330) - + The dimension specification is related to the ``refindex`` axis within the ``ref`` field by an offset of ``incr``. Requires ``ref`` and ``refindex`` @@ -1361,9 +1353,9 @@ This dimension is required (true: default) or not required (false). - + The default value is ``true``. - + When ``required="false"`` is specified, all subsequent ``<dim`` nodes (with higher ``index`` value) @@ -1378,10 +1370,10 @@ Rank (number of dimensions) of the data structure. - + Value could be either an unsigned integer or a symbol as defined in the *symbol* table of the NXDL file. - + For example: ``a[5]`` has ``rank="1"`` while ``b[8,5,6,4]`` has ``rank="4"``. See https://en.wikipedia.org/wiki/Rank_%28computer_programming%29 for more details. @@ -1389,5 +1381,5 @@ - + From 4019634c89b22c7b2f954b08724904e1f5fd369c Mon Sep 17 00:00:00 2001 From: sanbrock Date: Tue, 31 Jan 2023 22:46:46 +0100 Subject: [PATCH 079/203] fix requirements after merge --- requirements.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/requirements.txt b/requirements.txt index 6d024bda3a..df2e384663 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5,6 +5,7 @@ pyyaml # Documentation building sphinx>=5 sphinx-tabs +sphinx-comments # Testing pytest From 4add0a6286e68f5abac377b7dd07ed1146f6c80e Mon Sep 17 00:00:00 2001 From: sanbrock Date: Tue, 31 Jan 2023 23:51:53 +0100 Subject: [PATCH 080/203] donot perform pdf generation (because of minor errors); accept WARNINGS during html generatin (e.g. duplicate definitions base_class and contributed; NXareprute Line endings) --- .github/workflows/ci.yaml | 1 - Makefile | 2 +- contributed_definitions/NXaperture.nxdl.xml | 5 +++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 1311c93fd0..95547cfea0 100644 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -81,7 +81,6 @@ jobs: - name: Build User Manual run: | - make pdf make html ls -lAFgh build/manual/build/html/index.html ls -lAFgh build/manual/build/latex/nexus.pdf diff --git a/Makefile b/Makefile index ae556d7339..5a52d92072 100644 --- a/Makefile +++ b/Makefile @@ -59,7 +59,7 @@ pdf :: cp $(BUILD_DIR)/manual/build/latex/nexus.pdf $(BUILD_DIR)/manual/source/_static/NeXusManual.pdf html :: - $(SPHINX) -b html -W $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html + $(SPHINX) -b html $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html impatient-guide :: $(SPHINX) -b html -W $(BUILD_DIR)/impatient-guide/ $(BUILD_DIR)/impatient-guide/build/html diff --git a/contributed_definitions/NXaperture.nxdl.xml b/contributed_definitions/NXaperture.nxdl.xml index 6877dc01a6..3e4b8dd42c 100644 --- a/contributed_definitions/NXaperture.nxdl.xml +++ b/contributed_definitions/NXaperture.nxdl.xml @@ -8,8 +8,9 @@ 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 + It is recommended (as of NIAC2014) to use this attribute to help define the path to the + default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. From 5159892367d5288bf563d7842a9e6da37113f243 Mon Sep 17 00:00:00 2001 From: sanbrock Date: Tue, 31 Jan 2023 23:57:15 +0100 Subject: [PATCH 081/203] fix removing the pdf generation --- .github/workflows/ci.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 95547cfea0..229211149d 100644 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -83,7 +83,6 @@ jobs: run: | make html ls -lAFgh build/manual/build/html/index.html - ls -lAFgh build/manual/build/latex/nexus.pdf - name: Build and Commit the User Manual if: ${{ github.event.inputs.deploy && env.python_version == '3.7' }} From 0e12a51e43c8272dfddc68e5aa46ae0aee6f208f Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Wed, 1 Feb 2023 09:49:19 +0100 Subject: [PATCH 082/203] Dispersion application definition (#11) * Adds dispersion nxdls * Adds NXdispersion class * Adds entry to NXdispersive_material * Creates base class for dispersion function parameters * Adds identifier and refines units for dispersions * Fixes typo * Sets literature_references to recommended * Makes dispersion table & function recommeded * Corrects typo in dispersive_material * Renames units to parameter_units * Adds docstrings * Corrects docstring for dispersion_function * Adds docstring for colloquial_name * Adds NXsample to dispersive_material --- contributed_definitions/NXdispersion.nxdl.xml | 16 ++ .../NXdispersion_function.nxdl.xml | 71 +++++++ .../NXdispersion_repeated_parameter.nxdl.xml | 44 ++++ .../NXdispersion_single_parameter.nxdl.xml | 22 ++ .../NXdispersion_table.nxdl.xml | 67 +++++++ .../NXdispersive_material.nxdl.xml | 188 ++++++++++++++++++ 6 files changed, 408 insertions(+) create mode 100644 contributed_definitions/NXdispersion.nxdl.xml create mode 100644 contributed_definitions/NXdispersion_function.nxdl.xml create mode 100644 contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml create mode 100644 contributed_definitions/NXdispersion_single_parameter.nxdl.xml create mode 100644 contributed_definitions/NXdispersion_table.nxdl.xml create mode 100644 contributed_definitions/NXdispersive_material.nxdl.xml diff --git a/contributed_definitions/NXdispersion.nxdl.xml b/contributed_definitions/NXdispersion.nxdl.xml new file mode 100644 index 0000000000..8a4534f760 --- /dev/null +++ b/contributed_definitions/NXdispersion.nxdl.xml @@ -0,0 +1,16 @@ + + + + + A dispersion denoting a sum of different dispersions. + All NXdispersion_table and NXdispersion_function groups will be added together + to form a single dispersion. + + + + The name of the composite model. + + + + + diff --git a/contributed_definitions/NXdispersion_function.nxdl.xml b/contributed_definitions/NXdispersion_function.nxdl.xml new file mode 100644 index 0000000000..15ff513241 --- /dev/null +++ b/contributed_definitions/NXdispersion_function.nxdl.xml @@ -0,0 +1,71 @@ + + + + + + + The number of repetitions for the repeated parameters + + + + + This describes a dispersion function for a material or layer + + + + The name of this dispersion model. + + + + + This should be a python parsable function. + Here we should provide which keywords are available + and a BNF of valid grammar. + + + + + The sign convention being used (n + or - ik) + + + + + + + + + The identifier used to represent energy + in the formula. It is recommended to use `E`. + + + + + The identifier useed to represent wavelength + in the formula. It is recommended to use `lambda`. + + + + + Which representation does the formula evaluate to. + This may either be n for refractive index or eps for dielectric function. + The appropriate token is then to be used inside the formula. + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml new file mode 100644 index 0000000000..de7b01d73e --- /dev/null +++ b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml @@ -0,0 +1,44 @@ + + + + + + + The number of parameter repetitions + + + + + A repeated parameter for a dispersion function + + + + The name of the parameter + + + + + A description of what this parameter represents + + + + + A unit array associating a unit with each parameter. + The first element should be equal to values/@unit. + The values should be SI interpretable standard units + with common prefixes (e.g. mikro, nano etc.) or their + short-hand notation (e.g. nm, mm, kHz etc.). + + + + + + + + The value of the parameter + + + + + + diff --git a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml new file mode 100644 index 0000000000..4ecca1b535 --- /dev/null +++ b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml @@ -0,0 +1,22 @@ + + + + + A single parameter for a dispersion function + + + + The name of the parameter + + + + + A description of what this parameter represents + + + + + The value of the parameter + + + diff --git a/contributed_definitions/NXdispersion_table.nxdl.xml b/contributed_definitions/NXdispersion_table.nxdl.xml new file mode 100644 index 0000000000..90de756669 --- /dev/null +++ b/contributed_definitions/NXdispersion_table.nxdl.xml @@ -0,0 +1,67 @@ + + + + + + The symbols in this schema to denote the dimensions + + + + The number of energy and dielectric function points + + + + + A dispersion table denoting energy, dielectric function tabulated values. + + + + The name of this dispersion model. + + + + + The sign convention being used (n + or - ik) + + + + + + + + + The wavelength array of the tabulated dataset. + This is essentially a duplicate of the energy field. + There should be one or both of them present. + + + + + + + + The energy array of the tabulated dataset. + This is essentially a duplicate of the wavelength field. + There should be one or both of them present. + + + + + + + + The refractive index array of the tabulated dataset. + + + + + + + + The dielectric function of the tabulated dataset. + + + + + + diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml new file mode 100644 index 0000000000..2dd9646ce4 --- /dev/null +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -0,0 +1,188 @@ + + + + + NXdispersion + + + + + An application definition for a dispersive material. + + + + Version number to identify which definition of this application definition was + used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant to the + application definition + + + + + + + + + + + The colloquial name of the material, e.g. graphite or diamond for carbon. + + + + + The phase of the material + + + + + + + + + + + Additional information about the phase if the + material phase is other. + + + + + This field may be used to denote additional phase information, + such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or + if a measurement was done on a thin film or bulk material. + + + + + + Denotes whether the dispersion is calculated or derived from an experiment + + + + + + + + + This fields holds a literature reference for this material. + + + + + This field holds the respective doi for the literature references. + + + + + The dispersion along the optical axis of the material. + This should be the only dispersion available for isotropic materials. + For uniaxial materials this denotes the ordinary axis. + For biaxial materials this denotes the x axis or epsilon 11 tensor element + of the diagionalized permittivity tensor. + + + + The name of this dispersion model. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This should only be filled for biaxial materials. + It denotes the epsilon 22 direction of the diagionalized + permittivity tensor. + + + + The name of this dispersion model. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This should only be filled for uniaxial or biaxial materials. + For uniaxial materials this denotes the extraordinary axis. + For biaxial materials this denotes the epsilon 33 tensor element + of the diagionalized perimittivty tensor. + + + + The name of this dispersion model. + + + + + + + + + + + + + + + + + + + + + + + + + + + + From d4ef6066a36f2fd068d7eb5ac60fffc0d13e10ff Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Wed, 1 Feb 2023 13:18:05 +0100 Subject: [PATCH 083/203] Changes for apm and em within search sprint --- contributed_definitions/NXapm.nxdl.xml | 168 +++++++----- contributed_definitions/NXem.nxdl.xml | 255 ++++++++++++++---- .../NXimage_set_em.nxdl.xml | 86 ++++++ .../NXimage_set_em_adf.nxdl.xml | 25 +- contributed_definitions/NXion.nxdl.xml | 2 +- .../NXspectrum_set_em_eels.nxdl.xml | 49 ++-- .../NXspectrum_set_em_xray.nxdl.xml | 88 +++--- 7 files changed, 480 insertions(+), 193 deletions(-) create mode 100644 contributed_definitions/NXimage_set_em.nxdl.xml diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 2723abeee6..fea453d9df 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -28,8 +28,7 @@ - Number of mass-to-charge-state-ratio intervals mapped on this ion - type. + Number of mass-to-charge-state-ratio intervals of this ion type. @@ -56,7 +55,7 @@ Application definition for atom probe and field ion microscopy experiments. - + An at least as strong as SHA256 hashvalue of the file @@ -87,8 +86,8 @@ Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. @@ -98,7 +97,7 @@ If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant - - this start time field should be used. + - this start_time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping @@ -286,7 +285,8 @@ Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform @@ -311,7 +311,8 @@ - Account name that is associated with the user in social media platforms. + Account name that is associated with the user + in social media platforms. @@ -457,7 +458,7 @@ Consult the work of A. J. Breen and B. Gault and team for further details. - + @@ -489,7 +490,9 @@ Using GEOREF is preferred. - + + + @@ -509,19 +512,6 @@ detected or hit elsewhere in the analysis_chamber. - - - - - - - - - - Average pressure in the analysis chamber. - - - @@ -530,6 +520,8 @@ + + @@ -580,7 +572,8 @@ - Given hardware name/serial number or hash identifier issued by the manufacturer. + Given hardware name/serial number or hash identifier + issued by the manufacturer. @@ -607,12 +600,12 @@ - + - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. If pulse_mode is set to laser or laser_and_voltage (e.g. for LEAP6000-type instruments) having the group/section laser_gun is required and the following of its fields have to be filled: @@ -623,6 +616,8 @@ + + @@ -643,22 +638,26 @@ - + + + - Average pressure in the load_lock_chamber. + Average pressure in the analysis chamber. + + @@ -669,9 +668,26 @@ + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + @@ -679,6 +695,8 @@ + + @@ -686,6 +704,8 @@ + + @@ -892,17 +912,18 @@ - + - Hit multiplicity. + Number of pulses since the start of the atom probe + run/evaporation sequence. - + - Number of pulses since the start of the atom probe run/evaporation sequence. + Hit multiplicity. @@ -936,7 +957,8 @@ - Bitmask which is set to true if the ion is considered and false otherwise. + Bitmask which is set to true if the ion + is considered and false otherwise. @@ -1134,9 +1156,15 @@ - A default three-dimensional histogram of the total number of ions in each bin. + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. - + + + + + Array of counts for each bin. @@ -1146,26 +1174,33 @@ - + - Bin positions along the z axis. + Bin center of mass position along the z axis. + + + + - + - Bin positions along the y axis. + Bin center of mass position along the y axis. + + + + - + - Bin positions along the x axis. + Bin center of mass position along the x axis. + + + + - - - Naive point cloud density map. - - @@ -1196,7 +1231,7 @@ - + How many ion types are distinguished. If no ranging was performed each ion is of the special unknown type. @@ -1252,24 +1287,28 @@ A default histogram aka mass spectrum of the mass-to-charge-state ratio values. - + + + + + Array of counts for each bin. + - + - End of value for each mass-to-charge-state ratio bin. + Right boundary of each mass-to-charge-state ratio value bin. + + + + - - - Mass-to-charge-state histogram. - - @@ -1317,7 +1356,11 @@ - + + + THIS DOCSTRING NEEDS CLARIFICATION. + + @@ -1341,11 +1384,12 @@ - + - + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 4ed1c9204a..f81f4ea447 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1,6 +1,6 @@ - + Characterization and session with one sample in an electron microscope. @@ -279,9 +279,10 @@ research data management systems to show a visual representation of some aspect of the content of the EM session. Default plottables not intended to serve every possible analysis and - visualization demand but be a preview. We made this choice because what constitutes - a useful default plot is often a matter of interpretation, somewhat of personal taste, - and community standards. In effect, default plottables are case- and method-specific. + visualization demand but be a preview. We made this choice because what + constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. Usually a session at a microscope is used to collect multiple signals and images. Examples for possible default plottables could be arbitrarily @@ -304,16 +305,16 @@ field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) * Spectra (X-ray quanta or Auger electron counts) * These data are in virtually all cases a result of some numerical processing. - It makes sense to name these data and processing tasks with a controlled vocabulary, - e.g. SE (secondary electron), BSE (back-scattered electron), Kikuchi, - X-ray, Auger, Cathodolum(inescence) etc. + It makes sense to name these data and processing tasks with a controlled + vocabulary, e.g. SE (secondary electron), BSE (back-scattered electron), + Kikuchi, X-ray, Auger, Cathodolum(inescence) etc. A key question often asked with EM experiments is how the actual (meta)data should be stored (in memory or on disk). To this end the schema, here makes no specific assumptions, not even that all the fields/group of a schema instance have to be stored at all into a single file. Instead, the schema specifies the - relations between metadata, some of the constraints and conditions on how the data - should be formatted, what the data conceptually represent, and which terms + relations between metadata, some of the constraints and conditions on how the + data should be formatted, what the data conceptually represent, and which terms (controlled vocabulary) is practical to store to index specific quantities. In effect, the application definition is a graph which describes how @@ -360,7 +361,7 @@ when the microscope session started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact - duration is not relevant - this start time field should be used. + duration is not relevant - this start_time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and @@ -462,7 +463,8 @@ Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform @@ -541,15 +543,16 @@ was placed into the microscope at the beginning of the session. In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a sub-set - of the entire sample history, i.e. what you would consider are the key steps - and relevant information about the specimen, its material, microstructure, - thermo-chemo-mechanical processing state, and the details of the preparation. + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. Specific details about eventual physically-connected material like embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly discouraged - because it leads to eventually non-machine-actionable + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable data. @@ -560,8 +563,8 @@ Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over for - the analysis. At the point it enters the microscope the session starts. + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. At the point it enters the microscope the session starts. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as @@ -578,11 +581,13 @@ - Use Hill's system for listing elements of the periodic table which are inside or attached - to the surface of the specimen and thus relevant from a scientific point of view. + Use Hill's system for listing elements of the periodic table which are + inside or attached to the surface of the specimen and thus relevant + from a scientific point of view. - The purpose of the field is to offer materials database systems an opportunity to parse - the relevant elements without having to interpret these from the sample history. + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. @@ -596,12 +601,6 @@ surface normal of the specimen is parallel to the optical axis. - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - (Measured) density of the specimen. For multi-layered specimens this @@ -613,6 +612,12 @@ of the specimen. + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + @@ -621,7 +626,7 @@ - + @@ -639,8 +644,8 @@ For example it is not relevant to store in each event's electron_gun group again the details of the gun type and manufacturer but only the high-voltage if for that event the high-voltage was different. If for all events - the high-voltage was the same it is not even necessary to include an electron_gun - section in the event. + the high-voltage was the same it is not even necessary to include an + electron_gun section in the event. Individual sections of specific type should have the following names: @@ -666,35 +671,45 @@ + + + + + + - + - + + + - + If the lens is described at least one of the fields voltage, current, or value should be defined. + + @@ -705,6 +720,8 @@ + + @@ -726,23 +743,30 @@ + + + + - - + + + + + @@ -760,14 +784,18 @@ - + + + - + + + @@ -780,7 +808,7 @@ - + Description of the type of the detector. @@ -801,6 +829,8 @@ + + @@ -929,21 +959,148 @@ instance called ebsd_camera. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - + @@ -956,7 +1113,7 @@ - + @@ -977,10 +1134,10 @@ - - - + + + @@ -1009,7 +1166,7 @@ - + diff --git a/contributed_definitions/NXimage_set_em.nxdl.xml b/contributed_definitions/NXimage_set_em.nxdl.xml new file mode 100644 index 0000000000..6a8e009aac --- /dev/null +++ b/contributed_definitions/NXimage_set_em.nxdl.xml @@ -0,0 +1,86 @@ + + + + + + + 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 with an electron microscope. + + + + + Imaging mode in which the instrument was and with which the images + were captured. + + + + + + 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/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index 0eda1ed99a..b776f4731b 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -1,6 +1,6 @@ - + @@ -77,7 +77,7 @@ Annular dark field image stack. - + Image intensity values. @@ -87,12 +87,7 @@ - - - Image intensities - - - + Image identifier @@ -101,33 +96,33 @@ - Image ID. + Image identifier. - + - Pixel center of mass position y-coordinates. + Pixel coordinate center of mass along y direction. - Label for the y axis. + Coordinate along y direction. - + - Pixel center of mass position x-coordinates. + Pixel coordinate center of mass along x direction. - Label for the x axis. + Coordinate along x direction. diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 713ca4e45c..9e6e3be437 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml index d94dbe0902..4c3f7d3784 100644 --- a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -1,6 +1,6 @@ - + @@ -68,19 +68,22 @@ Collected EELS spectra for all pixels of a rectangular region-of-interest. This representation supports rectangular scan pattern. - + + + Counts for one spectrum per each pixel. + + + + EELS counts + + - - - EELS counts - - - + Pixel center of mass position y-coordinates. @@ -89,11 +92,11 @@ - Label for the y axis. + Coordinate along y direction. - + Pixel center of mass position x-coordinates. @@ -102,11 +105,11 @@ - Label for the x axis. + Coordinate along x direction. - + Pixel center of mass energy loss bins. @@ -115,30 +118,30 @@ - Label for the energy loss axis. + Coordinate along energy loss axis. - Accumulated EELS spectrum over all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. + Accumulated EELS spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. - + Counts for specific energy losses. + + + Counts electrons with an energy loss within binned range. + + - - - Counts electrons with an energy loss within binned range. - - - + Pixel center of mass energy loss bins. @@ -147,7 +150,7 @@ - Energy loss + Coordinate along energy loss axis. diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml index 9ac10fcbe5..08a3c9d458 100644 --- a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -1,6 +1,6 @@ - + @@ -81,71 +81,71 @@ Collected X-ray spectra for all pixels of a rectangular region-of-interest. This representation supports rectangular scan pattern. - + + + + X-ray photon counts + + - - - X-ray photon counts - - - + - Label for the y axis + Coordinate along y direction. - + - Label for the x axis + Coordinate along x direction. - + - X-ray energy + Photon energy. - Accumulated X-ray spectrum over all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. + Accumulated X-ray spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. - + + + + X-ray photon counts + + - - - X-ray photon counts - - - + - X-ray energy + Photon energy @@ -160,10 +160,11 @@ - Program 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. + Program 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. @@ -193,7 +194,7 @@ - + Individual element-specific EDX/EDS/EDXS/SXES mapping @@ -206,10 +207,11 @@ - Program 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. + Program 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. @@ -227,39 +229,39 @@ Human-readable, given name to the image. - + Individual element-specific maps. Individual maps should each be a group and be named according to element_names. - + + + + Accumulated photon counts for observed element. + + - - - Accumulated X-ray photon counts - - - + - Label for the y axis + Coordinate along y direction. - + - Label for the x axis + Coordinate along x direction. From 712b0e6f13f52402feae8d9037da0048facde383 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Wed, 1 Feb 2023 13:49:55 +0100 Subject: [PATCH 084/203] Updates or adds atom_types field (#17) --- contributed_definitions/NXapm.nxdl.xml | 7 +- .../NXellipsometry.nxdl.xml | 101 +++++++++--------- contributed_definitions/NXem.nxdl.xml | 7 +- contributed_definitions/NXmpes.nxdl.xml | 74 +++++++------ 4 files changed, 99 insertions(+), 90 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index fea453d9df..2e636b9d6f 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -387,9 +387,10 @@ - Use Hill's system for listing elements of the periodic table which - are inside or attached to the surface of the specimen, and thus - relevant from a scientific point of view. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 3a4df7cb89..5db2f3bdae 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -1,6 +1,6 @@ - + Variables used throughout the document, e.g. dimensions and important @@ -118,7 +118,7 @@ ii) The identifier enables to link experiments to e.g. proposals. - + A free-text description of the experiment. What is the aim of the experiment? The general procedure. @@ -129,7 +129,7 @@ Start time of the experiment. UTC offset should be specified. - + Commercial or otherwise defined given name to the program that was used to @@ -152,7 +152,7 @@ - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -179,12 +179,12 @@ Email address of the user. - + Author ID defined by https://orcid.org/. - + Official telephone number of the user. @@ -205,12 +205,12 @@ - + Name of the company which build the instrument - + ISO8601 date when the instrument was constructed. UTC offset should be specified. @@ -242,12 +242,12 @@ Were focussing probes (lenses) used? - + Were the recorded data corrected by the window effects of the lenses? - + Specify the angular spread caused by the focussing probes @@ -284,12 +284,12 @@ - + Ellipsometers require regular calibration to adjust the hardware parameters for proper zero values and background light compensation. - + If calibtration status is 'calibration time provided', specify the ISO8601 date when calibration was last performed before this measurement. UTC offset should @@ -391,19 +391,19 @@ - + A free-text field to provide information about the stage. - + The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with the angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). This transformation brings us from the NEXUS coordinates to the stage coordinates. Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) Last, provide the rotations of the sample - + If there is no motorized stage, we should at least qualify where the beam hits the sample and in what direction the sample stands in a free-text description, @@ -412,7 +412,7 @@ - + For environmental measurements, the environment (liquid, vapor, vacuum etc.) is enclosed in a cell or cryostat, which has windows both in the direction of the @@ -435,7 +435,7 @@ - + If you specified 'other' as window material, decsribe here what it is. @@ -471,7 +471,7 @@ - + Recorded data of a reference surface with and without window/medium. @@ -505,12 +505,12 @@ - + If you specified 'other' as detector type, please write down what it is. - + Define how many rotations of the rotating element were taken into account per spectrum. @@ -527,12 +527,12 @@ - + Rotation rate, if the revolution does not change during the measurement. - + Specify maximum and minimum values for the revolution. @@ -540,12 +540,12 @@ - + Minimum signal for which dynamic averaging is performed. - + Value for the minimum intensity chosen. Data points below this value might be skipped by the instrument @@ -569,7 +569,7 @@ - + Diffraction grating, as could be used in a monochromator. If two or more gratings were used, define the angular dispersion and the wavelength range @@ -577,37 +577,37 @@ do not overlap. The dispersion should be defined for the entire wavelength range of the experiment. - + Dispersion of the grating in nm/mm used. - + Minimum wavelength of the grating. - + Maximum wavelength of the grating. - + Spectral resolution of the instrument. - + Define the width of the monochromator slit in the subfield x_gap. - + Was the slit width fixed? - + If slit width was not fixed, define the maximum slit width. @@ -623,11 +623,10 @@ - Use Hill's system for listing elements of the periodic table which are inside or - attached to the surface of the specimen and thus relevant from a scientific - point. The purpose of this field is to allow material databases to parse the - relevant elements without having to interpret the sample history or other - fields. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. @@ -645,7 +644,7 @@ details of the sample and its preparation. - + ISO8601 date with time zone (UTC offset) specified. @@ -703,7 +702,7 @@ - + Specified uncertainties (errors) of the data described by data type. The structure is the same as for the measured data. @@ -716,7 +715,7 @@ - + An array of relative time points if a time series was recorded. @@ -736,7 +735,7 @@ air, UHV, etc.). - + Array of pairs of complex refractive indices of the medium for every measured wavelength. Only necessary if the measurement was performed not in air, or @@ -747,14 +746,14 @@ - + How many measurements were done varying the parameters? This forms an extra dimension beyond incident angle, time points and energy/wavelength (this is the length of the 4th dimension of the data). Defaults to 1. - + Indicates which parameter was changed. Its definition must exist below. The specified variable has to be number_of_runs long, providing the parameters for @@ -774,7 +773,7 @@ - + Was the sample modified using an optical source? Describe in this group the parameters of the optical excitation used. @@ -786,23 +785,23 @@ types, such as pulsed lasers, or lamps, a range may describe the source better. - + Specify the FWHM of the excitation - + How long was the sample excited. - + The integrated energy of light pulse. - + A sensor used to monitor an external condition. The value field contains the measured values. If it is constant within an error for every run then use only @@ -811,17 +810,17 @@ - + What parameters are derived from the above data. - + Light loss due to depolarization as a value in [0-1]. - + A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Mueller matrix elements, such as N, diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index f81f4ea447..aafb0b6ea9 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -581,9 +581,10 @@ - Use Hill's system for listing elements of the periodic table which are - inside or attached to the surface of the specimen and thus relevant - from a scientific point of view. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 1711826f5f..8f01e1446f 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -1,6 +1,6 @@ - + This is the most general application definition for multidimensional photoelectron spectroscopy. @@ -28,13 +28,13 @@ Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. @@ -45,7 +45,7 @@ Email address of the user. - + Author ID defined by https://orcid.org/. @@ -93,19 +93,19 @@ - - + + - + Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. - - + + @@ -120,15 +120,15 @@ - - - + + + The size and position of the field aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. - + The size and position of the contrast aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. @@ -148,13 +148,13 @@ - + Size, position and shape of the entrance slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. - + Size, position and shape of the exit slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. @@ -162,7 +162,7 @@ - + Type of electron amplifier in the first amplification step. @@ -171,7 +171,7 @@ - + Description of the detector type. @@ -184,7 +184,7 @@ - + @@ -198,13 +198,13 @@ - + Manipulator for positioning of the sample. - - - + + + @@ -213,49 +213,49 @@ Describe the appropriate axis calibrations for your experiment using one or more of the following NXcalibrations - + Has an energy calibration been applied? - + This is the calibrated energy axis to be used for data plotting. - + Has an angular calibration been applied? - + This is the calibrated angular axis to be used for data plotting. - + Has an spatial calibration been applied? - + This is the calibrated spatial axis to be used for data plotting. - + Has an momentum calibration been applied? - + This is the momentum axis to be used for data plotting. @@ -264,13 +264,13 @@ - + The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead. - + A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. Ideally, a full report of the previous operations, in @@ -279,7 +279,15 @@ case these are not available, free-text description. - + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). From ab3618eb35cd46834f84ae20a86c9773995a4aad Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 1 Feb 2023 14:57:37 +0100 Subject: [PATCH 085/203] Updates atom_types in NXmpes --- contributed_definitions/NXmpes.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 8f01e1446f..e17a9097cc 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -279,7 +279,7 @@ case these are not available, free-text description. - + List of comma-separated elements from the periodic table that are contained in the sample. From 204c87664ec1a7eeccec5fe4c09f70b5b49d7e87 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Tue, 7 Feb 2023 16:03:18 +0100 Subject: [PATCH 086/203] Copying yaml files from data-modeling main branch. --- base_classes/nyaml/NXaperture.yml | 49 + base_classes/nyaml/NXbeam.yml | 206 +++ base_classes/nyaml/NXdetector.yml | 497 +++++++ base_classes/nyaml/NXentry.yml | 162 +++ base_classes/nyaml/NXinstrument.yml | 65 + base_classes/nyaml/NXprocess.yml | 37 + base_classes/nyaml/NXsample.yml | 315 +++++ base_classes/nyaml/NXsource.yml | 143 ++ .../nyaml/NXaperture_em.yaml | 27 + contributed_definitions/nyaml/NXapm.yaml | 1243 +++++++++++++++++ .../nyaml/NXapm_input_ranging.yaml | 27 + .../nyaml/NXapm_input_reconstruction.yaml | 27 + .../NXapm_paraprobe_config_clusterer.yaml | 246 ++++ .../NXapm_paraprobe_config_distancer.yaml | 179 +++ .../NXapm_paraprobe_config_intersector.yaml | 370 +++++ .../NXapm_paraprobe_config_nanochem.yaml | 872 ++++++++++++ .../nyaml/NXapm_paraprobe_config_ranger.yaml | 221 +++ .../NXapm_paraprobe_config_spatstat.yaml | 220 +++ .../NXapm_paraprobe_config_surfacer.yaml | 175 +++ .../NXapm_paraprobe_config_tessellator.yaml | 180 +++ .../NXapm_paraprobe_config_transcoder.yaml | 62 + .../nyaml/NXapm_paraprobe_results_ranger.yaml | 282 ++++ .../NXapm_paraprobe_results_transcoder.yaml | 395 ++++++ contributed_definitions/nyaml/NXatom_set.yaml | 12 + .../nyaml/NXcalibration.yml | 51 + .../nyaml/NXcg_alpha_shape.yaml | 83 ++ .../nyaml/NXcg_cylinder_set.yaml | 112 ++ .../nyaml/NXcg_ellipsoid_set.yaml | 87 ++ .../nyaml/NXcg_face_list_data_structure.yaml | 169 +++ .../nyaml/NXcg_geodesic_mesh.yaml | 28 + contributed_definitions/nyaml/NXcg_grid.yaml | 109 ++ .../nyaml/NXcg_half_edge_data_structure.yaml | 115 ++ .../nyaml/NXcg_hexahedron_set.yaml | 178 +++ .../nyaml/NXcg_isocontour.yaml | 30 + .../nyaml/NXcg_marching_cubes.yaml | 39 + .../nyaml/NXcg_parallelogram_set.yaml | 132 ++ .../nyaml/NXcg_point_set.yaml | 55 + .../nyaml/NXcg_polygon_set.yaml | 171 +++ .../nyaml/NXcg_polyhedron_set.yaml | 131 ++ .../nyaml/NXcg_polyline_set.yaml | 131 ++ .../nyaml/NXcg_roi_set.yaml | 13 + .../nyaml/NXcg_sphere_set.yaml | 76 + .../nyaml/NXcg_tetrahedron_set.yaml | 122 ++ .../nyaml/NXcg_triangle_set.yaml | 79 ++ .../nyaml/NXcg_triangulated_surface_mesh.yaml | 27 + .../nyaml/NXcg_unit_normal_set.yaml | 33 + contributed_definitions/nyaml/NXchamber.yaml | 11 + .../nyaml/NXclustering.yaml | 67 + .../nyaml/NXcollectioncolumn.yml | 40 + .../nyaml/NXcoordinate_system_set.yaml | 116 ++ .../nyaml/NXcorrector_cs.yaml | 33 + .../nyaml/NXcs_computer.yaml | 32 + contributed_definitions/nyaml/NXcs_cpu.yaml | 9 + .../nyaml/NXcs_filter_boolean_mask.yaml | 59 + contributed_definitions/nyaml/NXcs_gpu.yaml | 10 + .../nyaml/NXcs_io_obj.yaml | 17 + .../nyaml/NXcs_io_sys.yaml | 7 + .../nyaml/NXcs_mm_sys.yaml | 9 + contributed_definitions/nyaml/NXcs_prng.yaml | 44 + .../nyaml/NXcs_profiling.yaml | 103 ++ .../nyaml/NXcs_profiling_event.yaml | 52 + contributed_definitions/nyaml/NXdeflector.yml | 27 + .../nyaml/NXdelocalization.yaml | 83 ++ .../nyaml/NXdistortion.yml | 54 + .../nyaml/NXebeam_column.yaml | 55 + .../nyaml/NXelectronanalyser.yml | 74 + .../nyaml/NXellipsometry.yaml | 735 ++++++++++ contributed_definitions/nyaml/NXem.yaml | 1131 +++++++++++++++ .../nyaml/NXenergydispersion.yml | 37 + .../nyaml/NXevent_data_em.yaml | 210 +++ .../nyaml/NXevent_data_em_set.yaml | 8 + .../nyaml/NXfabrication.yaml | 20 + .../nyaml/NXgraph_edge_set.yaml | 69 + .../nyaml/NXgraph_node_set.yaml | 48 + .../nyaml/NXgraph_root.yaml | 9 + .../nyaml/NXibeam_column.yaml | 93 ++ .../nyaml/NXimage_set_em_adf.yaml | 85 ++ contributed_definitions/nyaml/NXion.yaml | 87 ++ contributed_definitions/nyaml/NXiv_temp.yaml | 40 + contributed_definitions/nyaml/NXlens_em.yaml | 50 + contributed_definitions/nyaml/NXlens_em.yml | 36 + .../nyaml/NXliquid_jet.yml | 47 + .../nyaml/NXmanipulator.yml | 41 + .../nyaml/NXmatch_filter.yaml | 28 + contributed_definitions/nyaml/NXmpes.yml | 227 +++ .../nyaml/NXmpes_liquid.yml | 267 ++++ .../nyaml/NXms_crystal_set.yaml | 129 ++ .../nyaml/NXms_dislocation_set.yaml | 118 ++ .../nyaml/NXms_interface_set.yaml | 106 ++ .../nyaml/NXms_snapshot.yaml | 17 + .../nyaml/NXms_snapshot_set.yaml | 28 + .../nyaml/NXoptical_system_em.yaml | 50 + .../nyaml/NXorientation_set.yaml | 84 ++ contributed_definitions/nyaml/NXpeak.yaml | 43 + contributed_definitions/nyaml/NXpid.yaml | 46 + .../nyaml/NXpulser_apm.yaml | 80 ++ contributed_definitions/nyaml/NXpump.yaml | 11 + .../nyaml/NXreflectron.yaml | 21 + .../nyaml/NXregistration.yml | 15 + .../nyaml/NXscanbox_em.yaml | 29 + .../nyaml/NXsensor_scan.yaml | 131 ++ .../nyaml/NXslip_system_set.yaml | 38 + .../nyaml/NXspatial_filter.yaml | 39 + .../nyaml/NXspectrum_set_em_eels.yaml | 104 ++ .../nyaml/NXspectrum_set_em_xray.yaml | 194 +++ .../nyaml/NXspindispersion.yml | 38 + .../nyaml/NXstage_lab.yaml | 131 ++ .../nyaml/NXsubsampling_filter.yaml | 20 + .../nyaml/NXtransmission.yml | 211 +++ 109 files changed, 13836 insertions(+) create mode 100644 base_classes/nyaml/NXaperture.yml create mode 100644 base_classes/nyaml/NXbeam.yml create mode 100644 base_classes/nyaml/NXdetector.yml create mode 100644 base_classes/nyaml/NXentry.yml create mode 100644 base_classes/nyaml/NXinstrument.yml create mode 100644 base_classes/nyaml/NXprocess.yml create mode 100644 base_classes/nyaml/NXsample.yml create mode 100644 base_classes/nyaml/NXsource.yml create mode 100644 contributed_definitions/nyaml/NXaperture_em.yaml create mode 100644 contributed_definitions/nyaml/NXapm.yaml create mode 100644 contributed_definitions/nyaml/NXapm_input_ranging.yaml create mode 100644 contributed_definitions/nyaml/NXapm_input_reconstruction.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml create mode 100644 contributed_definitions/nyaml/NXatom_set.yaml create mode 100644 contributed_definitions/nyaml/NXcalibration.yml create mode 100644 contributed_definitions/nyaml/NXcg_alpha_shape.yaml create mode 100644 contributed_definitions/nyaml/NXcg_cylinder_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml create mode 100644 contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml create mode 100644 contributed_definitions/nyaml/NXcg_grid.yaml create mode 100644 contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml create mode 100644 contributed_definitions/nyaml/NXcg_hexahedron_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_isocontour.yaml create mode 100644 contributed_definitions/nyaml/NXcg_marching_cubes.yaml create mode 100644 contributed_definitions/nyaml/NXcg_parallelogram_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_point_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_polygon_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_polyhedron_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_polyline_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_roi_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_sphere_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_triangle_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml create mode 100644 contributed_definitions/nyaml/NXcg_unit_normal_set.yaml create mode 100644 contributed_definitions/nyaml/NXchamber.yaml create mode 100644 contributed_definitions/nyaml/NXclustering.yaml create mode 100644 contributed_definitions/nyaml/NXcollectioncolumn.yml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system_set.yaml create mode 100644 contributed_definitions/nyaml/NXcorrector_cs.yaml create mode 100644 contributed_definitions/nyaml/NXcs_computer.yaml create mode 100644 contributed_definitions/nyaml/NXcs_cpu.yaml create mode 100644 contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml create mode 100644 contributed_definitions/nyaml/NXcs_gpu.yaml create mode 100644 contributed_definitions/nyaml/NXcs_io_obj.yaml create mode 100644 contributed_definitions/nyaml/NXcs_io_sys.yaml create mode 100644 contributed_definitions/nyaml/NXcs_mm_sys.yaml create mode 100644 contributed_definitions/nyaml/NXcs_prng.yaml create mode 100644 contributed_definitions/nyaml/NXcs_profiling.yaml create mode 100644 contributed_definitions/nyaml/NXcs_profiling_event.yaml create mode 100644 contributed_definitions/nyaml/NXdeflector.yml create mode 100644 contributed_definitions/nyaml/NXdelocalization.yaml create mode 100644 contributed_definitions/nyaml/NXdistortion.yml create mode 100644 contributed_definitions/nyaml/NXebeam_column.yaml create mode 100644 contributed_definitions/nyaml/NXelectronanalyser.yml create mode 100644 contributed_definitions/nyaml/NXellipsometry.yaml create mode 100644 contributed_definitions/nyaml/NXem.yaml create mode 100644 contributed_definitions/nyaml/NXenergydispersion.yml create mode 100644 contributed_definitions/nyaml/NXevent_data_em.yaml create mode 100644 contributed_definitions/nyaml/NXevent_data_em_set.yaml create mode 100644 contributed_definitions/nyaml/NXfabrication.yaml create mode 100644 contributed_definitions/nyaml/NXgraph_edge_set.yaml create mode 100644 contributed_definitions/nyaml/NXgraph_node_set.yaml create mode 100644 contributed_definitions/nyaml/NXgraph_root.yaml create mode 100644 contributed_definitions/nyaml/NXibeam_column.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_adf.yaml create mode 100644 contributed_definitions/nyaml/NXion.yaml create mode 100644 contributed_definitions/nyaml/NXiv_temp.yaml create mode 100644 contributed_definitions/nyaml/NXlens_em.yaml create mode 100644 contributed_definitions/nyaml/NXlens_em.yml create mode 100644 contributed_definitions/nyaml/NXliquid_jet.yml create mode 100644 contributed_definitions/nyaml/NXmanipulator.yml create mode 100644 contributed_definitions/nyaml/NXmatch_filter.yaml create mode 100644 contributed_definitions/nyaml/NXmpes.yml create mode 100644 contributed_definitions/nyaml/NXmpes_liquid.yml create mode 100644 contributed_definitions/nyaml/NXms_crystal_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_dislocation_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_interface_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_snapshot.yaml create mode 100644 contributed_definitions/nyaml/NXms_snapshot_set.yaml create mode 100644 contributed_definitions/nyaml/NXoptical_system_em.yaml create mode 100644 contributed_definitions/nyaml/NXorientation_set.yaml create mode 100644 contributed_definitions/nyaml/NXpeak.yaml create mode 100644 contributed_definitions/nyaml/NXpid.yaml create mode 100644 contributed_definitions/nyaml/NXpulser_apm.yaml create mode 100644 contributed_definitions/nyaml/NXpump.yaml create mode 100644 contributed_definitions/nyaml/NXreflectron.yaml create mode 100644 contributed_definitions/nyaml/NXregistration.yml create mode 100644 contributed_definitions/nyaml/NXscanbox_em.yaml create mode 100644 contributed_definitions/nyaml/NXsensor_scan.yaml create mode 100644 contributed_definitions/nyaml/NXslip_system_set.yaml create mode 100644 contributed_definitions/nyaml/NXspatial_filter.yaml create mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml create mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml create mode 100644 contributed_definitions/nyaml/NXspindispersion.yml create mode 100644 contributed_definitions/nyaml/NXstage_lab.yaml create mode 100644 contributed_definitions/nyaml/NXsubsampling_filter.yaml create mode 100644 contributed_definitions/nyaml/NXtransmission.yml diff --git a/base_classes/nyaml/NXaperture.yml b/base_classes/nyaml/NXaperture.yml new file mode 100644 index 0000000000..26fae686a4 --- /dev/null +++ b/base_classes/nyaml/NXaperture.yml @@ -0,0 +1,49 @@ +category: base +doc: "A beamline aperture" +(NXaperture): + \@default(NX_CHAR): + doc: | + 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. + material(NX_CHAR): + doc: "Absorbing material of the aperture." + description(NX_CHAR): + doc: "Description of the aperture." + shape: + doc: "Shape of the aperture." + enumeration: + [ + "straight slit", + "curved slit", + "pinhole", + "circle", + "square", + "hexagon", + "octagon", + "bladed", + "open", + "grid", + ] + size(NX_NUMBER): + doc: + "The relevant dimension for the aperture, i.e. slit width, pinhole and iris + diameter" + unit: NX_LENGTH + depends_on(NX_CHAR): + doc: "Specifies the position of the aperture by pointing to the last transformation in the transformation chain in the NXtransformations group." + (NXtransformations): + doc: "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 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." + (NXpositioner): + doc: "Stores the raw positions of aperture motors." + (NXgeometry): + doc: "Location and shape of the aperture." + BLADE_GEOMETRY(NXgeometry): + doc: "Location and shape of each blade." + (NXnote): + doc: "Describes any additional information." diff --git a/base_classes/nyaml/NXbeam.yml b/base_classes/nyaml/NXbeam.yml new file mode 100644 index 0000000000..88e5bc72d5 --- /dev/null +++ b/base_classes/nyaml/NXbeam.yml @@ -0,0 +1,206 @@ +doc: | + Properties of the neutron or X-ray beam at a given location. + + It will be referenced by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. + Note that variables such as the incident energy could be scalar values or arrays. + This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, + time distribution etc. at each beamline component. + Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. +symbols: + doc: "The symbols used in the schema to specify e.g. dimensions of arrays" + nx: "Number of pixels of the horizontal axis (e.g. delay) of a FROG trace" + ny: "Number of pixels of the vertical axis (e.g. frequency) of a FROG trace" +category: base +(NXbeam): + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "Distance from sample" + incident_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + In the case of a monchromatic beam this is the scalar energy. + Several other use cases are permitted, depending on the presence of other incident_energy_X fields. + + * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + Here, incident_energy_weights and incident_energy_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_energy_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + dimensions: + rank: 1 + dim: [[1, i]] + incident_energy_spread(NX_NUMBER): + unit: NX_ENERGY + doc: + "The energy spread FWHM for the corresponding energy(ies) in incident_energy. + In the case of shot-to-shot variation in the energy spread, + this is a 2D array of dimension nP by m (slow to fast) of the spreads of the corresponding wavelength in incident_wavelength." + incident_energy_weights(NX_NUMBER): + unit: NX_ENERGY + doc: + "In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding energies in incident_energy. + In the case of a polychromatic beam that varies shot-to-shot, + this is a 2D array of dimensions np by m (slow to fast) of the relative weights of the corresponding energies in incident_energy." + final_energy(NX_FLOAT): + unit: NX_ENERGY + doc: "Energy on leaving beamline component" + dimensions: + rank: 1 + dim: [[1, i]] + energy_transfer(NX_FLOAT): + unit: NX_ENERGY + doc: "Energy change caused by beamline component" + dimensions: + rank: 1 + dim: [[1, i]] + incident_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + In the case of a monchromatic beam this is the scalar wavelength. + Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. + + * In the case of a polychromatic beam this is an array of length m of wavelengths, + with the relative weights in incident_wavelength_weights. + * In the case of a monochromatic beam that varies shot-to-shot, + this is an array of wavelengths, one for each recorded shot. + Here, incident_wavelength_weights and incident_wavelength_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, + single-value wavelength value is available along with the original spectrum from which it was calibrated. + dimensions: + rank: 1 + dim: [[1, i]] + incident_wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + doc: "Wavelength spread FWHM on entering component" + dimensions: + rank: 1 + dim: [[1, i]] + incident_beam_divergence(NX_FLOAT): + unit: NX_ANGLE + doc: "Divergence of beam entering this component" + dimensions: + rank: 2 + dim: [[1, 2], [2, j]] + extent(NX_FLOAT): + unit: NX_LENGTH + doc: "Size of the beam entering this component" + dimensions: + rank: 2 + dim: [[1, 2], [2, j]] + final_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: "Wavelength on leaving beamline component" + dimensions: + rank: 1 + dim: [[1, i]] + incident_polarization(NX_FLOAT): + unit: NX_ANY + doc: "Incident polarization as a Stokes vector" + dimensions: + rank: 1 + dim: [[1, 4]] + \@units: + doc: | + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. + Correct parsing can still be implemented by using this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: 'farad' for capacitance). + * A string describing the units according to unidata unit operation notation, + if the unit is a complex combination of named units and does not have a name. + + Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. + Here: SI units are 'V2/m2'. + final_polarization(NX_FLOAT): + unit: NX_ANY + doc: "Polarization as Stokes vector on leaving beamline component" + dimensions: + rank: 1 + dim: [[1, 4]] + \@units: + doc: "Here: SI units are 'V2/m2'." + final_wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + doc: "Wavelength spread FWHM of beam leaving this component" + dimensions: + rank: 1 + dim: [[1, i]] + final_beam_divergence(NX_FLOAT): + unit: NX_ANGLE + doc: "Divergence FWHM of beam leaving this component" + dimensions: + rank: 2 + dim: [[1, 2], [2, j]] + flux(NX_FLOAT): + unit: NX_FLUX + doc: "flux incident on beam plane area" + dimensions: + rank: 1 + dim: [[1, i]] + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: "Energy of a single pulse at the diagnostic point" + average_power(NX_FLOAT): + unit: NX_POWER + doc: "Average power at the diagnostic point" + fluence(NX_FLOAT): + unit: NX_ANY + doc: "Incident fluence at the diagnostic point" + \@units: + doc: "Here: SI units are + ''J/m2'', customary ''mJ/cm2''." + pulse_duration(NX_FLOAT): + unit: NX_TIME + doc: "FWHM duration of the pulses at the diagnostic point" + frog_trace(NX_FLOAT): + doc: "FROG trace of the pulse." + dimensions: + rank: 2 + dim: [[1, nx], [1, ny]] + frog_delays(NX_FLOAT): + unit: NX_TIME + doc: "Horizontal axis of a FROG trace, i.e. delay." + dimensions: + rank: 1 + dim: [[1, nx]] + frog_frequencies(NX_FLOAT): + unit: NX_FREQUENCY + doc: "Vertical axis of a FROG trace, i.e. frequency." + dimensions: + rank: 1 + dim: [[1, ny]] + chirp_type(NX_CHAR): + doc: "The type of chirp implemented" + chirp_GDD(NX_FLOAT): + unit: NX_TIME + doc: "Group delay dispersion of the pulse for linear chirp" + (NXdata): + doc: + "Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly + useful for simulations which need to store plottable information at each beamline + component." + \@default: + doc: | + .. 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/nyaml/NXdetector.yml b/base_classes/nyaml/NXdetector.yml new file mode 100644 index 0000000000..1826f95858 --- /dev/null +++ b/base_classes/nyaml/NXdetector.yml @@ -0,0 +1,497 @@ +doc: "A detector, detector bank, or multidetector." +symbols: + doc: "These symbols will be used below to coordinate datasets with the same shape." + np: "number of scan points (only present in scanning measurements)" + i: "number of detector pixels in the first (slowest) direction" + j: "number of detector pixels in the second (faster) direction" + k: "number of detector pixels in the third (if necessary, fastest) direction" + tof: "number of bins in the time-of-flight histogram" +category: base +(NXdetector): + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: "Total time of flight" + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@axis: + enumeration: [3] + \@primary: + enumeration: [1] + \@long_name: + doc: "Total time of flight" + raw_time_of_flight(NX_INT): + unit: NX_PULSES + doc: "In DAQ clock pulses" + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@frequency: + doc: "Clock frequency in Hz" + detector_number(NX_INT): + doc: "Identifier for detector (pixels) + Can be multidimensional, if needed" + data(NX_NUMBER): + unit: NX_ANY + doc: "Data values from the detector." + dimensions: + rank: 4 + dim: [[1, np], [2, i], [3, j], [4, tof]] + \@long_name: + doc: "Title of measurement" + \@check_sum: + doc: "Integral of data as check of data integrity" + data_errors(NX_NUMBER): + unit: NX_ANY + doc: "The best estimate of the uncertainty in the data value. Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated." + dimensions: + rank: 4 + dim: [[1, np], [2, i], [3, j], [4, tof]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: "Offset from the detector center in x-direction. + Can be multidimensional when needed." + \@axis: + enumeration: [1] + \@primary: + enumeration: [1] + \@long_name: + doc: "x-axis offset from detector center" + y_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: "Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel." + \@axis: + enumeration: [2] + \@primary: + enumeration: [1] + \@long_name: + doc: "y-axis offset from detector center" + z_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: "Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel." + \@axis: + enumeration: [3] + \@primary: + enumeration: [1] + \@long_name: + doc: "y-axis offset from detector center" + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel." + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel." + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel." + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + description: + doc: "name/manufacturer/model/etc. information" + serial_number: + doc: "Serial number for the detector" + local_name: + doc: "Local name for the detector" + (NXgeometry): + doc: "Position and orientation of detector" + solid_angle(NX_FLOAT): + unit: NX_SOLID_ANGLE + doc: "Solid angle subtended by the detector at the sample" + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: "Size of each detector pixel. If it is scalar all pixels are the same size." + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: "Size of each detector pixel. If it is scalar all pixels are the same size" + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + dead_time(NX_FLOAT): + unit: NX_TIME + doc: "Detector dead time" + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: "Detector gas pressure" + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + detection_gas_path(NX_FLOAT): + unit: NX_LENGTH + doc: "maximum drift space dimension" + crate(NX_INT): + doc: "Crate number of detector" + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: "Equivalent local term" + slot(NX_INT): + doc: "Slot number of detector" + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: "Equivalent local term" + input(NX_INT): + doc: "Input number of detector" + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: "Equivalent local term" + type: + doc: "Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ..." + efficiency(NXdata): + doc: "Spectral efficiency of detector with respect to e.g. wavelength" + \@signal: + enumeration: [efficiency] + \@axes: + enumeration: [., . ., . . ., . . . ., wavelength] + \@wavelength_indices: + enumeration: [0] + efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: "efficiency of the detector" + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + This field can be two things: + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + real_time(NX_NUMBER): + unit: NX_TIME + doc: | + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + start_time(NX_FLOAT): + unit: NX_TIME + doc: "Start time for each frame, with the ``start`` attribute as absolute reference" + dimensions: + rank: 1 + dim: [[1, np]] + \@start: + stop_time(NX_FLOAT): + unit: NX_TIME + doc: "stop time for each frame, with the ``start`` attribute as absolute reference" + dimensions: + rank: 1 + dim: [[1, np]] + \@start: + calibration_date(NX_DATE_TIME): + doc: "date of last calibration (geometry and/or efficiency) measurements" + calibration_method(NXnote): + doc: "summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations" + layout: + doc: "How the detector is represented" + enumeration: [point, linear, area] + count_time(NX_NUMBER): + unit: NX_TIME + doc: "Elapsed actual counting time" + dimensions: + rank: 1 + dim: [[1, np]] + data_file(NXnote): + (NXcollection): + doc: "Use this group to provide other data related to this NXdetector group." + sequence_number(NX_INT): + doc: "In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image." + dimensions: + rank: 1 + dim: [[1, nBrightFrames]] + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: "This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute." + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: "This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute." + frame_start_number(NX_INT): + doc: "This is the start number of the first frame of a scan. In PX one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements." + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: "The diameter of a cylindrical detector" + acquisition_mode(NX_CHAR): + doc: "The acquisition mode of the detector." + enumeration: [gated, triggered, summed, event, histogrammed, decimated] + angular_calibration_applied(NX_BOOLEAN): + doc: "True when the angular calibration has been applied in the + electronics, false otherwise." + angular_calibration(NX_FLOAT): + doc: "Angular calibration data." + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_applied(NX_BOOLEAN): + doc: "True when the flat field correction has been applied in the + electronics, false otherwise." + flatfield(NX_FLOAT): + doc: "Flat field correction data." + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_errors(NX_FLOAT): + doc: "Errors of the flat field correction data. + The form flatfield_error is deprecated." + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + pixel_mask_applied(NX_BOOLEAN): + doc: "True when the pixel mask correction has been applied in the + electronics, false otherwise." + pixel_mask(NX_INT): + doc: | + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + countrate_correction_applied(NX_BOOLEAN): + doc: "True when a count-rate correction has already been applied in the + electronics, false otherwise." + bit_depth_readout(NX_INT): + doc: "How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ..." + detector_readout_time(NX_FLOAT): + unit: NX_TIME + doc: "Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments." + trigger_delay_time(NX_FLOAT): + unit: NX_TIME + doc: "Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments." + trigger_delay_time_set(NX_FLOAT): + unit: NX_TIME + doc: "User-specified trigger delay." + trigger_internal_delay_time(NX_FLOAT): + unit: NX_TIME + doc: "Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay." + trigger_dead_time(NX_FLOAT): + unit: NX_TIME + doc: "Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments." + frame_time(NX_FLOAT): + unit: NX_TIME + doc: "This is time for each frame. This is exposure_time + readout time." + dimensions: + rank: 1 + dim: [[1, NP]] + gain_setting(NX_CHAR): + doc: "The gain setting of the detector. This influences background etc." + enumeration: [high, standard, fast, auto] + saturation_value(NX_INT): + doc: "The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value." + underload_value(NX_INT): + doc: "The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value." + number_of_cycles(NX_INT): + doc: "CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image." + sensor_material(NX_CHAR): + doc: "At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material." + sensor_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: "At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material." + threshold_energy(NX_FLOAT): + unit: NX_ENERGY + doc: "Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this." + (NXdetector_module): + doc: "For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + Use one or more instances of the NXdetector_module + group to declare regions of interest or some other + subdivision of a detector." + (NXoff_geometry): + doc: "Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape." + (NXcylindrical_geometry): + doc: "Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders." + (NXoff_geometry): + doc: "Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape." + (NXcylindrical_geometry): + doc: "Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders." + \@default: + doc: | + .. 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. + amplifier_type(NX_CHAR): + doc: "Type of electron amplifier, MCP, channeltron, etc." + detector_type(NX_CHAR): + doc: "Description of the detector type, DLD, Phosphor+CCD, CMOS." + detector_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: "Voltage applied to detector." + amplifier_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: "Voltage applied to the amplifier." + amplifier_bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: "The low voltage of the amplifier migh not be the ground." + sensor_size(NX_FLOAT): + unit: NX_LENGTH + doc: "Size of each imaging sensor chip on the detector." + sensor_count(NX_INT): + unit: NX_UNITLESS + doc: "Number of imaging sensor chips on the detector." + sensor_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: "Physical size of the pixels of the imaging chip on the detector." + sensor_pixels(NX_INT): + unit: NX_UNITLESS + doc: "Number of raw active elements in each dimension. Important for swept scans." + (NXdata): + doc: "raw data output from the detector" diff --git a/base_classes/nyaml/NXentry.yml b/base_classes/nyaml/NXentry.yml new file mode 100644 index 0000000000..b2655dfe35 --- /dev/null +++ b/base_classes/nyaml/NXentry.yml @@ -0,0 +1,162 @@ +doc: | + (**required**) :ref:`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. +category: base +(NXentry): + \@default: + doc: | + .. index:: plotting + + Declares which :ref:`NXdata` (or :ref:`NXsubentry`) group + contains the data to be shown by default. + It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. + The value is the name of the default :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. + + .. [#] NIAC2014 discussion summary: + https://www.nexusformat.org/2014_How_to_find_default_data.html + (NXdata): + doc: | + The data group + + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 + \@IDF_Version: + doc: "ISIS Muon IDF_Version" + title: + doc: "Extended title for entry" + experiment_identifier: + doc: "Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals" + experiment_description: + doc: "Brief summary of the experiment, including key objectives." + experiment_documentation(NXnote): + doc: "Description of the full experiment (document in pdf, latex, ...)" + collection_identifier: + doc: "User or Data Acquisition defined group of NeXus files or NXentry" + collection_description: + doc: "Brief summary of the collection, including grouping criteria." + entry_identifier: + doc: "Unique identifier for the measurement, defined by the facility." + entry_identifier_uuid: + doc: "UUID identifier for the measurement." + \@version: + doc: "Version of UUID used" + features: + doc: "Reserved for future use by NIAC. + See https://github.com/nexusformat/definitions/issues/382" + definition: + doc: | + (alternate use: see same field in :ref:`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms. + This field is provided so that :ref:`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + \@version: + doc: "NXDL version number" + \@URL: + doc: "URL of NXDL file" + definition_local: + doc: "Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry." + \@version: + doc: "NXDL version number" + \@URL: + doc: "URL of NXDL file" + start_time(NX_DATE_TIME): + doc: "Starting time of measurement" + end_time(NX_DATE_TIME): + doc: "Ending time of measurement" + duration(NX_INT): + unit: NX_TIME + doc: "Duration of measurement" + collection_time(NX_FLOAT): + unit: NX_TIME + doc: + "Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range" + run_cycle: + doc: "Such as '2007-3'. Some user facilities organize their beam time into run cycles." + program_name: + doc: "Name of program used to generate this file" + \@version: + doc: "Program version number" + \@configuration: + doc: "configuration of the program" + revision: + doc: + "Revision id of the file due to re-calibration, reprocessing, new analysis, + new instrument definition format, ..." + \@comment: + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: + "This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link." + experiment_location(NX_CHAR): + doc: "City and country where the experiment took place" + experiment_start_date(NX_DATE_TIME): + doc: "Start time of experimental run that includes the current measurement, + for example a beam time." + experiment_end_date(NX_DATE_TIME): + doc: "End time of experimental run that includes the current measurement, + for example a beam time." + experiment_institution(NX_CHAR): + doc: "Name of the institution hosting the facility" + experiment_facility(NX_CHAR): + doc: "Name of the experimental facility" + experiment_laboratory(NX_CHAR): + doc: "Name of the laboratory or beamline" + notes(NXnote): + doc: "Notes describing entry" + thumbnail(NXnote): + doc: + "A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata." + \@type: + doc: "The mime type should be an ``image/*``" + enumeration: [image/*] + (NXuser): + (NXsample): + (NXinstrument): + (NXcollection): + (NXmonitor): + (NXparameters): + (NXprocess): + (NXsubentry): diff --git a/base_classes/nyaml/NXinstrument.yml b/base_classes/nyaml/NXinstrument.yml new file mode 100644 index 0000000000..37bd792161 --- /dev/null +++ b/base_classes/nyaml/NXinstrument.yml @@ -0,0 +1,65 @@ +doc: "Collection of the components of the instrument or beamline. + Template of instrument descriptions comprising various beamline components. + Each component will also be a NeXus group defined by its distance from the + sample. Negative distances represent beamline components that are before the + sample while positive distances represent components that are after the sample. + This device allows the unique identification of beamline components in a way + that is valid for both reactor and pulsed instrumentation." +category: base +(NXinstrument): + name: + doc: "Name of instrument" + \@short_name: + doc: "short name for instrument, perhaps the acronym" + energy_resolution(NX_FLOAT): + doc: "Energy resolution of the experiment (FWHM or gaussian broadening)" + unit: NX_ENERGY + momentum_resolution(NX_FLOAT): + doc: "Momentum resolution of the experiment (FWHM)" + unit: NX_WAVENUMBER + angular_resolution(NX_FLOAT): + doc: "Angular resolution of the experiment (FWHM)" + unit: NX_ANGLE + spatial_resolution(NX_FLOAT): + doc: "Spatial resolution of the experiment (Airy disk radius)" + unit: NX_LENGTH + temporal_resolution(NX_FLOAT): + doc: "Temporal resolution of the experiment (FWHM)" + unit: NX_TIME + (NXaperture): + (NXattenuator): + (NXbeam): + (NXbeam_stop): + (NXbending_magnet): + (NXcollimator): + (NXcollection): + (NXcapillary): + (NXcrystal): + (NXdetector): + (NXdetector_group): + (NXdisk_chopper): + (NXevent_data): + (NXfermi_chopper): + (NXfilter): + (NXflipper): + (NXguide): + (NXinsertion_device): + (NXmirror): + (NXmoderator): + (NXmonochromator): + (NXpolarizer): + (NXpositioner): + (NXsource): + DIFFRACTOMETER(NXtransformations): + (NXvelocity_selector): + (NXxraylens): + \@default: + doc: ".. 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/nyaml/NXprocess.yml b/base_classes/nyaml/NXprocess.yml new file mode 100644 index 0000000000..39daa5fbf8 --- /dev/null +++ b/base_classes/nyaml/NXprocess.yml @@ -0,0 +1,37 @@ +doc: "Document an event of data processing, reconstruction, or analysis for this data." +category: base +(NXprocess): + program(NX_CHAR): + doc: "Name of the program used" + sequence_index(NX_POSINT): + doc: "Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1." + version(NX_CHAR): + doc: "Version of the program used" + date(NX_DATE_TIME): + doc: "Date and time of processing." + (NXregistration): + doc: "Describes the operations of image registration" + (NXdistortion): + doc: "Describes the operations of image distortion correction" + (NXcalibration): + doc: "Describes the operations of calibration procedures, + e.g. axis calibrations." + (NXnote): + doc: "Notes contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + The name will be numbered to allow for ordering of steps." + \@default: + doc: | + .. 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/nyaml/NXsample.yml b/base_classes/nyaml/NXsample.yml new file mode 100644 index 0000000000..17f525117f --- /dev/null +++ b/base_classes/nyaml/NXsample.yml @@ -0,0 +1,315 @@ +doc: | + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. +symbols: + doc: "symbolic array lengths to be coordinated between various fields" + n_comp: "number of compositions" + n_Temp: "number of temperatures" + n_eField: "number of values in applied electric field" + n_mField: "number of values in applied magnetic field" + n_pField: "number of values in applied pressure field" + n_sField: "number of values in applied stress field" +category: base +(NXsample): + name: + doc: "Descriptive name of sample" + chemical_formula: + doc: | + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * 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. + * This is the *Hill* system used by Chemical Abstracts. + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: "Sample temperature. This could be a scanned variable" + dimensions: + rank: anyRank + dim: [[1, n_Temp]] + electric_field(NX_FLOAT): + unit: NX_VOLTAGE + doc: "Applied electric field" + dimensions: + dim: [[1, n_eField]] + \@direction: + enumeration: [x, y, z] + magnetic_field(NX_FLOAT): + unit: NX_ANY + doc: "Applied magnetic field" + dimensions: + dim: [[1, n_mField]] + \@direction: + enumeration: [x, y, z] + stress_field(NX_FLOAT): + unit: NX_ANY + doc: "Applied external stress field" + dimensions: + dim: [[1, n_sField]] + \@direction: + enumeration: [x, y, z] + pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: "Applied pressure" + dimensions: + dim: [[1, n_pField]] + changer_position(NX_INT): + unit: NX_UNITLESS + doc: "Sample changer position" + unit_cell_abc(NX_FLOAT): + unit: NX_LENGTH + doc: "Crystallography unit cell parameters a, b, and c" + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: "Crystallography unit cell parameters alpha, beta, and gamma" + dimensions: + dim: [[1, 3]] + unit_cell(NX_FLOAT): + unit: NX_LENGTH + doc: "Unit cell parameters (lengths and angles)" + dimensions: + rank: 2 + dim: [[1, n_comp], [2, 6]] + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: "Volume of the unit cell" + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: + + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + ub_matrix(NX_FLOAT): + doc: | + 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. + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: "Mass of sample" + dimensions: + rank: 1 + dim: [[1, n_comp]] + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: "Density of sample" + dimensions: + rank: 1 + dim: [[1, n_comp]] + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: "Relative Molecular Mass of sample" + dimensions: + rank: 1 + dim: [[1, n_comp]] + type: + enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] + situation: + doc: "The atmosphere will be one of the components, which is where + its details will be stored; the relevant components will be + indicated by the entry in the sample_component member." + enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] + description: + doc: "Description of the sample" + preparation_date(NX_DATE_TIME): + doc: "Date of preparation of the sample" + geometry(NXgeometry): + doc: "The position and orientation of the center of mass of the sample" + (NXbeam): + doc: "Details of beam incident on sample - used to calculate sample/beam interaction point" + (NXsample_component): + doc: "One group per sample component + This is the perferred way of recording per component information over the n_comp arrays" + component: + doc: "Details of the component of the sample and/or can" + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_component: + doc: "Type of component" + dimensions: + rank: 1 + dim: [[1, n_comp]] + enumeration: [sample, can, atmosphere, kit] + concentration(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: "Concentration of each component" + dimensions: + rank: 1 + dim: [[1, n_comp]] + volume_fraction(NX_FLOAT): + doc: "Volume fraction of each component" + dimensions: + rank: 1 + dim: [[1, n_comp]] + scattering_length_density(NX_FLOAT): + unit: NX_SCATTERING_LENGTH_DENSITY + doc: "Scattering length density of each component" + dimensions: + rank: 1 + dim: [[1, n_comp]] + unit_cell_class: + doc: "In case it is all we know and we want to record/document it" + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + doc: "Crystallographic space group" + dimensions: + dim: [[1, n_comp]] + point_group: + doc: "Crystallographic point group, deprecated if space_group present" + dimensions: + dim: [[1, n_comp]] + path_length(NX_FLOAT): + unit: NX_LENGTH + doc: "Path length through sample/can for simple case when + it does not vary with scattering direction" + path_length_window(NX_FLOAT): + unit: NX_LENGTH + doc: "Thickness of a beam entry/exit window on the can (mm). + It is assumed to be the same for entry and exit" + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: "sample thickness" + sample_id(NX_CHAR): + doc: "Identification number or signatures of the sample used." + sample_history(NXnote): + doc: "A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. + Ideally, a full report of the previous operations, in any format (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" + state(NX_CHAR): + doc: "Physical state of the sample" + purity(NX_FLOAT): + unit: NX_UNITLESS + doc: "Chemical purity of the sample" + orientation(NX_CHAR): + doc: "Surface termination of the sample (if crystalline)" + layer(NX_CHAR): + doc: "Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.)" + chemical_name(NX_CHAR): + doc: "Full chemical name of the sample" + chem_id_cas(NX_CHAR): + doc: "CAS registry number of the sample chemical content." + gas(NX_CHAR): + doc: "Gases might be fluxed on the surface for various reasons. Chemical designation, or residual." + gas_pressure(NX_NUMBER): + doc: "In the case of a fixed pressure measurement this is the scalar pressure. + In the case of an experiment in which pressure changes, or anyway is recorded, + this is an array of length m of pressures." + unit: NX_PRESSURE + surface_dopant(NX_CHAR): + doc: "Element of evaporated surface dopant such as alkali or other" + surface_dopant_coverage(NX_FLOAT): + unit: NX_LENGTH + doc: "Nominal thickness of the evaporated dopant" + bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: "Voltage applied to sample and sample holder." + growth_method(NX_CHAR): + doc: "Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition etc.)" + vendor(NX_CHAR): + doc: "Name of the sample vendor (company or research group)" + substrate_material(NX_CHAR): + doc: "Material of the substrate in direct contact with the sample." + substrate_state(NX_CHAR): + doc: "Physical state of the substrate, similar options to sample_state" + drain_current(NX_FLOAT): + doc: "Current to neutralize the photoemission current. + This field may also be found in NXmanpulator if present." + unit: NX_CURRENT + bias_voltage(NX_FLOAT): + doc: "Possible bias of the sample with respect to analyser ground. + This field may also be found as sample_bias in NXmanipulator if present." + unit: NX_VOLTAGE + notes(NXnote): + doc: "Further notes." + transmission(NXdata): + doc: "As a function of Wavelength" + temperature(NXlog): + doc: "temperature.value is a link to e.g. temperature_env.sensor1.value" + temperature_log(NXlog): + doc: "temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value" + temperature_env(NXenvironment): + doc: "Additional sample temperature environment information" + magnetic_field(NXlog): + doc: "magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value" + magnetic_field_log(NXlog): + doc: "magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value" + magnetic_field_env(NXenvironment): + doc: "Additional sample magnetic environment information" + external_DAC(NX_FLOAT): + unit: NX_ANY + doc: "value sent to user's sample setup" + external_ADC(NXlog): + doc: "logged value (or logic state) read from user's setup" + short_title: + doc: "20 character fixed length sample description for legends" + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer" + x_translation(NX_FLOAT): + unit: NX_LENGTH + doc: "Translation of the sample along the X-direction of the laboratory coordinate system" + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "Translation of the sample along the Z-direction of the laboratory coordinate system" + (NXpositioner): + doc: "Any positioner (motor, PZT, ...) used to locate the sample" + depends_on(NX_CHAR): + doc: "Refers to the last transformation specifying the positon of the manipulator in the NXtransformations chain." + (NXtransformations): + doc: + "Collection of axis-based translations and rotations to describe the location and geometry of the sample 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." + \@default: + doc: | + .. 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/nyaml/NXsource.yml b/base_classes/nyaml/NXsource.yml new file mode 100644 index 0000000000..112ad77ece --- /dev/null +++ b/base_classes/nyaml/NXsource.yml @@ -0,0 +1,143 @@ +doc: "The neutron or x-ray storage ring/facility." +symbols: + doc: "The symbols used in the schema to specify e.g. dimensions of arrays" + nx: "Number of points in a spectrum" +category: base +(NXsource): + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample." + name: + doc: "Name of source" + \@short_name: + doc: "short name for source, perhaps the acronym" + type: + doc: "Type of radiation source (pick one from the enumerated list and spell exactly)" + enumeration: [ + Spallation Neutron Source, + Pulsed Reactor Neutron Source, + Reactor Neutron Source, + Synchrotron X-ray Source, + Pulsed Muon Source, + Rotating Anode X-ray, + Fixed Tube X-ray, + UV Laser, + Free-Electron Laser, + Optical Laser, + Ion Source, + UV Plasma Source, + Metal Jet X-ray, + arc lamp, + halogen lamp, + LED + ] + probe: + doc: "Type of radiation probe (pick one from the enumerated list and spell exactly)" + enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + power(NX_FLOAT): + unit: NX_POWER + doc: "Source power" + emittance_x(NX_FLOAT): + unit: NX_EMITTANCE + doc: "Source emittance (nm-rad) in X (horizontal) direction." + emittance_y(NX_FLOAT): + unit: NX_EMITTANCE + doc: "Source emittance (nm-rad) in Y (horizontal) direction." + sigma_x(NX_FLOAT): + unit: NX_LENGTH + doc: "Particle beam size in x" + sigma_y(NX_FLOAT): + unit: NX_LENGTH + doc: "Particle beam size in y" + flux(NX_FLOAT): + unit: NX_FLUX + doc: "Source intensity/area (example: s-1 cm-2)" + energy(NX_FLOAT): + unit: NX_ENERGY + doc: "Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage." + current(NX_FLOAT): + unit: NX_CURRENT + doc: "Accelerator, X-ray tube, or storage ring current" + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: "Accelerator voltage" + frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: "Frequency of pulsed source" + period(NX_FLOAT): + unit: NX_PERIOD + doc: "Period of pulsed source" + target_material: + doc: "Pulsed source target material or other material used to generate light, e.g. + He, Ar gas for lasers, Xe or Hg/Cd vapor for arc lamps, etc." + enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C, Ar, He, Xe, Hg/Cd, H] + notes(NXnote): + doc: "Any source/facility related messages/events that + occurred during the experiment" + bunch_pattern(NXdata): + doc: "For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns." + title: + doc: "name of the bunch pattern" + number_of_bunches(NX_INT): + doc: "For storage rings, the number of bunches in use." + bunch_length(NX_FLOAT): + unit: NX_TIME + doc: "For storage rings, temporal length of the bunch" + bunch_distance(NX_FLOAT): + unit: NX_TIME + doc: "For storage rings, time between bunches" + pulse_width(NX_FLOAT): + unit: NX_TIME + doc: "Temporal width of source pulse" + pulse_shape(NXdata): + doc: "Source pulse shape" + mode: + doc: "Source operating mode" + enumeration: + Single Bunch: + doc: "For storage rings" + Multi Bunch: + doc: "For storage rings" + top_up(NX_BOOLEAN): + doc: "Is the synchrotron operating in top_up mode?" + last_fill(NX_NUMBER): + unit: NX_CURRENT + doc: "For storage rings, the current at the end of the most recent injection." + \@time: + doc: "Date and time of the most recent injection." + photon_energy(NX_FLOAT): + unit: NX_ENERGY + doc: "The center photon energy of the source, before it is monochromatized or converted" + center_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: "The center wavelength of the source, before it is monochromatized or converted" + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: "For pulsed sources, the energy of a single pulse" + peak_power(NX_FLOAT): + unit: NX_POWER + doc: "For pulsed sources, the pulse energy divided by the pulse duration" + bunch_number_start(NX_INT): + doc: "Some facilities tag each bunch. First bunch of the measurement" + bunch_number_end(NX_INT): + doc: "Last bunch of the measurement" + geometry(NXgeometry): + doc: "'Engineering' location of source" + distribution(NXdata): + doc: "The wavelength or energy distribution of the source" + \@default: + doc: | + .. 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/nyaml/NXaperture_em.yaml b/contributed_definitions/nyaml/NXaperture_em.yaml new file mode 100644 index 0000000000..203463f9e9 --- /dev/null +++ b/contributed_definitions/nyaml/NXaperture_em.yaml @@ -0,0 +1,27 @@ +category: base +# extends: NXaperture +doc: | + Details of an individual aperture for beams in electron microscopy. +NXaperture_em: + name: + doc: Given name/alias of the aperture. + value(NX_NUMBER): + doc: | + Relevant value from the control software. + + This is not always just the diameter of (not even in the case) + of a circular aperture. Usually it is a mode setting value which + is selected in the control software. + Which settings are behind the value should be defined + for now in the description field, if these are known + in more detail. + unit: NX_ANY + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details. Alternatively a free-text field. + (NXfabrication): + (NXtransformations): + doc: | + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml new file mode 100644 index 0000000000..3fcc548c45 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -0,0 +1,1243 @@ +category: application +doc: | + Application definition for atom probe and field ion microscopy experiments. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: Total number of ions collected. + n_dld_wires: Total number of independent wires in the delay-line detector. + n_support: Number of support points for e.g. modeling peaks. + n_ivec_max: | + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + n_ranges: Number of mass-to-charge-state-ratio intervals mapped on this ion type. + n_x: Number of bins in the x direction. + n_y: Number of bins in the y direction. + n_z: Number of bins in the z direction. + n_bins: Number of bins. +NXapm: + (NXentry): + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + # enumeration: [sha_256_hash] + definition: + doc: NeXus NXDL schema to which this file conforms. + enumeration: [NXapm] + experiment_identifier: + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + experiment_description: + exists: optional + doc: | + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + start_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + # These computations can take advantage of individual time stamps + # in NXevent_em instances to provide additional pieces of information. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + # NEW ISSUE: fields like duration need a clearer description as to how these quantities should be defined. Most atom probers do not care for this other than getting an approximate hour-accurate estimate of the time how long it took to evaporate the specimen. + program: + doc: | + Commercial or otherwise given name to the program which was used + to create the original results file of the atom probe experiment. + This file and program should not be confused with downstream + processing operations and file format conversion tasks. + + Atom probe microscopy experiments are except for still very much cases + controlled via commercial software. Such software is designed as an + integrated acquisition and instrument control software. + + For AMETEK/Cameca local electrode atom probe (LEAP) instruments the + least processed (rawest) numerical results and metadata are stored + in so-called RHIT and HITS files, which are proprietary and the + specifications of which are not publicly documented. + + Supplementary metadata are kept in a database which is connected + to the instrument control software and synced with the experiment + while signal is being detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also to resolve isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + Therefore, this application definition documents not only the measurement + but also the key post-processing steps which transform the proprietary + data into a tomographic reconstruction with ranging definitions. + + Future guidance by the vendors could improve this description to cover + a substantial larger number of eventually metadata that so far + are not publicly documented and accessible in an open-source manner. + \@version: + doc: | + Program 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. + run_number(NX_CHAR): + doc: | + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow to store the + entire set of such interrupted runs to be stored and covered. However, + this is not because of a technical limitation within NeXus but + because we have not seen a covering use case based on which we could + have implemented and conceptualized this. Atom probers are invited to + contact the respective people in the FAIRmat team to fix this. + experiment_documentation(NXnote): + exists: optional + doc: | + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + thumbnail(NXnote): + exists: optional + doc: | + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + \@type: + operation_mode: + doc: | + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + enumeration: [apt, fim, apt_fim, other] + # description: + # exists: optional + # doc: | + (NXuser): + exists: [min, 1, max, infty] + doc: | + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + name: + doc: Given (first) name and surname of the user. + affiliation: + exists: recommended + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address: + exists: recommended + doc: Postal address of the affiliation. + email: + exists: recommended + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + orcid: + exists: recommended + doc: | + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + orcid_platform: + exists: recommended + doc: | + Name of the OrcID or ResearcherID where the account + under orcid is registered. + telephone_number: + exists: optional + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role: + exists: recommended + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + social_media_name: + exists: optional + doc: | + Account name that is associated with the user in social media platforms. + social_media_platform: + exists: optional + doc: | + Name of the social media platform where the account + under social_media_name is registered. + specimen(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + name: + doc: | + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin from where the specimen was cut. + In cases where the specimen was e.g. site-specifically cut from + samples or in cases of an instrument session during which multiple + specimens are loaded, the name has to be descriptive enough to resolve + which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how specimens were + cut/prepared from samples in the sample history. This field must + not be used for an alias of the specimen. Instead, use short_title. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample history. + sample_history: + doc: | + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + short_title: + exists: optional + doc: Possibility to give an abbreviation of the specimen name field. + atom_types: + doc: | + Use Hill's system for listing elements of the periodic table which + are inside or attached to the surface of the specimen, and thus + relevant from a scientific point of view. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + description: + exists: optional + doc: | + Discouraged free-text field in case properly designed records + for the sample_history are not available. + # NEW ISSUE: error model + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + (NXdata): + exists: optional + doc: | + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + (NXcoordinate_system_set): + exists: recommended + doc: | + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + (NXtransformations): + exists: [min, 0, max, infty] + # NEW ISSUE: add Breen's Ultramicroscopy paper on atom probe crystallography + # in what follows each component of the instrument might be equipped with an NXmonitor + (NXmonitor): + exists: [min, 0, max, infty] + # NEW ISSUE ADD AS MANY MONITORS AS NEEDED, also for pressure etc. + atom_probe(NXinstrument): + doc: | + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + instrument_name: + doc: | + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + location: + exists: optional + doc: | + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + (NXfabrication): + identifier: + exists: recommended + capabilities: + exists: optional + flight_path_length(NX_FLOAT): + doc: | + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + unit: NX_LENGTH + # NEW ISSUE: discussion depends on the type of instrument, straight flight path, curved + field_of_view(NX_FLOAT): + exists: recommended + doc: | + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + unit: NX_LENGTH + analysis_chamber(NXchamber): + name: + exists: optional + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + description: + exists: optional + pressure(NX_FLOAT): + doc: Average pressure in the analysis chamber. + unit: NX_PRESSURE + (NXreflectron): + # check if doc string gets carried over doc: Device for reducing flight time differences of ions in ToF experiments. + applied(NX_BOOLEAN): + doc: Is a reflectron installed and was it used? + name: + exists: optional + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + description: + exists: recommended + # NEW ISSUE: flat_test_data(NXcollection): + # exists: recommended + # doc: NEED FOR FURTHER DISCUSSIONS WITH APM COLLEAGUES WHAT IS RELEVANT HERE. + local_electrode(NXlens_em): + doc: | + A local electrode guiding the ion flight path. + name: + doc: | + Identifier of the local_electrode in an e.g. database. + (NXaperture_em): + exists: optional + name: + exists: recommended # ##MK::should become required + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + value(NX_NUMBER): + exists: recommended # ##MK::should become required + # but the local_electrode does not really on purpose create a magnetic field, + # specific for an electro-magnetic lens is the symmetry of its field + # NEW ISSUE: for now keep that we have what is an NXlens_em + # NEW ISSUE: APEX MONITOR / LEAP distance monitoring + # NEW ISSUE: the definition of flat test data should be included and documented + # NEW ISSUE: local electrode, baking strategies, storage + ion_detector(NXdetector): + doc: | + Detector for taking raw time-of-flight and + ion/hit impact positions data. + type: + doc: | + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + # enumeration: [mcp_dld, phosphor_ccd, other] + name: + exists: recommended + doc: Given name/alias. + # NEW ISSUE: why not (NXfabrication) + model: + exists: recommended + doc: Given brand or model name by the manufacturer. + serial_number: + exists: recommended + doc: Given hardware name/serial number or hash identifier issued by the manufacturer. + manufacturer_name: + exists: recommended + doc: Given name of the manufacturer. + signal_amplitude(NX_FLOAT): + exists: optional + doc: | + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + unit: NX_CURRENT + dimensions: + rank: 1 + dim: [[1, n_ions]] + pulser(NXpulser_apm): + pulse_mode: + pulse_frequency(NX_FLOAT): + pulse_fraction(NX_FLOAT): + pulsed_voltage(NX_FLOAT): + exists: recommended + standing_voltage(NX_FLOAT): + exists: recommended + laser_gun(NXsource): + exists: recommended + # INVIZO 6000 instrument have two symmetric lasers! so for these + # laser_gun and laser_beam exists: [min, 0, max, 2] + doc: | + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + name: + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + wavelength(NX_FLOAT): + exists: recommended + power(NX_FLOAT): + exists: recommended + pulse_energy(NX_FLOAT): + exists: recommended + laser_beam(NXbeam): + exists: recommended + pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set + exists: recommended + spot_position(NXcollection): # NXsnapshot, NXcg_point_set + exists: recommended + + stage_lab(NXstage_lab): + # NEW ISSUE: consider more detailed opportunities for specifying holders like cryo-controller holder, type of holder, material for pucks make a difference for studies which hunt for hydrogen signal, equally dwell time in buffer and load lock chamber and environmental transfer, the application definition does not account for this at the moment, would need a class representing stage and specimen holder hierarchy of the entire sample loading and transfer system and the contributions or not these components make wrt to contamination. + base_temperature(NX_FLOAT): + doc: | + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + unit: NX_TEMPERATURE + + # NEW ISSUE: begin add and support I/O of further details + load_lock_chamber(NXchamber): + exists: optional + name: + exists: optional + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + description: + exists: optional + pressure(NX_FLOAT): + doc: Average pressure in the load_lock_chamber. + unit: NX_PRESSURE + buffer_chamber(NXchamber): + exists: optional + name: + exists: optional + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + description: + exists: optional + pressure(NX_FLOAT): + doc: Average pressure in the buffer chamber. + unit: NX_PRESSURE + getter_pump(NXpump): + exists: optional + design: + exists: recommended + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + roughening_pump(NXpump): + exists: optional + design: + exists: recommended + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + turbomolecular_pump(NXpump): + exists: optional + design: + exists: recommended + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + # NEW ISSUE: end add and support I/O of further details + specimen_monitoring(NXcollection): + exists: recommended + # NEW ISSUE: should be promoted to recommended at some point in particular with closer integration of APM and EM instruments + doc: | + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. `_ + and `C. Fletcher `_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann `_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. `_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + # NEW ISSUE: consider the above comments into new fields when important progress has been made. + initial_radius(NX_FLOAT): + doc: | + Ideally measured or best elaborated guess of the + initial radius of the specimen. + unit: NX_LENGTH + shank_angle(NX_FLOAT): + doc: | + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + unit: NX_ANGLE + detection_rate(NX_FLOAT): + doc: | + Average detection rate over the course of the experiment. + unit: NX_DIMENSIONLESS + # NEW ISSUE: define e.g. radius(NX_FLOAT) and evaporation_id(NX_UINT) to store snapshots of the shape evolution of the specimen. + + control_software(NXcollection): + doc: | + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) `_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + # NEW ISSUE: With new development pull fields out of this collection into dedicated groups. + # might consider moving this to individual groups under (NXpump) or (NXchamber) groups. + program: + doc: | + Name of the control software of the microscope + used during acquisition (e.g. IVAS/APSuite). + \@version: + doc: | + Program 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. + buffer_chamber(NXcollection): + exists: optional + doc: Track time-dependent details over the course of the measurement about the buffer_chamber. + load_lock_chamber(NXcollection): + exists: optional + doc: Track time-dependent details over the course of the measurement about the load_lock_chamber. + analysis_chamber(NXcollection): + exists: optional + doc: Track time-dependent details over the course of the measurement about the analysis_chamber. + # NEW ISSUE: pressure in the buffer and load lock chambers + # NEW ISSUE: atmosphere and partial pressures + + # so although strictly speaking the following steps are computational + # post-processing of detector raw data to be specific they are listed + # under the atom_lab group because for experiment with commercial instrument + # these steps are currently not fully separatable as all processing in + # most cases the processing is done in commercial software. + + ion_impact_positions(NXprocess): + exists: recommended + doc: | + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + arrival_time_pairs(NX_NUMBER): + exists: recommended + doc: | + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + # NEW ISSUE: discuss with Oxcart developers which modifications might be necessary here. + unit: NX_TIME + dimensions: + rank: 3 + dim: [[1, n_ions], [2, n_dld_wires], [3, 2]] + hit_positions(NX_NUMBER): + doc: | + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_ions], [2, 2]] + # NEW ISSUE: follow the example of base_temperature_time_profile to monitor the temporal evolution of the detection_rate over the course of the evaporation sequence + # detection_rate_time_profile(NX_FLOAT): + # doc: Spatio-temporal profile of the detection rate since the start of the measurement. + # NEW ISSUE: discuss how to handle cases when we would like to store ideally an array where one dimensions is NX_TIME and the other one is e.g. NX_PERCENT + hit_multiplicity(NXprocess): + # NEW ISSUE: use symbols to monitor number of pulses + exists: recommended + doc: | + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + pulses_since_last_ion(NX_UINT): + exists: recommended + doc: | + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + dimensions: + rank: 1 + dim: [[1, n_ions]] + unit: NX_UNITLESS + hit_multiplicity(NX_UINT): + exists: recommended + # NEW ISSUE: further discussions with members of the APM community is required to clarify this field and what it means + doc: Hit multiplicity. + dimensions: + rank: 1 + dim: [[1, n_ions]] + unit: NX_UNITLESS + pulse_id(NX_UINT): + # NEW ISSUE: I feel the name is misleading, the quantity is + # named like this de facto only because thats the jargon term with epos files. + exists: optional + doc: | + Number of pulses since the start of the atom probe run/evaporation sequence. + dimensions: + rank: 1 + dim: [[1, n_ions]] + unit: NX_UNITLESS + + ion_filtering(NXprocess): + exists: recommended + doc: | + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + evaporation_id_included(NX_BOOLEAN): # NXcs_filter_boolean_mask + doc: Bitmask which is set to true if the ion is considered and false otherwise. + dimensions: + rank: 1 + dim: [[1, n_ions]] # then only a group + + voltage_and_bowl_correction(NXprocess): + exists: recommended + doc: | + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + # NEW ISSUE: realistic is that currently scientists can pull always a calibrated time-of-flight but not necessarily unprocessed timing data from the detector (unless individuals built the instrument). Relevant for ranging are the calibrated data, thats why only these (as an intermediate/compromise solution) are required in this version of the application definition + raw_tof(NX_FLOAT): + exists: recommended + doc: | + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, n_ions]] + calibrated_tof(NX_FLOAT): + # NEW ISSUE: which type of calibrations are applied is usually a modified sqrt tof to m/q mapping the exact parameter of which are for LEAP instruments not immediately accessible. + doc: | + Calibrated time-of-flight. + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, n_ions]] + tof_calibration(NXcollection): + exists: recommended + doc: | + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + # NEW ISSUE: should be recommended as otherwise one cannot ensure that numerically the same voltage-and-bowl correction results are obtained (without knowning the parameters...) + + mass_to_charge_conversion(NXprocess): + exists: recommended + doc: | + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + parameter(NXcollection): + exists: recommended + doc: | + Store vendor-specific calibration models here (if available). + mass_to_charge(NX_FLOAT): + doc: | + Mass-to-charge-state ratio values. + unit: NX_ANY + # \@units: Da + dimensions: + rank: 1 + dim: [[1, n_ions]] + + reconstruction(NXprocess): + exists: recommended + doc: | + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + program: + doc: | + Given name of the program that was used to perform this computation. + Similar comments as voltage_and_bowl_correction apply. + \@version: + doc: | + Program 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. + protocol_name: + doc: | + Qualitative statement about which reconstruction protocol was used. + enumeration: [bas, geiser, gault, cameca, other] + parameter: + # NEW ISSUE: the status here should be promoted to required but currently one needs to manually extract the reconstruction parameters + # NEW ISSUE: for instance from commercial software, here a better strategy is needed how to document the reconstruction parameter. + doc: | + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + # k(NX_FLOAT): + # doc: Field factor + # unit: ?? + # icf(NX_FLOAT): + # doc: Image compression factor. + # unit: ?? + # NEW ISSUE: for AMETEK, as well as for the Bas, Geiser, and + # Gault protocols we know the usual naming of the parameters + # they should be added as optional quantities. + # Therefore, it is difficult for now to generalize the meaning + # and idea behind all relevant reconstruction parameters. + # One could create a class for each reconstruction method, as + # these methods are de facto application definitions. + crystallographic_calibration: + doc: | + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + reconstructed_positions(NX_FLOAT): + doc: | + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_ions], [2, 3]] + + naive_point_cloud_density_map(NXprocess): + doc: | + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + (NXdata): + doc: | + A default three-dimensional histogram of the total number of ions in each bin. + # \@signal: + # doc: Which is the dependent signal to plot, here the counts. + # \@axes: + # doc: Which axes are plotted, here the three principal coordinate directions. + counts(NX_NUMBER): + doc: Array of counts for each bin. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_z], [2, n_y], [3, n_x]] #why do indices start at 0 here and not 1 ? + zpos(NX_NUMBER): + doc: Bin positions along the z axis. + unit: NX_LENGTH + ypos(NX_NUMBER): + doc: Bin positions along the y axis. + unit: NX_LENGTH + xpos(NX_NUMBER): + doc: Bin positions along the x axis. + unit: NX_LENGTH + # \@xpos_indices: + # doc: Bin edge end along x. + # \@ypos_indices: + # doc: Bin edge end along y. + # \@zpos_indices: + # doc: Bin edge end along z. + \@long_name: + doc: Naive point cloud density map. + + ranging(NXprocess): + exists: recommended + doc: | + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller `_ + * `D. Haley et al. `_ + * `M. Kühbach et al. `_ + + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + number_of_ion_types(NX_POSINT): + doc: | + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + unit: NX_UNITLESS + maximum_number_of_atoms_per_molecular_ion(NX_UINT): + doc: | + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + unit: NX_UNITLESS + + mass_to_charge_distribution(NXprocess): + exists: recommended + doc: | + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + range_minmax(NX_FLOAT): + doc: Smallest and largest mass-to-charge-state ratio value. + unit: NX_ANY + # \@units: Da + # NEW ISSUE: NX_ATOMIC_MASS_UNIT use Tommasso scheme here Da + dimensions: + rank: 1 + dim: [[1, 2]] + range_increment(NX_FLOAT): + doc: Binning width of the mass-to-charge-state ratio values. + unit: NX_ANY + # \@units: Da + # NEW ISSUE: unit must match with range, is Da + mass_spectrum(NXdata): + doc: | + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + # \@signal: + # doc: Which is the dependent signal to plot. + # \@axes: + # doc: Which axes are plotted, here counts over bins. + counts(NX_NUMBER): + doc: Array of counts for each bin. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_bins]] + bin_ends(NX_NUMBER): + doc: End of value for each mass-to-charge-state ratio bin. + unit: NX_ANY + # # \@units: Da + # \@bin_ends_indices: + # doc: Label of the mass-to-charge-state ratio bin axis. + \@long_name: + doc: Mass-to-charge-state histogram. + + background_quantification(NXprocess): + exists: recommended + doc: | + Details of the background model which was used to + correct the total counts per bin into counts. + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + # NEW ISSUE: add parameters of the background model in an e.g. + # NXcollection as these are specific to every background model + # NEW ISSUE: touching upon i.e. research activities by Andrew London et al. + # substantiating the need for a clearer description how peak/signals were + # eventually processed via deconvolution methods + + peak_search_and_deconvolution(NXprocess): + exists: recommended + doc: | + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + (NXpeak): + exists: [min, 0, max, infty] + label: + exists: recommended + peak_model: + + peak_identification(NXprocess): + exists: recommended + doc: | + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + program: + doc: | + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + \@version: + doc: | + Program 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. + (NXion): + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): # more human-readable form of the isotope_vector + exists: recommended + charge_state(NX_INT): # ##MK::needs to be NX_INT + mass_to_charge_range(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXapm_input_ranging.yaml b/contributed_definitions/nyaml/NXapm_input_ranging.yaml new file mode 100644 index 0000000000..f3c07abbc1 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_input_ranging.yaml @@ -0,0 +1,27 @@ +category: base +doc: | + Metadata to ranging definitions made for a dataset in atom probe microscopy. +# symbols: +NXapm_input_ranging: + filename: + doc: | + Name of (NeXus)/HDF5 file which stores ranging definitions which define + how mass-to-charge-state ratios map to iontypes and which iontypes are + distinguished. The UNKNOWNTYPE iontype (unranged) is the default iontype. + The ID of this special iontype is always reserved as 0. Each ion + is assigned to the UNKNOWNTYPE by default. Iontypes are assigned + by checking if the mass-to-charge-state ratio of an ion matches + to any of the defined mass-to-charge-state ratio intervals. + \@version: + doc: | + Version identifier of the file (representing an at least SHA256) hash + which documents the binary state of the file to add an additional layer + of reproducibility for tracking provenance. + group_name_iontypes: + doc: | + Name of the group (prefix to the individual ranging definitions) + inside the HDF5 file which refers to the ranging definition to use. + A HDF5 file can store multiple ranging definitions. Using an ID is + the mechanism to distinguish which specific ranging (version) will + be processed. Reconstruction and ranging IDs can differ. + They specify different IDs. diff --git a/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml new file mode 100644 index 0000000000..152b71d48d --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml @@ -0,0 +1,27 @@ +category: base +doc: | + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. +# symbols: +NXapm_input_reconstruction: + filename: + doc: | + Name of the (NeXus)/HDF5 file which stores reconstructed ion position + and mass-to-charge-state ratios. Such an HDF5 file can store multiple + reconstructions. Using an identifier (ID) is the mechanism which + paraprobe uses to distinguish which specific reconstruction will + be processed. With this design it is possible that the same HDF5 + file stores multiple versions of a reconstruction of e.g. the same + or different measured datasets, respectively. + \@version: + doc: | + Version identifier of the file (representing an at least SHA256) hash + which documents the binary state of the file to add an additional layer + of reproducibility for tracking provenance. + dataset_name_reconstruction: + doc: | + Name of the dataset inside the HDF5 file which refers to the + specific reconstructed ion positions to use for this analysis. + dataset_name_mass_to_charge: + doc: | + Name of the dataset inside the HDF5 file which refers to the + specific mass-to-charge-state ratios to use for this analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml new file mode 100644 index 0000000000..014885c3ed --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml @@ -0,0 +1,246 @@ +category: application +doc: | + Configuration of a paraprobe-clusterer tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_positions: Number of position values. + n_disjoint_clusters: Number of disjoint cluster. +NXapm_paraprobe_config_clusterer: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_clusterer] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + number_of_processes(NX_UINT): + doc: | + How many clustering processes should the tool execute. + unit: NX_UNITLESS + cameca_to_nexus(NXprocess): + exists: [min, 0, max, 1] + doc: | + This process maps results from cluster analyses performed with IVAS/APSuite + into an interoperable representation. Specifically in this process + paraprobe-clusterer takes results from clustering methods from other tools + of the APM community, like IVAS/APSuite. These results are usually reported + in two ways. Either as an explicit list of reconstructed ion positions. + In the case of IVAS these positions are reported through a text file + with a cluster label for each position. + + Alternatively, the list of positions is reported, as it is the case for + AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly + only in the following way: The mass-to-charge-state ratio column of a + what is effectively a file formatted like POS is used to assign a hypothetical + mass-to-charge value which resolves a floating point representation + of the cluster ID. + + Another case can occur where all disjoint floating point values, + i.e. here cluster labels, are reported and then a dictionary is created + how each value matches to a cluster ID. + + In general the cluster ID zero is reserved for marking the dataset + as to not be assigned to any cluster. Therefore, indices of disjoint + clusters start at 1. + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + exists: required + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + + ion_position_filename: + doc: | + Name of HDF5 file which stores reconstructed ion positions. + This file should have been generated by from the community or vendor format. + This file not necessarily contains all the of the dataset because + spatial filters might have been applied in commercial software prior + to executing the cluster analysis so that e.g. only positions within a + ROI are reported by the commercial software. + POS files from IVAS have to be converted first. + dataset_name_positions: + doc: | + Name of the dataset inside the HDF5 file ion_position_filename + which refers to the specific positions to use for this analysis. + The referred to dataset has to be formatted as an array of shape + (n_positions, 3). + cluster_indices_filename: + doc: | + Name of the HDF5 file which stores mass-to-charge-state-ratio values + (in the case of IVAS/APSuite) or other numbers which can be interpreted + as cluster labels. + dataset_name_cluster_indices: + doc: | + Name of the dataset inside the HDF5 file cluster_indices_filename + which refers to the specifically encoded cluster indices. + The referred to dataset has to be formatted as an array of shape + (n_positions, 1). + # mapping_method: + # doc: | + # How should cluster labels be created from the cluster_labels information + # especially when these areNcluste floating point values. + # enumeration: [take_as_is, use_dictionary] + mapping_dictionary_keyword(NX_NUMBER): + doc: | + The list of all keywords of a dictionary which maps implicit cluster + indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_disjoint_clusters]] + mapping_dictionary_value(NX_UINT): + doc: | + The list of all values of a dictionary which maps implicit cluster + indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + The sequences of mapping_dictionary_keyword and mapping_dictionary_value + have to match. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_disjoint_clusters]] + recover_evaporation_id(NX_BOOLEAN): + doc: | + Specifies if the tool should try to recover for each position the closest + matching position from dataset/dataset_name_reconstruction (within + floating point accuracy). This can be useful for instance when users + wish to recover the original evaporation ID which IVAS/AP Suite drops + for instance when writing their *.indexed.* cluster results files. + unit: NX_UNITLESS + recover_bitmask(NX_BOOLEAN): + doc: | + Specifies if the tool should try to recover, after a recovery of the + evaporation IDs a bitmask which identifies which of the positions + in dataset/dataset/dataset_name_reconstruction where covered + by the IVAS/APSuite cluster analysis. This can be useful to recover + the region of interest. + unit: NX_UNITLESS + # compute_convex_hulls(NX_BOOLEAN): + # doc: | + # For now a support functionality which instructs the tool based on the group all positions for each ion to compute a representation of the convex hull of the dataset. This functionality is planned to be replaced at some point by the surfacer tool inasmuch as the surfacer tool gets the option to accept labelled positions. This approach would also be more useful in the future because then the machinery for computing alpha shapes can immediately be applied as well for set of point clouds, i.e. cluster analysis. + + cluster_analysis(NXprocess): + exists: [min, 0, max, 1] + doc: | + This process performs a cluster analysis on a reconstructed dataset + or a portion of the reconstruction. + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + exists: required + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + + clustering_algorithm: + doc: Name of the algorithm. + clustering_parameter: + doc: | + A text representation like a JSON/YAML dictionary with the + parameter of the clustering_algorithm. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml new file mode 100644 index 0000000000..275287cd48 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml @@ -0,0 +1,179 @@ +category: application +doc: | + Configuration/settings of a paraprobe-distancer software tool run. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXapm_paraprobe_config_distancer: + (NXentry): + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_distancer] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + number_of_processes(NX_UINT): + doc: How many individual analyses should the tool execute. + unit: NX_UNITLESS + (NXprocess): + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + exists: required + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + + point_to_triangle(NXprocess): + doc: | + Compute for all filtered points, e.g. ions of the point set + the shortest Euclidean distance to the closest triangle of the + set of triangles. The triangles can formed a closed surface mesh. + Distances are not simple distances based on normal projections but + giving an exact solution. + triangle_soup(NXprocess): + # NEW ISSUE NXtriangle_soup + doc: | + Paraprobe-distancer enables the computation of the Euclidean shortest + distance for each member of a set of points against a set of triangles. + In contrast to comparable methods used in atom probe the here computed + distance is not simply the projected distance to one of the triangles + but the more costly but robust computation of the distance between + a point and a triangle. + + The triangles can represent for instance the facets of a triangulated + surface mesh of a model for the edge of the dataset. Such a model can + be computed with paraprobe-surfacer. Alternatively, the triangles can + be those from the set of all facets for a set of convex hulls, alpha-shapes, + or alpha wrappings about three-dimensional objects like precipitates + (computed with e.g. paraprobe-nanochem). + + Currently, the tool does not check if the respectively specified + triangle sets are consistent, what their topology is, or whether or + not they are consistently oriented. + Each dataset that is referred to in the list_of _dataset_names_vertices + should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred + to in the list_of_dataset_names_facet_indices should be an + (Nfacets, 3) array of NX_UINT. + Facet indices refer to vertex indices. These need to start at zero + and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and vertices are indexed thus implicitly. + Facet normal vectors have to be also an array + of shape (Nfacets, 3) of NX_FLOAT. + number_of_files(NX_UINT): + doc: How many triangle sets to consider. + unit: NX_UNITLESS + (NXprocess): # should better be an NXprocess + doc: | + List of triangle sets. This design allows users to combine + multiple triangle sets. + filename: + doc: | + Name of the HDF5 file(s) which contain(s) vertex coordinates + and facet indices to describe the desired set of triangles. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility. + dataset_name_vertices: + doc: | + Absolute HDF5 path to the dataset which + specifies the array of vertex positions. + dataset_name_facet_indices: + doc: | + Absolute HDF5 path to the dataset which + specifies the array of facet indices. + dataset_name_facet_normals: + exists: optional + doc: | + Absolute HDF5 path to the dataset which + specifies the array of facet normal vectors. + method: + doc: | + Specifies for which ions/points the tool will compute distances. + The purpose of this setting is to avoid unnecessary computations + when the user requests to only compute distances of ions within a + threshold distance to the triangle soup. + + By default the distances are computed for all ions; however + the setting skin enables to compute distances only for those + ions which are not farther away located to a triangle + than threshold_distance. + enumeration: [default, skin] + threshold_distance(NX_FLOAT): + # ##MK::only required when method is skin + doc: | + Maximum distance for which distances are computed when method is skin. + unit: NX_LENGTH + # \@units: nm + + # point_set_to_polyline_set(NXprocess): + # doc: | + # Compute the shortest Euclidean distance of all filtered points/ions + # of a point set to the closest point on the closest polyline. + # polyhedra_set_to_triangle_set(NXprocess): + # doc: | + # Compute the (shortest Euclidean) distance of all polyhedra of a set diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml new file mode 100644 index 0000000000..a67c5c599d --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml @@ -0,0 +1,370 @@ +category: application +doc: | + Configuration of a paraprobe-intersector tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + # Nityp_cand: How many iontypes does the delocalization filter specify. + # Nivec: Maximum number of atoms per molecular ion. + n_elements: How many elements to use for computing a composition. +NXapm_paraprobe_config_intersector: + (NXentry): + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_intersector] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + intersection_detection_method: + doc: | + Specifies the method to use which decides if two objects intersect. + For reasons which are detailed in the supplementary material of + `M. Kühbach et al. `_, the tool by + default assumes that two objects intersect if they share at least one + ion with the same evaporation ID + (shared_ion). Alternatively, with specifying tetrahedra_intersections, + the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks + for at least one pair of intersecting tetrahedra to identify if two objects + intersect or not. + + However, we found that these geometrical analyses can result in corner + cases which the currently used library (TetGen) was not unable to + tetrahedralize successfully. These cases were virtually always + associated with complicated non-convex polyhedra + which had portions of the mesh that were connected by almost point like + tubes of triangles. + enumeration: [shared_ion, tetrahedra_intersections] + has_object_volume(NX_BOOLEAN): + doc: | + Specifies if the tool should load the volume of each object + (if existent in the input file) to characterize the evolution of the + objects' volume as a function of set identifier (e.g. time). + + This and the has_object_composition option enables to activate + computations in the code which correlate the spatio-temporal tracking + with an object's properties. This is useful to explore/understand how + the object descriptor values evolve as a function of the parameterization + of the object. To arrive at a detailed understanding and quantification + of the differences of a given object as a function of delocalization and + e.g. iso-surfacing settings. + + The point made in M. Kühbach et al. 2022, is that this functionality + can be used to track for instance how the accumulated volume and + composition of an object depends on its segmentation via iso-surfaces. + The benefit of such computations is that users can inspect the + parameter sensitivity of an objects representation rigorously. + has_object_composition(NX_BOOLEAN): + doc: | + Specifies if the tool should load the composition of each object + (if existent in the input file) to characterize the evolution of the + object's composition as a function of set identifier. See the description + of has_object_volume for further details. In M. Kühbach et al. 2022, both + has_object options were used to characterize e.g. the parameter + sensitivity of computed composition, volume, and shape specifically, + for a carbide that was segmented via different carbon iso-composition + values. + element_whitelist(NX_UINT): + doc: | + List of np.uint16 elements, via their proton number. The whitelist is + evaluated to compute the composition of an object during tracking + when has_object_composition is set to true. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_elements]] + #[[1, Nivec], [2, Nityp_cand]] + number_of_processes(NX_UINT): + doc: | + For now a support field for the tool to identify how many individual + analyses the tool should execute as part of the analysis. + unit: NX_UNITLESS + + (NXprocess): + number_of_tracking_sets(NX_UINT): + doc: | + For now a support field for the tool to identify how many individual + analyses (i. e. individual current_to_next mappings) the tool should + perform as part of the high-throughput analysis. + unit: NX_UNITLESS + (NXprocess): + exists: [min, 1, max, 1] + doc: | + Tracking is the process of building logical relations between objects + based on proximity and mesh intersections. For each time step pairs + of sets are compared: members of a current_set and a next_set. + Members have to be objects and eventually can in addition be so-called + proxies. Objects and proxies are non-degenerated closed polyhedra which + are not necessarily convex. Proxies are doppelganger/replacement + meshes of objects which would otherwise be impossible to describe + with a closed mesh. + # To offer a draft implementation for the handling of proxies, + # the code currently imports the proxies as if they were objects. + current_set(NXcollection): + # NEW ISSUE: better should be a set of geometric primitives + # provenance handling + doc: | + Current set stores a set of object geometries that should be checked + for proximity and/or intersection with member of the next_set. + identifier(NX_UINT): + doc: | + This identifier can be used to label the current set. The label + effectively represents the time/iteration step when the current + set was taken. As it is detailed in M. Kühbach et al. 2022, + this identifier takes the role of the time variable k. + unit: NX_ANY + # number_of_objects(NX_UINT): + # doc: For now a support field to tell the tool how many objects to load. + # unit: NX_UNITLESS + filename: + doc: | + Name of the HDF5 file which contain geometry (vertex coordinates, + facet indices) and properties (ions, composition) of polyhedra + (l objects) which should be included in the current set. + The user has to ensure that the datasets under list_of_dataset_names + (vertices, facet_indices, ions) exist and are formatted consistently. + # NEW ISSUE: make more robust checks wrt to the consistence of the datasets + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + groupname_object_geometry_data: + doc: | + Paraprobe-intersector loads triangulated surface mesh data of a + set of objects. For each object its mesh is expected to have + three-dimensional position data of the unique vertices and a + matrix of vertex indices which describe the faces. + As each object has to be a polyhedron/closed surface mesh, this + matrix has as many rows as faces, i.e. triangles and three columns. + Vertex indices have to start at zero. + groupname_object_supplementary_data: + doc: | + The default intersection detection method uses shared ions. + Therefore, it is necessary to specify where the results from the + paraprobe-nanochem tool run are located which document which ions + (with their evaporation IDs) are inside or on the surface of each + object. This field points the tool to these evaporation IDs. + groupname_object_property_data: + doc: | + In order to correlate object properties like volume and composition + with tracking data, it is necessary to specify where the results + (object properties) from the paraprobe-nanochem tool run are located. + This field instructs the tool where to load these object property data + from. + dataset_object_identifier: + doc: | + Paraprobe-intersector does not just compare two objects but a set + of sets of objects. This field instructs the tool where to load + the identifiers (names) of each object in a current_set or next_set + respectively from. + groupname_proxy_geometry_data: + exists: optional + doc: | + Like groupname_object_geometry_data but for the proxies. + Triangulated surface meshes of proxies have to be formatted + in the same manner as objects. + groupname_proxy_interior_supplementary_data: + exists: optional + doc: | + Like groupname_proxy_supplementary_data but for the interior proxies. + Leave an empty string if proxies should not be used. + groupname_proxy_exterior_supplementary_data: + exists: optional + doc: | + Like groupname_proxy_supplementary_data but for the exterior proxies. + Leave an empty string if proxies should not be used. + # groupname_proxy_property_data: + # exists: optional + # doc: | + # Like groupname_proxy_property_data but for the proxies. + # dataset_proxy_identifier: + # exists: optional + # doc: Like dataset_object_identifier but for the proxies. + # list_of_dataset_names_vertices: + # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of vertex positions for each object. + # list_of_dataset_names_facet_indices: + # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of facet indices for each object. + # list_of_dataset_names_properties: + # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of properties for each object. + + next_set(NXcollection): + doc: | + Next set stores a set of object geometries that should be checked + for proximity and/or intersection with (each) member(s) of the + current_set. + identifier(NX_UINT): + doc: | + This identifier can be used to label the next set. Like for the current_set + the identifier is effectively the time/iteration step when the next set was taken. + As it is detailed in M. Kühbach et al. 2022, this identifier + takes the role of the time variable k+1. + unit: NX_ANY + # number_of_objects(NX_UINT): + # doc: For now a support field to tell the tool how many objects to load. + # unit: NX_UNITLESS + filename: + doc: | + Name of the HDF5 file which contain geometry (vertex coordinates, + facet indices) and properties (ions, composition) of + polyhedra(l objects) which should be included in the current set. + The user has to ensure that the datasets that are referred to + under list_of_dataset_names (vertices, facet_indices, ions). + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + groupname_object_geometry_data: + doc: | + Paraprobe-intersector loads triangulated surface mesh data of a + set of objects. For each object its mesh is expected to have + three-dimensional position data of the unique vertices and a + matrix of vertex indices which describe the faces. + As each object has to be a polyhedron/closed surface mesh + this matrix has as many rows as faces, i.e. triangles and + three columns. Vertex indices have to start at zero. + groupname_object_supplementary_data: + doc: | + The default intersection detection method uses shared ions. + Therefore, it is necessary to specify where the results from the + paraprobe-nanochem tool run are located which document which ions + (with their identifiers) are inside or on the surface of each object. + This field instructs the tool where to load these + ion evaporation ids from. + groupname_object_property_data: + doc: | + In order to correlate object properties like volume and composition + with tracking data, it is necessary to specify where the results + (object properties) from the paraprobe-nanochem tool run are located. + This field instructs the tool where to load these object property + data from. + dataset_object_identifier: + doc: | + Paraprobe-intersector does not just compare two objects but a set + of sets of objects. This field instructs the tool where to load + the identifiers (names) of each object in a current or next set + respectively from. + groupname_proxy_geometry_data: + exists: optional + doc: | + Like groupname_object_geometry_data but for the proxies. + Triangulated surface meshes of proxies have to be formatted + in the same manner. Leave an empty string if proxies should not + be used. + groupname_proxy_interior_supplementary_data: + exists: optional + doc: | + Like groupname_proxy_supplementary_data but for the interior proxies. + Leave an empty string if proxies should not be used. + groupname_proxy_exterior_supplementary_data: + exists: optional + doc: | + Like groupname_proxy_supplementary_data but for the exterior proxies. + Leave an empty string if proxies should not be used. + # groupname_proxy_property_data: + # exists: optional + # doc: | + # Like groupname_proxy_property_data but for the proxies. + # Leave an empty string if proxies should not be used. + # dataset_proxy_identifier: + # exists: optional + # doc: | + # Like dataset_object_identifier but for the proxies. + # Leave an empty string if proxies should not be used. + # list_of_dataset_names_vertices: + # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of vertex positions for each object. + # list_of_dataset_names_facet_indices: + # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of facet indices for each object. + # list_of_dataset_names_properties: + # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of properties for each object. + + add_proxies_to_objects(NX_BOOLEAN): + doc: | + Specifies if, in the case of small finite datasets, objects which are + located at the edge of the dataset should be accounted for or not. + If these so-called proxy/doppelganger objects are accounted for, the + respective groupname_proxy and dataset_proxy fields have to be + filled to tell the tool where to load which proxy meshes from. + analyze_intersection(NX_BOOLEAN): + doc: | + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) intersect volumetrically. + analyze_proximity(NX_BOOLEAN): + doc: | + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) lie closer to one another than the + threshold_proximity. + analyze_coprecipitation(NX_BOOLEAN): + doc: | + Specifies if the tool evaluates, ones all tracking tasks were + successfully completed, how intersecting or proximity related + objects build sub-graphs. This is the feature which enabled + M. Kühbach et al. 2022 the high-throughput analyses of how many + objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order. For these analyses to work + has_object_volume needs to be activated. + threshold_proximity(NX_FLOAT): + doc: | + The maximum Euclidean distance between two objects below which + both objects are still considered within proximity. + unit: NX_LENGTH + # \@units: nm + has_current_to_next_links(NX_BOOLEAN): + doc: | + Specifies if the tool stores the so-called forward relations between + nodes representing members of the current_set to nodes representing + members of the next_set. + has_next_to_current_links(NX_BOOLEAN): + doc: | + Specifies if the tool stores the so-called backward relations between + nodes representing members of the next_set to nodes representing + members of the current_set. + + # ##MK::guru features tetrahedra volume intersection and tessellation, currently only supported through the C/C++ source code + # NEW ISSUE: correlating objects and then tessellating these to create three-dimensional renditions of the regions of intersections at the single ion level. This can be used to segment grain and phase boundary regions volumetrically as it is discussed in M. Kühbach et al. 2022, npj Computational Materials. + # analyze_intersection_volume(NX_BOOLEAN): + # doc: Specifies if the tool evaluates numerically the intersection volume between intersected objects. Demands tetrahedra_intersections to be set as the intersection_detection_method. As it is detailed in the supplementary material of M. Kühbach et al. 2022, npj Computational Materials, the computation uses an algorithm based on explicitly constructing intersecting NEF tetrahedra. This is currently an extremely time-consuming operation. + # analyze_tessellation(NX_BOOLEAN): + # doc: Specifies if the tool should tessellate a given region of the dataset. + # threshold_halo_width(NX_FLOAT): + # doc: The width of the halo region about an AABB bounding the set of target objects to tessellated. The to ensure that upon Voronoi tessellating the point cloud no cell of an object is incorrectly truncated by the boundaries of the local region cut out from the entire point cloud. + # dataset(NXprocess): + # filename: + # doc: Name of HDF5 file which stores reconstructed ion position and mass-to-charge-state ratios. Such an HDF5 file can store multiple reconstructions. Using an identifier (ID) is the mechanism which paraprobe uses to distinguish which specific reconstruction will be processed. With this design it is possible that the same HDF5 file stores multiple versions of a reconstruction of e.g. the same or different measured datasets, respectively. + # \@version: + # doc: Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of reproducibility from which file specifically contains these data. + # dataset_name_reconstruction: + # doc: Name of the dataset inside the HDF5 file which refers to the specific reconstructed ion positions to use for this analysis. + # dataset_name_mass_to_charge: + # doc: Name of the dataset inside the HDF5 file which refers to the specific mass-to-charge-state ratios to use for this analysis. + # iontypes(NXprocess): + # doc: Ranging definitions which were used to map mass-to-charge-state-ratio values and resulting iontype labels. + # filename: + # doc: Name of HDF5 file which stores ranging definitions which define how mass-to-charge ratios map map to iontypes and which iontypes are distinguished. The UNKNOWNTYPE iontype is the default iontype. The ID of this special iontype is always reserved as 0. Each ion is assigned to the UNKNOWNTYPE by default. Iontypes are assigned by checking if the mass-to-charge-state ratio of an ion matches to any of the defined mass-to-charge-state ratio intervals. + # \@version: + # doc: Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of reproducibility from which file specifically contains these data. + # group_name_iontypes: + # doc: Name of the group (prefix to the individual ranging definitions) inside the HDF5 file which refers to the ranging definition to use. A HDF5 file can store multiple ranging definitions. Using an ID is the mechanism to distinguish which specific ranging (version) will be processed. Reconstruction and ranging ID can differ. They specify different IDs. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml new file mode 100644 index 0000000000..07e82dfaf5 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml @@ -0,0 +1,872 @@ +category: application +doc: | + Configuration of a paraprobe-nanochem tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ityp_deloc_cand: How many iontypes does the delocalization filter specify. + n_control_pts: How many disjoint control points are defined. + n_fct_filter_cand: How many iontypes does the interface meshing iontype filter specify. + n_fct_iterations: How many DCOM iterations. + n_ivec: Maximum number of atoms per molecular ion. +NXapm_paraprobe_config_nanochem: + (NXentry): + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_nanochem] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + number_of_processes(NX_UINT): + doc: | + How many individual analyses should the tool execute as part of the analysis. + unit: NX_UNITLESS + + (NXprocess): + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + exists: required + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + + edge_of_the_dataset(NXprocess): + doc: | + The tool enables to inject a previously computed triangle soup or + triangulated surface mesh representing a model (of the surface) of + the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + # NEW ISSUE: exists: optional + filename: + doc: | + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the edge of the dataset. + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + dataset_name_vertices: + doc: | + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + dataset_name_facet_indices: + doc: | + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + + ion_to_edge_distances(NXprocess): + exists: optional + doc: | + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + # NEW ISSUE: is this optional? + filename: + doc: Name of an HDF5 file which contains the ion distances. + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + dataset_name: + doc: Absolute HDF5 path to the dataset with distance values for each ion. + + number_of_delocalizations(NX_UINT): + doc: | + For now a support field for the tool to identify how many individual + delocalization analyses for the above-mentioned dataset and supplementary + files are executed as part of the high-throughput analysis. + unit: NX_UNITLESS + delocalization(NXprocess): + # NEW ISSUE delocalization is all lower case meaning you cannot have right now multiple of these + # even though paraprobe-nanochem triggers a number of delocalizations for each of which triggering again isosurfaces + # currently the principal idea behind this design is that you normally focus iso-surface-based analyses + # on specific elements and for these you may have different discretization and isosurface computation demands + # for instance you might be super interested in analyzing in find details the iso-surfaces of carbon in a dataset + # but in addition you could be interested also to study chromium iso-surfaces but for completely different iso-contour values + # etc. this is what paraprobe-nanochem allows you to do + # you create one process for all your carbon related delocalizations, isosurfaces etc + # plus another process packing all your chromium delocalization and isosurfaces + exists: [min, 0, max, 1] + doc: Discretization of the ion point cloud on a three-dimensional grid. + input: + doc: | + Delocalization in the field of atom probe microscopy is the process + of discretizing a point cloud. By default the tool computes a full + kernel density estimation of decomposed ions to create one discretized + field for each element. + + Although, this uses an efficient multithreaded algorithm, + the computation is costly. Therefore, it can be advantageous for users + to load an already computed delocalization. This can be achieved with + the load_existent option. + When using this option the user is responsible to assure that the + settings which were used for computing this already existent delocalization + are specified in the same manner as they were. + # NEW ISSUE: improve UX experience + enumeration: [default, load_existent] + # NEW ISSUE: base class filter + isotope_whitelist(NX_UINT): + doc: | + Matrix of isotope vectors representing iontypes. + The filter specifies a matrix of isotope_vectors which is the most + general approach to define if and how many times an ion is counted. + Currently, paraprobe_nanochem performs a so-called atomic decomposition + of all iontypes. Specifically, the tool interprets of how many + elements/atoms a molecular ion is composed; and thus determines the + atoms multiplicity with respect to the iontype. + + Let's take the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore in an atomic + decomposition computation of the iso-surface each H3O+ ion adds + three hydrogen counts. This is a practical solution which accepts + the situation that during an atom probe experiment not each bond + of each ion/a group of neighboring atoms is broken but molecular + ions get detected. The exact ab-initio details depend on the local + field conditions and thus also the detailed spatial arrangement + of the atoms and their own electronic state and that of the neighbors + before and upon launch. + Being able to measure the information for such sites only as + molecular ions causes an inherent information loss with respect to the + detailed spatial arrangement. This information loss is more relevant + for local electrode atom probe than for field ion microscopy setting + how precisely the atomic positions can be reconstructed. + Accounting for multiplicities assures that at least the + compositional information is analyzed. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ityp_deloc_cand], [2, n_ivec]] + gridresolutions(NX_FLOAT): + doc: | + List of individual grid resolutions to analyse. + Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with + an edge length of values in gridresolutions. + unit: NX_LENGTH + # \@units: nm + kernel_size(NX_UINT): + doc: | + Half the width of a (2n+1)^3 cubic kernel of voxel beyond + which the Gaussian Ansatz function will be truncated. + Intensity beyond the kernel is refactored into the kernel via + a normalization procedure. + unit: NX_UNITLESS + kernel_variance(NX_FLOAT): + doc: | + Variance of the Gaussian Ansatz kernel sigma_x = sigma_y = 2*sigma_z. + unit: NX_LENGTH + # \@units: nm + normalization: + doc: | + How should the results of the kernel-density estimation be computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + enumeration: [total, candidates, composition, concentration] + has_scalar_fields(NX_BOOLEAN): + doc: | + Specifies if the tool should report the delocalization 3D field values. + # number_of_isosurfaces: + # doc: For now a support field for the tool to identify how many individual analyses the tool should execute during the analysis run. + # unit: NX_UNITLESS + + isosurfacing(NXprocess): + # NEW ISSUE: currently isosurface has to be a child of delocalization because otherwise + # you could construct the incorrect situation that you leave delocalization optional do not add sth there but fill isosurface + # and this does not work because without a delocalization/field quantity you cannot compute iso-surfaces + exists: [min, 0, max, 1] + doc: | + Optional computation of iso-surfaces after each computed delocalization + to identify for instance objects in the microstructure + (line features, interfaces, precipitates). + edge_handling_method: + doc: | + As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., + the handling of triangles at the edge of the dataset requires + special attention. Especially for composition-normalized + delocalization it is possible that the composition increases + towards the edge of the dataset because the quotient of two numbers + which are both smaller than one is larger instead of smaller than + the counter. By default, the tool uses a modified marching cubes + algorithm of Lewiner et al. which detects if voxels face such a + situation. In this case, no triangles are generated for such voxels. + Alternatively, (via setting keep_edge_triangles) the user can + instruct the tool to not remove these triangles at the cost of bias. + + Specifically, in this case the user should understand that all + objects/microstructural features in contact with the edge of the + dataset get usually artificial enlarged and their surface mesh + often closed during the marching. This closure however is artificial! + It can result in biased shape analyses for those objects. + The reason why this should in general be avoided is a similar + argument as when one analyzes grain shapes in orientation microscopy + via e.g. SEM/EBSD. Namely, these grains, here the objects at the + edge of the dataset, were not fully captured during e.g. limited + field of view. + Therefore, it is questionable if one would like to make + substantiated quantitative statements about them. + + Thanks to collaboration with the V. V. Rielli and S. Primig, though, + paraprobe-nanochem implements a complete pipeline to + process even these objects at the edge of the dataset. Specifically, + the objects are replaced by so-called proxies, i.e. replacement + objects whose holes on the surface mesh have been closed if possible + via iterative mesh and hole-filling procedures with fairing operations. + In the results of each paraprobe-nanochem run, these proxy objects + are listed separately to allow users to quantify and analyze in + detail the differences when accounting for these objects or not. + Especially this is relevant in atom probe microscopy are small + in the sense that they contain few (many a few dozen) objects. + Even though such a dataset may give statistically significant + results for compositions this does not mean it necessarily yields + also statistically significant and unbiased results for three-dimensional + object analyses. Being able to quantify these effects and making + atom probers aware of these subtleties was one of the main reasons + why the paraprobe-nanochem tool was implemented. + enumeration: [default, keep_edge_triangles] + edge_threshold(NX_FLOAT): + doc: | + The ion-to-edge-distance that is used in the analyses of objects + (and proxies) to identify whether these are inside the dataset or + close to the edge of the dataset. If an object has at least one ion + with an ion-to-edge-distance below this threshold, the object is + considered as one which lies close to the edge of the dataset. + This implements essentially a distance-based approach to solve + the in general complicated and involved treatment of computing + volumetric intersections between not-necessarily convex + closed 2-manifolds. In fact, such computational geometry analyses + can face numerical robustness issues as a consequence of which a + mesh can be detected as lying completely inside a dataset although + in reality it is epsilon-close only, i.e. almost touching only + the edge (e.g. from inside). + Practically, humans would state in such case that the object is + close to the edge of the dataset; however mathematically the object + is indeed completely inside. + In short, a distance-based approach is rigorous and more flexible. + unit: NX_LENGTH + # \@units: nm + phi(NX_FLOAT): + doc: | + Array of iso-contour values. For each value the tool computes + an iso-surface and performs subsequent analyses. + The unit depends on the choice for the normalization of the + accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + + unit: NX_ANY + # NEW ISSUE: details what these options activate need to be described in more detail !!!!! + has_triangle_soup(NX_BOOLEAN): + doc: | + Specifies if the tool should report the triangle soup which represents + each triangle of the iso-surface complex. + Each triangle is reported with an ID specifying to which triangle + cluster (with IDs starting at zero) the triangle belongs. + The clustering is performed with a modified DBScan algorithm. + has_object(NX_BOOLEAN): + doc: | + Specifies if the tool should analyze for each cluster of triangles + how they can be combinatorially processed to describe a closed + polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In fact, inaccuracies in the + reconstructed positions cause inaccuracies in all downstream + processing operations. Especially the effect on one-dimensional + spatial statistics like nearest neighbor correlation functions these + effects were discussed in the literature + `B. Gault et al. `_ + In continuation of these thoughts this applies also to reconstructed + objects. A well-known example is the discussion of shape deviations + of Al3Sc precipitates in aluminium alloys which in reconstructions + can appear as ellipsoids although they should be almost spherical, + depending on their size. + has_object_geometry(NX_BOOLEAN): + doc: | + Specifies if the tool should report a triangulated surface mesh + for each identified closed polyhedron. It is common that a + marching cubes algorithm creates iso-surfaces with a fraction of very + small sub-complexes (e.g. small isolated tetrahedra). + + These can be for instance be small tetrahedra/polyhedra about the + center of a voxel of the support grid on which marching cubes operates. + When these objects are small, it is possible that they contain no ion; + especially when considering that delocalization procedures smoothen + the positions of the ions. Although these small objects are interesting + from a numerical point of view, scientists may argue they are not worth + to be reported: + Physically a microstructural feature should contain at least a few + atoms to become relevant. Therefore, paraprobe-nanochem by default + does not report closed objects which bound not at least one ion. + has_object_properties(NX_BOOLEAN): + doc: | + Specifies if the tool should report properties of each closed + polyhedron, such as volume and other details. + has_object_obb(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each closed polyhedron an + approximately optimal bounding box fitted to all triangles of the + surface mesh of the object and ion positions inside or on the + surface of the mesh. + This bounding box informs about the closed object's shape + (aspect ratios). + # NEW ISSUE: Addendum Alternatively it is possible to fit triaxial ellipsoids. + has_object_ions(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each closed polyhedron + all evaporation IDs of those ions which lie inside or on the + boundary of the polyhedron. This information can be used e.g. + in the paraprobe-intersector tool to infer if two objects share + common ions, which can be interpreted as an argument to assume + that the two objects intersect. + + Users should be aware that two arbitrarily closed polyhedra + in three-dimensional space can intersect but not share a common ion. + In fact, the volume bounded by the polyhedron has sharp edges. + When taking two objects, an edge of one object may for instance + pierce into the surface of another object. In this case the + objects partially overlap / intersect volumetrically; + however this piercing might be so small or happening in the volume + between two ion positions and thus sharing ions is a sufficient + but not a necessary condition for object intersections. + + Paraprobe-intersector implements a rigorous alternative to handle + such intersections using a tetrahedralization of closed objects. + However, in many practical cases, we found through examples that there + are polyhedra (especially when they are non-convex and have almost + point-like) connected channels, where tetrahedralization libraries + have challenges dealing with. In this case checking intersections + via shared_ions is a more practical alternative. + has_object_edge_contact(NX_BOOLEAN): + doc: | + Specifies if the tool should report if a (closed) object has + contact with the edge of the dataset. For this the tool currently + inspects if the shortest distance between the set of triangles of the + surface mesh and the triangles of the edge model is larger than the + edge_threshold. If this is the case, the object is assumed to be + deeply embedded in the interior of the dataset. Otherwise, the object + is considered to have an edge contact, i.e. it is likely affected + by the fact that the dataset is finite. + # the edge_threshold can be decided based on half the length of the diagonal of the delocalization kernel. + # as a consequence of which wider kernels result in larger threshold values causing more objects to become + # qualified as having edge contact. + has_proxy(NX_BOOLEAN): + doc: | + Specifies if the tool should analyze a doppelganger/proxy mesh for + each cluster of triangles whose combinatorial analysis according + to has_object showed that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, + and fairing operations. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In most cases objects, + like precipitates in atom probe end up as open objects because + they have been clipped by the edge of the dataset. Using a proxy is + then a strategy to still be able to account for these objects. + Nevertheless users should make themselves familiar with the + potential consequences and biases which this can introduce + into the analysis. + has_proxy_geometry(NX_BOOLEAN): + doc: Like has_object_geometry but for the proxies. + has_proxy_properties(NX_BOOLEAN): + doc: Like has_object_properties but for the proxies. + has_proxy_obb(NX_BOOLEAN): + doc: Like has_object_obb but for the proxies. + has_proxy_ions(NX_BOOLEAN): + doc: Like has_object_ions but for the proxies. + has_proxy_edge_contact(NX_BOOLEAN): + doc: Like has_object_edge_contact but for the proxies. + has_object_auto_proxigram(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each closed object a + (cylindrical) region of interest placed, centered, and align + with the local normal for each triangle of the object. + has_object_auto_proxigram_edge_contact(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each ROI that was placed + at a triangle of each object if this ROI intersects the edge of + the dataset. Currently paraprobe-nanochem supports cylindrical + ROIs. A possible intersection of these with the edge of the + dataset, i.e. the triangulated surface mesh model for the edge + is performed. This test checks if the cylinder intersects with + a triangle of the surface mesh. If this is the case, the ROI is + assumed to make edge contact, else, the ROI is assumed to have + no edge contact. + + This approach does not work if the ROI would be completely + outside the dataset. Also in this case there would be + no intersection. For atom probe this case is practically + irrelevant because for such a ROI there would also be no ion + laying inside the ROI. Clearly it has thus to be assumed that + the edge model culls the entire dataset. Instead, if one would + cut a portion of the dataset, compute an edge model for this + point cloud, it might make sense to place a ROI but in this + case the edge contact detection is not expected to work properly. + # has_object_mesh_smoothing(NX_BOOLEAN): + # doc: Specifies if the tool should post-process each mesh to improve the mesh quality. + # mesh_smoothing(NXprocess): + # NEW ISSUE: here we need to specify how the meshes were smoothened + # ##MK::is this group not at the previous level of the hierarchy? + + interfacial_excess(NXprocess): + exists: optional + doc: Analyses of interfacial excess. + interface_model: + doc: | + Interfacial excess computations are performed for local regions-of-interests + (ROIs) at selected facets or interface patch. + For instance many scientist compute the interfacial excess for + selected triangle facets of a created iso-surface. In this case, + computed iso-surfaces of paraprobe could be used. An example are triangle + facet sets about closed polyhedra, for instance to compute interfacial + excess related to phase boundaries of second-phase precipitates. + + Another example are free-standing triangle patches of the iso- + surfaces which paraprobe creates. These could be characterized + for interfacial excess. The sub-routines during iso-surface + computations already include a procedure to automatically align + local triangle normals based on the gradients of e.g. composition + fields. In this case, these triangulated surface patches + could also be used as a source for computing interfacial + excess. + + Often scientists face situations, though, in which there is no + immediately evident composition gradient across the interface + (grain or phase boundary) and orientation information about the + adjoining crystal is neither available nor reliable enough. + + In this case `P. Felfer et al. `_ proposed a method + to manually place control points and run an automated tessellation-based + algorithm to create a triangulated surface patch, i.e. a model of the + location of the interface. In a post-processing step this triangle + set can then be used to compute again interfacial excess in an + automated manner by placing ROIs and aligning them with + consistently precomputed triangle normals. + + A similar use case is conceptually the one proposed by `X. Zhou et al. `_ + They used first a deep-learning method to locate planar triangulated + grain boundary patches. These are eventually processed further + with manual editing of the mesh via tools like Blender. + Once the user is satisfied with the mesh, the computations of interfacial + excess reduce again to an automated placing of ROIs, computations + of the distributing of ions to respective ROIs and + reporting the findings via plotting. + + Yet another approach for constructing an triangulated surface patch + of an interface is to use point cloud processing methods which have + been proposed in the laser-scanning, geoinformatics, and CAD community. + Different computational geometry methods are available for fitting + a parameterized surface to a set of points, using e.g. non-uniform + rational B-splines (NURBS) and triangulating these according + to prescribed mesh quality demands. + + The advantage of these methods is that they can be automated and + pick up curved interface segments. The disadvantage is their often + strong sensitivity to parameterization. As a result also such methods + can be post-processed to yield a triangulated surface patch, + and thus enable to run again automated ROI placement methods. + For example like these which were explored for the use case of + iso-surfaces with closed objects and free-standing + surface patches that delineate regions of the dataset with a + pronounced composition gradient normal to the interface. + + This summary of the situations which atom probers can face when + requesting for interfacial excess computations, substantiates there + exists a common set of settings which can describe all of these methods + and, specifically, as here exemplified, the automated placing + and alignment functionalities for ROIs that is an important + step all these workflows. + + Specifically, paraprobe-nanochem operates on an already existent + triangle set. + enumeration: [isosurface, external] + # NEW ISSUE: how to implement and also check consistently via NeXus that a + # NEW ISSUE: child group is required only when a field has a certain value? + external(NXprocess): + exists: optional + doc: | + The interface model is the result of a previous (set of) processing + steps as a result of which the user has created a triangulated + surface mesh (or a set of, eventually connected such meshes). + These interface models are useful, if not required, in cases when + there is no other independent approach to locate an interface. + + These are cases when insufficient crystallographic latent + information is available and also no consistent concentration + gradient detectable across the interface. It is then the users' + responsibility to deliver a triangle mesh of the interface model. + file_name: + doc: | + Filename to HDF5 file which contain vertex coordinates, facet indices, + facet unit normals. The user is responsible for the triangle + and winding order to be consistent. + Input is expected as a matrix of the coordinates for all disjoint + vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. + Input is expected to include also a matrix of facet indices + referring to these disjoint vertices. This matrix should be a + (Nfacets, 3)-shaped array of NX_UINT. Further required input + is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit + normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed + vertex unit normals. Vertex indices need to start at zero and + must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + dataset_name_vertices: + doc: | + Absolute HDF5 path to the dataset which specifies the + array of vertex positions. + dataset_name_facet_indices: + doc: | + Absolute HDF5 path to the dataset which specifies the + array of facet indices. + dataset_name_facet_normals: + doc: | + Absolute HDF5 path to the dataset which specifies the + array of facet signed unit normals. + dataset_name_facet_vertices: + doc: | + Absolute HDF5 path to the dataset which specifies the + array of vertex signed unit normals. + + Users should be aware that triangulated surface meshes are + only approximations to a given complex, eventually curved shape. + Consequently, computations of normals show differences between + the vertex and facet normals. Vertex normals have to be + interpolated from normals of neighboring facets. Consequently, + these normals are affected by the underlying parameterization + and curvature estimation algorithms, irrespective of how + contributions from neighboring facets are weighted. By contrast, + facet normals are clearly defined by the associated triangle. + Their disadvantage is that they the normal field has discontinuities + at the edges. In general the coarser an object is triangulated + the more significant the difference becomes between computations + based on facet or vertex normals. + Paraprobe-nanochem works with facet normals as it can use + parts of the numerical performance gained by using cutting + edge libraries to work rather with finer meshes. + + interface_meshing(NXprocess): + exists: [min, 0, max, 1] + doc: | + Create a simple principle component analysis (PCA) to mesh a + free-standing interface patch through a point cloud of decorating solutes. + These models can be useful for quantification of Gibbsian + interfacial excess for interfaces where iso-surface based methods + may fail or closed objects from iso-surfaces are not desired or + when e.g. there are no substantial or consistently oriented + concentration gradients across the interface patch. + + The interface_meshing functionality of paraprobe-nanochem can be useful + when there is also insufficient latent crystallographic information + available that could otherwise support modelling the interface, + via e.g. ion density traces in field-desorption maps, as were used and + discussed by `Y. Wei et al. `_ + or are discussed by `A. Breen et al. `_ + + It is noteworthy that the method here used is conceptually very similar + in implementation to the work by `Z. Peng et al. `_ + Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. + However, both of these previous works neither discuss in detail + nor implement inspection functionalities which enable a detection of + potential geometric inconsistencies or self-interactions of the + resulting DCOM mesh. This is what paraprobe-nanochem implements + via the Computational Geometry Algorithms Library. + initialization: + doc: | + Method how to initialize the PCA: + + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. + + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. `_ + to create a control_point_file which can be parsed by paraprobe-parmsetup + to match the here required formatting in control_points. + enumeration: [default, control_point_file] + filename: + doc: The name of the control point file to use. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + control_points(NX_FLOAT): + doc: | + X, Y, Z coordinates of disjoint control point read from + an HDF5 file named according to control_point_file. + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 2 + dim: [[1, N], [2, n_control_pts]] + method: + doc: | + Method used for identifying and refining the location of the + interface. Currently, paraprobe-nanochem implements a PCA followed + by an iterative loop of isotropic mesh refinement and DCOM step(s), + paired with self-intersection detection in a more robust + implementation. + enumeration: [pca_plus_dcom] + decorating_iontypes_filter(NXprocess): + doc: | + Specify the types of those ions which decorate the interface and + can thus be assumed as markers for locating the interface and + refining its local curvature. + candidates(NX_UINT): + doc: | + Array of iontypes to filter. The list is interpreted as a whitelist, + i.e. ions of these types are considered the decorating species (solutes). + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_fct_filter_cand]] + number_of_iterations(NX_UINT): + doc: How many times should the DCOM and mesh refinement be applied? + unit: NX_UNITLESS + target_edge_length(NX_FLOAT): + doc: | + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 1 + dim: [[1, n_fct_iterations]] + target_dcom_radius(NX_FLOAT): + doc: | + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within + which the DCOM algorithm decides for each vertex how the vertex will + be eventually relocated. The larger the DCOM radius is relative to + the target_edge_length the more likely it is that vertices will be + relocated so substantially that eventually triangle self-intersections + can occur. + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 1 + dim: [[1, n_fct_iterations]] + target_smoothing_step(NX_UINT): + doc: | + Array of integers which specify for each DCOM step how many times + the mesh should be iteratively smoothened. + + Users should be aware the three array target_edge_length, + target_dcom_radius, and target_smoothing_step are interpreted in the + same sequence, i.e. the zeroth entry of each array specifies the + values to be used in the first DCOM iteration. The first entry of + each array those for the second DCOM iteration and so on and so forth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_fct_iterations]] + + composition_profiling(NXprocess): + exists: [min, 0, max, 1] + doc: | + Functionalities for placing regions-of-interest (ROIs) in the dataset + or at specific microstructural features to characterize composition + profiles and cumulated profiles for quantification of interfacial excess. + Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed + across the triangulated surface of a user-defined mesh. + ROIs are placed at the barycenter of the triangular facet. + + The tool can be instructed to orient the profile for each ROIs with + the positive normal of the triangle facet normals. Profiles are + computed for each ROI and facet triangle. The code will test which + ROIs are completely embedded in the dataset. + Specifically, in this test the tool evaluates if the ROI cuts at least + one triangle of the triangulated surface mesh of the edge of the dataset. + If this is the case the ROI will be considered close to the edge + (of the dataset) and not analyzed further; else the ROI will be + processed further. + Users should be aware that the latter intersection analysis is strictly + speaking not a volumetric intersection analysis as such one is much + more involved because the edge model can be a closed non-convex polyhedron + in which case one would have to test robustly if the cylinder piercing + or laying completely inside the polyhedron. For this the polyhedron has + to be tessellated into convex polyhedra as otherwise tests like the + Gilbert-Johnson-Keerthi algorithm would not be applicable. + + Specifically, the tool computes atomically decomposed profiles. + This means molecular ions are split into atoms/isotopes with respective + multiplicity. As an example an H3O+ molecular ion contains three + hydrogen and one oxygen atom respectively. The tool then evaluates + how many ions are located inside the ROI or on the surface of the + ROI respectively. All atom types and the unranged ions are distinguished. + As a result, the analyses yield for each ROI a set of sorted lists of + signed distance values. Currently, the distance is the projected + distance of the ion position to the barycenter of the triangle + and triangle plane. + + This will return a one-dimensional profile. Post-processing the set + of atom-type-specific profiles into cumulated profiles enable the + classical Krakauer/Seidman-style interfacial excess analyses. + Furthermore, the tool can be instructed to compute for each + (or a selected sub-set of facet) a set of differently oriented profiles. + # In the second case, these profiles will be probed in the direction of + # the outer unit surface normal vectors of a sphere. The sphere is + # discretized via a geodesic sphere (according to ideas of M. Kühbach + # et al. Journal of Applied Crystallography 2021) model with 40962 + # directions, some of which are duplicates (for now). This direction + # sampling enables substantially more detailed analyses of the effect + # of aligning the ROI because alignments of ROI based on triangle + # surface normals of the feature mesh can result in larger direction + # differences between neighboring ROIs when the mesh for rough + # surface meshes. + feature_mesh(NXprocess): + doc: | + The feature mesh enables the injection of previously computed triangle + soup or mesh data. Such a mesh can be the model for a grain- or phase + boundary patch (from e.g. interface_meshing) jobs. + filename: + doc: | + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the feature. + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + dataset_name_vertices: + doc: | + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + dataset_name_facet_indices: + doc: | + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + dataset_name_facet_normals: + doc: | + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details consistently oriented facet + normals of the facets. + # dataset_name_vertex_normals: + # doc: Absolute path to the HDF5 dataset in the respective specified + # HDF5 file under filename which details consistently oriented + # vertex normals of the facets. + # exists: optional + ion_to_feature_distances(NXprocess): + exists: optional + doc: | + The tool enables to inject precomputed distance information for each + point which can be used for further post-processing and analysis. + # NEW ISSUE: is this optional? + filename: + doc: | + Name of an HDF5 file which contains ion distances. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically contains + these data. + dataset_name: + doc: | + Absolute HDF5 path to the dataset with distance values for each ion. + distancing_model: + doc: | + Which type of distance should be reported for the profile. + enumeration: [project_to_triangle_plane] + # NEW ISSUE:, ion_to_feature] + direction_model: + doc: In which directions should the tool probe for each ROI. + enumeration: [triangle_outer_unit_normal] + # NEW ISSUE:, angularly_geodesic_sphere] + roi_cylinder_height(NX_FLOAT): + doc: | + For each ROI, how high (projected on the cylinder axis) + should the cylindrical ROI be. + unit: NX_LENGTH + # \@units: nm + # all ROIs the same height + # dimensions: + # rank: 1 + # dim: [[1, 1]] + roi_cylinder_radius(NX_FLOAT): + doc: For each ROI, how wide (radius) should the cylindrical ROI be. + unit: NX_LENGTH + # \@units: nm + # all ROIs the same radius + # dimensions: + # rank: 1 + # dim: [[1, 1]] diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml new file mode 100644 index 0000000000..5029d16686 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml @@ -0,0 +1,221 @@ +category: application +doc: | + Configuration of a paraprobe-ranger tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_isotopes: The number of isotopes to consider as building blocks for searching molecular ions. + n_composition: The number of compositions to consider for molecular ion search tasks. +NXapm_paraprobe_config_ranger: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_ranger] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + number_of_processes(NX_UINT): + doc: How many task to perform? + unit: NX_UNITLESS + + (NXprocess): + exists: [min, 0, max, infty] + number_of_ranging_processes(NX_UINT): + doc: | + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. + unit: NX_UNITLESS + number_of_ion_search_processes(NX_UINT): + doc: | + How many molecular_ion_search processes should + the tool execute as part of the analysis. + unit: NX_UNITLESS + + range_with_existent_iontypes(NXprocess): + exists: [min, 0, max, 1] + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + exists: required + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + + molecular_ion_search(NXprocess): + exists: [min, 0, max, infty] + assumed_composition_isotopes(NX_UINT): + doc: | + A list of pairs of number of protons and either the value 0 (per row) + or the mass number for all those isotopes which are assumed present + in a virtual specimen. + The purpose of this field is to compute also composition-weighted + products to yield a simple estimation which could potentially help + scientists to judge if certain molecular ions are to be expected. + The corresponding setting store_composition_weighted_product should be + activated. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_composition], [2, 2]] + # assumed_composition_value(NX_FLOAT): + # doc: | + # A list of atomic (at.-%) ! percent values for the composition of each + # isotope in the virtual specimen following the sequence of + # assumed_composition_isotopes. + # unit: NX_DIMENSIONLESS + # dimensions: + # rank: 1 + # dim: [[1, n_compositions]] + isotope_whitelist(NX_UINT): + doc: | + A list of pairs of number of protons and mass number for all isotopes + to consider that can be composed into (molecular) ions, during the + recursive molecular_ion_search. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_isotopes], [2, 2]] + mass_to_charge_interval(NX_FLOAT): + doc: | + The mass-to-charge-state ratio interval in which + all molecular ions are searched. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, 2]] + maximum_charge(NX_UINT): + doc: The maximum charge that a molecular ion should have. + unit: NX_UNITLESS + maximum_number_of_isotopes(NX_UINT): + doc: | + The maximum number of isotopes of which the molecular ion + should be composed. Currently this must not be larger than 32. + + Users should be warned that the larger the maximum_charge and + especially the larger the maximum_number_of_isotopes is chosen, + the eventually orders of magnitude more costly the search becomes. + + This is because paraprobe-ranger computes really all (at least) + theoretically possible combinations that would have likely a + mass-to-charge-state ratio in the specified mass_to_charge_interval. + It is the challenge in atom probe to judge which of these (molecular) + ions are feasible and also practically possible. This tool does not + answer this question. + + Namely, which specific molecular ion will evaporate, remain stable + during flight and becomes detected is a complicated and in many cases + not yet in detail understood phenomenon. The ab-initio conditions + before and during launch, the local environment, arrangement and field + as well as the flight phase in an evacuated but not analysis chamber + with a complex electrical field, eventual laser pulsing in place, + temperature and remaining atoms or molecules all can have an effect + which iontypes are really physically evaporating and detected. + unit: NX_UNITLESS + store_atomic_mass_sum(NX_BOOLEAN): + doc: | + Report the accumulated atomic mass from each isotope building the ion. + Accounts for each identified ion. + Relatistic effects are not accounted for. + store_natural_abundance_product(NX_BOOLEAN): + doc: | + Report the product of the natural abundances from each isotope building + the ion. Accounts for each identified ion. + + The value zero indicates it is not possible to build such molecular ion + from nuclids which are all observationally stable. + Very small values can give an idea/about how likely such a molecular ion + is expected to form assuming equal probabilities. + + However in atom probe experiments this product has to be modified + by the (spatially-correlated) local composition in the region from + which the ions launch because the formation of a molecular ion depends + as summarized under maximum_number_of_isotopes on the specific + quantum-mechanical configuration and field state upon launch + or/and (early state) of flight respectively. + We are aware that this modified product can have a substantially + different value than the natural_abundance_product. + + Natural abundancies folded with the estimated compositions of the + specimen can differ by orders of magnitude. + # add assumed composition of the specimen + # store_composition_weighted_product(NX_BOOLEAN): + # doc: | + # Report the product of the composition from each isotope building the + # ion. This sets strong constraints on the molecular ions which are + # expected to have at all a noteworthy product value. + # It should not be forgotten though the computation relies on assumptions: + # + # * The composition is homogeneous within the virtual specimen. + # * It is a priori know which nuclids the specimen is build of. + # + store_charge_state(NX_BOOLEAN): + doc: | + Report the charge state of the ions. + store_disjoint_isotopes(NX_BOOLEAN): + doc: | + Report if identified ions should be characterized + wrt to their number of disjoint isotopes. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml new file mode 100644 index 0000000000..e825b4216a --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml @@ -0,0 +1,220 @@ +category: application +doc: | + Configuration of a paraprobe-spatstat tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ivecmax: Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + n_ion_source: Number of different sources iontypes to distinguish. + n_ion_target: Number of different target iontypes to distinguish. +NXapm_paraprobe_config_spatstat: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_spatstat] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + number_of_processes(NX_UINT): + doc: | + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. + unit: NX_UNITLESS + spatial_statistics(NXprocess): + exists: [min, 0, max, 1] + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + exists: required + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + + ion_to_edge_distances(NXprocess): + doc: | + The tool enables to inject precomputed distances of each ion to a + representation of the edge of the dataset which can be used to + control and substantially reduce edge effects when computing spatial statistics. + exists: optional + filename: + doc: | + Name of an HDF5 file which contains ion-to-edge distances. + dataset_name_distances: + doc: | + Absolute HDF5 path to the dataset with the + ion-to-edge distance values for each ion. + The shape of the distance values has to match the length + of the ion positions array in dataset/dataset_name_reconstruction + and dataset_name_mass_to_charge respectively. + ion_to_feature_distances(NXprocess): + doc: | + In addition to spatial filtering, and considering how far ions lie + to the edge of the dataset, it is possible to restrict the analyses + to a sub-set of ions within a distance not farther away to a feature than + a threshold value. + # which is this threshold value + exists: optional + # NEW ISSUE: is this optional? + filename: + doc: | + Name of an HDF5 file which contains ion-to-feature distances. + dataset_name_distances: + doc: | + Absolute HDF5 path to the dataset with the + ion-to-feature distance values for each ion. + + randomize_labels(NX_BOOLEAN): + doc: | + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + random_number_generator(NXcs_prng): + exists: recommended + type: + seed(NX_NUMBER): + warmup(NX_NUMBER): + ion_query_type_source: + doc: | + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + ion_query_isotope_vector_source(NX_UINT): + doc: | + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ion_source], [2, n_ivecmax]] + ion_query_type_target: + doc: | + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + # NEW ISSUE: conditionally required only when resolve_isotope + ion_query_isotope_vector_target(NX_UINT): + doc: | + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ion_target], [2, n_ivecmax]] + statistics(NXprocess): + doc: | + Specifies which spatial statistics to compute. + knn(NXcollection): + doc: Compute k-th nearest neighbour statistics. + exists: optional + nth(NX_UINT): + doc: Order k. + unit: NX_UNITLESS + histogram_min_incr_max(NX_FLOAT): + doc: | + Minimum value, increment, and maximum value of the histogram binning. + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 1 + dim: [[1, 3]] + # NEW ISSUE: rdf(NXcollection): + # NEW ISSUE: ripleyk(NXcollection): + # NEW ISSUE: two_point(NXcollection): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml new file mode 100644 index 0000000000..d71a9684a4 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml @@ -0,0 +1,175 @@ +category: application +doc: | + Configuration of a paraprobe-surfacer tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_alpha_values: Number of alpha values (and offset values) to probe. +NXapm_paraprobe_config_surfacer: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_surfacer] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + number_of_processes(NX_UINT): + doc: | + For now a support field for the tool to identify how many individual + analyses the tool should executed as part of the analysis. + unit: NX_UNITLESS + (NXprocess): + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + exists: required + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + + surface_meshing(NXprocess): + preprocessing_method: + doc: | + Specifies the method that is used to preprocess the point cloud. + The main purpose of this setting is to specify whether the point + cloud should be segmented or not during the preprocessing + to identify which points are more likely lying close to the edge + of the point cloud. These points could be more relevant than the + interior points for certain alpha-shape constructions. + + By default no such filtering is used during pre-processing. + By contrast, the option kuehbach activates a preprocessing + during which a Hoshen-Kopelman percolation analysis is used + to identify which points are closer to the edge of the dataset. + This can reduce the number of points in the alpha-shape + computation and thus improve performance substantially. + Details about the methods are reported in + `M. Kühbach et al. `_. + enumeration: [default, kuehbach] + preprocessing_kernel_width(NX_UINT): + # the exists is dependant on the value for preprocessing_method + doc: | + When using the kuehbach preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. + unit: NX_UNITLESS + alpha_value_choice: + doc: | + Specifies which method to use to define the alpha value. + By default, the tool uses a fast specialized algorithm for + computing only the convex hull. + + The value smallest_solid instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value cgal_optimal instructs the library to choose a value + which the library considers as an optimal value. Details are + define in the respective section of the CGAL library on 3D alpha + shapes. + + The value set_of_values instructs to compute a list of + alpha-shapes for the specified alpha-values. + + The value set_of_alpha_wrappings instructs the library to generate + a set of so-called alpha wrappings. These are a method + which is similar to alpha shapes but provide additional guarantees + though such as watertightness and proximity constraints on the + resulting wrapping. + # NEW ISSUE: further details CGAL documentation + enumeration: [fast_convex_hull, smallest_solid, cgal_optimal, set_of_values, set_of_alpha_wrappings] + alpha_values(NX_FLOAT): + doc: | + Array of alpha values to use when alpha_value_choice is set_of_values + or when alpha_value_choice is set_of_alpha_wrappings. + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 1 + dim: [[1, n_alpha_values]] + offset_values(NX_FLOAT): + doc: | + Array of offset values to use when alpha_value_choice is + set_of_alpha_wrappings. The array of alpha_values and offset_values + define a sequence of (alpha and offset value). + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 1 + dim: [[1, n_alpha_values]] + has_exterior_facets(NX_BOOLEAN): + doc: | + Specifies if the tool should compute the set of exterior triangle + facets for each alpha complex (for convex hull, alpha shapes, and wrappings) + has_closure(NX_BOOLEAN): + doc: | + Specifies if the tool should check if the alpha complex of exterior + triangular facets is a closed polyhedron. + has_interior_tetrahedra(NX_BOOLEAN): + doc: | + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). + # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml new file mode 100644 index 0000000000..4df2dd0bb3 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml @@ -0,0 +1,180 @@ +category: application +doc: | + Configuration of a paraprobe-tessellator tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + # n_control_points: The number of control points for tessellating regions instead of tessellating the volume about ion positions. +NXapm_paraprobe_config_tessellator: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_tessellator] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + number_of_processes(NX_UINT): + doc: | + How many individual analyses should the tool execute. + unit: NX_UNITLESS + (NXprocess): + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + exists: required + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + # a perfect example for limited conditions in NeXus + # if windowing_method is entire_dataset: no constraint on existence of NXcg and NXcs instances + # if windowing_method is union_of_primitives: sum of cardinality of NXcg >= 0 + # if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardinality of NXcs_filter_boolean_mask == 1 + + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + + ion_to_edge_distances(NXprocess): + exists: optional + doc: | + The tool enables to inject precomputed distance information for + each point which can be used for further post-processing and analysis. + filename: + doc: | + Name of an HDF5 file which contains the ion distances. + Users are responsible this file and referred to dataset under + dataset_name have an ion_distance value for each ion. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional layer of + reproducibility. + dataset_name: + doc: | + Absolute HDF5 path to the dataset with distance values for each ion. + tessellating(NXprocess): + method: + doc: | + Specifies for which points the tool will compute the tessellation. + By default, a Voronoi tessellation is computed for all ions in the + filtered point cloud. + # The value control_points will compute the tessellation for the + # provided overlay_control_points irregardless of the ion point cloud. + # This enables for instance computations as proposed by P. Felfer and + # coworkers where, for the purpose of e.g. interfacial excess quantification, + # a tessellation of the dataset into regions about manually-specified + # control points is needed. + # For this option, the overlay_control points. + enumeration: [default] #, control_points] + # overlay_control_points(NXprocess): + # doc: | + # Overlaying an additional set of control points onto the reconstruction + # can be used as a first step to construct a tessellation of the dataset + # into regions to segment the dataset or construct a model for internal + # structural features in the dataset. Such an approach was suggested + # e.g. by P. Felfer et al. which use a control points to locate + # interfaces (grain/phase boundaries) in atom probe data to perform + # e.g. interfacial excess computations. The control points can be + # imported for example from some manual preprocessing of a dataset + # where the user figured these control points could be of relevance + # for the analysis. + # # NEW ISSUE: dislocation lines + # exists: optional + # filename: + # doc: | + # Name of an HDF5 file which contains control point coordinates. + # \@version: + # doc: | + # Version identifier of the file such as a secure hash which + # documents the binary state of the file to add an additional + # layer of reproducibility. + # dataset_name: + # doc: | + # Absolute HDF5 path to the dataset which contains the array of + # control points. This has to be an array of shape + # (n_control_points, 3). + has_cell_volume(NX_BOOLEAN): + doc: | + Specifies if the tool should report the volume of each cell. + has_cell_neighbors(NX_BOOLEAN): + doc: | + Specifies if the tool should report the first-order neighbors of each cell. + has_cell_geometry(NX_BOOLEAN): + doc: | + Specifies if the tool should report the facets and vertices of each cell. + has_cell_edge_detection(NX_BOOLEAN): + doc: | + Specifies if the tool should report if the cell makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + by the presence of the boundary. + erosion_distance(NX_FLOAT): + doc: | + Maximum distance for which cells are eroded. + # ##MK::needs further details + unit: NX_LENGTH + # \@units: nm + # minValue: EPSILON diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml new file mode 100644 index 0000000000..cbcb566f96 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml @@ -0,0 +1,62 @@ +category: application +doc: | + Configurations of a paraprobe-transcoder tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXapm_paraprobe_config_transcoder: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_transcoder] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + (NXprocess): + dataset(NXapm_input_reconstruction): + filename: + doc: | + The absolute path and name of the vendor or community file from which + to read the reconstructed ion positions. Currently POS, ePOS, and APT + files from APSuite are supported. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + iontypes(NXapm_input_ranging): + filename: + doc: | + The absolute path and name of the vendor or community file from which + to read the ranging definitions, i.e. how to map mass-to-charge-state + ratios on iontypes. Currently RRNG and RNG files are supported. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml new file mode 100644 index 0000000000..b40032b3d7 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml @@ -0,0 +1,282 @@ +category: application +doc: | + Results of a paraprobe-ranger tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: The total number of ions in the reconstruction. + n_ivec: The maximum number of atoms per molecular ion type. +NXapm_paraprobe_results_ranger: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_ranger] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: Details about the coordinate system conventions used. + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which used. + fields should be prefixed with a prefix taken from an + enumeration which details the individual coordinate systems: + + * lab + * specimen + * laser + * leap + * detector + * recon + + +# ##MK::begin of the tool-specific section + (NXprocess): + exists: [min, 0, max, 1] + # ##MK::number_of_ion_types(NX_POSINT): + # ##MK::maximum_number_of_atoms_per_molecular_ion(NX_POSINT): + use_existent_ranging(NXprocess): + exists: [min, 0, max, 1] + doc: | + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on none, the + ion is considered of the default unknown type with a 0 as its + respective value in the iontypes array. + (NXion): + exists: [min, 1, max, 256] + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + exists: recommended + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): + iontypes(NX_UINT): + doc: | + The iontype ID for each ion that was best matching, stored in the + order of the evaporation sequence ID. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + + molecular_ion_search(NXprocess): + exists: [min, 0, max, 1] + doc: | + Paraprobe-ranger performs a combinatorial search over + all possible or a reduced set of nuclids to identify + into which ions these can be composed. + isotope_vector_matrix(NX_UINT): + doc: | + The main result is the list of molecular ions, here formatted + according to the definitions of a set of isotope_vectors + as detailed in :ref:`NXion`. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, i], [2, 32]] + mass_to_charge_state_ratio(NX_FLOAT): + doc: | + The mass-to-charge-state ratio of each molecular ion + without considering relativistic or quantum effects. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, i]] + mass(NX_FLOAT): + exists: optional + doc: | + The mass of each molecular ion without + considering relativistic or quantum effects. + unit: NX_ANY + # \@units: amu + dimensions: + rank: 1 + dim: [[1, i]] + charge_state(NX_UINT): + doc: | + The charge_state of each molecular ion. + unit: NX_CHARGE + dimensions: + rank: 1 + dim: [[1, i]] + natural_abundance_product(NX_FLOAT): + exists: optional + doc: | + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, i]] + composition_product(NX_FLOAT): + exists: optional + doc: | + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, i]] + number_of_disjoint_nuclids(NX_POSINT): + exists: optional + doc: | + The number of disjoint nuclids for each molecular ion. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + number_of_nuclids(NX_POSINT): + exists: optional + doc: | + The number of nuclids for each molecular ion. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] +# ##MK::end of the tool-specific section + + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml new file mode 100644 index 0000000000..beae6f6a71 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml @@ -0,0 +1,395 @@ +category: application +doc: | + Results of a paraprobe-transcoder tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: Total number of ions collected. + n_ivec_max: | + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + n_ranges: Number of mass-to-charge-state-ratio intervals mapped on this ion type. + n_topology: Total number of integers in the supplementary XDMF topology array. +NXapm_paraprobe_results_transcoder: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_transcoder] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: Details about the coordinate system conventions used. + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon +# ##MK::begin of the tool-specific section + visualization(NXprocess): + exists: recommended + xdmf_topology(NX_UINT): + exists: required + doc: | + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_topology]] + # n_topology == 3*n_ions + # not in all cases a PARAPROBE.Transcoder.Results.SimID..h5 is required + # namely when an NXapm-compliant NeXus file is directly used for interacting + # with paraprobe tools in all other cases, the PARAPROBE.Transcoder.Results + # file will get an *.nxs file ending + # the original proposal + # results(NXprocess): + # exists: [min, 1, max, 1] + # doc: | + # Paraprobe-transcoder prepares the data in POS, ePOS, APT files from + # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can + # be used with the tools of the paraprobe-toolbox. + # reconstruction(NXcg_point_set): + # dimensionality(NX_POSINT): + # cardinality(NX_POSINT): + # identifier_offset(NX_INT): + # position(NX_NUMBER): + # # ##MK::number_of_ion_types(NX_POSINT): + # # ##MK::maximum_number_of_atoms_per_molecular_ion(NX_POSINT): + # ranging(NXcollection): + # exists: [min, 1, max, 256] + # doc: | + # This is the collection of iontypes distinguished. + # The default unknown iontype always has to map to 0. + # Its non-physical mass_to_charge_state_ratio is [0., 0.001] Da. + # ion_type(NX_UINT): + # exists: optional + # isotope_vector(NX_UINT): + # nuclid_list(NX_UINT): + # exists: recommended + # charge_state(NX_INT): + # name: + # exists: optional + # mass_to_charge_range(NX_FLOAT): + # the key problem still for apm is people use different formats + # when people would like to use paraprobe without nomad and pos, epos, apt + # rrng and rng files the data have to be transcoded, this is the main + # reason for having the transcoder however, when you already have an NXapm + # file (like) in nomad, why should we create yet another format here the + # transcoder is not needed + # namely take e.g. paraprobe-nanochem all it needs to know is the place of + # an HDF5 file where the nanochem tool knows there will be groups in this file + # with entry/atom_probe/reconstruction/reconstructed_positions + # and entry/atom_probe/ranging/peak_identification and a set of NXion + # this suggest the need for three fundamental changes: + # if transcoder config gets an nxs file as input it just checks if + # the above-mentioned groups are available, if yes it accepts and + # guides that no transcoding is needed any longer + # if transcoder config gets other files it creates the above-mentioned + # groups in different places than it does currently + # convenience functions of tools have to be changed in the following way: + # you hunt for PARAPROBE.Transcoder.Config.SimID..h5 + # if the references to dataset files there end with nxs you know + # data are in an NXapm so reconstruction will be in + # entry/atom_probe/reconstruction/reconstructed_positions + # ranging will be in + # entry/atom_probe/ranging/peak_identification + # however if the references to dataset files there end with != nxs + # you point the tool to in fact data inside PARAPROBE.Transcoder.Results + # because in this case transcoding was necessary but also then you + # will find the data in entry/atom_probe/.. respectively + # alternatively: + atom_probe(NXinstrument): + doc: | + On a mid term perspective we would like to evolve the paraprobe-toolbox + to an implementation stage where it works exclusively with completely + provenance-tracked formats for both the configuration of the workflow step + and/or analysis with each tool and also for the output of these analyses + in the form of so-called tool-specific results files. + Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. + + Different file formats can be used to inject reconstructed datasets and + ranging definitions into the toolbox. Traditionally, these are the POS, + ePOS, and APT files with the tomographic reconstruction and other metadata + and RNG and RRNG file formats for the ranging definitions how mass-to-charge + state-ratio values map on (molecular) ion types. Such input should be + injected via specific NeXus/HDF5 files which are documented + in compliance with the NXapm application definition. + + So far the paraprobe-toolbox was used as a standalone tool. Therefore, it + was not relevant during the development to focus on interoperability. + Essentially paraprobe-transcoder was used as a parser to transcode data + in the above-mentioned file formats into a paraprobe-specific + representation. This transcoding should become deprecated. + Here we describe steps we have taken into this direction. + + With the work in the FAIRmat project and the desire to make the paraprobe- + toolbox also accessible as a cloud-computing capable service in the Nomad + Remote Tools Hub (NORTH) the topic of interoperability became more important + and eventually the NXapm application definition was proposed. + NORTH is a GUI and related service in a NOMAD OASIS instance which allows + to spawn preconfigured docker containers via JupyterHub. + Currently, NORTH includes the so-called apm container. A container with + tools specific for analyzing data from atom probe microscopy as well as + processing of point cloud and mesh data. + + The NXapm application definition and related implementation work within + NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and + RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook + solutions directly into NOMAD OASIS via the uploads section. + The process is automated and yields an NXapm-compliant NeXus/HDF5 file + inside the uploads section in return. + + With these improvements made there is no longer a need for - at least the + users of a NOMAD OASIS and NORTH instance to use the deprecated + PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should + automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 + file and in response work with this file directly. + To remain compliant with users however who do not have or do not wish + to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is + as follows: + + Calling the configuration stage of paraprobe-transcoder is always mandatory. + It is always the first step of working with the toolbox. In this process + the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ + HDF5 file from e.g. the upload section, or such a file that was obtained from + a colleague with a NOMAD OASIS instance. + In all other cases, users can pass the reconstruction and ranging definitions + using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. + + Based on which input the user delivers, the parmsetup-transcoder tool then + creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and + informs the user whether the input was NeXus (and thus if all relevant + input is already available) or whether the paraprobe-transcoder tool needs + to be executed to convert the content of the vendor files first into a + format which paraprobe can provenance track and understand. + In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is + used to communicate to all subsequently used tools from which files + the tools can expect to find the reconstruction and ranging definitions. + + All subsequent analysis steps start also with a tool-specific configuration. + This configuration step reads in (among others) the + PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration + tool identifies automatically whether to read the reconstruction and ranging data + from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant + NeXus/HDF5 file that was created upon preparing the upload or the file shared + from a colleague. This design removes the need for unnecessary copies of the data. + Currently still though users should execute the transcoder step as it will + generate a supplementary XDMF topology field with which the data in either + the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. + Paraview. For this purpose XDMF is used. + + Of course ideally the APT community would at some point converge to use + a common data exchange file format. To this end, AMETEK/Cameca's APT file format + could be a good starting point but so far it is lacking a consistent way of + how to store generalized ranging definitions and post-processing results. + POS, ePOS, Rouen's ATO, as well as other so far used representations of data + like CSV or text files have, to the best of our current knowledge, no + concept of how to marry reconstruction and (optional) ranging data into + one self-descriptive format. + + This summarizes the rationale behind the current choices of the I/O for + paraprobe. Furthermore, this summarizes also why the fundamental design + of splitting an analysis always into steps of configuration (with parmsetup), + task execution (with the respective C/C++ or Python tool of the toolbox), + and post-processing (e.g. with autoreporter) is useful because it offers + a clear description of provenance tracking. This is a necessary step to make + atom probe microscopy data at all better aligned with the aims of the + FAIR principles. + + The internal organization of the data entries in the atom_probe group + in this application definition for paraprobe-transcoder results files + mirror the definitions of the NXapm for consistency reasons. + # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can + # be used with the tools of the paraprobe-toolbox. + mass_to_charge_conversion(NXprocess): + mass_to_charge(NX_FLOAT): + doc: | + Mass-to-charge-state ratio values. + unit: NX_ANY + # \@units: Da + dimensions: + rank: 1 + dim: [[1, n_ions]] + reconstruction(NXprocess): + # number_of_ions(NX_UINT): + # doc: | + # For now still a support field to store the total number of ions in the + # dataset. This field will become deprecated when the new HDF5 I/O routines + # come in place which detect the metadata to an entry automatically. + # For now has to be the same value as n_ions. + reconstructed_positions(NX_FLOAT): + doc: | + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_ions], [2, 3]] + ranging(NXprocess): + peak_identification(NXprocess): + doc: | + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + (NXion): + exists: [min, 1, max, 256] + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + exists: recommended + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): +# ##MK::end of the tool-specific section + + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXatom_set.yaml b/contributed_definitions/nyaml/NXatom_set.yaml new file mode 100644 index 0000000000..02c5385e91 --- /dev/null +++ b/contributed_definitions/nyaml/NXatom_set.yaml @@ -0,0 +1,12 @@ +category: base +doc: | + A base class to wrap details about a spatial configuration of atoms. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXatom_set: + (NXcg_point_set): + doc: Atom positions. + # the application-definition specific NXcg_point_set instance + # should be extended then by a field type(NX_UINT): + # we need a case-dependent discussion with e.g. Joseph, Nathan, and Luca + # on time-tracking of atom sets diff --git a/contributed_definitions/nyaml/NXcalibration.yml b/contributed_definitions/nyaml/NXcalibration.yml new file mode 100644 index 0000000000..d32250c66b --- /dev/null +++ b/contributed_definitions/nyaml/NXcalibration.yml @@ -0,0 +1,51 @@ +category: base +symbols: + doc: "The symbols used in the schema to specify e.g. dimensions of arrays" + ncoeff: "Number of coefficients of the calibration function" + nfeat: "Number of features used to fit the calibration function" + ncal: "Number of points of the calibrated and uncalibrated axes" +doc: "Subclass of NXprocess to describe post-processing calibrations." +(NXcalibration): + last_process(NX_CHAR): + doc: "Indicates the name of the last operation applied in the NXprocess sequence." + applied(NX_BOOLEAN): + doc: "Has the calibration been applied?" + coefficients(NX_FLOAT): + doc: + "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." + unit: NX_ANY + dimensions: + dim: [[1, ncoeff]] + rank: 1 + fit_function(NX_CHAR): + doc: | + 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. + scaling(NX_FLOAT): + doc: "For linear calibration. Scaling parameter." + unit: NX_ANY + offset(NX_FLOAT): + doc: "For linear calibration. Offset parameter." + unit: NX_ANY + calibrated_axis(NX_FLOAT): + doc: "A vector representing the axis after calibration, matching the data length" + unit: NX_ANY + dimensions: + dim: [[1, ncal]] + rank: 1 + original_axis(NX_FLOAT): + doc: "Vector containing the data coordinates in the original uncalibrated axis" + unit: NX_ANY + dimensions: + dim: [[1, ncal]] + rank: 1 + description(NX_CHAR): + doc: "A description of the procedures employed." diff --git a/contributed_definitions/nyaml/NXcg_alpha_shape.yaml b/contributed_definitions/nyaml/NXcg_alpha_shape.yaml new file mode 100644 index 0000000000..88a5c2929b --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_alpha_shape.yaml @@ -0,0 +1,83 @@ +category: base +doc: | + Computational geometry description of alpha shapes or wrappings to primitives. + + For details see: + + * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, + * https://dx.doi.org/10.1145/174462.156635 for 3D, + * https://dl.acm.org/doi/10.5555/871114 for weighted, and + * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap + + in CGAL, the Computational Geometry Algorithms Library. + As a starting point, we follow the conventions of the CGAL library. +# weighted alpha shapes +# The so-called spectrum or sets of (weighted) alpha shapes includes the +# convex hull of a point set. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality of the alpha shape, for now 2 or 3. + # generalize to d > 3 + n_e: The number of edges. + n_f: The number of faces. + n_c: The number of cells. +NXcg_alpha_shape: + dimensionality(NX_UINT): + unit: NX_UNITLESS + enumeration: [2, 3] + version: + doc: | + Specify which general type of alpha shape is computed. + Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. + Alpha_wrapping means meshes created using alpha wrapping procedures. + enumeration: [basic, alpha_wrapping] # , weighted] + mode: + doc: | + Specifically when computed with the CGAL, the mode specifies if singular + faces are removed (regularized) of the alpha complex. + # CHECK THIS AGAIN CAREFULLY + enumeration: [general, regularized] + alpha(NX_NUMBER): + doc: | + The alpha, (radius of the alpha-sphere) parameter to be used for alpha + shapes and alpha wrappings. + unit: NX_LENGTH + offset(NX_NUMBER): + doc: | + The offset distance parameter to be used in addition to alpha + in the case of alpha_wrapping. + unit: NX_LENGTH + # check again carefully the CGAL documentation talks about, for 3D, the square of the radius! + s(NXcg_point_set): + doc: Point cloud for which the alpha shape or wrapping should be computed. + # this could also just be implemented as a link but how would this be possible + # unfold the NXcg_point_set and add a + # weight(NX_NUMBER): + # doc: Weights for each point + # In general, an alpha complex is a disconnected and non-pure complex, + # meaning in particular that the alpha complex may have singular faces. + # so the number of cells, faces and edges depends on how a specific alpha complex, + # i.e. an alpha-shape of S for alpha, is filtrated with respect to k < d-dimensional + # simplices. Here we assume that number_of_cells, number_of_faces, number_of_edges + # are reported assuming one filtrates these simplices according to mode. + # also using the assumption the base class reports the unique vertices + # of the specifically filtrated alpha complex. + t(NXcg_triangle_set): + doc: Triangle soup for which the alpha wrapping should be computed. + triangulation(NXcg_triangle_set): + doc: A meshed representation of the resulting shape. + # should be a mesh + # add for each triangle if desirable a notation of whether the simplex is + # exterior, regular, singular, or interior with respect to the alpha complex + # but a triangulation is more than a triangle (soup)/set because there is + # connectivity information + # customize the NXcg_triangle_set base class members such that connectivity + # information is contained + # we need to find also a better name for this, what people intutive understand + # as the interior, may not even exist for a given alpha value + # more specifically it is the set of filtrated cells acknowledging mode + # e.g. the interior cells of the regularized alpha complex + interior_cells(NXcg_tetrahedron_set): + # document the alpha status + # https://doc.cgal.org/latest/Alpha_shapes_3/classCGAL_1_1Alpha__status.html diff --git a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml new file mode 100644 index 0000000000..f96547014e --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml @@ -0,0 +1,112 @@ +# redundant as there is NXcsg, NXquadric, NXsolid_geometry with which +# cylinder could be constructed, but NXcylinder is easier to understand +category: base +doc: | + Computational geometry description of a set of cylinders in Euclidean space. + + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + c: The cardinality of the set, i.e. the number of cylinders or cones. +NXcg_cylinder_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish members for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + doc: | + The geometric center of each member. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + height(NX_NUMBER): + doc: | + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + # alternatively one could store the center of the lower and upper cap but + # these are then no longer necessarily on the same axis + # maybe a future feature for representing skewed cylinder, but then + # one should really better use NXquadric... + radii(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + upper_cap_radius(NX_NUMBER): + doc: | + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + lower_cap_radius(NX_NUMBER): + doc: | + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + # properties of the cylinder + volume(NX_NUMBER): + doc: Interior volume of each cylinder + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, c]] + lateral_surface_area(NX_NUMBER): + doc: Lateral surface area + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + cap_surface_area(NX_NUMBER): + doc: Area of the upper and the lower cap of each cylinder respectively. + unit: NX_AREA + dimensions: + rank: 2 + dim: [[1, c], [2, 2]] + surface_area(NX_NUMBER): + doc: Cap and lateral surface area for each cylinder. + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] +# again cap, lateral surface area and volume are so trivial to compute +# do we need really storage for this or recompute on-the-fly? +# similarly to hollow sphere discussion, hollow cylinder, cylinder stack +# do wish to define intersections?, if this is the case, one +# should use the NXcsg and NXquadric descriptions? diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml new file mode 100644 index 0000000000..384cd3f47d --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml @@ -0,0 +1,87 @@ +# redundant as there is NXcsg, and NXquadric but easier to understand +category: base +doc: | + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality, which has to be at least 2. + c: The cardinality of the set, i.e. the number of ellipses, or ellipsoids. +NXcg_ellipsoid_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish ellipsoids for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + doc: | + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + half_axes_radius(NX_NUMBER): + doc: | + If all ellipsoids in the set have the same half-axes. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, d]] + half_axes_radii(NX_NUMBER): + doc: | + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + # properties of ellipsoids + is_closed(NX_BOOLEAN): + doc: Are the ellipsoids closed or hollow? + dimensions: + rank: 1 + dim: [[1, c]] + volume(NX_NUMBER): + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, c]] + surface_area(NX_NUMBER): + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, c]] + # NXcg_orientation_set + orientation(NX_NUMBER): + doc: | + Direction unit vector which points along the largest half-axes. + unit: NX_DIMENSIONLESS + dimensions: + rank: 2 + dim: [[1, c], [2, d]] diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml new file mode 100644 index 0000000000..fb9569afee --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml @@ -0,0 +1,169 @@ +# duplicate of an NXoff_geometry ? +category: base +doc: | + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality, which has to be at least 2. + n_v: The number of vertices. + n_e: The number of edges. + n_f: The number of faces. + n_total: The total number of vertices of all faces. Faces are polygons. + n_weinberg: The total number of Weinberg vector values of all faces. +NXcg_face_list_data_structure: + dimensionality(NX_POSINT): + doc: Dimensionality. + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + doc: Number of vertices. + unit: NX_UNITLESS + number_of_edges(NX_POSINT): + doc: Number of edges. + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + doc: Number of faces. + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + edge_identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + vertex_identifier(NX_INT): + doc: Integer used to distinguish vertices explicitly. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_v]] + edge_identifier(NX_INT): + doc: Integer used to distinguish edges explicitly. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_e]] + face_identifier(NX_INT): + doc: Integer used to distinguish faces explicitly. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_f]] + vertices(NX_NUMBER): + doc: | + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, d]] + edges(NX_INT): + doc: | + The edges are stored as a pairs of vertex identifier values. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_e], [2, 2]] + # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology + number_of_vertices(NX_POSINT): + doc: | + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_f]] + faces(NX_INT): + doc: | + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_total]] + # properties + vertices_are_unique(NX_BOOLEAN): + doc: | + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + edges_are_unique(NX_BOOLEAN): + doc: | + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + faces_are_unique(NX_BOOLEAN): + winding_order(NX_INT): + doc: | + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_f]] diff --git a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml new file mode 100644 index 0000000000..e61e00d22d --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml @@ -0,0 +1,28 @@ +category: base +doc: | + Computational geometry description of a geodesic mesh. + + People from geodesic/surveyors will likely have specific demands and + different views about what should be included in such a base class, given + that nested geodesic meshes are a key component of climate modelling tools. + For now we propose to use this base class as a container to organize metadata + and data related to geodesic meshes. + + Specifically an instance of this base class should detail the rule set how + how the geodesic (surface) mesh was instantiated as there are many + possibilities. A geodesic surface mesh is in this sense a triangulated + surface mesh with metadata. For additional details as an introduction + into the topic see e.g.: + + * `E. S. Popko and C. J. Kitrick `_ + + Here, especially the section on subdivision schemes is relevant. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcg_geodesic_mesh: + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + (NXcg_triangulated_surface_mesh): +# Discussions with NFDI-Earth could make this base class more meaty and detailed. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcg_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml new file mode 100644 index 0000000000..a97fb0cda3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_grid.yaml @@ -0,0 +1,109 @@ +category: base +doc: | + Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. + + Frequently convenient three-dimensional grids with cubic cells are used. + Exemplar applications are spectral-solver based crystal plasticity + and stencil methods like phase-field or cellular automata. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality of the grid. + c: The cardinality or total number of cells/grid points. + n_b: Number of boundaries of the bounding box or primitive to the grid. +NXcg_grid: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + origin(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, d]] + symmetry: + doc: The symmetry of the lattice defining the shape of the unit cell. + enumeration: [cubic] + cell_dimensions(NX_NUMBER): + doc: The unit cell dimensions using crystallographic notation. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, d]] + extent(NX_POSINT): + doc: | + Number of unit cells along each of the d unit vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, d]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + # number_of_cells(NX_UINT): maybe already too trivial quantities + # should constraints on the grid be place here or not + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for cells. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish cells for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + position(NX_NUMBER): + doc: Position of each cell in Euclidean space. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + coordinate(NX_INT): + doc: Coordinate of each cell with respect to the discrete grid. + unit: NX_DIMENSIONLESS + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + # this should be a ROI + bounding_box(NXcg_polyhedron_set): + doc: A tight bounding box or sphere or bounding primitive about the grid. + # a good example for a general bounding box description for such a grids of triclinic cells + # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped + number_of_boundaries(NX_POSINT): + doc: | + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + unit: NX_UNITLESS + boundaries(NX_CHAR): + doc: | + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + boundary_conditions(NX_INT): + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_b]] diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml new file mode 100644 index 0000000000..04a12cc2e8 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml @@ -0,0 +1,115 @@ +category: base +doc: | + Computational geeometry description of a half-edge data structure. + + Such a data structure can be used to efficiently circulate around faces + and iterate over vertices of a planar graph. +# holes in the polygon mesh can be handled +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality, which has to be at least 2. + n_v: The number of vertices. + n_f: The number of faces. + n_he: The number of half-edges. +NXcg_half_edge_data_structure: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + number_of_half_edges(NX_POSINT): + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + doc: | + In this half-edge data structure vertex identifiers start at 1. + Vertices are identified with consecutive integers up to number_of_vertices. + This field can be used to document which constant integer has to be + added to another set of vertex_identifier to assure that these other + identifiers also start at 1. + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + doc: | + In this half-edge data structure face identifiers start at 1. + Faces are identified with consecutive integers up to number_of_faces. + This field can be used to document which constant integer has to be + added to another set of face_identifier to assure that these other + identifiers also start at 1. + + The face identifier zero is reserved for the NULL face ! + unit: NX_UNITLESS + half_edge_identifier_offset(NX_INT): + doc: | + In this half-edge data structure half-edge identifiers start at 1. + Half-edges are identified with consecutive integers up to number_of_half_edges. + This field can be used to document which constant integer has to be + added to another set of half_edge_identifier to assure that these other + identifiers also start at 1. + unit: NX_UNITLESS + # therefore, vertex_-, face_-, half_edge_-identifier are implicit + position(NX_NUMBER): + doc: The position of the vertices. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, d]] + vertex_incident_half_edge(NX_UINT): + doc: Identifier of the incident half-edge. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_v]] + face_half_edge(NX_UINT): + doc: Identifier of the (starting)/associated half-edge of the face. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_f]] + half_edge_vertex_origin(NX_UINT): + doc: | + The identifier of the vertex from which this half-edge is outwards pointing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_he]] + half_edge_twin(NX_UINT): + doc: Identifier of the associated oppositely pointing half-edge. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_he]] + half_edge_incident_face(NX_UINT): + doc: | + If the half-edge is a boundary half-edge the + incident face identifier is NULL, i.e. 0. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_he]] + half_edge_next(NX_UINT): + doc: Identifier of the next half-edge. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_he]] + half_edge_prev(NX_UINT): + doc: Identifier of the previous half-edge. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_he]] + weinberg_vector(NX_CHAR): + doc: | + Users are referred to the literature for the background of L. Weinberg's + work about topological characterization of planar graphs: + + * `L. Weinberg 1966a, `_ + * `L. Weinberg, 1966b, `_ + * `E. A. Lazar et al. `_ + + and how this work can e.g. be applied in space-filling tessellations + of microstructural objects like crystals/grains. +# eventually store the Weinberg vector as an integer array +# which could be more efficient +# see https://jerryyin.info/geometry-processing-algorithms/half-edge/ +# for an illustrative example of half-edge data structures diff --git a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml new file mode 100644 index 0000000000..0dc7f274b7 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml @@ -0,0 +1,178 @@ +# it is useful to define own base classes for frequently used classes +# a polyhedron is a specific polytope in 3d, do we need +# higher-dimensional polytopes? that could be useful for simplicies though +# as they are used in numerics etc. maybe reach out here to our friends +# from MarDI, for now let's assume we do not need polytopes for d > 3 +category: base +doc: | + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + c: The cardinality of the set, i.e. the number of hexahedra. +NXcg_hexahedron_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + # qualifiers and properties of hexahedra + shape(NX_NUMBER): + doc: A qualitative description of each hexahedron/cuboid/cube/box. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + length(NX_NUMBER): + doc: | + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of an edge within + a specific coordinate system. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + height(NX_NUMBER): + doc: | + Qualifier often used to describe the length of an edge within + a specific coordinate system. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + doc: | + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + volume(NX_NUMBER): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, c]] + surface_area(NX_NUMBER): + doc: Total area (of all six faces) of each hexahedron. + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + face_area(NX_NUMBER): + doc: Area of each of the six faces of each hexahedron. + unit: NX_AREA + dimensions: + rank: 2 + dim: [[1, c], [2, 6]] + is_box(NX_BOOLEAN): + doc: | + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + dimensions: + rank: 1 + dim: [[1, c]] + is_axis_aligned(NX_BOOLEAN): + doc: | + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish hexahedra for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + # substantially more detailed descriptors of the shape, the mesh + orientation(NXorientation_set): + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # detailed mesh-based representation + hexahedra(NXcg_face_list_data_structure): + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + hexahedron(NXcg_face_list_data_structure): + # exists: [min, 0, max, infty] # can this be max, c? + doc: Disentangled representations of the mesh of specific hexahedra. + hexahedron_half_edge(NXcg_half_edge_data_structure): + # exists: [min, 0, max, infty] + doc: | + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. diff --git a/contributed_definitions/nyaml/NXcg_isocontour.yaml b/contributed_definitions/nyaml/NXcg_isocontour.yaml new file mode 100644 index 0000000000..cfb693efb9 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_isocontour.yaml @@ -0,0 +1,30 @@ +category: base +doc: | + Computational geometry description of isocontouring/phase-fields in Euclidean space. + + Iso-contouring algorithms such as MarchingCubes and others are frequently + used to segment d-dimensional regions into regions where intensities are + lower or higher than a threshold value, the so-called isovalue. + + Frequently in computational materials science phase-field methods are + used which generate data on discretized grids. Isocontour algorithms + are often used in such context to pinpoint the locations of microstructural + features from this implicit phase-field-variable-based description. + + One of the key intentions of this base class is to provide a starting point + for scientists from the phase-field community (condensed matter physicists, + and materials engineers) to incentivize that also phase-field simulation + data could be described with NeXus, provided base classes such as the this one + get further extend according to the liking of the phase-field community. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality of the description. +NXcg_isocontour: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + grid(NXcg_grid): + doc: | + The discretized grid on which the iso-contour algorithm operates. + isovalue(NX_NUMBER): + doc: The threshold or iso-contour value. + unit: NX_ANY diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml new file mode 100644 index 0000000000..d52388bb47 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Computational geometry description of the marching cubes algorithm. + + Documenting which specific version was used can help to understand how robust + the results are with respect to the topology of the triangulation. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcg_marching_cubes: + grid(NXcg_grid): + doc: | + Reference/link to and/or details of the grid on which a specific + marching cubes algorithm implementation is operating. + implementation: + doc: | + Reference to the specific implementation of marching cubes used. + + See for example the following papers for details about how to identify a + DOI which specifies the implementation used: + + * `W. E. Lorensen `_ + * `T. S. Newman and H. Yi `_ + + The value placed here should be a DOI. If there are no specific DOI or + details write not_further_specified, or give at least a free-text + description. + program: + doc: | + Commercial or otherwise given name to the program which was used. + \@version: + doc: | + Program 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. +# we could also think about storing the rule sets in here explicitly including the +# coordinate system conventions; however, the problem is that many commercial +# tools like Matlab do not expose the rule set. diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml new file mode 100644 index 0000000000..44e56bceb9 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml @@ -0,0 +1,132 @@ +category: base +doc: | + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + c: The cardinality of the set, i.e. the number of parallelograms. +NXcg_parallelogram_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [2] + cardinality(NX_POSINT): + unit: NX_UNITLESS + # qualifiers and properties of parallelograms + shape(NX_NUMBER): + doc: A qualitative description of each parallelogram/rectangle/square/box. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 2]] + length(NX_NUMBER): + doc: | + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of an edge within + a specific coordinate system. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + doc: | + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 2]] + surface_area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + is_axis_aligned(NX_BOOLEAN): + doc: | + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish parallelograms for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + # substantially more detailed descriptors of the shape, the mesh + orientation(NXorientation_set): + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # detailed mesh-based representation + parallelograms(NXcg_face_list_data_structure): + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + parallelogram(NXcg_face_list_data_structure): + # exists: [min, 0, max, infty] # can this be max, c? + doc: Disentangled representations of the mesh of specific parallelograms. + # ##MK::a half-edge structure would be overkill as this is a simple primitive diff --git a/contributed_definitions/nyaml/NXcg_point_set.yaml b/contributed_definitions/nyaml/NXcg_point_set.yaml new file mode 100644 index 0000000000..017bd77382 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_point_set.yaml @@ -0,0 +1,55 @@ +category: base +doc: | + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality, which has to be at least 1. + c: The cardinality of the set, i.e. the number of points. +NXcg_point_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish points for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + position(NX_NUMBER): + doc: The array of point coordinates. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + time(NX_NUMBER): + doc: The optional array of time for each vertex. + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.yaml b/contributed_definitions/nyaml/NXcg_polygon_set.yaml new file mode 100644 index 0000000000..624d047ff6 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_polygon_set.yaml @@ -0,0 +1,171 @@ +category: base +# somewhat redundant as there is NXoff_geometry but easier to understand +doc: | + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. +# Users can take advantage of NXcg_polygon_set to describe such complexes +# when using the defines_plc and related topological and boundary constraint +# descriptors. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality, which has to be either 2 or 3. + c: The cardinality of the set, i.e. the number of polygons. + # n_unique: Number of unique points supporting the polygons. + n_total: The total number of vertices when visiting every polygon. +NXcg_polygon_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [2, 3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + number_of_total_vertices(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish polygons for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + polygons(NXcg_face_list_data_structure): + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + # detailed additional information eventually mesh-related data + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # triangles_half_edge(NXcg_half_edge_data_structure): + # properties of the polygon primitives + area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + edge_length(NX_NUMBER): + doc: The accumulated length of the polygon edge. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + interior_angle(NX_NUMBER): + doc: | + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, n_total]] + shape(NX_INT): + doc: | + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + doc: The center of mass of each polygon. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + bounding_box(NXcg_hexahedron_set): + doc: Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + # ##MK::ROI about the set ? +# a set of polygons can be interpreted as a descriptor for an object +# an, in TetGen terminology, piecewise-linear complex +# defines_plc(NX_BOOLEAN): +# doc: True, if the set describes a piecewise-linear complex. +# ##MK::each polygon could be given a role with respect to what the polygon +# ##MK::represents of the complex, this would allow to define a complex with +# ##MK::holes +# vertices(NXcg_point_set): +# doc: | +# The set of vertices supporting the polygons. +# +# The dimensionality of the point set and this polygon set are the same. +# The number of vertices is arbitrary because polygons may different in +# their number of edges. +# +# Like it is the case for NXcg_triangle_set instances, individual +# polygons may make edge contact in which case a lower number of vertices +# suffices than naively expected from a summation of the edges. +# +# Users are encouraged to reduce the vertex set to a set of unique vertices +# as this can often turn out to allow for a more efficient storage +# of the geometry data. It is also possible though to store +# the vertices naively in which case vertices_are_unique is likely False. +# vertices_are_unique(NX_BOOLEAN): +# doc: | +# If true indicates that the vertices are all placed at different positions +# and have different identifiers, i.e. no points overlap or are counted twice. +# number_of_vertices(NX_POSINT): +# doc: | +# Array which specifies of how many vertices each polygon is built. +# The number of vertices represent the total number of vertices for +# each polygon, irrespectively whether vertices are shared or not. +# See the docstring for polygons for further details about how +# a set with different polyline members should be stored. +# unit: NX_UNITLESS +# dimensions: +# rank: 1 +# dimensions: [[1, c]] +# # ##MK::there is nothing like value constraints... or minimum bitdepth +# polygons(NX_INT): +# doc: | +# Array of identifiers from vertices which describe each polygon. +# +# The first entry is the identifier of the start vertex of the first polyline, +# followed by the second vertex of the first polyline, until the last vertex +# of the polyline. Thereafter, the start vertex of the second polyline, and +# so on and so forth. Using the (cumulated) counts in number_of_vertices, +# the vertices of the n-th polyline can be accessed on the following +# array index interval: +# [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. +# +# Users are advised to store the vertex identifiers, if possible and +# ideally then for all of them, according to and using winding order. +# If the winding_order field is given, it has to report the specific winding +# order used. +# unit: NX_UNITLESS +# dimensions: +# rank: 1 +# dim: [[1, n_total]] diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml new file mode 100644 index 0000000000..7142213823 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml @@ -0,0 +1,131 @@ +# it is useful to define own base classes for frequently used classes +# a polyhedron is a specific polytope in 3d, do we need +# higher-dimensional polytopes? that could be useful for simplicies though +# as they are used in numerics etc. maybe reach out here to our friends +# from MarDI, for now let's assume we do not need polytopes for d > 3 +# NeXus already supports polyhedra via NXoff_geometry +# the here proposed base class extends the capabilities to qualifiers of +# polyhedra and also half_edge_data_structures that can be useful +# for clean graph-based descriptions of polyhedra. +category: base +doc: | + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + c: The cardinality of the set, i.e. the number of polyhedra. + n_e_total: The total number of edges for all polyhedra. + n_f_total: The total number of faces for all polyhedra. +NXcg_polyhedron_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + # qualifiers and properties of polyhedra + volume(NX_NUMBER): + doc: Interior volume + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + doc: | + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + surface_area(NX_NUMBER): + doc: Total surface area as the sum of all faces. + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + number_of_faces(NX_POSINT): + doc: | + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + face_area(NX_NUMBER): + doc: | + Area of each of the four triangular faces of each tetrahedron. + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, n_f_total]] + number_of_edges(NX_POSINT): + doc: | + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + edge_length(NX_NUMBER): + doc: | + Length of each edge of each tetrahedron. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_e_total]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + # substantially more detailed descriptors of the shape, the mesh + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish polyhedra for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # detailed mesh-based representation + polyhedra(NXcg_face_list_data_structure): + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + polyhedron(NXcg_face_list_data_structure): + # exists: [min, 0, max, infty] # can this be max, c? + doc: Disentangled representations of the mesh of specific polyhedron. + polyhedron_half_edge(NXcg_half_edge_data_structure): + # exists: [min, 0, max, infty] + doc: | + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. +# face_type(NX_UINT): #maybe a better name maybe topology, although this is misleading for the above-mentioned reasons +# doc: A concatenated array, for each polygon face the number of vertices. +# unit: NX_UNITLESS +# dimensions: +# rank: 1 +# dim: [[1, nfaces]] +# intersections between members? as a graph +# contact with external primitives like simulation domain etc \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.yaml b/contributed_definitions/nyaml/NXcg_polyline_set.yaml new file mode 100644 index 0000000000..8dcd9e426c --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_polyline_set.yaml @@ -0,0 +1,131 @@ +category: base +doc: | + Computational geometry description of a set of polylines in Euclidean space. + + Each polyline is built from a sequence of vertices (points with identifiers). + Each polyline must have a start and an end point. + The sequence describes the positive traversal along the polyline when walking + from the start vertex to the end/last vertex. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality, which has to be at least 1. + c: The cardinality of the set, i.e. the number of polylines. + # n_unique: The number of unique vertices supporting the polyline. + # multiple vertices possible with the same point coordinates but different names. + n_v: The number of vertices, supporting the polylines. + n_total: The total number of vertices traversed when visiting every polyline. +NXcg_polyline_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + # number_of_unique_vertices(NX_POSINT): + # unit: NX_UNITLESS + number_of_total_vertices(NX_POSINT): + doc: | + The total number of vertices, irrespective of their eventual uniqueness, + i.e. the total number of vertices that have to be visited when walking + along each polyline. + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + doc: | + The number of vertices. If vertices are reduced to the unique ones, this + number_of_vertices is not necessarily equal to the total number of vertices. + unit: NX_UNITLESS + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and polyline data are interpretable. + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + polylines. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish polylines for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + vertices(NX_NUMBER): + doc: | + Positions of the vertices which support the members of the polyline set. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + # Users are encouraged to reduce the vertex set to the unique vertices. + # Unique means not necessarily unique in position only but also unique in + # identifier. In fact, it is possible to distinguish two vertices as two when + # they share the same position in space but have different identifiers. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, d]] + vertices_are_unique(NX_BOOLEAN): + doc: | + If true indicates that the vertices are all placed at different + positions and have different identifiers, i.e. no points overlap + or are counted twice. + number_of_vertices(NX_POSINT): + doc: | + Array which specifies of how many vertices each polyline is built. + The number of vertices represent the total number of vertices for + each polyline, irrespectively whether vertices are shared or not. + See the docstring for polylines for further details about how + a set with different polyline members should be stored. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + polylines(NX_INT): + doc: | + Sequence of vertex identifiers which describe each polyline. + + A trivial example is a set with two polylines with three vertices each. + If the polylines meet in a junction, say the second vertex is shared + and marking the junction between the two polylines, it is possible that + there are only five unique positions suggesting five unique vertices. + + A non-trivial example is a set with several polylines, each of which with + eventually different number of vertices. The array stores the vertex + identifiers in the order how the polylines are visited: + + The first entry is the identifier of the start vertex of the first polyline, + followed by the second vertex of the first polyline, until the last vertex + of the polyline. Thereafter, the start vertex of the second polyline, and + so on and so forth. Using the (cumulated) counts in number_of_vertices, + the vertices of the n-th polyline can be accessed on the following + array index interval: + :math:`$[\sum_i = 0}^{i = N-1}, \sum_{i=0}^{i=N}]$`. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_total]] + # properties of the polyline primitives + length(NX_NUMBER): + doc: The length of each polyline. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + is_closed(NX_BOOLEAN): + doc: | + If true specifies that a polyline is closed, i.e. + its end point is connected to the start point. + dimensions: + rank: 1 + dim: [[1, c]] + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): diff --git a/contributed_definitions/nyaml/NXcg_roi_set.yaml b/contributed_definitions/nyaml/NXcg_roi_set.yaml new file mode 100644 index 0000000000..a28aae9e2e --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_roi_set.yaml @@ -0,0 +1,13 @@ +# eventually redundant NXsolid_geometry? +category: base +doc: | + Base class to hold geometric primitives. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcg_roi_set: + CG_SPHERE_SET(NXcg_sphere_set): + CG_ELLIPSOID_SET(NXcg_ellipsoid_set): + CG_CYLINDER_SET(NXcg_cylinder_set): + CG_POLYHEDRON_SET(NXcg_polyhedron_set): +# doc: An eventually redundant container to hold multiple primitives. +# how to handle cases where multiple primitives should be included? diff --git a/contributed_definitions/nyaml/NXcg_sphere_set.yaml b/contributed_definitions/nyaml/NXcg_sphere_set.yaml new file mode 100644 index 0000000000..1ae6751e33 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_sphere_set.yaml @@ -0,0 +1,76 @@ +# redundant as there is NXcsg, and NXquadric but easier to understand +category: base +doc: | + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality, which has to be at least 2. + c: The cardinality of the set, i.e. the number of circles or spheres. +NXcg_sphere_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish spheres for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + doc: | + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + radius(NX_NUMBER): + doc: | + In the case that all spheres have the same radius. + unit: NX_LENGTH + radii(NX_NUMBER): + doc: | + In the case that spheres have different radius use this + instead of the radius field. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + # properties of spheres + is_closed(NX_BOOLEAN): + doc: Are the spheres closed or hollow? + dimensions: + rank: 1 + dim: [[1, c]] + volume(NX_NUMBER): + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, c]] + surface_area(NX_NUMBER): + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, c]] diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml new file mode 100644 index 0000000000..fd5376fc0d --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml @@ -0,0 +1,122 @@ +# it is useful to define own base classes for frequently used classes +# a polyhedron is a specific polytope in 3d, do we need +# higher-dimensional polytopes? that could be useful for simplicies though +# as they are used in numerics etc. maybe reach out here to our friends +# from MarDI, for now let's assume we do not need polytopes for d > 3 +category: base +doc: | + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + c: The cardinality of the set, i.e. the number of tetrahedra. +NXcg_tetrahedron_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + # qualifiers and properties of tetrahedra + volume(NX_NUMBER): + doc: Interior volume + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + doc: | + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + surface_area(NX_NUMBER): + doc: Total surface area as the sum of all four triangular faces. + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + face_area(NX_NUMBER): + doc: | + Area of each of the four triangular faces of each tetrahedron. + unit: NX_AREA + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] + edge_length(NX_NUMBER): + doc: | + Length of each edge of each tetrahedron. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 6]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + # substantially more detailed descriptors of the shape, the mesh + # interior_angle(NX_NUMBER): + # doc: | + # Array of interior angle values. For each tetrahedron the quadruplet of + # angles is a sequence following the order of the vertices. The angle + # is the angle at the specific vertex. TODO lexiographical order. + # Winding order has to be interpreted to resolve the individual angles + # between edges of adjoining face triangles meeting at each corner/vertex. + # unit: NX_ANGLE + # dimensions: + # rank: 2 + # dim: [[1, c], [2, 12]] + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish tetrahedra for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # detailed mesh-based representation + tetrahedra(NXcg_face_list_data_structure): + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + tetrahedron(NXcg_face_list_data_structure): + # exists: [min, 0, max, infty] # can this be max, c? + doc: Disentangled representations of the mesh of specific tetrahedra. + tetrahedron_half_edge(NXcg_half_edge_data_structure): + # exists: [min, 0, max, infty] + doc: | + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.yaml b/contributed_definitions/nyaml/NXcg_triangle_set.yaml new file mode 100644 index 0000000000..848b3d366a --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_triangle_set.yaml @@ -0,0 +1,79 @@ +category: base +doc: | + Computational geometry description of a set of triangles in Euclidean space. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality, which has to be at least 2. + c: The cardinality of the set, i.e. the number of triangles. + n_unique: The number of unique vertices supporting the triangles. +NXcg_triangle_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + number_of_unique_vertices(NX_POSINT): + unit: NX_UNITLESS + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish triangles for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + triangles(NXcg_face_list_data_structure): + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + # detailed additional information eventually mesh-related data + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # triangles_half_edge(NXcg_half_edge_data_structure): + # properties of triangles + area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + edge_length(NX_NUMBER): + doc: | + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + interior_angle(NX_NUMBER): + doc: | + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + center(NX_NUMBER): + doc: The center of mass of each polygon. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + bounding_box(NXcg_hexahedron_set): + doc: Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml new file mode 100644 index 0000000000..79af29f276 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml @@ -0,0 +1,27 @@ +category: base +doc: | + Computational geometry description of a mesh of triangles. + + The mesh may be self-intersecting and have holes but the + triangles must not be degenerated. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcg_triangulated_surface_mesh: +# (NXtransformations): +# doc: | +# Reference to or definition of a coordinate system with +# which the qualifiers and mesh data are interpretable. +# # substantially more detailed descriptors of the shape, the mesh +# vertex_normal(NXcg_unit_normal_set): +# edge_normal(NXcg_unit_normal_set): +# face_normal(NXcg_unit_normal_set): +# # detailed mesh-based representation +# (NXcg_face_list_data_structure): +# doc: | +# A simple approach to describe the mesh when the main intention is to +# store its triangles for visualization. + (NXcg_triangle_set): + (NXcg_half_edge_data_structure): + doc: | + A graph-based approach to describe the mesh when it is also desired + to perform topological processing or analyses on the mesh. diff --git a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml new file mode 100644 index 0000000000..4a04ae634b --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml @@ -0,0 +1,33 @@ +# the benefit of NXcg_point_set is that the origin is 0 by default +# how to resolve the association between the unit normal and its associated primitive? +# rather make this a set of vectors, irrespective whether these are unit or not +category: base +doc: | + Computational geometry description of a set of (oriented) unit normal vectors. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality, which has to be at least 2. + c: The cardinality of the set, i.e. the number of unit normals. +NXcg_unit_normal_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + doc: Direction of each normal + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + orientation(NX_INT): + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] diff --git a/contributed_definitions/nyaml/NXchamber.yaml b/contributed_definitions/nyaml/NXchamber.yaml new file mode 100644 index 0000000000..da826038d1 --- /dev/null +++ b/contributed_definitions/nyaml/NXchamber.yaml @@ -0,0 +1,11 @@ +category: base +doc: | + Component of an instrument to store or place objects and specimens. +NXchamber: + name: + doc: Given name/alias. + description: + doc: | + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + (NXfabrication): diff --git a/contributed_definitions/nyaml/NXclustering.yaml b/contributed_definitions/nyaml/NXclustering.yaml new file mode 100644 index 0000000000..73959a6e26 --- /dev/null +++ b/contributed_definitions/nyaml/NXclustering.yaml @@ -0,0 +1,67 @@ +category: base +doc: | + Metadata to the results of a clustering analysis. + + Clustering algorithms are routine tools to segment a set of objects/primitives + into groups, objects of different type. A plethora of algorithms have been + proposed for geometric primitives as objects, such as points, triangles, + or (abstract) objects. + + This base class considers metadata and results of one clustering + applied to a set in which objects are either categorized as noise + or belonging to a cluster, specifically here only one cluster. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_lbl_num: Number of numeral labels per object. + n_lbl_cat: Number of categorical labels per object. + n_cluster: Total number of clusters detected. +NXclustering: + number_of_numeric_labels(NX_UINT): + doc: How many numeric labels does each object have. + unit: NX_UNITLESS + number_of_categorical_labels(NX_UINT): + doc: How many categorical labels does each object have. + unit: NX_UNITLESS + objects(NX_CHAR): + doc: | + Reference to a set of objects investigated in a cluster analysis. + Objects must have clear integer identifier. + numeric_label(NX_NUMBER): + doc: | + Reference to numeric attribute data for each object. + categorical_label(NX_CHAR): + doc: | + Reference to categorical attribute data for each object. + # list instances of base classes of an applied cluster algorithm + # e.g. (NXclustering_hdbscan): + identifier_offset(NX_UINT): + doc: | + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + unit: NX_UNITLESS + unassigned(NX_UINT): + doc: Total number of objects categorized as unassigned. + unit: NX_UNITLESS + noise(NX_UINT): + doc: Total number of objects categorized as noise. + unit: NX_UNITLESS + number_of_cluster(NX_UINT): + doc: Total number of clusters (excluding noise and unassigned). + unit: NX_UNITLESS + size(NX_NUMBER): + doc: | + Number of objects associated to each cluster. The labels are implicit, + meaning the zeroth/first entry in the array belongs to the first cluster, + the second entry to the second cluster and so on and so forth. + The first cluster has the value of identifier_offset as its identifier. + The second cluster has identifier_offset + 1, and so on and so forth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_cluster]] + # should we handle, and if so how fuzzy assignments or similarly probability diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yml b/contributed_definitions/nyaml/NXcollectioncolumn.yml new file mode 100644 index 0000000000..74f0016164 --- /dev/null +++ b/contributed_definitions/nyaml/NXcollectioncolumn.yml @@ -0,0 +1,40 @@ +category: base +doc: "Subclass of NXelectronanalyser to describe the electron collection column + of a photoelectron analyser." +(NXcollectioncolumn): + scheme(NX_CHAR): + doc: + "Scheme of the electron collection lens, i.e. standard, deflector, PEEM, + momentum microscope, etc." + extractor_voltage(NX_FLOAT): + doc: "Voltage applied to the extractor lens" + unit: NX_VOLTAGE + extractor_current(NX_FLOAT): + doc: "Current necessary to keep the extractor lens at a set voltage. + Variations indicate leakage, field emission or arc currents to the extractor lens." + unit: NX_CURRENT + working_distance(NX_FLOAT): + doc: "Distance between sample and detector entrance" + unit: NX_LENGTH + mode(NX_CHAR): + doc: "Labelling of the lens setting in use." + projection(NX_CHAR): + doc: "The space projected in the angularly dispersive directions, real or reciprocal" + enumeration: ["real", "reciprocal"] + magnification(NX_FLOAT): + doc: "The magnification of the electron lens assembly." + unit: NX_DIMENSIONLESS + depends_on(NX_CHAR): + doc: "Specifies the position of the collectioncolumn by pointing to the last transformation in the transformation chain in the NXtransformations group." + (NXtransformations): + doc: + "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 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." + (NXaperture): + doc: "The size and position of an aperture inserted in the column, e.g. field aperture or contrast aperture" + (NXdeflector): + doc: "Deflectors in the collection column section" + (NXlens_em): + doc: "Individual lenses in the collection column section" diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml new file mode 100644 index 0000000000..9c0d26edda --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml @@ -0,0 +1,116 @@ +category: base +doc: | + 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 `_ 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.) + +NXcoordinate_system_set: + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + (NXtransformations): + doc: | + 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. + + # NEW ISSUE: add an illustrated example + + # thoughts on how to use this + # these user-defined frames could be the sample surface, the detector, + # individual frames attached to specific instruments, for instance in an + # atom probe experiment we usually have a lab, specimen surface/apex, laser (pinhole), detector, reconstruction frames + # in electron/focused ion beam, lab, e-beam, i-beam, sample surface, individual frames for each detector + + # THE REMAINING TEXT IS NOT PART OF THE BASE CLASS + # An example follows how each field under transformations can look like + # I would like to encourage a description where each coordinate system is defined + # and for each coordinate system a transformation written down which maps each + # user-defined Frame_i onto Frame_McStas (and maybe for convenience purposes also vice versa + # Frame_McStas = T_i * Frame_i + # if there would be a small python tool that takes a collection of frames + # and does the mapping automatically and writing the respective NeXus entries + # this would be very useful. + + # # \@transformation_type should not be used + # # define frame of reference that is understood as the laboratory coordinate system + # x_axis(NX_NUMBER): + # unit: NX_TRANSFORMATION + # \@depends_on: # "." meaning the root coordinate system, i.e. the McStas + # \@vector(NX_NUMBER): # [1, 0, 0] + # # \@offset(NX_NUMBER): + # y_axis(NX_NUMBER): + # unit: NX_TRANSFORMATION + # \@depends_on: # "." + # \@vector(NX_NUMBER): # [0, 1, 0] + # # \@offset(NX_NUMBER): + # z_axis(NX_NUMBER): + # unit: NX_TRANSFORMATION + # \@depends_on: # "." + # \@vector(NX_NUMBER): # [0, 0, 1] + # \@offset(NX_NUMBER): # is [0, 0, 0] if the origin of the McStas coordinate system and of the laboratory_frame overlap + # # \@offset_units: # should be an NX_LENGTH + # # and how it translates into the McStas convention + # lab_mcstas(NX_NUMBER): + # doc: Rotation matrix which maps the x_axis of the laboratory_frame to the x_axis of the McStas system. + # # BUT as far as I know you cannot define a 3D rotation matrix, you should rather make a chain of transformations + # # each about a single axis and thus building a depends_on chain + # # for example a 4x4 translation with a more-than-one-value-non-zero/non-identity rotation matrix + # # could be you first rotate about Z by R_Z'/R_1 depends_on is x_axis := X, yielding X', Y', Z' + # # second you rotate about the X' by R_X/R_2 depends_on is X', yielding X'', Y'', Z'' + # # third you rotate about the Z'' by R_Z''/R_3 depends_on is then Z'', yielding X''', Y''', Z''' matching McStas, + # # this is the Bunge-Euler way of doing it, but would it also be possible to just define + # # the lab_mcstas(NX_NUMBER) value as an 3x3 array and give the offsets and translations as it is discussed in the manual ? + # unit: NX_ANGLE + # \@depends_on: # x_axis + # # 3x3 rotation matrices are decoupled into three successive planar rotations + # see https://manual.nexusformat.org/classes/base_classes/NXtransformations.html + # mcstas_to_lab(NX_NUMBER): + # # same story but the inverse affine transformation diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml new file mode 100644 index 0000000000..112eac1035 --- /dev/null +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -0,0 +1,33 @@ +category: base +doc: | + Corrector for aberrations in an electron microscope. + + Different vendors use a different naming schemes for aberration coefficients. + It is the users responsibility to map to the best matching values. + + In transmission electron microscopes the spherical aberration corrector is + a component that is controlled via instructing the microscope to achieve + set point values. The corrector is composed of multiple lenses and other + parts with vendor-specific details which are often undisclosed. + + In the case of Nion Co. microscopes the coefficients of the corrector can be + retrieved via NionSwift, which is why currently the Nion convention for the + aberration coefficients is used. +NXcorrector_cs: + applied(NX_BOOLEAN): + doc: Was the corrector used? + name: + doc: Given name/alias. + (NXfabrication): + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + # NEW ISSUE: clarify the mathematical details behind the + # NEW ISSUE: following parameters of the these constants and how they are useful + (NXaberration): + (NXlens_em): + (NXtransformations): +# NEW ISSUE: add the reference to the conversion table between +# NEW ISSUE: Haider and Krivanek The table [##MK]() is here used for reference. diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml new file mode 100644 index 0000000000..45e2d3ef83 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -0,0 +1,32 @@ +category: base +doc: | + Computer science description of a set of computing nodes. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcs_computer: + name: + doc: Given name/alias to the computing system, e.g. MyDesktop. + operating_system: + doc: | + Name of the operating system, e.g. Windows, Linux, Mac, Android. + \@version: + doc: | + 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. + # difference e.g. in Win11 between hardware ID, UUID, and device ID + uuid: + doc: | + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + # when it comes to performance monitoring + (NXcs_cpu): + doc: A list of physical processing units (can be multi-core chips). + (NXcs_gpu): + doc: A list of physical coprocessor/graphic cards/accelerator units. + (NXcs_mm_sys): + doc: Details about the memory sub-system. + (NXcs_io_sys): + doc: Details about the I/O sub-system. diff --git a/contributed_definitions/nyaml/NXcs_cpu.yaml b/contributed_definitions/nyaml/NXcs_cpu.yaml new file mode 100644 index 0000000000..ae9b3f8285 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_cpu.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Computer science description of a central processing unit (CPU) of a computer. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcs_cpu: + name: + doc: Given name of the CPU. Users should be as specific as possible. + (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml new file mode 100644 index 0000000000..a43dc803a4 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml @@ -0,0 +1,59 @@ +category: base +doc: | + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_objs: Number of entries (e.g. number of points or objects). + bitdepth: Number of bits assumed for the container datatype used. + n_total: Length of mask considering the eventual need for padding. +NXcs_filter_boolean_mask: + number_of_objects(NX_UINT): + doc: Number of objects represented by the mask. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_total]] + identifier(NX_UINT): + doc: | + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + dimensions: + rank: 1 + dim: [[1, n_object]] diff --git a/contributed_definitions/nyaml/NXcs_gpu.yaml b/contributed_definitions/nyaml/NXcs_gpu.yaml new file mode 100644 index 0000000000..67809eb18c --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_gpu.yaml @@ -0,0 +1,10 @@ +category: base +doc: | + Computer science description of a graphic processing unit (GPU) of a computer. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcs_gpu: + name: + doc: Given name of the GPU. Users should be as specific as possible. + (NXfabrication): + diff --git a/contributed_definitions/nyaml/NXcs_io_obj.yaml b/contributed_definitions/nyaml/NXcs_io_obj.yaml new file mode 100644 index 0000000000..78396ac05b --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_io_obj.yaml @@ -0,0 +1,17 @@ +category: base +doc: | + Computer science description of a storage object in an input/output system. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcs_io_obj: + technology: + doc: Qualifier for the type of storage medium used. + enumeration: [solid_state_disk, hard_disk, tape] + # recording technique etc. + max_physical_capacity(NX_NUMBER): + doc: Total amount of data which the medium can hold. + # unit: NX_BIT + name: + doc: Given name to the I/O unit. + (NXfabrication): + diff --git a/contributed_definitions/nyaml/NXcs_io_sys.yaml b/contributed_definitions/nyaml/NXcs_io_sys.yaml new file mode 100644 index 0000000000..5c53610f2f --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_io_sys.yaml @@ -0,0 +1,7 @@ +category: base +doc: | + Computer science description of system of a computer. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcs_io_sys: + (NXcs_io_obj): diff --git a/contributed_definitions/nyaml/NXcs_mm_sys.yaml b/contributed_definitions/nyaml/NXcs_mm_sys.yaml new file mode 100644 index 0000000000..a9f310913e --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_mm_sys.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Computer science description of a main memory system of a computer. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcs_mm_sys: + total_physical_memory(NX_NUMBER): + doc: How much physical memory does the system provide. + # unit: NX_BIT \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcs_prng.yaml b/contributed_definitions/nyaml/NXcs_prng.yaml new file mode 100644 index 0000000000..f77ed6b7a8 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_prng.yaml @@ -0,0 +1,44 @@ +category: base +doc: | + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcs_prng: + type: + doc: | + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + enumeration: [physical, system_clock, mt19937, other] + program: + doc: | + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + \@version: + doc: Version and build number, or commit hash. + seed(NX_NUMBER): + doc: | + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + unit: NX_UNITLESS + warmup(NX_NUMBER): + doc: | + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + # reformulate last part of the first sentence. + unit: NX_UNITLESS + # one could add spectral properties but this is usually well documented in the PRNG literature + # one could also think about making reference to the NIST PRNG test suite to qualify the PRNG diff --git a/contributed_definitions/nyaml/NXcs_profiling.yaml b/contributed_definitions/nyaml/NXcs_profiling.yaml new file mode 100644 index 0000000000..cb3acc7f35 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_profiling.yaml @@ -0,0 +1,103 @@ +category: base +doc: | + Computer science description for summary performance/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 + contributions to performance: + + * Hardware capabilities and configuration + * 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. + + 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. + + 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 + 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. + + This base class cannot and should not replace these specific solutions. + 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 + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcs_profiling: + # details about queuing systems etc + command_line_call(NX_CHAR): + doc: | + Command line call with arguments if applicable. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + total_elapsed_time(NX_NUMBER): + doc: | + 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. + unit: NX_TIME + number_of_processes(NX_POSINT): + doc: | + 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. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + unit: NX_UNITLESS + number_of_threads(NX_POSINT): + doc: | + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + unit: NX_UNITLESS + number_of_gpus(NX_POSINT): + doc: | + Qualifier with how many nominal GPUs the app was invoked at runtime. + unit: NX_UNITLESS + # there are more complicated usage models, where GPUs are activated in + # between runs etc, but here application definition and base class developers + # should feel free to suggest customizations wrt to if and how such more + # complicated models should be captured. + # how can you have an empty list? + (NXcs_computer): + doc: | + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + (NXcs_profiling_event): + doc: | + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. +# how to retrieve UUID for cloud computing instances +# https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html diff --git a/contributed_definitions/nyaml/NXcs_profiling_event.yaml b/contributed_definitions/nyaml/NXcs_profiling_event.yaml new file mode 100644 index 0000000000..8a5eaeb6f7 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_profiling_event.yaml @@ -0,0 +1,52 @@ +category: base +doc: | + Computer science description of a profiling event. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_processes: Number of processes. +NXcs_profiling_event: + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + description: + doc: | + Free-text description what was monitored/executed during the event. + elapsed_time(NX_NUMBER): + doc: | + 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. + Elapsed time may contain time portions where resources were idling. + unit: NX_TIME + number_of_processes(NX_POSINT): + doc: | + Number of processes used (max) during the execution of this event. + unit: NX_UNITLESS + number_of_threads(NX_POSINT): + doc: | + Number of threads used (max) during the execution of this event. + unit: NX_UNITLESS + number_of_gpus(NX_POSINT): + doc: | + Number of GPUs used (max) during the execution of this event. + unit: NX_UNITLESS + max_virtual_memory_snapshot(NX_NUMBER): + doc: | + Maximum amount of virtual memory allocated per process during the event. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_processes]] + max_resident_memory_snapshot(NX_NUMBER): + doc: | + Maximum amount of resident memory allocated per process during the event. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_processes]] diff --git a/contributed_definitions/nyaml/NXdeflector.yml b/contributed_definitions/nyaml/NXdeflector.yml new file mode 100644 index 0000000000..3624d5c461 --- /dev/null +++ b/contributed_definitions/nyaml/NXdeflector.yml @@ -0,0 +1,27 @@ +category: base +doc: "Deflectors as they are used e.g. in an electron analyser." +(NXdeflector): + type: + doc: "Qualitative type of deflector with respect to the number of pole pieces" + enumeration: ["dipole", "quadrupole", "hexapole", "octupole"] + name: + doc: "Colloquial or short name for the deflector. For manufacturer names and identifiers use respective manufacturer fields." + manufacturer_name: + doc: "Name of the manufacturer who built/constructed the deflector." + manufacturer_model: + doc: "Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the deflector." + description: + doc: "Ideally an identifier, persistent link, or free text which gives further details about the deflector." + voltage(NX_NUMBER): + doc: "Excitation voltage of the deflector. For dipoles it is a single number. For higher orders, it is an array." + unit: NX_VOLTAGE + current(NX_NUMBER): + doc: "Excitation current of the deflector. For dipoles it is a single number. For higher orders, it is an array." + unit: NX_CURRENT + depends_on(NX_CHAR): + doc: "Specifies the position of the deflector by pointing to the last transformation in the transformation chain in the NXtransformations group." + (NXtransformations): + doc: "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 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/nyaml/NXdelocalization.yaml b/contributed_definitions/nyaml/NXdelocalization.yaml new file mode 100644 index 0000000000..0a3d48f4d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXdelocalization.yaml @@ -0,0 +1,83 @@ +category: base +doc: | + Base class to describe the delocalization of point-like objects on a grid. + + Such a procedure is for instance used in image processing and e.g. atom probe + microscopy (APM) to discretize a point cloud onto a grid to enable e.g. + computing of point density, composition, or concentration values, obtain + scalar fields, and compute gradients of these fields. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_p: Number of points/objects. + n_m: Number of mark data per point/object. + n_atoms: Number of atoms in the whitelist. + n_isotopes: Number of isotopes in the whitelist. +NXdelocalization: + grid: + doc: Reference or link to the grid on which the delocalization is applied. + objects: + doc: Reference or link to the points which are delocalized on the grid. + # for APM the speciality is nothing but: + # each point marks the location of an ion (object) in the tomographic reconstruction + # there is a boolean mask which filters which ions, i.e. points are considered + # plus there is a weight interpretation model, specifically in atom probe + # if a (molecular) ion is decomposed into its atoms or isotopes + # plus, given there is such a weight interpretation model, there is a weight + # associated, specifically an integer >= 1 with each considered ion and 0 for + # all ions which are not considered, + # this weight is the multiplicity with respect to the interpretation model + # i.e. a C:2 molecular ion has a multiplicity of 2 if the ion is considered + # and the interpretation model that to consider carbon atoms or carbon ions + weighting_model: + doc: | + The weighting model specifies how mark data are mapped to a weight per point. + For atom probe microscopy (APM) as an example, different models are used which + account differently for the multiplicity of an ion/atom: + + * default, points all get the same weight 1.; + for APM this is equivalent to ion species + * atomic_decomposition, points get as much weight as they have atoms + of a type in element_whitelist, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotope_whitelist. + + This description shows an example that could be reinterpreted for + similar such data processing steps in other fields of science. + enumeration: [default, atomic_decomposition, isotope_decomposition] + # other + # can one conditionally set a field required if a weighting_model has a + # specific value, + # i.e. if atomic_decomposition is set element_whitelist t is required + # i.e. if isotope_decomposition is set isotope_whitelist is required? + element_whitelist(NX_UINT): # optional for atom probe + doc: | + A list of elements (via proton number) to consider for the atomic_decomposition + weighting model. Elements must exist in the periodic table of elements. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_atoms]] + isotope_whitelist(NX_UINT): # optional for atom probe + doc: | + A list of isotopes to consider for the isotope_decomposition weighting model. + Isotopes must exist in the nuclid table. Entries in the fastest changing + dimension should be the pair of proton (first entry) and neutron number + (second entry). + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_isotopes], [2, 2]] + mark(NX_NUMBER): + doc: | + Attribute data for each member of the point cloud. For APM these are the + ion species labels generated via ranging. The number of mark data per + point is 1 in the case for atom probe. + dimensions: + rank: 2 + dim: [[1, n_p], [2, n_m]] + weight(NX_NUMBER): + doc: | + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point. For APM the weight are positive + integer values, specifically the multiplicity of the ion, + according to the details of the weighting_model. diff --git a/contributed_definitions/nyaml/NXdistortion.yml b/contributed_definitions/nyaml/NXdistortion.yml new file mode 100644 index 0000000000..873322a464 --- /dev/null +++ b/contributed_definitions/nyaml/NXdistortion.yml @@ -0,0 +1,54 @@ +category: base +symbols: + doc: "The symbols used in the schema to specify e.g. dimensions of arrays" + nsym: "Number of symmetry points used for distortion correction" + ndx: "Number of points of the matrix distortion field (x direction)" + ndy: "Number of points of the matrix distortion field (y direction)" +doc: "Subclass of NXprocess to describe post-processing distortion correction." +(NXdistortion): + last_process(NX_CHAR): + doc: "Indicates the name of the last operation applied in the NXprocess sequence." + applied(NX_BOOLEAN): + doc: "Has the distortion correction been applied?" + symmetry(NX_INT): + doc: | + For `symmetry-guided distortion correction`_, + where a pattern of features is mapped to the regular geometric structure expected + from the symmetry. Here we record the number of elementary symmetry operations. + + .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub + unit: NX_UNITLESS + original_centre(NX_FLOAT): + doc: + "For symmetry-guided distortion correction. Here we record the coordinates + of the symmetry centre point." + unit: NX_UNITLESS + dimensions: + dim: [[1, 2]] + rank: 1 + original_points(NX_FLOAT): + doc: + "For symmetry-guided distortion correction. Here we record the coordinates of + the relevant symmetry points." + unit: NX_UNITLESS + dimensions: + dim: [[1, nsym], [2, 2]] + rank: 2 + cdeform_field(NX_FLOAT): + doc: + "Column deformation field for general non-rigid distortion corrections. 2D matrix holding + the column information of the mapping of each original coordinate." + unit: NX_UNITLESS + dimensions: + dim: [[1, ndx], [2, ndy]] + rank: 2 + rdeform_field(NX_FLOAT): + doc: + "Row deformation field for general non-rigid distortion corrections. 2D matrix holding + the row information of the mapping of each original coordinate." + unit: NX_UNITLESS + dimensions: + dim: [[1, ndx], [2, ndy]] + rank: 2 + description(NX_CHAR): + doc: "Description of the procedures employed." diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml new file mode 100644 index 0000000000..9411816950 --- /dev/null +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -0,0 +1,55 @@ +category: base +doc: | + Container for components to form a controlled beam in electron microscopy. +# symbols: +# doc: The symbols used in the schema to specify e.g. variables. +NXebeam_column: + (NXfabrication): + electron_gun(NXsource): + doc: The source which creates the electron beam. + name: + doc: Given name/alias. + (NXfabrication): + voltage(NX_FLOAT): + doc: | + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + unit: NX_VOLTAGE + probe: + doc: Type of radiation. + enumeration: [electron] + emitter_type: + doc: | + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + enumeration: [filament, schottky, cold_cathode_field_emitter, other] + emitter_material: + doc: Material of which the emitter is build, e.g. the filament material. + ##MK could be made an instance of NXsample + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + # NEW ISSUE: details about the life/up-time of the source + # relevant from maintenance point of view + (NXtransformations): + doc: | + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + (NXaperture_em): + (NXlens_em): + (NXcorrector_cs): + # ebeam_deflector(NXscan_box_em): + (NXstage_lab): + (NXsensor): + doc: | + A sensor used to monitor an external or internal condition. + (NXbeam): + doc: | + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yml b/contributed_definitions/nyaml/NXelectronanalyser.yml new file mode 100644 index 0000000000..320880d9fd --- /dev/null +++ b/contributed_definitions/nyaml/NXelectronanalyser.yml @@ -0,0 +1,74 @@ +category: base +doc: "Subclass of NXinstrument to describe a photoelectron analyser." +symbols: + doc: "The symbols used in the schema to specify e.g. dimensions of arrays" + nfa: "Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity)" + nsa: "Number of slow axes (axes acquired scanning a pysical quantity)" +(NXelectronanalyser): + description(NX_CHAR): + doc: "Free text description of the type of the detector " + name(NX_CHAR): + doc: "Name or model of the equipment" + \@short_name(NX_CHAR): + doc: "Acronym or other shorthand name" + energy_resolution(NX_FLOAT): + doc: "Energy resolution of the electron analyser (FWHM of gaussian broadening)" + unit: NX_ENERGY + momentum_resolution(NX_FLOAT): + doc: "Momentum resolution of the electron analyser (FWHM)" + unit: NX_WAVENUMBER + angular_resolution(NX_FLOAT): + doc: "Angular resolution of the electron analyser (FWHM)" + unit: NX_ANGLE + spatial_resolution(NX_FLOAT): + doc: "Spatial resolution of the electron analyser (Airy disk radius)" + unit: NX_LENGTH + fast_axes(NX_CHAR): + doc: | + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + dimensions: + dim: [[1, nfa]] + rank: 1 + slow_axes(NX_CHAR): + doc: + "List of the axes that are acquired by scanning a physical parameter, listed + in order of decreasing speed. See fast_axes for examples." + dimensions: + dim: [[1, nsa]] + rank: 1 + depends_on(NX_CHAR): + doc: "Refers to the last transformation specifying the positon of the manipulator in the NXtransformations chain." + (NXtransformations): + doc: + "Collection of axis-based translations and rotations to describe the location and geometry of the electron analyser 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." + (NXcollectioncolumn): + doc: + "Describes the electron collection (spatial and momentum imaging) + column" + (NXenergydispersion): + doc: "Describes the energy dispersion section" + (NXspindispersion): + doc: "Describes the spin dispersion section" + (NXdetector): + doc: "Describes the electron detector" + (NXdeflector): + doc: "Deflectors outside the main optics ensambles described by the subclasses" + (NXlens_em): + doc: "Individual lenses outside the main optics ensambles described by the subclasses" diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml new file mode 100644 index 0000000000..df6070b4f8 --- /dev/null +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -0,0 +1,735 @@ +# 06/2022 +# A draft version of a NeXus application definition for ellipsometry. + +# The document has the following main elements: +# - Instrument used and is characteristics +# - Measured data, the discription of the sample and what was measured about it +# - Derived parameters: extra parameters derived in the measurement software + +category: application +doc: | + Ellipsometry, complex systems, up to variable angle spectroscopy. + + Information on ellipsometry is provided, e.g. in: + + * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, + John Wiley & Sons, 2007. + * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, + North-Holland Publishing Company, 1977. + * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, + William Andrew, 2005. + + Open access sources: + + * https://www.angstromadvanced.com/resource.asp + * https://pypolar.readthedocs.io/en/latest/ + + Review articles: + + * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", + J. Phys. D: Appl. Phys. 32, R45 (1999), + https://doi.org/10.1088/0022-3727/32/9/201 + * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", + Thin Solid Films 571, 334-344 (2014), + https://doi.org/10.1016/j.tsf.2014.03.056 + * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", + Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, + (3 October 1997), + https://doi.org/10.1117/12.283870 + * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", + Thin Solid Films 233, 96-111 (1993), + https://doi.org/10.1016/0040-6090(93)90069-2 + * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", + Adv. Opt. Techn., (2022), + https://doi.org/10.1515/aot-2022-0016 + +symbols: + doc: "Variables used throughout the document, e.g. dimensions and important parameters" + N_wavelength: "Size of the energy or wavelength vector used, the length of + NXinstrument/spectrometer/wavelength array" + N_variables: "How many variables are saved in a measurement. e.g. 2 for Psi + and Delta, 16 for Mueller matrix elements, 15 for normalized + Mueller matrix, 3 for NCS, the length of NXsample/column_names" + N_angles: "Number of incident angles used, the length of + NXinstrument/angle_of_incidence array" + + N_p1: + "Number of sample parameters scanned, if you varied any of the parameters + such as temperature, pressure, or pH, the maximal length of the arrays + specified by NXsample/environment_conditions/SENSOR/value if it exists." + N_time: "Number of time points measured, the length of NXsample/time_points" + +NXellipsometry: + (NXentry): + doc: | + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition defines: + + * elements of the experimental instrument + * calibration information if available + * parameters used to tune the state of the sample + * sample description + + definition: + doc: "An application definition for ellipsometry." + \@version: + doc: "Version number to identify which definition of this application + definition was used for this entry/data." + \@url: + doc: "URL where to find further material (documentation, examples) + relevant to the application definition" + enumeration: [NXellipsometry] + + experiment_identifier: + doc: | + Unique identifier of the experiment, such as a (globally persistent) unique + identifier. + i) The identifier is usually defined by the facility or principle investigator. + ii) The identifier enables to link experiments to e.g. proposals. + + experiment_description: + exists: recommended + doc: "A free-text description of the experiment. What is the aim of the + experiment? The general procedure." + + start_time(NX_DATE_TIME): + doc: "Start time of the experiment. UTC offset should be specified." + + acquisition_program(NXprocess): + exists: optional + program: + doc: "Commercial or otherwise defined given name to the program that was + used to generate the result file(s) with measured data and metadata. + This program converts the measured signals to ellipsometry data. If + home written, one can provide the actual steps in the NOTE subfield + here." + version: + doc: "Either version with build number, commit hash, or description of + a (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner." + \@url: + doc: "Website of the software." + + (NXuser): + exists: [min, 1] + doc: "Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users if relevant is recommended." + name: + doc: "Name of the user." + affiliation: + doc: "Name of the affiliation of the user at the point in time when the + experiment was performed." + address: + doc: "Full address (street, street number, ZIP, city, country) of the + user's affiliation." + email: + doc: "Email address of the user." + orcid: + exists: recommended + doc: "Author ID defined by https://orcid.org/." + telephone_number: + exists: recommended + doc: "Official telephone number of the user." + + (NXinstrument): + doc: "General properties of the ellipsometry equipment" + model: + doc: The name of the instrument + \@version: + doc: "The used version of the hardware if available. If not a + commercial instrument use date of completion of the hardware." + company: + exists: optional + doc: "Name of the company which build the instrument" + + construction_year(NX_DATE_TIME): + exists: optional + doc: "ISO8601 date when the instrument was constructed. + UTC offset should be specified." + + firmware: + doc: "Commercial or otherwise defined name of the software that was + used for the measurement" + \@version: + doc: "Version and build number or commit hash of the software source code" + \@url: + doc: "Website of the software." + + light_source(NXsource): + doc: "Specify the used light source. Multiple selection possible." + + #type: -- be added into the base class + # doc: "NXsource lists already possible sources, and here we list some + # further sources to complement the original list. Please select one or + # more, according to the setup" + # enumeration: [arc lamp, halogen lamp, LED, other] + + #target_material: + # doc: "unlike in the original, the material used to generate the light, that is + # argon, helium, neon, gases, or mercury/cadmium vapor, etc." + + focussing_probes(NX_BOOLEAN): + doc: "Were focussing probes (lenses) used?" + + data_correction(NX_BOOLEAN): + exists: optional + doc: "Were the recorded data corrected by the window effects of the lenses?" + + angular_spread(NX_NUMBER): + exists: optional + doc: "Specify the angular spread caused by the focussing probes" + unit: NX_ANGLE + + ellipsometry_type: + doc: "What type of ellipsometry was used? See Fujiwara Table 4.2" + enumeration: + [ + rotating analyzer, + rotating analyzer with analyzer compensator, + rotating analyzer with polarizer compensator, + rotating polarizer, + rotating compensator on polarizer side, + rotating compensator on analyzer side, + modulator on polarizer side, + modulator on analyzer side, + dual compensator, + phase modulation, + imaging ellipsometry, + null ellipsometry, + ] + + calibration_status(NX_CHAR): + doc: "Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + calibration/calibration_time." + enumeration: + [ + calibration time provided, + no calibration, + within 1 hour, + within 1 day, + within 1 week, + ] + + calibration(NXsubentry): + exists: recommended + doc: "Ellipsometers require regular calibration to adjust the hardware + parameters for proper zero values and background light compensation." + calibration_time(NX_DATE_TIME): + exists: optional + doc: "If calibtration status is 'calibration time provided', specify + the ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified." + + calibration_data(NXsubentry): + doc: "Arrays which provide the measured calibration data. + Multiple sets are possible, e.g. Psi and delta measured on a + e.g. silicon calibration wafer, and the straight-through data. + We recommend to provide data that is measured under the same + settings as the measurement was performed, that is if Psi and + Delta are measured for your data, also provide Psi and Delta + here and use the same wavelenghts as for the measured data." + + calibration_data_type: + doc: "What data were recorded for the calibration? + The number of variables (N_variables) have to be set to the + number of provided data columns accordingly, + e.g. psi/delta -> N_variables = 2, + Jones vector -> N_variables = 4, + Mueller martix -> N_variables = 16, etc." + enumeration: + [ + psi/delta, + tan(psi)/cos(delta), + Jones matrix, + Mueller matrix, + not provided, + ] + calibration_angle_of_incidence(NX_NUMBER): + doc: "Angle(s) of incidence used during the calibration measurement + (excluding straight through mode)" + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, N_calibration_angles]] + + calibration_wavelength(NX_NUMBER): + doc: | + The wavelength or equivalent values (which are inter-convertible). + The importer should convert all to one unit, and make the others + accessible. Historically, energy is used in eV, but for visible + spectroscopy wavelength is more common, for IR wave numbers in + 1/cm units. + + Possibly use the same type of data as for the measurement. + dimensions: + rank: 1 + dim: [[1, N_calibration_wavelength]] + + calibration_data(NX_NUMBER): + doc: "Calibration is performed on a reference surface (usually a + silicon wafer with a well defined oxide layer) at a number of + angles of incidence and in a straight through mode + (transmission in air)." + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: + [ + [1, N_calibration_angles+1], + [2, N_variables], + [3, N_calibration_wavelength], + ] + + calibration_sample(NX_CHAR): + doc: "Free-text to describe which sample was used for calibration, + e.g. silicon wafer with 25 nm thermal oxide layer." + + angle_of_incidence(NX_NUMBER): + doc: "Incident angle of the beam vs. the normal of the bottom + reflective (substrate) surface in the sample" + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, N_angles]] + + stage(NXsubentry): + doc: "Sample stage, holding the sample at a specific position in X,Y,Z + (Cartesian) coordinate system and at an orientation defined + by three Euler angles (alpha, beta, gamma). + The stage may be motorized or manual, special for liquids or gas + environment." + stage_type(NX_CHAR): + doc: "Specify what type of stage was used." + enumeration: + [manual stage, scanning stage, liquid stage, gas cell, cryostat] + + description: + doc: "A free-text field to provide information about the stage." + exists: recommended + (NXtransformations): + exists: recommended + doc: "The stage coordinate system vs. the incident beam. The Z-axis + of the stage is considered to point along the normal of the + substrate (bottom reflecting surface) from the stage towards + the general direction of the light source. The beam comes with + the angle of incidence towards this Z-axis, but in opposite + direction, thus they are connected with a rotation of + 180 - angle of incidence (in degrees). + + This transformation brings us from the NEXUS coordinates to the + stage coordinates. + + Then provide the set of translations (if there are any). These + all have a vector defining their relative direction in the + current coordinate system. (This current coordinate system + changes with every transformation if you set the parameter + 'depends' to the name of the previous step.) + + Last, provide the rotations of the sample" + + alternative: + exists: optional + doc: "If there is no motorized stage, we should at least qualify + where the beam hits the sample and in what direction the + sample stands in a free-text description, e.g. 'center of + sample, long edge parallel to plane of incidence'." + + window(NXaperture): + exists: optional + doc: "For environmental measurements, the environment (liquid, vapor, + vacuum etc.) is enclosed in a cell or cryostat, which has windows + both in the direction of the source and the detector (looking + from the sample). These windows also add a phase shift to the + light altering the measured signal. This shift has to be + corrected based on measuring a known sample in the environmental + cell." + + material(NX_CHAR): + doc: The material of the window + enumeration: + [ + quartz, + diamond, + calcium fluoride, + zinc selenide, + thallium bromoiodide, + alkali halide compound, + Mylar, + other, + ] + + other_material(NX_CHAR): + exists: optional + doc: "If you specified 'other' as window material, decsribe here + what it is." + + thickness(NX_NUMBER): + doc: Thickness of the window + unit: NX_LENGTH + + orientation_angle(NX_NUMBER): + doc: "Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence)." + unit: NX_ANGLE + + reference_data(NXsubentry): + doc: "Recorded data that can be used to calculate the window effect. + Typically this is the substrate (e.g. silicon with thermal + oxide layer) in air without window and in a known medium with + the window." + + reference_sample: + doc: "What sample was used to estimate the window effect?" + + reference_wavelength(NX_NUMBER): + doc: "Wavelength of the reference data. Use the same wavelengths + at which all other measurements are recorded" + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, N_wavelength]] + + data(NX_NUMBER): + exists: recommended + doc: "Recorded data of a reference surface with and without window/medium." + unit: NX_UNITLESS + dimensions: + rank: 4 + dim: [[1, 2], [2, N_angles], [3, N_variables], [4, N_wavelength]] + + (NXdetector): + doc: "Which type of detector was used, and what is known about it? + A detector can be a photomultiplier (PMT), a CCD in a camera, or + an array in a spectrometer. If so, the whole detector unit goes + in here. + Integration time is the count time field, or the real time + field. See their definition." + + detector_type: + doc: "What kind of detector module is used, e.g. CCD-spectrometer, + CCD camera, PMT, photodiode, etc." + enumeration: + [ + PMT, + photodiode, + avalanche diode, + CCD camera, + CCD spectrometer, + other, + ] + + other_detector: + exists: optional + doc: "If you specified 'other' as detector type, please write down + what it is." + + revolution(NX_NUMBER): + exists: optional + doc: "Define how many rotations of the rotating element were taken + into account per spectrum." + unit: NX_ANY + + rotating_element: + doc: "Define which element rotates, e.g. polarizer or analyzer." + enumeration: + [ + polarizer (source side), + analyzer (detector side), + compensator (source side), + compensator (detector side), + ] + + fixed_revolution(NX_NUMBER): + exists: optional + doc: "Rotation rate, if the revolution does not change during + the measurement." + unit: NX_FREQUENCY + + variable_revolution(NX_NUMBER): + exists: optional + doc: "Specify maximum and minimum values for the revolution." + dimensions: + rank: 1 + dim: [[1, 2]] + + intensity_threshold(NX_NUMBER): + exists: optional + doc: "Minimum signal for which dynamic averaging is performed." + unit: NX_UNITLESS + + min_intensity(NX_NUMBER): + exists: optional + doc: "Value for the minimum intensity chosen. + Data points below this value might be skipped by the instrument" + unit: NX_UNITLESS + + spectrometer(NXmonochromator): + doc: "The spectroscope element of the ellipsometer before the detector, + but often integrated to form one closed unit. Information on the + dispersive element can be specified in the subfield GRATING. Note + that different gratings might be used for different wavelength + ranges. The dispersion of the grating for each wavelength range + can be stored in grating_dispersion." + + wavelength(NX_NUMBER): + doc: "Wavelength value(s) used for the measurement. + An array of 1 or more elements. Length defines N_wavelength" + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, N_wavelength]] + + (NXgrating): + exists: optional + doc: "Diffraction grating, as could be used in a monochromator. + If two or more gratings were used, define the angular + dispersion and the wavelength range (min/max wavelength) + for each grating and make sure that the wavelength ranges + do not overlap. The dispersion should be defined for the + entire wavelength range of the experiment." + + angular_dispersion(NX_NUMBER): + exists: optional + doc: "Dispersion of the grating in nm/mm used." + + grating_wavelength_min(NX_NUMBER): + exists: optional + doc: "Minimum wavelength of the grating." + unit: NX_LENGTH + + grating_wavelength_max(NX_NUMBER): + exists: optional + doc: "Maximum wavelength of the grating." + unit: NX_LENGTH + + spectral_resolution(NX_NUMBER): + exists: optional + doc: "Spectral resolution of the instrument." + unit: NX_WAVENUMBER + + (NXslit): + exists: optional + doc: "Define the width of the monochromator slit in the subfield x_gap." + + fixed_slit(NX_BOOLEAN): + exists: optional + doc: "Was the slit width fixed?" + + max_gap(NX_NUMBER): + exists: optional + doc: "If slit width was not fixed, define the maximum slit width." + unit: NX_LENGTH + + (NXsample): + doc: "Properties of the sample, its history, the sample environment and + experimental conditions (e.g. surrounding medium, temperature, + pressure etc.), along with the data (data type, wavelength array, + measured data)." + atom_types: + doc: "Use Hill's system for listing elements of the periodic table + which are inside or attached to the surface of the specimen + and thus relevant from a scientific point. The purpose of this + field is to allow material databases to parse the relevant + elements without having to interpret the sample history or other + fields." + sample_name: + doc: "Descriptive name of the sample" + + sample_history: + doc: "Ideally, a reference to the location or a unique (globally + persistent) identifier (e.g.) of e.g. another file which gives + as many as possible details of the material, its microstructure, + and its thermo-chemo-mechanical processing/preparation history. + In the case that such a detailed history of the sample is not + available, use this field as a free-text description to specify + details of the sample and its preparation." + + preparation_date(NX_DATE_TIME): + exists: recommended + doc: "ISO8601 date with time zone (UTC offset) specified." + + layer_structure: + doc: "Qualitative description of the layer structure for the sample. + For example: Si/native oxide/thermal oxide/polymer/peptide" + + data_identifier(NX_NUMBER): + doc: "An identifier to correlate data to the experimental conditions, + if several were used in this measurement; + typically an index of 0 - N" + + data_type: + doc: "Select which type of data was recorded, for example Psi and Delta + (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). + It is possible to have multiple selections. Data types may also be + converted to each other, e.g. a Mueller matrix contains N,C,S data + as well. This selection defines how many columns (N_variables) are + stored in the data array." + enumeration: + [ + psi/delta, + tan(psi)/cos(delta), + Mueller matrix, + Jones matrix, + N/C/S, + raw data, + ] + + column_names: + doc: + "Please list in this array the column names used in your actual data. + That is ['psi', 'delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for + a full Mueller matrix, etc." + dimensions: + rank: 1 + dim: [[1, N_variables]] + + measured_data(NX_NUMBER): + doc: "Resulting data from the measurement, described by data type. + Minimum two columns containing Psi and Delta, or for the normalized + Mueller matrix it may be 16 (or 15 if the element (1,1) is all 1)." + dimensions: + rank: 5 + dim: + [ + [1, N_time], + [2, N_p1], + [3, N_angles], + [4, N_variables], + [5, N_wavelength], + ] + + data_error(NX_NUMBER): + doc: + "Specified uncertainties (errors) of the data described by data type. + The structure is the same as for the measured data." + exists: recommended + dimensions: + rank: 5 + dim: + [ + [1, N_time], + [2, N_p1], + [3, N_angles], + [4, N_variables], + [5, N_wavelength], + ] + + time_points(NX_NUMBER): + exists: optional + doc: "An array of relative time points if a time series was recorded." + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, N_time]] + + environment_conditions(NXenvironment): + doc: "Specify external parameters that have influenced the sample." + + medium: + doc: "Describe what was the medium above or around the sample. The + common model is built up from the substrate to the medium on the + other side. Both boundaries are assumed infinite in the model. + Here, define the name of the medium (e.g. water, air, UHV, etc.)." + + medium_refractive_indices(NX_NUMBER): + exists: optional + doc: "Array of pairs of complex refractive indices of the medium for + every measured wavelength. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + Specify the complex refractive index: n + ik" + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, N_wavelength]] + + number_of_runs(NX_UINT): + exists: optional + doc: "How many measurements were done varying the parameters? This + forms an extra dimension beyond incident angle, time points and + energy/wavelength (this is the length of the 4th dimension of + the data). Defaults to 1." + unit: NX_DIMENSIONLESS + + varied_parameters: + exists: optional + doc: "Indicates which parameter was changed. Its definition must exist + below. The specified variable has to be number_of_runs long, + providing the parameters for each data set. If you vary more than + one parameter simultaneously use one signal instance for each. + Record every parameter value in a linear manner, so N_p1 is the + number of measurements taken. + For example, if you measure at two temperatures and three pressures + the temperature signal value looks like [T1, T1, T1, T2, T2, T2] + and the pressure signal value looks like [p1, p2, p3, p1, p2, p3], + and N_p1 = 6." + enumeration: + [ + optical excitation, + voltage, + temperature, + pH, + stress, + stage positions, + ] + + optical_excitation(NXsource): + exists: optional + doc: + "Was the sample modified using an optical source? Describe in this + group the parameters of the optical excitation used." + + wavelength(NX_NUMBER): + doc: "Wavelength value(s) or the range used for excitation. + In cases of continuous laser radiation, a value or a set of + values may do but for other illumination types, such as pulsed + lasers, or lamps, a range may describe the source better." + unit: NX_LENGTH + + broadening(NX_NUMBER): + exists: optional + doc: "Specify the FWHM of the excitation" + unit: NX_LENGTH + + duration(NX_NUMBER): + exists: optional + doc: "How long was the sample excited." + unit: NX_TIME + + pulse_energy(NX_NUMBER): + exists: optional + doc: "The integrated energy of light pulse." + unit: NX_ENERGY + + (NXsensor): + exists: optional + doc: "A sensor used to monitor an external condition. The value + field contains the measured values. If it is constant within + an error for every run then use only an array of length one." + + derived_parameters(NXprocess): + exists: optional + doc: "What parameters are derived from the above data." + depolarization(NX_NUMBER): + exists: optional + doc: "Light loss due to depolarization as a value in [0-1]." + unit: NX_UNITLESS + + plot(NXdata): + exists: optional + doc: "A default view of the data, in this case Psi vs. wavelength and + the angles of incidence. If Psi does not exist, use other Mueller + matrix elements, such as N, C and S." + \@axes: + doc: "We recommend to use wavelength as a default attribute, but it + can be replaced in the case of not full spectral ellipsometry + to any suitable parameter along the X-axis." diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml new file mode 100644 index 0000000000..4c855eeb12 --- /dev/null +++ b/contributed_definitions/nyaml/NXem.yaml @@ -0,0 +1,1131 @@ +category: application +doc: | + Characterization and session with one sample in an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM), whether it be with scanning electron microscope (SEM) + or transmission electron microscope (TEM) instruments, are versatile tools for + preparing and characterizing samples and specimens. The term specimen is considered + a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating either the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an EM is an electron accelerator. Experimentalists use an EM + in sessions during which they characterize as well as prepare specimens. + This application definition describes data and metadata about processes and + characterization tasks applied to one specimen. The application definition + focuses on the usage of EM in materials research. The application definition + design makes it in principle applicable also in cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple NXentry instances. + + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process maybe even operating + the microscope. Oftentimes the scientists operate the instrument themselves + either on-site or remotely and can ask technicians for support. + In all cases, these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate application + definitions for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is used mainly to measure the + transmitted electron beam. This calls for using a different lens setup and + relative placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to illuminate + through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Compared to SEMs, TEMs have a different relative arrangement between the + lenses and the specimen which is most obvious by the different relative + arrangement of the objective lens versus the specimen. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Consequently, detectors can also be similar + if not exactly the same. + + **An embracing schema instead of specific SEM or TEM schemes**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower + the addressed user base is which develops or uses schemes for research data + management (RDM) with EM, the more understandable it is that scientists of + either community (or sub-community) ask for method-specific schemes. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemes such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the development in the past has shown that these activities led to + a zoo of schemes and especially vocabulary in use with implementations of these + into many data and file formats. There is nothing which prevents the communities + to make these schemes open and interoperable. Open here means specifically not + that all data are compliant with/or use the schema and have to end up in the + open-source domain. There can be embargo periods first of all. + + Open means that the metadata and associated schemata are documented in a manner + that as many details as possible are open in the sense that others can understand + what the (meta)data mean conceptually. Instead of trying of maintain a zoo + of eventually difficult to make interoperable formats and schema we would like + to advocate that the `FAIR principles `_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different + schemes with associated representations of data and metadata in EM: + Each combination of schemes or an interoperable-made handshake between two + file formats or software packages has to be maintained by software developers. + This counts especially when data should be processed interoperably + between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. `_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemes and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemes. + + Aiming for more standardization, i.e. a lower number of schemes rather than + a single standard for electron microscopy is a compromise that can serve + academia as it enables the EM community to focus their software development + efforts on those schemes, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for vendors of EM hard- and software as it improves the longevity of certain + schema; and thus can help to incentivize vendors to support the community with + implementing support for such schemes into their proprietary applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemes for EM research. + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemes differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemes can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be software from specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions and strictly speaking an application definition can only be + really general if it does not make a single entry required, in which case however + it would also not offer much value as even empty datasets would be compliant. + + **Verification of constraints and conditions**: + Tools like NeXus so far do not avoid or protect against all such possible + inconsistencies; however NeXus offers a mechanism and toolset, through which + schemes can be documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + This application definition takes a key step towards standardization of EM data. + It offers a controlled vocabulary and relation between concepts and data + relevant for research with electron microscopes. To be most efficient and + offering reusability, the application definition should be understood as a + template that one should ideally use as is. This application definition + is called NXem. NXem can be considered a base for designing more specialized + definitions (ideally prefixed with NXem) *method*. + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but make + them optional or, even better, propose changes in this NXem application definition. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as vendors also have a relevant interest in finding + a compromise between being open to their user and securing their business. + + EM experiments by design illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being vendor-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + often undocumented in detail by vendors. This serves users and makes EM + experiments easier understandable and conveniently executable for a broad + user base. On the flipside these subtilities limit the opportunities for + making application definitions too general. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemes. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what are metadata in EM. While doing + so we found that existent terminology can be encoded into a more controlled + vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Generic experimental details (time-zone-aware timestamp, identifiers, name); + conceptually these are session details. A session at a microscope may + involve the characterization of multiple specimens. For each specimen + an instance of an (NXentry) is created. Details of the instrument have to + be stored at least in an entry. Other entries should refer to these + metadata via links to reduce redundancies. + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of NXevent_data_em have an own em_lab section. + The reason is that EMs can be highly dynamic, be used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * NXmonitor; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. Alternatively, NXevent_data_em + instances can be used to store time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * NXinstrument; + conceptually this is a container to store arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * NXuser; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details who executed an event of data acquisition or processing. + * NXevent_data_em instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * NXdata; at the top-level, conceptually, this is a place for documenting + available default plottable data. A default plottable can be useful for + research data management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables not intended to serve every possible analysis and + visualization demand but be a preview. We made this choice because what constitutes + a useful default plot is often a matter of interpretation, somewhat of personal taste, + and community standards. In effect, default plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals and + images. Examples for possible default plottables could be arbitrarily + taken secondary, back-scattered, electron image, diffraction pattern, + EELS spectra, composition, or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Above images, spectra, and mappings should be stored as NXdata instances, + ideally formatted in such a way that they can be displayed with + visualization software that can be specific for the file format in which + the data are stored. NeXus specifies only the data model, i.e. the terms + and their relations. These descriptions can be implemented and stored in + JSON, HDF5, XML, or HSDS, file storage, or even other formats, although + HDF5 is often used. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images of electron counts detected in specific operation modes (bright + field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) + * Spectra (X-ray quanta or Auger electron counts) + * These data are in virtually all cases a result of some numerical processing. + It makes sense to name these data and processing tasks with a controlled vocabulary, + e.g. SE (secondary electron), BSE (back-scattered electron), Kikuchi, + X-ray, Auger, Cathodolum(inescence) etc. + + A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk). To this end the schema, here makes no + specific assumptions, not even that all the fields/group of a schema instance + have to be stored at all into a single file. Instead, the schema specifies the + relations between metadata, some of the constraints and conditions on how the data + should be formatted, what the data conceptually represent, and which terms + (controlled vocabulary) is practical to store to index specific quantities. + + In effect, the application definition is a graph which describes how + numerical data and (meta)data for EM research are related to one another. +# While an important +# step this will still need in the future a mechains +# So far Essentially when the docstrings are no longer needed +# but can be replaced by a connection to an automated tool which understands +# what a specific field represents conceptually, EM data have become more +# generally interoperable EM data. +# NEW ISSUE: see duration and collection time, duty cycle +# NEW ISSUE: duration and collection_time needs a clearer description and +# definition by the community +# NEW ISSUE: should version always be an enumeration? +# NEW ISSUE: filter keywords \(.*?\) +# NEW ISSUE: NXdetector adding only those fields which have changed or not? +# symbols: +# the NeXus default for application definitions wrt to the exists keyword is +# that it is required +NXem: + (NXentry): + exists: [min, 1, max, infty] + # NEW ISSUE: the definition field and its version attribute enumeration + # NEW ISSUE: will be added by yaml2nxdl automatically + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + # enumeration: [sha_256_hash] + definition: + doc: NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier: + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + experiment_description: + exists: optional + doc: | + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + start_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_em instances to + provide additional pieces of information. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + program: + doc: | + Commercial or otherwise given name to the program which was used to + create the file. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual NXprocess + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + \@version: + doc: | + Program 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. + experiment_documentation(NXnote): + exists: optional + doc: | + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + thumbnail(NXnote): + exists: optional + doc: | + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + \@type: + (NXuser): + exists: [min, 1, max, infty] + doc: | + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + name: + doc: Given (first) name and surname of the user. + affiliation: + exists: recommended + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address: + exists: recommended + doc: Postal address of the affiliation. + email: + exists: recommended + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + orcid: + exists: recommended + doc: | + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + orcid_platform: + exists: recommended + doc: | + Name of the OrcID or ResearcherID where the account + under orcid is registered. + telephone_number: + exists: optional + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role: + exists: recommended + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + social_media_name: + exists: optional + doc: | + Account name that is associated with the user in social media platforms. + social_media_platform: + exists: optional + doc: | + Name of the social media platform where the account + under social_media_name is registered. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by the RDM graph management system + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + method: + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + name: # MK: for now the ID + doc: | + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + sample_history: + doc: | + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a sub-set + of the entire sample history, i.e. what you would consider are the key steps + and relevant information about the specimen, its material, microstructure, + thermo-chemo-mechanical processing state, and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly discouraged + because it leads to eventually non-machine-actionable + data. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over for + the analysis. At the point it enters the microscope the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + short_title: + exists: optional + doc: | + Possibility to give an abbreviation or alias of the specimen name field. + atom_types: + doc: | + Use Hill's system for listing elements of the periodic table which are inside or attached + to the surface of the specimen and thus relevant from a scientific point of view. + + The purpose of the field is to offer materials database systems an opportunity to parse + the relevant elements without having to interpret these from the sample history. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_FLOAT): + doc: | + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague, spatio-temporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # simple could be problematic or not decision, it is also these descriptors if remaining vague are also not useful + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + description: + exists: optional + doc: | + Discouraged free-text field in case properly designed records + for the sample_history are not available. + density(NX_FLOAT): + exists: optional + doc: | + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an NXinteraction_vol_em for + individual NXevent_data_em instances can provide a much better description + of the relevant details why one would otherwise ask to store the density + of the specimen. + unit: NX_ANY + # \@units: g/cm^3 + (NXdata): + exists: optional + doc: | + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + (NXcoordinate_system_set): + exists: recommended + TRANSFORMATIONS(NXtransformations): + # in what follows each component of the instrument might be equipped with an NXmonitor + (NXmonitor): + exists: optional + # NEW ISSUE ADD AS MANY MONITORS AS NEEDED, also for pressure etc. + + # in what follows, an as-detailed as desired collection of components + # making up the instrument follows at this level of the hierarchy + em_lab(NXinstrument): + doc: | + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_em sections. These event instances take the role of time snapshot. + For an NXevent_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_gun group + again the details of the gun type and manufacturer but only the high-voltage + if for that event the high-voltage was different. If for all events + the high-voltage was the same it is not even necessary to include an electron_gun + section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + instrument_name: + doc: | + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + location: + exists: optional + doc: | + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + (NXfabrication): + identifier: + exists: recommended + capabilities: + exists: optional + (NXebeam_column): + exists: [min, 1, max, 1] + (NXfabrication): + exists: recommended + identifier: + exists: recommended + electron_gun(NXsource): + name: + exists: recommended + (NXfabrication): + exists: recommended + identifier: + exists: recommended + voltage(NX_FLOAT): + emitter_type: + (NXaperture_em): + exists: recommended + (NXfabrication): + exists: recommended + identifier: + exists: recommended + value(NX_NUMBER): + name: + description: + exists: optional + (NXlens_em): + exists: recommended + doc: | + If the lens is described at least one of the fields + voltage, current, or value should be defined. + # a classical case where we want at least one field of multiple to exist + (NXfabrication): + exists: recommended + identifier: + exists: recommended + voltage(NX_NUMBER): + exists: recommended + current(NX_NUMBER): + exists: recommended + value(NX_NUMBER): + exists: recommended + aberration_correction(NXcorrector_cs): + exists: recommended + applied(NX_BOOLEAN): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: recommended + (NXaberration): + exists: recommended + c_1_0(NX_FLOAT): + exists: recommended + c_1_2_a(NX_FLOAT): + exists: recommended + c_1_2_b(NX_FLOAT): + exists: recommended + c_2_1_a(NX_FLOAT): + exists: recommended + c_2_1_b(NX_FLOAT): + exists: recommended + c_2_3_a(NX_FLOAT): + exists: recommended + c_2_3_b(NX_FLOAT): + exists: recommended + c_3_0(NX_FLOAT): + exists: recommended + c_3_2_a(NX_FLOAT): + exists: recommended + c_3_2_b(NX_FLOAT): + exists: recommended + c_3_4_a(NX_FLOAT): + exists: recommended + c_3_4_b(NX_FLOAT): + exists: recommended + c_5_0(NX_FLOAT): + exists: recommended + (NXibeam_column): + exists: [min, 0, max, 2] + (NXfabrication): + exists: recommended + identifier: + exists: recommended + ion_gun(NXsource): + name: + exists: recommended + (NXfabrication): + exists: recommended + identifier: + exists: recommended + emitter_type: + probe(NXion): + isotope_names(NX_UINT): + charge_state(NX_INT): + exists: optional + voltage(NX_FLOAT): + current(NX_FLOAT): + (NXaperture_em): + exists: recommended + (NXfabrication): + exists: recommended + identifier: + exists: recommended + value(NX_NUMBER): + (NXlens_em): + exists: recommended + doc: | + If the lens is described at least one of the fields + voltage, current, or value should be defined. + (NXfabrication): + exists: recommended + identifier: + exists: recommended + voltage(NX_NUMBER): + exists: recommended + current(NX_NUMBER): + exists: recommended + value(NX_NUMBER): + exists: recommended + ebeam_deflector(NXscanbox_em): + exists: recommended + (NXfabrication): + exists: recommended + identifier: + exists: recommended + pixel_time(NX_FLOAT): + exists: recommended + ibeam_deflector(NXscanbox_em): + exists: recommended + (NXfabrication): + exists: recommended + identifier: + exists: recommended + (NXoptical_system_em): + exists: recommended + camera_length(NX_NUMBER): + exists: optional + magnification(NX_NUMBER): + exists: optional + defocus(NX_NUMBER): + exists: recommended + semi_convergence_angle(NX_NUMBER): + exists: recommended + working_distance(NX_FLOAT): + exists: recommended + beam_current(NX_FLOAT): + exists: recommended + beam_current_description: + exists: recommended + # vendor/instrument-specific data currently case-by-case dependent + # e.g. Nion Co. magboard settings + # instances of NXoptical system can be placed here and specific for + # each NXevent_data_em instance if desired + (NXdetector): + # ##MK::eventually only adding (NXfabrication) and the new docstring + # is needed, will the rest be inferred automatically? + exists: [min, 1, max, infty] + doc: | + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + type: + doc: Free text option to write further details about the detector. + (NXfabrication): + exists: recommended + identifier: + exists: recommended + (NXpump): + exists: [min, 0, max, infty] + # NEW ISSUE: do we consider the EELS spectrometer an own detector or an own functional unit i.e. NXeels + stage_lab(NXstage_lab): + name: + (NXfabrication): + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + design: + exists: recommended + description: + exists: optional + # tricky for arbitrary design we cannot enforce all the below to exist at all + position(NX_FLOAT): + exists: recommended + rotation(NX_FLOAT): + exists: recommended + tilt_1(NX_FLOAT): + exists: recommended + tilt_2(NX_FLOAT): + exists: recommended + measurement(NXevent_data_em_set): + exists: [min, 0, max, 1] + ##MK because it should be possible to use the application definition + ##MK to store e.g. just some descriptions about the instrument + ##MK:with which then no measurements are attached + # this would enable to use nxs file also for instrument inventory + # system like offer through ELNs/or LIMS + doc: | + A container to structure a set of NXevent_data_em instances. + + An event is a time point/time interval during which the microscope + was configured in a specific way and the microscope was used + to take a measurement. The microscope is considered stable during this + interval. + + Each NXevent_data_em instance holds an acquisition task with the microscope. + For instance the capturing of a secondary electron, backscattered + electron, diffraction image, or spectrum. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed into consumable data like images, spectra, + etc. These on-the-fly data processing tasks are usually performed + by the control software, eventually realized with custom scripts. + + Furthermore, NXevent_dat_em instances can document specific values + and settings of the microscope during the snapshot/event. + (NXevent_data_em): + exists: [min, 1, max, infty] + doc: | + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_em instances can hold several specific + NXimage_em or NXspectrum_em instances taken and considered as + one event, i.e. a point in time when the microscope had the + settings specified either in NXinstrument or in this NXevent_data_em + instance. + + The application definition is designed without an explicit need + an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. An NXevent_data_em can be used to document a + specific state of the microscope at a time without having it placed + into the NXinstrument group. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there is no vendor-overarching standard according to which + electron microscope data are documented and stored. Therefore, it is + still a frequently the case that vendor-specific files have many fields + that cannot be safely mapped. Therefore, users are always adviced to + keep the vendor files. Working however with these vendor files inside + specific software, like materials databases, demands for parsers which + extract pieces of information from the vendor representation (numerical + data and metadata) and map them on a schema with which the database + and its associated software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented dynamically, coveringly enough in our opinion so that it is + safe to assume all vendor field names are known, logically understood, + interpretable, and thus mappable on a common schema using a controlled + common vocabulary. + + Therefore we encourage user for now to store for each image_set_em + or spectra_set_em instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain like numerical data and metadata were copied into an instance + of this schema for the purpose of working with the data in e.g. tools + offered by the materials database. + + During work on implementing file format/metadata parsers and developing + this application definition we realized that several software tools + currently do not consistently track time-zone-aware timestamps of + events associated with the data, processing, and during the microscope + session. This is in partly a consequence of vendor which store + detailed time data in different formats. We would like to encourage the + community and especially the vendors to work towards a standardization, + or at least a open documentation of the way how time-zone-aware time + data are collected and stored how and where during a microscope session + and how they end up in files and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + event_identifier: + exists: recommended + doc: | + Reference to a specific state and setting of the microscope components. + event_type: + exists: recommended + detector_identifier: + exists: recommended + doc: | + The detector or set of detectors that was used to collect this signal. + The name of the detector has to match one of the names of available + NXdetector instances e.g. if the instrument has an ebsd_camera + the detector for an NXimage_em_kikuchi should be the NXdetector + instance called ebsd_camera. + # a collection of images take and group under this event + # NEW ISSUE: should this only be one instance for a given event? + (NXimage_set_em_se): + exists: optional + (NXimage_set_em_bse): + exists: optional + (NXimage_set_em_bf): + exists: optional + (NXimage_set_em_df): + exists: optional + (NXimage_set_em_adf): + exists: optional + (NXimage_set_em_kikuchi): + exists: optional + (NXspectrum_set_em_xray): + exists: optional + (NXspectrum_set_em_eels): + exists: optional + (NXspectrum_set_em_auger): + exists: optional + (NXspectrum_set_em_cathodolum): + exists: optional + (NXimage_set_em_ecci): + exists: optional + (NXimage_set_em_diffrac): + exists: optional + (NXimage_set_em_ronchigram): + exists: optional + (NXimage_set_em_chamber): + exists: optional + + # a collection of specific details about state of the microscope + em_lab(NXinstrument): + (NXebeam_column): + exists: [min, 0, max, 1] + electron_gun(NXsource): + exists: optional + voltage(NX_FLOAT): + (NXaperture_em): + exists: optional + value(NX_NUMBER): + (NXlens_em): + exists: optional + voltage(NX_NUMBER): + exists: recommended + current(NX_NUMBER): + exists: recommended + value(NX_NUMBER): + exists: recommended + (NXcorrector_cs): + exists: optional + applied: + (NXaberration): + exists: recommended + c_1_0(NX_FLOAT): + exists: recommended + c_1_2_a(NX_FLOAT): + exists: recommended + c_1_2_b(NX_FLOAT): + exists: recommended + c_2_1_a(NX_FLOAT): + exists: recommended + c_2_1_b(NX_FLOAT): + exists: recommended + c_2_3_a(NX_FLOAT): + exists: recommended + c_2_3_b(NX_FLOAT): + exists: recommended + c_3_0(NX_FLOAT): + exists: recommended + c_3_2_a(NX_FLOAT): + exists: recommended + c_3_2_b(NX_FLOAT): + exists: recommended + c_3_4_a(NX_FLOAT): + exists: recommended + c_3_4_b(NX_FLOAT): + exists: recommended + c_5_0(NX_FLOAT): + exists: recommended + (NXibeam_column): + exists: [min, 0, max, 2] + ion_gun(NXsource): + exists: optional + emitter_type: + exists: recommended + probe(NXion): + exists: recommended + isotope_names(NX_UINT): + exists: recommended + charge_state(NX_INT): + exists: optional + voltage(NX_FLOAT): + exists: recommended + current(NX_FLOAT): + exists: recommended + (NXaperture_em): + exists: optional + value(NX_NUMBER): + exists: recommended + (NXlens_em): + exists: optional + voltage(NX_NUMBER): + exists: recommended + current(NX_NUMBER): + exists: recommended + value(NX_NUMBER): + exists: recommended + ebeam_deflector(NXscanbox_em): + exists: optional + pixel_time(NX_FLOAT): + exists: recommended + ibeam_deflector(NXscanbox_em): + exists: optional + (NXoptical_system_em): + exists: optional + camera_length(NX_NUMBER): + exists: optional + magnification(NX_NUMBER): + exists: optional + defocus(NX_NUMBER): + exists: recommended + semi_convergence_angle(NX_NUMBER): + exists: recommended + working_distance(NX_FLOAT): + exists: recommended + beam_current(NX_FLOAT): + exists: recommended + beam_current_description: + exists: recommended + (NXdetector): + exists: optional + # dynamically changing detector settings uses only during this NXevent_data_em + (NXpump): + exists: optional + (NXstage_lab): + # tricky for arbitrary design we cannot enforce all the below to exist at all + position(NX_FLOAT): + exists: recommended + rotation(NX_FLOAT): + exists: recommended + tilt_1(NX_FLOAT): + exists: recommended + tilt_2(NX_FLOAT): + exists: recommended + (NXuser): + exists: optional + name: + (NXinteraction_vol_em): + exists: optional diff --git a/contributed_definitions/nyaml/NXenergydispersion.yml b/contributed_definitions/nyaml/NXenergydispersion.yml new file mode 100644 index 0000000000..4bc9702509 --- /dev/null +++ b/contributed_definitions/nyaml/NXenergydispersion.yml @@ -0,0 +1,37 @@ +category: base +doc: "Subclass of NXelectronanalyser to describe the energy dispersion section + of a photoelectron analyser." +(NXenergydispersion): + scheme(NX_CHAR): + doc: "Energy dispersion scheme employed, for example: + tof, hemispherical, cylindrical, mirror, retarding grid, etc." + pass_energy(NX_FLOAT): + doc: "Energy of the electrons on the mean path of the analyser. + Pass energy for hemispherics, drift energy for tofs." + unit: NX_ENERGY + center_energy(NX_FLOAT): + doc: "Center of the energy window" + unit: NX_ENERGY + energy_interval(NX_FLOAT): + doc: + "The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector containing + the extrema of the transmitted energy window (smaller number first). With a + swept scan of m steps it is a 2xm array of windows one for each measurement + point." + unit: NX_ENERGY + (NXaperture): + doc: "Size, position and shape of a slit in dispersive analyzer, e.g. entrance and exit slits." + diameter(NX_FLOAT): + doc: "Diameter of the dispersive orbit" + unit: NX_LENGTH + energy_scan_mode(NX_CHAR): + doc: "Way of scanning the energy axis (fixed or sweep)." + enumeration: ["fixed", "sweep"] + tof_distance(NX_FLOAT): + doc: "Length of the tof drift electrode" + unit: NX_LENGTH + (NXdeflector): + doc: "Deflectors in the energy dispersive section" + (NXlens_em): + doc: "Individual lenses in the energy dispersive section" diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml new file mode 100644 index 0000000000..d019254150 --- /dev/null +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -0,0 +1,210 @@ +category: base +doc: | + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations caused or apertures used. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then choose a different value. As the aperture affects + the electron beam it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of objects, + and eventually (externally) applied stimuli and positioning of the specimen. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Theoretically, an instrument and specimen should be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + stable and of high enough quality to reuse data collection. + + In all these cases it is practical to store time-dependent data of the + instrument state not in the respective instrument component groups + of the top-level NXinstrument but in a sort of a log of event data. + This is the idea behind the NXevent_data_em snapshot containers. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + But does this warrant to document the microscope state at an even finer + and impractical in-between one collects signal time intervals? + + This is a question of how finely does one granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and illuminates a portion of the material, i.e. + the interaction volume, whose signal contributions are then counted by the + detector(s) as per pixel- or per voxel signal in the region-of-interest. + In principle this application definition allows for such doing so. + However, in most cases such a fine granularization would demand the collection + of data which are as of now hardly retrievable with commercial instruments + nor of primary interest. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. Which warrant an own + consideration in the future. A more detailed overview of such computational + steps to cope with scan distortions is available in the literature: + + * `C. Ophus et al. `_ + * `B. Berkels et al. `_ + * `L. Jones et al. `_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axis; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements + (i.e. images, spectra of scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective groups of the NXinstrument though + inside instances of here detailed NXevent_data_em. +NXevent_data_em: + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + event_identifier: + doc: | + Reference to a specific state and setting of the microscope components. + event_type: + doc: | + Which specific event/measurement type. Examples are: + + * In-lens/backscattered electron, usually has quadrants + * Secondary_electron, image, topography, fractography, overview images + * Backscattered_electron, image, Z or channeling contrast (ECCI) + * Bright_field, image, TEM + * Dark_field, image, crystal defects + * Annular dark field, image (medium- or high-angle), TEM + * Diffraction, image, TEM, or a comparable technique in the SEM + * Kikuchi, image, SEM EBSD and TEM diffraction + * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) + * Electron energy loss spectra for points, lines, surfaces, TEM + * Auger, spectrum, (low Z contrast element composition) + * Cathodoluminescence (optical spectra) + * Ronchigram, image, alignment utility specifically in TEM + * Chamber, e.g. TV camera inside the chamber, education purposes. + + detector_identifier: + doc: | + The detector or set of detectors that was used to collect this signal. + The name of the detector has to match the names used for available + detectors, i.e. if the instrument has an *ebsd_camera* + named detector, instances of NXimage_em_kikuchi should use + *ebsd_camera* as the detector name. + # a collection of images take and group under this event + # NEW ISSUE: should this only be one instance for a given event? + (NXimage_set_em_se): + (NXimage_set_em_bse): + (NXimage_set_em_ecci): + (NXimage_set_em_bf): + (NXimage_set_em_df): + (NXimage_set_em_adf): + (NXimage_set_em_kikuchi): + (NXimage_set_em_diffrac): + (NXspectrum_set_em_xray): + (NXspectrum_set_em_eels): + (NXspectrum_set_em_auger): + (NXspectrum_set_em_cathodolum): + (NXimage_set_em_ronchigram): + (NXimage_set_em_chamber): + # a collection of specific details about state of the microscope + em_lab(NXinstrument): + doc: | + A group where specific settings of the instrument during the + event can be captured. This is the preferred way to keep track of + different settings of the microscope during the session. + For instance, a user may first take an overview image with different + magnification and settings and then start a spectrum analyses. + These should be stored as two NXevent_data_em instances in an + application definition. Each storing the specific settings. + + NXfabrication relevant details should not be repeated because + we assume that the session is with the same microscope. + Namely, it is hopefully not happening that someone builds out a + component of the microscope while is taking a measurement with it. + For this reason the specialized NXinstrument here contains no + NXfabrication group. + (NXebeam_column): + (NXibeam_column): + ebeam_deflector(NXscanbox_em): + ibeam_deflector(NXscanbox_em): + (NXoptical_system_em): + (NXuser): + (NXinteraction_vol_em): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXevent_data_em_set.yaml b/contributed_definitions/nyaml/NXevent_data_em_set.yaml new file mode 100644 index 0000000000..b0ec49f075 --- /dev/null +++ b/contributed_definitions/nyaml/NXevent_data_em_set.yaml @@ -0,0 +1,8 @@ +category: base +doc: | + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. +NXevent_data_em_set: + (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml new file mode 100644 index 0000000000..4253d7a200 --- /dev/null +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -0,0 +1,20 @@ +category: base +doc: | + Details about a component as defined by its manufacturer. +NXfabrication: + vendor: + exists: required + doc: Company name of the manufacturer. + model: + exists: required + doc: Version or model of the component named by the manufacturer. + identifier: + exists: recommended + doc: | + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + capability: + doc: | + Free-text list with eventually multiple terms of + functionalities which the component offers. + # NEW ISSUE: Define a bag of controlled words and use only these. Examples are Feg, Astar, OmegaFilter. diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.yaml b/contributed_definitions/nyaml/NXgraph_edge_set.yaml new file mode 100644 index 0000000000..70c3dbf90c --- /dev/null +++ b/contributed_definitions/nyaml/NXgraph_edge_set.yaml @@ -0,0 +1,69 @@ +category: base +doc: | + A set of (eventually directed) edges which connect nodes/vertices of a graph. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_edges: The number of edges. +NXgraph_edge_set: + number_of_edges(NX_POSINT): + doc: Total number of edges, counting eventual bidirectional edges only once. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish edges for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_edges]] + directionality(NX_INT): + doc: | + Specifier whether each edge is non-directional, one-directional, + or bidirectional. Use the smallest available binary representation + which can store three different states: + + * 0 / state 0x00 is non-directional + * 1 / state 0x01 is one-directional + * 2 / state 0x02 is bi-directional + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_edges]] + node_pair(NX_INT): + doc: | + Pairs of node/vertex identifier. Each pair represents the connection + between two nodes. + + In the case that the edge is non- or bi-directional + node identifier should be stored in ascending order is preferred. + + In the case of one-directional, for each pair the identifier of the source + node is the first entry in the pair. The identifier of the target is the + second entry in the pair, i.e. the pair encodes the information as + if one traverses the edge from the source node walking to the target node. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_edges], [2, 2]] + is_a(NX_CHAR): + doc: | + A human-readable qualifier which type or e.g. class instance the + edge is an instance of. + dimensions: + rank: 1 + dim: [[1, c]] + label(NX_CHAR): + doc: A human-readable label/caption/tag for the edge. + dimensions: + rank: 1 + dim: [[1, n_edges]] diff --git a/contributed_definitions/nyaml/NXgraph_node_set.yaml b/contributed_definitions/nyaml/NXgraph_node_set.yaml new file mode 100644 index 0000000000..de0d22bd99 --- /dev/null +++ b/contributed_definitions/nyaml/NXgraph_node_set.yaml @@ -0,0 +1,48 @@ +category: base +doc: | + A set of nodes/vertices in space representing members of a graph. +# a graph in which space d-dimensional, categorical, at all a metric one? +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality of the graph. Eventually use one for categorical. + c: The cardinality of the set, i.e. the number of nodes/vertices of the graph. +NXgraph_node_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + nodes. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish nodes for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + is_a(NX_CHAR): + doc: | + A human-readable qualifier which type or e.g. class instance the + node is an instance of. As e.g. a NeXus application definition is a + graph, more specifically a hierarchical directed labelled property graph, + instances which are groups like NXgraph_node_set could have an is_a + qualifier reading NXgraph_node_set. + dimensions: + rank: 1 + dim: [[1, c]] + label(NX_CHAR): + doc: A human-readable label/caption/tag of the graph. + dimensions: + rank: 1 + dim: [[1, c]] +# how to handle arrays which are compressed? This can be useful for instance +# if there are substantially fewer disjoint labels than c \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXgraph_root.yaml b/contributed_definitions/nyaml/NXgraph_root.yaml new file mode 100644 index 0000000000..2bdee47d39 --- /dev/null +++ b/contributed_definitions/nyaml/NXgraph_root.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + An instance of a graph. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXgraph_root: + nodes(NXgraph_node_set): + relation(NXgraph_edge_set): + # further attributes diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml new file mode 100644 index 0000000000..e67d30dafc --- /dev/null +++ b/contributed_definitions/nyaml/NXibeam_column.yaml @@ -0,0 +1,93 @@ +category: base +doc: | + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. `_ + * `E. I. Preiß et al. `_ + * `J. F. Ziegler et al. `_ + * `J. Lili `_ + +# symbols: +# doc: The symbols used in the schema to specify e.g. variables. +NXibeam_column: + (NXfabrication): + ion_gun(NXsource): + doc: The source which creates the ion beam. + name: + doc: Given name/alias for the ion gun. + emitter_type: + doc: | + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + enumeration: [liquid_metal, plasma, gas_field, other] + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + probe(NXion): + doc: | + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + # NEW ISSUE: use NXion instead + brightness(NX_FLOAT): + doc: Average/nominal brightness + unit: NX_ANY + # \@units: A/cm*sr + # NEW ISSUE: (at which location?). + current(NX_FLOAT): + doc: Charge current + unit: NX_CURRENT + voltage(NX_FLOAT): + doc: Ion acceleration voltage upon source exit and entering the vacuum flight path. + unit: NX_VOLTAGE + ion_energy_profile(NX_NUMBER): + unit: NX_ENERGY + (NXtransformations): + doc: Affine transformation which detail the arrangement in the microscope relative to the optical axis and beam path. + # NEW ISSUE: details about the life/up-time of the source + # relevant from maintenance point of view + (NXaperture_em): + (NXlens_em): + # ibeam_deflector(NXscanbox_em): + (NXsensor): #for column pressure, temperature, magnetic fields etc + (NXbeam): + doc: | + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + # all these components of the FIB system are usually controlled via an + # instrment control software that is often part of the e.g. microscope control # software or at least linked to this software. + # NEW ISSUE: scan_align(NXprocess): + # NEW ISSUE: milling_plan(NXprocess): + # doc: Description of the program and sequence of sample positions sputtered. + # in here we can store time-dependent quantities + # NEW ISSUE: for documentation of charge compensation + # (NXtransformation): + # doc: | + # A right-handed Cartesian coordinate system is used whose positive + # z-axis points in the direction of the ion beam, i.e. towards the + # sample. For modelling ion milling it is relevant to document the + # illumination vector. NXtransformations offers a place to store how the + # ion gun coordinate system has to be rotated to align its positive z-axis + # with the positive z-axis of e.g. the electron beam and ion beam + # respectively. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml new file mode 100644 index 0000000000..de787e3cdd --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml @@ -0,0 +1,85 @@ +category: base +doc: | + Container for reporting a set of annular dark field images. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. +symbols: + n_images: Number of images in the stack. + n_y: Number of pixel per image in the slow direction. + n_x: Number of pixel per image in the fast direction. +NXimage_set_em_adf: + (NXprocess): + doc: | + Details how (HA)ADF images were processed from the detector readings. + source: + doc: | + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXimage_set_em_adf were loaded during + parsing to represent them in e.g. databases. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + program: + doc: | + Commercial or otherwise given name to the program which was used + to process detector data into the adf image(s). + \@version: + doc: | + Program 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. + adf_inner_half_angle(NX_FLOAT): + doc: Annulus inner half angle + unit: NX_ANGLE + adf_outer_half_angle(NX_FLOAT): + doc: Annulus outer half angle + unit: NX_ANGLE + stack(NXdata): + doc: Annular dark field image stack. + # \@signal: intensity + # \@axes: [image_id, ypos, xpos] + # \@xpos_indices: 2 + # \@ypos_indices: 1 + # \@image_indices: 0 + intensity(NX_NUMBER): + doc: Image intensity values. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_images], [2, n_y], [3, n_x]] + \@long_name: + doc: Image intensities + image_id(NX_UINT): + doc: Image identifier + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_images]] + \@long_name: + doc: Image ID. + ypos(NX_NUMBER): + doc: Pixel center of mass position y-coordinates. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis. + xpos(NX_NUMBER): + doc: Pixel center of mass position x-coordinates. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis. diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml new file mode 100644 index 0000000000..774f27ab77 --- /dev/null +++ b/contributed_definitions/nyaml/NXion.yaml @@ -0,0 +1,87 @@ +category: base +doc: | + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ivecmax: Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + n_ranges: Number of mass-to-charge-state-ratio range intervals for ion type. +NXion: + ion_type(NX_UINT): + doc: | + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + unit: NX_UNITLESS + isotope_vector(NX_UINT): + doc: | + 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) `_ + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ivecmax]] + nuclid_list(NX_UINT): + doc: | + 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, 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 should be filled with zero. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, 2], [2, n_ivecmax]] + charge_state(NX_INT): + doc: | + 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 `_ + unit: NX_CHARGE + name: + doc: | + 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, the + isotope_vector should be the preferred machine-readable format to use. + mass_to_charge_range(NX_FLOAT): + doc: | + 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 labelled + as an ion of the here referred to ion_type. + unit: NX_ANY + # \@units: Da + dimensions: + rank: 2 + dim: [[1, n_ranges], [2, 2]] diff --git a/contributed_definitions/nyaml/NXiv_temp.yaml b/contributed_definitions/nyaml/NXiv_temp.yaml new file mode 100644 index 0000000000..8c6909a549 --- /dev/null +++ b/contributed_definitions/nyaml/NXiv_temp.yaml @@ -0,0 +1,40 @@ +doc: | + Application definition for temperature-dependent IV curve measurements. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature dependent IV curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. +symbols: + n_different_temperatures: "Number of different temperature setpoints used in the experiment." + n_different_voltages: "Number of different voltage setpoints used in the experiment." +category: application +NXiv_temp(NXsensor_scan): + (NXentry): + definition(NX_CHAR): + enumeration: [NXiv_temp] + (NXinstrument): + (NXenvironment): + doc: | + Describes an environment setup for a temperature-dependent IV measurement experiment. + + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + voltage_controller(NXsensor): + temperature_controller(NXsensor): + current_sensor(NXsensor): + (NXdata): + doc: | + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + temperature(NX_NUMBER): + voltage(NX_NUMBER): + current(NX_NUMBER): + dimensions: + rank: 2 + dim: [[1, n_different_temperatures], [2, n_different_voltages]] diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml new file mode 100644 index 0000000000..b5482e9a9a --- /dev/null +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -0,0 +1,50 @@ +category: base +doc: | + 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 `_ +NXlens_em: + type: + doc: Qualitative type of lens with respect to the number of pole pieces. + enumeration: [single, double, quadrupole, hexapole, octupole] + name: + doc: | + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + manufacturer_name: + doc: Name of the manufacturer who built/constructed the lens. + (NXfabrication): + model: + doc: Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens. + description: + doc: Ideally an identifier, persistent link, or free text which gives further details about the lens. + voltage(NX_NUMBER): + doc: Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array. + unit: NX_VOLTAGE + current(NX_NUMBER): + doc: Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array. + unit: NX_CURRENT + value(NX_NUMBER): + doc: | + 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. + unit: NX_ANY + depends_on(NX_CHAR): + doc: Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group. + (NXtransformations): + doc: | + 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/nyaml/NXlens_em.yml b/contributed_definitions/nyaml/NXlens_em.yml new file mode 100644 index 0000000000..e0966c5ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXlens_em.yml @@ -0,0 +1,36 @@ +category: base +doc: | + Description of an electro-magnetic lens or a compound lens. + + Details of an `electro-magnetic 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. + + .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 +(NXlens_em): + type: + doc: "Qualitative type of lens with respect to the number of pole pieces" + enumeration: ["single", "double", "quadrupole", "hexapole", "octupole"] + name: + doc: "Colloquial or short name for the lens. For manufacturer names and identifiers use respective manufacturer fields." + manufacturer_name: + doc: "Name of the manufacturer who built/constructed the lens." + (NXmanufacturer): + model: + doc: "Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens." + description: + doc: "Ideally an identifier, persistent link, or free text which gives further details about the lens." + voltage(NX_NUMBER): + doc: "Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array." + unit: NX_VOLTAGE + current(NX_NUMBER): + doc: "Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array." + unit: NX_CURRENT + depends_on(NX_CHAR): + doc: "Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group." + (NXtransformations): + doc: + "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/nyaml/NXliquid_jet.yml b/contributed_definitions/nyaml/NXliquid_jet.yml new file mode 100644 index 0000000000..3cbb8d7f5e --- /dev/null +++ b/contributed_definitions/nyaml/NXliquid_jet.yml @@ -0,0 +1,47 @@ +category: base +doc: | + Description of a liquid jet +(NXliquid_jet): + name(NX_CHAR): + chemical_formula(NX_CHAR): + preparation_data(NX_DATE_TIME): + description(NX_CHAR): + electric_field(NX_FLOAT): + unit: NX_VOLTAGE / NX_LENGTH + geometry(NXoff_geometry): + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + situation(NX_CHAR): + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + thickness(NX_FLOAT): + unit: NX_LENGTH + type(NX_CHAR): + flow_rate(NX_FLOAT): + unit: NX_VOLUME / NX_TIME + shape(NX_CHAR): + enumeration: [round, flat] + leaf_geometry(NXtransformations): + leaf_normal(NX_NUMBER): + vector(NX_NUMBER): + depends_on(NX_CHAR): + SOLVENT(NX_SAMPLE): + description: + name: + chemical_formula: + chem_id_cas(NX_CHAR): + flow_rate(NX_FLOAT): + unit: NX_VOLUME / NX_TIME + nozzle_angle(NX_FLOAT): + unit: NX_ANGLE + ph_value(NX_FLOAT): + unit: NX_UNITLESS + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + SOLUTE(NX_SAMPLE): + description: + name: + chemical_formula: + chem_id_cas(NX_CHAR): + mol_fraction(NX_FLOAT): + solvent(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXmanipulator.yml b/contributed_definitions/nyaml/NXmanipulator.yml new file mode 100644 index 0000000000..fd74a10496 --- /dev/null +++ b/contributed_definitions/nyaml/NXmanipulator.yml @@ -0,0 +1,41 @@ +category: base +doc: + "Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments." +(NXmanipulator): + name(NX_CHAR): + doc: "Name of the manipulator." + description(NX_CHAR): + doc: "A description of the manipulator." + type(NX_CHAR): + doc: "Type of manipulator, Hexapod, Rod, etc. " + cryocoolant(NX_BOOLEAN): + doc: "Is cryocoolant flowing through the manipulator?" + cryostat_temperature(NX_FLOAT): + doc: "Temperature of the cryostat (coldest point)" + unit: NX_TEMPERATURE + heater_power(NX_FLOAT): + doc: "Power in the heater for temperature control." + unit: NX_POWER + sample_temperature(NX_FLOAT): + doc: "Temperature at the closest point to the sample. + This field may also be found in NXsample if present." + unit: NX_TEMPERATURE + drain_current(NX_FLOAT): + doc: "Current to neutralize the photoemission current. + This field may also be found in NXsample if present." + unit: NX_CURRENT + sample_bias(NX_FLOAT): + doc: "Possible bias of the sample with trespect to analyser ground. + This field may also be found in NXsample if present." + unit: NX_CURRENT + (NXpositioner): + doc: "Class to describe the motors that are used in the manipulator" + depends_on(NX_CHAR): + doc: "Refers to the last transformation specifying the positon of the manipulator in the NXtransformations chain." + (NXtransformations): + doc: + "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/nyaml/NXmatch_filter.yaml b/contributed_definitions/nyaml/NXmatch_filter.yaml new file mode 100644 index 0000000000..b8cda3e529 --- /dev/null +++ b/contributed_definitions/nyaml/NXmatch_filter.yaml @@ -0,0 +1,28 @@ +category: base +doc: | + Settings of a filter to select or remove entries based on their value. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_values: How many different match values does the filter specify. +NXmatch_filter: + method: + exists: required + doc: | + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + enumeration: [whitelist, blacklist] + match(NX_NUMBER): + exists: required + doc: | + Array of values to filter according to method. For example if the filter + specifies [1, 5, 6] and method is whitelist, only entries with values + matching 1, 5 or 6 will be processed. All other entries will be filtered + out. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_values]] diff --git a/contributed_definitions/nyaml/NXmpes.yml b/contributed_definitions/nyaml/NXmpes.yml new file mode 100644 index 0000000000..73802accee --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes.yml @@ -0,0 +1,227 @@ +#Pincelli, Rettig, Arora at fhi-berlin.mpg.de, Dobener at hu-berlin.de, 06/2022 +#Draft version of a NeXus application definition for photoemission, +#It is designed to be extended by other application definitions +#with higher granularity in the data description. + +doc: This is the most general application definition for multidimensional photoelectron spectroscopy. +category: application +NXmpes: + (NXentry): + title: + start_time(NX_DATE_TIME): + doc: "Datetime of the start of the measurement." + definition: + \@version: + enumeration: ["NXmpes"] + (NXuser): + doc: "Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users if relevant is recommended." + name: + doc: "Name of the user." + affiliation: + exists: recommended + doc: "Name of the affiliation of the user at the point in time when the + experiment was performed." + address: + exists: recommended + doc: "Full address (street, street number, ZIP, city, country) of the + user's affiliation." + email: + doc: "Email address of the user." + orcid: + exists: recommended + doc: "Author ID defined by https://orcid.org/." + (NXinstrument): + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + (NXsource): + doc: "The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. + For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on." + type: + enumeration: [ + "Synchrotron X-ray Source", + "Rotating Anode X-ray", + "Fixed Tube X-ray", + "UV Laser", + "Free-Electron Laser", + "Optical Laser", + "UV Plasma Source", + "Metal Jet X-ray", + "HHG laser" + ] + name: + probe: + doc: "Type of probe. In photoemission it's always photons, so the full NIAC list is restricted." + enumeration: ["x-ray","ultraviolet", "visible light"] + (NXbeam): + distance(NX_NUMBER): + doc: "Distance of the point of evaluation of the beam from the sample surface." + unit: NX_LENGTH + incident_energy(NX_FLOAT): + unit: NX_ENERGY + incident_energy_spread(NX_NUMBER): + exists: recommended + unit: NX_ENERGY + incident_polarization(NX_NUMBER): + exists: recommended + unit: NX_ANY + (NXelectronanalyser): + description: + energy_resolution(NX_FLOAT): + exists: recommended + doc: "Energy resolution of the analyser with the current setting. May be linked from a NXcalibration." + unit: NX_ENERGY + fast_axes(NX_CHAR): + exists: recommended + slow_axes: + exists: recommended + (NXcollectioncolumn): + scheme: + doc: "Scheme of the electron collection column." + enumeration: [ + "Standard", + "Angular dispersive", + "Selective area", + "Deflector", + "PEEM", + "Momentum Microscope" + ] + mode: + exists: recommended + projection: + exists: recommended + field_aperture(NXaperture): + exists: optional + doc: "The size and position of the field aperture inserted in the column. + To add additional or other apertures use the APERTURE group of NXcollectioncolumn." + contrast_aperture(NXaperture): + exists: optional + doc: "The size and position of the contrast aperture inserted in the column. + To add additional or other apertures use the APERTURE group of NXcollectioncolumn." + (NXenergydispersion): + scheme: + enumeration: + [ + "tof", + "hemispherical", + "double hemispherical", + "cylindrical mirror", + "display mirror", + "retarding grid", + ] + pass_energy(NX_FLOAT): + unit: NX_ENERGY + energy_scan_mode: + entrance_slit(NXaperture): + exists: optional + doc: "Size, position and shape of the entrance slit in dispersive analyzers. + To add additional or other slits use the APERTURE group of NXenergydispersion." + exit_slit(NXaperture): + exists: optional + doc: "Size, position and shape of the exit slit in dispersive analyzers. + To add additional or other slits use the APERTURE group of NXenergydispersion." + (NXdetector): + amplifier_type: + exists: recommended + doc: "Type of electron amplifier in the first amplification step." + enumeration: ["MCP", "channeltron"] + # ToDo: Representation of count rate calibration + detector_type: + exists: recommended + doc: "Description of the detector type." + enumeration: ["DLD","Phosphor+CCD","Phosphor+CMOS","ECMOS", "Anode", "Multi-anode"] + (NXdata): # Raw signal without calibrated axes. + exists: recommended + \@signal: + enumeration: ['raw'] + raw(NX_NUMBER): # There is a block of numbers named raw. + doc: "Raw data before calibration." + (NXmanipulator): + exists: optional + doc: "Manipulator for positioning of the sample." + sample_temperature(NX_FLOAT): + exists: recommended + unit: NX_TEMPERATURE + drain_current(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + sample_bias(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + (NXprocess): + doc: "Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using + one or more of the following NXcalibrations" + energy_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an energy calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated energy axis to be used for data plotting." + angular_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an angular calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated angular axis to be used for data plotting." + spatial_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an spatial calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated spatial axis to be used for data plotting." + momentum_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an momentum calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the momentum axis to be used for data plotting." + (NXsample): + name: + chemical_formula: + exists: recommended + doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." + sample_history(NXnote): + exists: recommended + doc: "A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. + Ideally, a full report of the previous operations, in any format (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." + preparation_date(NX_DATE_TIME): + exists: recommended + doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." + preparation_description(NXnote): + doc: "Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. + Ideally, a full report of the previous operations, in any format(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." + # Problem: if the temperature is logged, the data is an array of temperature/timestamp pairs. + # the timestamp NX_DATE_TIME structure of the timestamp can not be easily handled by just a field. + # there is a base class for this, NXlog. The NIAC decided to use the same name (temperature) instead of the previous temperature_log. + # how do I explain here in an appdef that temperature can be either NXnumber (single value or scanned array) or a NXlog? + # It seems quite contorted to ask to create a separate timestamp array when we have a base class that handles it more elegantly. + temperature(NX_FLOAT): + doc: "In the case of a fixed temperature measurement this is the scalar temperature of the sample. + In the case of an experiment in which the temperature is changed and recoded, this is an array of length m of temperatures. + This should be a link to + /entry/instrument/manipulator/sample_temperature." + unit: NX_TEMPERATURE + situation: + enumeration: ["vacuum", "inert atmosphere", "oxidising atmosphere", "reducing atmosphere"] + # Similar situation here, ca be a single number or a log. + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + (NXdata): + \@signal: + enumeration: ["data"] # There is an object named data that contains the signal + data(NX_NUMBER): # There is a block of numbers named data. + doc: "Represents a measure of one- or more-dimensional photoemission counts, where + the varied axis may be for example + energy, momentum, spatial coordinate, pump-probe delay, spin index, temperature, etc. + The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." + unit: NX_ANY diff --git a/contributed_definitions/nyaml/NXmpes_liquid.yml b/contributed_definitions/nyaml/NXmpes_liquid.yml new file mode 100644 index 0000000000..b8d8690b4b --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes_liquid.yml @@ -0,0 +1,267 @@ +#Pincelli, Rettig, Arora at fhi-berlin.mpg.de, Dobener at hu-berlin.de, 06/2022 +#Draft version of a NeXus application definition for photoemission, +#It is designed to be extended by other application definitions +#with higher granularity in the data description. + +doc: This is the application definition for multidimensional photoelectron spectroscopy on liquids +category: application +(NXmpes): + (NXentry): + title: + start_time(NX_DATE_TIME): + doc: "Datetime of the start of the measurement." + definition: + \@version: + enumeration: ["NXmpes_liquid"] + (NXuser): + doc: "Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users if relevant is recommended." + name: + doc: "Name of the user." + affiliation: + exists: recommended + doc: "Name of the affiliation of the user at the point in time when the + experiment was performed." + address: + exists: recommended + doc: "Full address (street, street number, ZIP, city, country) of the + user's affiliation." + email: + doc: "Email address of the user." + orcid: + exists: recommended + doc: "Author ID defined by https://orcid.org/." + (NXinstrument): + energy_resolution(NX_FLOAT): + (NXsource): + doc: "The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. + For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on." + type: + enumeration: [ + "Synchrotron X-ray Source", + "Rotating Anode X-ray", + "Fixed Tube X-ray", + "UV Laser", + "Free-Electron Laser", + "Optical Laser", + "UV Plasma Source", + "Metal Jet X-ray", + "HHG laser" + ] + name: + probe: + doc: "Type of probe. In photoemission it's always photons, so the full NIAC list is restricted." + enumeration: ["x-ray","ultraviolet", "visible light"] + (NXbeam): + distance(NX_NUMBER): + doc: "Distance of the point of evaluation of the beam from the sample surface." + incident_energy(NX_FLOAT): + incident_energy_spread(NX_NUMBER): + exists: recommended + incident_polarization(NX_NUMBER): + exists: recommended + (NXelectronanalyser): + description: + energy_resolution(NX_FLOAT): + exists: recommended + doc: "Energy resolution of the analyser with the current setting. May be linked from a NXcalibration." + fast_axes(NX_CHAR): + exists: recommended + slow_axes: + exists: recommended + (NXcollectioncolumn): + scheme: + doc: "Scheme of the electron collection column." + enumeration: [ + "Standard", + "Angular dispersive", + "Selective area", + "Deflector", + "PEEM", + "Momentum Microscope" + ] + mode: + exists: recommended + projection: + exists: recommended + field_aperture(NXaperture): + exists: optional + doc: "The size and position of the field aperture inserted in the column. + To add additional or other apertures use the APERTURE group of NXcollectioncolumn." + contrast_aperture(NXaperture): + exists: optional + doc: "The size and position of the contrast aperture inserted in the column. + To add additional or other apertures use the APERTURE group of NXcollectioncolumn." + (NXenergydispersion): + scheme: + enumeration: + [ + "tof", + "hemispherical", + "double hemispherical", + "cylindrical mirror", + "display mirror", + "retarding grid", + ] + pass_energy(NX_FLOAT): + energy_scan_mode: + entrance_slit(NXaperture): + exists: optional + doc: "Size, position and shape of the entrance slit in dispersive analyzers. + To add additional or other slits use the APERTURE group of NXenergydispersion." + exit_slit(NXaperture): + exists: optional + doc: "Size, position and shape of the exit slit in dispersive analyzers. + To add additional or other slits use the APERTURE group of NXenergydispersion." + (NXdetector): + amplifier_type: + exists: recommended + doc: "Type of electron amplifier in the first amplification step." + enumeration: ["MCP", "channeltron"] + # ToDo: Representation of count rate calibration + detector_type: + exists: recommended + doc: "Description of the detector type." + enumeration: ["DLD","Phosphor+CCD","Phosphor+CMOS","ECMOS", "Anode", "Multi-anode"] + (NXdata): # Raw signal without calibrated axes. + exists: recommended + \@signal: + enumeration: ['raw'] + raw(NX_NUMBER): # There is a block of numbers named raw. + doc: "Raw data before calibration." + (NXmanipulator): + exists: optional + doc: "Manipulator for positioning of the sample." + sample_temperature(NX_FLOAT): + exists: recommended + drain_current(NX_FLOAT): + exists: recommended + sample_bias(NX_FLOAT): + exists: recommended + (NXprocess): + doc: "Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using + one or more of the following NXcalibrations" + energy_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an energy calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated energy axis to be used for data plotting." + angular_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an angular calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated angular axis to be used for data plotting." + spatial_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an spatial calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated spatial axis to be used for data plotting." + momentum_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an momentum calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the momentum axis to be used for data plotting." + sample(NXsample): + name: + description: + chemical_formula: + exists: recommended + doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." + sample_history(NXnote): + exists: recommended + doc: "A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. + Ideally, a full report of the previous operations, in any format (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." + preparation_date(NX_DATE_TIME): + exists: recommended + doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." + preparation_description(NXnote): + doc: "Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. + Ideally, a full report of the previous operations, in any format(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." + # Problem: if the temperature is logged, the data is an array of temperature/timestamp pairs. + # the timestamp NX_DATE_TIME structure of the timestamp can not be easily handled by just a field. + # there is a base class for this, NXlog. The NIAC decided to use the same name (temperature) instead of the previous temperature_log. + # how do I explain here in an appdef that temperature can be either NXnumber (single value or scanned array) or a NXlog? + # It seems quite contorted to ask to create a separate timestamp array when we have a base class that handles it more elegantly. + temperature(NX_FLOAT): + doc: "In the case of a fixed temperature measurement this is the scalar temperature of the sample. + In the case of an experiment in which the temperature is changed and recoded, this is an array of length m of temperatures. + This should be a link to + /entry/instrument/manipulator/sample_temperature." + unit: NX_TEMPERATURE + situation: + enumeration: ["vacuum", "inert atmosphere", "oxidising atmosphere", "reducing atmosphere"] + # Similar situation here, ca be a single number or a log. + gas_pressure(NX_FLOAT): + electric_field(NX_FLOAT): + unit: NX_VOLTAGE / NX_LENGTH + geometry(NXoff_geometry): + thickness(NX_FLOAT): + unit: NX_LENGTH + type(NX_CHAR): + flow_rate(NX_FLOAT): + unit: NX_VOLUME / NX_TIME + shape(NX_CHAR): + enumeration: [round, flat] + leaf_geometry(NXtransformations): + doc: | + Transformations describing the transformation chain to the + liqudjet leaf. + leaf_normal(NX_NUMBER): + doc: The normal of the liquidjet leaf. + \@vector(NX_NUMBER): + doc: The vector normal to the liquidjet leaf. + \@depends_on(NX_CHAR): + doc: | + Pointer to the previous matrices in the transformation chain + to relate the normal to the rest of the instrument. + If this is '.' the vector attribute only specifies the normal vector + without specifying the position of the liquidjet leaf with respect + to the instrument. + SOLVENT(NX_SAMPLE): + # FD 24.08.22: Should we also add transformations here to + # describe the directions of the liquidjets? + doc: | + Solvent material of the liquidjet. + This also accounts for multiple jets if more + than one solvent is given. + description: + name: + chemical_formula: + chem_id_cas(NX_CHAR): + flow_rate(NX_FLOAT): + unit: NX_VOLUME / NX_TIME + nozzle_angle(NX_FLOAT): + unit: NX_ANGLE + ph_value(NX_FLOAT): + unit: NX_UNITLESS + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + SOLUTE(NX_SAMPLE): + description: + name: + chemical_formula: + chem_id_cas(NX_CHAR): + mol_fraction(NX_FLOAT): + solvent(NX_CHAR): + (NXdata): + \@signal: + enumeration: ["data"] # There is an object named data that contains the signal + data(NX_NUMBER): # There is a block of numbers named data. + doc: "Represents a measure of one- or more-dimensional photoemission counts, where + the varied axis may be for example + energy, momentum, spatial coordinate, pump-probe delay, spin index, temperature, etc. + The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." diff --git a/contributed_definitions/nyaml/NXms_crystal_set.yaml b/contributed_definitions/nyaml/NXms_crystal_set.yaml new file mode 100644 index 0000000000..b9da729eef --- /dev/null +++ b/contributed_definitions/nyaml/NXms_crystal_set.yaml @@ -0,0 +1,129 @@ +category: base +doc: | + Base class to describe data about observed crystals in microstructures. + + Both experiments and computer simulations support that atoms organize into regions + which are often separated and interconnected by different types of crystal defects. + Crystalline regions show a long-range periodic arrangement (compared to the + length scale of nearest neighbor distances). + Although the group of atoms forming a crystal is virtually never static, due + to diffusive in- and outflux of atoms and thermal fluctuations of the atoms + about their equilibrium positions, crystals are relevant persistent features + in microstructures. The size of crystals can span orders of magnitude from + meters to nanometers. + + There are two different and (somewhat extremal) views on crystals and how to + describe their eventually very rich variety of internal defects. Either + crystals can be coarse-grained into continuum objects or not. In the second case + they need a more advanced internal description of defects inside the grains + which convinces many that eventually a grain has to be viewed from its + individual atoms, its material points, and the hierarchy of structural motifs + local arrangements in the crystal. + + Despite these details, identifying crystals is foremost a labeling task. + Atoms are clustered into structural motifs and (noise) and these motifs + are again clustered into crystals. + + There are two main approaches how crystals are described in mesoscale + microstructure evolution simulations. Assuming for now transformations in the + solid state, precipitates, phase regions, sub-grains or grains are examples + of crystals: + + * Objects are either tracked explicitly in the sense that their shape will + be resolved through the crystal interfaces using e.g. a phase-field, + level-set, grid, or finite element mesh based models and implementations. + These simulations may keep track of explicit crystal/grain/object-related + quantities. Such models can treat the interface network implicitly while + still focusing their description on the explicit crystals. + During such simulations the interface is often analyzed on-the-fly, + because of technical demands (like in level-set implementations) or to + trigger specific situations where it is relevant to resolve the + position of the interfaces explicitly (like for placing seeds for phases, + recrystallizing grains etc, or for visualization purposes), demand a + description of interfaces between crystals. + For explicitly tracking simulations this base class can be applied as is. + * Objects are tracked implicitly in the sense that the computational domain + is discretized into an ensemble of what one can call material points. + Such models can be described at different length scale: On the one hand + where atom dynamics are (whether the assumption is substantiated or not) + homogenized/-able already or not. Each material point is assumed to have + at least one associated constitutive phase. + Such simulations usually do not/cannot resolve crystal-related quantities + without executing an on-the-fly post-processing of snapshot data from + which the spatial representation of the crystal is recovered. + An important case are large-strain formalism crystal plasticity methods. + Here the initial configuration represents most frequently material points + on a regular grid. Within the course of the simulation this grid gets + deformed implicitly. The code internally keeps no track of how the cells/ + material points of what is essentially a Voronoi tessellation, are deformed. + Only in the case when one would like to visualize the deformed configuration, + a post-processing of the simulation snapshot data is executed which + recovers the positions of the material points in the deformed configuration + in the laboratory coordinate system from which one can then extract a + representation of grains/precipitates, i.e. crystals. + It is a signature of such simulations that quantities like orientation + are defined as material point quantities. This means what constitutes the grain + needs to be extracted by cluster analyses. + In this regard, such simulation are essentially matching the representation and + case of molecular dynamics simulations, with the important difference + that these track atoms, from whose configuration + in a snapshot a description has to be computed what are most likely the + atoms that belong to the volume of the crystal or the interface/defect + network. +# for implicitly tracking simulation one can also argue that as +# one anyway needs to do post-processing to extract at all what the grains +# one could also group fields from this base class into an NXprocess +# the fundamental problem making a decision is that depending on which +# model and implementation is used some of these post-processes are +# executed on-the-fly, so from the perspective of an application definition +# the internal workflows in the software are irrelevant but instead one +# just cares what is reported as a result from the software +# !!! this example nicely shows that drafting an application definition is +# !!! eventually also demanding to make a somewhat arbitrary cutting of the +# !!! workflow steps, tag this sub-workflow as some entity +# !!! (e.g. the phase field simulation) +# !!! and thus have application definitions that merely assure specific data +# !!! are passed into this sub-graph or expect as output from the sub-graph +# !!! in a particular application +# a general enough phase-field description needs to account for the +# fact that not necessarily each region is crystalline +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality of the description. + n_objects: The number of objects, which can be crystals, grains, phases or phase field regions. +# how can we elegantly implement that in simulations and situations where the number +# of objects remains static there is no need to store identifiers several times? +NXms_crystal_set: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_objects(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + objects. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish objects for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_objects]] + object_size(NX_NUMBER): + doc: Depending on the value of dimensionality, the area or volume of each object. + dimensions: + rank: 1 + dim: [[1, n_objects]] + # add further object specific properties + # (NXorientation_set): + # (NXms_dislocation_set): + # (NXms_boundary_set): + # (NXms_triple_line_set): + # (NXms_quadruple_junction_set): diff --git a/contributed_definitions/nyaml/NXms_dislocation_set.yaml b/contributed_definitions/nyaml/NXms_dislocation_set.yaml new file mode 100644 index 0000000000..5bf8e65536 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_dislocation_set.yaml @@ -0,0 +1,118 @@ +category: base +doc: | + Base class to describe details about dislocations observed in microstructures. + + Dislocations are one-dimensional crystal defects whose primary interest is + that they are the carrier of plastic deformation. Conceptually dislocations + are a continuum-scale description of how atoms arrange spatio-temporally on + the one hand as a persistent defect which on the other hand though, when + inspected in detail for the atom dynamics and their interaction with other + crystal defects manifest as an involved microstructural feature for which + very different descriptions are used depending which length-, time-scale, + and research question people address. + + This is manifested in the large amount of literature on the topic: + + * https://www.sciencedirect.com/bookseries/dislocations-in-solids + + Dislocations are one prominent group of representatives for one-dimensional + features, other defects include disconnections and/or disclinations, and even + more complicated configurations, especially when one considers not-necessarily + crystalline materials, quasi crystals. It would be rude to claim that a single + base class can encompass the entire complexity that this effectively + coarse-graining of atomic spatio-temporal configurations has, in an effort + to simplicify the description in the hope to arrive at physical models which + do not need to take into account the location and movement of every atom. + + However, it is also a fact that not every description, research question, and + thus use cases that one could think of what one should store as data and metadata + for one-dimensional, primarily line-type crystal defects, is equally relevant + for an ensemble of research studies. + + Thus, for the design of concrete schemata for the purpose of structured storage + of research data on dislocations or studies where dislocations are measured + or characterized, one has to prioritize which descriptors and aspects about + dislocations are likely relevant for a large number of users of a research + infrastructure. Consequently, it is possible to narrow down the scope of + the base class and application definition. + + It is noteworthy to mention that this applies not only to description + using NeXus, but points to the problem of creating a golden-bullet schema + capable of handling all possible subtleties. + + For now we have to accept that is not yet an ontology of e.g. the above + understanding of what dislocations are. Pragmatically we thus make the + following assumptions: + + * This base class is essentially a template how specific often referred + quantities for one-dimensional crystal defects can be stored. + * In practice dislocations have a finite length as they are embedded in a + finite specimen and wired into an ensemble of adjoining dislocations + or other adjoining crystal defects. + * There are the following general approaches of studying/characterizing + * 1. Indirect measurements where dislocations characterized statistically. + In this case different types of dislocations are distinguished + (geometrically-necessary, mobile, immobile), mainly motivated by + different constitutive, continuum-models how they are threated in + computer simulations with respect to what their effect is on ms evolution. + * 2. Electron microscopy measurements of single or several dislocation (bundles) + In this case post-processing strategies are necessary which can + extract statistical descriptors or d-dimensional reconstructions + * 3. Atomic-scale-resolved simulations. In this case the most frequently + performed tasks are again post-processing into polyline networks, + detailed local investigations of the atomic configurations, or both + with or without some correlation. + * 4. Analytical approaches whereby dislocations are resolved at the continuum + scale, as line defects containing other elementary defects (for instance) + in models of disconnection motion), or again atomically resolved treatments. + + From this we can conclude that an NXms_dislocation_set can primarily be + useful as a wrapper class in which specific details about dislocations + can be stored in an arbitrarily nested manner. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXms_dislocation_set: + doc: A starting point for the discussion. +# doc: Needs to be extended based on the NXannealing appdef. +# lets sketch for each of the four above-mentioned frequent use cases what +# could be relevant to be nested inside such base classes +# !!! here we really need to discuss if these many options +# !!! warrant necessary deeper nesting or further splitting of the base class +# !!! essentially pseudo-code yaml follows !!! +# USE CASE statistical treatments +# (NXslip_system_set): +# for each slip system one would add +# symbols: +# n_types: Number of different types. +# density(NX_NUMBER): +# doc: Dislocation density as number of dislocations per unit area. +# dimensions: +# rank: 1 +# dim: [[1, n_types]] +# USE CASE spatially-resolved +# (NXcg_point_set): # !!! should one at all consider any longer 2D or 2.5D simulations... +# (NXcg_polyline_set): +# for each polyline eventual further properties like mobility etc. +# USE CASE analytical treatment +# !!! there is no clear separation between these use case +# one might also just want to store elementary properties of dislocations in the set +# burgers_vector(NX_NUMBER): +# doc: Burgers vector +# dimensions: +# rank: 2 +# dim: [[1, n], [2, 3]] +# line_element(NX_NUMBER): # but the line element for a general dislocation +# is a position dependent quantity, expect for the very specific text book +# simple configuration like straight edge and straight screw dislocations +# !!! especially for analytical treatment one may resolve individual dislocations +# at the continuu-scale using some domain, discretized and analyze the strain and stress fields, +# solute concentrations +# !!! admittedly these combinations and configurations are very specific for a research study +# !!! however, this can not be an excuse for aiming at a controlled and shared vocabulary to use +# !!! otherwise how should a machine ever understand how jog is different to kink +# !!! especially in theoretical analyses at the continuum-scale it has been frequently +# discussed that dislocations host an ensemble of other defects along their, jogs, kinks, stacking faults, +# core structure anomalies, the point is again they either have to be measured or simulated +# and this results in either a description at the continuum-scale or based on the atomic architecture and dynamics +# often thermodynamics are used to describe ensemble statistics about these defects along the dislocation line +# or of the dislocation network, a distinction, which is especially in the research on recovery phenomena, oftentimes not well separated. diff --git a/contributed_definitions/nyaml/NXms_interface_set.yaml b/contributed_definitions/nyaml/NXms_interface_set.yaml new file mode 100644 index 0000000000..e44ab2accd --- /dev/null +++ b/contributed_definitions/nyaml/NXms_interface_set.yaml @@ -0,0 +1,106 @@ +category: base +doc: | + Base class to describe details about interfaces observed in microstructures. + + Classically, interfaces are two-dimensional crystal defects whose relevance is + that they are agents which trigger crystal growth and discontinuities of the + crystal at which defects can accumulate and solutes segregate with fundamental + effect on the properties of materials. Conceptually, interfaces are a + continuum-scale description of how atoms arrange spatio-temporally. Interfaces + manifests as persistent defects. When inspected in more detail though they show + atom dynamics, coarse-grainable into again interactions between line-type + crystal defects (disconnections) through which interfaces are dynamic and can + interact with other defects. Owing to this complexity very different + descriptions are used depending on which length-, time-scale, + and research question people address. + + This is manifested in the large amount of literature on the topic: + + * A. P. Sutton et al. ISBN-13 978-0198500612 + * G. Gottstein et al. ISBN-13 978-1-4200-5436-1 + * K. Chen et al. https://doi.org/10.1073/pnas.1920504117 + + Interfaces, specifically grain and phase boundaries, are representatives of + two-dimensional microstructural features. It would be rude to claim that a single + base class can encompass the entire complexity that this effective + coarse-graining of atomic spatio-temporal configurations has. In the end, + interfaces are a model, an effort to simplicify the description in the hope + to arrive at physical models which do not need to take into account the static + and dynamic details of every atom. + + However, it is also a fact that not every description, research question, and + thus use cases that one could think of storing as data and metadata for + interfaces, is equally relevant and useful for an ensemble of research studies. + + Thus, for the design of concrete schemes for a structured storage of data on + interfaces are measured or characterized, one has to prioritize which + descriptors and aspects about interfaces are likely relevant for a large + number of users of the research infrastructure. Consequently, it is possible + to narrow down the scope of this base class. + + It is noteworthy to mention that this applies not only to schemes build + with NeXus, but points to the problem of creating a golden-bullet schema + that could handle all possible subtleties of interfaces. + + For now we have to accept that there is not yet an ontology of e.g. the + above-mentioned understanding of what interfaces are. + + Pragmatically we thus make the following assumptions: + + * This base class is essentially a template how specific, often referred to + quantities, for two-dimensional crystal defects can be stored. + * Coarse-graining point-like features into a curve or surfaces is an + ill-posed problem. In practice, it has to be accounted for that interfaces + have a finite extent, they are delineated by triple lines and quadruple + junctions. Interfaces are thus connected into a three-dimensional network + of defects. Interfaces can interact or intersect with other defects + (partially or completely, as it is the case for disconnections). + + There are the following general approaches of studying/characterizing: + + * Non-atomically resolved measurements of 2D or 3D sections. + Examples are optical, electron, X-ray, or atom probe microscopy. + * Under specific conditions using electron microscopy, electron tomography + (provided numerical post-processing is applied) as well as with atom probe + microscopy these measurement can resolve structural motifs of or in the + interface plane. + * Atomic-scale-resolved simulations. In this case the most frequently + performed tasks are again post-processing snapshots with grain identification + or graph-based techniques to identify which atoms belong to the regions + with local changes or breakdown of the long-range crystal symmetry. + * Analytical approaches whereby grain boundaries are resolved at the continuum + scale, as surface defects containing other elementary defects (for instance) + in models of disconnection motion), using eventual statistical approaches, + or again atomically resolved treatments. + + From this we can conclude that an NXms_interface_set can primarily be + useful as a wrapper class in which specific details about interfaces + can be stored in an arbitrarily nested manner. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXms_interface_set: + doc: A starting point for the discussion. +# needs to be extended based on the NXannealing appdef. + +# lets sketch for each of the four above-mentioned frequent use cases what +# could be relevant to nest inside such base classes +# !!! here we really need to discuss if these many options +# !!! warrant necessary deeper nesting or further splitting of the base class +# !!! essentially pseudo-code yaml follows !!! +# USE CASE statistical treatments +# # described via representatives of geometric descriptors, for instance +# depending on which method one uses interfaces are described in 2D via their traces +# (NXcg_polyline_set) +# more frequently nowadays though one resorts to 3D +# (NXcg_triangle_set) +# (NXcg_triangulated_surface_mesh_set) +# (NXcg_polygon_set) +# (NXcg_polyhedra_set) +# instances for all of these base class can be customized with specific fields +# i.e. properties +# !!! a particular challenge in certain applications/use cases is that +# descriptions are combined (continuum with atomic scale) +# in such a case NXcg_roi_set can be used to add further nested +# NXcg_*_set), e.g. NXcg_cuboid_set or NXcg_cylinder_set which detail how +# atoms are arranged inside such sub-volumina +# similar statements as they were made for NXms_dislocation_set apply diff --git a/contributed_definitions/nyaml/NXms_snapshot.yaml b/contributed_definitions/nyaml/NXms_snapshot.yaml new file mode 100644 index 0000000000..45dcdc8ef9 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_snapshot.yaml @@ -0,0 +1,17 @@ +category: base +doc: | + Base class for data on the state of the microstructure at a given time/iteration. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXms_snapshot: + comment: + doc: Is this time for a measurement or a simulation. + enumeration: [measurement, simulation] + time(NX_NUMBER): + doc: | + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + unit: NX_TIME + iteration(NX_INT): + doc: Iteration or increment counter. + unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXms_snapshot_set.yaml b/contributed_definitions/nyaml/NXms_snapshot_set.yaml new file mode 100644 index 0000000000..d923384e0d --- /dev/null +++ b/contributed_definitions/nyaml/NXms_snapshot_set.yaml @@ -0,0 +1,28 @@ +category: base +doc: | + A collection of spatiotemporal microstructure data. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXms_snapshot_set: + comment: + doc: Is this set describing a measurement or a simulation? + enumeration: [measurement, simulation] + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + # should we rather name snapshots explicitly always snapshot_1, snapshot_2 + # in which case identifier fields are not required, on the other hand + # if we give the names of the snapshots free via making them all capital + # how can we assure that snapshots are numbered consecutively? + # MS_SNAPSHOT + (NXms_snapshot): + # exists: [min, 0, max, infty] diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml new file mode 100644 index 0000000000..d01ab5fe2a --- /dev/null +++ b/contributed_definitions/nyaml/NXoptical_system_em.yaml @@ -0,0 +1,50 @@ +category: base +doc: | + A container for qualifying an electron optical system. +NXoptical_system_em: + # NEW ISSUE: for now used to store difficult to place entries + # NEW ISSUE: all the definitions here should better be backed up by the + # work of the HMC EM glossary activities + camera_length(NX_NUMBER): + doc: | + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + unit: NX_LENGTH + magnification(NX_NUMBER): + doc: | + The factor of enlargement of the apparent size, not physical size, of an object. + unit: NX_DIMENSIONLESS + defocus(NX_NUMBER): + doc: | + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + unit: NX_LENGTH + semi_convergence_angle(NX_NUMBER): + doc: | + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + unit: NX_ANGLE + field_of_view(NX_NUMBER): + doc: | + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + unit: NX_LENGTH + working_distance(NX_FLOAT): + doc: | + Citing `Globalsino `_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + unit: NX_LENGTH + beam_current(NX_FLOAT): + doc: | + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + unit: NX_CURRENT + beam_current_description(NX_CHAR): + doc: | + Specify further details how the beam current was measured or estimated. + # NEW ISSUE: the KIT/SCC propose: + # adding of the image_mode or field mode + # imageMode: enum: [normal_image, sad, eds, nbd, cbed] + # fieldMode: enum: [dark_field, bright_field] diff --git a/contributed_definitions/nyaml/NXorientation_set.yaml b/contributed_definitions/nyaml/NXorientation_set.yaml new file mode 100644 index 0000000000..1a446a92b8 --- /dev/null +++ b/contributed_definitions/nyaml/NXorientation_set.yaml @@ -0,0 +1,84 @@ +category: base +doc: | + Details about individual orientations of a set of objects. + + For a more detailed insight into the discussion of parameterizing + orientations in materials science see: + + * https://doi.org/10.1016/j.matchar.2016.04.008 + * https://doi.org/10.1088/0965-0393/23/8/083501 + * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations + * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge + + +# This class stores a set of specifically parameterized NXtransformations which describe +# how each object is oriented/rotated with respect to a reference coordinate system. +# we should offer here support for d==2, d==3 +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality of the reference space/coordinate system. + c: The cardinality of the set, i.e. the number of orientations. + n_p: Number of parameters for the chosen parameterization. +NXorientation_set: + # depending on the dimensionality n_p is correlated but not necessarily, e.g. for d==3 one can store quaternions (n_p==4) or Bunge-Euler angles (n_p==3) + # clearly one could think about a single best approach that everybody should use, and indeed quaternions could be a candidate but this conflicts with the + # expectations understanding and in fact habit by very many materials engineers who know and report their values in Euler angles so at least one would need to + # have a system in place which converts... + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the definitions are interpretable. + parameterization(NX_CHAR): + enumeration: [bunge-euler (ZXZ), quaternion] # there are many more ways of parameterizing orientations and for each of them different conventions to be used. many scientists do not recall by hard which rule set is associated with an e.g. ZXZ Bunge-Euler angles vers ZXY so there are at least two ways how to encode these metadata: Either to have different enumerations like bunge-euler-zxz, bunge-euler-zxy, etc. or a base class NXori_bunge_euler and then internally here a rule set...? + # how to take into account the reduction to two-d? just list these cases XY, XZ, ... also in the enumeration? + # an instance of an NXorientation_set is useful as attribute (meta)data to a set of microstructural objects e.g. crystals, grains when the base class is stored as a sub-ordinate of the grain_set + # one may argue we expect that for each grain there is an orientation value, in this case the indexing is implicit and this is often used in computer simulations + # without making a specific statement that e.g. the 0-th value of the array gives the volume of the 0-th grain but that 0-th grain might not necessarily be named as grain 0 but e.g. grain 23 + # because many computer simulations deal with ensemble where the number of objects changes over time, e.g. molecular dynamics simulation treat always the same set of atoms but post-processing + # of the data may reveal these atoms are grouped/labelled as different microstructural features (grains, dislocations, vacancies) and then the names/identifiers of the objects may change over time + # therefore the idea to specify if we use implicit or explicit indexing and listing of the indices because I know of colleagues where even that went havoc! + objects(NX_CHAR): + doc: | + A link or reference to the objects whose identifier are referred to in + identifier to resolve which row tuple is the orientation of each object + by reading orientations. + identifier_offset(NX_INT): + doc: | + Integer which specifies which orientation (row of array orientation) matches + to which object.e first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Integer used to distinguish how a row in orientation describes a specific + object with an explicit identifier that can be queried via inspecting the + list of available objects in objects. + + The rational behind having such a more complicated pattern is that not + all objects referred when following the link in objects may still exists + or are still tracked when the orientation set was characterized. + + This design enables to also use NXorientation_set in situations where + the orientation of objects change as a function in time. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + orientation(NX_NUMBER): + doc: Parameterized orientations. + unit: NX_ANY + dimensions: + rank: 2 + dim: [[1, c], [2, n_p]] + # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists + # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) + # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. + +# the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml new file mode 100644 index 0000000000..c1c7d020c1 --- /dev/null +++ b/contributed_definitions/nyaml/NXpeak.yaml @@ -0,0 +1,43 @@ +category: base +doc: | + Description of peaks, their functional form or measured support. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_support: Number of support points +NXpeak: + label: + doc: | + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + peak_model: + doc: | + 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. + enumeration: [empirical, gaussian, lorentzian, other] + position(NX_NUMBER): + doc: | + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_support]] + intensity(NX_NUMBER): + doc: | + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_support]] + (NXcollection): + doc: | + 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/nyaml/NXpid.yaml b/contributed_definitions/nyaml/NXpid.yaml new file mode 100644 index 0000000000..e4a6e17e54 --- /dev/null +++ b/contributed_definitions/nyaml/NXpid.yaml @@ -0,0 +1,46 @@ +doc: | + Contains the settings of a PID controller. +category: base +NXpid: + description: + doc: | + Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. + + For example, a set of sensors could be averaged over before feeding it back into the loop. + pv_sensor(NXsensor): + doc: | + The sensor representing the Process Value used in the feedback loop for the PID. + + In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. + value_log(NXlog): + value(NX_NUMBER): + doc: | + The actual timeseries data fed back to the PID loop. + setpoint(NX_FLOAT): + unit: NX_ANY + doc: | + The Setpoint(s) used as an input for the PID controller. + + It can also be a link to an NXsensor.value field. + K_p_value(NX_NUMBER): + doc: | + 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. + K_i_value(NX_NUMBER): + doc: | + The contribution from the integral term is proportional to both + the magnitude of the error and the duration of the error. + The integral in a PID controller is the sum of the instantaneous + error over time and gives the accumulated offset that should have + been corrected previously. The accumulated error is then + multiplied by the integral gain (Ki) and added to the + controller output. + K_d_value(NX_NUMBER): + doc: | + The derivative of the process error is calculated by determining + the slope of the error over time and multiplying this rate of + change by the derivative gain K_d. The magnitude of the + contribution of the derivative term to the overall control + action is termed the derivative gain, K_d diff --git a/contributed_definitions/nyaml/NXpulser_apm.yaml b/contributed_definitions/nyaml/NXpulser_apm.yaml new file mode 100644 index 0000000000..8c48ae158f --- /dev/null +++ b/contributed_definitions/nyaml/NXpulser_apm.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: Total number of ions collected. +NXpulser_apm: + (NXfabrication): + pulse_mode: + doc: | + How is field evaporation physically triggered. + enumeration: [laser, voltage, laser_and_voltage] + pulse_frequency(NX_FLOAT): + doc: Frequency with which the high voltage or laser pulser fires. + unit: NX_FREQUENCY + pulse_fraction(NX_FLOAT): + doc: | + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + unit: NX_DIMENSIONLESS + pulsed_voltage(NX_FLOAT): + doc: | + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + unit: NX_VOLTAGE + dimensions: + rank: 1 + dim: [[1, n_ions]] + standing_voltage(NX_FLOAT): + doc: | + Direct current voltage between the specimen and the + (local electrode) in the case of local electrode atom + probe (LEAP) instrument. + unit: NX_VOLTAGE + dimensions: + rank: 1 + dim: [[1, n_ions]] + + laser_gun(NXsource): + doc: | + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + name: + doc: Given name/alias. + (NXfabrication): + wavelength(NX_FLOAT): + doc: Nominal wavelength of the laser radiation. + unit: NX_WAVELENGTH + power(NX_FLOAT): + doc: Nominal power of the laser source while illuminating the specimen. + unit: NX_POWER + pulse_energy(NX_FLOAT): + doc: Average energy of the laser at peak of each pulse. + # NEW ISSUE: needs clearer specification/definition + unit: NX_ENERGY + (NXtransformations): + doc: | + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + laser_beam(NXbeam): + doc: | + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set + doc: | + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + spot_position(NXcollection): # NXsnapshot, NXcg_point_set + doc: | + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. diff --git a/contributed_definitions/nyaml/NXpump.yaml b/contributed_definitions/nyaml/NXpump.yaml new file mode 100644 index 0000000000..8755f51514 --- /dev/null +++ b/contributed_definitions/nyaml/NXpump.yaml @@ -0,0 +1,11 @@ +category: base +doc: | + Device to reduce an atmosphere to a controlled remaining pressure level. +NXpump: + (NXfabrication): + design: + doc: Principle type of the pump. + enumeration: [membrane, rotary_vane, roots, turbo_molecular] +# NEW ISSUE: take community input and work further to store what is relevant to report about pumps +# NEW ISSUE: see e.g. https://www.youtube.com/watch?v=Nsr_AdTiIIA for a discussion about +# NEW ISSUE: the role, pros and cons of pump used for atom probe microscopy diff --git a/contributed_definitions/nyaml/NXreflectron.yaml b/contributed_definitions/nyaml/NXreflectron.yaml new file mode 100644 index 0000000000..f61cef2148 --- /dev/null +++ b/contributed_definitions/nyaml/NXreflectron.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Device for reducing flight time differences of ions in ToF experiments. +NXreflectron: + name: + doc: Given name/alias. + (NXfabrication): + description: + doc: | + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + (NXtransformations): + doc: | + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. diff --git a/contributed_definitions/nyaml/NXregistration.yml b/contributed_definitions/nyaml/NXregistration.yml new file mode 100644 index 0000000000..3a3f889af7 --- /dev/null +++ b/contributed_definitions/nyaml/NXregistration.yml @@ -0,0 +1,15 @@ +category: base +doc: "Describes image registration procedures." +(NXregistration): + applied(NX_BOOLEAN): + doc: "Has the registration been applied?" + last_process(NX_CHAR): + doc: "Indicates the name of the last operation applied in the NXprocess sequence." + depends_on(NX_CHAR): + doc: "Specifies the position by pointing to the last transformation in the transformation chain in the NXtransformations group." + (NXtransformations): + doc: + "To describe the operations of image registration (combinations of rigid + translations and rotations)" + description(NX_CHAR): + doc: "Description of the procedures employed." diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml new file mode 100644 index 0000000000..19436b41e6 --- /dev/null +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -0,0 +1,29 @@ +category: base +doc: | + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. +NXscanbox_em: + calibration_style: + center(NX_NUMBER): + unit: NX_ANY + # \@units: + # enumeration: nm + flyback_time(NX_FLOAT): + unit: NX_TIME + line_time(NX_FLOAT): + unit: NX_TIME + pixel_time(NX_FLOAT): + # pixel_dwell_time? + unit: NX_TIME + requested_pixel_time(NX_FLOAT): + unit: NX_TIME + rotation(NX_FLOAT): + unit: NX_ANGLE + ac_line_sync(NX_BOOLEAN): + (NXfabrication): +# (NXcg_point_set): +# NEW ISSUE: build on work of EMglossary with HMC and use duty cycle instead +# NEW ISSUE: make use of and define duty cycle diff --git a/contributed_definitions/nyaml/NXsensor_scan.yaml b/contributed_definitions/nyaml/NXsensor_scan.yaml new file mode 100644 index 0000000000..32844608b9 --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor_scan.yaml @@ -0,0 +1,131 @@ +doc: | + Application definition for a generic scan using sensors. + + In this application definition, times should be specified always together + with an UTC offset. +category: application +symbols: + doc: "Variables used to set a common size for collected sensor data." + N_scanpoints: "The number of scan points measured in this scan." +NXsensor_scan: + (NXentry): + definition(NX_CHAR): + \@version: + enumeration: [NXsensor_scan] + experiment_identifier(NX_CHAR): + exists: recommended + experiment_description(NX_CHAR): + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + (NXprocess): + doc: | + Define the program that was used to generate the results file(s) + with measured data and metadata. + program(NX_CHAR): + doc: | + Commercial or otherwise defined given name of the program + (or a link to the instrument software). + \@version: + doc: | + Either version with build number, commit hash, or description of an + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@program_url: + doc: | + Website of the software. + (NXuser): + doc: | + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. + name(NX_CHAR): + doc: | + Name of the user. + affiliation(NX_CHAR): + exists: recommended + doc: | + Name of the affiliation of the user at the point in time when + the experiment was performed. + address(NX_CHAR): + exists: recommended + doc: | + Full address (street, street number, ZIP, city, country) + of the user's affiliation. + email(NX_CHAR): + exists: recommended + doc: | + Email address of the user. + orcid(NX_CHAR): + exists: recommended + doc: | + Author ID defined by https://orcid.org/. + telephone_number(NX_CHAR): + exists: recommended + doc: | + Official telephone number of the user. + (NXinstrument): + (NXenvironment): + doc: | + Describes an environment setup for the experiment. + + All the setting values of the independently scanned controllers are listed under corresponding + NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each + measurement sensor. + + For example, in a temperature-dependent IV measurement, the temperature and voltage must be + present as independently scanned controllers and the current sensor must also be present with + its readings. + (NXsensor): + (NXdata): + exists: recommended + doc: | + Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. + value(NX_FLOAT): + unit: NX_ANY + doc: | + For each point in the scan space, either the nominal setpoint of an independently scanned controller + or a representative average value of a measurement sensor is registered. + + The length of each sensor's data value array stored in this group should be equal to the number of scan points + probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. + This allows the scan to be made in any order as the user describes above in the experiment. We get matching + values simply using the index of the scan point. + dimensions: + rank: 1 + dim: [[1, N_scanpoints]] + + value_timestamp(NX_DATE_TIME): + exists: recommended + doc: | + Timestamp for when the values provided in the value field were registered. + + Individual readings can be stored with their timestamps under value_log. This is to timestamp + the nominal setpoint or average reading values listed above in the value field. + run_control(NX_CHAR): + exists: recommended + \@description: + doc: | + Free-text describing the data acquisition control: an internal + sweep using the built-in functionality of the controller device, + or a set/wait/read/repeat mechanism. + calibration_time(NX_DATE_TIME): + doc: | + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. + (NXpid): + independent_controllers: + doc: | + A list of names of NXsensor groups used as independently scanned controllers. + measurement_sensors: + doc: | + A list of names of NXsensor groups used as measurement sensors. + (NXsample): + name(NX_CHAR): + (NXdata): + doc: | + A scan specific representation of the measured signals as a function of the independently controlled environment settings. + Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. diff --git a/contributed_definitions/nyaml/NXslip_system_set.yaml b/contributed_definitions/nyaml/NXslip_system_set.yaml new file mode 100644 index 0000000000..da0651ea37 --- /dev/null +++ b/contributed_definitions/nyaml/NXslip_system_set.yaml @@ -0,0 +1,38 @@ +category: base +doc: | + Base class for describing a set of crystallographic slip systems. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n: Number of slip systems. +NXslip_system_set: + # number_of_objects(NX_UINT): + # identifier_offset(NX_UINT): + # identifier(NX_UINT): + lattice_type: + # doc: Array of lattice types. + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, trigonal, hexagonal, cubic] + # dimensions: + # rank: 1 + # dim: [[1, n]] + miller_plane(NX_NUMBER): + doc: Array of Miller indices which describe the crystallographic plane. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n], [2, i]] + # fastest changing dimension needs to be i because for instance for hexagonal hkil is needed + miller_direction(NX_NUMBER): + doc: Array of Miller indices which describe the crystallographic direction. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n], [2, i]] + is_specific(NX_BOOLEAN): + doc: | + For each slip system a marker whether the specified Miller indices + refer to the specific slip system or the set of crystallographic equivalent + slip systems of the respective family of slip systems. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n]] diff --git a/contributed_definitions/nyaml/NXspatial_filter.yaml b/contributed_definitions/nyaml/NXspatial_filter.yaml new file mode 100644 index 0000000000..7f2b341296 --- /dev/null +++ b/contributed_definitions/nyaml/NXspatial_filter.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Spatial filter to filter entries within a region-of-interest based on their position. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ellipsoids: Number of ellipsoids. + n_hexahedra: Number of hexahedra. + n_cylinders: Number of cylinders. +# n_polyhedra: Number of polyhedra. +# n_vertices: Number of vertices for polyhedra. +# n_facets: Number of facets for polyhedra. +NXspatial_filter: + windowing_method: + doc: | + Qualitative statement which specifies which spatial filtering with respective + geometric primitives or bitmask is used. These settings are possible: + + * entire_dataset, no filter is applied, the entire dataset is used. + * union_of_primitives, a filter with (rotated) geometric primitives. + All ions in or on the surface of the primitives are considered + while all other ions are ignored. + * bitmasked_points, a boolean array whose bits encode with 1 + which ions should be included. Those ions whose bit is set to 0 + will be excluded. Users of python can use the bitfield operations + of the numpy package to define such bitfields. + + Conditions: + In the case that windowing_method is entire_dataset all entries are processed. + In the case that windowing_method is union_of_primitives, + it is possible to specify none or all types of primitives + (ellipsoids, cylinder, hexahedra). If no primitives are specified + the filter falls back to entire_dataset. + In the case that windowing_method is bitmask, the bitmask has to be defined; + otherwise the filter falls back to entire dataset. + enumeration: [entire_dataset, union_of_primitives, bitmask] + (NXcg_ellipsoid_set): + (NXcg_cylinder_set): + (NXcg_hexahedron_set): + (NXcs_filter_boolean_mask): diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml new file mode 100644 index 0000000000..8772ffd4b6 --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml @@ -0,0 +1,104 @@ +category: base +doc: | + Container for reporting a set of electron energy loss (EELS) spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + + The latter pattern is the most frequently used. + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. +symbols: +# n_p: Number of scan points + n_y: Number of pixel per EELS mapping in the slow direction. + n_x: Number of pixel per EELS mapping in the fast direction. + n_energy_loss: Number of electron energy loss bins. +NXspectrum_set_em_eels: + (NXprocess): + doc: | + Details how EELS spectra were processed from the detector readings. + source: + doc: | + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_eels were loaded during + parsing to represent them in e.g. databases. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + program: + doc: | + Commercial or otherwise given name to the program which was used + to process detector data into the EELS spectra stack and summary. + \@version: + doc: | + Program 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. + stack(NXdata): + doc: | + Collected EELS spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, n_energy_loss]] + \@long_name: + doc: EELS counts + # \@signal: counts + # \@axes: [ypos, xpos, energy_loss] + # \@energy_loss_indices: 2 + # \@xpos_indices: 1 + # \@ypos_indices: 0 + ypos(NX_NUMBER): + doc: Pixel center of mass position y-coordinates. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis. + xpos(NX_NUMBER): + doc: Pixel center of mass position x-coordinates. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis. + energy_loss(NX_NUMBER): + doc: Pixel center of mass energy loss bins. + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy_loss]] + \@long_name: + doc: Label for the energy loss axis. + summary(NXdata): + doc: | + Accumulated EELS spectrum over all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + counts(NX_NUMBER): + doc: Counts for specific energy losses. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_energy_loss]] + \@long_name: + doc: Counts electrons with an energy loss within binned range. + # \@signal: counts + # \@axes: [energy_loss] + # \@energy_loss_indices: 0 + energy_loss(NX_NUMBER): + doc: Pixel center of mass energy loss bins. + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy_loss]] + \@long_name: + doc: Energy loss diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml new file mode 100644 index 0000000000..1bbaa66b1a --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml @@ -0,0 +1,194 @@ +category: base +doc: | + Container for reporting a set of energy-dispersive X-ray spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + `IUPAC instead of Siegbahn notation `_ + should be used. +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: +# n_p: Number of scan points + n_y: Number of pixel per X-ray mapping in the slow direction + n_x: Number of pixel per X-ray mapping in the fast direction + n_photon_energy: Number of X-ray photon energy (bins) + n_elements: Number of identified elements + n_peaks: Number of peaks +NXspectrum_set_em_xray: + (NXprocess): + doc: | + Details how X-ray spectra were processed from the detector readings. + source: + doc: | + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_xray were loaded during + parsing to represent them in e.g. databases. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + program: + doc: | + Commercial or otherwise given name to the program which was used + to process detector data into the X-ray spectra stack and summary. + \@version: + doc: | + Program 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. + # ##MK::for supporting arbitrary scan pattern we need a good example first + # ##MK::feel free to contact us in this regard! + stack(NXdata): + doc: | + Collected X-ray spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + counts(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, n_photon_energy]] + \@long_name: + doc: X-ray photon counts + # \@signal: counts + # \@axes: [ypos, xpos, photon_energy] + # \@ypos_indices: 0 + # \@xpos_indices: 1 + # \@photon_energy_indices: 2 + ypos(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis + xpos(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis + photon_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_photon_energy]] + \@long_name: + doc: X-ray energy + summary(NXdata): + doc: | + Accumulated X-ray spectrum over all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + counts(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_photon_energy]] + \@long_name: + doc: X-ray photon counts + # \@signal: counts + # \@axes: [photon_energy] + # \@photon_energy_indices: 0 + photon_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_photon_energy]] + \@long_name: + doc: X-ray energy + + # for post-processing of/with the above-defined data entries + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + program: + doc: | + Given name of the program that was used to perform this computation. + \@version: + doc: | + Program 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. + (NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are group with the same peak. + element_names(NX_CHAR): + doc: List of the names of identified elements. + dimensions: + rank: 1 + dim: [[1, n_elements]] + composition_map(NXprocess): + doc: | + Individual element-specific EDX/EDS/EDXS/SXES mapping + + A composition map is an image whose intensities for each pixel are the + accumulated X-ray quanta *under the curve(s)* of a set of peaks. + program: + doc: | + Given name of the program that was used to perform this computation. + \@version: + doc: | + Program 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. + peaks: + doc: | + A list of strings of named instances of NXpeak from indexing + whose X-ray quanta where accumulated for each pixel. + dimensions: + rank: 1 + dim: [[1, n_peaks]] + name: + doc: Human-readable, given name to the image. + # example how an element-specific pattern could be stored + (NXdata): + doc: | + Individual element-specific maps. Individual maps should + each be a group and be named according to element_names. + counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_y], [2, n_x]] + \@long_name: + doc: Accumulated X-ray photon counts + # \@signal: counts + # \@axes: [ypos, xpos] + # \@xpos_indices: 1 + # \@ypos_indices: 0 + ypos(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis + xpos(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis diff --git a/contributed_definitions/nyaml/NXspindispersion.yml b/contributed_definitions/nyaml/NXspindispersion.yml new file mode 100644 index 0000000000..05a9b6026f --- /dev/null +++ b/contributed_definitions/nyaml/NXspindispersion.yml @@ -0,0 +1,38 @@ +category: base +doc: + "Subclass of NXelectronanalyser to describe the spin filters in photoemission + experiments." +(NXspindispersion): + type(NX_CHAR): + doc: "Type of spin detector, VLEED, SPLEED, Mott, etc. " + figure_of_merit(NX_FLOAT): + doc: "Figure of merit of the spin detector" + unit: NX_DIMENSIONLESS + shermann_function(NX_FLOAT): + doc: "Effective Shermann function, calibrated spin selectivity factor" + unit: NX_DIMENSIONLESS + scattering_energy(NX_FLOAT): + doc: "Energy of the spin-selective scattering " + unit: NX_ENERGY + scattering_angle(NX_FLOAT): + doc: "Angle of the spin-selective scattering" + unit: NX_ANGLE + target(NX_CHAR): + doc: "Name of the target" + target_preparation(NX_CHAR): + doc: "Preparation procedure of the spin target" + target_preparation_date(NX_DATE_TIME): + doc: "Date of last preparation of the spin target" + depends_on(NX_CHAR): + doc: "Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group." + (NXtransformations): + doc: + "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 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." + + (NXdeflector): + doc: "Deflectors in the spin dispersive section" + (NXlens_em): + doc: "Individual lenses in the spin dispersive section" diff --git a/contributed_definitions/nyaml/NXstage_lab.yaml b/contributed_definitions/nyaml/NXstage_lab.yaml new file mode 100644 index 0000000000..9cb60d2d22 --- /dev/null +++ b/contributed_definitions/nyaml/NXstage_lab.yaml @@ -0,0 +1,131 @@ +category: base +doc: | + 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 `_ + * `Chip-based designs `_ + * `Further chip-based designs `_ + * `Stages in transmission electron microscopy `_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy `_ (page 124ff) + * `Specimens in atom probe `_ (page 47ff) + * `Exemplar micro-manipulators `_ + +NXstage_lab: + design: + doc: | + 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 + name: + doc: Given name/alias for the components making the stage. + (NXfabrication): + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + tilt_1(NX_FLOAT): + doc: Should be defined by the application definition. + unit: NX_ANGLE + tilt_2(NX_FLOAT): + doc: Should be defined by the application definition. + unit: NX_ANGLE + rotation(NX_FLOAT): + doc: Should be defined by the application definition. + unit: NX_ANGLE + position(NX_FLOAT): + doc: Should be defined by the application definition. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + bias_voltage(NX_FLOAT): + doc: Voltage applied to the stage to decelerate electrons. + unit: NX_VOLTAGE + # NEW ISSUE: rather the field if possible should be specified + (NXtransformations): + doc: | + 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. + (NXpositioner): +# see for complicated positioning tools like an eucentric five-axis table stage in an SEM +# https://www.nanotechnik.com/e5as.html +# shipswing_tilt(NXpositioner): +# normal_rotate(NXpositioner): +# normal_height(NXpositioner): +# inplane_translate1(NXpositioner): +# inplane_translate2(NXpositioner): +# NEW ISSUE: add temperature control units and components to apply external stimuli +# NEW ISSUE: on the specimen such as NXmech_testing_unit and NXfurnace, NXreaction_cell +# NEW ISSUE: by contrast, the purpose and design of so-called nano/or micromanipulators, +# i.e. automatable devices to perform e.g. site-specific lift out, procedures warrants +# to define an own class NXspecimen_manipulator given this is nothing else than +# miniature robot arm essential one could also think about creating an own NXrobotarm class, +# below are two examples of such tools as they are used in FIB and SEMs \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/NXsubsampling_filter.yaml new file mode 100644 index 0000000000..3a27ddf114 --- /dev/null +++ b/contributed_definitions/nyaml/NXsubsampling_filter.yaml @@ -0,0 +1,20 @@ +category: base +doc: | + Settings of a filter to sample entries based on their value. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXsubsampling_filter: + linear_range_min_incr_max(NX_UINT): + exists: required + doc: | + Triplet of the minimum, increment, and maximum value which will + be included in the analysis. The increment controls which n-th entry to take. + + Take as an example a dataset with 100 entries (their indices start at zero) + and the filter set to 0, 1, 99. This will process each entry. + 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third + entry beginning from entry 90 up to 99. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 3]] diff --git a/contributed_definitions/nyaml/NXtransmission.yml b/contributed_definitions/nyaml/NXtransmission.yml new file mode 100644 index 0000000000..96d774cb2e --- /dev/null +++ b/contributed_definitions/nyaml/NXtransmission.yml @@ -0,0 +1,211 @@ +# FAIRmat consortium 21.07.2022 +# Draft NeXus application definition for transmission experiments + +category: application +doc: Application definition for transmission experiments +symbols: + doc: Variables used throughout the experiment + N_wavelengths: Number of wavelength points + N_scans: Number of scans + +(NXtransmission): + (NXentry): + doc: | + This application definition + definition: + doc: "An application definition for transmission." + \@version: + doc: "Version number to identify which definition of this application + definition was used for this entry/data." + \@url: + doc: "URL where to find further material (documentation, examples) + relevant to the application definition." + enumeration: [NXtransmission] + start_time(NX_DATE_TIME): + doc: "Start time of the experiment." + experiment_identifier(NX_CHAR): + doc: | + Unique identifier of the experiment, such as a (globally persistent) + unique identifier. + + * The identifier is usually defined by the facility or principle + investigator. + * The identifier enables to link experiments to e.g. proposals. + experiment_description(NX_CHAR): + exists: optional + doc: "An optional free-text description of the experiment. + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description." + acquisition_program(NXfabrication): + # TODO: Just used a NXmanufacturer, maybe + # it is nicer to introduce a general NXprogram class? + # However, a program may also be viewed as some sort + # of instrument. + exists: optional + model(NX_CHAR): + doc: | + Commercial or otherwise defined given name to the program that was + used to generate the result file(s) with measured data and metadata. + identifier(NX_CHAR): + doc: | + Version number of the program that was used to generate the result + file(s) with measured data and metadata. + \@url(NX_CHAR): + exists: recommended + doc: Website of the software + operator(NXuser): + exists: [min, 1] + doc: "Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users if relevant is recommended." + name: + doc: "Name of the user." + affiliation: + doc: "Name of the affiliation of the user at the point in time when the + experiment was performed." + address: + doc: "Street address of the user's affiliation." + email: + doc: "Email address of the user." + url: + exists: recommended + doc: | + Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). + telephone_number: + exists: recommended + doc: "Telephone number of the user." + instrument(NXinstrument): + manufacturer(NXfabrication): + exists: recommended + doc: "Manufacturer of the instrument." + common_beam_mask(NXslit): + doc: Common beam mask to shape the incident beam + y_gap(NX_NUMBER): + doc: "The height of the common beam in percentage of the beam" + unit: NX_UNITLESS + common_beam_depolarizer(NX_BOOLEAN): + doc: | + If true, the incident beam is depolarized. + polarizer(NX_NUMBER): + doc: Polarizer value inside the beam path + unit: NX_ANGLE + ref_attenuator(NXattenuator): + doc: Attenuator in the reference beam + attenuator_transmission(NX_FLOAT): + sample_attenuator(NXattenuator): + doc: Attenuator in the sample beam + attenuator_transmission(NX_FLOAT): + spectrometer(NXmonochromator): + wavelength(NX_NUMBER): + doc: | + Wavelength value(s) used for the measurement. + An array of 1 or more elements. Length defines N_wavelenghts + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, N_wavelengths]] + spectral_resolution(NX_NUMBER): + doc: | + Overall spectral resolution of this spectrometer. + If several gratings are employed the spectral resoultion + should rather be specified for each grating inside the + NXgrating group of this spectrometer. + exists: optional + unit: NX_WAVENUMBER + (NXgrating): + exists: optional + doc: | + Diffraction grating, as could be used in a monochromator. + If two or more gratings were used, define the angular + dispersion and the wavelength range (min/max wavelength) + for each grating and make sure that the wavelength ranges + do not overlap. The dispersion should be defined for the + entire wavelength range of the experiment. + angular_dispersion(NX_NUMBER): + exists: optional + doc: Dispersion of the grating in nm/mm used. + blaze_wavelength(NX_NUMBER): + exists: optional + doc: The blaze wavelength of the grating used. + unit: NX_LENGTH + spectral_resolution(NX_NUMBER): + exists: optional + doc: | + Overall spectral resolution of the instrument + when this grating is used. + unit: NX_WAVENUMBER + wavelength_range(NX_NUMBER): + doc: Wavelength range in which this grating was used + dimensions: + rank: 1 + dim: [[1, 2]] + unit: NX_LENGTH + (NXdetector): + wavelength_range(NX_NUMBER): + doc: Wavelength range in which this detector was used + dimensions: + rank: 1 + dim: [[1, 2]] + unit: NX_LENGTH + type(NX_CHAR): + doc: Detector type + enumeration: [PMT, PbS, InGaAs] + response_time(NX_NUMBER): + doc: Response time of the detector + exists: optional + unit: NX_TIME + gain(NX_NUMBER): + doc: Detector gain + exists: optional + slit(NXslit): + doc: Slit setting used for measurement with this detector + type(NX_CHAR): + enumeration: [fixed, servo] + time_points(NX_NUMBER): + exists: optional + doc: An array of relative scan start time points. + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, N_scans]] + measured_data(NX_NUMBER): + doc: | + Resulting data from the measurement. + The length of the 2nd dimension is + the number of time points. + If it has length one the time_points + may be empty. + dimensions: + rank: 2 + dim: [[1, N_scans], [2, N_wavelengths]] + (NXsource): + doc: The lamp used for illumination + type(NX_CHAR): + doc: The type of lamp, e.g. halogen, D2 etc. + enumeration: [halogen, D2] + spectrum(NX_NUMBER): + doc: The spectrum of the lamp used + exists: optional + dimensions: + rank: 1 + dim: [[1, N_wavelengths]] + wavelength_range(NX_NUMBER): + doc: Wavelength range in which the lamp was used + dimensions: + rank: 1 + dim: [[1, 2]] + unit: NX_LENGTH + (NXsample): + # TODO: This should be extended by a generic + # NXsample class. + doc: Properties of the sample measured + name(NX_CHAR): + data(NXdata): + doc: | + A default view of the data emitted intensity vs. wavelength. + From measured_data plot intensity and wavelength. + \@axes: + doc: | + We recommend to use wavelength as a default attribute, but it can be + replaced by any suitable parameter along the X-axis. From c4ca2444943b9b654586b354bd10952c936a2fc4 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Wed, 8 Feb 2023 15:19:32 +0100 Subject: [PATCH 087/203] dir ND/BC/nyaml: Removing '()' around base class name. As '()' these raise error --- base_classes/nyaml/NXaperture.yml | 2 +- base_classes/nyaml/NXbeam.yml | 2 +- base_classes/nyaml/NXdetector.yml | 2 +- base_classes/nyaml/NXentry.yml | 2 +- base_classes/nyaml/NXinstrument.yml | 2 +- base_classes/nyaml/NXprocess.yml | 2 +- base_classes/nyaml/NXsample.yml | 2 +- base_classes/nyaml/NXsource.yml | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/base_classes/nyaml/NXaperture.yml b/base_classes/nyaml/NXaperture.yml index 26fae686a4..62c345e06b 100644 --- a/base_classes/nyaml/NXaperture.yml +++ b/base_classes/nyaml/NXaperture.yml @@ -1,6 +1,6 @@ category: base doc: "A beamline aperture" -(NXaperture): +NXaperture: \@default(NX_CHAR): doc: | Declares which child group contains a path leading to a :ref:`NXdata` group. diff --git a/base_classes/nyaml/NXbeam.yml b/base_classes/nyaml/NXbeam.yml index 88e5bc72d5..27096b72ff 100644 --- a/base_classes/nyaml/NXbeam.yml +++ b/base_classes/nyaml/NXbeam.yml @@ -12,7 +12,7 @@ symbols: nx: "Number of pixels of the horizontal axis (e.g. delay) of a FROG trace" ny: "Number of pixels of the vertical axis (e.g. frequency) of a FROG trace" category: base -(NXbeam): +NXbeam: distance(NX_FLOAT): unit: NX_LENGTH doc: "Distance from sample" diff --git a/base_classes/nyaml/NXdetector.yml b/base_classes/nyaml/NXdetector.yml index 1826f95858..6e38945a95 100644 --- a/base_classes/nyaml/NXdetector.yml +++ b/base_classes/nyaml/NXdetector.yml @@ -7,7 +7,7 @@ symbols: k: "number of detector pixels in the third (if necessary, fastest) direction" tof: "number of bins in the time-of-flight histogram" category: base -(NXdetector): +NXdetector: time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT doc: "Total time of flight" diff --git a/base_classes/nyaml/NXentry.yml b/base_classes/nyaml/NXentry.yml index b2655dfe35..4c92bc208d 100644 --- a/base_classes/nyaml/NXentry.yml +++ b/base_classes/nyaml/NXentry.yml @@ -6,7 +6,7 @@ doc: | It is mandatory that there is at least one group of this type in the NeXus file. category: base -(NXentry): +NXentry: \@default: doc: | .. index:: plotting diff --git a/base_classes/nyaml/NXinstrument.yml b/base_classes/nyaml/NXinstrument.yml index 37bd792161..91e292ee8f 100644 --- a/base_classes/nyaml/NXinstrument.yml +++ b/base_classes/nyaml/NXinstrument.yml @@ -6,7 +6,7 @@ doc: "Collection of the components of the instrument or beamline. This device allows the unique identification of beamline components in a way that is valid for both reactor and pulsed instrumentation." category: base -(NXinstrument): +NXinstrument: name: doc: "Name of instrument" \@short_name: diff --git a/base_classes/nyaml/NXprocess.yml b/base_classes/nyaml/NXprocess.yml index 39daa5fbf8..3ddceebbc3 100644 --- a/base_classes/nyaml/NXprocess.yml +++ b/base_classes/nyaml/NXprocess.yml @@ -1,6 +1,6 @@ doc: "Document an event of data processing, reconstruction, or analysis for this data." category: base -(NXprocess): +NXprocess: program(NX_CHAR): doc: "Name of the program used" sequence_index(NX_POSINT): diff --git a/base_classes/nyaml/NXsample.yml b/base_classes/nyaml/NXsample.yml index 17f525117f..37e7201e88 100644 --- a/base_classes/nyaml/NXsample.yml +++ b/base_classes/nyaml/NXsample.yml @@ -13,7 +13,7 @@ symbols: n_pField: "number of values in applied pressure field" n_sField: "number of values in applied stress field" category: base -(NXsample): +NXsample: name: doc: "Descriptive name of sample" chemical_formula: diff --git a/base_classes/nyaml/NXsource.yml b/base_classes/nyaml/NXsource.yml index 112ad77ece..8aa002b513 100644 --- a/base_classes/nyaml/NXsource.yml +++ b/base_classes/nyaml/NXsource.yml @@ -3,7 +3,7 @@ symbols: doc: "The symbols used in the schema to specify e.g. dimensions of arrays" nx: "Number of points in a spectrum" category: base -(NXsource): +NXsource: distance(NX_FLOAT): unit: NX_LENGTH doc: "Effective distance from sample From 3cae796becd3e9e0b71c38486a1b9b901af64f65 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Wed, 8 Feb 2023 15:32:06 +0100 Subject: [PATCH 088/203] dir ND/BC/ynaml: nxdl files generated by nyaml2nxdl from yml file in ND/BC/ynaml --- base_classes/nyaml/NXaperture.nxdl.xml | 87 +++ base_classes/nyaml/NXbeam.nxdl.xml | 286 ++++++++ base_classes/nyaml/NXdetector.nxdl.xml | 801 +++++++++++++++++++++++ base_classes/nyaml/NXentry.nxdl.xml | 270 ++++++++ base_classes/nyaml/NXinstrument.nxdl.xml | 82 +++ base_classes/nyaml/NXprocess.nxdl.xml | 64 ++ base_classes/nyaml/NXsample.nxdl.xml | 599 +++++++++++++++++ base_classes/nyaml/NXsource.nxdl.xml | 274 ++++++++ 8 files changed, 2463 insertions(+) create mode 100644 base_classes/nyaml/NXaperture.nxdl.xml create mode 100644 base_classes/nyaml/NXbeam.nxdl.xml create mode 100644 base_classes/nyaml/NXdetector.nxdl.xml create mode 100644 base_classes/nyaml/NXentry.nxdl.xml create mode 100644 base_classes/nyaml/NXinstrument.nxdl.xml create mode 100644 base_classes/nyaml/NXprocess.nxdl.xml create mode 100644 base_classes/nyaml/NXsample.nxdl.xml create mode 100644 base_classes/nyaml/NXsource.nxdl.xml diff --git a/base_classes/nyaml/NXaperture.nxdl.xml b/base_classes/nyaml/NXaperture.nxdl.xml new file mode 100644 index 0000000000..6877dc01a6 --- /dev/null +++ b/base_classes/nyaml/NXaperture.nxdl.xml @@ -0,0 +1,87 @@ + + + + + A beamline aperture + + + + 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. + + + + + Absorbing material of the aperture. + + + + + Description of the aperture. + + + + + Shape of the aperture. + + + + + + + + + + + + + + + + + The relevant dimension for the aperture, i.e. slit width, pinhole and iris + diameter + + + + + Specifies the position of the aperture 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 + 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. + + + + + Stores the raw positions of aperture motors. + + + + + Location and shape of the aperture. + + + + + Location and shape of each blade. + + + + + Describes any additional information. + + + diff --git a/base_classes/nyaml/NXbeam.nxdl.xml b/base_classes/nyaml/NXbeam.nxdl.xml new file mode 100644 index 0000000000..14b560bf19 --- /dev/null +++ b/base_classes/nyaml/NXbeam.nxdl.xml @@ -0,0 +1,286 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of pixels of the horizontal axis (e.g. delay) of a FROG trace + + + + + Number of pixels of the vertical axis (e.g. frequency) of a FROG trace + + + + + Properties of the neutron or X-ray beam at a given location. + + It will be referenced by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. + Note that variables such as the incident energy could be scalar values or arrays. + This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, + time distribution etc. at each beamline component. + Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. + + + + Distance from sample + + + + + In the case of a monchromatic beam this is the scalar energy. + Several other use cases are permitted, depending on the presence of other incident_energy_X fields. + + * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + Here, incident_energy_weights and incident_energy_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_energy_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + + + + + + + + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In + the case of shot-to-shot variation in the energy spread, this is a 2D array of + dimension nP by m (slow to fast) of the spreads of the corresponding wavelength + in incident_wavelength. + + + + + In the case of a polychromatic beam this is an array of length m of the relative + weights of the corresponding energies in incident_energy. In the case of a + polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np + by m (slow to fast) of the relative weights of the corresponding energies in + incident_energy. + + + + + Energy on leaving beamline component + + + + + + + + Energy change caused by beamline component + + + + + + + + In the case of a monchromatic beam this is the scalar wavelength. + Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. + + * In the case of a polychromatic beam this is an array of length m of wavelengths, + with the relative weights in incident_wavelength_weights. + * In the case of a monochromatic beam that varies shot-to-shot, + this is an array of wavelengths, one for each recorded shot. + Here, incident_wavelength_weights and incident_wavelength_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, + single-value wavelength value is available along with the original spectrum from which it was calibrated. + + + + + + + + Wavelength spread FWHM on entering component + + + + + + + + Divergence of beam entering this component + + + + + + + + + Size of the beam entering this component + + + + + + + + + Wavelength on leaving beamline component + + + + + + + + Incident polarization as a Stokes vector + + + + + + + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. + Correct parsing can still be implemented by using this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: 'farad' for capacitance). + * A string describing the units according to unidata unit operation notation, + if the unit is a complex combination of named units and does not have a name. + + Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. + Here: SI units are 'V2/m2'. + + + + + + Polarization as Stokes vector on leaving beamline component + + + + + + + Here: SI units are 'V2/m2'. + + + + + + Wavelength spread FWHM of beam leaving this component + + + + + + + + Divergence FWHM of beam leaving this component + + + + + + + + + flux incident on beam plane area + + + + + + + + Energy of a single pulse at the diagnostic point + + + + + Average power at the diagnostic point + + + + + Incident fluence at the diagnostic point + + + + Here: SI units are ''J/m2'', customary ''mJ/cm2''. + + + + + + FWHM duration of the pulses at the diagnostic point + + + + + FROG trace of the pulse. + + + + + + + + + Horizontal axis of a FROG trace, i.e. delay. + + + + + + + + Vertical axis of a FROG trace, i.e. frequency. + + + + + + + + The type of chirp implemented + + + + + Group delay dispersion of the pulse for linear chirp + + + + + Distribution of beam with respect to relevant variable e.g. wavelength. This is + mainly useful for simulations which need to store plottable information at each + beamline component. + + + + + .. 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/nyaml/NXdetector.nxdl.xml b/base_classes/nyaml/NXdetector.nxdl.xml new file mode 100644 index 0000000000..d5df7c8c66 --- /dev/null +++ b/base_classes/nyaml/NXdetector.nxdl.xml @@ -0,0 +1,801 @@ + + + + + + These symbols will be used below to coordinate datasets with the same + shape. + + + + number of scan points (only present in scanning measurements) + + + + + number of detector pixels in the first (slowest) direction + + + + + number of detector pixels in the second (faster) direction + + + + + number of detector pixels in the third (if necessary, fastest) + direction + + + + + number of bins in the time-of-flight histogram + + + + + A detector, detector bank, or multidetector. + + + + Total time of flight + + + + + + + + + + + + + + + + + Total time of flight + + + + + + In DAQ clock pulses + + + + + + + Clock frequency in Hz + + + + + + Identifier for detector (pixels) Can be multidimensional, if needed + + + + + Data values from the detector. + + + + + + + + + + Title of measurement + + + + + Integral of data as check of data integrity + + + + + + The best estimate of the uncertainty in the data value. Where possible, this + should be the standard deviation, which has the same units as the data. The form + data_error is deprecated. + + + + + + + + + + + Offset from the detector center in x-direction. Can be multidimensional when + needed. + + + + + + + + + + + + + + x-axis offset from detector center + + + + + + Offset from the detector center in the y-direction. Can be multidimensional when + different values are required for each pixel. + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + Offset from the detector center in the z-direction. Can be multidimensional when + different values are required for each pixel. + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + This is the distance to the previous component in the instrument; most often the + sample. The usage depends on the nature of the detector: Most often it is the + distance of the detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + + + + + + + + + This is the polar angle of the detector towards the previous component in the + instrument; most often the sample. The usage depends on the nature of the + detector. Most often it is the polar_angle of the detector assembly. But there + are irregular detectors. In this case, the polar_angle must be specified for + each detector pixel. + + + + + + + + + + This is the azimuthal angle angle of the detector towards the previous component + in the instrument; most often the sample. The usage depends on the nature of the + detector. Most often it is the azimuthal_angle of the detector assembly. But + there are irregular detectors. In this case, the azimuthal_angle must be + specified for each detector pixel. + + + + + + + + + + name/manufacturer/model/etc. information + + + + + Serial number for the detector + + + + + Local name for the detector + + + + + Position and orientation of detector + + + + + Solid angle subtended by the detector at the sample + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size. + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size + + + + + + + + + Detector dead time + + + + + + + + + + Detector gas pressure + + + + + + + + + maximum drift space dimension + + + + + Crate number of detector + + + + + + + + Equivalent local term + + + + + + Slot number of detector + + + + + + + + Equivalent local term + + + + + + Input number of detector + + + + + + + + Equivalent local term + + + + + + Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission + chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, ... + + + + + Spectral efficiency of detector with respect to e.g. wavelength + + + + + + + + + + + + + + + + + + + + + + + efficiency of the detector + + + + + + + + + + This field can be two things: + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + + + + + + + + + + + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + + + + + + + + + + Start time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + stop time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + date of last calibration (geometry and/or efficiency) measurements + + + + + summary of conversion of array data to pixels (e.g. polynomial approximations) + and location of details of the calibrations + + + + + How the detector is represented + + + + + + + + + + Elapsed actual counting time + + + + + + + + + Use this group to provide other data related to this NXdetector group. + + + + + In order to properly sort the order of the images taken in (for example) a + tomography experiment, a sequence number is stored with each image. + + + + + + + + This is the x position where the direct beam would hit the detector. This is a + length and can be outside of the actual detector. The length can be in physical + units or pixels as documented by the units attribute. + + + + + This is the y position where the direct beam would hit the detector. This is a + length and can be outside of the actual detector. The length can be in physical + units or pixels as documented by the units attribute. + + + + + This is the start number of the first frame of a scan. In PX one often scans a + couple of frames on a give sample, then does something else, then returns to the + same sample and scans some more frames. Each time with a new data file. This + number helps concatenating such measurements. + + + + + The diameter of a cylindrical detector + + + + + The acquisition mode of the detector. + + + + + + + + + + + + + True when the angular calibration has been applied in the electronics, false + otherwise. + + + + + Angular calibration data. + + + + + + + + + True when the flat field correction has been applied in the electronics, false + otherwise. + + + + + Flat field correction data. + + + + + + + + + Errors of the flat field correction data. The form flatfield_error is + deprecated. + + + + + + + + + True when the pixel mask correction has been applied in the electronics, false + otherwise. + + + + + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + + + + + + + + + True when a count-rate correction has already been applied in the electronics, + false otherwise. + + + + + How many bits the electronics reads per pixel. With CCD's and single photon + counting detectors, this must not align with traditional integer sizes. This can + be 4, 8, 12, 14, 16, ... + + + + + Time it takes to read the detector (typically milliseconds). This is important + to know for time resolved experiments. + + + + + Time it takes to start exposure after a trigger signal has been received. This + is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set + delay.. This is important to know for time resolved experiments. + + + + + User-specified trigger delay. + + + + + Time it takes to start exposure after a trigger signal has been received. This + is the reaction time of the detector hardware after receiving the trigger signal + to when the detector starts to acquire the exposure. It forms the lower boundary + of the trigger_delay_time when the user does not request an additional delay. + + + + + Time during which no new trigger signal can be accepted. Typically this is the + trigger_delay_time + exposure_time + readout_time. This is important to know for + time resolved experiments. + + + + + This is time for each frame. This is exposure_time + readout time. + + + + + + + + The gain setting of the detector. This influences background etc. + + + + + + + + + + + The value at which the detector goes into saturation. Especially common to CCD + detectors, the data is known to be invalid above this value. For example, given + a saturation_value and an underload_value, the valid pixels are those less than + or equal to the saturation_value and greater than or equal to the + underload_value. + + + + + The lowest value at which pixels for this detector would be reasonably measured. + The data is known to be invalid below this value. For example, given a + saturation_value and an underload_value, the valid pixels are those less than or + equal to the saturation_value and greater than or equal to the underload_value. + + + + + CCD images are sometimes constructed by summing together multiple short + exposures in the electronics. This reduces background etc. This is the number of + short exposures used to sum images for an image. + + + + + At times, radiation is not directly sensed by the detector. Rather, the detector + might sense the output from some converter like a scintillator. This is the name + of this converter material. + + + + + At times, radiation is not directly sensed by the detector. Rather, the detector + might sense the output from some converter like a scintillator. This is the + thickness of this converter material. + + + + + Single photon counter detectors can be adjusted for a certain energy range in + which they work optimally. This is the energy setting for this. + + + + + For use in special cases where the data in NXdetector is represented in several + parts, each with a separate geometry. Use one or more instances of the + NXdetector_module group to declare regions of interest or some other subdivision + of a detector. + + + + Shape description of the whole detector. Use only if pixels in the detector are + not of uniform shape. + + + + + Shape description of the whole detector. Use only if pixels in the detector are + not of uniform shape and require being described by cylinders. + + + + + + .. 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. + + + + + Type of electron amplifier, MCP, channeltron, etc. + + + + + Description of the detector type, DLD, Phosphor+CCD, CMOS. + + + + + Voltage applied to detector. + + + + + Voltage applied to the amplifier. + + + + + The low voltage of the amplifier migh not be the ground. + + + + + Size of each imaging sensor chip on the detector. + + + + + Number of imaging sensor chips on the detector. + + + + + Physical size of the pixels of the imaging chip on the detector. + + + + + Number of raw active elements in each dimension. Important for swept scans. + + + + + raw data output from the detector + + + diff --git a/base_classes/nyaml/NXentry.nxdl.xml b/base_classes/nyaml/NXentry.nxdl.xml new file mode 100644 index 0000000000..b062a10d3d --- /dev/null +++ b/base_classes/nyaml/NXentry.nxdl.xml @@ -0,0 +1,270 @@ + + + + + (**required**) :ref:`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. + + + + .. index:: plotting + + Declares which :ref:`NXdata` (or :ref:`NXsubentry`) group + contains the data to be shown by default. + It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. + The value is the name of the default :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. + + .. [#] NIAC2014 discussion summary: + https://www.nexusformat.org/2014_How_to_find_default_data.html + + + + + The data group + + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 + + + + + ISIS Muon IDF_Version + + + + + Extended title for entry + + + + + Unique identifier for the experiment, defined by the facility, possibly linked + to the proposals + + + + + Brief summary of the experiment, including key objectives. + + + + + Description of the full experiment (document in pdf, latex, ...) + + + + + User or Data Acquisition defined group of NeXus files or NXentry + + + + + Brief summary of the collection, including grouping criteria. + + + + + Unique identifier for the measurement, defined by the facility. + + + + + UUID identifier for the measurement. + + + + Version of UUID used + + + + + + Reserved for future use by NIAC. See + https://github.com/nexusformat/definitions/issues/382 + + + + + (alternate use: see same field in :ref:`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms. + This field is provided so that :ref:`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Local NXDL schema extended from the entry specified in the ``definition`` field. + This contains any locally-defined, additional fields in the entry. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Starting time of measurement + + + + + Ending time of measurement + + + + + Duration of measurement + + + + + Time transpired actually collecting data i.e. taking out time when collection + was suspended due to e.g. temperature out of range + + + + + Such as '2007-3'. Some user facilities organize their beam time into run cycles. + + + + + Name of program used to generate this file + + + + Program version number + + + + + configuration of the program + + + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a + chopper, by the moderator or the source itself. In other words: it the distance + to the component which gives the T0 signal to the detector electronics. If + another component in the NXinstrument hierarchy provides this information, this + should be a link. + + + + + City and country where the experiment took place + + + + + Start time of experimental run that includes the current measurement, for + example a beam time. + + + + + End time of experimental run that includes the current measurement, for example + a beam time. + + + + + Name of the institution hosting the facility + + + + + Name of the experimental facility + + + + + Name of the laboratory or beamline + + + + + Notes describing entry + + + + + A small image that is representative of the entry. An example of this is a + 640x480 jpeg image automatically produced by a low resolution plot of the + NXdata. + + + + The mime type should be an ``image/*`` + + + + + + + + + + + + + + + diff --git a/base_classes/nyaml/NXinstrument.nxdl.xml b/base_classes/nyaml/NXinstrument.nxdl.xml new file mode 100644 index 0000000000..bec81c7a30 --- /dev/null +++ b/base_classes/nyaml/NXinstrument.nxdl.xml @@ -0,0 +1,82 @@ + + + + + Collection of the components of the instrument or beamline. Template of + instrument descriptions comprising various beamline components. Each component + will also be a NeXus group defined by its distance from the sample. Negative + distances represent beamline components that are before the sample while + positive distances represent components that are after the sample. This device + allows the unique identification of beamline components in a way that is valid + for both reactor and pulsed instrumentation. + + + + Name of instrument + + + + short name for instrument, perhaps the acronym + + + + + + Energy resolution of the experiment (FWHM or gaussian broadening) + + + + + Momentum resolution of the experiment (FWHM) + + + + + Angular resolution of the experiment (FWHM) + + + + + Spatial resolution of the experiment (Airy disk radius) + + + + + Temporal resolution of the experiment (FWHM) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + .. 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/nyaml/NXprocess.nxdl.xml b/base_classes/nyaml/NXprocess.nxdl.xml new file mode 100644 index 0000000000..5b12ff4776 --- /dev/null +++ b/base_classes/nyaml/NXprocess.nxdl.xml @@ -0,0 +1,64 @@ + + + + + Document an event of data processing, reconstruction, or analysis for this data. + + + + Name of the program used + + + + + Sequence index of processing, for determining the order of multiple + **NXprocess** steps. Starts with 1. + + + + + Version of the program used + + + + + Date and time of processing. + + + + + Describes the operations of image registration + + + + + Describes the operations of image distortion correction + + + + + Describes the operations of calibration procedures, e.g. axis calibrations. + + + + + Notes contain information about how the data was processed or anything about the + data provenance. The contents of the note can be anything that the processing + code can understand, or simple text. The name will be numbered to allow for + ordering of steps. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + diff --git a/base_classes/nyaml/NXsample.nxdl.xml b/base_classes/nyaml/NXsample.nxdl.xml new file mode 100644 index 0000000000..9c74b79383 --- /dev/null +++ b/base_classes/nyaml/NXsample.nxdl.xml @@ -0,0 +1,599 @@ + + + + + + symbolic array lengths to be coordinated between various fields + + + + number of compositions + + + + + number of temperatures + + + + + number of values in applied electric field + + + + + number of values in applied magnetic field + + + + + number of values in applied pressure field + + + + + number of values in applied stress field + + + + + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + + + + Descriptive name of sample + + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * 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. + * This is the *Hill* system used by Chemical Abstracts. + + + + + Sample temperature. This could be a scanned variable + + + + + + + + Applied electric field + + + + + + + + + + + + + + + Applied magnetic field + + + + + + + + + + + + + + + Applied external stress field + + + + + + + + + + + + + + + Applied pressure + + + + + + + + Sample changer position + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Unit cell parameters (lengths and angles) + + + + + + + + + Volume of the unit cell + + + + + + + + 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. + + + + + + + + + + Mass of sample + + + + + + + + Density of sample + + + + + + + + Relative Molecular Mass of sample + + + + + + + + + + + + + + + + + + + + + + The atmosphere will be one of the components, which is where its details will be + stored; the relevant components will be indicated by the entry in the + sample_component member. + + + + + + + + + + + + + + Description of the sample + + + + + Date of preparation of the sample + + + + + The position and orientation of the center of mass of the sample + + + + + Details of beam incident on sample - used to calculate sample/beam interaction + point + + + + + One group per sample component This is the perferred way of recording per + component information over the n_comp arrays + + + + + Details of the component of the sample and/or can + + + + + + + + Type of component + + + + + + + + + + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + + + + + + Crystallographic point group, deprecated if space_group present + + + + + + + + Path length through sample/can for simple case when it does not vary with + scattering direction + + + + + Thickness of a beam entry/exit window on the can (mm). It is assumed to be the + same for entry and exit + + + + + sample thickness + + + + + Identification number or signatures of the sample used. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (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 + + + + + Physical state of the sample + + + + + Chemical purity of the sample + + + + + Surface termination of the sample (if crystalline) + + + + + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + + + + + Full chemical name of the sample + + + + + CAS registry number of the sample chemical content. + + + + + Gases might be fluxed on the surface for various reasons. Chemical designation, + or residual. + + + + + In the case of a fixed pressure measurement this is the scalar pressure. In the + case of an experiment in which pressure changes, or anyway is recorded, this is + an array of length m of pressures. + + + + + Element of evaporated surface dopant such as alkali or other + + + + + Nominal thickness of the evaporated dopant + + + + + Voltage applied to sample and sample holder. + + + + + Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition + etc.) + + + + + Name of the sample vendor (company or research group) + + + + + Material of the substrate in direct contact with the sample. + + + + + Physical state of the substrate, similar options to sample_state + + + + + Current to neutralize the photoemission current. This field may also be found in + NXmanpulator if present. + + + + + Possible bias of the sample with respect to analyser ground. This field may also + be found as sample_bias in NXmanipulator if present. + + + + + Further notes. + + + + + As a function of Wavelength + + + + + temperature.value is a link to e.g. temperature_env.sensor1.value + + + + + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + + + + + Additional sample temperature environment information + + + + + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + + + + + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value + + + + + Additional sample magnetic environment information + + + + + value sent to user's sample setup + + + + + logged value (or logic state) read from user's setup + + + + + 20 character fixed length sample description for legends + + + + + Optional rotation angle for the case when the powder diagram has been obtained + through an omega-2theta scan like from a traditional single detector powder + diffractometer + + + + + Translation of the sample along the X-direction of the laboratory coordinate + system + + + + + Translation of the sample along the Z-direction of the laboratory coordinate + system + + + + + Any positioner (motor, PZT, ...) used to locate the sample + + + + + 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 sample 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/nyaml/NXsource.nxdl.xml b/base_classes/nyaml/NXsource.nxdl.xml new file mode 100644 index 0000000000..ae24b92e00 --- /dev/null +++ b/base_classes/nyaml/NXsource.nxdl.xml @@ -0,0 +1,274 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of points in a spectrum + + + + + The neutron or x-ray storage ring/facility. + + + + Effective distance from sample Distance as seen by radiation from sample. This + number should be negative to signify that it is upstream of the sample. + + + + + Name of source + + + + short name for source, perhaps the acronym + + + + + + Type of radiation source (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + + + + + + + + + Type of radiation probe (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + Source power + + + + + Source emittance (nm-rad) in X (horizontal) direction. + + + + + Source emittance (nm-rad) in Y (horizontal) direction. + + + + + Particle beam size in x + + + + + Particle beam size in y + + + + + Source intensity/area (example: s-1 cm-2) + + + + + Source energy. For storage rings, this would be the particle beam energy. For + X-ray tubes, this would be the excitation voltage. + + + + + Accelerator, X-ray tube, or storage ring current + + + + + Accelerator voltage + + + + + Frequency of pulsed source + + + + + Period of pulsed source + + + + + Pulsed source target material or other material used to generate light, e.g. He, + Ar gas for lasers, Xe or Hg/Cd vapor for arc lamps, etc. + + + + + + + + + + + + + + + + + + + Any source/facility related messages/events that occurred during the experiment + + + + + For storage rings, description of the bunch pattern. This is useful to describe + irregular bunch patterns. + + + + name of the bunch pattern + + + + + + For storage rings, the number of bunches in use. + + + + + For storage rings, temporal length of the bunch + + + + + For storage rings, time between bunches + + + + + Temporal width of source pulse + + + + + Source pulse shape + + + + + Source operating mode + + + + + For storage rings + + + + + For storage rings + + + + + + + Is the synchrotron operating in top_up mode? + + + + + For storage rings, the current at the end of the most recent injection. + + + + Date and time of the most recent injection. + + + + + + The center photon energy of the source, before it is monochromatized or + converted + + + + + The center wavelength of the source, before it is monochromatized or converted + + + + + For pulsed sources, the energy of a single pulse + + + + + For pulsed sources, the pulse energy divided by the pulse duration + + + + + Some facilities tag each bunch. First bunch of the measurement + + + + + Last bunch of the measurement + + + + + 'Engineering' location of source + + + + + The wavelength or energy distribution of the source + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + From 82558aa18fd61a0f69721e8f2e8a9ecaffa79b63 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Wed, 8 Feb 2023 16:41:27 +0100 Subject: [PATCH 089/203] dir ND/condefs/nymals: Removing '()' around definition name, because of that we get errors. --- contributed_definitions/nyaml/NXcalibration.yml | 2 +- contributed_definitions/nyaml/NXcollectioncolumn.yml | 2 +- contributed_definitions/nyaml/NXdeflector.yml | 2 +- contributed_definitions/nyaml/NXdistortion.yml | 2 +- contributed_definitions/nyaml/NXelectronanalyser.yml | 2 +- contributed_definitions/nyaml/NXenergydispersion.yml | 2 +- contributed_definitions/nyaml/NXlens_em.yml | 2 +- contributed_definitions/nyaml/NXliquid_jet.yml | 2 +- contributed_definitions/nyaml/NXmanipulator.yml | 2 +- contributed_definitions/nyaml/NXmpes_liquid.yml | 2 +- contributed_definitions/nyaml/NXregistration.yml | 2 +- contributed_definitions/nyaml/NXspindispersion.yml | 2 +- contributed_definitions/nyaml/NXtransmission.yml | 2 +- 13 files changed, 13 insertions(+), 13 deletions(-) diff --git a/contributed_definitions/nyaml/NXcalibration.yml b/contributed_definitions/nyaml/NXcalibration.yml index d32250c66b..b0a4e31eb6 100644 --- a/contributed_definitions/nyaml/NXcalibration.yml +++ b/contributed_definitions/nyaml/NXcalibration.yml @@ -5,7 +5,7 @@ symbols: nfeat: "Number of features used to fit the calibration function" ncal: "Number of points of the calibrated and uncalibrated axes" doc: "Subclass of NXprocess to describe post-processing calibrations." -(NXcalibration): +NXcalibration: last_process(NX_CHAR): doc: "Indicates the name of the last operation applied in the NXprocess sequence." applied(NX_BOOLEAN): diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yml b/contributed_definitions/nyaml/NXcollectioncolumn.yml index 74f0016164..55a76cd957 100644 --- a/contributed_definitions/nyaml/NXcollectioncolumn.yml +++ b/contributed_definitions/nyaml/NXcollectioncolumn.yml @@ -1,7 +1,7 @@ category: base doc: "Subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser." -(NXcollectioncolumn): +NXcollectioncolumn: scheme(NX_CHAR): doc: "Scheme of the electron collection lens, i.e. standard, deflector, PEEM, diff --git a/contributed_definitions/nyaml/NXdeflector.yml b/contributed_definitions/nyaml/NXdeflector.yml index 3624d5c461..32c8e0ccce 100644 --- a/contributed_definitions/nyaml/NXdeflector.yml +++ b/contributed_definitions/nyaml/NXdeflector.yml @@ -1,6 +1,6 @@ category: base doc: "Deflectors as they are used e.g. in an electron analyser." -(NXdeflector): +NXdeflector: type: doc: "Qualitative type of deflector with respect to the number of pole pieces" enumeration: ["dipole", "quadrupole", "hexapole", "octupole"] diff --git a/contributed_definitions/nyaml/NXdistortion.yml b/contributed_definitions/nyaml/NXdistortion.yml index 873322a464..072e47e46a 100644 --- a/contributed_definitions/nyaml/NXdistortion.yml +++ b/contributed_definitions/nyaml/NXdistortion.yml @@ -5,7 +5,7 @@ symbols: ndx: "Number of points of the matrix distortion field (x direction)" ndy: "Number of points of the matrix distortion field (y direction)" doc: "Subclass of NXprocess to describe post-processing distortion correction." -(NXdistortion): +NXdistortion: last_process(NX_CHAR): doc: "Indicates the name of the last operation applied in the NXprocess sequence." applied(NX_BOOLEAN): diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yml b/contributed_definitions/nyaml/NXelectronanalyser.yml index 320880d9fd..11e8274857 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yml @@ -5,7 +5,7 @@ symbols: nfa: "Number of fast axes (axes acquired symultaneously, without scanning a pysical quantity)" nsa: "Number of slow axes (axes acquired scanning a pysical quantity)" -(NXelectronanalyser): +NXelectronanalyser: description(NX_CHAR): doc: "Free text description of the type of the detector " name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXenergydispersion.yml b/contributed_definitions/nyaml/NXenergydispersion.yml index 4bc9702509..784abbecbb 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yml +++ b/contributed_definitions/nyaml/NXenergydispersion.yml @@ -1,7 +1,7 @@ category: base doc: "Subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser." -(NXenergydispersion): +NXenergydispersion: scheme(NX_CHAR): doc: "Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, mirror, retarding grid, etc." diff --git a/contributed_definitions/nyaml/NXlens_em.yml b/contributed_definitions/nyaml/NXlens_em.yml index e0966c5ca5..682d36d7bf 100644 --- a/contributed_definitions/nyaml/NXlens_em.yml +++ b/contributed_definitions/nyaml/NXlens_em.yml @@ -9,7 +9,7 @@ doc: | reference. The origin should be specified in the NXtransformations. .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 -(NXlens_em): +NXlens_em: type: doc: "Qualitative type of lens with respect to the number of pole pieces" enumeration: ["single", "double", "quadrupole", "hexapole", "octupole"] diff --git a/contributed_definitions/nyaml/NXliquid_jet.yml b/contributed_definitions/nyaml/NXliquid_jet.yml index 3cbb8d7f5e..e24b8b9b00 100644 --- a/contributed_definitions/nyaml/NXliquid_jet.yml +++ b/contributed_definitions/nyaml/NXliquid_jet.yml @@ -1,7 +1,7 @@ category: base doc: | Description of a liquid jet -(NXliquid_jet): +NXliquid_jet: name(NX_CHAR): chemical_formula(NX_CHAR): preparation_data(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXmanipulator.yml b/contributed_definitions/nyaml/NXmanipulator.yml index fd74a10496..b54624b2d6 100644 --- a/contributed_definitions/nyaml/NXmanipulator.yml +++ b/contributed_definitions/nyaml/NXmanipulator.yml @@ -2,7 +2,7 @@ category: base doc: "Extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments." -(NXmanipulator): +NXmanipulator: name(NX_CHAR): doc: "Name of the manipulator." description(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXmpes_liquid.yml b/contributed_definitions/nyaml/NXmpes_liquid.yml index b8d8690b4b..2a0224d50e 100644 --- a/contributed_definitions/nyaml/NXmpes_liquid.yml +++ b/contributed_definitions/nyaml/NXmpes_liquid.yml @@ -5,7 +5,7 @@ doc: This is the application definition for multidimensional photoelectron spectroscopy on liquids category: application -(NXmpes): +NXmpes: (NXentry): title: start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXregistration.yml b/contributed_definitions/nyaml/NXregistration.yml index 3a3f889af7..39229b31a2 100644 --- a/contributed_definitions/nyaml/NXregistration.yml +++ b/contributed_definitions/nyaml/NXregistration.yml @@ -1,6 +1,6 @@ category: base doc: "Describes image registration procedures." -(NXregistration): +NXregistration: applied(NX_BOOLEAN): doc: "Has the registration been applied?" last_process(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXspindispersion.yml b/contributed_definitions/nyaml/NXspindispersion.yml index 05a9b6026f..7745255c78 100644 --- a/contributed_definitions/nyaml/NXspindispersion.yml +++ b/contributed_definitions/nyaml/NXspindispersion.yml @@ -2,7 +2,7 @@ category: base doc: "Subclass of NXelectronanalyser to describe the spin filters in photoemission experiments." -(NXspindispersion): +NXspindispersion: type(NX_CHAR): doc: "Type of spin detector, VLEED, SPLEED, Mott, etc. " figure_of_merit(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXtransmission.yml b/contributed_definitions/nyaml/NXtransmission.yml index 96d774cb2e..ce2c2fd0a0 100644 --- a/contributed_definitions/nyaml/NXtransmission.yml +++ b/contributed_definitions/nyaml/NXtransmission.yml @@ -8,7 +8,7 @@ symbols: N_wavelengths: Number of wavelength points N_scans: Number of scans -(NXtransmission): +NXtransmission: (NXentry): doc: | This application definition From 565e200900237c36a4f1b0bfc2d9b75acc2c35a4 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Wed, 8 Feb 2023 16:43:24 +0100 Subject: [PATCH 090/203] dir ND/condef/nyaml: Generating 'nxdl.xml' file from ''.yaml' or 'yml' file --- .../nyaml/NXaperture_em.nxdl.xml | 37 + contributed_definitions/nyaml/NXapm.nxdl.xml | 1354 +++++++++++++++++ .../nyaml/NXapm_input_ranging.nxdl.xml | 35 + .../nyaml/NXapm_input_reconstruction.nxdl.xml | 37 + .../NXapm_paraprobe_config_clusterer.nxdl.xml | 283 ++++ .../NXapm_paraprobe_config_distancer.nxdl.xml | 216 +++ ...Xapm_paraprobe_config_intersector.nxdl.xml | 387 +++++ .../NXapm_paraprobe_config_nanochem.nxdl.xml | 1005 ++++++++++++ .../NXapm_paraprobe_config_ranger.nxdl.xml | 248 +++ .../NXapm_paraprobe_config_spatstat.nxdl.xml | 284 ++++ .../NXapm_paraprobe_config_surfacer.nxdl.xml | 219 +++ ...Xapm_paraprobe_config_tessellator.nxdl.xml | 180 +++ ...NXapm_paraprobe_config_transcoder.nxdl.xml | 95 ++ .../NXapm_paraprobe_results_ranger.nxdl.xml | 290 ++++ ...Xapm_paraprobe_results_transcoder.nxdl.xml | 350 +++++ .../nyaml/NXatom_set.nxdl.xml | 17 + .../nyaml/NXcalibration.nxdl.xml | 90 ++ .../nyaml/NXcg_alpha_shape.nxdl.xml | 98 ++ .../nyaml/NXcg_cylinder_set.nxdl.xml | 132 ++ .../nyaml/NXcg_ellipsoid_set.nxdl.xml | 112 ++ .../NXcg_face_list_data_structure.nxdl.xml | 219 +++ .../nyaml/NXcg_geodesic_mesh.nxdl.xml | 35 + .../nyaml/NXcg_grid.nxdl.xml | 151 ++ .../NXcg_half_edge_data_structure.nxdl.xml | 147 ++ .../nyaml/NXcg_hexahedron_set.nxdl.xml | 207 +++ .../nyaml/NXcg_isocontour.nxdl.xml | 43 + .../nyaml/NXcg_marching_cubes.nxdl.xml | 50 + .../nyaml/NXcg_parallelogram_set.nxdl.xml | 156 ++ .../nyaml/NXcg_point_set.nxdl.xml | 77 + .../nyaml/NXcg_polygon_set.nxdl.xml | 135 ++ .../nyaml/NXcg_polyhedron_set.nxdl.xml | 150 ++ .../nyaml/NXcg_polyline_set.nxdl.xml | 153 ++ .../nyaml/NXcg_roi_set.nxdl.xml | 16 + .../nyaml/NXcg_sphere_set.nxdl.xml | 98 ++ .../nyaml/NXcg_tetrahedron_set.nxdl.xml | 132 ++ .../nyaml/NXcg_triangle_set.nxdl.xml | 107 ++ .../NXcg_triangulated_surface_mesh.nxdl.xml | 22 + .../nyaml/NXcg_unit_normal_set.nxdl.xml | 46 + .../nyaml/NXchamber.nxdl.xml | 19 + .../nyaml/NXclustering.nxdl.xml | 100 ++ .../nyaml/NXcollectioncolumn.nxdl.xml | 83 + .../nyaml/NXcoordinate_system_set.nxdl.xml | 62 + .../nyaml/NXcorrector_cs.nxdl.xml | 40 + .../nyaml/NXcs_computer.nxdl.xml | 57 + .../nyaml/NXcs_cpu.nxdl.xml | 18 + .../nyaml/NXcs_filter_boolean_mask.nxdl.xml | 83 + .../nyaml/NXcs_gpu.nxdl.xml | 18 + .../nyaml/NXcs_io_obj.nxdl.xml | 33 + .../nyaml/NXcs_io_sys.nxdl.xml | 13 + .../nyaml/NXcs_mm_sys.nxdl.xml | 17 + .../nyaml/NXcs_prng.nxdl.xml | 61 + .../nyaml/NXcs_profiling.nxdl.xml | 115 ++ .../nyaml/NXcs_profiling_event.nxdl.xml | 74 + .../nyaml/NXdeflector.nxdl.xml | 71 + .../nyaml/NXdelocalization.nxdl.xml | 109 ++ .../nyaml/NXdistortion.nxdl.xml | 90 ++ .../nyaml/NXebeam_column.nxdl.xml | 82 + .../nyaml/NXelectronanalyser.nxdl.xml | 136 ++ .../nyaml/NXellipsometry.nxdl.xml | 839 ++++++++++ contributed_definitions/nyaml/NXem.nxdl.xml | 1026 +++++++++++++ .../nyaml/NXenergydispersion.nxdl.xml | 69 + .../nyaml/NXevent_data_em.nxdl.xml | 221 +++ .../nyaml/NXevent_data_em_set.nxdl.xml | 11 + .../nyaml/NXfabrication.nxdl.xml | 29 + .../nyaml/NXgraph_edge_set.nxdl.xml | 92 ++ .../nyaml/NXgraph_node_set.nxdl.xml | 66 + .../nyaml/NXgraph_root.nxdl.xml | 14 + .../nyaml/NXibeam_column.nxdl.xml | 99 ++ .../nyaml/NXimage_set_em_adf.nxdl.xml | 135 ++ contributed_definitions/nyaml/NXion.nxdl.xml | 110 ++ .../nyaml/NXiv_temp.nxdl.xml | 63 + .../nyaml/NXlens_em.nxdl.xml | 88 ++ .../nyaml/NXliquid_jet.nxdl.xml | 48 + .../nyaml/NXmanipulator.nxdl.xml | 79 + .../nyaml/NXmatch_filter.nxdl.xml | 42 + contributed_definitions/nyaml/NXmpes.nxdl.xml | 331 ++++ .../nyaml/NXmpes_liquid.nxdl.xml | 392 +++++ .../nyaml/NXms_crystal_set.nxdl.xml | 123 ++ .../nyaml/NXms_dislocation_set.nxdl.xml | 83 + .../nyaml/NXms_interface_set.nxdl.xml | 90 ++ .../nyaml/NXms_snapshot.nxdl.xml | 32 + .../nyaml/NXms_snapshot_set.nxdl.xml | 35 + .../nyaml/NXoptical_system_em.nxdl.xml | 55 + .../nyaml/NXorientation_set.nxdl.xml | 94 ++ contributed_definitions/nyaml/NXpeak.nxdl.xml | 66 + contributed_definitions/nyaml/NXpid.nxdl.xml | 63 + .../nyaml/NXpulser_apm.nxdl.xml | 117 ++ contributed_definitions/nyaml/NXpump.nxdl.xml | 19 + .../nyaml/NXreflectron.nxdl.xml | 31 + .../nyaml/NXregistration.nxdl.xml | 34 + .../nyaml/NXscanbox_em.nxdl.xml | 20 + .../nyaml/NXsensor_scan.nxdl.xml | 176 +++ .../nyaml/NXslip_system_set.nxdl.xml | 56 + .../nyaml/NXspatial_filter.nxdl.xml | 60 + .../nyaml/NXspectrum_set_em_eels.nxdl.xml | 155 ++ .../nyaml/NXspectrum_set_em_xray.nxdl.xml | 269 ++++ .../nyaml/NXspindispersion.nxdl.xml | 76 + .../nyaml/NXstage_lab.nxdl.xml | 137 ++ .../nyaml/NXsubsampling_filter.nxdl.xml | 26 + .../nyaml/NXtransmission.nxdl.xml | 327 ++++ 100 files changed, 14592 insertions(+) create mode 100644 contributed_definitions/nyaml/NXaperture_em.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXatom_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcalibration.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_grid.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXchamber.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXclustering.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_cpu.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_gpu.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_prng.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_profiling.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXdeflector.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXdelocalization.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXdistortion.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXebeam_column.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXellipsometry.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXem.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXevent_data_em.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXfabrication.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXgraph_root.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXibeam_column.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXion.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXiv_temp.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXliquid_jet.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXmanipulator.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXmatch_filter.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXmpes.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXms_interface_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXms_snapshot.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXorientation_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXpeak.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXpid.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXpulser_apm.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXpump.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXreflectron.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXregistration.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXsensor_scan.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXslip_system_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXspatial_filter.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXspindispersion.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXstage_lab.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXtransmission.nxdl.xml diff --git a/contributed_definitions/nyaml/NXaperture_em.nxdl.xml b/contributed_definitions/nyaml/NXaperture_em.nxdl.xml new file mode 100644 index 0000000000..e07b704b13 --- /dev/null +++ b/contributed_definitions/nyaml/NXaperture_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Details of an individual aperture for beams in electron microscopy. + + + + Given name/alias of the aperture. + + + + + Relevant value from the control software. + + This is not always just the diameter of (not even in the case) + of a circular aperture. Usually it is a mode setting value which + is selected in the control software. + Which settings are behind the value should be defined + for now in the description field, if these are known + in more detail. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details. Alternatively a free-text field. + + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + diff --git a/contributed_definitions/nyaml/NXapm.nxdl.xml b/contributed_definitions/nyaml/NXapm.nxdl.xml new file mode 100644 index 0000000000..8ad9bf96c4 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm.nxdl.xml @@ -0,0 +1,1354 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). Needs + to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals mapped on this ion + type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Application definition for atom probe and field ion microscopy experiments. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + Commercial or otherwise given name to the program which was used + to create the original results file of the atom probe experiment. + This file and program should not be confused with downstream + processing operations and file format conversion tasks. + + Atom probe microscopy experiments are except for still very much cases + controlled via commercial software. Such software is designed as an + integrated acquisition and instrument control software. + + For AMETEK/Cameca local electrode atom probe (LEAP) instruments the + least processed (rawest) numerical results and metadata are stored + in so-called RHIT and HITS files, which are proprietary and the + specifications of which are not publicly documented. + + Supplementary metadata are kept in a database which is connected + to the instrument control software and synced with the experiment + while signal is being detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also to resolve isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + Therefore, this application definition documents not only the measurement + but also the key post-processing steps which transform the proprietary + data into a tomographic reconstruction with ranging definitions. + + Future guidance by the vendors could improve this description to cover + a substantial larger number of eventually metadata that so far + are not publicly documented and accessible in an open-source manner. + + + + Program 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. + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow to store the + entire set of such interrupted runs to be stored and covered. However, + this is not because of a technical limitation within NeXus but + because we have not seen a covering use case based on which we could + have implemented and conceptualized this. Atom probers are invited to + contact the respective people in the FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin from where the specimen was cut. + In cases where the specimen was e.g. site-specifically cut from + samples or in cases of an instrument session during which multiple + specimens are loaded, the name has to be descriptive enough to resolve + which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how specimens were + cut/prepared from samples in the sample history. This field must + not be used for an alias of the specimen. Instead, use short_title. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Possibility to give an abbreviation of the specimen name field. + + + + + Use Hill's system for listing elements of the periodic table which + are inside or attached to the surface of the specimen, and thus + relevant from a scientific point of view. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + A local electrode guiding the ion flight path. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + Given name/alias. + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + Name of the control software of the microscope + used during acquisition (e.g. IVAS/APSuite). + + + + Program 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. + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + + + + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + Hit multiplicity. + + + + + + + + Number of pulses since the start of the atom probe run/evaporation sequence. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + Bitmask which is set to true if the ion is considered and false otherwise. + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + Given name of the program that was used to perform this computation. + Similar comments as voltage_and_bowl_correction apply. + + + + Program 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. + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + A default three-dimensional histogram of the total number of ions in each bin. + + + + Array of counts for each bin. + + + + + + + + + + Bin positions along the z axis. + + + + + Bin positions along the y axis. + + + + + Bin positions along the x axis. + + + + + Naive point cloud density map. + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + Array of counts for each bin. + + + + + + + + End of value for each mass-to-charge-state ratio bin. + + + + + Mass-to-charge-state histogram. + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + Given name of the program that was used to perform this computation. + Apart from the classical approach to use AMETEK software for this + processing step, a number of open-source alternative tools exists. + + + + Program 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. + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml b/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml new file mode 100644 index 0000000000..5ccc9567c7 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml @@ -0,0 +1,35 @@ + + + + + Metadata to ranging definitions made for a dataset in atom probe microscopy. + + + + Name of (NeXus)/HDF5 file which stores ranging definitions which define + how mass-to-charge-state ratios map to iontypes and which iontypes are + distinguished. The UNKNOWNTYPE iontype (unranged) is the default iontype. + The ID of this special iontype is always reserved as 0. Each ion + is assigned to the UNKNOWNTYPE by default. Iontypes are assigned + by checking if the mass-to-charge-state ratio of an ion matches + to any of the defined mass-to-charge-state ratio intervals. + + + + Version identifier of the file (representing an at least SHA256) hash + which documents the binary state of the file to add an additional layer + of reproducibility for tracking provenance. + + + + + + Name of the group (prefix to the individual ranging definitions) + inside the HDF5 file which refers to the ranging definition to use. + A HDF5 file can store multiple ranging definitions. Using an ID is + the mechanism to distinguish which specific ranging (version) will + be processed. Reconstruction and ranging IDs can differ. + They specify different IDs. + + + diff --git a/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml new file mode 100644 index 0000000000..a1d33d25c9 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. + + + + Name of the (NeXus)/HDF5 file which stores reconstructed ion position + and mass-to-charge-state ratios. Such an HDF5 file can store multiple + reconstructions. Using an identifier (ID) is the mechanism which + paraprobe uses to distinguish which specific reconstruction will + be processed. With this design it is possible that the same HDF5 + file stores multiple versions of a reconstruction of e.g. the same + or different measured datasets, respectively. + + + + Version identifier of the file (representing an at least SHA256) hash + which documents the binary state of the file to add an additional layer + of reproducibility for tracking provenance. + + + + + + Name of the dataset inside the HDF5 file which refers to the + specific reconstructed ion positions to use for this analysis. + + + + + Name of the dataset inside the HDF5 file which refers to the + specific mass-to-charge-state ratios to use for this analysis. + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml new file mode 100644 index 0000000000..8f0db4b2c2 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -0,0 +1,283 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of position values. + + + + + Number of disjoint cluster. + + + + + Configuration of a paraprobe-clusterer tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many clustering processes should the tool execute. + + + + + This process maps results from cluster analyses performed with IVAS/APSuite + into an interoperable representation. Specifically in this process + paraprobe-clusterer takes results from clustering methods from other tools + of the APM community, like IVAS/APSuite. These results are usually reported + in two ways. Either as an explicit list of reconstructed ion positions. + In the case of IVAS these positions are reported through a text file + with a cluster label for each position. + + Alternatively, the list of positions is reported, as it is the case for + AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly + only in the following way: The mass-to-charge-state ratio column of a + what is effectively a file formatted like POS is used to assign a hypothetical + mass-to-charge value which resolves a floating point representation + of the cluster ID. + + Another case can occur where all disjoint floating point values, + i.e. here cluster labels, are reported and then a dictionary is created + how each value matches to a cluster ID. + + In general the cluster ID zero is reserved for marking the dataset + as to not be assigned to any cluster. Therefore, indices of disjoint + clusters start at 1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Name of HDF5 file which stores reconstructed ion positions. + This file should have been generated by from the community or vendor format. + This file not necessarily contains all the of the dataset because + spatial filters might have been applied in commercial software prior + to executing the cluster analysis so that e.g. only positions within a + ROI are reported by the commercial software. + POS files from IVAS have to be converted first. + + + + + Name of the dataset inside the HDF5 file ion_position_filename + which refers to the specific positions to use for this analysis. + The referred to dataset has to be formatted as an array of shape + (n_positions, 3). + + + + + Name of the HDF5 file which stores mass-to-charge-state-ratio values + (in the case of IVAS/APSuite) or other numbers which can be interpreted + as cluster labels. + + + + + Name of the dataset inside the HDF5 file cluster_indices_filename + which refers to the specifically encoded cluster indices. + The referred to dataset has to be formatted as an array of shape + (n_positions, 1). + + + + + The list of all keywords of a dictionary which maps implicit cluster + indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + + + + + + + + The list of all values of a dictionary which maps implicit cluster + indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + The sequences of mapping_dictionary_keyword and mapping_dictionary_value + have to match. + + + + + + + + Specifies if the tool should try to recover for each position the closest + matching position from dataset/dataset_name_reconstruction (within + floating point accuracy). This can be useful for instance when users + wish to recover the original evaporation ID which IVAS/AP Suite drops + for instance when writing their *.indexed.* cluster results files. + + + + + Specifies if the tool should try to recover, after a recovery of the + evaporation IDs a bitmask which identifies which of the positions + in dataset/dataset/dataset_name_reconstruction where covered + by the IVAS/APSuite cluster analysis. This can be useful to recover + the region of interest. + + + + + + This process performs a cluster analysis on a reconstructed dataset + or a portion of the reconstruction. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Name of the algorithm. + + + + + A text representation like a JSON/YAML dictionary with the + parameter of the clustering_algorithm. + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml new file mode 100644 index 0000000000..b653e4a285 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml @@ -0,0 +1,216 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration/settings of a paraprobe-distancer software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + How many individual analyses should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Compute for all filtered points, e.g. ions of the point set + the shortest Euclidean distance to the closest triangle of the + set of triangles. The triangles can formed a closed surface mesh. + Distances are not simple distances based on normal projections but + giving an exact solution. + + + + Paraprobe-distancer enables the computation of the Euclidean shortest + distance for each member of a set of points against a set of triangles. + In contrast to comparable methods used in atom probe the here computed + distance is not simply the projected distance to one of the triangles + but the more costly but robust computation of the distance between + a point and a triangle. + + The triangles can represent for instance the facets of a triangulated + surface mesh of a model for the edge of the dataset. Such a model can + be computed with paraprobe-surfacer. Alternatively, the triangles can + be those from the set of all facets for a set of convex hulls, alpha-shapes, + or alpha wrappings about three-dimensional objects like precipitates + (computed with e.g. paraprobe-nanochem). + + Currently, the tool does not check if the respectively specified + triangle sets are consistent, what their topology is, or whether or + not they are consistently oriented. + Each dataset that is referred to in the list_of _dataset_names_vertices + should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred + to in the list_of_dataset_names_facet_indices should be an + (Nfacets, 3) array of NX_UINT. + Facet indices refer to vertex indices. These need to start at zero + and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and vertices are indexed thus implicitly. + Facet normal vectors have to be also an array + of shape (Nfacets, 3) of NX_FLOAT. + + + + How many triangle sets to consider. + + + + + List of triangle sets. This design allows users to combine + multiple triangle sets. + + + + Name of the HDF5 file(s) which contain(s) vertex coordinates + and facet indices to describe the desired set of triangles. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility. + + + + + + Absolute HDF5 path to the dataset which + specifies the array of vertex positions. + + + + + Absolute HDF5 path to the dataset which + specifies the array of facet indices. + + + + + Absolute HDF5 path to the dataset which + specifies the array of facet normal vectors. + + + + + + + Specifies for which ions/points the tool will compute distances. + The purpose of this setting is to avoid unnecessary computations + when the user requests to only compute distances of ions within a + threshold distance to the triangle soup. + + By default the distances are computed for all ions; however + the setting skin enables to compute distances only for those + ions which are not farther away located to a triangle + than threshold_distance. + + + + + + + + + Maximum distance for which distances are computed when method is skin. + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml new file mode 100644 index 0000000000..3401650db5 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml @@ -0,0 +1,387 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many elements to use for computing a composition. + + + + + Configuration of a paraprobe-intersector tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + + + + + Specifies the method to use which decides if two objects intersect. + For reasons which are detailed in the supplementary material of + `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by + default assumes that two objects intersect if they share at least one + ion with the same evaporation ID + (shared_ion). Alternatively, with specifying tetrahedra_intersections, + the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks + for at least one pair of intersecting tetrahedra to identify if two objects + intersect or not. + + However, we found that these geometrical analyses can result in corner + cases which the currently used library (TetGen) was not unable to + tetrahedralize successfully. These cases were virtually always + associated with complicated non-convex polyhedra + which had portions of the mesh that were connected by almost point like + tubes of triangles. + + + + + + + + + Specifies if the tool should load the volume of each object + (if existent in the input file) to characterize the evolution of the + objects' volume as a function of set identifier (e.g. time). + + This and the has_object_composition option enables to activate + computations in the code which correlate the spatio-temporal tracking + with an object's properties. This is useful to explore/understand how + the object descriptor values evolve as a function of the parameterization + of the object. To arrive at a detailed understanding and quantification + of the differences of a given object as a function of delocalization and + e.g. iso-surfacing settings. + + The point made in M. Kühbach et al. 2022, is that this functionality + can be used to track for instance how the accumulated volume and + composition of an object depends on its segmentation via iso-surfaces. + The benefit of such computations is that users can inspect the + parameter sensitivity of an objects representation rigorously. + + + + + Specifies if the tool should load the composition of each object + (if existent in the input file) to characterize the evolution of the + object's composition as a function of set identifier. See the description + of has_object_volume for further details. In M. Kühbach et al. 2022, both + has_object options were used to characterize e.g. the parameter + sensitivity of computed composition, volume, and shape specifically, + for a carbide that was segmented via different carbon iso-composition + values. + + + + + List of np.uint16 elements, via their proton number. The whitelist is + evaluated to compute the composition of an object during tracking + when has_object_composition is set to true. + + + + + + + + For now a support field for the tool to identify how many individual + analyses the tool should execute as part of the analysis. + + + + + + For now a support field for the tool to identify how many individual + analyses (i. e. individual current_to_next mappings) the tool should + perform as part of the high-throughput analysis. + + + + + Tracking is the process of building logical relations between objects + based on proximity and mesh intersections. For each time step pairs + of sets are compared: members of a current_set and a next_set. + Members have to be objects and eventually can in addition be so-called + proxies. Objects and proxies are non-degenerated closed polyhedra which + are not necessarily convex. Proxies are doppelganger/replacement + meshes of objects which would otherwise be impossible to describe + with a closed mesh. + + + + Current set stores a set of object geometries that should be checked + for proximity and/or intersection with member of the next_set. + + + + This identifier can be used to label the current set. The label + effectively represents the time/iteration step when the current + set was taken. As it is detailed in M. Kühbach et al. 2022, + this identifier takes the role of the time variable k. + + + + + Name of the HDF5 file which contain geometry (vertex coordinates, + facet indices) and properties (ions, composition) of polyhedra + (l objects) which should be included in the current set. + The user has to ensure that the datasets under list_of_dataset_names + (vertices, facet_indices, ions) exist and are formatted consistently. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Paraprobe-intersector loads triangulated surface mesh data of a + set of objects. For each object its mesh is expected to have + three-dimensional position data of the unique vertices and a + matrix of vertex indices which describe the faces. + As each object has to be a polyhedron/closed surface mesh, this + matrix has as many rows as faces, i.e. triangles and three columns. + Vertex indices have to start at zero. + + + + + The default intersection detection method uses shared ions. + Therefore, it is necessary to specify where the results from the + paraprobe-nanochem tool run are located which document which ions + (with their evaporation IDs) are inside or on the surface of each + object. This field points the tool to these evaporation IDs. + + + + + In order to correlate object properties like volume and composition + with tracking data, it is necessary to specify where the results + (object properties) from the paraprobe-nanochem tool run are located. + This field instructs the tool where to load these object property data + from. + + + + + Paraprobe-intersector does not just compare two objects but a set + of sets of objects. This field instructs the tool where to load + the identifiers (names) of each object in a current_set or next_set + respectively from. + + + + + Like groupname_object_geometry_data but for the proxies. + Triangulated surface meshes of proxies have to be formatted + in the same manner as objects. + + + + + Like groupname_proxy_supplementary_data but for the interior proxies. + Leave an empty string if proxies should not be used. + + + + + Like groupname_proxy_supplementary_data but for the exterior proxies. + Leave an empty string if proxies should not be used. + + + + + + Next set stores a set of object geometries that should be checked + for proximity and/or intersection with (each) member(s) of the + current_set. + + + + This identifier can be used to label the next set. Like for the current_set + the identifier is effectively the time/iteration step when the next set was taken. + As it is detailed in M. Kühbach et al. 2022, this identifier + takes the role of the time variable k+1. + + + + + Name of the HDF5 file which contain geometry (vertex coordinates, + facet indices) and properties (ions, composition) of + polyhedra(l objects) which should be included in the current set. + The user has to ensure that the datasets that are referred to + under list_of_dataset_names (vertices, facet_indices, ions). + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Paraprobe-intersector loads triangulated surface mesh data of a + set of objects. For each object its mesh is expected to have + three-dimensional position data of the unique vertices and a + matrix of vertex indices which describe the faces. + As each object has to be a polyhedron/closed surface mesh + this matrix has as many rows as faces, i.e. triangles and + three columns. Vertex indices have to start at zero. + + + + + The default intersection detection method uses shared ions. + Therefore, it is necessary to specify where the results from the + paraprobe-nanochem tool run are located which document which ions + (with their identifiers) are inside or on the surface of each object. + This field instructs the tool where to load these + ion evaporation ids from. + + + + + In order to correlate object properties like volume and composition + with tracking data, it is necessary to specify where the results + (object properties) from the paraprobe-nanochem tool run are located. + This field instructs the tool where to load these object property + data from. + + + + + Paraprobe-intersector does not just compare two objects but a set + of sets of objects. This field instructs the tool where to load + the identifiers (names) of each object in a current or next set + respectively from. + + + + + Like groupname_object_geometry_data but for the proxies. + Triangulated surface meshes of proxies have to be formatted + in the same manner. Leave an empty string if proxies should not + be used. + + + + + Like groupname_proxy_supplementary_data but for the interior proxies. + Leave an empty string if proxies should not be used. + + + + + Like groupname_proxy_supplementary_data but for the exterior proxies. + Leave an empty string if proxies should not be used. + + + + + + Specifies if, in the case of small finite datasets, objects which are + located at the edge of the dataset should be accounted for or not. + If these so-called proxy/doppelganger objects are accounted for, the + respective groupname_proxy and dataset_proxy fields have to be + filled to tell the tool where to load which proxy meshes from. + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) intersect volumetrically. + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) lie closer to one another than the + threshold_proximity. + + + + + Specifies if the tool evaluates, ones all tracking tasks were + successfully completed, how intersecting or proximity related + objects build sub-graphs. This is the feature which enabled + M. Kühbach et al. 2022 the high-throughput analyses of how many + objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order. For these analyses to work + has_object_volume needs to be activated. + + + + + The maximum Euclidean distance between two objects below which + both objects are still considered within proximity. + + + + + Specifies if the tool stores the so-called forward relations between + nodes representing members of the current_set to nodes representing + members of the next_set. + + + + + Specifies if the tool stores the so-called backward relations between + nodes representing members of the next_set to nodes representing + members of the current_set. + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml new file mode 100644 index 0000000000..34f6168404 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -0,0 +1,1005 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many iontypes does the delocalization filter specify. + + + + + How many disjoint control points are defined. + + + + + How many iontypes does the interface meshing iontype filter specify. + + + + + How many DCOM iterations. + + + + + Maximum number of atoms per molecular ion. + + + + + Configuration of a paraprobe-nanochem tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + + + + + How many individual analyses should the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject a previously computed triangle soup or + triangulated surface mesh representing a model (of the surface) of + the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + + + + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the edge of the dataset. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + + + + + + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + For now a support field for the tool to identify how many individual + delocalization analyses for the above-mentioned dataset and supplementary + files are executed as part of the high-throughput analysis. + + + + + Discretization of the ion point cloud on a three-dimensional grid. + + + + Delocalization in the field of atom probe microscopy is the process + of discretizing a point cloud. By default the tool computes a full + kernel density estimation of decomposed ions to create one discretized + field for each element. + + Although, this uses an efficient multithreaded algorithm, + the computation is costly. Therefore, it can be advantageous for users + to load an already computed delocalization. This can be achieved with + the load_existent option. + When using this option the user is responsible to assure that the + settings which were used for computing this already existent delocalization + are specified in the same manner as they were. + + + + + + + + + Matrix of isotope vectors representing iontypes. + The filter specifies a matrix of isotope_vectors which is the most + general approach to define if and how many times an ion is counted. + Currently, paraprobe_nanochem performs a so-called atomic decomposition + of all iontypes. Specifically, the tool interprets of how many + elements/atoms a molecular ion is composed; and thus determines the + atoms multiplicity with respect to the iontype. + + Let's take the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore in an atomic + decomposition computation of the iso-surface each H3O+ ion adds + three hydrogen counts. This is a practical solution which accepts + the situation that during an atom probe experiment not each bond + of each ion/a group of neighboring atoms is broken but molecular + ions get detected. The exact ab-initio details depend on the local + field conditions and thus also the detailed spatial arrangement + of the atoms and their own electronic state and that of the neighbors + before and upon launch. + Being able to measure the information for such sites only as + molecular ions causes an inherent information loss with respect to the + detailed spatial arrangement. This information loss is more relevant + for local electrode atom probe than for field ion microscopy setting + how precisely the atomic positions can be reconstructed. + Accounting for multiplicities assures that at least the + compositional information is analyzed. + + + + + + + + + List of individual grid resolutions to analyse. + Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with + an edge length of values in gridresolutions. + + + + + Half the width of a (2n+1)^3 cubic kernel of voxel beyond + which the Gaussian Ansatz function will be truncated. + Intensity beyond the kernel is refactored into the kernel via + a normalization procedure. + + + + + Variance of the Gaussian Ansatz kernel sigma_x = sigma_y = 2*sigma_z. + + + + + How should the results of the kernel-density estimation be computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + + + + + + + + + + + Specifies if the tool should report the delocalization 3D field values. + + + + + Optional computation of iso-surfaces after each computed delocalization + to identify for instance objects in the microstructure + (line features, interfaces, precipitates). + + + + As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., + the handling of triangles at the edge of the dataset requires + special attention. Especially for composition-normalized + delocalization it is possible that the composition increases + towards the edge of the dataset because the quotient of two numbers + which are both smaller than one is larger instead of smaller than + the counter. By default, the tool uses a modified marching cubes + algorithm of Lewiner et al. which detects if voxels face such a + situation. In this case, no triangles are generated for such voxels. + Alternatively, (via setting keep_edge_triangles) the user can + instruct the tool to not remove these triangles at the cost of bias. + + Specifically, in this case the user should understand that all + objects/microstructural features in contact with the edge of the + dataset get usually artificial enlarged and their surface mesh + often closed during the marching. This closure however is artificial! + It can result in biased shape analyses for those objects. + The reason why this should in general be avoided is a similar + argument as when one analyzes grain shapes in orientation microscopy + via e.g. SEM/EBSD. Namely, these grains, here the objects at the + edge of the dataset, were not fully captured during e.g. limited + field of view. + Therefore, it is questionable if one would like to make + substantiated quantitative statements about them. + + Thanks to collaboration with the V. V. Rielli and S. Primig, though, + paraprobe-nanochem implements a complete pipeline to + process even these objects at the edge of the dataset. Specifically, + the objects are replaced by so-called proxies, i.e. replacement + objects whose holes on the surface mesh have been closed if possible + via iterative mesh and hole-filling procedures with fairing operations. + In the results of each paraprobe-nanochem run, these proxy objects + are listed separately to allow users to quantify and analyze in + detail the differences when accounting for these objects or not. + Especially this is relevant in atom probe microscopy are small + in the sense that they contain few (many a few dozen) objects. + Even though such a dataset may give statistically significant + results for compositions this does not mean it necessarily yields + also statistically significant and unbiased results for three-dimensional + object analyses. Being able to quantify these effects and making + atom probers aware of these subtleties was one of the main reasons + why the paraprobe-nanochem tool was implemented. + + + + + + + + + The ion-to-edge-distance that is used in the analyses of objects + (and proxies) to identify whether these are inside the dataset or + close to the edge of the dataset. If an object has at least one ion + with an ion-to-edge-distance below this threshold, the object is + considered as one which lies close to the edge of the dataset. + This implements essentially a distance-based approach to solve + the in general complicated and involved treatment of computing + volumetric intersections between not-necessarily convex + closed 2-manifolds. In fact, such computational geometry analyses + can face numerical robustness issues as a consequence of which a + mesh can be detected as lying completely inside a dataset although + in reality it is epsilon-close only, i.e. almost touching only + the edge (e.g. from inside). + Practically, humans would state in such case that the object is + close to the edge of the dataset; however mathematically the object + is indeed completely inside. + In short, a distance-based approach is rigorous and more flexible. + + + + + Array of iso-contour values. For each value the tool computes + an iso-surface and performs subsequent analyses. + The unit depends on the choice for the normalization of the + accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + + + + + Specifies if the tool should report the triangle soup which represents + each triangle of the iso-surface complex. + Each triangle is reported with an ID specifying to which triangle + cluster (with IDs starting at zero) the triangle belongs. + The clustering is performed with a modified DBScan algorithm. + + + + + Specifies if the tool should analyze for each cluster of triangles + how they can be combinatorially processed to describe a closed + polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In fact, inaccuracies in the + reconstructed positions cause inaccuracies in all downstream + processing operations. Especially the effect on one-dimensional + spatial statistics like nearest neighbor correlation functions these + effects were discussed in the literature + `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_ + In continuation of these thoughts this applies also to reconstructed + objects. A well-known example is the discussion of shape deviations + of Al3Sc precipitates in aluminium alloys which in reconstructions + can appear as ellipsoids although they should be almost spherical, + depending on their size. + + + + + Specifies if the tool should report a triangulated surface mesh + for each identified closed polyhedron. It is common that a + marching cubes algorithm creates iso-surfaces with a fraction of very + small sub-complexes (e.g. small isolated tetrahedra). + + These can be for instance be small tetrahedra/polyhedra about the + center of a voxel of the support grid on which marching cubes operates. + When these objects are small, it is possible that they contain no ion; + especially when considering that delocalization procedures smoothen + the positions of the ions. Although these small objects are interesting + from a numerical point of view, scientists may argue they are not worth + to be reported: + Physically a microstructural feature should contain at least a few + atoms to become relevant. Therefore, paraprobe-nanochem by default + does not report closed objects which bound not at least one ion. + + + + + Specifies if the tool should report properties of each closed + polyhedron, such as volume and other details. + + + + + Specifies if the tool should report for each closed polyhedron an + approximately optimal bounding box fitted to all triangles of the + surface mesh of the object and ion positions inside or on the + surface of the mesh. + This bounding box informs about the closed object's shape + (aspect ratios). + + + + + Specifies if the tool should report for each closed polyhedron + all evaporation IDs of those ions which lie inside or on the + boundary of the polyhedron. This information can be used e.g. + in the paraprobe-intersector tool to infer if two objects share + common ions, which can be interpreted as an argument to assume + that the two objects intersect. + + Users should be aware that two arbitrarily closed polyhedra + in three-dimensional space can intersect but not share a common ion. + In fact, the volume bounded by the polyhedron has sharp edges. + When taking two objects, an edge of one object may for instance + pierce into the surface of another object. In this case the + objects partially overlap / intersect volumetrically; + however this piercing might be so small or happening in the volume + between two ion positions and thus sharing ions is a sufficient + but not a necessary condition for object intersections. + + Paraprobe-intersector implements a rigorous alternative to handle + such intersections using a tetrahedralization of closed objects. + However, in many practical cases, we found through examples that there + are polyhedra (especially when they are non-convex and have almost + point-like) connected channels, where tetrahedralization libraries + have challenges dealing with. In this case checking intersections + via shared_ions is a more practical alternative. + + + + + Specifies if the tool should report if a (closed) object has + contact with the edge of the dataset. For this the tool currently + inspects if the shortest distance between the set of triangles of the + surface mesh and the triangles of the edge model is larger than the + edge_threshold. If this is the case, the object is assumed to be + deeply embedded in the interior of the dataset. Otherwise, the object + is considered to have an edge contact, i.e. it is likely affected + by the fact that the dataset is finite. + + + + + Specifies if the tool should analyze a doppelganger/proxy mesh for + each cluster of triangles whose combinatorial analysis according + to has_object showed that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, + and fairing operations. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In most cases objects, + like precipitates in atom probe end up as open objects because + they have been clipped by the edge of the dataset. Using a proxy is + then a strategy to still be able to account for these objects. + Nevertheless users should make themselves familiar with the + potential consequences and biases which this can introduce + into the analysis. + + + + + Like has_object_geometry but for the proxies. + + + + + Like has_object_properties but for the proxies. + + + + + Like has_object_obb but for the proxies. + + + + + Like has_object_ions but for the proxies. + + + + + Like has_object_edge_contact but for the proxies. + + + + + Specifies if the tool should report for each closed object a + (cylindrical) region of interest placed, centered, and align + with the local normal for each triangle of the object. + + + + + Specifies if the tool should report for each ROI that was placed + at a triangle of each object if this ROI intersects the edge of + the dataset. Currently paraprobe-nanochem supports cylindrical + ROIs. A possible intersection of these with the edge of the + dataset, i.e. the triangulated surface mesh model for the edge + is performed. This test checks if the cylinder intersects with + a triangle of the surface mesh. If this is the case, the ROI is + assumed to make edge contact, else, the ROI is assumed to have + no edge contact. + + This approach does not work if the ROI would be completely + outside the dataset. Also in this case there would be + no intersection. For atom probe this case is practically + irrelevant because for such a ROI there would also be no ion + laying inside the ROI. Clearly it has thus to be assumed that + the edge model culls the entire dataset. Instead, if one would + cut a portion of the dataset, compute an edge model for this + point cloud, it might make sense to place a ROI but in this + case the edge contact detection is not expected to work properly. + + + + + + Analyses of interfacial excess. + + + + Interfacial excess computations are performed for local regions-of-interests + (ROIs) at selected facets or interface patch. + For instance many scientist compute the interfacial excess for + selected triangle facets of a created iso-surface. In this case, + computed iso-surfaces of paraprobe could be used. An example are triangle + facet sets about closed polyhedra, for instance to compute interfacial + excess related to phase boundaries of second-phase precipitates. + + Another example are free-standing triangle patches of the iso- + surfaces which paraprobe creates. These could be characterized + for interfacial excess. The sub-routines during iso-surface + computations already include a procedure to automatically align + local triangle normals based on the gradients of e.g. composition + fields. In this case, these triangulated surface patches + could also be used as a source for computing interfacial + excess. + + Often scientists face situations, though, in which there is no + immediately evident composition gradient across the interface + (grain or phase boundary) and orientation information about the + adjoining crystal is neither available nor reliable enough. + + In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method + to manually place control points and run an automated tessellation-based + algorithm to create a triangulated surface patch, i.e. a model of the + location of the interface. In a post-processing step this triangle + set can then be used to compute again interfacial excess in an + automated manner by placing ROIs and aligning them with + consistently precomputed triangle normals. + + A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ + They used first a deep-learning method to locate planar triangulated + grain boundary patches. These are eventually processed further + with manual editing of the mesh via tools like Blender. + Once the user is satisfied with the mesh, the computations of interfacial + excess reduce again to an automated placing of ROIs, computations + of the distributing of ions to respective ROIs and + reporting the findings via plotting. + + Yet another approach for constructing an triangulated surface patch + of an interface is to use point cloud processing methods which have + been proposed in the laser-scanning, geoinformatics, and CAD community. + Different computational geometry methods are available for fitting + a parameterized surface to a set of points, using e.g. non-uniform + rational B-splines (NURBS) and triangulating these according + to prescribed mesh quality demands. + + The advantage of these methods is that they can be automated and + pick up curved interface segments. The disadvantage is their often + strong sensitivity to parameterization. As a result also such methods + can be post-processed to yield a triangulated surface patch, + and thus enable to run again automated ROI placement methods. + For example like these which were explored for the use case of + iso-surfaces with closed objects and free-standing + surface patches that delineate regions of the dataset with a + pronounced composition gradient normal to the interface. + + This summary of the situations which atom probers can face when + requesting for interfacial excess computations, substantiates there + exists a common set of settings which can describe all of these methods + and, specifically, as here exemplified, the automated placing + and alignment functionalities for ROIs that is an important + step all these workflows. + + Specifically, paraprobe-nanochem operates on an already existent + triangle set. + + + + + + + + + The interface model is the result of a previous (set of) processing + steps as a result of which the user has created a triangulated + surface mesh (or a set of, eventually connected such meshes). + These interface models are useful, if not required, in cases when + there is no other independent approach to locate an interface. + + These are cases when insufficient crystallographic latent + information is available and also no consistent concentration + gradient detectable across the interface. It is then the users' + responsibility to deliver a triangle mesh of the interface model. + + + + Filename to HDF5 file which contain vertex coordinates, facet indices, + facet unit normals. The user is responsible for the triangle + and winding order to be consistent. + Input is expected as a matrix of the coordinates for all disjoint + vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. + Input is expected to include also a matrix of facet indices + referring to these disjoint vertices. This matrix should be a + (Nfacets, 3)-shaped array of NX_UINT. Further required input + is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit + normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed + vertex unit normals. Vertex indices need to start at zero and + must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + Absolute HDF5 path to the dataset which specifies the + array of vertex positions. + + + + + Absolute HDF5 path to the dataset which specifies the + array of facet indices. + + + + + Absolute HDF5 path to the dataset which specifies the + array of facet signed unit normals. + + + + + Absolute HDF5 path to the dataset which specifies the + array of vertex signed unit normals. + + Users should be aware that triangulated surface meshes are + only approximations to a given complex, eventually curved shape. + Consequently, computations of normals show differences between + the vertex and facet normals. Vertex normals have to be + interpolated from normals of neighboring facets. Consequently, + these normals are affected by the underlying parameterization + and curvature estimation algorithms, irrespective of how + contributions from neighboring facets are weighted. By contrast, + facet normals are clearly defined by the associated triangle. + Their disadvantage is that they the normal field has discontinuities + at the edges. In general the coarser an object is triangulated + the more significant the difference becomes between computations + based on facet or vertex normals. + Paraprobe-nanochem works with facet normals as it can use + parts of the numerical performance gained by using cutting + edge libraries to work rather with finer meshes. + + + + + + + + Create a simple principle component analysis (PCA) to mesh a + free-standing interface patch through a point cloud of decorating solutes. + These models can be useful for quantification of Gibbsian + interfacial excess for interfaces where iso-surface based methods + may fail or closed objects from iso-surfaces are not desired or + when e.g. there are no substantial or consistently oriented + concentration gradients across the interface patch. + + The interface_meshing functionality of paraprobe-nanochem can be useful + when there is also insufficient latent crystallographic information + available that could otherwise support modelling the interface, + via e.g. ion density traces in field-desorption maps, as were used and + discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ + or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ + + It is noteworthy that the method here used is conceptually very similar + in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ + Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. + However, both of these previous works neither discuss in detail + nor implement inspection functionalities which enable a detection of + potential geometric inconsistencies or self-interactions of the + resulting DCOM mesh. This is what paraprobe-nanochem implements + via the Computational Geometry Algorithms Library. + + + + Method how to initialize the PCA: + + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. + + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ + to create a control_point_file which can be parsed by paraprobe-parmsetup + to match the here required formatting in control_points. + + + + + + + + + The name of the control point file to use. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + X, Y, Z coordinates of disjoint control point read from + an HDF5 file named according to control_point_file. + + + + + + + + + Method used for identifying and refining the location of the + interface. Currently, paraprobe-nanochem implements a PCA followed + by an iterative loop of isotropic mesh refinement and DCOM step(s), + paired with self-intersection detection in a more robust + implementation. + + + + + + + + Specify the types of those ions which decorate the interface and + can thus be assumed as markers for locating the interface and + refining its local curvature. + + + + Array of iontypes to filter. The list is interpreted as a whitelist, + i.e. ions of these types are considered the decorating species (solutes). + + + + + + + + + How many times should the DCOM and mesh refinement be applied? + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. + + + + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within + which the DCOM algorithm decides for each vertex how the vertex will + be eventually relocated. The larger the DCOM radius is relative to + the target_edge_length the more likely it is that vertices will be + relocated so substantially that eventually triangle self-intersections + can occur. + + + + + + + + Array of integers which specify for each DCOM step how many times + the mesh should be iteratively smoothened. + + Users should be aware the three array target_edge_length, + target_dcom_radius, and target_smoothing_step are interpreted in the + same sequence, i.e. the zeroth entry of each array specifies the + values to be used in the first DCOM iteration. The first entry of + each array those for the second DCOM iteration and so on and so forth. + + + + + + + + + Functionalities for placing regions-of-interest (ROIs) in the dataset + or at specific microstructural features to characterize composition + profiles and cumulated profiles for quantification of interfacial excess. + Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed + across the triangulated surface of a user-defined mesh. + ROIs are placed at the barycenter of the triangular facet. + + The tool can be instructed to orient the profile for each ROIs with + the positive normal of the triangle facet normals. Profiles are + computed for each ROI and facet triangle. The code will test which + ROIs are completely embedded in the dataset. + Specifically, in this test the tool evaluates if the ROI cuts at least + one triangle of the triangulated surface mesh of the edge of the dataset. + If this is the case the ROI will be considered close to the edge + (of the dataset) and not analyzed further; else the ROI will be + processed further. + Users should be aware that the latter intersection analysis is strictly + speaking not a volumetric intersection analysis as such one is much + more involved because the edge model can be a closed non-convex polyhedron + in which case one would have to test robustly if the cylinder piercing + or laying completely inside the polyhedron. For this the polyhedron has + to be tessellated into convex polyhedra as otherwise tests like the + Gilbert-Johnson-Keerthi algorithm would not be applicable. + + Specifically, the tool computes atomically decomposed profiles. + This means molecular ions are split into atoms/isotopes with respective + multiplicity. As an example an H3O+ molecular ion contains three + hydrogen and one oxygen atom respectively. The tool then evaluates + how many ions are located inside the ROI or on the surface of the + ROI respectively. All atom types and the unranged ions are distinguished. + As a result, the analyses yield for each ROI a set of sorted lists of + signed distance values. Currently, the distance is the projected + distance of the ion position to the barycenter of the triangle + and triangle plane. + + This will return a one-dimensional profile. Post-processing the set + of atom-type-specific profiles into cumulated profiles enable the + classical Krakauer/Seidman-style interfacial excess analyses. + Furthermore, the tool can be instructed to compute for each + (or a selected sub-set of facet) a set of differently oriented profiles. + + + + The feature mesh enables the injection of previously computed triangle + soup or mesh data. Such a mesh can be the model for a grain- or phase + boundary patch (from e.g. interface_meshing) jobs. + + + + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the feature. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details consistently oriented facet + normals of the facets. + + + + + + The tool enables to inject precomputed distance information for each + point which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains ion distances. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically contains + these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + Which type of distance should be reported for the profile. + + + + + + + + In which directions should the tool probe for each ROI. + + + + + + + + For each ROI, how high (projected on the cylinder axis) + should the cylindrical ROI be. + + + + + For each ROI, how wide (radius) should the cylindrical ROI be. + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml new file mode 100644 index 0000000000..84b97864e8 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml @@ -0,0 +1,248 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of isotopes to consider as building blocks for searching + molecular ions. + + + + + The number of compositions to consider for molecular ion search tasks. + + + + + Configuration of a paraprobe-ranger tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + How many task to perform? + + + + + + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. + + + + + How many molecular_ion_search processes should + the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A list of pairs of number of protons and either the value 0 (per row) + or the mass number for all those isotopes which are assumed present + in a virtual specimen. + The purpose of this field is to compute also composition-weighted + products to yield a simple estimation which could potentially help + scientists to judge if certain molecular ions are to be expected. + The corresponding setting store_composition_weighted_product should be + activated. + + + + + + + + + A list of pairs of number of protons and mass number for all isotopes + to consider that can be composed into (molecular) ions, during the + recursive molecular_ion_search. + + + + + + + + + The mass-to-charge-state ratio interval in which + all molecular ions are searched. + + + + + + + + The maximum charge that a molecular ion should have. + + + + + The maximum number of isotopes of which the molecular ion + should be composed. Currently this must not be larger than 32. + + Users should be warned that the larger the maximum_charge and + especially the larger the maximum_number_of_isotopes is chosen, + the eventually orders of magnitude more costly the search becomes. + + This is because paraprobe-ranger computes really all (at least) + theoretically possible combinations that would have likely a + mass-to-charge-state ratio in the specified mass_to_charge_interval. + It is the challenge in atom probe to judge which of these (molecular) + ions are feasible and also practically possible. This tool does not + answer this question. + + Namely, which specific molecular ion will evaporate, remain stable + during flight and becomes detected is a complicated and in many cases + not yet in detail understood phenomenon. The ab-initio conditions + before and during launch, the local environment, arrangement and field + as well as the flight phase in an evacuated but not analysis chamber + with a complex electrical field, eventual laser pulsing in place, + temperature and remaining atoms or molecules all can have an effect + which iontypes are really physically evaporating and detected. + + + + + Report the accumulated atomic mass from each isotope building the ion. + Accounts for each identified ion. + Relatistic effects are not accounted for. + + + + + Report the product of the natural abundances from each isotope building + the ion. Accounts for each identified ion. + + The value zero indicates it is not possible to build such molecular ion + from nuclids which are all observationally stable. + Very small values can give an idea/about how likely such a molecular ion + is expected to form assuming equal probabilities. + + However in atom probe experiments this product has to be modified + by the (spatially-correlated) local composition in the region from + which the ions launch because the formation of a molecular ion depends + as summarized under maximum_number_of_isotopes on the specific + quantum-mechanical configuration and field state upon launch + or/and (early state) of flight respectively. + We are aware that this modified product can have a substantially + different value than the natural_abundance_product. + + Natural abundancies folded with the estimated compositions of the + specimen can differ by orders of magnitude. + + + + + Report the charge state of the ions. + + + + + Report if identified ions should be characterized + wrt to their number of disjoint isotopes. + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml new file mode 100644 index 0000000000..c0a76168cf --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -0,0 +1,284 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of different sources iontypes to distinguish. + + + + + Number of different target iontypes to distinguish. + + + + + Configuration of a paraprobe-spatstat tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distances of each ion to a + representation of the edge of the dataset which can be used to + control and substantially reduce edge effects when computing spatial statistics. + + + + Name of an HDF5 file which contains ion-to-edge distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-edge distance values for each ion. + The shape of the distance values has to match the length + of the ion positions array in dataset/dataset_name_reconstruction + and dataset_name_mass_to_charge respectively. + + + + + + In addition to spatial filtering, and considering how far ions lie + to the edge of the dataset, it is possible to restrict the analyses + to a sub-set of ions within a distance not farther away to a feature than + a threshold value. + + + + Name of an HDF5 file which contains ion-to-feature distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-feature distance values for each ion. + + + + + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + + + + + + + + + + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + + + + + + + + + Specifies which spatial statistics to compute. + + + + Compute k-th nearest neighbour statistics. + + + + Order k. + + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml new file mode 100644 index 0000000000..7c3878ed78 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -0,0 +1,219 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of alpha values (and offset values) to probe. + + + + + Configuration of a paraprobe-surfacer tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + For now a support field for the tool to identify how many individual + analyses the tool should executed as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies the method that is used to preprocess the point cloud. + The main purpose of this setting is to specify whether the point + cloud should be segmented or not during the preprocessing + to identify which points are more likely lying close to the edge + of the point cloud. These points could be more relevant than the + interior points for certain alpha-shape constructions. + + By default no such filtering is used during pre-processing. + By contrast, the option kuehbach activates a preprocessing + during which a Hoshen-Kopelman percolation analysis is used + to identify which points are closer to the edge of the dataset. + This can reduce the number of points in the alpha-shape + computation and thus improve performance substantially. + Details about the methods are reported in + `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. + + + + + + + + + When using the kuehbach preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. + + + + + Specifies which method to use to define the alpha value. + By default, the tool uses a fast specialized algorithm for + computing only the convex hull. + + The value smallest_solid instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value cgal_optimal instructs the library to choose a value + which the library considers as an optimal value. Details are + define in the respective section of the CGAL library on 3D alpha + shapes. + + The value set_of_values instructs to compute a list of + alpha-shapes for the specified alpha-values. + + The value set_of_alpha_wrappings instructs the library to generate + a set of so-called alpha wrappings. These are a method + which is similar to alpha shapes but provide additional guarantees + though such as watertightness and proximity constraints on the + resulting wrapping. + + + + + + + + + + + + Array of alpha values to use when alpha_value_choice is set_of_values + or when alpha_value_choice is set_of_alpha_wrappings. + + + + + + + + Array of offset values to use when alpha_value_choice is + set_of_alpha_wrappings. The array of alpha_values and offset_values + define a sequence of (alpha and offset value). + + + + + + + + Specifies if the tool should compute the set of exterior triangle + facets for each alpha complex (for convex hull, alpha shapes, and wrappings) + + + + + Specifies if the tool should check if the alpha complex of exterior + triangular facets is a closed polyhedron. + + + + + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml new file mode 100644 index 0000000000..9a62f065fb --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -0,0 +1,180 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration of a paraprobe-tessellator tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many individual analyses should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distance information for + each point which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + Users are responsible this file and referred to dataset under + dataset_name have an ion_distance value for each ion. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional layer of + reproducibility. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + + Specifies for which points the tool will compute the tessellation. + By default, a Voronoi tessellation is computed for all ions in the + filtered point cloud. + + + + + + + + Specifies if the tool should report the volume of each cell. + + + + + Specifies if the tool should report the first-order neighbors of each cell. + + + + + Specifies if the tool should report the facets and vertices of each cell. + + + + + Specifies if the tool should report if the cell makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + by the presence of the boundary. + + + + + Maximum distance for which cells are eroded. + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml new file mode 100644 index 0000000000..eb52a23f27 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configurations of a paraprobe-transcoder tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + + + The absolute path and name of the vendor or community file from which + to read the reconstructed ion positions. Currently POS, ePOS, and APT + files from APSuite are supported. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + + + The absolute path and name of the vendor or community file from which + to read the ranging definitions, i.e. how to map mass-to-charge-state + ratios on iontypes. Currently RRNG and RNG files are supported. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml new file mode 100644 index 0000000000..adfe091c0f --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml @@ -0,0 +1,290 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The maximum number of atoms per molecular ion type. + + + + + Results of a paraprobe-ranger tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which used. + fields should be prefixed with a prefix taken from an + enumeration which details the individual coordinate systems: + + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on none, the + ion is considered of the default unknown type with a 0 as its + respective value in the iontypes array. + + + + + + + + + + The iontype ID for each ion that was best matching, stored in the + order of the evaporation sequence ID. + + + + + + + + + Paraprobe-ranger performs a combinatorial search over + all possible or a reduced set of nuclids to identify + into which ions these can be composed. + + + + The main result is the list of molecular ions, here formatted + according to the definitions of a set of isotope_vectors + as detailed in :ref:`NXion`. + + + + + + + + + The mass-to-charge-state ratio of each molecular ion + without considering relativistic or quantum effects. + + + + + + + + The mass of each molecular ion without + considering relativistic or quantum effects. + + + + + + + + The charge_state of each molecular ion. + + + + + + + + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + + + + + + + + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + + + + + + + + The number of disjoint nuclids for each molecular ion. + + + + + + + + The number of nuclids for each molecular ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml new file mode 100644 index 0000000000..e66cdeb45f --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -0,0 +1,350 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). Needs + to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals mapped on this ion + type. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Results of a paraprobe-transcoder tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + + + + + + + + + On a mid term perspective we would like to evolve the paraprobe-toolbox + to an implementation stage where it works exclusively with completely + provenance-tracked formats for both the configuration of the workflow step + and/or analysis with each tool and also for the output of these analyses + in the form of so-called tool-specific results files. + Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. + + Different file formats can be used to inject reconstructed datasets and + ranging definitions into the toolbox. Traditionally, these are the POS, + ePOS, and APT files with the tomographic reconstruction and other metadata + and RNG and RRNG file formats for the ranging definitions how mass-to-charge + state-ratio values map on (molecular) ion types. Such input should be + injected via specific NeXus/HDF5 files which are documented + in compliance with the NXapm application definition. + + So far the paraprobe-toolbox was used as a standalone tool. Therefore, it + was not relevant during the development to focus on interoperability. + Essentially paraprobe-transcoder was used as a parser to transcode data + in the above-mentioned file formats into a paraprobe-specific + representation. This transcoding should become deprecated. + Here we describe steps we have taken into this direction. + + With the work in the FAIRmat project and the desire to make the paraprobe- + toolbox also accessible as a cloud-computing capable service in the Nomad + Remote Tools Hub (NORTH) the topic of interoperability became more important + and eventually the NXapm application definition was proposed. + NORTH is a GUI and related service in a NOMAD OASIS instance which allows + to spawn preconfigured docker containers via JupyterHub. + Currently, NORTH includes the so-called apm container. A container with + tools specific for analyzing data from atom probe microscopy as well as + processing of point cloud and mesh data. + + The NXapm application definition and related implementation work within + NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and + RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook + solutions directly into NOMAD OASIS via the uploads section. + The process is automated and yields an NXapm-compliant NeXus/HDF5 file + inside the uploads section in return. + + With these improvements made there is no longer a need for - at least the + users of a NOMAD OASIS and NORTH instance to use the deprecated + PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should + automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 + file and in response work with this file directly. + To remain compliant with users however who do not have or do not wish + to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is + as follows: + + Calling the configuration stage of paraprobe-transcoder is always mandatory. + It is always the first step of working with the toolbox. In this process + the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ + HDF5 file from e.g. the upload section, or such a file that was obtained from + a colleague with a NOMAD OASIS instance. + In all other cases, users can pass the reconstruction and ranging definitions + using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. + + Based on which input the user delivers, the parmsetup-transcoder tool then + creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and + informs the user whether the input was NeXus (and thus if all relevant + input is already available) or whether the paraprobe-transcoder tool needs + to be executed to convert the content of the vendor files first into a + format which paraprobe can provenance track and understand. + In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is + used to communicate to all subsequently used tools from which files + the tools can expect to find the reconstruction and ranging definitions. + + All subsequent analysis steps start also with a tool-specific configuration. + This configuration step reads in (among others) the + PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration + tool identifies automatically whether to read the reconstruction and ranging data + from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant + NeXus/HDF5 file that was created upon preparing the upload or the file shared + from a colleague. This design removes the need for unnecessary copies of the data. + Currently still though users should execute the transcoder step as it will + generate a supplementary XDMF topology field with which the data in either + the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. + Paraview. For this purpose XDMF is used. + + Of course ideally the APT community would at some point converge to use + a common data exchange file format. To this end, AMETEK/Cameca's APT file format + could be a good starting point but so far it is lacking a consistent way of + how to store generalized ranging definitions and post-processing results. + POS, ePOS, Rouen's ATO, as well as other so far used representations of data + like CSV or text files have, to the best of our current knowledge, no + concept of how to marry reconstruction and (optional) ranging data into + one self-descriptive format. + + This summarizes the rationale behind the current choices of the I/O for + paraprobe. Furthermore, this summarizes also why the fundamental design + of splitting an analysis always into steps of configuration (with parmsetup), + task execution (with the respective C/C++ or Python tool of the toolbox), + and post-processing (e.g. with autoreporter) is useful because it offers + a clear description of provenance tracking. This is a necessary step to make + atom probe microscopy data at all better aligned with the aims of the + FAIR principles. + + The internal organization of the data entries in the atom_probe group + in this application definition for paraprobe-transcoder results files + mirror the definitions of the NXapm for consistency reasons. + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXatom_set.nxdl.xml b/contributed_definitions/nyaml/NXatom_set.nxdl.xml new file mode 100644 index 0000000000..5d0997de0b --- /dev/null +++ b/contributed_definitions/nyaml/NXatom_set.nxdl.xml @@ -0,0 +1,17 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A base class to wrap details about a spatial configuration of atoms. + + + + Atom positions. + + + diff --git a/contributed_definitions/nyaml/NXcalibration.nxdl.xml b/contributed_definitions/nyaml/NXcalibration.nxdl.xml new file mode 100644 index 0000000000..16e54bd054 --- /dev/null +++ b/contributed_definitions/nyaml/NXcalibration.nxdl.xml @@ -0,0 +1,90 @@ + + + + + + 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/nyaml/NXcg_alpha_shape.nxdl.xml b/contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml new file mode 100644 index 0000000000..82271950d3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the alpha shape, for now 2 or 3. + + + + + The number of edges. + + + + + The number of faces. + + + + + The number of cells. + + + + + Computational geometry description of alpha shapes or wrappings to primitives. + + For details see: + + * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, + * https://dx.doi.org/10.1145/174462.156635 for 3D, + * https://dl.acm.org/doi/10.5555/871114 for weighted, and + * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap + + in CGAL, the Computational Geometry Algorithms Library. + As a starting point, we follow the conventions of the CGAL library. + + + + + + + + + + Specify which general type of alpha shape is computed. + Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. + Alpha_wrapping means meshes created using alpha wrapping procedures. + + + + + + + + + Specifically when computed with the CGAL, the mode specifies if singular + faces are removed (regularized) of the alpha complex. + + + + + + + + + The alpha, (radius of the alpha-sphere) parameter to be used for alpha + shapes and alpha wrappings. + + + + + The offset distance parameter to be used in addition to alpha + in the case of alpha_wrapping. + + + + + Point cloud for which the alpha shape or wrapping should be computed. + + + + + Triangle soup for which the alpha wrapping should be computed. + + + + + A meshed representation of the resulting shape. + + + + diff --git a/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml new file mode 100644 index 0000000000..d1628ba45c --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of cylinders or cones. + + + + + Computational geometry description of a set of cylinders in Euclidean space. + + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish members for explicit indexing. + + + + + + + + The geometric center of each member. + + + + + + + + + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. + + + + + + + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Interior volume of each cylinder + + + + + + + + Lateral surface area + + + + + + + + Area of the upper and the lower cap of each cylinder respectively. + + + + + + + + + Cap and lateral surface area for each cylinder. + + + + + + diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml new file mode 100644 index 0000000000..34fb36bcb2 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml @@ -0,0 +1,112 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or + ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 0000000000..abe8d791e7 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,219 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml new file mode 100644 index 0000000000..67c969d3e0 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml @@ -0,0 +1,35 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computational geometry description of a geodesic mesh. + + People from geodesic/surveyors will likely have specific demands and + different views about what should be included in such a base class, given + that nested geodesic meshes are a key component of climate modelling tools. + For now we propose to use this base class as a container to organize metadata + and data related to geodesic meshes. + + Specifically an instance of this base class should detail the rule set how + how the geodesic (surface) mesh was instantiated as there are many + possibilities. A geodesic surface mesh is in this sense a triangulated + surface mesh with metadata. For additional details as an introduction + into the topic see e.g.: + + * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ + + Here, especially the section on subdivision schemes is relevant. + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + diff --git a/contributed_definitions/nyaml/NXcg_grid.nxdl.xml b/contributed_definitions/nyaml/NXcg_grid.nxdl.xml new file mode 100644 index 0000000000..92e86a4abe --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_grid.nxdl.xml @@ -0,0 +1,151 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the grid. + + + + + The cardinality or total number of cells/grid points. + + + + + Number of boundaries of the bounding box or primitive to the grid. + + + + + Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. + + Frequently convenient three-dimensional grids with cubic cells are used. + Exemplar applications are spectral-solver based crystal plasticity + and stencil methods like phase-field or cellular automata. + + + + + + + + + + + + + + + + + The symmetry of the lattice defining the shape of the unit cell. + + + + + + + + The unit cell dimensions using crystallographic notation. + + + + + + + + Number of unit cells along each of the d unit vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for cells. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish cells for explicit indexing. + + + + + + + + Position of each cell in Euclidean space. + + + + + + + + + Coordinate of each cell with respect to the discrete grid. + + + + + + + + + A tight bounding box or sphere or bounding primitive about the grid. + + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml new file mode 100644 index 0000000000..fe3a1bc18e --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml @@ -0,0 +1,147 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of faces. + + + + + The number of half-edges. + + + + + Computational geeometry description of a half-edge data structure. + + Such a data structure can be used to efficiently circulate around faces + and iterate over vertices of a planar graph. + + + + + + + + In this half-edge data structure vertex identifiers start at 1. + Vertices are identified with consecutive integers up to number_of_vertices. + This field can be used to document which constant integer has to be + added to another set of vertex_identifier to assure that these other + identifiers also start at 1. + + + + + In this half-edge data structure face identifiers start at 1. + Faces are identified with consecutive integers up to number_of_faces. + This field can be used to document which constant integer has to be + added to another set of face_identifier to assure that these other + identifiers also start at 1. + + The face identifier zero is reserved for the NULL face ! + + + + + In this half-edge data structure half-edge identifiers start at 1. + Half-edges are identified with consecutive integers up to number_of_half_edges. + This field can be used to document which constant integer has to be + added to another set of half_edge_identifier to assure that these other + identifiers also start at 1. + + + + + The position of the vertices. + + + + + + + + + Identifier of the incident half-edge. + + + + + + + + Identifier of the (starting)/associated half-edge of the face. + + + + + + + + The identifier of the vertex from which this half-edge is outwards pointing. + + + + + + + + Identifier of the associated oppositely pointing half-edge. + + + + + + + + If the half-edge is a boundary half-edge the + incident face identifier is NULL, i.e. 0. + + + + + + + + Identifier of the next half-edge. + + + + + + + + Identifier of the previous half-edge. + + + + + + + + Users are referred to the literature for the background of L. Weinberg's + work about topological characterization of planar graphs: + + * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ + * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ + * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ + + and how this work can e.g. be applied in space-filling tessellations + of microstructural objects like crystals/grains. + + + diff --git a/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 0000000000..887c34fbdc --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,207 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml b/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml new file mode 100644 index 0000000000..b11f04e6e9 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml @@ -0,0 +1,43 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the description. + + + + + Computational geometry description of isocontouring/phase-fields in Euclidean space. + + Iso-contouring algorithms such as MarchingCubes and others are frequently + used to segment d-dimensional regions into regions where intensities are + lower or higher than a threshold value, the so-called isovalue. + + Frequently in computational materials science phase-field methods are + used which generate data on discretized grids. Isocontour algorithms + are often used in such context to pinpoint the locations of microstructural + features from this implicit phase-field-variable-based description. + + One of the key intentions of this base class is to provide a starting point + for scientists from the phase-field community (condensed matter physicists, + and materials engineers) to incentivize that also phase-field simulation + data could be described with NeXus, provided base classes such as the this one + get further extend according to the liking of the phase-field community. + + + + + The discretized grid on which the iso-contour algorithm operates. + + + + + The threshold or iso-contour value. + + + diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml new file mode 100644 index 0000000000..09037986a5 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml @@ -0,0 +1,50 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computational geometry description of the marching cubes algorithm. + + Documenting which specific version was used can help to understand how robust + the results are with respect to the topology of the triangulation. + + + + Reference/link to and/or details of the grid on which a specific + marching cubes algorithm implementation is operating. + + + + + Reference to the specific implementation of marching cubes used. + + See for example the following papers for details about how to identify a + DOI which specifies the implementation used: + + * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ + * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ + + The value placed here should be a DOI. If there are no specific DOI or + details write not_further_specified, or give at least a free-text + description. + + + + + Commercial or otherwise given name to the program which was used. + + + + Program 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. + + + + diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 0000000000..9f6bc830e1 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,156 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + Disentangled representations of the mesh of specific parallelograms. + + + diff --git a/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml new file mode 100644 index 0000000000..889c296035 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml @@ -0,0 +1,77 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml new file mode 100644 index 0000000000..e84ad842f6 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,135 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + The total number of vertices when visiting every polygon. + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 0000000000..ded991b30c --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,150 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml new file mode 100644 index 0000000000..e8f67207a4 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml @@ -0,0 +1,153 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of polylines. + + + + + The number of vertices, supporting the polylines. + + + + + The total number of vertices traversed when visiting every polyline. + + + + + Computational geometry description of a set of polylines in Euclidean space. + + Each polyline is built from a sequence of vertices (points with identifiers). + Each polyline must have a start and an end point. + The sequence describes the positive traversal along the polyline when walking + from the start vertex to the end/last vertex. + + + + + + The total number of vertices, irrespective of their eventual uniqueness, + i.e. the total number of vertices that have to be visited when walking + along each polyline. + + + + + Array which specifies of how many vertices each polyline is built. + The number of vertices represent the total number of vertices for + each polyline, irrespectively whether vertices are shared or not. + See the docstring for polylines for further details about how + a set with different polyline members should be stored. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and polyline data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + polylines. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polylines for explicit indexing. + + + + + + + + Positions of the vertices which support the members of the polyline set. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + If true indicates that the vertices are all placed at different + positions and have different identifiers, i.e. no points overlap + or are counted twice. + + + + + Sequence of vertex identifiers which describe each polyline. + + A trivial example is a set with two polylines with three vertices each. + If the polylines meet in a junction, say the second vertex is shared + and marking the junction between the two polylines, it is possible that + there are only five unique positions suggesting five unique vertices. + + A non-trivial example is a set with several polylines, each of which with + eventually different number of vertices. The array stores the vertex + identifiers in the order how the polylines are visited: + + The first entry is the identifier of the start vertex of the first polyline, + followed by the second vertex of the first polyline, until the last vertex + of the polyline. Thereafter, the start vertex of the second polyline, and + so on and so forth. Using the (cumulated) counts in number_of_vertices, + the vertices of the n-th polyline can be accessed on the following + array index interval: + :math:`$[\sum_i = 0}^{i = N-1}, \sum_{i=0}^{i=N}]$`. + + + + + + + + The length of each polyline. + + + + + + + + If true specifies that a polyline is closed, i.e. + its end point is connected to the start point. + + + + + + + + diff --git a/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml new file mode 100644 index 0000000000..246bfbcc6d --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml @@ -0,0 +1,16 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class to hold geometric primitives. + + + + + + diff --git a/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml new file mode 100644 index 0000000000..c267c04dd6 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 0000000000..40a555b63d --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml new file mode 100644 index 0000000000..cbbdf3e1c8 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,107 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml new file mode 100644 index 0000000000..8b38e0736d --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml @@ -0,0 +1,22 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computational geometry description of a mesh of triangles. + + The mesh may be self-intersecting and have holes but the + triangles must not be degenerated. + + + + + A graph-based approach to describe the mesh when it is also desired + to perform topological processing or analyses on the mesh. + + + diff --git a/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml new file mode 100644 index 0000000000..278021f38c --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml @@ -0,0 +1,46 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of unit normals. + + + + + Computational geometry description of a set of (oriented) unit normal vectors. + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + diff --git a/contributed_definitions/nyaml/NXchamber.nxdl.xml b/contributed_definitions/nyaml/NXchamber.nxdl.xml new file mode 100644 index 0000000000..f146141a4e --- /dev/null +++ b/contributed_definitions/nyaml/NXchamber.nxdl.xml @@ -0,0 +1,19 @@ + + + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + + diff --git a/contributed_definitions/nyaml/NXclustering.nxdl.xml b/contributed_definitions/nyaml/NXclustering.nxdl.xml new file mode 100644 index 0000000000..475b21e477 --- /dev/null +++ b/contributed_definitions/nyaml/NXclustering.nxdl.xml @@ -0,0 +1,100 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of numeral labels per object. + + + + + Number of categorical labels per object. + + + + + Total number of clusters detected. + + + + + Metadata to the results of a clustering analysis. + + Clustering algorithms are routine tools to segment a set of objects/primitives + into groups, objects of different type. A plethora of algorithms have been + proposed for geometric primitives as objects, such as points, triangles, + or (abstract) objects. + + This base class considers metadata and results of one clustering + applied to a set in which objects are either categorized as noise + or belonging to a cluster, specifically here only one cluster. + + + + How many numeric labels does each object have. + + + + + How many categorical labels does each object have. + + + + + Reference to a set of objects investigated in a cluster analysis. + Objects must have clear integer identifier. + + + + + Reference to numeric attribute data for each object. + + + + + Reference to categorical attribute data for each object. + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + + + + + Total number of objects categorized as unassigned. + + + + + Total number of objects categorized as noise. + + + + + Total number of clusters (excluding noise and unassigned). + + + + + Number of objects associated to each cluster. The labels are implicit, + meaning the zeroth/first entry in the array belongs to the first cluster, + the second entry to the second cluster and so on and so forth. + The first cluster has the value of identifier_offset as its identifier. + The second cluster has identifier_offset + 1, and so on and so forth. + + + + + + diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml b/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml new file mode 100644 index 0000000000..13e0d213f3 --- /dev/null +++ b/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml @@ -0,0 +1,83 @@ + + + + + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. + + + + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + + + + + Voltage applied to the extractor lens + + + + + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + + + + + Distance between sample and detector entrance + + + + + Labelling of the lens setting in use. + + + + + The space projected in the angularly dispersive directions, real or reciprocal + + + + + + + + + The magnification of the electron lens assembly. + + + + + Specifies the position of the collectioncolumn 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 + 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. + + + + + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + + + + + Deflectors in the collection column section + + + + + Individual lenses in the collection column section + + + diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml new file mode 100644 index 0000000000..3e1d15e101 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml @@ -0,0 +1,62 @@ + + + + + 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/nyaml/NXcorrector_cs.nxdl.xml b/contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml new file mode 100644 index 0000000000..8b6516486a --- /dev/null +++ b/contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml @@ -0,0 +1,40 @@ + + + + + Corrector for aberrations in an electron microscope. + + Different vendors use a different naming schemes for aberration coefficients. + It is the users responsibility to map to the best matching values. + + In transmission electron microscopes the spherical aberration corrector is + a component that is controlled via instructing the microscope to achieve + set point values. The corrector is composed of multiple lenses and other + parts with vendor-specific details which are often undisclosed. + + In the case of Nion Co. microscopes the coefficients of the corrector can be + retrieved via NionSwift, which is why currently the Nion convention for the + aberration coefficients is used. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + diff --git a/contributed_definitions/nyaml/NXcs_computer.nxdl.xml b/contributed_definitions/nyaml/NXcs_computer.nxdl.xml new file mode 100644 index 0000000000..eb94e16498 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_computer.nxdl.xml @@ -0,0 +1,57 @@ + + + + + + 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/nyaml/NXcs_cpu.nxdl.xml b/contributed_definitions/nyaml/NXcs_cpu.nxdl.xml new file mode 100644 index 0000000000..33045fdc71 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_cpu.nxdl.xml @@ -0,0 +1,18 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a central processing unit (CPU) of a computer. + + + + Given name of the CPU. Users should be as specific as possible. + + + + diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml new file mode 100644 index 0000000000..fd360d2982 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml @@ -0,0 +1,83 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries (e.g. number of points or objects). + + + + + Number of bits assumed for the container datatype used. + + + + + Length of mask considering the eventual need for padding. + + + + + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. + + + + Number of objects represented by the mask. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + + + + + + + + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + + + + + + diff --git a/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml b/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml new file mode 100644 index 0000000000..178671d13a --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml @@ -0,0 +1,18 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a graphic processing unit (GPU) of a computer. + + + + Given name of the GPU. Users should be as specific as possible. + + + + diff --git a/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml b/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml new file mode 100644 index 0000000000..90fe381cce --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a storage object in an input/output system. + + + + Qualifier for the type of storage medium used. + + + + + + + + + + Total amount of data which the medium can hold. + + + + + Given name to the I/O unit. + + + + diff --git a/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml b/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml new file mode 100644 index 0000000000..4a06897cdd --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml @@ -0,0 +1,13 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of system of a computer. + + + diff --git a/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml b/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml new file mode 100644 index 0000000000..45d07c2e98 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml @@ -0,0 +1,17 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a main memory system of a computer. + + + + How much physical memory does the system provide. + + + diff --git a/contributed_definitions/nyaml/NXcs_prng.nxdl.xml b/contributed_definitions/nyaml/NXcs_prng.nxdl.xml new file mode 100644 index 0000000000..72ab372fa1 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_prng.nxdl.xml @@ -0,0 +1,61 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). + + + + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + + + + + + + + + + + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + + + + Version and build number, or commit hash. + + + + + + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + + + + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + + diff --git a/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml b/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml new file mode 100644 index 0000000000..8877494263 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml @@ -0,0 +1,115 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description for summary performance/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 + contributions to performance: + + * Hardware capabilities and configuration + * 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. + + 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. + + 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 + 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. + + This base class cannot and should not replace these specific solutions. + 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 + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. + + + + Command line call with arguments if applicable. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + + + + + 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. + + + + + 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. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + 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 + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + + + + + Qualifier with how many nominal GPUs the app was invoked at runtime. + + + + + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + + + + + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + + diff --git a/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml b/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml new file mode 100644 index 0000000000..b4779cb6c4 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml @@ -0,0 +1,74 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of processes. + + + + + Computer science description of a profiling event. + + + + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + + + + + ISO 8601 time code with local time zone offset to UTC information + 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. + 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. + + + + + Maximum amount of virtual memory allocated per process during the event. + + + + + + + + Maximum amount of resident memory allocated per process during the event. + + + + + + diff --git a/contributed_definitions/nyaml/NXdeflector.nxdl.xml b/contributed_definitions/nyaml/NXdeflector.nxdl.xml new file mode 100644 index 0000000000..1af741055d --- /dev/null +++ b/contributed_definitions/nyaml/NXdeflector.nxdl.xml @@ -0,0 +1,71 @@ + + + + + Deflectors as they are used e.g. in an electron analyser. + + + + Qualitative type of deflector with respect to the number of pole pieces + + + + + + + + + + + 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. + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + + + + + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + + + + + 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 + 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/nyaml/NXdelocalization.nxdl.xml b/contributed_definitions/nyaml/NXdelocalization.nxdl.xml new file mode 100644 index 0000000000..993baa9401 --- /dev/null +++ b/contributed_definitions/nyaml/NXdelocalization.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of points/objects. + + + + + Number of mark data per point/object. + + + + + Number of atoms in the whitelist. + + + + + Number of isotopes in the whitelist. + + + + + Base class to describe the delocalization of point-like objects on a grid. + + Such a procedure is for instance used in image processing and e.g. atom probe + microscopy (APM) to discretize a point cloud onto a grid to enable e.g. + computing of point density, composition, or concentration values, obtain + scalar fields, and compute gradients of these fields. + + + + Reference or link to the grid on which the delocalization is applied. + + + + + Reference or link to the points which are delocalized on the grid. + + + + + The weighting model specifies how mark data are mapped to a weight per point. + For atom probe microscopy (APM) as an example, different models are used which + account differently for the multiplicity of an ion/atom: + + * default, points all get the same weight 1.; + for APM this is equivalent to ion species + * atomic_decomposition, points get as much weight as they have atoms + of a type in element_whitelist, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotope_whitelist. + + This description shows an example that could be reinterpreted for + similar such data processing steps in other fields of science. + + + + + + + + + + A list of elements (via proton number) to consider for the atomic_decomposition + weighting model. Elements must exist in the periodic table of elements. + + + + + + + + A list of isotopes to consider for the isotope_decomposition weighting model. + Isotopes must exist in the nuclid table. Entries in the fastest changing + dimension should be the pair of proton (first entry) and neutron number + (second entry). + + + + + + + + + Attribute data for each member of the point cloud. For APM these are the + ion species labels generated via ranging. The number of mark data per + point is 1 in the case for atom probe. + + + + + + + + + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point. For APM the weight are positive + integer values, specifically the multiplicity of the ion, + according to the details of the weighting_model. + + + diff --git a/contributed_definitions/nyaml/NXdistortion.nxdl.xml b/contributed_definitions/nyaml/NXdistortion.nxdl.xml new file mode 100644 index 0000000000..679d63a48b --- /dev/null +++ b/contributed_definitions/nyaml/NXdistortion.nxdl.xml @@ -0,0 +1,90 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of symmetry points used for distortion correction + + + + + Number of points of the matrix distortion field (x direction) + + + + + Number of points of the matrix distortion field (y direction) + + + + + Subclass of NXprocess to describe post-processing distortion correction. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the distortion correction been applied? + + + + + For `symmetry-guided distortion correction`_, + where a pattern of features is mapped to the regular geometric structure expected + from the symmetry. Here we record the number of elementary symmetry operations. + + .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub + + + + + For symmetry-guided distortion correction. Here we record the coordinates of the + symmetry centre point. + + + + + + + + For symmetry-guided distortion correction. Here we record the coordinates of the + relevant symmetry points. + + + + + + + + + Column deformation field for general non-rigid distortion corrections. 2D matrix + holding the column information of the mapping of each original coordinate. + + + + + + + + + Row deformation field for general non-rigid distortion corrections. 2D matrix + holding the row information of the mapping of each original coordinate. + + + + + + + + + Description of the procedures employed. + + + diff --git a/contributed_definitions/nyaml/NXebeam_column.nxdl.xml b/contributed_definitions/nyaml/NXebeam_column.nxdl.xml new file mode 100644 index 0000000000..697766a35b --- /dev/null +++ b/contributed_definitions/nyaml/NXebeam_column.nxdl.xml @@ -0,0 +1,82 @@ + + + + + Container for components to form a controlled beam in electron microscopy. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml b/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml new file mode 100644 index 0000000000..7b40cd372e --- /dev/null +++ b/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml @@ -0,0 +1,136 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a + pysical quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + 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 electron analyser 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. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/nyaml/NXellipsometry.nxdl.xml b/contributed_definitions/nyaml/NXellipsometry.nxdl.xml new file mode 100644 index 0000000000..3a4df7cb89 --- /dev/null +++ b/contributed_definitions/nyaml/NXellipsometry.nxdl.xml @@ -0,0 +1,839 @@ + + + + + + Variables used throughout the document, e.g. dimensions and important + parameters + + + + Size of the energy or wavelength vector used, the length of + NXinstrument/spectrometer/wavelength array + + + + + How many variables are saved in a measurement. e.g. 2 for Psi and + Delta, 16 for Mueller matrix elements, 15 for normalized Mueller + matrix, 3 for NCS, the length of NXsample/column_names + + + + + Number of incident angles used, the length of + NXinstrument/angle_of_incidence array + + + + + Number of sample parameters scanned, if you varied any of the + parameters such as temperature, pressure, or pH, the maximal length of + the arrays specified by NXsample/environment_conditions/SENSOR/value + if it exists. + + + + + Number of time points measured, the length of NXsample/time_points + + + + + Ellipsometry, complex systems, up to variable angle spectroscopy. + + Information on ellipsometry is provided, e.g. in: + + * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, + John Wiley & Sons, 2007. + * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, + North-Holland Publishing Company, 1977. + * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, + William Andrew, 2005. + + Open access sources: + + * https://www.angstromadvanced.com/resource.asp + * https://pypolar.readthedocs.io/en/latest/ + + Review articles: + + * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", + J. Phys. D: Appl. Phys. 32, R45 (1999), + https://doi.org/10.1088/0022-3727/32/9/201 + * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", + Thin Solid Films 571, 334-344 (2014), + https://doi.org/10.1016/j.tsf.2014.03.056 + * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", + Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, + (3 October 1997), + https://doi.org/10.1117/12.283870 + * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", + Thin Solid Films 233, 96-111 (1993), + https://doi.org/10.1016/0040-6090(93)90069-2 + * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", + Adv. Opt. Techn., (2022), + https://doi.org/10.1515/aot-2022-0016 + + + + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition defines: + + * elements of the experimental instrument + * calibration information if available + * parameters used to tune the state of the sample + * sample description + + + + An application definition for ellipsometry. + + + + Version number to identify which definition of this application definition was + used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant to the + application definition + + + + + + + + + Unique identifier of the experiment, such as a (globally persistent) unique + identifier. + i) The identifier is usually defined by the facility or principle investigator. + ii) The identifier enables to link experiments to e.g. proposals. + + + + + A free-text description of the experiment. What is the aim of the experiment? + The general procedure. + + + + + Start time of the experiment. UTC offset should be specified. + + + + + + Commercial or otherwise defined given name to the program that was used to + generate the result file(s) with measured data and metadata. This program + converts the measured signals to ellipsometry data. If home written, one can + provide the actual steps in the NOTE subfield here. + + + + + Either version with build number, commit hash, or description of a (online) + repository where the source code of the program and build instructions can be + found so that the program can be configured in such a way that result files can + be created ideally in a deterministic manner. + + + + + Website of the software. + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + Official telephone number of the user. + + + + + + General properties of the ellipsometry equipment + + + + The name of the instrument + + + + The used version of the hardware if available. If not a commercial instrument + use date of completion of the hardware. + + + + + + Name of the company which build the instrument + + + + + ISO8601 date when the instrument was constructed. UTC offset should be + specified. + + + + + Commercial or otherwise defined name of the software that was used for the + measurement + + + + Version and build number or commit hash of the software source code + + + + + Website of the software. + + + + + + Specify the used light source. Multiple selection possible. + + + + + Were focussing probes (lenses) used? + + + + + Were the recorded data corrected by the window effects of the lenses? + + + + + Specify the angular spread caused by the focussing probes + + + + + What type of ellipsometry was used? See Fujiwara Table 4.2 + + + + + + + + + + + + + + + + + + + Was a calibration performed? If yes, when was it done? If the calibration time + is provided, it should be specified in calibration/calibration_time. + + + + + + + + + + + + Ellipsometers require regular calibration to adjust the hardware parameters for + proper zero values and background light compensation. + + + + If calibtration status is 'calibration time provided', specify the ISO8601 date + when calibration was last performed before this measurement. UTC offset should + be specified. + + + + + Arrays which provide the measured calibration data. Multiple sets are possible, + e.g. Psi and delta measured on a e.g. silicon calibration wafer, and the + straight-through data. We recommend to provide data that is measured under the + same settings as the measurement was performed, that is if Psi and Delta are + measured for your data, also provide Psi and Delta here and use the same + wavelenghts as for the measured data. + + + + What data were recorded for the calibration? The number of variables + (N_variables) have to be set to the number of provided data columns accordingly, + e.g. psi/delta -> N_variables = 2, Jones vector -> N_variables = 4, Mueller + martix -> N_variables = 16, etc. + + + + + + + + + + + + Angle(s) of incidence used during the calibration measurement (excluding + straight through mode) + + + + + + + + The wavelength or equivalent values (which are inter-convertible). + The importer should convert all to one unit, and make the others + accessible. Historically, energy is used in eV, but for visible + spectroscopy wavelength is more common, for IR wave numbers in + 1/cm units. + + Possibly use the same type of data as for the measurement. + + + + + + + + Calibration is performed on a reference surface (usually a silicon wafer with a + well defined oxide layer) at a number of angles of incidence and in a straight + through mode (transmission in air). + + + + + + + + + + + Free-text to describe which sample was used for calibration, e.g. silicon wafer + with 25 nm thermal oxide layer. + + + + + + Incident angle of the beam vs. the normal of the bottom reflective (substrate) + surface in the sample + + + + + + + + Sample stage, holding the sample at a specific position in X,Y,Z (Cartesian) + coordinate system and at an orientation defined by three Euler angles (alpha, + beta, gamma). The stage may be motorized or manual, special for liquids or gas + environment. + + + + Specify what type of stage was used. + + + + + + + + + + + + A free-text field to provide information about the stage. + + + + + The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with the angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). + This transformation brings us from the NEXUS coordinates to the stage coordinates. + Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) + Last, provide the rotations of the sample + + + + If there is no motorized stage, we should at least qualify where the beam hits + the sample and in what direction the sample stands in a free-text description, + e.g. 'center of sample, long edge parallel to plane of incidence'. + + + + + + + For environmental measurements, the environment (liquid, vapor, vacuum etc.) is + enclosed in a cell or cryostat, which has windows both in the direction of the + source and the detector (looking from the sample). These windows also add a + phase shift to the light altering the measured signal. This shift has to be + corrected based on measuring a known sample in the environmental cell. + + + + The material of the window + + + + + + + + + + + + + + + If you specified 'other' as window material, decsribe here what it is. + + + + + Thickness of the window + + + + + Angle of the window normal (outer) vs. the substrate normal (similar to the + angle of incidence). + + + + + Recorded data that can be used to calculate the window effect. Typically this is + the substrate (e.g. silicon with thermal oxide layer) in air without window and + in a known medium with the window. + + + + What sample was used to estimate the window effect? + + + + + Wavelength of the reference data. Use the same wavelengths at which all other + measurements are recorded + + + + + + + + Recorded data of a reference surface with and without window/medium. + + + + + + + + + + + + + Which type of detector was used, and what is known about it? A detector can be a + photomultiplier (PMT), a CCD in a camera, or an array in a spectrometer. If so, + the whole detector unit goes in here. Integration time is the count time field, + or the real time field. See their definition. + + + + What kind of detector module is used, e.g. CCD-spectrometer, CCD camera, PMT, + photodiode, etc. + + + + + + + + + + + + + If you specified 'other' as detector type, please write down what it is. + + + + + Define how many rotations of the rotating element were taken into account per + spectrum. + + + + + Define which element rotates, e.g. polarizer or analyzer. + + + + + + + + + + + Rotation rate, if the revolution does not change during the measurement. + + + + + Specify maximum and minimum values for the revolution. + + + + + + + + Minimum signal for which dynamic averaging is performed. + + + + + Value for the minimum intensity chosen. Data points below this value might be + skipped by the instrument + + + + + + The spectroscope element of the ellipsometer before the detector, but often + integrated to form one closed unit. Information on the dispersive element can be + specified in the subfield GRATING. Note that different gratings might be used + for different wavelength ranges. The dispersion of the grating for each + wavelength range can be stored in grating_dispersion. + + + + Wavelength value(s) used for the measurement. An array of 1 or more elements. + Length defines N_wavelength + + + + + + + + Diffraction grating, as could be used in a monochromator. If two or more + gratings were used, define the angular dispersion and the wavelength range + (min/max wavelength) for each grating and make sure that the wavelength ranges + do not overlap. The dispersion should be defined for the entire wavelength range + of the experiment. + + + + Dispersion of the grating in nm/mm used. + + + + + Minimum wavelength of the grating. + + + + + Maximum wavelength of the grating. + + + + + + Spectral resolution of the instrument. + + + + + Define the width of the monochromator slit in the subfield x_gap. + + + + Was the slit width fixed? + + + + + If slit width was not fixed, define the maximum slit width. + + + + + + + + Properties of the sample, its history, the sample environment and experimental + conditions (e.g. surrounding medium, temperature, pressure etc.), along with the + data (data type, wavelength array, measured data). + + + + Use Hill's system for listing elements of the periodic table which are inside or + attached to the surface of the specimen and thus relevant from a scientific + point. The purpose of this field is to allow material databases to parse the + relevant elements without having to interpret the sample history or other + fields. + + + + + Descriptive name of the sample + + + + + Ideally, a reference to the location or a unique (globally persistent) + identifier (e.g.) of e.g. another file which gives as many as possible details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history. In the case that such a detailed history of the + sample is not available, use this field as a free-text description to specify + details of the sample and its preparation. + + + + + ISO8601 date with time zone (UTC offset) specified. + + + + + Qualitative description of the layer structure for the sample. For example: + Si/native oxide/thermal oxide/polymer/peptide + + + + + An identifier to correlate data to the experimental conditions, if several were + used in this measurement; typically an index of 0 - N + + + + + Select which type of data was recorded, for example Psi and Delta (see: + https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It is possible to + have multiple selections. Data types may also be converted to each other, e.g. a + Mueller matrix contains N,C,S data as well. This selection defines how many + columns (N_variables) are stored in the data array. + + + + + + + + + + + + + Please list in this array the column names used in your actual data. That is + ['psi', 'delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for a full Mueller matrix, + etc. + + + + + + + + Resulting data from the measurement, described by data type. Minimum two columns + containing Psi and Delta, or for the normalized Mueller matrix it may be 16 (or + 15 if the element (1,1) is all 1). + + + + + + + + + + + + Specified uncertainties (errors) of the data described by data type. The + structure is the same as for the measured data. + + + + + + + + + + + + An array of relative time points if a time series was recorded. + + + + + + + + Specify external parameters that have influenced the sample. + + + + Describe what was the medium above or around the sample. The common model is + built up from the substrate to the medium on the other side. Both boundaries are + assumed infinite in the model. Here, define the name of the medium (e.g. water, + air, UHV, etc.). + + + + + Array of pairs of complex refractive indices of the medium for every measured + wavelength. Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. Specify the complex + refractive index: n + ik + + + + + + + + How many measurements were done varying the parameters? This forms an extra + dimension beyond incident angle, time points and energy/wavelength (this is the + length of the 4th dimension of the data). Defaults to 1. + + + + + Indicates which parameter was changed. Its definition must exist below. The + specified variable has to be number_of_runs long, providing the parameters for + each data set. If you vary more than one parameter simultaneously use one signal + instance for each. Record every parameter value in a linear manner, so N_p1 is + the number of measurements taken. For example, if you measure at two + temperatures and three pressures the temperature signal value looks like [T1, + T1, T1, T2, T2, T2] and the pressure signal value looks like [p1, p2, p3, p1, + p2, p3], and N_p1 = 6. + + + + + + + + + + + + + Was the sample modified using an optical source? Describe in this group the + parameters of the optical excitation used. + + + + Wavelength value(s) or the range used for excitation. In cases of continuous + laser radiation, a value or a set of values may do but for other illumination + types, such as pulsed lasers, or lamps, a range may describe the source better. + + + + + Specify the FWHM of the excitation + + + + + How long was the sample excited. + + + + + The integrated energy of light pulse. + + + + + + A sensor used to monitor an external condition. The value field contains the + measured values. If it is constant within an error for every run then use only + an array of length one. + + + + + + + What parameters are derived from the above data. + + + + Light loss due to depolarization as a value in [0-1]. + + + + + + A default view of the data, in this case Psi vs. wavelength and the angles of + incidence. If Psi does not exist, use other Mueller matrix elements, such as N, + C and S. + + + + We recommend to use wavelength as a default attribute, but it can be replaced in + the case of not full spectral ellipsometry to any suitable parameter along the + X-axis. + + + + + diff --git a/contributed_definitions/nyaml/NXem.nxdl.xml b/contributed_definitions/nyaml/NXem.nxdl.xml new file mode 100644 index 0000000000..e044a10c31 --- /dev/null +++ b/contributed_definitions/nyaml/NXem.nxdl.xml @@ -0,0 +1,1026 @@ + + + + + Characterization and session with one sample in an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM), whether it be with scanning electron microscope (SEM) + or transmission electron microscope (TEM) instruments, are versatile tools for + preparing and characterizing samples and specimens. The term specimen is considered + a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating either the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an EM is an electron accelerator. Experimentalists use an EM + in sessions during which they characterize as well as prepare specimens. + This application definition describes data and metadata about processes and + characterization tasks applied to one specimen. The application definition + focuses on the usage of EM in materials research. The application definition + design makes it in principle applicable also in cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple NXentry instances. + + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process maybe even operating + the microscope. Oftentimes the scientists operate the instrument themselves + either on-site or remotely and can ask technicians for support. + In all cases, these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate application + definitions for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is used mainly to measure the + transmitted electron beam. This calls for using a different lens setup and + relative placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to illuminate + through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Compared to SEMs, TEMs have a different relative arrangement between the + lenses and the specimen which is most obvious by the different relative + arrangement of the objective lens versus the specimen. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Consequently, detectors can also be similar + if not exactly the same. + + **An embracing schema instead of specific SEM or TEM schemes**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower + the addressed user base is which develops or uses schemes for research data + management (RDM) with EM, the more understandable it is that scientists of + either community (or sub-community) ask for method-specific schemes. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemes such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the development in the past has shown that these activities led to + a zoo of schemes and especially vocabulary in use with implementations of these + into many data and file formats. There is nothing which prevents the communities + to make these schemes open and interoperable. Open here means specifically not + that all data are compliant with/or use the schema and have to end up in the + open-source domain. There can be embargo periods first of all. + + Open means that the metadata and associated schemata are documented in a manner + that as many details as possible are open in the sense that others can understand + what the (meta)data mean conceptually. Instead of trying of maintain a zoo + of eventually difficult to make interoperable formats and schema we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different + schemes with associated representations of data and metadata in EM: + Each combination of schemes or an interoperable-made handshake between two + file formats or software packages has to be maintained by software developers. + This counts especially when data should be processed interoperably + between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemes and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemes. + + Aiming for more standardization, i.e. a lower number of schemes rather than + a single standard for electron microscopy is a compromise that can serve + academia as it enables the EM community to focus their software development + efforts on those schemes, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for vendors of EM hard- and software as it improves the longevity of certain + schema; and thus can help to incentivize vendors to support the community with + implementing support for such schemes into their proprietary applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemes for EM research. + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemes differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemes can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be software from specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions and strictly speaking an application definition can only be + really general if it does not make a single entry required, in which case however + it would also not offer much value as even empty datasets would be compliant. + + **Verification of constraints and conditions**: + Tools like NeXus so far do not avoid or protect against all such possible + inconsistencies; however NeXus offers a mechanism and toolset, through which + schemes can be documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + This application definition takes a key step towards standardization of EM data. + It offers a controlled vocabulary and relation between concepts and data + relevant for research with electron microscopes. To be most efficient and + offering reusability, the application definition should be understood as a + template that one should ideally use as is. This application definition + is called NXem. NXem can be considered a base for designing more specialized + definitions (ideally prefixed with NXem) *method*. + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but make + them optional or, even better, propose changes in this NXem application definition. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as vendors also have a relevant interest in finding + a compromise between being open to their user and securing their business. + + EM experiments by design illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being vendor-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + often undocumented in detail by vendors. This serves users and makes EM + experiments easier understandable and conveniently executable for a broad + user base. On the flipside these subtilities limit the opportunities for + making application definitions too general. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemes. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what are metadata in EM. While doing + so we found that existent terminology can be encoded into a more controlled + vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Generic experimental details (time-zone-aware timestamp, identifiers, name); + conceptually these are session details. A session at a microscope may + involve the characterization of multiple specimens. For each specimen + an instance of an (NXentry) is created. Details of the instrument have to + be stored at least in an entry. Other entries should refer to these + metadata via links to reduce redundancies. + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of NXevent_data_em have an own em_lab section. + The reason is that EMs can be highly dynamic, be used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * NXmonitor; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. Alternatively, NXevent_data_em + instances can be used to store time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * NXinstrument; + conceptually this is a container to store arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * NXuser; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details who executed an event of data acquisition or processing. + * NXevent_data_em instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * NXdata; at the top-level, conceptually, this is a place for documenting + available default plottable data. A default plottable can be useful for + research data management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables not intended to serve every possible analysis and + visualization demand but be a preview. We made this choice because what constitutes + a useful default plot is often a matter of interpretation, somewhat of personal taste, + and community standards. In effect, default plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals and + images. Examples for possible default plottables could be arbitrarily + taken secondary, back-scattered, electron image, diffraction pattern, + EELS spectra, composition, or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Above images, spectra, and mappings should be stored as NXdata instances, + ideally formatted in such a way that they can be displayed with + visualization software that can be specific for the file format in which + the data are stored. NeXus specifies only the data model, i.e. the terms + and their relations. These descriptions can be implemented and stored in + JSON, HDF5, XML, or HSDS, file storage, or even other formats, although + HDF5 is often used. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images of electron counts detected in specific operation modes (bright + field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) + * Spectra (X-ray quanta or Auger electron counts) + * These data are in virtually all cases a result of some numerical processing. + It makes sense to name these data and processing tasks with a controlled vocabulary, + e.g. SE (secondary electron), BSE (back-scattered electron), Kikuchi, + X-ray, Auger, Cathodolum(inescence) etc. + + A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk). To this end the schema, here makes no + specific assumptions, not even that all the fields/group of a schema instance + have to be stored at all into a single file. Instead, the schema specifies the + relations between metadata, some of the constraints and conditions on how the data + should be formatted, what the data conceptually represent, and which terms + (controlled vocabulary) is practical to store to index specific quantities. + + In effect, the application definition is a graph which describes how + numerical data and (meta)data for EM research are related to one another. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + Commercial or otherwise given name to the program which was used to + create the file. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual NXprocess + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + Program 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. + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a sub-set + of the entire sample history, i.e. what you would consider are the key steps + and relevant information about the specimen, its material, microstructure, + thermo-chemo-mechanical processing state, and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly discouraged + because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over for + the analysis. At the point it enters the microscope the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + Use Hill's system for listing elements of the periodic table which are inside or attached + to the surface of the specimen and thus relevant from a scientific point of view. + + The purpose of the field is to offer materials database systems an opportunity to parse + the relevant elements without having to interpret these from the sample history. + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an NXinteraction_vol_em for + individual NXevent_data_em instances can provide a much better description + of the relevant details why one would otherwise ask to store the density + of the specimen. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_em sections. These event instances take the role of time snapshot. + For an NXevent_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_gun group + again the details of the gun type and manufacturer but only the high-voltage + if for that event the high-voltage was different. If for all events + the high-voltage was the same it is not even necessary to include an electron_gun + section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Free text option to write further details about the detector. + + + + + + + + + + + + + + + + + + + + + + + + A container to structure a set of NXevent_data_em instances. + + An event is a time point/time interval during which the microscope + was configured in a specific way and the microscope was used + to take a measurement. The microscope is considered stable during this + interval. + + Each NXevent_data_em instance holds an acquisition task with the microscope. + For instance the capturing of a secondary electron, backscattered + electron, diffraction image, or spectrum. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed into consumable data like images, spectra, + etc. These on-the-fly data processing tasks are usually performed + by the control software, eventually realized with custom scripts. + + Furthermore, NXevent_dat_em instances can document specific values + and settings of the microscope during the snapshot/event. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_em instances can hold several specific + NXimage_em or NXspectrum_em instances taken and considered as + one event, i.e. a point in time when the microscope had the + settings specified either in NXinstrument or in this NXevent_data_em + instance. + + The application definition is designed without an explicit need + an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. An NXevent_data_em can be used to document a + specific state of the microscope at a time without having it placed + into the NXinstrument group. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there is no vendor-overarching standard according to which + electron microscope data are documented and stored. Therefore, it is + still a frequently the case that vendor-specific files have many fields + that cannot be safely mapped. Therefore, users are always adviced to + keep the vendor files. Working however with these vendor files inside + specific software, like materials databases, demands for parsers which + extract pieces of information from the vendor representation (numerical + data and metadata) and map them on a schema with which the database + and its associated software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented dynamically, coveringly enough in our opinion so that it is + safe to assume all vendor field names are known, logically understood, + interpretable, and thus mappable on a common schema using a controlled + common vocabulary. + + Therefore we encourage user for now to store for each image_set_em + or spectra_set_em instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain like numerical data and metadata were copied into an instance + of this schema for the purpose of working with the data in e.g. tools + offered by the materials database. + + During work on implementing file format/metadata parsers and developing + this application definition we realized that several software tools + currently do not consistently track time-zone-aware timestamps of + events associated with the data, processing, and during the microscope + session. This is in partly a consequence of vendor which store + detailed time data in different formats. We would like to encourage the + community and especially the vendors to work towards a standardization, + or at least a open documentation of the way how time-zone-aware time + data are collected and stored how and where during a microscope session + and how they end up in files and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + Reference to a specific state and setting of the microscope components. + + + + + + The detector or set of detectors that was used to collect this signal. + The name of the detector has to match one of the names of available + NXdetector instances e.g. if the instrument has an ebsd_camera + the detector for an NXimage_em_kikuchi should be the NXdetector + instance called ebsd_camera. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml b/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml new file mode 100644 index 0000000000..def450232e --- /dev/null +++ b/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml @@ -0,0 +1,69 @@ + + + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml b/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml new file mode 100644 index 0000000000..06000fa95d --- /dev/null +++ b/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml @@ -0,0 +1,221 @@ + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations caused or apertures used. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then choose a different value. As the aperture affects + the electron beam it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of objects, + and eventually (externally) applied stimuli and positioning of the specimen. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Theoretically, an instrument and specimen should be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + stable and of high enough quality to reuse data collection. + + In all these cases it is practical to store time-dependent data of the + instrument state not in the respective instrument component groups + of the top-level NXinstrument but in a sort of a log of event data. + This is the idea behind the NXevent_data_em snapshot containers. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + But does this warrant to document the microscope state at an even finer + and impractical in-between one collects signal time intervals? + + This is a question of how finely does one granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and illuminates a portion of the material, i.e. + the interaction volume, whose signal contributions are then counted by the + detector(s) as per pixel- or per voxel signal in the region-of-interest. + In principle this application definition allows for such doing so. + However, in most cases such a fine granularization would demand the collection + of data which are as of now hardly retrievable with commercial instruments + nor of primary interest. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. Which warrant an own + consideration in the future. A more detailed overview of such computational + steps to cope with scan distortions is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axis; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements + (i.e. images, spectra of scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective groups of the NXinstrument though + inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope components. + + + + + Which specific event/measurement type. Examples are: + + * In-lens/backscattered electron, usually has quadrants + * Secondary_electron, image, topography, fractography, overview images + * Backscattered_electron, image, Z or channeling contrast (ECCI) + * Bright_field, image, TEM + * Dark_field, image, crystal defects + * Annular dark field, image (medium- or high-angle), TEM + * Diffraction, image, TEM, or a comparable technique in the SEM + * Kikuchi, image, SEM EBSD and TEM diffraction + * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) + * Electron energy loss spectra for points, lines, surfaces, TEM + * Auger, spectrum, (low Z contrast element composition) + * Cathodoluminescence (optical spectra) + * Ronchigram, image, alignment utility specifically in TEM + * Chamber, e.g. TV camera inside the chamber, education purposes. + + + + + The detector or set of detectors that was used to collect this signal. + The name of the detector has to match the names used for available + detectors, i.e. if the instrument has an *ebsd_camera* + named detector, instances of NXimage_em_kikuchi should use + *ebsd_camera* as the detector name. + + + + + + + + + + + + + + + + + + + A group where specific settings of the instrument during the + event can be captured. This is the preferred way to keep track of + different settings of the microscope during the session. + For instance, a user may first take an overview image with different + magnification and settings and then start a spectrum analyses. + These should be stored as two NXevent_data_em instances in an + application definition. Each storing the specific settings. + + NXfabrication relevant details should not be repeated because + we assume that the session is with the same microscope. + Namely, it is hopefully not happening that someone builds out a + component of the microscope while is taking a measurement with it. + For this reason the specialized NXinstrument here contains no + NXfabrication group. + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml b/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml new file mode 100644 index 0000000000..030f21c18c --- /dev/null +++ b/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml @@ -0,0 +1,11 @@ + + + + + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. + + + diff --git a/contributed_definitions/nyaml/NXfabrication.nxdl.xml b/contributed_definitions/nyaml/NXfabrication.nxdl.xml new file mode 100644 index 0000000000..15187d07f5 --- /dev/null +++ b/contributed_definitions/nyaml/NXfabrication.nxdl.xml @@ -0,0 +1,29 @@ + + + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml b/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml new file mode 100644 index 0000000000..e140483346 --- /dev/null +++ b/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of edges. + + + + + A set of (eventually directed) edges which connect nodes/vertices of a graph. + + + + Total number of edges, counting eventual bidirectional edges only once. + + + + + Integer which specifies the first index to be used for distinguishing + edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish edges for explicit indexing. + + + + + + + + Specifier whether each edge is non-directional, one-directional, + or bidirectional. Use the smallest available binary representation + which can store three different states: + + * 0 / state 0x00 is non-directional + * 1 / state 0x01 is one-directional + * 2 / state 0x02 is bi-directional + + + + + + + + Pairs of node/vertex identifier. Each pair represents the connection + between two nodes. + + In the case that the edge is non- or bi-directional + node identifier should be stored in ascending order is preferred. + + In the case of one-directional, for each pair the identifier of the source + node is the first entry in the pair. The identifier of the target is the + second entry in the pair, i.e. the pair encodes the information as + if one traverses the edge from the source node walking to the target node. + + + + + + + + + A human-readable qualifier which type or e.g. class instance the + edge is an instance of. + + + + + + + + A human-readable label/caption/tag for the edge. + + + + + + diff --git a/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml b/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml new file mode 100644 index 0000000000..85b26b99ed --- /dev/null +++ b/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml @@ -0,0 +1,66 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the graph. Eventually use one for categorical. + + + + + The cardinality of the set, i.e. the number of nodes/vertices of the + graph. + + + + + A set of nodes/vertices in space representing members of a graph. + + + + + + Integer which specifies the first index to be used for distinguishing + nodes. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish nodes for explicit indexing. + + + + + + + + A human-readable qualifier which type or e.g. class instance the + node is an instance of. As e.g. a NeXus application definition is a + graph, more specifically a hierarchical directed labelled property graph, + instances which are groups like NXgraph_node_set could have an is_a + qualifier reading NXgraph_node_set. + + + + + + + + A human-readable label/caption/tag of the graph. + + + + + + diff --git a/contributed_definitions/nyaml/NXgraph_root.nxdl.xml b/contributed_definitions/nyaml/NXgraph_root.nxdl.xml new file mode 100644 index 0000000000..169cd51519 --- /dev/null +++ b/contributed_definitions/nyaml/NXgraph_root.nxdl.xml @@ -0,0 +1,14 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + An instance of a graph. + + + + diff --git a/contributed_definitions/nyaml/NXibeam_column.nxdl.xml b/contributed_definitions/nyaml/NXibeam_column.nxdl.xml new file mode 100644 index 0000000000..22b67688c3 --- /dev/null +++ b/contributed_definitions/nyaml/NXibeam_column.nxdl.xml @@ -0,0 +1,99 @@ + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + Average/nominal brightness + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml new file mode 100644 index 0000000000..5bf3f42f7c --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml @@ -0,0 +1,135 @@ + + + + + + + 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 annular dark field images. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + + + Details how (HA)ADF images were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXimage_set_em_adf were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the adf image(s). + + + + Program 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. + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + Annular dark field image stack. + + + + Image intensity values. + + + + + + + + + + Image intensities + + + + + Image identifier + + + + + + + Image ID. + + + + + + Pixel center of mass position y-coordinates. + + + + + + + Label for the y axis. + + + + + + Pixel center of mass position x-coordinates. + + + + + + + Label for the x axis. + + + + + diff --git a/contributed_definitions/nyaml/NXion.nxdl.xml b/contributed_definitions/nyaml/NXion.nxdl.xml new file mode 100644 index 0000000000..08de2c9c52 --- /dev/null +++ b/contributed_definitions/nyaml/NXion.nxdl.xml @@ -0,0 +1,110 @@ + + + + + + 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. + + + + 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, 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 should be filled with zero. + + + + + + + + + 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, 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 labelled + as an ion of the here referred to ion_type. + + + + + + + diff --git a/contributed_definitions/nyaml/NXiv_temp.nxdl.xml b/contributed_definitions/nyaml/NXiv_temp.nxdl.xml new file mode 100644 index 0000000000..5370bb2425 --- /dev/null +++ b/contributed_definitions/nyaml/NXiv_temp.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + Number of different temperature setpoints used in the experiment. + + + + + Number of different voltage setpoints used in the experiment. + + + + + Application definition for temperature-dependent IV curve measurements. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature dependent IV curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + + + + + + + + + + + Describes an environment setup for a temperature-dependent IV measurement experiment. + + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + + + + + + + + + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXlens_em.nxdl.xml b/contributed_definitions/nyaml/NXlens_em.nxdl.xml new file mode 100644 index 0000000000..88aff9b2b2 --- /dev/null +++ b/contributed_definitions/nyaml/NXlens_em.nxdl.xml @@ -0,0 +1,88 @@ + + + + + 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/nyaml/NXliquid_jet.nxdl.xml b/contributed_definitions/nyaml/NXliquid_jet.nxdl.xml new file mode 100644 index 0000000000..e66ef2fe29 --- /dev/null +++ b/contributed_definitions/nyaml/NXliquid_jet.nxdl.xml @@ -0,0 +1,48 @@ + + + + + Description of a liquid jet + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXmanipulator.nxdl.xml b/contributed_definitions/nyaml/NXmanipulator.nxdl.xml new file mode 100644 index 0000000000..d961e331bc --- /dev/null +++ b/contributed_definitions/nyaml/NXmanipulator.nxdl.xml @@ -0,0 +1,79 @@ + + + + + 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/nyaml/NXmatch_filter.nxdl.xml b/contributed_definitions/nyaml/NXmatch_filter.nxdl.xml new file mode 100644 index 0000000000..8ccc82cd31 --- /dev/null +++ b/contributed_definitions/nyaml/NXmatch_filter.nxdl.xml @@ -0,0 +1,42 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many different match values does the filter specify. + + + + + Settings of a filter to select or remove entries based on their value. + + + + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + + + + + + + + + Array of values to filter according to method. For example if the filter + specifies [1, 5, 6] and method is whitelist, only entries with values + matching 1, 5 or 6 will be processed. All other entries will be filtered + out. + + + + + + diff --git a/contributed_definitions/nyaml/NXmpes.nxdl.xml b/contributed_definitions/nyaml/NXmpes.nxdl.xml new file mode 100644 index 0000000000..1711826f5f --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes.nxdl.xml @@ -0,0 +1,331 @@ + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (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. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(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. + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml b/contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml new file mode 100644 index 0000000000..52eb835d3c --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml @@ -0,0 +1,392 @@ + + + + + This is the application definition for multidimensional photoelectron + spectroscopy on liquids + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (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. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(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. + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + + + + Transformations describing the transformation chain to the + liqudjet leaf. + + + + The normal of the liquidjet leaf. + + + + The vector normal to the liquidjet leaf. + + + + + Pointer to the previous matrices in the transformation chain + to relate the normal to the rest of the instrument. + If this is '.' the vector attribute only specifies the normal vector + without specifying the position of the liquidjet leaf with respect + to the instrument. + + + + + + + Solvent material of the liquidjet. + This also accounts for multiple jets if more + than one solvent is given. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml b/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml new file mode 100644 index 0000000000..58ea100bc4 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml @@ -0,0 +1,123 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the description. + + + + + The number of objects, which can be crystals, grains, phases or phase + field regions. + + + + + Base class to describe data about observed crystals in microstructures. + + Both experiments and computer simulations support that atoms organize into regions + which are often separated and interconnected by different types of crystal defects. + Crystalline regions show a long-range periodic arrangement (compared to the + length scale of nearest neighbor distances). + Although the group of atoms forming a crystal is virtually never static, due + to diffusive in- and outflux of atoms and thermal fluctuations of the atoms + about their equilibrium positions, crystals are relevant persistent features + in microstructures. The size of crystals can span orders of magnitude from + meters to nanometers. + + There are two different and (somewhat extremal) views on crystals and how to + describe their eventually very rich variety of internal defects. Either + crystals can be coarse-grained into continuum objects or not. In the second case + they need a more advanced internal description of defects inside the grains + which convinces many that eventually a grain has to be viewed from its + individual atoms, its material points, and the hierarchy of structural motifs + local arrangements in the crystal. + + Despite these details, identifying crystals is foremost a labeling task. + Atoms are clustered into structural motifs and (noise) and these motifs + are again clustered into crystals. + + There are two main approaches how crystals are described in mesoscale + microstructure evolution simulations. Assuming for now transformations in the + solid state, precipitates, phase regions, sub-grains or grains are examples + of crystals: + + * Objects are either tracked explicitly in the sense that their shape will + be resolved through the crystal interfaces using e.g. a phase-field, + level-set, grid, or finite element mesh based models and implementations. + These simulations may keep track of explicit crystal/grain/object-related + quantities. Such models can treat the interface network implicitly while + still focusing their description on the explicit crystals. + During such simulations the interface is often analyzed on-the-fly, + because of technical demands (like in level-set implementations) or to + trigger specific situations where it is relevant to resolve the + position of the interfaces explicitly (like for placing seeds for phases, + recrystallizing grains etc, or for visualization purposes), demand a + description of interfaces between crystals. + For explicitly tracking simulations this base class can be applied as is. + * Objects are tracked implicitly in the sense that the computational domain + is discretized into an ensemble of what one can call material points. + Such models can be described at different length scale: On the one hand + where atom dynamics are (whether the assumption is substantiated or not) + homogenized/-able already or not. Each material point is assumed to have + at least one associated constitutive phase. + Such simulations usually do not/cannot resolve crystal-related quantities + without executing an on-the-fly post-processing of snapshot data from + which the spatial representation of the crystal is recovered. + An important case are large-strain formalism crystal plasticity methods. + Here the initial configuration represents most frequently material points + on a regular grid. Within the course of the simulation this grid gets + deformed implicitly. The code internally keeps no track of how the cells/ + material points of what is essentially a Voronoi tessellation, are deformed. + Only in the case when one would like to visualize the deformed configuration, + a post-processing of the simulation snapshot data is executed which + recovers the positions of the material points in the deformed configuration + in the laboratory coordinate system from which one can then extract a + representation of grains/precipitates, i.e. crystals. + It is a signature of such simulations that quantities like orientation + are defined as material point quantities. This means what constitutes the grain + needs to be extracted by cluster analyses. + In this regard, such simulation are essentially matching the representation and + case of molecular dynamics simulations, with the important difference + that these track atoms, from whose configuration + in a snapshot a description has to be computed what are most likely the + atoms that belong to the volume of the crystal or the interface/defect + network. + + + + + + Integer which specifies the first index to be used for distinguishing + objects. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish objects for explicit indexing. + + + + + + + + Depending on the value of dimensionality, the area or volume of each object. + + + + + + diff --git a/contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml b/contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml new file mode 100644 index 0000000000..d5766da5bd --- /dev/null +++ b/contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml @@ -0,0 +1,83 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class to describe details about dislocations observed in microstructures. + + Dislocations are one-dimensional crystal defects whose primary interest is + that they are the carrier of plastic deformation. Conceptually dislocations + are a continuum-scale description of how atoms arrange spatio-temporally on + the one hand as a persistent defect which on the other hand though, when + inspected in detail for the atom dynamics and their interaction with other + crystal defects manifest as an involved microstructural feature for which + very different descriptions are used depending which length-, time-scale, + and research question people address. + + This is manifested in the large amount of literature on the topic: + + * https://www.sciencedirect.com/bookseries/dislocations-in-solids + + Dislocations are one prominent group of representatives for one-dimensional + features, other defects include disconnections and/or disclinations, and even + more complicated configurations, especially when one considers not-necessarily + crystalline materials, quasi crystals. It would be rude to claim that a single + base class can encompass the entire complexity that this effectively + coarse-graining of atomic spatio-temporal configurations has, in an effort + to simplicify the description in the hope to arrive at physical models which + do not need to take into account the location and movement of every atom. + + However, it is also a fact that not every description, research question, and + thus use cases that one could think of what one should store as data and metadata + for one-dimensional, primarily line-type crystal defects, is equally relevant + for an ensemble of research studies. + + Thus, for the design of concrete schemata for the purpose of structured storage + of research data on dislocations or studies where dislocations are measured + or characterized, one has to prioritize which descriptors and aspects about + dislocations are likely relevant for a large number of users of a research + infrastructure. Consequently, it is possible to narrow down the scope of + the base class and application definition. + + It is noteworthy to mention that this applies not only to description + using NeXus, but points to the problem of creating a golden-bullet schema + capable of handling all possible subtleties. + + For now we have to accept that is not yet an ontology of e.g. the above + understanding of what dislocations are. Pragmatically we thus make the + following assumptions: + + * This base class is essentially a template how specific often referred + quantities for one-dimensional crystal defects can be stored. + * In practice dislocations have a finite length as they are embedded in a + finite specimen and wired into an ensemble of adjoining dislocations + or other adjoining crystal defects. + * There are the following general approaches of studying/characterizing + * 1. Indirect measurements where dislocations characterized statistically. + In this case different types of dislocations are distinguished + (geometrically-necessary, mobile, immobile), mainly motivated by + different constitutive, continuum-models how they are threated in + computer simulations with respect to what their effect is on ms evolution. + * 2. Electron microscopy measurements of single or several dislocation (bundles) + In this case post-processing strategies are necessary which can + extract statistical descriptors or d-dimensional reconstructions + * 3. Atomic-scale-resolved simulations. In this case the most frequently + performed tasks are again post-processing into polyline networks, + detailed local investigations of the atomic configurations, or both + with or without some correlation. + * 4. Analytical approaches whereby dislocations are resolved at the continuum + scale, as line defects containing other elementary defects (for instance) + in models of disconnection motion), or again atomically resolved treatments. + + From this we can conclude that an NXms_dislocation_set can primarily be + useful as a wrapper class in which specific details about dislocations + can be stored in an arbitrarily nested manner. + + + A starting point for the discussion. + + diff --git a/contributed_definitions/nyaml/NXms_interface_set.nxdl.xml b/contributed_definitions/nyaml/NXms_interface_set.nxdl.xml new file mode 100644 index 0000000000..d4dc82624e --- /dev/null +++ b/contributed_definitions/nyaml/NXms_interface_set.nxdl.xml @@ -0,0 +1,90 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class to describe details about interfaces observed in microstructures. + + Classically, interfaces are two-dimensional crystal defects whose relevance is + that they are agents which trigger crystal growth and discontinuities of the + crystal at which defects can accumulate and solutes segregate with fundamental + effect on the properties of materials. Conceptually, interfaces are a + continuum-scale description of how atoms arrange spatio-temporally. Interfaces + manifests as persistent defects. When inspected in more detail though they show + atom dynamics, coarse-grainable into again interactions between line-type + crystal defects (disconnections) through which interfaces are dynamic and can + interact with other defects. Owing to this complexity very different + descriptions are used depending on which length-, time-scale, + and research question people address. + + This is manifested in the large amount of literature on the topic: + + * A. P. Sutton et al. ISBN-13 978-0198500612 + * G. Gottstein et al. ISBN-13 978-1-4200-5436-1 + * K. Chen et al. https://doi.org/10.1073/pnas.1920504117 + + Interfaces, specifically grain and phase boundaries, are representatives of + two-dimensional microstructural features. It would be rude to claim that a single + base class can encompass the entire complexity that this effective + coarse-graining of atomic spatio-temporal configurations has. In the end, + interfaces are a model, an effort to simplicify the description in the hope + to arrive at physical models which do not need to take into account the static + and dynamic details of every atom. + + However, it is also a fact that not every description, research question, and + thus use cases that one could think of storing as data and metadata for + interfaces, is equally relevant and useful for an ensemble of research studies. + + Thus, for the design of concrete schemes for a structured storage of data on + interfaces are measured or characterized, one has to prioritize which + descriptors and aspects about interfaces are likely relevant for a large + number of users of the research infrastructure. Consequently, it is possible + to narrow down the scope of this base class. + + It is noteworthy to mention that this applies not only to schemes build + with NeXus, but points to the problem of creating a golden-bullet schema + that could handle all possible subtleties of interfaces. + + For now we have to accept that there is not yet an ontology of e.g. the + above-mentioned understanding of what interfaces are. + + Pragmatically we thus make the following assumptions: + + * This base class is essentially a template how specific, often referred to + quantities, for two-dimensional crystal defects can be stored. + * Coarse-graining point-like features into a curve or surfaces is an + ill-posed problem. In practice, it has to be accounted for that interfaces + have a finite extent, they are delineated by triple lines and quadruple + junctions. Interfaces are thus connected into a three-dimensional network + of defects. Interfaces can interact or intersect with other defects + (partially or completely, as it is the case for disconnections). + + There are the following general approaches of studying/characterizing: + + * Non-atomically resolved measurements of 2D or 3D sections. + Examples are optical, electron, X-ray, or atom probe microscopy. + * Under specific conditions using electron microscopy, electron tomography + (provided numerical post-processing is applied) as well as with atom probe + microscopy these measurement can resolve structural motifs of or in the + interface plane. + * Atomic-scale-resolved simulations. In this case the most frequently + performed tasks are again post-processing snapshots with grain identification + or graph-based techniques to identify which atoms belong to the regions + with local changes or breakdown of the long-range crystal symmetry. + * Analytical approaches whereby grain boundaries are resolved at the continuum + scale, as surface defects containing other elementary defects (for instance) + in models of disconnection motion), using eventual statistical approaches, + or again atomically resolved treatments. + + From this we can conclude that an NXms_interface_set can primarily be + useful as a wrapper class in which specific details about interfaces + can be stored in an arbitrarily nested manner. + + + A starting point for the discussion. + + diff --git a/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml b/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml new file mode 100644 index 0000000000..302e425335 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml @@ -0,0 +1,32 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class for data on the state of the microstructure at a given time/iteration. + + + + Is this time for a measurement or a simulation. + + + + + + + + + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Iteration or increment counter. + + + diff --git a/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml b/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml new file mode 100644 index 0000000000..5198b90af0 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml @@ -0,0 +1,35 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A collection of spatiotemporal microstructure data. + + + + Is this set describing a measurement or a simulation? + + + + + + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + diff --git a/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml b/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml new file mode 100644 index 0000000000..1a1cf7ed1a --- /dev/null +++ b/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml @@ -0,0 +1,55 @@ + + + + + A container for qualifying an electron optical system. + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + diff --git a/contributed_definitions/nyaml/NXorientation_set.nxdl.xml b/contributed_definitions/nyaml/NXorientation_set.nxdl.xml new file mode 100644 index 0000000000..f3316e8152 --- /dev/null +++ b/contributed_definitions/nyaml/NXorientation_set.nxdl.xml @@ -0,0 +1,94 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the reference space/coordinate system. + + + + + The cardinality of the set, i.e. the number of orientations. + + + + + Number of parameters for the chosen parameterization. + + + + + Details about individual orientations of a set of objects. + + For a more detailed insight into the discussion of parameterizing + orientations in materials science see: + + * https://doi.org/10.1016/j.matchar.2016.04.008 + * https://doi.org/10.1088/0965-0393/23/8/083501 + * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations + * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge + + + + Reference to or definition of a coordinate system with + which the definitions are interpretable. + + + + + + + + + + + A link or reference to the objects whose identifier are referred to in + identifier to resolve which row tuple is the orientation of each object + by reading orientations. + + + + + Integer which specifies which orientation (row of array orientation) matches + to which object.e first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish how a row in orientation describes a specific + object with an explicit identifier that can be queried via inspecting the + list of available objects in objects. + + The rational behind having such a more complicated pattern is that not + all objects referred when following the link in objects may still exists + or are still tracked when the orientation set was characterized. + + This design enables to also use NXorientation_set in situations where + the orientation of objects change as a function in time. + + + + + + + + Parameterized orientations. + + + + + + + diff --git a/contributed_definitions/nyaml/NXpeak.nxdl.xml b/contributed_definitions/nyaml/NXpeak.nxdl.xml new file mode 100644 index 0000000000..4eaffed5de --- /dev/null +++ b/contributed_definitions/nyaml/NXpeak.nxdl.xml @@ -0,0 +1,66 @@ + + + + + + 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/nyaml/NXpid.nxdl.xml b/contributed_definitions/nyaml/NXpid.nxdl.xml new file mode 100644 index 0000000000..7e779c91ff --- /dev/null +++ b/contributed_definitions/nyaml/NXpid.nxdl.xml @@ -0,0 +1,63 @@ + + + + + Contains the settings of a PID controller. + + + + Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. + + For example, a set of sensors could be averaged over before feeding it back into the loop. + + + + + The sensor representing the Process Value used in the feedback loop for the PID. + + In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. + + + + + The actual timeseries data fed back to the PID loop. + + + + + + + The Setpoint(s) used as an input for the PID controller. + + It can also be a link to an NXsensor.value field. + + + + + 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 contribution from the integral term is proportional to both + the magnitude of the error and the duration of the error. + The integral in a PID controller is the sum of the instantaneous + error over time and gives the accumulated offset that should have + been corrected previously. The accumulated error is then + multiplied by the integral gain (Ki) and added to the + controller output. + + + + + The derivative of the process error is calculated by determining + the slope of the error over time and multiplying this rate of + change by the derivative gain K_d. The magnitude of the + contribution of the derivative term to the overall control + action is termed the derivative gain, K_d + + + diff --git a/contributed_definitions/nyaml/NXpulser_apm.nxdl.xml b/contributed_definitions/nyaml/NXpulser_apm.nxdl.xml new file mode 100644 index 0000000000..6097cff7fd --- /dev/null +++ b/contributed_definitions/nyaml/NXpulser_apm.nxdl.xml @@ -0,0 +1,117 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + Direct current voltage between the specimen and the + (local electrode) in the case of local electrode atom + probe (LEAP) instrument. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + Average energy of the laser at peak of each pulse. + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + diff --git a/contributed_definitions/nyaml/NXpump.nxdl.xml b/contributed_definitions/nyaml/NXpump.nxdl.xml new file mode 100644 index 0000000000..17075281a0 --- /dev/null +++ b/contributed_definitions/nyaml/NXpump.nxdl.xml @@ -0,0 +1,19 @@ + + + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + + Principle type of the pump. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXreflectron.nxdl.xml b/contributed_definitions/nyaml/NXreflectron.nxdl.xml new file mode 100644 index 0000000000..0f0a164173 --- /dev/null +++ b/contributed_definitions/nyaml/NXreflectron.nxdl.xml @@ -0,0 +1,31 @@ + + + + + Device for reducing flight time differences of ions in ToF experiments. + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/contributed_definitions/nyaml/NXregistration.nxdl.xml b/contributed_definitions/nyaml/NXregistration.nxdl.xml new file mode 100644 index 0000000000..8ddd155260 --- /dev/null +++ b/contributed_definitions/nyaml/NXregistration.nxdl.xml @@ -0,0 +1,34 @@ + + + + + Describes image registration procedures. + + + + Has the registration been applied? + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + To describe the operations of image registration (combinations of rigid + translations and rotations) + + + + + Description of the procedures employed. + + + diff --git a/contributed_definitions/nyaml/NXscanbox_em.nxdl.xml b/contributed_definitions/nyaml/NXscanbox_em.nxdl.xml new file mode 100644 index 0000000000..60f9b74870 --- /dev/null +++ b/contributed_definitions/nyaml/NXscanbox_em.nxdl.xml @@ -0,0 +1,20 @@ + + + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml b/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml new file mode 100644 index 0000000000..2d6ce487ca --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml @@ -0,0 +1,176 @@ + + + + + + Variables used to set a common size for collected sensor data. + + + + The number of scan points measured in this scan. + + + + + Application definition for a generic scan using sensors. + + In this application definition, times should be specified always together + with an UTC offset. + + + + + + + + + + + + + + + Define the program that was used to generate the results file(s) + with measured data and metadata. + + + + Commercial or otherwise defined given name of the program + (or a link to the instrument software). + + + + Either version with build number, commit hash, or description of an + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when + the experiment was performed. + + + + + Full address (street, street number, ZIP, city, country) + of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + Official telephone number of the user. + + + + + + + Describes an environment setup for the experiment. + + All the setting values of the independently scanned controllers are listed under corresponding + NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each + measurement sensor. + + For example, in a temperature-dependent IV measurement, the temperature and voltage must be + present as independently scanned controllers and the current sensor must also be present with + its readings. + + + + + Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. + + + + + For each point in the scan space, either the nominal setpoint of an independently scanned controller + or a representative average value of a measurement sensor is registered. + + The length of each sensor's data value array stored in this group should be equal to the number of scan points + probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. + This allows the scan to be made in any order as the user describes above in the experiment. We get matching + values simply using the index of the scan point. + + + + + + + + Timestamp for when the values provided in the value field were registered. + + Individual readings can be stored with their timestamps under value_log. This is to timestamp + the nominal setpoint or average reading values listed above in the value field. + + + + + + Free-text describing the data acquisition control: an internal + sweep using the built-in functionality of the controller device, + or a set/wait/read/repeat mechanism. + + + + + + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. + + + + + + + A list of names of NXsensor groups used as independently scanned controllers. + + + + + A list of names of NXsensor groups used as measurement sensors. + + + + + + + + + + A scan specific representation of the measured signals as a function of the independently controlled environment settings. + Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. + + + + diff --git a/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml b/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml new file mode 100644 index 0000000000..71d1fcf7b0 --- /dev/null +++ b/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of slip systems. + + + + + Base class for describing a set of crystallographic slip systems. + + + + + + + + + + + + + + + Array of Miller indices which describe the crystallographic plane. + + + + + + + + + Array of Miller indices which describe the crystallographic direction. + + + + + + + + + For each slip system a marker whether the specified Miller indices + refer to the specific slip system or the set of crystallographic equivalent + slip systems of the respective family of slip systems. + + + + + + diff --git a/contributed_definitions/nyaml/NXspatial_filter.nxdl.xml b/contributed_definitions/nyaml/NXspatial_filter.nxdl.xml new file mode 100644 index 0000000000..4245459eab --- /dev/null +++ b/contributed_definitions/nyaml/NXspatial_filter.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of ellipsoids. + + + + + Number of hexahedra. + + + + + Number of cylinders. + + + + + Spatial filter to filter entries within a region-of-interest based on their position. + + + + Qualitative statement which specifies which spatial filtering with respective + geometric primitives or bitmask is used. These settings are possible: + + * entire_dataset, no filter is applied, the entire dataset is used. + * union_of_primitives, a filter with (rotated) geometric primitives. + All ions in or on the surface of the primitives are considered + while all other ions are ignored. + * bitmasked_points, a boolean array whose bits encode with 1 + which ions should be included. Those ions whose bit is set to 0 + will be excluded. Users of python can use the bitfield operations + of the numpy package to define such bitfields. + + Conditions: + In the case that windowing_method is entire_dataset all entries are processed. + In the case that windowing_method is union_of_primitives, + it is possible to specify none or all types of primitives + (ellipsoids, cylinder, hexahedra). If no primitives are specified + the filter falls back to entire_dataset. + In the case that windowing_method is bitmask, the bitmask has to be defined; + otherwise the filter falls back to entire dataset. + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml new file mode 100644 index 0000000000..4952128e6e --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml @@ -0,0 +1,155 @@ + + + + + + + Number of pixel per EELS mapping in the slow direction. + + + + + Number of pixel per EELS mapping in the fast direction. + + + + + Number of electron energy loss bins. + + + + + Container for reporting a set of electron energy loss (EELS) spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + + The latter pattern is the most frequently used. + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + + + Details how EELS spectra were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_eels were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the EELS spectra stack and summary. + + + + Program 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. + + + + + + + Collected EELS spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + + EELS counts + + + + + Pixel center of mass position y-coordinates. + + + + + + + Label for the y axis. + + + + + + Pixel center of mass position x-coordinates. + + + + + + + Label for the x axis. + + + + + + Pixel center of mass energy loss bins. + + + + + + + Label for the energy loss axis. + + + + + + + Accumulated EELS spectrum over all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + Counts for specific energy losses. + + + + + + + + Counts electrons with an energy loss within binned range. + + + + + Pixel center of mass energy loss bins. + + + + + + + Energy loss + + + + + diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml new file mode 100644 index 0000000000..95ddca359a --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml @@ -0,0 +1,269 @@ + + + + + + + Number of pixel per X-ray mapping in the slow direction + + + + + Number of pixel per X-ray mapping in the fast direction + + + + + Number of X-ray photon energy (bins) + + + + + Number of identified elements + + + + + Number of peaks + + + + + Container for reporting a set of energy-dispersive X-ray spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ + should be used. + + + + Details how X-ray spectra were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_xray were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the X-ray spectra stack and summary. + + + + Program 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. + + + + + + + Collected X-ray spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + + X-ray photon counts + + + + + + + + + Label for the y axis + + + + + + + + + + Label for the x axis + + + + + + + + + + X-ray energy + + + + + + + Accumulated X-ray spectrum over all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + X-ray photon counts + + + + + + + + + X-ray energy + + + + + + + Details about computational steps how peaks were indexed as elements. + + + + Given name of the program that was used to perform this computation. + + + + Program 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. + + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are group with the same peak. + + + + + + + List of the names of identified elements. + + + + + + + + Individual element-specific EDX/EDS/EDXS/SXES mapping + + A composition map is an image whose intensities for each pixel are the + accumulated X-ray quanta *under the curve(s)* of a set of peaks. + + + + Given name of the program that was used to perform this computation. + + + + Program 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. + + + + + + A list of strings of named instances of NXpeak from indexing + whose X-ray quanta where accumulated for each pixel. + + + + + + + + Human-readable, given name to the image. + + + + + Individual element-specific maps. Individual maps should + each be a group and be named according to element_names. + + + + + + + + + + Accumulated X-ray photon counts + + + + + + + + + Label for the y axis + + + + + + + + + + Label for the x axis + + + + + + + diff --git a/contributed_definitions/nyaml/NXspindispersion.nxdl.xml b/contributed_definitions/nyaml/NXspindispersion.nxdl.xml new file mode 100644 index 0000000000..71668a6480 --- /dev/null +++ b/contributed_definitions/nyaml/NXspindispersion.nxdl.xml @@ -0,0 +1,76 @@ + + + + + Subclass of NXelectronanalyser to describe the spin filters in photoemission + experiments. + + + + Type of spin detector, VLEED, SPLEED, Mott, etc. + + + + + Figure of merit of the spin detector + + + + + Effective Shermann function, calibrated spin selectivity factor + + + + + Energy of the spin-selective scattering + + + + + Angle of the spin-selective scattering + + + + + Name of the target + + + + + Preparation procedure of the spin target + + + + + Date of last preparation of the spin target + + + + + 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 deflector 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. + + + + + Deflectors in the spin dispersive section + + + + + Individual lenses in the spin dispersive section + + + diff --git a/contributed_definitions/nyaml/NXstage_lab.nxdl.xml b/contributed_definitions/nyaml/NXstage_lab.nxdl.xml new file mode 100644 index 0000000000..c34a57e790 --- /dev/null +++ b/contributed_definitions/nyaml/NXstage_lab.nxdl.xml @@ -0,0 +1,137 @@ + + + + + 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. + + + + diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml b/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml new file mode 100644 index 0000000000..7613a30b4e --- /dev/null +++ b/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml @@ -0,0 +1,26 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Settings of a filter to sample entries based on their value. + + + + Triplet of the minimum, increment, and maximum value which will + be included in the analysis. The increment controls which n-th entry to take. + + Take as an example a dataset with 100 entries (their indices start at zero) + and the filter set to 0, 1, 99. This will process each entry. + 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third + entry beginning from entry 90 up to 99. + + + + + + diff --git a/contributed_definitions/nyaml/NXtransmission.nxdl.xml b/contributed_definitions/nyaml/NXtransmission.nxdl.xml new file mode 100644 index 0000000000..23898fe9e7 --- /dev/null +++ b/contributed_definitions/nyaml/NXtransmission.nxdl.xml @@ -0,0 +1,327 @@ + + + + + + Variables used throughout the experiment + + + + Number of wavelength points + + + + + Number of scans + + + + + Application definition for transmission experiments + + + + This application definition + + + + An application definition for transmission. + + + + Version number to identify which definition of this application definition was + used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant to the + application definition. + + + + + + + + + Start time of the experiment. + + + + + Unique identifier of the experiment, such as a (globally persistent) + unique identifier. + + * The identifier is usually defined by the facility or principle + investigator. + * The identifier enables to link experiments to e.g. proposals. + + + + + An optional free-text description of the experiment. However, details of the + experiment should be defined in the specific fields of this application + definition rather than in this experiment description. + + + + + + Commercial or otherwise defined given name to the program that was + used to generate the result file(s) with measured data and metadata. + + + + + Version number of the program that was used to generate the result + file(s) with measured data and metadata. + + + + + Website of the software + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Street address of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). + + + + + Telephone number of the user. + + + + + + + Manufacturer of the instrument. + + + + + Common beam mask to shape the incident beam + + + + The height of the common beam in percentage of the beam + + + + + + If true, the incident beam is depolarized. + + + + + Polarizer value inside the beam path + + + + + Attenuator in the reference beam + + + + + + Attenuator in the sample beam + + + + + + + Wavelength value(s) used for the measurement. + An array of 1 or more elements. Length defines N_wavelenghts + + + + + + + + Overall spectral resolution of this spectrometer. + If several gratings are employed the spectral resoultion + should rather be specified for each grating inside the + NXgrating group of this spectrometer. + + + + + Diffraction grating, as could be used in a monochromator. + If two or more gratings were used, define the angular + dispersion and the wavelength range (min/max wavelength) + for each grating and make sure that the wavelength ranges + do not overlap. The dispersion should be defined for the + entire wavelength range of the experiment. + + + + Dispersion of the grating in nm/mm used. + + + + + The blaze wavelength of the grating used. + + + + + Overall spectral resolution of the instrument + when this grating is used. + + + + + Wavelength range in which this grating was used + + + + + + + + + + + Wavelength range in which this detector was used + + + + + + + + Detector type + + + + + + + + + + Response time of the detector + + + + + Detector gain + + + + + Slit setting used for measurement with this detector + + + + + + + + + + + + An array of relative scan start time points. + + + + + + + + Resulting data from the measurement. + The length of the 2nd dimension is + the number of time points. + If it has length one the time_points + may be empty. + + + + + + + + + The lamp used for illumination + + + + The type of lamp, e.g. halogen, D2 etc. + + + + + + + + + The spectrum of the lamp used + + + + + + + + Wavelength range in which the lamp was used + + + + + + + + + + Properties of the sample measured + + + + + + A default view of the data emitted intensity vs. wavelength. + From measured_data plot intensity and wavelength. + + + + We recommend to use wavelength as a default attribute, but it can be + replaced by any suitable parameter along the X-axis. + + + + + From 2cc9d98a09776bd77ae3b05fe12afac911140ff8 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Wed, 8 Feb 2023 18:37:18 +0100 Subject: [PATCH 091/203] NXdispersion refinements (#19) * Uses NXcite for references * Fixes types in appdef and adds atom_types * Adds plot NXdata group to dispersions * Copying yaml files from data-modeling main branch. * Adds yml files --------- Co-authored-by: RubelMozumder --- .../NXdispersion_function.nxdl.xml | 2 +- .../NXdispersive_material.nxdl.xml | 60 ++++--- .../nyaml/NXdispersion.yml | 11 ++ .../nyaml/NXdispersion_function.yml | 45 +++++ .../nyaml/NXdispersion_repeated_parameter.yml | 30 ++++ .../nyaml/NXdispersion_single_parameter.yml | 14 ++ .../nyaml/NXdispersion_table.yml | 48 +++++ .../nyaml/NXdispersive_material.yml | 164 ++++++++++++++++++ .../nyaml/NXellipsometry.yaml | 11 +- contributed_definitions/nyaml/NXmpes.yml | 7 + 10 files changed, 360 insertions(+), 32 deletions(-) create mode 100644 contributed_definitions/nyaml/NXdispersion.yml create mode 100644 contributed_definitions/nyaml/NXdispersion_function.yml create mode 100644 contributed_definitions/nyaml/NXdispersion_repeated_parameter.yml create mode 100644 contributed_definitions/nyaml/NXdispersion_single_parameter.yml create mode 100644 contributed_definitions/nyaml/NXdispersion_table.yml create mode 100644 contributed_definitions/nyaml/NXdispersive_material.yml diff --git a/contributed_definitions/NXdispersion_function.nxdl.xml b/contributed_definitions/NXdispersion_function.nxdl.xml index 15ff513241..5a0bc96c7d 100644 --- a/contributed_definitions/NXdispersion_function.nxdl.xml +++ b/contributed_definitions/NXdispersion_function.nxdl.xml @@ -62,7 +62,7 @@ - + diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index 2dd9646ce4..a4ba555b93 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -27,6 +27,14 @@ + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The colloquial name of the material, e.g. graphite or diamond for carbon. @@ -66,16 +74,15 @@ - - - This fields holds a literature reference for this material. - - - - - This field holds the respective doi for the literature references. - - + + + + A text description of this reference, e.g. + `E. Example et al, The mighty example, An example journal 50 (2023), 100` + + + + The dispersion along the optical axis of the material. @@ -92,9 +99,9 @@ - - - + + + @@ -105,13 +112,14 @@ - + - + + @@ -127,9 +135,9 @@ - - - + + + @@ -140,13 +148,14 @@ - + - + + @@ -163,9 +172,9 @@ - - - + + + @@ -176,13 +185,14 @@ - + - + + diff --git a/contributed_definitions/nyaml/NXdispersion.yml b/contributed_definitions/nyaml/NXdispersion.yml new file mode 100644 index 0000000000..963d7b12b3 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion.yml @@ -0,0 +1,11 @@ +category: base +doc: | + A dispersion denoting a sum of different dispersions. + All NXdispersion_table and NXdispersion_function groups will be added together + to form a single dispersion. +NXdispersion: + model_name(NX_CHAR): + doc: | + The name of the composite model. + (NXdispersion_table): + (NXdispersion_function): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_function.yml b/contributed_definitions/nyaml/NXdispersion_function.yml new file mode 100644 index 0000000000..58a572c927 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_function.yml @@ -0,0 +1,45 @@ +category: base +doc: | + This describes a dispersion function for a material or layer +symbols: + n_repetitions: | + The number of repetitions for the repeated parameters +NXdispersion_function: + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + formula(NX_CHAR): + doc: | + This should be a python parsable function. + Here we should provide which keywords are available + and a BNF of valid grammar. + convention(NX_CHAR): + doc: | + The sign convention being used (n + or - ik) + enumeration: ['n + ik', 'n - ik'] + energy_identifier(NX_CHAR): + doc: | + The identifier used to represent energy + in the formula. It is recommended to use `E`. + unit: NX_ENERGY + wavelength_identifier(NX_CHAR): + doc: | + The identifier useed to represent wavelength + in the formula. It is recommended to use `lambda`. + unit: NX_LENGTH + representation(NX_CHAR): + doc: | + Which representation does the formula evaluate to. + This may either be n for refractive index or eps for dielectric function. + The appropriate token is then to be used inside the formula. + enumeration: [n, eps] + (NXdispersion_single_parameter): + (NXdispersion_repeated_parameter): + parameter_units: + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + values(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, n_repetitions]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yml b/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yml new file mode 100644 index 0000000000..80b6e55178 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yml @@ -0,0 +1,30 @@ +category: base +doc: | + A repeated parameter for a dispersion function +symbols: + n_repetitions: | + The number of parameter repetitions +NXdispersion_repeated_parameter: + name(NX_CHAR): + doc: | + The name of the parameter + description(NX_CHAR): + doc: | + A description of what this parameter represents + parameter_units(NX_CHAR): + doc: | + A unit array associating a unit with each parameter. + The first element should be equal to values/@unit. + The values should be SI interpretable standard units + with common prefixes (e.g. mikro, nano etc.) or their + short-hand notation (e.g. nm, mm, kHz etc.). + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + values(NX_NUMBER): + doc: | + The value of the parameter + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_repetitions]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_single_parameter.yml b/contributed_definitions/nyaml/NXdispersion_single_parameter.yml new file mode 100644 index 0000000000..571edf0464 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_single_parameter.yml @@ -0,0 +1,14 @@ +category: base +doc: | + A single parameter for a dispersion function +NXdispersion_single_parameter: + name(NX_CHAR): + doc: | + The name of the parameter + description(NX_CHAR): + doc: | + A description of what this parameter represents + value(NX_NUMBER): + doc: | + The value of the parameter + unit: NX_ANY \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_table.yml b/contributed_definitions/nyaml/NXdispersion_table.yml new file mode 100644 index 0000000000..0c691a5fa6 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_table.yml @@ -0,0 +1,48 @@ +category: base +doc: | + A dispersion table denoting energy, dielectric function tabulated values. +symbols: + doc: | + The symbols in this schema to denote the dimensions + n_points: | + The number of energy and dielectric function points +NXdispersion_table: + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + convention(NX_CHAR): + doc: | + The sign convention being used (n + or - ik) + enumeration: ['n + ik', 'n - ik'] + wavelength(NX_NUMBER): + doc: | + The wavelength array of the tabulated dataset. + This is essentially a duplicate of the energy field. + There should be one or both of them present. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_points]] + energy(NX_NUMBER): + doc: | + The energy array of the tabulated dataset. + This is essentially a duplicate of the wavelength field. + There should be one or both of them present. + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_points]] + refractive_index(NX_COMPLEX): + doc: | + The refractive index array of the tabulated dataset. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_points]] + dielectric_function(NX_COMPLEX): + doc: | + The dielectric function of the tabulated dataset. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_points]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersive_material.yml b/contributed_definitions/nyaml/NXdispersive_material.yml new file mode 100644 index 0000000000..c08ecbdb3d --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersive_material.yml @@ -0,0 +1,164 @@ +category: application +doc: | + NXdispersion +NXdispersive_material: + (NXentry): + definition: + doc: "An application definition for a dispersive material." + \@version: + doc: "Version number to identify which definition of this application + definition was used for this entry/data." + \@url: + doc: "URL where to find further material (documentation, examples) + relevant to the application definition" + enumeration: [NXdispersive_material] + sample(NXsample): + chemical_formula(NX_CHAR): + atom_types(NX_CHAR): + exists: optional + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + colloquial_name(NX_CHAR): + exists: optional + doc: | + The colloquial name of the material, e.g. graphite or diamond for carbon. + material_phase(NX_CHAR): + exists: optional + doc: | + The phase of the material + enumeration: [gas, liquid, solid, other] + material_phase_comment(NX_CHAR): + exists: optional + doc: | + Additional information about the phase if the + material phase is other. + additional_phase_information(NX_CHAR): + exists: recommended + doc: | + This field may be used to denote additional phase information, + such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or + if a measurement was done on a thin film or bulk material. + dispersion_type(NX_CHAR): + doc: | + Denotes whether the dispersion is calculated or derived from an experiment + enumeration: ["measured", "simulated"] + REFERENCES(NXcite): + exists: recommended + text: + doc: | + A text description of this reference, e.g. + `E. Example et al, The mighty example, An example journal 50 (2023), 100` + doi: + dispersion_x(NXdispersion): + doc: | + The dispersion along the optical axis of the material. + This should be the only dispersion available for isotropic materials. + For uniaxial materials this denotes the ordinary axis. + For biaxial materials this denotes the x axis or epsilon 11 tensor element + of the diagionalized permittivity tensor. + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + (NXdispersion_table): + exists: recommended + model_name: + convention: + wavelength(NX_NUMBER): + dielectric_function(NX_COMPLEX): + exists: recommended + refractive_index(NX_COMPLEX): + exists: recommended + (NXdispersion_function): + exists: recommended + model_name: + formula: + convention: + energy_identifier: + exists: recommended + wavelength_identifier: + exists: recommended + representation: + (NXdispersion_single_parameter): + name: + value(NX_NUMBER): + (NXdispersion_repeated_parameter): + name: + values(NX_NUMBER): + plot(NXdata): + exists: recommended + dispersion_y(NXdispersion): + doc: | + This should only be filled for biaxial materials. + It denotes the epsilon 22 direction of the diagionalized + permittivity tensor. + exists: optional + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + (NXdispersion_table): + exists: recommended + model_name: + convention: + wavelength(NX_NUMBER): + dielectric_function(NX_COMPLEX): + exists: recommended + refractive_index(NX_COMPLEX): + exists: recommended + (NXdispersion_function): + exists: recommended + model_name: + formula: + convention: + energy_identifier: + exists: recommended + wavelength_identifier: + exists: recommended + representation: + (NXdispersion_single_parameter): + name: + value(NX_NUMBER): + (NXdispersion_repeated_parameter): + name: + values(NX_NUMBER): + plot(NXdata): + exists: recommended + dispersion_z(NXdispersion): + doc: | + This should only be filled for uniaxial or biaxial materials. + For uniaxial materials this denotes the extraordinary axis. + For biaxial materials this denotes the epsilon 33 tensor element + of the diagionalized perimittivty tensor. + exists: optional + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + (NXdispersion_table): + exists: recommended + model_name: + convention: + wavelength(NX_NUMBER): + dielectric_function(NX_COMPLEX): + exists: recommended + refractive_index(NX_COMPLEX): + exists: recommended + (NXdispersion_function): + exists: recommended + model_name: + formula: + convention: + energy_identifier: + exists: recommended + wavelength_identifier: + exists: recommended + representation: + (NXdispersion_single_parameter): + name: + value(NX_NUMBER): + (NXdispersion_repeated_parameter): + name: + values(NX_NUMBER): + plot(NXdata): + exists: recommended diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index df6070b4f8..68a52830e3 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -535,12 +535,11 @@ NXellipsometry: pressure etc.), along with the data (data type, wavelength array, measured data)." atom_types: - doc: "Use Hill's system for listing elements of the periodic table - which are inside or attached to the surface of the specimen - and thus relevant from a scientific point. The purpose of this - field is to allow material databases to parse the relevant - elements without having to interpret the sample history or other - fields." + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. sample_name: doc: "Descriptive name of the sample" diff --git a/contributed_definitions/nyaml/NXmpes.yml b/contributed_definitions/nyaml/NXmpes.yml index 73802accee..6b82c6233f 100644 --- a/contributed_definitions/nyaml/NXmpes.yml +++ b/contributed_definitions/nyaml/NXmpes.yml @@ -192,6 +192,13 @@ NXmpes: Ideally, a full report of the previous operations, in any format (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." + atom_types: + exists: recommended + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. preparation_date(NX_DATE_TIME): exists: recommended doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." From 8c7e16968b5a91fe482b45735f71fbfe9916fb71 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Fri, 10 Feb 2023 10:03:29 +0100 Subject: [PATCH 092/203] Consolidated and updated appdefs including prototypes for EBSD --- contributed_definitions/nyaml/NXapm.yaml | 272 ++- .../NXapm_paraprobe_config_clusterer.yaml | 351 ++-- .../NXapm_paraprobe_config_intersector.yaml | 471 ++--- .../NXapm_paraprobe_config_nanochem.yaml | 4 + .../nyaml/NXapm_paraprobe_config_ranger.yaml | 9 +- .../NXapm_paraprobe_config_selector.yaml | 90 + .../NXapm_paraprobe_config_spatstat.yaml | 217 ++- .../NXapm_paraprobe_config_surfacer.yaml | 31 +- .../NXapm_paraprobe_config_tessellator.yaml | 2 +- .../NXapm_paraprobe_results_clusterer.yaml | 429 ++++ .../NXapm_paraprobe_results_distancer.yaml | 320 +++ .../NXapm_paraprobe_results_intersector.yaml | 314 +++ .../NXapm_paraprobe_results_nanochem.yaml | 1719 +++++++++++++++++ .../nyaml/NXapm_paraprobe_results_ranger.yaml | 148 +- .../NXapm_paraprobe_results_selector.yaml | 233 +++ .../NXapm_paraprobe_results_spatstat.yaml | 290 +++ .../NXapm_paraprobe_results_surfacer.yaml | 405 ++++ .../NXapm_paraprobe_results_tessellator.yaml | 591 ++++++ .../NXapm_paraprobe_results_transcoder.yaml | 33 +- contributed_definitions/nyaml/NXem.yaml | 382 +++- contributed_definitions/nyaml/NXem_ebsd.yaml | 984 ++++++++++ .../nyaml/NXem_ebsd_conventions.yaml | 270 +++ .../NXem_ebsd_crystal_structure_model.yaml | 150 ++ .../nyaml/NXimage_set_em.yaml | 69 + .../nyaml/NXimage_set_em_adf.yaml | 28 +- .../nyaml/NXimage_set_em_kikuchi.yaml | 139 ++ contributed_definitions/nyaml/NXion.yaml | 9 +- .../nyaml/NXspectrum_set_em_eels.yaml | 33 +- .../nyaml/NXspectrum_set_em_xray.yaml | 72 +- 29 files changed, 7305 insertions(+), 760 deletions(-) create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml create mode 100644 contributed_definitions/nyaml/NXem_ebsd.yaml create mode 100644 contributed_definitions/nyaml/NXem_ebsd_conventions.yaml create mode 100644 contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 3fcc548c45..65433f77a2 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -9,13 +9,15 @@ symbols: n_ivec_max: | Maximum number of allowed atoms per (molecular) ion (fragment). Needs to match maximum_number_of_atoms_per_molecular_ion. - n_ranges: Number of mass-to-charge-state-ratio intervals mapped on this ion type. + n_ranges: | + Number of mass-to-charge-state-ratio intervals of this ion type. n_x: Number of bins in the x direction. n_y: Number of bins in the y direction. n_z: Number of bins in the z direction. n_bins: Number of bins. NXapm: (NXentry): + exists: [min, 1, max, infty] \@version: doc: | An at least as strong as SHA256 hashvalue of the file @@ -39,8 +41,8 @@ NXapm: Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. start_time(NX_DATE_TIME): exists: recommended doc: | @@ -49,7 +51,7 @@ NXapm: If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant - - this start time field should be used. + - this start_time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping @@ -134,7 +136,7 @@ NXapm: 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. - run_number(NX_CHAR): + run_number: doc: | Neither the specimen_name nor the experiment_identifier but the identifier through which the experiment is referred to in the control software. @@ -220,7 +222,8 @@ NXapm: exists: recommended doc: | Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform orcid_platform: exists: recommended doc: | @@ -241,7 +244,8 @@ NXapm: social_media_name: exists: optional doc: | - Account name that is associated with the user in social media platforms. + Account name that is associated with the user + in social media platforms. social_media_platform: exists: optional doc: | @@ -303,12 +307,14 @@ NXapm: better be placed in resources which describe the sample_history. short_title: exists: optional - doc: Possibility to give an abbreviation of the specimen name field. + doc: | + Possibility to give an abbreviation of the specimen name field. atom_types: doc: | - Use Hill's system for listing elements of the periodic table which - are inside or attached to the surface of the specimen, and thus - relevant from a scientific point of view. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret @@ -319,7 +325,8 @@ NXapm: Discouraged free-text field in case properly designed records for the sample_history are not available. # NEW ISSUE: error model - # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + # NEW ISSUE: use Andrea and MarkusK groups for + # describing the geometry of the sample (NXdata): exists: optional doc: | @@ -374,7 +381,7 @@ NXapm: the positive z-axes of either coordinate systems is oriented. Consult the work of A. J. Breen and B. Gault and team for further details. - (NXtransformations): + TRANSFORMATIONS(NXtransformations): exists: [min, 0, max, infty] # NEW ISSUE: add Breen's Ultramicroscopy paper on atom probe crystallography # in what follows each component of the instrument might be equipped with an NXmonitor @@ -408,6 +415,11 @@ NXapm: Location of the lab or place where the instrument is installed. Using GEOREF is preferred. (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -419,7 +431,8 @@ NXapm: THIS DOCSTRING NEEDS CLARIFICATION. unit: NX_LENGTH - # NEW ISSUE: discussion depends on the type of instrument, straight flight path, curved + # NEW ISSUE: discussion depends on the type of instrument, + # straight flight path, curved field_of_view(NX_FLOAT): exists: recommended doc: | @@ -428,28 +441,19 @@ NXapm: cannot be measured completely because ions may launch but not be detected or hit elsewhere in the analysis_chamber. unit: NX_LENGTH - analysis_chamber(NXchamber): - name: - exists: optional - (NXfabrication): - exists: optional - identifier: - exists: recommended - capabilities: - exists: optional - description: - exists: optional - pressure(NX_FLOAT): - doc: Average pressure in the analysis chamber. - unit: NX_PRESSURE (NXreflectron): # check if doc string gets carried over doc: Device for reducing flight time differences of ions in ToF experiments. applied(NX_BOOLEAN): - doc: Is a reflectron installed and was it used? + doc: | + Is a reflectron installed and was it used? name: exists: optional (NXfabrication): exists: optional + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -505,7 +509,9 @@ NXapm: doc: Given brand or model name by the manufacturer. serial_number: exists: recommended - doc: Given hardware name/serial number or hash identifier issued by the manufacturer. + doc: | + Given hardware name/serial number or hash identifier + issued by the manufacturer. manufacturer_name: exists: recommended doc: Given name of the manufacturer. @@ -530,14 +536,14 @@ NXapm: standing_voltage(NX_FLOAT): exists: recommended laser_gun(NXsource): - exists: recommended + exists: [min, 0, max, 2] # INVIZO 6000 instrument have two symmetric lasers! so for these # laser_gun and laser_beam exists: [min, 0, max, 2] doc: | - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. If pulse_mode is set to laser or laser_and_voltage (e.g. for LEAP6000-type instruments) having the group/section laser_gun is required and the following of its fields have to be filled: @@ -549,6 +555,10 @@ NXapm: name: (NXfabrication): exists: optional + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -575,12 +585,15 @@ NXapm: unit: NX_TEMPERATURE # NEW ISSUE: begin add and support I/O of further details - load_lock_chamber(NXchamber): - exists: optional + analysis_chamber(NXchamber): name: exists: optional (NXfabrication): exists: optional + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -588,7 +601,8 @@ NXapm: description: exists: optional pressure(NX_FLOAT): - doc: Average pressure in the load_lock_chamber. + doc: | + Average pressure in the analysis chamber. unit: NX_PRESSURE buffer_chamber(NXchamber): exists: optional @@ -596,6 +610,30 @@ NXapm: exists: optional (NXfabrication): exists: optional + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + description: + exists: optional + pressure(NX_FLOAT): + doc: | + Average pressure in the buffer chamber. + unit: NX_PRESSURE + load_lock_chamber(NXchamber): + exists: optional + name: + exists: optional + (NXfabrication): + exists: optional + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -603,7 +641,8 @@ NXapm: description: exists: optional pressure(NX_FLOAT): - doc: Average pressure in the buffer chamber. + doc: | + Average pressure in the load_lock_chamber. unit: NX_PRESSURE getter_pump(NXpump): exists: optional @@ -611,6 +650,10 @@ NXapm: exists: recommended (NXfabrication): exists: optional + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -621,6 +664,10 @@ NXapm: exists: recommended (NXfabrication): exists: optional + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -631,6 +678,10 @@ NXapm: exists: recommended (NXfabrication): exists: optional + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -744,7 +795,7 @@ NXapm: ion_impact_positions(NXprocess): exists: recommended - doc: | + doc: | Details about where ions hit the ion_detector and data processing steps related to analog-to-digital conversion of detector signals into ion hit positions. For AMETEK LEAP instruments this processing @@ -772,7 +823,8 @@ NXapm: doc: | Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - # NEW ISSUE: discuss with Oxcart developers which modifications might be necessary here. + # NEW ISSUE: discuss with Oxcart developers which + # modifications might be necessary here. unit: NX_TIME dimensions: rank: 3 @@ -828,25 +880,27 @@ NXapm: rank: 1 dim: [[1, n_ions]] unit: NX_UNITLESS - hit_multiplicity(NX_UINT): - exists: recommended - # NEW ISSUE: further discussions with members of the APM community is required to clarify this field and what it means - doc: Hit multiplicity. + pulse_id(NX_UINT): + # NEW ISSUE: I feel the name is misleading, the quantity is + # named like this de facto only because thats the jargon + # term with epos files. + exists: optional + doc: | + Number of pulses since the start of the atom probe + run/evaporation sequence. dimensions: rank: 1 dim: [[1, n_ions]] unit: NX_UNITLESS - pulse_id(NX_UINT): - # NEW ISSUE: I feel the name is misleading, the quantity is - # named like this de facto only because thats the jargon term with epos files. - exists: optional + hit_multiplicity(NX_UINT): + # NEW ISSUE: further discussions with members of the APM community + # is required to clarify this field and what it means doc: | - Number of pulses since the start of the atom probe run/evaporation sequence. + Hit multiplicity. dimensions: rank: 1 dim: [[1, n_ions]] unit: NX_UNITLESS - ion_filtering(NXprocess): exists: recommended doc: | @@ -869,7 +923,9 @@ NXapm: configured in such a manner that the result file is ideally recreatable yielding the same results. evaporation_id_included(NX_BOOLEAN): # NXcs_filter_boolean_mask - doc: Bitmask which is set to true if the ion is considered and false otherwise. + doc: | + Bitmask which is set to true if the ion + is considered and false otherwise. dimensions: rank: 1 dim: [[1, n_ions]] # then only a group @@ -893,7 +949,10 @@ NXapm: 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. - # NEW ISSUE: realistic is that currently scientists can pull always a calibrated time-of-flight but not necessarily unprocessed timing data from the detector (unless individuals built the instrument). Relevant for ranging are the calibrated data, thats why only these (as an intermediate/compromise solution) are required in this version of the application definition + # NEW ISSUE: realistic is that currently scientists can pull always a calibrated time-of-flight + # but not necessarily unprocessed timing data from the detector (unless individuals built the instrument). + # Relevant for ranging are the calibrated data, thats why only these + # (as an intermediate/compromise solution) are required in this version of the application definition raw_tof(NX_FLOAT): exists: recommended doc: | @@ -904,7 +963,8 @@ NXapm: rank: 1 dim: [[1, n_ions]] calibrated_tof(NX_FLOAT): - # NEW ISSUE: which type of calibrations are applied is usually a modified sqrt tof to m/q mapping the exact parameter of which are for LEAP instruments not immediately accessible. + # NEW ISSUE: which type of calibrations are applied is usually a modified + # sqrt tof to m/q mapping the exact parameter of which are for LEAP instruments not immediately accessible. doc: | Calibrated time-of-flight. unit: NX_TIME @@ -935,7 +995,9 @@ NXapm: will see displayed in e.g. APSuite while they execute the voltage-and-bowl correction as a part of the reconstruction pipeline in APSuite. - # NEW ISSUE: should be recommended as otherwise one cannot ensure that numerically the same voltage-and-bowl correction results are obtained (without knowning the parameters...) + # NEW ISSUE: should be recommended as otherwise one cannot ensure that + # numerically the same voltage-and-bowl correction results are obtained + # (without knowning the parameters...) mass_to_charge_conversion(NXprocess): exists: recommended @@ -993,8 +1055,10 @@ NXapm: Qualitative statement about which reconstruction protocol was used. enumeration: [bas, geiser, gault, cameca, other] parameter: - # NEW ISSUE: the status here should be promoted to required but currently one needs to manually extract the reconstruction parameters - # NEW ISSUE: for instance from commercial software, here a better strategy is needed how to document the reconstruction parameter. + # NEW ISSUE: the status here should be promoted to required but currently + # one needs to manually extract the reconstruction parameters + # NEW ISSUE: for instance from commercial software, here a better strategy + # is needed how to document the reconstruction parameter. doc: | Different reconstruction protocols exist. Although these approaches are qualitatively similar, each protocol uses different parameters @@ -1050,34 +1114,41 @@ NXapm: recreatable yielding the same results. (NXdata): doc: | - A default three-dimensional histogram of the total number of ions in each bin. - # \@signal: - # doc: Which is the dependent signal to plot, here the counts. - # \@axes: - # doc: Which axes are plotted, here the three principal coordinate directions. - counts(NX_NUMBER): + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): doc: Array of counts for each bin. unit: NX_UNITLESS dimensions: rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] #why do indices start at 0 here and not 1 ? - zpos(NX_NUMBER): - doc: Bin positions along the z axis. + dim: [[1, n_z], [2, n_y], [3, n_x]] + axis_z(NX_FLOAT): + doc: Bin center of mass position along the z axis. unit: NX_LENGTH - ypos(NX_NUMBER): - doc: Bin positions along the y axis. + dimensions: + rank: 1 + dim: [[1, n_z]] + \@long_name: + axis_y(NX_FLOAT): + doc: Bin center of mass position along the y axis. unit: NX_LENGTH - xpos(NX_NUMBER): - doc: Bin positions along the x axis. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + axis_x(NX_FLOAT): + doc: Bin center of mass position along the x axis. unit: NX_LENGTH - # \@xpos_indices: - # doc: Bin edge end along x. - # \@ypos_indices: - # doc: Bin edge end along y. - # \@zpos_indices: - # doc: Bin edge end along z. - \@long_name: - doc: Naive point cloud density map. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: ranging(NXprocess): exists: recommended @@ -1103,7 +1174,7 @@ NXapm: 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. - number_of_ion_types(NX_POSINT): + number_of_ion_types(NX_UINT): doc: | How many ion types are distinguished. If no ranging was performed each ion is of the special unknown type. @@ -1137,7 +1208,8 @@ NXapm: configured in such a manner that the result file is ideally recreatable yielding the same results. range_minmax(NX_FLOAT): - doc: Smallest and largest mass-to-charge-state ratio value. + doc: | + Smallest and largest mass-to-charge-state ratio value. unit: NX_ANY # \@units: Da # NEW ISSUE: NX_ATOMIC_MASS_UNIT use Tommasso scheme here Da @@ -1145,7 +1217,8 @@ NXapm: rank: 1 dim: [[1, 2]] range_increment(NX_FLOAT): - doc: Binning width of the mass-to-charge-state ratio values. + doc: | + Binning width of the mass-to-charge-state ratio values. unit: NX_ANY # \@units: Da # NEW ISSUE: unit must match with range, is Da @@ -1153,24 +1226,26 @@ NXapm: doc: | A default histogram aka mass spectrum of the mass-to-charge-state ratio values. - # \@signal: - # doc: Which is the dependent signal to plot. - # \@axes: - # doc: Which axes are plotted, here counts over bins. - counts(NX_NUMBER): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): doc: Array of counts for each bin. unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_bins]] - bin_ends(NX_NUMBER): - doc: End of value for each mass-to-charge-state ratio bin. + \@long_name: + axis_mass_to_charge(NX_FLOAT): + doc: | + Right boundary of each mass-to-charge-state ratio value bin. unit: NX_ANY - # # \@units: Da - # \@bin_ends_indices: - # doc: Label of the mass-to-charge-state ratio bin axis. - \@long_name: - doc: Mass-to-charge-state histogram. + dimensions: + rank: 1 + dim: [[1, n_bins]] + \@long_name: background_quantification(NXprocess): exists: recommended @@ -1217,6 +1292,8 @@ NXapm: label: exists: recommended peak_model: + doc: | + THIS DOCSTRING NEEDS CLARIFICATION. peak_identification(NXprocess): exists: recommended @@ -1236,8 +1313,11 @@ NXapm: configured in such a manner that the result file is ideally recreatable yielding the same results. (NXion): + exists: [min, 0, max, 256] isotope_vector(NX_UINT): - nuclid_list(NX_UINT): # more human-readable form of the isotope_vector - exists: recommended - charge_state(NX_INT): # ##MK::needs to be NX_INT + charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): + nuclid_list(NX_UINT): + exists: recommended + name: + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml index 014885c3ed..574dba0b21 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml @@ -3,8 +3,11 @@ doc: | Configuration of a paraprobe-clusterer tool run in atom probe microscopy. symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_positions: Number of position values. - n_disjoint_clusters: Number of disjoint cluster. + # n_positions: Number of position values. + # n_disjoint_clusters: Number of disjoint cluster. + n_ivecmax: Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + n_clust_algos: Number of clustering algorithms used. + n_ions: Number of different iontypes to distinguish during clustering. NXapm_paraprobe_config_clusterer: (NXentry): # by default for appdefs the value of the exists keyword is required @@ -25,6 +28,10 @@ NXapm_paraprobe_config_clusterer: build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. analysis_identifier: exists: optional doc: | @@ -33,16 +40,13 @@ NXapm_paraprobe_config_clusterer: analysis_description: exists: optional doc: Possibility for leaving a free-text description about this analysis. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. number_of_processes(NX_UINT): doc: | - How many clustering processes should the tool execute. + How many tasks to perform? unit: NX_UNITLESS + cameca_to_nexus(NXprocess): - exists: [min, 0, max, 1] + exists: optional doc: | This process maps results from cluster analyses performed with IVAS/APSuite into an interoperable representation. Specifically in this process @@ -71,118 +75,52 @@ NXapm_paraprobe_config_clusterer: \@version: dataset_name_reconstruction: dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - exists: required - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - - ion_position_filename: - doc: | - Name of HDF5 file which stores reconstructed ion positions. - This file should have been generated by from the community or vendor format. - This file not necessarily contains all the of the dataset because - spatial filters might have been applied in commercial software prior - to executing the cluster analysis so that e.g. only positions within a - ROI are reported by the commercial software. - POS files from IVAS have to be converted first. - dataset_name_positions: - doc: | - Name of the dataset inside the HDF5 file ion_position_filename - which refers to the specific positions to use for this analysis. - The referred to dataset has to be formatted as an array of shape - (n_positions, 3). - cluster_indices_filename: - doc: | - Name of the HDF5 file which stores mass-to-charge-state-ratio values - (in the case of IVAS/APSuite) or other numbers which can be interpreted - as cluster labels. - dataset_name_cluster_indices: - doc: | - Name of the dataset inside the HDF5 file cluster_indices_filename - which refers to the specifically encoded cluster indices. - The referred to dataset has to be formatted as an array of shape - (n_positions, 1). + doc: | + AMETEK/Cameca results of cluster analyses, like with the maximum- + separation (MS) method clustering algorithm `J. Hyde et al. `_ + are stored as an improper POS file: This is a matrix of floating + point quadruplets, one for each ion and as many quadruplets as + ions were investigated. The first three values encode the position + of the ion. The fourth value is an improper mass-to-charge-state-ratio + value which encodes the integer identifier of the cluster as a floating + point number. # mapping_method: # doc: | # How should cluster labels be created from the cluster_labels information # especially when these areNcluste floating point values. # enumeration: [take_as_is, use_dictionary] - mapping_dictionary_keyword(NX_NUMBER): - doc: | - The list of all keywords of a dictionary which maps implicit cluster - indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_disjoint_clusters]] - mapping_dictionary_value(NX_UINT): - doc: | - The list of all values of a dictionary which maps implicit cluster - indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - The sequences of mapping_dictionary_keyword and mapping_dictionary_value - have to match. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_disjoint_clusters]] + # mapping_dictionary_keyword(NX_NUMBER): + # doc: | + # The list of all keywords of a dictionary which maps implicit cluster + # indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_disjoint_clusters]] + # mapping_dictionary_value(NX_UINT): + # doc: | + # The list of all values of a dictionary which maps implicit cluster + # indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + # The sequences of mapping_dictionary_keyword and mapping_dictionary_value + # have to match. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_disjoint_clusters]] recover_evaporation_id(NX_BOOLEAN): doc: | Specifies if the tool should try to recover for each position the closest matching position from dataset/dataset_name_reconstruction (within floating point accuracy). This can be useful for instance when users - wish to recover the original evaporation ID which IVAS/AP Suite drops - for instance when writing their *.indexed.* cluster results files. - unit: NX_UNITLESS - recover_bitmask(NX_BOOLEAN): - doc: | - Specifies if the tool should try to recover, after a recovery of the - evaporation IDs a bitmask which identifies which of the positions - in dataset/dataset/dataset_name_reconstruction where covered - by the IVAS/APSuite cluster analysis. This can be useful to recover - the region of interest. - unit: NX_UNITLESS - # compute_convex_hulls(NX_BOOLEAN): + wish to recover the original evaporation ID, which IVAS/AP Suite drops + for instance when writing their *.indexed.* cluster results POS files. + # recover_bitmask(NX_BOOLEAN): # doc: | - # For now a support functionality which instructs the tool based on the group all positions for each ion to compute a representation of the convex hull of the dataset. This functionality is planned to be replaced at some point by the surfacer tool inasmuch as the surfacer tool gets the option to accept labelled positions. This approach would also be more useful in the future because then the machinery for computing alpha shapes can immediately be applied as well for set of point clouds, i.e. cluster analysis. + # Specifies if the tool should try to recover, after a recovery of the + # evaporation IDs a bitmask which identifies which of the positions + # in dataset/dataset/dataset_name_reconstruction where covered + # by the IVAS/APSuite cluster analysis. This can be useful to recover + # the region of interest. cluster_analysis(NXprocess): exists: [min, 0, max, 1] @@ -198,11 +136,26 @@ NXapm_paraprobe_config_clusterer: filename: \@version: group_name_iontypes: + ion_to_edge_distances(NXprocess): + exists: optional + doc: | + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + filename: + doc: Name of an HDF5 file which contains the ion distances. + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + dataset_name: + doc: Absolute HDF5 path to the dataset with distance values for each ion. spatial_filter(NXspatial_filter): exists: optional windowing_method: exists: required + enumeration: [entire_dataset] # ##MK::nothing implemented so far (NXcg_ellipsoid_set): exists: optional dimensionality(NX_POSINT): @@ -238,9 +191,179 @@ NXapm_paraprobe_config_clusterer: hit_multiplicity_filter(NXmatch_filter): exists: optional - clustering_algorithm: - doc: Name of the algorithm. - clustering_parameter: + # clustering_algorithm(NX_CHAR): + # doc: | + # Name of the clustering algorithm used. + # enumeration: [dbscan] # , optics, hpdbscan] + # dimensions: + # rank: 1 + # dim: [[1, n_clust_algos]] + ion_type_filter(NX_CHAR): + doc: | + How should iontypes be interpreted/considered during the cluster analysis. + Different options exist how iontypes are interpreted (if considered at all) + given an iontype represents in general a (molecular) ion with different isotopes + that have individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + This is relevant as in atom probe we have the situation that a ion + of a molecular ion with more than one nuclid, say Ti O for example + is counted such that although there is a single TiO molecular ion + at a position that the cluster has two members. This multiplicity + affects the size of the feature and chemical composition. + # enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + enumeration: [resolve_element] # specify further details + ion_query_isotope_vector(NX_UINT): + doc: | + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ions], [2, n_ivecmax]] + dbscan(NXprocess): + doc: | + Settings for DBScan clustering algorithm. For original details about the + algorithms and (performance-relevant) details consider: + + * `M. Ester et al. `_ + * `M. Götz et al. `_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. `_ + high_throughput_method(NX_CHAR): + doc: | + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + As an example we may define eps with ten entries and min_pts with + three entries. If high_throughput_method is tuple the analysis is + invalid as we have an insufficient number of min_pts for the ten + eps values. + By contrast, for combinatorics paraprobe-clusterer will run three + individual min_pts runs for each eps value, resulting in a total + of 30 analyses. + As an example the DBScan analysis reported in `M. Kühbach et al. `_ + would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) + eps values, min_pts one, and high_throughput_method set to combinatorics. + enumeration: [tuple, combinatorics] + eps(NX_FLOAT): + doc: | + Array of epsilon (eps) parameter values. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, i]] + min_pts(NX_UINT): + doc: | + Array of minimum points (min_pts) parameter values. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] # ##MK::has to be i like for eps when high_throughput_method is tuple ! + # THE IDEA BEHIND paraprobe-clusterer is that users can run a number of + # cluster analyses on their dataset on exactly the same point cloud and under + # the same conditions + + optics(NXprocess): + doc: | + Settings for the OPTICS clustering algorithm. + + * `M. Ankerest et al. `_ + high_throughput_method(NX_CHAR): + doc: | + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + enumeration: [tuple, combinatorics] + min_pts(NX_UINT): + doc: | + Array of minimum points (min_pts) parameter values. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + max_eps(NX_FLOAT): + doc: | + Array of maximum epsilon (eps) parameter values. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, j]] + hdbscan(NXprocess): doc: | - A text representation like a JSON/YAML dictionary with the - parameter of the clustering_algorithm. + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. `_ + * scikit-learn hdbscan library ``_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. + high_throughput_method(NX_CHAR): + doc: | + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + enumeration: [tuple, combinatorics] + min_cluster_size(NX_NUMBER): # ##MK:? NX_FLOAT + doc: | + Array of min_cluster_size parameter values. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, i]] + min_samples(NX_NUMBER): # ##MK::NX_UINT + doc: | + Array of min_samples parameter values. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, j]] + cluster_selection_epsilon(NX_NUMBER): + doc: | + Array of cluster_selection parameter values. + unit: NX_ANY # ##MK::? but so None as an argument + dimensions: + rank: 1 + dim: [[1, k]] + alpha(NX_NUMBER): # ##MK:? NX_FLOAT + doc: | + Array of alpha parameter values. + unit: NX_ANY # ##MK::? + dimensions: + rank: 1 + dim: [[1, m]] + # ADD FURTHER ALGORITHMS, see L. Stephenson for further details + # e.g. https://doi.org/10.1017/S1431927607070900 diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml index a67c5c599d..c7df56b67c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml @@ -3,12 +3,10 @@ doc: | Configuration of a paraprobe-intersector tool run in atom probe microscopy. symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. - # Nityp_cand: How many iontypes does the delocalization filter specify. - # Nivec: Maximum number of atoms per molecular ion. - n_elements: How many elements to use for computing a composition. NXapm_paraprobe_config_intersector: (NXentry): - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently \@version: doc: Version specifier of this application definition. definition: @@ -37,334 +35,199 @@ NXapm_paraprobe_config_intersector: doc: | ISO 8601 formatted time code with local time zone offset to UTC information included when this configuration file was created. - intersection_detection_method: - doc: | - Specifies the method to use which decides if two objects intersect. - For reasons which are detailed in the supplementary material of - `M. Kühbach et al. `_, the tool by - default assumes that two objects intersect if they share at least one - ion with the same evaporation ID - (shared_ion). Alternatively, with specifying tetrahedra_intersections, - the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks - for at least one pair of intersecting tetrahedra to identify if two objects - intersect or not. - - However, we found that these geometrical analyses can result in corner - cases which the currently used library (TetGen) was not unable to - tetrahedralize successfully. These cases were virtually always - associated with complicated non-convex polyhedra - which had portions of the mesh that were connected by almost point like - tubes of triangles. - enumeration: [shared_ion, tetrahedra_intersections] - has_object_volume(NX_BOOLEAN): - doc: | - Specifies if the tool should load the volume of each object - (if existent in the input file) to characterize the evolution of the - objects' volume as a function of set identifier (e.g. time). - - This and the has_object_composition option enables to activate - computations in the code which correlate the spatio-temporal tracking - with an object's properties. This is useful to explore/understand how - the object descriptor values evolve as a function of the parameterization - of the object. To arrive at a detailed understanding and quantification - of the differences of a given object as a function of delocalization and - e.g. iso-surfacing settings. - - The point made in M. Kühbach et al. 2022, is that this functionality - can be used to track for instance how the accumulated volume and - composition of an object depends on its segmentation via iso-surfaces. - The benefit of such computations is that users can inspect the - parameter sensitivity of an objects representation rigorously. - has_object_composition(NX_BOOLEAN): - doc: | - Specifies if the tool should load the composition of each object - (if existent in the input file) to characterize the evolution of the - object's composition as a function of set identifier. See the description - of has_object_volume for further details. In M. Kühbach et al. 2022, both - has_object options were used to characterize e.g. the parameter - sensitivity of computed composition, volume, and shape specifically, - for a carbide that was segmented via different carbon iso-composition - values. - element_whitelist(NX_UINT): - doc: | - List of np.uint16 elements, via their proton number. The whitelist is - evaluated to compute the composition of an object during tracking - when has_object_composition is set to true. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_elements]] - #[[1, Nivec], [2, Nityp_cand]] number_of_processes(NX_UINT): doc: | For now a support field for the tool to identify how many individual analyses the tool should execute as part of the analysis. unit: NX_UNITLESS - - (NXprocess): - number_of_tracking_sets(NX_UINT): + volume_volume_spatial_correlation(NXprocess): + exists: [min, 1, max, infty] + doc: | + Tracking volume_volume_spatial_correlation is the process of building logical + relations between volumetric features based on meshes, their proximity and + eventual intersections. Volumetric overlap and proximity of volumetric + features is identified for members of sets of features to members of + other sets of volumetric features. + Specifically, for each time step k pairs of sets are compared: + Members of a so-called current_set to members of a so-called next_set. + Members can be different types of volumetric features. + In the analysis of M. Kuehbach et al. specifically features can be + so-called objects (closed non-degnerated polyhedra representing watertight + parts of an e.g. iso-surface) and/or proxies. Proxies are computed + doppelganger/replacement meshes for parts of an iso-surface which initially + were not resulting in watertight meshes because objects at the edge + of the dataset or incompletely measured or truncated objects. + intersection_detection_method: + doc: | + Specifies the method whereby to decide if two objects intersect volumetrically. + For reasons which are detailed in the supplementary material of + `M. Kühbach et al. `_, the tool by + default assumes that two objects intersect if they share at least one + ion with the same evaporation ID (shared_ion). + Alternatively, with specifying tetrahedra_intersections, + the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks + for at least one pair of intersecting tetrahedra to identify if two objects + intersect or not. + + However, we found that these geometrical analyses can result in corner + cases which the currently used library (TetGen) was not unable to + tetrahedralize successfully. These cases were virtually always + associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + Finding more robust methods for computing intersections between + not necessarily convex polyhedra might improve the situation in the future. + enumeration: [shared_ion] # , tetrahedra_intersections] + analyze_intersection(NX_BOOLEAN): + doc: | + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) intersect volumetrically. + analyze_proximity(NX_BOOLEAN): + doc: | + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) lie closer to one another than the + threshold_proximity. + analyze_coprecipitation(NX_BOOLEAN): doc: | - For now a support field for the tool to identify how many individual - analyses (i. e. individual current_to_next mappings) the tool should - perform as part of the high-throughput analysis. - unit: NX_UNITLESS - (NXprocess): - exists: [min, 1, max, 1] + Specifies if the tool evaluates, ones all tracking tasks were + successfully completed, how intersecting or proximity related + objects build sub-graphs. This is the feature which enabled + M. Kühbach et al. 2022 the high-throughput analyses of how many + objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order. For these analyses to work + has_object_volume needs to be activated. + threshold_proximity(NX_FLOAT): doc: | - Tracking is the process of building logical relations between objects - based on proximity and mesh intersections. For each time step pairs - of sets are compared: members of a current_set and a next_set. - Members have to be objects and eventually can in addition be so-called - proxies. Objects and proxies are non-degenerated closed polyhedra which - are not necessarily convex. Proxies are doppelganger/replacement - meshes of objects which would otherwise be impossible to describe - with a closed mesh. - # To offer a draft implementation for the handling of proxies, - # the code currently imports the proxies as if they were objects. - current_set(NXcollection): - # NEW ISSUE: better should be a set of geometric primitives - # provenance handling + The maximum Euclidean distance between two objects below which + both objects are still considered within proximity. + unit: NX_LENGTH + # \@units: nm + has_current_to_next_links(NX_BOOLEAN): + doc: | + Specifies if the tool stores the so-called forward relations between + nodes representing members of the current_set to nodes representing + members of the next_set. + has_next_to_current_links(NX_BOOLEAN): + doc: | + Specifies if the tool stores the so-called backward relations between + nodes representing members of the next_set to nodes representing + members of the current_set. + + current_set(NXprocess): + doc: | + Current set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the current_set. + The meshes were generated as a result of some other meshing process. + set_identifier(NX_UINT): + doc: | + This identifier can be used to label the current set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in M. Kühbach + et al. 2022, this identifier takes the role of the time variable k. + unit: NX_ANY + # number_of_objects(NX_UINT): + # doc: For now a support field to tell the tool how many objects to load. + # unit: NX_UNITLESS + number_of_feature_types(NX_UINT): doc: | - Current set stores a set of object geometries that should be checked - for proximity and/or intersection with member of the next_set. - identifier(NX_UINT): + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + current_set. + unit: NX_UNITLESS + FEATURE(NXcollection): + exists: [min, 1, max, 4] # restriction to two not needed, currently for objects and proxies + feature_type(NX_CHAR): doc: | - This identifier can be used to label the current set. The label - effectively represents the time/iteration step when the current - set was taken. As it is detailed in M. Kühbach et al. 2022, - this identifier takes the role of the time variable k. - unit: NX_ANY - # number_of_objects(NX_UINT): - # doc: For now a support field to tell the tool how many objects to load. - # unit: NX_UNITLESS + Descriptive category explaining what these features are. + enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] filename: doc: | - Name of the HDF5 file which contain geometry (vertex coordinates, - facet indices) and properties (ions, composition) of polyhedra - (l objects) which should be included in the current set. - The user has to ensure that the datasets under list_of_dataset_names - (vertices, facet_indices, ions) exist and are formatted consistently. + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. # NEW ISSUE: make more robust checks wrt to the consistence of the datasets \@version: doc: | Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of reproducibility from which file specifically contains these data. - groupname_object_geometry_data: - doc: | - Paraprobe-intersector loads triangulated surface mesh data of a - set of objects. For each object its mesh is expected to have - three-dimensional position data of the unique vertices and a - matrix of vertex indices which describe the faces. - As each object has to be a polyhedron/closed surface mesh, this - matrix has as many rows as faces, i.e. triangles and three columns. - Vertex indices have to start at zero. - groupname_object_supplementary_data: - doc: | - The default intersection detection method uses shared ions. - Therefore, it is necessary to specify where the results from the - paraprobe-nanochem tool run are located which document which ions - (with their evaporation IDs) are inside or on the surface of each - object. This field points the tool to these evaporation IDs. - groupname_object_property_data: - doc: | - In order to correlate object properties like volume and composition - with tracking data, it is necessary to specify where the results - (object properties) from the paraprobe-nanochem tool run are located. - This field instructs the tool where to load these object property data - from. - dataset_object_identifier: - doc: | - Paraprobe-intersector does not just compare two objects but a set - of sets of objects. This field instructs the tool where to load - the identifiers (names) of each object in a current_set or next_set - respectively from. - groupname_proxy_geometry_data: - exists: optional + groupname_geometry_prefix: doc: | - Like groupname_object_geometry_data but for the proxies. - Triangulated surface meshes of proxies have to be formatted - in the same manner as objects. - groupname_proxy_interior_supplementary_data: - exists: optional + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object/polyhedron. + feature_identifier(NX_UINT): doc: | - Like groupname_proxy_supplementary_data but for the interior proxies. - Leave an empty string if proxies should not be used. - groupname_proxy_exterior_supplementary_data: - exists: optional - doc: | - Like groupname_proxy_supplementary_data but for the exterior proxies. - Leave an empty string if proxies should not be used. - # groupname_proxy_property_data: - # exists: optional - # doc: | - # Like groupname_proxy_property_data but for the proxies. - # dataset_proxy_identifier: - # exists: optional - # doc: Like dataset_object_identifier but for the proxies. - # list_of_dataset_names_vertices: - # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of vertex positions for each object. - # list_of_dataset_names_facet_indices: - # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of facet indices for each object. - # list_of_dataset_names_properties: - # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of properties for each object. + Array of identifier whereby the path to the geometry data + can be interferred automatically. - next_set(NXcollection): + next_set(NXcollection): + doc: | + Next set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the next_set. + The meshes were generated as a result of some other meshing process. + set_identifier(NX_UINT): doc: | - Next set stores a set of object geometries that should be checked - for proximity and/or intersection with (each) member(s) of the - current_set. - identifier(NX_UINT): - doc: | - This identifier can be used to label the next set. Like for the current_set - the identifier is effectively the time/iteration step when the next set was taken. - As it is detailed in M. Kühbach et al. 2022, this identifier - takes the role of the time variable k+1. - unit: NX_ANY - # number_of_objects(NX_UINT): - # doc: For now a support field to tell the tool how many objects to load. - # unit: NX_UNITLESS + This identifier can be used to label the next_set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in M. Kühbach + et al. 2022, this identifier takes the role of the time variable k+1. + unit: NX_ANY + # number_of_objects(NX_UINT): + # doc: For now a support field to tell the tool how many objects to load. + # unit: NX_UNITLESS + number_of_feature_types(NX_UINT): + doc: | + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + next_set. + unit: NX_UNITLESS + FEATURE(NXcollection): + exists: [min, 1, max, 4] # restriction to two not needed, currently for objects and proxies + feature_type(NX_CHAR): + doc: | + Descriptive category explaining what these features are. + enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] filename: doc: | - Name of the HDF5 file which contain geometry (vertex coordinates, - facet indices) and properties (ions, composition) of - polyhedra(l objects) which should be included in the current set. - The user has to ensure that the datasets that are referred to - under list_of_dataset_names (vertices, facet_indices, ions). + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. + # NEW ISSUE: make more robust checks wrt to the consistence of the datasets \@version: doc: | Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of reproducibility from which file specifically contains these data. - groupname_object_geometry_data: - doc: | - Paraprobe-intersector loads triangulated surface mesh data of a - set of objects. For each object its mesh is expected to have - three-dimensional position data of the unique vertices and a - matrix of vertex indices which describe the faces. - As each object has to be a polyhedron/closed surface mesh - this matrix has as many rows as faces, i.e. triangles and - three columns. Vertex indices have to start at zero. - groupname_object_supplementary_data: - doc: | - The default intersection detection method uses shared ions. - Therefore, it is necessary to specify where the results from the - paraprobe-nanochem tool run are located which document which ions - (with their identifiers) are inside or on the surface of each object. - This field instructs the tool where to load these - ion evaporation ids from. - groupname_object_property_data: - doc: | - In order to correlate object properties like volume and composition - with tracking data, it is necessary to specify where the results - (object properties) from the paraprobe-nanochem tool run are located. - This field instructs the tool where to load these object property - data from. - dataset_object_identifier: - doc: | - Paraprobe-intersector does not just compare two objects but a set - of sets of objects. This field instructs the tool where to load - the identifiers (names) of each object in a current or next set - respectively from. - groupname_proxy_geometry_data: - exists: optional + groupname_geometry_prefix: doc: | - Like groupname_object_geometry_data but for the proxies. - Triangulated surface meshes of proxies have to be formatted - in the same manner. Leave an empty string if proxies should not - be used. - groupname_proxy_interior_supplementary_data: - exists: optional + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object/polyhedron. + feature_identifier(NX_UINT): doc: | - Like groupname_proxy_supplementary_data but for the interior proxies. - Leave an empty string if proxies should not be used. - groupname_proxy_exterior_supplementary_data: - exists: optional - doc: | - Like groupname_proxy_supplementary_data but for the exterior proxies. - Leave an empty string if proxies should not be used. - # groupname_proxy_property_data: - # exists: optional - # doc: | - # Like groupname_proxy_property_data but for the proxies. - # Leave an empty string if proxies should not be used. - # dataset_proxy_identifier: - # exists: optional - # doc: | - # Like dataset_object_identifier but for the proxies. - # Leave an empty string if proxies should not be used. - # list_of_dataset_names_vertices: - # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of vertex positions for each object. - # list_of_dataset_names_facet_indices: - # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of facet indices for each object. - # list_of_dataset_names_properties: - # doc: Array of absolute HDF5 paths to datasets in the respectively specified HDF5 file under filename which details the array of properties for each object. - - add_proxies_to_objects(NX_BOOLEAN): - doc: | - Specifies if, in the case of small finite datasets, objects which are - located at the edge of the dataset should be accounted for or not. - If these so-called proxy/doppelganger objects are accounted for, the - respective groupname_proxy and dataset_proxy fields have to be - filled to tell the tool where to load which proxy meshes from. - analyze_intersection(NX_BOOLEAN): - doc: | - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) intersect volumetrically. - analyze_proximity(NX_BOOLEAN): - doc: | - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) lie closer to one another than the - threshold_proximity. - analyze_coprecipitation(NX_BOOLEAN): - doc: | - Specifies if the tool evaluates, ones all tracking tasks were - successfully completed, how intersecting or proximity related - objects build sub-graphs. This is the feature which enabled - M. Kühbach et al. 2022 the high-throughput analyses of how many - objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order. For these analyses to work - has_object_volume needs to be activated. - threshold_proximity(NX_FLOAT): - doc: | - The maximum Euclidean distance between two objects below which - both objects are still considered within proximity. - unit: NX_LENGTH - # \@units: nm - has_current_to_next_links(NX_BOOLEAN): - doc: | - Specifies if the tool stores the so-called forward relations between - nodes representing members of the current_set to nodes representing - members of the next_set. - has_next_to_current_links(NX_BOOLEAN): - doc: | - Specifies if the tool stores the so-called backward relations between - nodes representing members of the next_set to nodes representing - members of the current_set. + Array of identifier whereby the path to the geometry data + can be interferred automatically. - # ##MK::guru features tetrahedra volume intersection and tessellation, currently only supported through the C/C++ source code - # NEW ISSUE: correlating objects and then tessellating these to create three-dimensional renditions of the regions of intersections at the single ion level. This can be used to segment grain and phase boundary regions volumetrically as it is discussed in M. Kühbach et al. 2022, npj Computational Materials. - # analyze_intersection_volume(NX_BOOLEAN): - # doc: Specifies if the tool evaluates numerically the intersection volume between intersected objects. Demands tetrahedra_intersections to be set as the intersection_detection_method. As it is detailed in the supplementary material of M. Kühbach et al. 2022, npj Computational Materials, the computation uses an algorithm based on explicitly constructing intersecting NEF tetrahedra. This is currently an extremely time-consuming operation. - # analyze_tessellation(NX_BOOLEAN): - # doc: Specifies if the tool should tessellate a given region of the dataset. - # threshold_halo_width(NX_FLOAT): - # doc: The width of the halo region about an AABB bounding the set of target objects to tessellated. The to ensure that upon Voronoi tessellating the point cloud no cell of an object is incorrectly truncated by the boundaries of the local region cut out from the entire point cloud. - # dataset(NXprocess): - # filename: - # doc: Name of HDF5 file which stores reconstructed ion position and mass-to-charge-state ratios. Such an HDF5 file can store multiple reconstructions. Using an identifier (ID) is the mechanism which paraprobe uses to distinguish which specific reconstruction will be processed. With this design it is possible that the same HDF5 file stores multiple versions of a reconstruction of e.g. the same or different measured datasets, respectively. - # \@version: - # doc: Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of reproducibility from which file specifically contains these data. - # dataset_name_reconstruction: - # doc: Name of the dataset inside the HDF5 file which refers to the specific reconstructed ion positions to use for this analysis. - # dataset_name_mass_to_charge: - # doc: Name of the dataset inside the HDF5 file which refers to the specific mass-to-charge-state ratios to use for this analysis. - # iontypes(NXprocess): - # doc: Ranging definitions which were used to map mass-to-charge-state-ratio values and resulting iontype labels. - # filename: - # doc: Name of HDF5 file which stores ranging definitions which define how mass-to-charge ratios map map to iontypes and which iontypes are distinguished. The UNKNOWNTYPE iontype is the default iontype. The ID of this special iontype is always reserved as 0. Each ion is assigned to the UNKNOWNTYPE by default. Iontypes are assigned by checking if the mass-to-charge-state ratio of an ion matches to any of the defined mass-to-charge-state ratio intervals. - # \@version: - # doc: Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of reproducibility from which file specifically contains these data. - # group_name_iontypes: - # doc: Name of the group (prefix to the individual ranging definitions) inside the HDF5 file which refers to the ranging definition to use. A HDF5 file can store multiple ranging definitions. Using an ID is the mechanism to distinguish which specific ranging (version) will be processed. Reconstruction and ranging ID can differ. They specify different IDs. + # ##MK::tetrahedra volume intersection and tessellation, and Nef polyhedra intersection + # ##MK::are considered guru features and therefore currently supported via modifying the C/C++ source code diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml index 07e82dfaf5..75ea6b617b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml @@ -825,6 +825,10 @@ NXapm_paraprobe_config_nanochem: # HDF5 file under filename which details consistently oriented # vertex normals of the facets. # exists: optional + patch_identifier_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): ion_to_feature_distances(NXprocess): exists: optional doc: | diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml index 5029d16686..291dac3d5c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml @@ -54,7 +54,7 @@ NXapm_paraprobe_config_ranger: the tool execute as part of the analysis. unit: NX_UNITLESS - range_with_existent_iontypes(NXprocess): + apply_existent_ranging(NXprocess): exists: [min, 0, max, 1] dataset(NXapm_input_reconstruction): filename: @@ -219,3 +219,10 @@ NXapm_paraprobe_config_ranger: doc: | Report if identified ions should be characterized wrt to their number of disjoint isotopes. + + check_existent_ranging(NXprocess): + exists: [min, 0, max, 1] + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml new file mode 100644 index 0000000000..a0ac6b516f --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml @@ -0,0 +1,90 @@ +category: application +doc: | + Configuration of a paraprobe-selector tool run in atom probe microscopy. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXapm_paraprobe_config_selector: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_selector] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + number_of_processes(NX_UINT): + doc: | + How many roi_selection processes should the tool execute. + unit: NX_UNITLESS + roi_selection(NXprocess): + exists: [min, 1, max, 1] # for now allow for only one process + doc: | + This process identifies which of the points/ions in the datasets are + inside or on the surface of geometric primitives and meet optionally + specific other filtering constraints. + A typical use case of a roi_selection is to restrict analyses to + specific regions of the dataset, eventually regions with a complicated + shape. + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + + spatial_filter(NXspatial_filter): + windowing_method: + (NXcg_ellipsoid_set): + exists: optional + cardinality(NX_POSINT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + # orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + cardinality(NX_POSINT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + cardinality(NX_POSINT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_FLOAT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + linear_range_min_incr_max(NX_UINT): + iontype_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml index e825b4216a..eb9e09e83c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml @@ -93,13 +93,12 @@ NXapm_paraprobe_config_spatstat: exists: optional hit_multiplicity_filter(NXmatch_filter): exists: optional - ion_to_edge_distances(NXprocess): + exists: optional doc: | The tool enables to inject precomputed distances of each ion to a representation of the edge of the dataset which can be used to control and substantially reduce edge effects when computing spatial statistics. - exists: optional filename: doc: | Name of an HDF5 file which contains ion-to-edge distances. @@ -110,15 +109,28 @@ NXapm_paraprobe_config_spatstat: The shape of the distance values has to match the length of the ion positions array in dataset/dataset_name_reconstruction and dataset_name_mass_to_charge respectively. + edge_distance(NX_FLOAT): + doc: | + Threshold to define how large an ion has to lay at least far away + from the edge of the dataset so that the ion can act as a source, + i.e. that an ROI is placed at the location of the ion and its + neighbors are analyzed how they contribute to the computed statistics. + + The ion_to_edge_distances threshold can be combined with a threshold + for the ion_to_feature_distances. + Specifically, if ion_to_feature_distances are loaded an ion only + acts as a source if both threshold criteria are met. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + unit: NX_LENGTH ion_to_feature_distances(NXprocess): + exists: optional # NEW ISSUE: is this optional? doc: | In addition to spatial filtering, and considering how far ions lie to the edge of the dataset, it is possible to restrict the analyses to a sub-set of ions within a distance not farther away to a feature than a threshold value. - # which is this threshold value - exists: optional - # NEW ISSUE: is this optional? filename: doc: | Name of an HDF5 file which contains ion-to-feature distances. @@ -126,95 +138,118 @@ NXapm_paraprobe_config_spatstat: doc: | Absolute HDF5 path to the dataset with the ion-to-feature distance values for each ion. - - randomize_labels(NX_BOOLEAN): - doc: | - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - random_number_generator(NXcs_prng): - exists: recommended - type: - seed(NX_NUMBER): - warmup(NX_NUMBER): - ion_query_type_source: + threshold(NX_FLOAT): doc: | - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - ion_query_isotope_vector_source(NX_UINT): - doc: | - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_ion_source], [2, n_ivecmax]] - ion_query_type_target: - doc: | - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + Recall that the ion_to_feature_distances threshold is combined + with the ion_to_edge_distances threshold. + unit: NX_LENGTH + # ##MK::think about an inversion ruleset for the filter, i.e. + # like discussed in Haley/Stephenson's paper where ions only far enough + # from a feature AND deeply embedded enough in the dataset are chosen. + randomize_labels(NX_BOOLEAN): + doc: | + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + random_number_generator(NXcs_prng): + exists: recommended + type: + seed(NX_NUMBER): + warmup(NX_NUMBER): + ion_query_type_source: + doc: | + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + ion_query_isotope_vector_source(NX_UINT): + doc: | + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ion_source], [2, n_ivecmax]] + ion_query_type_target: + doc: | + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] # NEW ISSUE: conditionally required only when resolve_isotope - ion_query_isotope_vector_target(NX_UINT): - doc: | - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_ion_target], [2, n_ivecmax]] - statistics(NXprocess): + ion_query_isotope_vector_target(NX_UINT): + doc: | + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ion_target], [2, n_ivecmax]] + statistics(NXprocess): + doc: | + Specifies which spatial statistics to compute. + knn(NXprocess): + doc: Compute k-th nearest neighbour statistics. + exists: optional + nth(NX_UINT): + doc: Order k. + unit: NX_UNITLESS + histogram_min_incr_max(NX_FLOAT): + doc: | + Minimum value, increment, and maximum value of the histogram binning. + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 1 + dim: [[1, 3]] + rdf(NXprocess): doc: | - Specifies which spatial statistics to compute. - knn(NXcollection): - doc: Compute k-th nearest neighbour statistics. - exists: optional - nth(NX_UINT): - doc: Order k. - unit: NX_UNITLESS - histogram_min_incr_max(NX_FLOAT): - doc: | - Minimum value, increment, and maximum value of the histogram binning. - unit: NX_LENGTH - # \@units: nm - dimensions: - rank: 1 - dim: [[1, 3]] - # NEW ISSUE: rdf(NXcollection): + Compute radial distribution function. + exists: optional + histogram_min_incr_max(NX_FLOAT): + doc: | + Minimum value, increment, and maximum value of the histogram binning. + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 1 + dim: [[1, 3]] # NEW ISSUE: ripleyk(NXcollection): # NEW ISSUE: two_point(NXcollection): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml index d71a9684a4..59105c95d3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml @@ -4,6 +4,7 @@ doc: | symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. n_alpha_values: Number of alpha values (and offset values) to probe. + n_values: How many different match values does the filter specify. NXapm_paraprobe_config_surfacer: (NXentry): # by default for appdefs the value of the exists keyword is required @@ -84,13 +85,30 @@ NXapm_paraprobe_config_surfacer: bitdepth(NX_UINT): mask(NX_UINT): identifier(NX_UINT): + # ##MK::ion_id_filter(NXcs_filter_boolean_mask): evaporation_id_filter(NXsubsampling_filter): exists: optional + linear_range_min_incr_max(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 3]] iontype_filter(NXmatch_filter): exists: optional + method: + match(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_values]] hit_multiplicity_filter(NXmatch_filter): exists: optional - + method: + match(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_values]] surface_meshing(NXprocess): preprocessing_method: doc: | @@ -120,8 +138,13 @@ NXapm_paraprobe_config_surfacer: alpha_value_choice: doc: | Specifies which method to use to define the alpha value. - By default, the tool uses a fast specialized algorithm for - computing only the convex hull. + The value convex_hull_naive is the default. This instructs the tool + to use a fast specialized algorithm for computing only the convex + hull. The resulting triangles can be skinny. + + The value convex_hull_refine computes first also a convex_hull_naive + but refines the mesh by triangle flipping and splitting to improve + the quality of the mesh. The value smallest_solid instructs the CGAL library to choose a value which realizes an alpha-shape that is the smallest solid. @@ -140,7 +163,7 @@ NXapm_paraprobe_config_surfacer: though such as watertightness and proximity constraints on the resulting wrapping. # NEW ISSUE: further details CGAL documentation - enumeration: [fast_convex_hull, smallest_solid, cgal_optimal, set_of_values, set_of_alpha_wrappings] + enumeration: [convex_hull_naive, convex_hull_refine, smallest_solid, cgal_optimal, set_of_values, set_of_alpha_wrappings] alpha_values(NX_FLOAT): doc: | Array of alpha values to use when alpha_value_choice is set_of_values diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml index 4df2dd0bb3..06bd309294 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml @@ -174,7 +174,7 @@ NXapm_paraprobe_config_tessellator: erosion_distance(NX_FLOAT): doc: | Maximum distance for which cells are eroded. - # ##MK::needs further details + # ##MK::needs further details or is this at all a parameter? unit: NX_LENGTH # \@units: nm # minValue: EPSILON diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml new file mode 100644 index 0000000000..3d15b7b63f --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml @@ -0,0 +1,429 @@ +category: application +doc: | + Results of a paraprobe-clusterer tool run. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: The total number of ions in the reconstruction. + n_dict: The total number of entries in the restricted_identifier dictionary. + +NXapm_paraprobe_results_clusterer: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_clusterer] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + status(NX_CHAR): + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: optional + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: | + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + # ##MK::define also reconstruction coordinate system and + # ##MK::map between the two + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + +# ##MK::begin of the tool-specific section + (NXprocess): + exists: [min, 0, max, 1] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + + cluster_analysis(NXprocess): + exists: optional + doc: | + The result of a cluster analyses. These include typically the label for + each ion/point documenting to which feature (if any) an ion is assigned. + Typically, each analysis/run yields only a single cluster. + In cases of fuzzy clustering it can be possible that an ion is assigned + to multiple cluster (eventually with different) weight/probability. + dbscanID(NXsimilarity_grouping): + exists: [min, 0, max, infty] + doc: | + Results of a DBScan clustering analysis. + eps(NX_FLOAT): + doc: The epsilon (eps) parameter. + unit: NX_LENGTH + min_pts(NX_UINT): + doc: The minimum points (min_pts) parameter. + unit: NX_UNITLESS + cardinality(NX_UINT): + doc: | + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset. Cardinality here is not the total number of ions in the + dataset. + unit: NX_UNITLESS + # number_of_numeric_labels(NX_UINT): + # doc: | + # How many numerical labels does each feature have. + # unit: NX_UNITLESS + # number_of_categorical_labels(NX_UINT): + # doc: | + # How many categorical labels does each feature have. + # unit: NX_UNITLESS + # features(NX_CHAR): + # doc: | + # Reference to a set of features investigated in a cluster analysis. + # Features need to have disjoint numeric identifier. + identifier_offset(NX_NUMBER): + doc: | + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_lbl_num]] + # reserved_identifier_keyword(NX_UINT): + # doc: | + # By default we assume that cluster identifier 0 is reserved to + # mark that ions are not assigned to a cluster and identifier 1 is + # noise. The reserved_identifier_keyword and reserved_identifier_value + # can be used as a dictionary though to define that users + # which to overwrite this default and define own specific categories. + # In every case though cluster_identifier have to be positive integer + # and be consecutive on $[0, maximum_value]$. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_dict]] + # reserved_identifier_value(NX_CHAR): + # doc: | + # The corresponding value of the reserved_identifier dictionary. + # This can give a free-text description what a specific reserved + # ID specifies e.g. ignored, noise. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_dict]] + targets(NX_UINT): + doc: | + The evaporation sequence identifier to figure out which ions + from the reconstruction were considered targets. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + # quantities for debugging purposes + model_labels(NX_INT): + doc: | + The raw labels from the DBScan clustering backend process. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + core_sample_indices(NX_INT): + doc: | + The raw array of core sample indices which specify which of the + targets are core points. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n]] + # quantities to which these debugging quantities should be transformed + numerical_label(NX_UINT): # the cluster_identifier ! + doc: | + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the cluster_identifier. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] # ], [2, n_lbl_num]] + # categorical_label(NX_CHAR): + # doc: | + # Matrix of categorical attribute data for each member in the set. + # dimensions: + # rank: 2 + # dim: [[1, c], [2, n_lbl_cat]] + weight(NX_NUMBER): + exists: optional + doc: | + The array of weight which specifies how surely/likely the + cluster is associated/assigned to a specific identifier as + is specified in the cluster_identifier array. + For the DBScan and atom probe tomography the multiplicity + of each ion with respect to the cluster. That is how many times + should the position of the ion be accounted for because the ion + is e.g. a molecular ion with several elements or isotope of + requested type. + unit: NX_UNITLESS # ##MK:NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, c]] + is_noise(NX_BOOLEAN): + exists: optional + doc: | + Optional bitmask encoding if members of the set are assigned to as noise or not. + dimensions: + rank: 1 + dim: [[1, c]] + is_core(NX_BOOLEAN): + exists: optional + doc: | + Optional bitmask encoding if member of the set are a core point. + For details to which feature/cluster an ion/point is a core point + consider numerical_label. + dimensions: + rank: 1 + dim: [[1, c]] + statistics(NXprocess): + doc: | + In addition to the detailed storage which members was grouped to + which feature/group summary statistics are stored under this group. + # at the level of the set + # number_of_unassigned_members(NX_UINT): + # doc: | + # Total number of members in the set which are categorized as unassigned. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_lbl_num]] + number_of_noise(NX_UINT): + doc: | + Total number of members in the set which are categorized as noise. + unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_lbl_num]] + number_of_core(NX_UINT): + doc: | + Total number of members in the set which are categorized as a core point. + unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_lbl_num]] + # at the level of the feature set + number_of_features(NX_UINT): + doc: | + Total number of clusters (excluding noise and unassigned). + unit: NX_UNITLESS + feature_identifier(NX_UINT): + doc: | + Array of numerical identifier of each feature (cluster). + unit: NX_UNITLESS + dimensions: + rank: 1 # 2 + dim: [[1, n_features]] # [2, n_lbl_num]] + feature_member_count(NX_UINT): + doc: | + Array of number of members for each feature. + unit: NX_UNITLESS + dimensions: + rank: 1 # 2 + dim: [[1, n_features]] #, [2, n_lbl_num]] + + # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN + +# ##MK::end of the tool-specific section + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml new file mode 100644 index 0000000000..ee6132b0f0 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml @@ -0,0 +1,320 @@ +category: application +doc: | + Results of a paraprobe-distancer tool run. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: The total number of ions in the reconstruction. + n_tris: The total number of triangles in the set. + +NXapm_paraprobe_results_distancer: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_distancer] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + status(NX_CHAR): + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: Details about the coordinate system conventions used. + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + +# ##MK::begin of the tool-specific section + (NXprocess): + exists: [min, 0, max, 1] + point_to_triangle_set(NXprocess): + doc: | + The tool can be used to compute the analytical distance of each ion + to a set of triangles. + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed. + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + window_triangles(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the triangles in the set + were considered. Usually these are all but sometimes users may + wish to filter certain portions of the triangles out. + number_of_triangles(NX_UINT): + doc: | + Number of triangles covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_triangles]] + distance(NX_FLOAT): + doc: | + The closest analytical distance of the ions to their respectively + closest triangle from the triangle set. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, i]] + sign_valid(NXcs_filter_boolean_mask): + exists: optional + doc: | + A bitmask which identifies which of the distance values + can be assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + For points whose bit is set 0 the distance is correct but the + sign is not reliable. + number_of_points(NX_UINT): + doc: | + Number of triangles covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + triangle_identifier(NX_UINT): + exists: optional + doc: | + The identifier of the triangle that is closest for each ion. + unit: NX_UNITLESS + dimensions: + rank: + dim: [[1, i]] + xdmf_ion_identifier(NX_UINT): + exists: optional + doc: | + A support field to visualize each ion and with this the distance + informations using XDMF and e.g. Paraview. + unit: NX_UNITLESS + dimensions: + rank: + dim: [[1, i]] + +# ##MK::end of the tool-specific section + + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml new file mode 100644 index 0000000000..77a5f43ade --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml @@ -0,0 +1,314 @@ +category: application +doc: | + Results of a paraprobe-intersector tool run. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_c2n: The total number of links pointing from current to next. + n_n2c: The total number of links pointing from next to current. + n_features_curr: The total number of members in the current_set. + n_features_next: The total number of members in the next_set. + n_cluster: The total number of cluster found for coprecipitation analysis. + n_total: The number of rows in the table/matrix for coprecipitation stats. + +NXapm_paraprobe_results_intersector: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_intersector] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this results file was created. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: Details about the coordinate system conventions used. + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + +# ##MK::begin of the tool-specific section + (NXprocess): + volume_volume_spatial_correlation(NXprocess): + exists: [min, 0, max, 1] + doc: | + The results of an overlap/intersection analysis. + current_to_next_link(NX_UINT): + doc: | + A matrix of feature_identifier which specifies which named features + from the current set have directed link(s) pointing to which named + feature(s) from the next set. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_c2n], [2, 2]] + current_to_next_link_type(NX_UINT): + doc: | + For each link/pair in current_to_next a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_c2n]] + next_to_current_link(NX_UINT): + exists: optional # is an intersection analysis symmetrical ? + doc: | + A matrix of feature_identifier which specifies which named feature(s) + from the next set have directed link(s) pointing to which named + feature(s) from the current set. Only if the mapping whereby the + links is symmetric next_to_current maps the links in current_to_next + in the opposite direction. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n2c], [2, 2]] + next_to_current_link_type(NX_UINT): + exists: optional + doc: | + For each link/pair in next_to_current a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_n2c]] + intersection_volume(NX_FLOAT): + exists: optional + doc: | + For each pair of links in current_to_next the volume of the + intersection, i.e. how much volume do the two features share. + If features do not intersect the volume is zero. + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, c2n]] + coprecipitation_analysis(NXprocess): + exists: optional + doc: | + During coprecipitation analysis the current and next set are analyzed + for links in a special way. Three set comparisons are made. Members + of the set in each comparison are analyzed for overlap and proximity: + + The first comparison is the current_set against the current_set. + The second comparison is the next_set against the next_set. + The third comparison is the current_set against the next_set. + + Once the (forward) links for these comparisons are ready the + pair relations are analyzed with respect to which feature identifier + cluster in identifier space. Thereby a logical connection (link) is + established between the features in the current_set and next_set. + Recall that these two set typically represent different features + within an observed system for otherwise the same parameterization. + Examples include two sets of e.g. precipitates with differing + chemical composition that were characterized in the same material + volume representing a snapshot of an e.g. microstructure at the same + point in time. Researchers may have performed two analyses, one to + characterize precipitates A and another one to characterize percipitates + B. Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + precipitates spatial arrangement. + current_set_feature_to_cluster(NX_UINT): + doc: | + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the current_set. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_features_curr], [2, 2]] + next_set_feature_to_cluster(NX_UINT): + doc: | + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the next_set. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_features_next], [2, 2]] + cluster_identifier(NX_UINT): + doc: | + The identifier (names) of the cluster. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_cluster]] + cluster_composition(NX_UINT): + doc: | + Pivot table as a matrix. The first column encodes how many + members from the current_set are in each cluster, one row per cluster. + The second column encodes how many members from the next_set are + in each cluster, in the same row per cluster respectively. + The last column encodes the total number of members in the cluster. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_cluster], [2, 3]] + cluster_statistics(NX_UINT): + doc: | + Pivot table as a matrix. The first column encodes the different + types of clusters based on their number of members in the sub-graph. + The second column encodes how many clusters with as many members + exist. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [1, n_total], [2, 2]] + # ##MK::add results from NXapm_paraprobe_results_clusterer + +# ##MK::end of the tool-specific section + + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml new file mode 100644 index 0000000000..bcb7f2a220 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml @@ -0,0 +1,1719 @@ +category: application +doc: | + Results of a paraprobe-nanochem tool run. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: The total number of ions in the reconstruction. + n_atomic: The total number of atoms in the atomic_decomposition match filter. + n_isotopic: The total number of isotopes in the isotopic_decomposition match filter. + d: The dimensionality of the delocalization grid. + c: | + The cardinality/total number of cells/grid points in the delocalization grid. + # c_tri_soup: | + # The cardinality/total number of triangles in the triangle soup. + n_f_tri_xdmf: The total number of XDMF values to represent all faces of triangles via XDMF. + n_feature_dict: The total number of entries in a feature dictionary. + n_speci: The total number of member distinguished when reporting composition. +NXapm_paraprobe_results_nanochem: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_nanochem] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + status(NX_CHAR): + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: optional + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: | + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + # ##MK::define also reconstruction coordinate system and + # ##MK::map between the two + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + +# ##MK::begin of the tool-specific section + (NXprocess): + exists: [min, 0, max, 1] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + + iso_surface_analysis(NXprocess): + exists: [min, 0, max, infty] + delocalization(NXdelocalization): + weighting_model: + doc: | + The weighting model specifies how mark data are mapped to a weight + per point/ion. For atom probe microscopy (APM) mark data are e.g. + which iontype an ion has. As an example, different models are used + which account differently for the multiplicity of a point/ion + during delocalization: + + * unity, all points/ions get the same weight 1. + * atomic_decomposition, points get as much weight as they + have atoms of a type in atomic_decomposition_rule, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotopic_decomposition_rule. + + enumeration: [unity, atomic_decomposition, isotopic_decomposition] + # if weighting_model == atomic_decomposition needs atomic_decomposition_rule + # if weighting_model == isotopic_decomposition needs isotopic_decomposition_rule + atomic_decomposition_rule(NXmatch_filter): + exists: optional # but required when weighting_model is atomic_decomposition + doc: | + A list of elements (via proton number) to consider for the + atomic_decomposition weighting model. + Elements must exist in the periodic table of elements and be + specified by their number of protons. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + In the case of elements this hashing rule has the advantage + that for elements the proton number is their hash value because + N is zero. + method: + doc: | + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + enumeration: [whitelist, blacklist] + match(NX_NUMBER): + doc: | + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_atomic]] + isotopic_decomposition_rule(NXmatch_filter): + exists: optional # but required when weighting model is isotopic_decomposition + doc: | + A list of isotopes (via proton and neutron number) to consider + for the isotopic_decomposition weighting model. + Isotopes must exist in the nuclid table. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + method: + doc: | + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + enumeration: [whitelist, blacklist] + match(NX_NUMBER): + doc: | + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_isotopic]] + normalization(NX_CHAR): + doc: | + How results of the kernel-density estimation were computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + enumeration: [total, candidates, composition, concentration] + weight(NX_NUMBER): + exists: optional + doc: | + Weighting factor, in atom probe, often termed multiplicity. + The weighting factor is the multiplier with which the integrated + intensity contribution from the point/ion gets multiplied. + The delocalization computes the integrated intensity for each + grid cell. Effectively, this is an explicitly evaluated kernel + method where each specific position of an ion is replaced by a + smoothing kernel. For atom probe weights are positive and integer + specifically the multiplicity of the ion, in accordance with the + respective rulesets as defined by weighting_model. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + grid(NXcg_grid): + doc: | + The discretized domain/grid on which the delocalization is applied. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: The total number of cells/voxels of the grid. + unit: NX_UNITLESS + origin(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, d]] + symmetry: + doc: | + The symmetry of the lattice defining the shape of the unit cell. + enumeration: [cubic] + cell_dimensions(NX_NUMBER): + doc: | + The unit cell dimensions according to the coordinate system + defined under coordinate_system. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, d]] + extent(NX_POSINT): + doc: | + Number of unit cells along each of the d unit vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, d]] + # (NXtransformations): + coordinate_system(NX_CHAR): + exists: optional + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + # should constraints on the grid be place here or not + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for + distinguishing identifiers for cells. Identifiers are defined + either implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + unit: NX_UNITLESS + bounding_box(NXcg_hexahedron_set): + doc: | + A tight axis-aligned bounding box about the grid. + is_axis_aligned(NX_BOOLEAN): + doc: | + For atom probe should be set to true. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + unit: NX_UNITLESS + hexahedron(NXcg_face_list_data_structure): + vertex_identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + unit: NX_UNITLESS + vertices(NX_NUMBER): + doc: | + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, 8], [2, 3]] + faces(NX_NUMBER): + doc: | + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, 6], [2, 4]] + xdmf_topology(NX_UINT): + doc: | + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 36]] + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 36]] + + number_of_boundaries(NX_POSINT): + exists: optional + doc: | + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + unit: NX_UNITLESS + boundaries(NX_CHAR): + exists: optional + doc: | + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + dimensions: + rank: 1 + dim: [[1, 6]] + boundary_conditions(NX_INT): + exists: optional + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 6]] + # ##MK::how to avoid storing it for once in NeXus for H5Web and + # for XDMF in ParaView ? + scalar_field_magnitude(NXdata): + doc: | + The result of the delocalization based on which subsequent + iso-surfaces will be computed. In commercial software so far + there is not a possibility to export such grid. + # ##MK::math notation + \@long_name: + exists: optional + \@signal: + \@axes: + \@xpos_indices: + \@ypos_indices: + \@zpos_indices: + intensity(NX_FLOAT): + dimensions: + rank: 3 + dim: [[1, n_z], [2, n_y], [3, n_x]] # silent flip here? + xpos(NX_FLOAT): + doc: | + Cell center of mass positions along x. + dimensions: + rank: 1 + dim: [[1, n_x]] + # ##MK::how to relate back that this x is paraprobe x? + ypos(NX_FLOAT): + doc: | + Cell center of mass positions along y. + dimensions: + rank: 1 + dim: [[1, n_y]] + zpos(NX_FLOAT): + doc: | + Cell center of mass positions along z. + dimensions: + rank: 1 + dim: [[1, n_z]] + xdmf_intensity(NX_FLOAT): + exists: optional + doc: | + Intensity of the field at given point + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_xyz]] + xdmf_xyz(NX_FLOAT): + exists: optional + doc: | + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_xyz], [2, 3]] + xdmf_topology(NX_NUMBER): + exists: optional # but when xdmf_xyz exists also xdmf_topology has to exist + doc: | + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 3*n_xyz]] # ##MK::better syntax needed + scalar_field_gradient(NXdata): + doc: | + The three-dimensional gradient nabla operator applied to + scalar_field_magnitude. + # ##MK::boundary conditions which type of accuracy + # ##MK::math notation + \@signal: + \@axes: + # ##MK::vector_indices, # ##MK: 3 + \@xpos_indices: # ##MK: 2 + \@ypos_indices: # ##MK: 1 + \@zpos_indices: # ##MK: 0 + \@long_name: + exists: optional + intensity(NX_FLOAT): + dimensions: + rank: 4 + dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] # silent flip here? + xpos(NX_FLOAT): + doc: | + Cell center of mass positions along x. + dimensions: + rank: 1 + dim: [[1, n_x]] + # ##MK::how to relate back that this x is paraprobe x? + ypos(NX_FLOAT): + doc: | + Cell center of mass positions along y. + dimensions: + rank: 1 + dim: [[1, n_y]] + zpos(NX_FLOAT): + doc: | + Cell center of mass positions along z. + dimensions: + rank: 1 + dim: [[1, n_z]] + xdmf_gradient(NX_FLOAT): + exists: optional + doc: | + The gradient vector. + unit: NX_ANY + dimensions: + rank: 2 + dim: [[1, n_xyz], [2, 3]] + xdmf_xyz(NX_FLOAT): + exists: optional + doc: | + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_xyz], [2, 3]] + xdmf_topology(NX_NUMBER): + exists: optional # but when xdmf_xyz exists also xdmf_topology has to exist + doc: | + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 3*n_xyz]] # ##MK::better syntax needed + kernel_size(NX_POSINT): + doc: | + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. + unit: NX_DIMENSIONLESS + #\@units: pixel + dimensions: + rank: 1 + dim: [[1, 3]] + # kernel_type(NX_CHAR): + # doc: | + # Functional form of the kernel (Ansatz function). + kernel_sigma(NX_FLOAT): + doc: | + Sigma of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + kernel_mu(NX_FLOAT): ##MK + doc: | + Expectation value of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + # ##MK:: + iso_surface(NXisosurface): + exists: optional + doc: | + An iso-surface is the boundary between two regions across which + the magnitude of a scalar field falls below/exceeds a threshold + magnitude phi. + For applications in atom probe microscopy the location and shape + of such a boundary (set) is typically approximated by + discretization. + This yields a complex of not necessarily connected geometric + primitives. Paraprobe-nanochem approximates this complex with + a soup of triangles. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + isovalue(NX_NUMBER): + doc: The threshold or iso-contour value. + unit: NX_ANY + marching_cubes(NXcg_marching_cubes): + doc: | + Details about the specific marching cubes algorithm + which was taken to compute the iso-surface. + The grid is the delocalization grid. + implementation: + doc: | + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. + triangle_soup(NXcg_triangle_set): + exists: optional + doc: | + The resulting triangle soup computed via marching cubes. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for + distinguishing triangles. Identifiers are defined either + implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + unit: NX_UNITLESS + triangles(NXcg_face_list_data_structure): + number_of_vertices(NX_POSINT): + doc: Number of vertices. + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + doc: Number of faces. + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + unit: NX_UNITLESS + vertices(NX_NUMBER): + doc: | + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + faces(NX_INT): + doc: | + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + xdmf_topology(NX_UINT): + doc: | + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_f_tri_xdmf]] + vertex_normal(NXcg_unit_normal_set): + exists: optional + normals(NX_FLOAT): + doc: | + Direction of each normal. + unit: NX_DIMENSIONLESS + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + exists: optional + doc: | + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + # edge_normal(NXcg_unit_normal_set): + # exists: optional + face_normal(NXcg_unit_normal_set): + exists: optional + normals(NX_FLOAT): + doc: | + Direction of each normal. + unit: NX_DIMENSIONLESS + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] + orientation(NX_UINT): + exists: optional + doc: | + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + gradient_guide_magnitude(NX_FLOAT): + doc: | + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :mathref:`$\sum_{x, y, z} {\nabla{c}_i}^2$`. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, k]] + # gradient_guide_quality(NX_FLOAT): + # doc: | + # Triangle normals are oriented in the direction of the + # gradient vector of the local delocalized scalar field. + # Sum of squared values of cross product of triangle normal + # construction. + # unit: NX_ANY + # dimensions: + # rank: 1 + # dim: [[1, k]] + gradient_guide_projection(NX_FLOAT): + doc: | + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose projection is almost perpendicular. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, k]] + area(NX_NUMBER): + exists: optional + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, j]] + edge_length(NX_NUMBER): + exists: optional + doc: | + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] + interior_angle(NX_NUMBER): + exists: optional + doc: | + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + center(NX_NUMBER): + exists: optional + doc: The center of mass of each triangle. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + volumetric_feature(NXprocess): + exists: optional + doc: | + Iso-surfaces of arbitrary scalar three-dimensional fields + can show a complicated topology. Paraprobe-nanochem can run + a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup. This yields a + set of connected features with their surfaces discretized + by triangles. Currently, the tool distinguishes at most + three types of features: + + 1. So-called objects, i.e. not necessarily watertight features + convex polyhedra + 2. So-called proxies, i.e. features that were replaced by a + proxy mesh and made watertight. + 3. Remaining triangle surface meshes of arbitrary shape and + cardinality. + + These features can be interpreted as microstructural features. + Some of them may be precipitates, some of them may be poles, + some of them may be segments of dislocation lines or other + crystal defects which are decorated (or not) with solutes. + + Each type of feature needs to be registered in the feature_type + dictionary. Type identifiers (keywords are integer), values + are human-readable names like object, proxy, undefined + triangle_cluster_identifier(NX_UINT): + doc: | + The identifier which the triangle_soup connectivity analysis + returned, which constitutes the first step of the + volumetric_feature identification process. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + feature_type_dict_keyword(NX_UINT): + exists: optional + doc: | + The array of keywords of feature_type dictionary. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_feature_dict]] + feature_type_dict_value(NX_CHAR): + exists: optional + doc: | + The array of values for each keyword of the + feature_type dictionary. + dimensions: + rank: 1 + dim: [[1, n_feature_dict]] + feature_type(NX_UINT): + doc: | + The array of controlled keywords, need to be from + feature_type_dict_keyword, which specify which type + each feature triangle cluster belongs to. + Keep in mind that not each feature is an object or proxy. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, j]] + feature_identifier(NX_UINT): + doc: | + The explicit identifier of features. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + # ##MK::a nice example why we need group-overarching symbols + # a symbol for triangles would not work as the analysis can + # hold multiple instances of iso_surface each with a different + # number of triangles and/or features! + # details about specific features + objects(NXms_three_d_feature_set): + exists: optional + doc: | + Details for features which are (closed) objects. + Identifier have to exist in feature_identifier + `:mathcal:$identifier \in feature_identifier$`. + # ##MK::constraints! + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + obb(NXcg_hexahedron_set): + exists: optional + doc: | + An oriented bounding box (OBB) to each object. + size(NX_FLOAT): + exists: optional + doc: | + Edge length of the oriented bounding box from largest + to smallest value. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + aspect(NX_FLOAT): + exists: optional + doc: | + Oriented bounding box aspect ratio. YX versus ZY. + # ##MK::which is which + unit: NX_DIMENSIONLESS + dimensions: + rank: 2 + dim: [[1, i], [2, 2]] + center(NX_NUMBER): + exists: optional + doc: | + Position of the geometric center, which often is but + not necessarily has to be the center_of_mass of the + hexahedrally-shaped sample/sample part. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + hexahedra(NXcg_face_list_data_structure): + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of hexahedra + when the main intention is to store the shape of the + hexahedra for visualization. + # ##MK::more details needed here + vertices(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] + # ##MK::again we have no effective way to pinpoint the n_rows + # ##MK::namely k != i each OBB has eight vertices + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, k]] + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, k]] + objects_close_to_edge(NXms_three_d_feature_set): + exists: optional + doc: | + Details for all those objects close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + composition(NXchemical_composition): + exists: optional + total(NX_NUMBER): + doc: | + Total (count) relevant for normalization. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + ION(NXion): + exists: [min, 0, max, infty] # ##MK::should be n_speci or 0 ! + charge(NX_INT): + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + count(NX_NUMBER): + doc: | + Count or weight which, when divided by total, + yields the composition of this element, isotope, + molecule or ion. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + objectID(NXcg_polyhedron_set): + exists: [min, 0, max, infty] # ##MK::cannot be more than i + polyhedron(NXcg_face_list_data_structure): + # number_of_vertices(NX_POSINT): + # number_of_faces(NX_POSINT): + # vertex_identifier_offset(NX_UINT): + # face_identifier_offset(NX_UINT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + # face_normals(NXcg_unit_normal_set): + face_normals(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles + ion_identifier(NX_UINT): + exists: optional + doc: | + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + objects_far_from_edge(NXms_three_d_feature_set): + exists: optional + doc: | + Details for all those objects far from edge, i.e. those + whose ions lay all at least threshold distant from a + modelled edge of the dataset. + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + composition(NXchemical_composition): + exists: optional + total(NX_NUMBER): + doc: | + Total (count) relevant for normalization. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + ION(NXion): + exists: [min, 0, max, infty] # ##MK::should be n_speci or 0 ! + charge(NX_INT): + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + count(NX_NUMBER): + doc: | + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + objectID(NXcg_polyhedron_set): + exists: [min, 0, max, infty] # ##MK::cannot be more than i + polyhedron(NXcg_face_list_data_structure): + # number_of_vertices(NX_POSINT): + # number_of_faces(NX_POSINT): + # vertex_identifier_offset(NX_UINT): + # face_identifier_offset(NX_UINT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + # face_normals(NXcg_unit_normal_set): + face_normals(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles + ion_identifier(NX_UINT): + exists: optional + doc: | + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + # linear_feature_identification(NXprocess): + # these would be polylines etc + proxies(NXms_three_d_feature_set): + exists: optional + doc: | + Details for features which are so-called proxies, i.e. objects + which have been reconstructed and combinatorially closed with + processing their partial triangulated_surface_mesh + (hole filling, refinement). + Identifier have to exist in feature_identifier + `:mathcal:$identifier \in feature_identifier$`. + # ##MK::constraints feature_identifier are a subset of the parent! + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + # obb ? + proxies_close_to_edge(NXms_three_d_feature_set): + exists: optional + doc: | + Details for those proxies close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + Identifier have to exist in feature_identifier + `:mathcal:$identifier \in feature_identifier$`. + # ##MK::constraints! + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + composition(NXchemical_composition): + exists: optional + total(NX_NUMBER): + doc: | + Total (count) relevant for normalization. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + ION(NXion): + exists: [min, 0, max, infty] # ##MK::should be n_speci or 0 ! + # charge(NX_INT): + # isotope_vector(NX_UINT): + count(NX_NUMBER): + doc: | + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + objectID(NXcg_polyhedron_set): + exists: [min, 0, max, infty] + polyhedron(NXcg_face_list_data_structure): + # number_of_vertices(NX_POSINT): + # number_of_faces(NX_POSINT): + # vertex_identifier_offset(NX_UINT): + # face_identifier_offset(NX_UINT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + # face_normals(NXcg_unit_normal_set): + face_normals(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles + ion_identifier(NX_UINT): + exists: optional + doc: | + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i] + proxies_far_from_edge(NXms_three_d_feature_set): + exists: optional + doc: | + Details for those proxies far from edge, i.e. those whose + ions lay all at least threshold distant from a + modelled edge of the dataset. + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + composition(NXchemical_composition): + exists: optional + total(NX_NUMBER): + doc: | + Total (count) relevant for normalization. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + ION(NXion): + exists: [min, 0, max, infty] # ##MK::should be n_speci or 0 ! + # charge(NX_INT): + # isotope_vector(NX_UINT): + count(NX_NUMBER): + doc: | + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + objectID(NXcg_polyhedron_set): + exists: [min, 0, max, infty] + polyhedron(NXcg_face_list_data_structure): + # number_of_vertices(NX_POSINT): + # number_of_faces(NX_POSINT): + # vertex_identifier_offset(NX_UINT): + # face_identifier_offset(NX_UINT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + # face_normals(NXcg_unit_normal_set): + face_normals(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] # not k but predictably related to number_of_faces if these are triangles + ion_identifier(NX_UINT): + exists: optional + doc: | + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i] + interface_modelling(NXprocess): + exists: optional + ion_multiplicity(NX_UINT): + exists: optional + doc: | + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + decorator_multiplicity(NX_UINT): + exists: optional + doc: | + The multiplicity whereby the ion position is accounted + for when the ion is considered´one which is a decorator + of the interface. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + initial_interface: # ##MK::(NXcg_plane_set): + exists: optional + doc: | + The equation of the plane that is fitting initially. + point_normal_form(NX_FLOAT): + doc: | + The four parameter ax + by + cz + d = 0 which define the plane. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 4]] + MESH_CURR_PRE_DCOM_STEP(NXcg_triangle_set): + exists: [min, 0, max infty] + doc: | + The triangle surface mesh representing the interface model. + Exported at some iteration before the next DCOM step. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + triangles(NXcg_face_list_data_structure): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + edge_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + vertices(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + # ##MK::vertex_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + doc: Direction of each normal + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + vertex_normal(NXcg_unit_normal_set): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + doc: Direction of each normal + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + edge_length(NX_NUMBER): + doc: | + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + interior_angle(NX_NUMBER): + doc: | + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + MESH_CURR_POST_DCOM_STEP(NXcg_triangle_set): + exists: [min, 0, max infty] + doc: | + The triangle surface mesh representing the interface model. + Exported at some iteration after the next DCOM step. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + triangles(NXcg_face_list_data_structure): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + vertices(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + # ##MK::vertex_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + doc: Direction of each normal + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + vertex_normal(NXcg_unit_normal_set): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + doc: Direction of each normal + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + + area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + edge_length(NX_NUMBER): + doc: | + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + interior_angle(NX_NUMBER): + doc: | + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + + composition_analysis(NXprocess): + exists: optional + xdmf_cylinder(NXcg_polyhedron_set): + doc: | + The ROIs are defined as cylinders for the computations. + To visualize these though we discretize them into regular n-gons. + Using for instance a 360-gon, i.e. a regular n-gon with 360 + edges resolves the lateral surface of each cylinder very finely + so that they are rendered smoothly in visualization software. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + center(NX_NUMBER): + doc: | + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + roi_identifier(NX_UINT): + doc: | + Integer which specifies the first index to be used for distinguishing + ROI cylinder. Identifiers are defined explicitly. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + polyhedra(NXcg_face_list_data_structure): + exists: [min, 0, max, 1] + edge_contact(NX_UINT): + exists: optional + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + number_of_atoms(NX_UINT): + exists: optional + doc: | + The number of atoms in each ROI. + # ##MK::decomposed? + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + number_of_ions(NX_UINT): + exists: optional + doc: | + The number of ions in each ROI. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + orientation(NX_FLOAT): + exists: optional + doc: | + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + ROI(NXcollection): + exists: [min, 0, max, infty] + signed_distance(NX_FLOAT): + doc: In the direction of the ROI. + isotope(NX_UINT): + doc: Hashvalue + # ##MK::#define MYCHM_DATA_ISRF_TSKS_TSCL_OBJ_ROICYL_ROIID "RoiCylinderID" + # ##MK::#define MYCHM_DATA_ISRF_TSKS_TSCL_OBJ_ROICYL_OBJID "RoiCylinderObjectID" +# ##MK::end of the tool-specific section + + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml index b40032b3d7..1e7f5e8153 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml @@ -1,10 +1,12 @@ category: application doc: | - Results of a paraprobe-ranger tool run in atom probe microscopy. + Results of a paraprobe-ranger tool run. symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. n_ions: The total number of ions in the reconstruction. - n_ivec: The maximum number of atoms per molecular ion type. + n_ivec_max: | + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. NXapm_paraprobe_results_ranger: (NXentry): # by default for appdefs the value of the exists keyword is required @@ -36,11 +38,18 @@ NXapm_paraprobe_results_ranger: to this analysis. analysis_description: exists: optional - doc: Possibility for leaving a free-text description about this analysis. - time_stamp(NX_DATE_TIME): + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. config_filename: doc: | The absolute path and name of the config file for this analysis. @@ -48,6 +57,18 @@ NXapm_paraprobe_results_ranger: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + status(NX_CHAR): + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] (NXuser): exists: recommended doc: | @@ -78,10 +99,11 @@ NXapm_paraprobe_results_ranger: (NXtransformations): exists: [min, 1, max, infty] doc: | - The individual coordinate systems which used. - fields should be prefixed with a prefix taken from an - enumeration which details the individual coordinate systems: + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + * paraprobe * lab * specimen * laser @@ -93,16 +115,26 @@ NXapm_paraprobe_results_ranger: # ##MK::begin of the tool-specific section (NXprocess): exists: [min, 0, max, 1] - # ##MK::number_of_ion_types(NX_POSINT): - # ##MK::maximum_number_of_atoms_per_molecular_ion(NX_POSINT): - use_existent_ranging(NXprocess): + apply_existent_ranging(NXprocess): exists: [min, 0, max, 1] doc: | Paraprobe-ranger loads the iontypes and evaluates for each ion on which iontype it matches. If it matches on none, the ion is considered of the default unknown type with a 0 as its respective value in the iontypes array. - (NXion): + # ##MK::number_of_ion_types(NX_POSINT): + maximum_number_of_atoms_per_molecular_ion(NX_POSINT): + doc: | + The length of the isotope_vector used to describe molecular ions. + units: NX_UNITLESS + ION(NXion): + exists: [min, 1, max, 256] + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + exists: recommended + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): + charged_ION(NXion): exists: [min, 1, max, 256] isotope_vector(NX_UINT): nuclid_list(NX_UINT): @@ -112,12 +144,74 @@ NXapm_paraprobe_results_ranger: iontypes(NX_UINT): doc: | The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. + order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + is build are considered. By contrast, charged_iontypes takes + into account also the charge state. unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_ions]] - + charged_iontypes(NX_UINT): + doc: | + The iontype ID for each ion that was best matching, stored in the + order of the evaporation sequence ID. For the here computed + charged_iontypes the information for each (molecular) ion defined + in e.g. RNG or RRNG files is analyzed for which differently charge + states are possible. As an example while iontypes might only consider + if an ion is Al charged_iontypes will resolve if it is Al1+, Al2+, or + Al3+. To decide the charge state a recursive algorithm is used which + enumerates first all possible isotopic variants of a given molecular + ion build from a specific set of elements. All variants are then + analyzed for their natural abundance and filtered. The sub-set of + all significantly abundant variants is inspected if their charge + states are all the same. If only one significant variant is found + its charge state is assumed the relevant. If multiple significant + variants are found and all their charge states is the same this + charge state will be the decisive one. However, if multiple variants + are found and their charge state differs such a case highlights that + the charge state analysis is underconstrained and thus the charge + state is set to 0. Underconstrained cases are possible because + an arbitrary combination of elements into a molecular ion that is + constrained only by an additional single interval of mass-to-charge + state ratios is not necessarily sufficient. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies exactly all those ions ranged irrespective + the type they ended up with. + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] molecular_ion_search(NXprocess): exists: [min, 0, max, 1] doc: | @@ -194,6 +288,28 @@ NXapm_paraprobe_results_ranger: dimensions: rank: 1 dim: [[1, i]] + + check_existent_ranging(NXprocess): + exists: [min, 0, max, 1] + doc: | + Paraprobe-ranger loads iontypes and evaluates for each ion on which + iontype it matches. If it matches on none, the ion is considered of + the default unknown type with a 0 as its respective value in the + iontypes array. In contrast to use_existent_ranging this process + does neither needs measured ion position nor mass-to-charge-state + ratio values. + # ##MK::number_of_ion_types(NX_POSINT): + maximum_number_of_atoms_per_molecular_ion(NX_POSINT): + doc: | + The length of the isotope_vector used to describe molecular ions. + units: NX_UNITLESS + charged_ION(NXion): + exists: [min, 1, max, 256] + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + exists: recommended + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): # ##MK::end of the tool-specific section performance(NXcs_profiling): @@ -269,12 +385,12 @@ NXapm_paraprobe_results_ranger: number_of_threads(NX_POSINT): # exists: recommended doc: | - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. number_of_gpus(NX_POSINT): # exists: recommended doc: | - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. max_virtual_memory_snapshot(NX_NUMBER): exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml new file mode 100644 index 0000000000..3577368866 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml @@ -0,0 +1,233 @@ +category: application +doc: | + Results of a paraprobe-selector tool run. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: The total number of ions in the reconstruction. + +NXapm_paraprobe_results_selector: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_selector] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + status(NX_CHAR): + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: Details about the coordinate system conventions used. + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + +# ##MK::begin of the tool-specific section + (NXprocess): + exists: [min, 0, max, 1] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset + were selected to become included in the region-of-interest (ROI). + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + +# ##MK::end of the tool-specific section + + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml new file mode 100644 index 0000000000..c3e7af8ede --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml @@ -0,0 +1,290 @@ +category: application +doc: | + Results of a paraprobe-spatstat tool run. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: The total number of ions in the reconstruction. + +NXapm_paraprobe_results_spatstat: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_spatstat] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + status(NX_CHAR): + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: Details about the coordinate system conventions used. + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + +# ##MK::begin of the tool-specific section + (NXprocess): + exists: [min, 0, max, 1] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed. + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + iontypes_randomized(NX_UINT): + doc: | + The iontype ID for each ion that was assigned to each ion during + the randomization of the ionlabels. Iontype labels are just permuted + but the total number of values for each iontype stay the same. + + The order matches the iontypes array from a given ranging results + as is specified in the configuration settings inside the specific + config_filename that was used for this spatstat analysis. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + + knn(NXprocess): + exists: optional + doc: | + K-nearest neighbor statistics. + distance(NX_FLOAT): + doc: Right boundary of the binning. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, i]] + probability_mass(NX_FLOAT): + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, i]] + accumulated(NX_FLOAT): + doc: Cumulated + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, i]] + + rdf(NXprocess): + exists: optional + doc: | + Radial distribution statistics. + distance(NX_FLOAT): + doc: Right boundary of the binning. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, i]] + probability_mass(NX_FLOAT): + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, i]] + accumulated(NX_FLOAT): + doc: Cumulated + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, i]] + +# ##MK::end of the tool-specific section + + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml new file mode 100644 index 0000000000..0473cf9d3e --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml @@ -0,0 +1,405 @@ +category: application +doc: | + Results of a paraprobe-surfacer tool run. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: The total number of ions in the reconstruction. + n_v_tri: The number of vertices of the alpha complex. + n_f_tri: The number of faces of the alpha complex. + n_f_tri_xdmf: | + The total number of XDMF values to represent all faces of triangles via XDMF. + n_f_tet_xdmf: | + The total number of XDMF values to represent all faces of tetrahedra via XDMF. +NXapm_paraprobe_results_surfacer: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_surfacer] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + status(NX_CHAR): + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: Details about the coordinate system conventions used. + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + +# ##MK::begin of the tool-specific section + (NXprocess): + exists: [min, 0, max, 1] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed. Computations of alpha complexes may have filtered this + ion set further but this process is deterministic. + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. The mask may be 0 for most. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + POINT_SET_WRAPPING(NXprocess): + exists: [min, 0, max, infty] + doc: | + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. + # (NXcg_grid): currently we do not store the underlying grid + # for eventually performed preprocessing + alpha_complex(NXcg_alpha_complex): + exists: [min, 0, max, infty] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + the alpha complex was then in fact computed. This window + can be different to the entire window as irrelevant ions might + have been filtered out to reduce the computational costs of the + alpha complex analysis. + # filtered in addition to the ROI or again the entire dataset + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + dimensionality(NX_UINT): + unit: NX_UNITLESS + enumeration: [2, 3] + type: + enumeration: [convex_hull, alpha_shape, alpha_wrapping, other, undefined] + mode: + enumeration: [general, regularized] + alpha(NX_NUMBER): + unit: NX_LENGTH + offset(NX_NUMBER): + exists: optional # but is required when type is alpha_wrapping + unit: NX_LENGTH + triangle_set(NXcg_triangle_set): + exists: optional + doc: | + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distin- + guishing triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined + on the interval [identifier_offset, identifier_offset+c-1]. + unit: NX_UNITLESS + triangles(NXcg_face_list_data_structure): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + doc: Number of vertices. + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + doc: Number of faces. + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v_tri], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f_tri], [2, 3]] + xdmf_topology(NX_UINT): + doc: | + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_f_tri_xdmf]] + is_watertight(NX_BOOLEAN): + exists: optional + doc: | + Do the triangles define a triangulated surface mesh which + is watertight? + volume(NX_FLOAT): + exists: optional + doc: | + The volume which the triangulated surface mesh encloses + provided that the mesh is watertight. + unit: NX_VOLUME + interior_tetrahedra(NXcg_tetrahedron_set): + exists: optional + doc: | + The set of tetrahedra which represent the interior volume of the + complex if that is a closed 2-manifold. + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distin- + guishing tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined + on the interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + unit: NX_UNITLESS + volume(NX_FLOAT): + exists: optional + doc: | + The accumulated volume of all interior tetrahedra. + unit: NX_VOLUME + tetrahedra(NXcg_face_list_data_structure): + number_of_vertices(NX_POSINT): + doc: Number of vertices. + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + doc: Number of faces. + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v_tet], [2, 3]] + xdmf_topology(NX_UINT): + doc: | + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_f_tet_xdmf]] + + TRIANGLE_SET_WRAPPING(NXprocess): + exists: [min, 0, max, infty] + doc: | + In the future we may want to wrap other primitives + like triangles or polylines. +# ##MK::end of the tool-specific section + + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml new file mode 100644 index 0000000000..dc486643d8 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml @@ -0,0 +1,591 @@ +category: application +doc: | + Results of a paraprobe-tessellator tool run. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: The total number of ions in the reconstruction. + n_f_xdmf: The total number of facets/polygons defining the tessellation. + +NXapm_paraprobe_results_tessellator: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + +# ##MK::begin of the tool-specific section + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_tessellator] +# ##MK::end of the tool-specific section + + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + exists: optional + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + status(NX_CHAR): + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: Details about the coordinate system conventions used. + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + +# ##MK::begin of the tool-specific section + (NXprocess): + exists: [min, 0, max, 1] + voronoi_tessellation(NXprocess): + doc: | + The tool can be used to compute a Voronoi tessellation the entire + or a sub-set of the reconstruction. The point cloud in the ROI is + wrapped into a tight axis-aligned bounding box. The tool detects if + Voronoi cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed. + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + wall_contact_global(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by the global axis-aligned bounding box, i.e. boundaries + of the threads are ignored. + number_of_points(NX_UINT): + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + # ##MK::optional documenting of touching on thread-local boundaries + wall_contact_left(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative x axis of the paraprobe coordinate + system as the outer unit normal. + number_of_points(NX_UINT): + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + wall_contact_right(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The right wall has the positive x axis of the paraprobe coordinate + system as the outer unit normal. + number_of_points(NX_UINT): + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + wall_contact_front(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The front wall has the negative y axis of the paraprobe coordinate + system as the outer unit normal. + number_of_points(NX_UINT): + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + wall_contact_rear(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The rear wall has the positive y axis of the paraprobe coordinate + system as the outer unit normal. + number_of_points(NX_UINT): + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + + wall_contact_bottom(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative z axis of the paraprobe coordinate + system as the outer unit normal. + number_of_points(NX_UINT): + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + + wall_contact_top(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the positive z axis of the paraprobe coordinate + system as the outer unit normal. + number_of_points(NX_UINT): + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + # which does paraprobe use + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + + voronoi_cells(NXcg_polyhedron_set): + exists: optional + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + volume(NX_NUMBER): + doc: Interior volume + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + process_identifier(NX_POSINT): + exists: optional + doc: | + By which MPI process was the Voronoi cell computed. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + thread_identifier(NX_POSINT): + exists: optional + doc: | + By which OpenMP thread was the Voronoi cell computed. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + number_of_faces(NX_POSINT): + exists: optional + doc: | + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + # (NXtransformations): + # exists: optional + # doc: | + # Reference to or definition of a coordinate system with + # which the qualifiers and mesh data are interpretable. + # substantially more detailed descriptors of the shape, the mesh + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + unit: NX_UNITLESS + identifier(NX_INT): + exists: optional + doc: Integer used to distinguish polyhedra for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + polyhedra(NXcg_face_list_data_structure): + exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of polyhedra when + the main intention is to store the shape of the polyhedra for + visualization. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + doc: Number of vertices. + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + doc: Number of faces. + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + xdmf_topology(NX_UINT): + doc: | + A sequence of always first an XDMF topology type key, followed + by the XDMF number of vertices of the polygon, followed by + the vertex identifier which define the facet polygon. First + we store the polygon of the first facet of the first cell, then + the second facet of the first cell, until the last facet of the + first cell, followed by the first facet of the second cell, + and so on and so forth. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + xdmf_cell_identifier(NX_UINT): + doc: | + A sequence of cell identifier so that each facet is associated + with its cell because of which it is then possible to segment + out cells three-dimensionally based on cell i.e. evaporation_id. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_f_xdmf]] + + + + + + + + + + + + + +# ##MK::end of the tool-specific section + + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml index beae6f6a71..8f866fde6b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml @@ -1,9 +1,9 @@ category: application doc: | - Results of a paraprobe-transcoder tool run in atom probe microscopy. + Results of a paraprobe-transcoder tool run. symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: Total number of ions collected. + n_ions: The total number of ions in the reconstruction. n_ivec_max: | Maximum number of allowed atoms per (molecular) ion (fragment). Needs to match maximum_number_of_atoms_per_molecular_ion. @@ -40,11 +40,18 @@ NXapm_paraprobe_results_transcoder: to this analysis. analysis_description: exists: optional - doc: Possibility for leaving a free-text description about this analysis. - time_stamp(NX_DATE_TIME): + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. config_filename: doc: | The absolute path and name of the config file for this analysis. @@ -52,6 +59,18 @@ NXapm_paraprobe_results_transcoder: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + status(NX_CHAR): + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] (NXuser): exists: recommended doc: | @@ -382,12 +401,12 @@ NXapm_paraprobe_results_transcoder: number_of_threads(NX_POSINT): # exists: recommended doc: | - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. number_of_gpus(NX_POSINT): # exists: recommended doc: | - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. max_virtual_memory_snapshot(NX_NUMBER): exists: recommended diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 4c855eeb12..a43ca1fb0c 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -277,9 +277,10 @@ doc: | research data management systems to show a visual representation of some aspect of the content of the EM session. Default plottables not intended to serve every possible analysis and - visualization demand but be a preview. We made this choice because what constitutes - a useful default plot is often a matter of interpretation, somewhat of personal taste, - and community standards. In effect, default plottables are case- and method-specific. + visualization demand but be a preview. We made this choice because what + constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. Usually a session at a microscope is used to collect multiple signals and images. Examples for possible default plottables could be arbitrarily @@ -302,16 +303,16 @@ doc: | field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) * Spectra (X-ray quanta or Auger electron counts) * These data are in virtually all cases a result of some numerical processing. - It makes sense to name these data and processing tasks with a controlled vocabulary, - e.g. SE (secondary electron), BSE (back-scattered electron), Kikuchi, - X-ray, Auger, Cathodolum(inescence) etc. + It makes sense to name these data and processing tasks with a controlled + vocabulary, e.g. SE (secondary electron), BSE (back-scattered electron), + Kikuchi, X-ray, Auger, Cathodolum(inescence) etc. A key question often asked with EM experiments is how the actual (meta)data should be stored (in memory or on disk). To this end the schema, here makes no specific assumptions, not even that all the fields/group of a schema instance have to be stored at all into a single file. Instead, the schema specifies the - relations between metadata, some of the constraints and conditions on how the data - should be formatted, what the data conceptually represent, and which terms + relations between metadata, some of the constraints and conditions on how the + data should be formatted, what the data conceptually represent, and which terms (controlled vocabulary) is practical to store to index specific quantities. In effect, the application definition is a graph which describes how @@ -342,7 +343,8 @@ NXem: that specifies the application definition. # enumeration: [sha_256_hash] definition: - doc: NeXus NXDL schema to which this file conforms. + doc: | + NeXus NXDL schema to which this file conforms. enumeration: [NXem] experiment_identifier: doc: | @@ -368,7 +370,7 @@ NXem: when the microscope session started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact - duration is not relevant - this start time field should be used. + duration is not relevant - this start_time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and @@ -455,7 +457,8 @@ NXem: exists: recommended doc: | Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform orcid_platform: exists: recommended doc: | @@ -488,7 +491,7 @@ NXem: # ID: -> maps to name # name: -> short_title # user: -> not matched right now - # citation: doi ->why relevant, should be solved by the RDM graph management system + # citation: doi ->why relevant, should be solved by RDMS doc: | A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. @@ -496,7 +499,8 @@ NXem: doc: | A qualifier whether the sample is a real one or a virtual one (in a computer simulation) - enumeration: [experiment, simulation] # MK:: declared_by_vendor I would rather expect this for a substance + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance # COMPONENT.yaml # SUBSTANCE: # QUANTIFY @@ -527,15 +531,16 @@ NXem: was placed into the microscope at the beginning of the session. In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a sub-set - of the entire sample history, i.e. what you would consider are the key steps - and relevant information about the specimen, its material, microstructure, - thermo-chemo-mechanical processing state, and the details of the preparation. + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. Specific details about eventual physically-connected material like embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly discouraged - because it leads to eventually non-machine-actionable + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable data. preparation_date(NX_DATE_TIME): doc: | @@ -544,8 +549,8 @@ NXem: Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over for - the analysis. At the point it enters the microscope the session starts. + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. At the point it enters the microscope the session starts. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as @@ -559,11 +564,14 @@ NXem: Possibility to give an abbreviation or alias of the specimen name field. atom_types: doc: | - Use Hill's system for listing elements of the periodic table which are inside or attached - to the surface of the specimen and thus relevant from a scientific point of view. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. - The purpose of the field is to offer materials database systems an opportunity to parse - the relevant elements without having to interpret these from the sample history. + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample thickness(NX_FLOAT): doc: | @@ -587,11 +595,7 @@ NXem: # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM # are the ibeam description capabilities not sufficient enough? - description: - exists: optional - doc: | - Discouraged free-text field in case properly designed records - for the sample_history are not available. + density(NX_FLOAT): exists: optional doc: | @@ -604,6 +608,11 @@ NXem: of the specimen. unit: NX_ANY # \@units: g/cm^3 + description: + exists: optional + doc: | + Discouraged free-text field in case properly designed records + for the sample_history are not available. (NXdata): exists: optional doc: | @@ -612,6 +621,7 @@ NXem: (NXcoordinate_system_set): exists: recommended TRANSFORMATIONS(NXtransformations): + exists: [min, 0, max, infty] # in what follows each component of the instrument might be equipped with an NXmonitor (NXmonitor): exists: optional @@ -634,8 +644,8 @@ NXem: For example it is not relevant to store in each event's electron_gun group again the details of the gun type and manufacturer but only the high-voltage if for that event the high-voltage was different. If for all events - the high-voltage was the same it is not even necessary to include an electron_gun - section in the event. + the high-voltage was the same it is not even necessary to include an + electron_gun section in the event. Individual sections of specific type should have the following names: @@ -658,6 +668,10 @@ NXem: Location of the lab or place where the instrument is installed. Using GEOREF is preferred. (NXfabrication): + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -666,6 +680,10 @@ NXem: exists: [min, 1, max, 1] (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended electron_gun(NXsource): @@ -673,14 +691,24 @@ NXem: exists: recommended (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended voltage(NX_FLOAT): emitter_type: + exists: recommended + enumeration: ["thermionic", "schottky", "field_emission"] (NXaperture_em): - exists: recommended + exists: [min, 0, max, infty] (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended value(NX_NUMBER): @@ -688,13 +716,17 @@ NXem: description: exists: optional (NXlens_em): - exists: recommended + exists: [min, 0, max, infty] doc: | If the lens is described at least one of the fields voltage, current, or value should be defined. # a classical case where we want at least one field of multiple to exist (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended voltage(NX_NUMBER): @@ -710,6 +742,10 @@ NXem: exists: optional (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended (NXaberration): @@ -744,6 +780,10 @@ NXem: exists: [min, 0, max, 2] (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended ion_gun(NXsource): @@ -751,19 +791,30 @@ NXem: exists: recommended (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended emitter_type: probe(NXion): - isotope_names(NX_UINT): charge_state(NX_INT): - exists: optional + exists: recommended + isotope_vector(NX_UINT): + exists: recommended + name: + exists: recommended voltage(NX_FLOAT): current(NX_FLOAT): (NXaperture_em): exists: recommended (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended value(NX_NUMBER): @@ -783,17 +834,25 @@ NXem: value(NX_NUMBER): exists: recommended ebeam_deflector(NXscanbox_em): - exists: recommended + exists: [min, 0, max, infty] (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended pixel_time(NX_FLOAT): exists: recommended ibeam_deflector(NXscanbox_em): - exists: recommended + exists: [min, 0, max, infty] (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended (NXoptical_system_em): @@ -804,6 +863,7 @@ NXem: exists: optional defocus(NX_NUMBER): exists: recommended + # this is c_1_0 of aberration_correction semi_convergence_angle(NX_NUMBER): exists: recommended working_distance(NX_FLOAT): @@ -816,7 +876,7 @@ NXem: # e.g. Nion Co. magboard settings # instances of NXoptical system can be placed here and specific for # each NXevent_data_em instance if desired - (NXdetector): + DETECTOR(NXdetector): # ##MK::eventually only adding (NXfabrication) and the new docstring # is needed, will the rest be inferred automatically? exists: [min, 1, max, infty] @@ -839,6 +899,10 @@ NXem: name: (NXfabrication): exists: recommended + vendor: + exists: recommended + model: + exists: recommended identifier: exists: recommended capabilities: @@ -981,21 +1045,229 @@ NXem: instance called ebsd_camera. # a collection of images take and group under this event # NEW ISSUE: should this only be one instance for a given event? - (NXimage_set_em_se): + (NXimage_set_em): exists: optional - (NXimage_set_em_bse): - exists: optional - (NXimage_set_em_bf): + (NXprocess): + mode: + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 3 + # dim: [[1, n_images], [2, n_y], [3, n_x]] + axis_image_identifier(NX_UINT): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_images]] + axis_y(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + (NXimage_set_em_adf): exists: optional - (NXimage_set_em_df): + (NXprocess): + exists: recommended + adf_inner_half_angle(NX_FLOAT): + exists: recommended # should be required + adf_outer_half_angle(NX_FLOAT): + exists: recommended # should be required + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + axis_image_identifier(NX_UINT): + \@long_name: + # dimensions: + # rank: 3 + # dim: [[1, n_images], [2, n_y], [3, n_x]] + axis_y(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + (NXspectrum_set_em_xray): exists: optional - (NXimage_set_em_adf): + # there should also be more NXprocess instances + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 3 + # dim: [[1, n_y], [2, n_x], [3, n_photon_energy]] + axis_y(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + axis_photon_energy(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_photon_energy]] + summary(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_photon_energy]] + axis_photon_energy(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_photon_energy]] + indexing(NXprocess): + exists: optional + # ##MK:: much content of the base class has not been added although + # should be considered and made recommended at least + ELEMENTNAME(NXprocess): + exists: [min, 1, max, 256] + summary(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 2 + # dim: [[1, n_y], [2, n_x]] + axis_y(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + (NXspectrum_set_em_eels): exists: optional + # there should be more NXprocess instances + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 3 + # dim: [[1, n_y], [2, n_x], [3, n_energy_loss]] + axis_y(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + axis_energy_loss(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_energy_loss]] + summary(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_energy_loss]] + axis_energy_loss(NX_NUMBER): + # dimensions: + # rank: 1 + # dim: [[1, n_energy_loss]] + \@long_name: + # base classes for which we have at the moment no example implemented + # consider to replace se, bse, bf, df, chamber, ronchigram, by generic NXimage_set_em (NXimage_set_em_kikuchi): exists: optional - (NXspectrum_set_em_xray): + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 3 + # dim: [[1, n_p], [2, n_y], [3, n_x]] + pattern_identifier(NX_UINT): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + axis_y(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + scan_point_identifier(NX_UINT): + # \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # no summary because this will be handled by EBSD + + + (NXimage_set_em_se): exists: optional - (NXspectrum_set_em_eels): + (NXimage_set_em_bse): + exists: optional + (NXimage_set_em_bf): + exists: optional + (NXimage_set_em_df): exists: optional (NXspectrum_set_em_auger): exists: optional @@ -1009,9 +1281,9 @@ NXem: exists: optional (NXimage_set_em_chamber): exists: optional - # a collection of specific details about state of the microscope em_lab(NXinstrument): + exists: optional (NXebeam_column): exists: [min, 0, max, 1] electron_gun(NXsource): @@ -1028,7 +1300,7 @@ NXem: exists: recommended value(NX_NUMBER): exists: recommended - (NXcorrector_cs): + aberration_correction(NXcorrector_cs): exists: optional applied: (NXaberration): @@ -1063,14 +1335,14 @@ NXem: exists: [min, 0, max, 2] ion_gun(NXsource): exists: optional - emitter_type: - exists: recommended probe(NXion): exists: recommended - isotope_names(NX_UINT): - exists: recommended charge_state(NX_INT): - exists: optional + exists: recommended + isotope_vector(NX_UINT): + exists: recommended + name: + exists: recommended voltage(NX_FLOAT): exists: recommended current(NX_FLOAT): @@ -1115,7 +1387,7 @@ NXem: (NXpump): exists: optional (NXstage_lab): - # tricky for arbitrary design we cannot enforce all the below to exist at all + exists: optional position(NX_FLOAT): exists: recommended rotation(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml new file mode 100644 index 0000000000..fdbd5c3a6f --- /dev/null +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -0,0 +1,984 @@ +category: application +symbols: + n_op: Number of arguments per orientation for given parameterization. + n_sc: Number of scan points. + n_z: Number of pixel along the slowest changing dimension for a rediscretized, i.e. standardized default orientation mapping. + n_y: Number of pixel along slow changing dimension for a rediscretized i.e. standardized default orientation mapping. + n_x: Number of pixel along fast changing dimension for a rediscretized i.e. standardized default orientation mapping. +# what to do when multiple pattern are averaged into one before the beam moves further? +doc: | + Application definition for indexing Kikuchi pattern into orientation maps. + + For so-called three-dimensional or serial sectioning EBSD it is necessary to + follow a sequence of specimen, surface preparation, and data collection steps. + Results from individual measurements are combined into one reconstructed stack. + In this case, users should collect the data for each serial sectioning step + via an own instance of NXebsd. To report the resulting post-processing of this + set of EBSD (and/or orientation per scanned material point) users should use + an instance of the NXms application definition. This application definition + enables users to describe three-dimensional microstructures and features + identified in these microstructures. The term microstructure is used here + but is not restricted to features at the micron scale. + Eventual tomography methods also use such a workflow because first diffraction + images are collected and then these are indexed and composed into a 3D + orientation mapping. The here proposed NXebsd application definition can + give some conceptual ideas how this splitting between measurement and + post-processing can be granularized also for these techniques. +# also NXtkd, NXhedm, etc... ? the IUCr DMI should work on an e.g. NXhedm +# if we think of the metadata/data graph collected from the microscope session +# documented in NXem may have only few relations between nodes of an instance of +# NXebsd and NXem. Key data from NXem which many users would expect to find +# also enumerated in NXebsd could be settings of the microscope, timestamp data +# when tasks where performed at the microscope using which specimen, operated +# and prepared by whom. These latter pieces of information are all available +# in NXem but if we were to make fields in NXem deep inside an instance +# of NXem_event_data required than we factually more and more granularize and +# pull in steps of detailed numerical post-processing which arguably is not +# any longer at all necessarily related to the microscope session. +# We know many cases, see Marc de Graef's group or Hakon Anes with Knut +# Marthinsen at NTNU who spent much longer with a collected dataset in post- +# processing than at the microscope so there should be the flexibilty that +# documentation of the actual microscope session and the post-processing of +# some of the data therein collected remain coupled but not too repetively and +# strictly! +# one idea could be to use a reference to another NeXus file in the NXebsd +# file instance and the NXem file instance. +# by ho to the many metadata and data from a post-processing of ebsd +# data, namely the link to the microscope session where they were collected +# measurement: # name of file with raw microscope data +# \@version: # hash of file with raw microscope data +# on the other hand there are specific metadata to store with taking EBSD +# mappings +# tilt_angle(NX_FLOAT): +# maybe better make this integrated into the NXtransformations of the stage_lab, a stage_lab event? +# beam_position(NXcg_point_set): +# (NXdetector): +# exposure_time(NX_FLOAT): +# unit: NX_TIME +# gain(NX_FLOAT): +# ##MK how does a gain translate mathematically an input signal into an intensity signal? +# insertion_distance(NX_FLOAT): +# unit: NX_LENGTH +# ##MK a coordinate system for the detector in the NXcoordinate_system_set +# drift_correction(NX_BOOLEAN): ##MK?? +# move the next two rather to detector +# acquisition_speed(NX_FLOAT): +# doc: | +# Average number of patterns taken per second averaged over entire set. +# unit: NX_FREQUENCY +# acquisition_time(NX_FLOAT): +# doc: Wall-clock time the acquisition took. +# unit: NX_TIME + +# WHERE TO PLACE THE SCAN POSITIONS ? THEY SHOULD BE IN NXem +# THIS IS REALLY ABOUT CULTURE CHANGE DO NOT EXPECT TO FIND EVERYTHING +# IN SOME AD HOC COMPOSED FILE JUST BECAUSE THIS IS EASY BUT HAVE A TOOL +# WHERE YOU CAN QUERY WHERE YOU CAN FIND THESE VALUES. +# E.G. IF AN API CALL TO YOUR RDMS FOR A GIVEN EXPERIMENT WILL GIVE YOU THE +# SCAN POSITIONS ITS LIKE QUERYING A DATABASE AND NOBODY WOULD WASTE TIME +# WITH EXPORTING/IMPORTING THESE FROM LOUSY AND IMPRECISE ASCII TABLES... + +# we do not store EBSD data by default with making any assumptions about +# gridding, this enables to handle all sort of scan schemes. +# following the argumentation of MTex, in certain cases data will not +# be fully occupied grids anyway also gridding is effectively a +# delocalization/interpolation procedure +NXebsd: + (NXentry): + exists: [min, 1, max, infty] + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + # enumeration: [sha_256_hash] + definition: + doc: NeXus NXDL schema to which this file conforms. + enumeration: [NXebsd] + workflow_identifier: + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + workflow_description: + exists: optional + doc: | + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + start_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + program: + doc: | + Commercial, parser, or otherwise given name to the program + which was used to process the workflow. + \@version: + doc: | + Program 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. + (NXuser): + exists: [min, 0, max, infty] + doc: | + Optional contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + name: + doc: Given (first) name and surname of the user. + affiliation: + exists: recommended + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address: + exists: recommended + doc: Postal address of the affiliation. + email: + exists: recommended + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + orcid: + exists: recommended + doc: | + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + orcid_platform: + exists: recommended + doc: | + Name of the OrcID or ResearcherID where the account + under orcid is registered. + telephone_number: + exists: optional + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role: + exists: recommended + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + social_media_name: + exists: optional + doc: | + Account name that is associated with the user + in social media platforms. + social_media_platform: + exists: optional + doc: | + Name of the social media platform where the account + under social_media_name is registered. + + # the reference to the sample is made by measurement + # connection to an instance of NXem in which the input data to the workflow were measured + commercial_on_the_fly_indexing(NXprocess): + doc: | + An inspection of the availability of EBSD datasets with an open-source + license stored on public archive services like Zenodo revealed during + the implementation of a generic parser for EBSD data that such data are + in most cases stored in two ways: Case one was via a file in format used + by technology partners. This file contains result of an on-the-fly + executed indexing, i.e. processing of the Kikuchi pattern into scan point + positions, indexing solutions per scan point, and some quality descriptors + for the solutions as well as crystal structure and phase metadata. + Case two were raw pattern in some custom format often without a detailed + description of what the individual fields and data arrays resolve + except for some references to publications. + Therefore, we first need to collect how these files have been + generated. Ideally one would do so by creating a complete set of + information via e.g. NXem that could then be used via reading from + the information in the measurement group (see below) of this application + definition. However, in most cases this is not available. + + Therefore, this group stores key metadata about which results file + contain the EBSD mapping and which software was used (software name + and version with build number). These pieces of information support + the interpretation of specific metadata in these results file which + currently cannot or be interpreted completely or conceptually uniquely. + + Thereby this NXem_ebsd application definition solves two key documentation + tasks which are so far missing in the EBSD community. An instance + of the application definition (e.g. a NeXus/HDF5 file formatted according + to this application definition) stores the connection between the + microscope session and thus the sample and microscope settings, and + Kikuchi pattern, overview images etc. Furthermore, this application definition + connects these data to the conventions used, and the results file + which would otherwise also be ripped out of their context when using + many traditional procedures where EBSD data are indexed on-the-fly + and shared by just sharing the results file in the technology partner + specific formatting. + program: + doc: | + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing. This is the usual production workflow + how scanning electron microscopes are used when collecting + EBSD data. + \@version: + doc: | + Program version plus build number, commit hash, or other description + of an ever persistent resource where the source code of the program and + build instructions can be found or at least more information about the + program in this version can be found. If all such information is not + available, like for commercial software, here the version number + and build number should be named. Use semantic versioning if possible. + results_file: + doc: | + Name of the results file. + \@version: + doc: | + Hash of that file. + measurement(NXprocess): + doc: | + Connection between the measurement of the Kikuchi pattern and the + processing of these into an orientation microscopy image. + origin: + doc: | + Name or link to an existent instance of an EBSD raw dataset inside an + NXem which has at least one NXimage_set_em_kikuchi instance. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the field in the EBSD community is that many of the metadata + fields are not in all cases fully documented. In addition, it is common + practice in the research field of EBSD that users transcode their raw + data into other formats so that these data can be interpreted by + specific software tools including commercial software from technology + partners other than the one which delivered the system that was e.g. + used when the raw data were collected. + As many of the file formats are not designed to communicate also then + the specifically and most importantly the eventually different context + of the metadata, we have opted for the first iteration of the implementation + to discard these metadata. + + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions, should not be our authority and necessarily + demands profits from feedback from the technology partners we have + opted for this intermediate approach. + \@version: + doc: Commit identifying this resource. + path: + doc: | + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + # connection to the calibration data based on which the EBSD indexing is considered reliable + calibration(NXprocess): + exists: recommended + doc: | + The EBSD system, that is the electron gun, pole-piece, stage tilting, + and EBSD detector, as well as the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, + the gnomonic projection has to be calibrated. + + In most practical cases, especially in engineering, there is a substantial + larger number of sessions where such a calibrated system is used + rather than recalibrated. + + In the first case the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software is well calibrated. Consequently, users only pick + from an existent library of NXem_ebsd_crystal_structure_model + instances and use them to measure and index their data on-the-fly. + As a result an indexing is performed after/between the beam scanning + the specimen (depends on configuration). + Specifically, users load their specimen, typically create a coarse image + of the surface, set an approximate value for the calibrated working distance + then tilt, configure the microscope for collection quality data, then + configure the settings used for the calibrated EBSD system, pick one or + multiple ROIs and then measure (nowadays this is virtually always an + automated process which is in most cases unsupervised, running within the + allocated microscope session time slot, data are indexed on-the-fly, and + results file often automatically copied and/or archived in certain places. + The result of such an EBSD measurement is a set of usually proprietary + or open files from technology partners (EBSD system and microscope + manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. + origin: + doc: | + A link/cross reference to an existent instance of NXebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + \@version: + doc: Commit identifying this resource. + path: + doc: | + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + # rotation and reference frame conventions + conventions(NXem_ebsd_conventions): + rotation_conventions(NXprocess): + three_dimensional_rotation_handedness: + rotation_convention: + euler_angle_convention: + axis_angle_convention: + orientation_parameterization_sign_convention: + sample_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + detector_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + gnomonic_projection_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + pattern_centre(NXprocess): + xaxis_boundary_convention: + xaxis_normalization_direction: + yaxis_boundary_convention: + yaxis_normalization_direction: + + # base class for indexing methods with relevant vocabulary + indexing(NXprocess): + doc: | + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientations. Fundamentally different algorithms + can be used to index EBSD/EBSP pattern. + + Pattern indexing is comparing of diffraction pattern, measured + against assumed or simulated pattern. Quality descriptor are defined + based on which an indexing algorithms yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Dictionary-based indexing methods are most increasingly becoming used also. + method: + doc: | + Principal algorithm used for indexing. + enumeration: [undefined, hough_transform, dictionary, radon_transform, other] # emsoft, astro, mtex + background_correction(NXprocess): + exists: optional + # for each process the program used + doc: | + Details about the background correction applied to each Kikuchi pattern. + # auto_background_correction: + # static_or_dynamic: + # pattern_averaging(NXprocess): + # doc: | + # Details about how patterns of each scan point are average or how + # pattern from scan points and neighboring scan points are spatially + # averaged (using weighting schemes and e.g. kernels) before these + # patterns are passed to the indexing algorithm. + binning(NXprocess): # NEW ISSUE: binning replace by NXgrid + exists: optional + # for each process the program used + doc: | + Binning i.e. downsampling of the pattern. + # mode: + # doc: Free-text description for instrument specific settings + # binning(NX_UINT): ##MK equivalent to pattern height and width? + # doc: | + # How is the camera signal binned. + # First the number of pixel along the slow direction. + # Second the number of pixel along the fast direction. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, 2]] + parameter(NXcollection): + exists: optional + doc: | + Specific parameter relevant only for certain algorithms used + # mode: + # doc: Which method used to index pattern? + # enumeration: [optimize_bd] # what does optimize_bd mean Oxford? + (NXem_ebsd_crystal_structure_model): + exists: [min, 1, max, infty] + crystallographic_database_identifier: + exists: recommended + crystallographic_database: + exists: recommended + unit_cell_abc(NX_FLOAT): + unit_cell_alphabetagamma(NX_FLOAT): + space_group: + phase_identifier(NX_UINT): + phase_name: + exists: recommended + atom_identifier: + atom(NX_UINT): + atom_positions(NX_FLOAT): + atom_occupancy(NX_FLOAT): + number_of_planes(NX_UINT): + plane_miller(NX_NUMBER): + dspacing(NX_FLOAT): + relative_intensity(NX_FLOAT): + + # individual mappings + # (scientists in EBSD consult all sorts of mappings) + # like image_quality map, orientation mapping, ipf mapping, grain mapping + # etc. in fact these could be all the possible mappings which one can + # create with the famous commercial software solutions + # the problem a RDMS cannot understand these mappings unless they + # are standardized in the sense, one has an exchange format whereby + # these mappings can be exported/transcoded from their representation + # in the commercial software, e.g. + # keep in mind, everybody uses the TSL OIM or Bruker AZTec OIM mapping + # but even these two are not directly interoperable, which is why + # they are also not interoperable in some RDMS if one does not come + # up with a way how to go about standardizing their description + # summary(NXdata): + # doc: | + status(NX_UINT): + exists: optional + doc: | + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + # data(NX_UINT): + # doc: | + # Status value of each pixel of the orientation mapping. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_sc]] + # axis_y(NX_NUMBER): + # doc: | + # Coordinate along the slow direction. + # axis_x(NX_NUMBER): + # doc: | + # Coordinate along the fast direction. + n_phases_per_scan_point(NX_UINT): + doc: | + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_sc]] + phase_identifier(NX_UINT): + doc: | + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] # with i = sum of n_phases_per_scan_point + phase_matching(NX_NUMBER): + exists: recommended + doc: | + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] # with i = sum of n_phases_per_scan_point + phase_matching_descriptor: + doc: | + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + enumeration: [undefined, ci, mad, other] + orientation_parameterization: + doc: | + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + enumeration: [euler, axis_angle, rodrigues, quaternion, homochoric] + orientation(NX_NUMBER): + doc: | + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + unit: NX_ANY # because differs for different parameterizations + dimensions: + rank: 2 + dim: [[1, i], [2, n_op]] + scan_point_positions(NX_NUMBER): + # we make this only required as people may not yet be so happy with + # having to walk a graph from measurement -> path -> NXevent_data_em + # -> em_lab/ebeam_deflector to retrieve the actual scan positions + # although this would be much cleaner + doc: | + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_sc], [2, 2]] # could also become a [2, 3] + # EW ISSUE: this is in fact a duplicate because if we know th + # path to the measurement we would have available all ebeam_deflector + # settings and thus could identify where the beam was scanning for each + # NXevent_data_em instance, we have even more + # REPLACE BY MORE GENERIC pivot table + hit_rate(NX_NUMBER): + exists: optional + doc: | + Fraction of successfully indexed pattern + of the set averaged over entire set. + unit: NX_DIMENSIONLESS + + # candidate for default plots + region_of_interest(NXprocess): + exists: [min, 1, max, 1] + doc: | + An overview of the entire area which was scanned. + For details about what defines the image contrast inspect descriptor. + descriptor: + doc: | + Descriptor representing the image contrast. + enumeration: [band_contrast] + roi(NXdata): + data(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: Overview + # \@signal: rgb + # \@axes: [ypos, xpos] # rgb + # \@rgb_indices: 0 + # \@xpos_indices: 0 + # \@ypos_indices: 1 + axis_y(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the slow axis. + unit: NX_LENGTH # pixel coordinates + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis + axis_x(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the fast axis. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis + + ipf_mapID(NXprocess): + exists: [min, 1, max, infty] # should be as many as crystal structure models + doc: | + Default inverse pole figure (IPF) plot of the data specific for each + phase interpolated on a rectangular/cuboidal domain with square + pixels/voxels and the orientations colored according + to the coloring scheme used in the respective ipf_color_modelID/program. + + Most importantly as the parser is not performing the inverse pole figure + mapping it requires that this computation is stored inside the results_file + that is referred to under commercial_on_the_fly_indexing. + This example clearly shows the key limitation that is when the computational + steps of collecting the raw data and post-processing these with some + custom scripts like MTex or commercial tools. The limitation is that + the program which consumes this file, here the parser of the research + data management system, has not necessarily sufficient information + available to check if the injected orientation data and color models + are matching the conventions which get injected from the electronic + lab notebook into an instance of this application definition, such + as a NeXus/HDF5 file that is formatted according to NXem_ebsd. + + Ideally, the parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientations + eventually. Thereafter, convention-compliant default plot(s) could + be created and served for purposes of data exploration within the RDMS. + + Given the variety of post-processing tools used for EBSD however, and + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option because + at least one developer who would pursue such task would first have to + create a library for performing such tasks for the parser. + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies different players in the field have + implemement slightly different approaches each of which misses + one consistent view of the entire workflow that is EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The default plot does so far not + yet apply relevant rotations but takes the orientation + values as. Ideally with all conventions defined it can + be possible to develop a converter which rotates the + input data but this is here not yet assumed to happen. + + The key point is that the conventions however are captured + first of all because then such conversions for improving + interoperability can be achieved. + + This default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created. + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the beam + illuminates certain positions for a certain amount time (usually equally- + spaced and same time spent at each position). + + Scan positions can be such regular flight plans mapping lines, + line stacks, rectangular regions-of-interests, but also could instruct + spiral, random, or adaptive scans instead of square or hexagon grids. + + The majority of EBSD maps is reporting results for a regular grid + (square, hexagon). What matters though in terms of damage induced by + the electron beam and signal quality is the real electron dose history, + i.e. for how long the beam exposed which location for how long. + + Specifically the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + phase_identifier(NX_UINT): + doc: | + Specifying which phase this IPF mapping visualizes. + unit: NX_UNITLESS + description: + exists: optional + doc: | + Which IPF definition computation according to backend. + # AS THE FIRST STEP WE DO NOT IMPLEMENT A GENERIC ORIENTATION AND REFERENCE + # FRAME LIBRARY WHICH CAN TRANSLATE BETWEEN ALL POSSIBLE CONVENTIONS. + # INSTEAD WE TAKE THE RESULTS COMPUTED FROM THE BACKEND THAT IS + # For cpr/crc/ang the pythonEBSD backend + # For other file either MTex or kikuchipy + # For DREAM.3D this is DREAM.3D + # For pyxem following the orix library (which has some, though not yet in + # all details checked links and usage of the orix library because kikuchipy + # is somehow connected to pyxem. NEED TO TALK TO DEVELOPERS HERE! + projection_normal(NX_NUMBER): + doc: | + Along which axis to project? Typically [0, 0, 1] is chosen. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, 3]] + bitdepth(NX_UINT): + doc: | + Bitdepth used for the RGB color model. Usually 8 bit. + unit: NX_UNITLESS + # can an NX_UINT have an enumeration? + program: + doc: | + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively this program is the backend + which performs the computation of the inverse pole figure mappings + to reflect what the EBSD community expects and solve also eventual + limitation of research data management system that their data + ingestion backends parsers do not have sophisticated software tools + in place to compute such community-specific default plots. + Seeing first of all that different tools may yield different color + maps may help to convince the community to work towards a common + library which transcodes between all possible relations. + In fact while working on this example I found as many different as + in backend. + + This is why it is critical to store all rotation_conventions + and reference frame details as detailed as possible because + then one can always post-process the data. + enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] + \@version: + doc: Version of the program i.e. backend used. + ipf_rgb_map(NXdata): + data(NX_UINT): + doc: | + RGB array, with resolution per fastest changing value defined by bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] + # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: IPF color coded orientation mapping + # \@signal: rgb + # \@axes: [zpos, ypos, xpos] # rgb + # \@rgb_indices: 0 + # \@xpos_indices: 0 + # \@ypos_indices: 1 + # \@zpos_indices: 2 + axis_y(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the slow axis. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis # but for h5web RGB we need n_y + 1 + axis_x(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the fast axis. + dimensions: + rank: 1 + dim: [[1, n_x]] # but for h5web RGB we need n_x + 1 + \@long_name: + doc: Label for the x axis + + ipf_rgb_color_model(NXdata): + doc: | + For each stereographic standard triangle (SST), (fundamental zone) of + the orientation space, it is possible to define a color model which + assigns an orientation in the fundamental zone a color. + + For details see: + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web. + data(NX_UINT): + doc: | + RGB array, with resolution per fastest changing value defined by bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: Naive IPF color map + # \@signal: rgb + # \@axes: [ypos, xpos] # rgb + # \@rgb_indices: 0 + # \@xpos_indices: 0 + # \@ypos_indices: 1 + axis_y(NX_NUMBER): + doc: | + Pixel coordinate along the slow axis. + unit: NX_ANY # pixel coordinates + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis + axis_x(NX_NUMBER): + doc: | + Pixel coordinate along the fast axis. + unit: NX_ANY # pixel coordinates + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis + + # NEW ISSUE: frame averaging + # NEW ISSUE: going towards the level of suggestions what would all be immediately possible + # ebsd_mapping(NXprocess): + # doc: | + # An EBSD mapping is the result of a collecting and indexing of Kikuchi + # pattern, so that for each pattern there is either an associated + # phase_identifier or a status marker stating that no solution was found + # (NXsst_color_model): ##MK + # doc: | + # For each stereographic standard triangle, (fundamental zone) of + # the orientation space, it is possible to define a color model which + # associates an orientation in the fundamental zone to a color. + # + # For details see: + # * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + # * Srikanth Patala and coworkers"'" work and of others. + # (NXorientation_set): + # doc: | + # Collection of quaternions in the SO3 fundamental zone with colors and + # rgb(NX_NUMBER): + # doc: RGB colors. + # unit: NX_UNITLESS + # dimensions: [[1, n_oris], [2, 3]] + # # hsv and other models + # (NXcg_point_set): + # rgb(NX_NUMBER): + # dimensions: [[1, n_points], [2, 3]] + # mapping(NX_NUMBER): + # doc: | + # The EBSD mapping with colors outlined + # unit: NX_UNITLESS + # dimensions: [[1, n_y], [2, n_x], [3, 3]] + # NEW ISSUE: it would also be possible to define additional color models to overlay + # check n_p vs n_sc vs n_p_or_z + + # confidence_index(NX_FLOAT): + # doc: | + # Is a technology-partner-specific (TSL OIM) AMETEK phase_matching descriptor. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, i]] + # mean_angular_deviation(NX_FLOAT): + # doc: | + # The mean angular deviation is also a technology-partner-specific + # (HKL Channel5) solution-to-reflector matching descriptor. + # unit: NX_ANGLE + # dimensions: + # rank: 1 + # dim: [[1, i]] + # there are many other type of descriptor especially for new machine learning + # type and dictionary type indexing methods + # some descriptors are relevant only for Hough based indexing and technology-partner-specific + # band_count(NX_UINT): + # doc: | + # How many bands were detected in the pattern. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # band_minimum(NX_UINT): + # doc: | + # Minimum number of bands required to index the pattern + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # band_maximum(NX_UINT): + # doc: | + # Maximum number of bands required to index the pattern + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # resolution(NX_NUMBER): + # doc: | + # Resolution in Hough space. + # unit: NX_ANGLE # or NX_ANY + # band_detection(NXprocess): # for hough_transform + # mode: + # doc: | + # How are Kikuchi bands detected + # enumeration: [center] + # band_contrast(NX_NUMBER): + # doc: | + # Value for band contrast descriptor. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # band_slope(NX_NUMBER): + # doc: | + # Value for band slope descriptor. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # centre(NX_FLOAT): + # doc: | + # Pattern centre location used for analyzing each pattern. + # unit: NX_LENGTH + # dimensions: + # rank: 2 + # dim: [[1, n_p], [2, 2]] # what to do when a different one for each pattern seldom but possible + # distance(NX_FLOAT): + # doc: | + # Pattern centre distance used for analyzing each pattern. + # unit: NX_LENGTH + # dimensions: + # rank: 2 + # dim: [[1, n_p], [2, 2]] + # vh_ratio(NX_FLOAT): + # doc: | + # TBD Oxford/HKL Channel 5 CPR files + # unit: NX_DIMENSIONLESS + # how to parameterize a group with value, and descriptor type or a + # field with descriptor type as attribute? + # pattern_quality(NXprocess): + # value(NX_NUMBER): + # doc: | + # Pattern quality descriptor + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # model: + # doc: | + # Model used to describe some aspect of the pattern. + # enumeration: [band_contrast, mean_angular_deviation] diff --git a/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml b/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml new file mode 100644 index 0000000000..e60e27d76f --- /dev/null +++ b/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml @@ -0,0 +1,270 @@ +category: base +# symbols: +doc: | + Conventions for rotations and coordinate systems to interpret EBSD data. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. +NXem_ebsd_conventions: + # mandatory information about used or + # assumed reference frame and rotation conventions + rotation_conventions(NXprocess): + doc: | + Mathematical conventions and materials-science-specific conventions + required for interpreting every collection of orientation data. + three_dimensional_rotation_handedness: + doc: | + 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. + enumeration: [undefined, counter_clockwise, clockwise] + rotation_convention: + doc: | + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, passive, active] + euler_angle_convention: + doc: | + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) 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. + enumeration: [undefined, zxz] + axis_angle_convention: + doc: | + 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. + enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] + orientation_parameterization_sign_convention: + doc: | + 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. + enumeration: [undefined, p_plus_one, p_minus_one] + sample_reference_frame(NXprocess): + doc: | + Details about the sample/specimen reference frame. + reference_frame_type: + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + The reference frame for the sample surface reference is used for + identifying positions on a (virtual) image which is formed by + information collected from an electron beam scanning the + sample surface. We assume the configuration is inspected by + looking towards the sample surface from a position that is + located behind the detector. + Reference DOI: 10.1016/j.matchar.2016.04.008 + The sample surface reference frame has coordinates Xs, Ys, Zs. + In three dimensions these coordinates are not necessarily + located on the surface of the sample as there are multiple + faces/sides of the sample. Most frequently though the coordinate + system here is used to define the surface which the electron + beam scans. + enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] + xaxis_direction: + doc: | + Direction of the positively pointing x-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + yaxis_direction: + doc: | + Direction of the positively pointing y-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + zaxis_direction: + doc: | + Direction of the positively pointing z-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + origin: + doc: | + Location of the origin of the sample surface reference frame. + This specifies the location Xs = 0, Ys = 0, Zs = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + detector_reference_frame(NXprocess): + doc: | + Details about the detector reference frame. + reference_frame_type: + doc: | + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] + xaxis_direction: + doc: | + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + yaxis_direction: + doc: | + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + zaxis_direction: + doc: | + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + origin: + doc: | + Where is the origin of the detector space reference + frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + gnomonic_projection_reference_frame(NXprocess): + doc: | + Details about the gnomonic projection reference frame. + reference_frame_type: + doc: | + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] + xaxis_direction: + doc: | + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + yaxis_direction: + doc: | + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + zaxis_direction: + doc: | + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + origin: + doc: | + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, in_the_pattern_centre] + pattern_centre(NXprocess): + doc: | + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + xaxis_boundary_convention: + doc: | + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + enumeration: [undefined, top, right, bottom, left] + xaxis_normalization_direction: + doc: | + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + enumeration: [undefined, north, east, south, west] + yaxis_boundary_convention: + doc: | + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + enumeration: [undefined, top, right, bottom, left] + yaxis_normalization_direction: + doc: | + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + enumeration: [undefined, north, east, south, west] + # distance_convention: + # doc: | + # How is the third of the three pattern centre parameter values, + # the (distance) parameter DD, normalized. Which convention + # is followed. We are aware that specifying one of the options here + # also implicitly comes with conventions for some of the parameter + # requested in this ELN. For now we would rather like to ask + # the users though to be specific also to learn how such an ELN + # will be used in practice. + # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] diff --git a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml new file mode 100644 index 0000000000..33927936b7 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml @@ -0,0 +1,150 @@ +category: base +symbols: + n_hkl: Number of reflectors (Miller crystallographic plane triplets). + n_pos: Number of atom positions. +doc: | + Crystal structure phase models used for indexing Kikuchi pattern. + + This base class contains key metadata relevant to every physical + kinematic or dynamic diffraction model to be used for simulating + Kikuchi diffraction pattern. + The actual indexing of Kikuchi pattern however maybe use different + algorithms which build on these simulation results but evaluate different + workflows of comparing simulated and measured Kikuchi pattern to make + suggestions which orientation is the most likely (if any) for each + scan point investigated. + + Traditionally Hough transform based indexing has been the most frequently + used algorithm. More and more dictionary based alternatives are used. + Either way both algorithm need a crystal structure model. +NXem_ebsd_crystal_structure_model: + # for EBSD specifically we need to know the assumed crystal structure + # with assumed statistically distributed atoms, i.e. structure and atom + # positions + crystallographic_database_identifier: + doc: | + Identifier of an entry from crystallographic_database which was used + for creating this structure model. + crystallographic_database: + doc: | + Name of the crystallographic database to resolve + crystallographic_database_identifier e.g. COD or others. + unit_cell_abc(NX_FLOAT): + doc: | + Crystallography unit cell parameters a, b, and c. + # defined using which convention? + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + # defined using which convention? + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, 3]] + unit_cell_volume(NX_FLOAT): + doc: | + Volume of the unit cell + unit: NX_VOLUME + space_group: + doc: | + Crystallographic space group + # add enumeration all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + 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). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + laue_group: + doc: | + Laue group + # add enumeration all possible + point_group: + doc: | + Point group using International Notation. + # add enumeration all possible + unit_cell_class: + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + phase_identifier(NX_UINT): + doc: | + Numeric identifier for each phase. + The value 0 is reversed for the unknown phase essentially representing the + null-model that no phase model was sufficiently significantly confirmed. + Consequently, the value 0 must not be used as a phase_identifier. + unit: NX_UNITLESS + phase_name: + doc: | + Name of the phase/alias. + atom_identifier: + doc: | + Labels for each atom position + dimensions: + rank: 1 + dim: [[1, n_pos]] + atom(NX_UINT): + doc: | + 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) `_ + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_pos]] + atom_positions(NX_FLOAT): + doc: | + Atom positions x, y, z. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_pos], [2, 3]] + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_FLOAT): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_pos]] + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. Value has to be n_hkl. + unit: NX_UNITLESS + plane_miller(NX_NUMBER): + doc: | + Miller indices :math:`(hkl)`. + # Miller indices :math:`(hkl)[uvw]`. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_hkl], [2, 3]] + dspacing(NX_FLOAT): + doc: | + D-spacing. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_hkl]] + relative_intensity(NX_FLOAT): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_hkl]] +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXimage_set_em.yaml b/contributed_definitions/nyaml/NXimage_set_em.yaml new file mode 100644 index 0000000000..9acd6e6fb2 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em.yaml @@ -0,0 +1,69 @@ +category: base +doc: | + Container for reporting a set of images taken with an electron microscope. +symbols: + n_images: Number of images in the stack. + n_y: Number of pixel per image in the slow direction. + n_x: Number of pixel per image in the fast direction. +NXimage_set_em: + (NXprocess): + doc: | + Details how images were processed from the detector readings. + source: + doc: | + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXimage_set_em were loaded during + parsing to represent them in e.g. databases. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + program: + doc: | + Commercial or otherwise given name to the program which was used + to process detector data into the adf image(s). + \@version: + doc: | + Program 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. + (NXprocess): + mode: + doc: | + Imaging mode in which the instrument was and with which the images + were captured. + stack(NXdata): + doc: | + Image (stack). + data_counts(NX_NUMBER): + doc: Image intensity values. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_images], [2, n_y], [3, n_x]] + axis_image_identifier(NX_UINT): + doc: Image identifier + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_images]] + \@long_name: + doc: Image identifier. + axis_y(NX_NUMBER): + doc: Pixel coordinate center of mass along y direction. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Coordinate along y direction. + axis_x(NX_NUMBER): + doc: Pixel coordinate center of mass along x direction. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml index de787e3cdd..0bfb4088f9 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml @@ -45,41 +45,35 @@ NXimage_set_em_adf: doc: Annulus outer half angle unit: NX_ANGLE stack(NXdata): - doc: Annular dark field image stack. - # \@signal: intensity - # \@axes: [image_id, ypos, xpos] - # \@xpos_indices: 2 - # \@ypos_indices: 1 - # \@image_indices: 0 - intensity(NX_NUMBER): + doc: | + Annular dark field image stack. + data_counts(NX_NUMBER): doc: Image intensity values. unit: NX_UNITLESS dimensions: rank: 3 dim: [[1, n_images], [2, n_y], [3, n_x]] - \@long_name: - doc: Image intensities - image_id(NX_UINT): + axis_image_identifier(NX_UINT): doc: Image identifier unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_images]] \@long_name: - doc: Image ID. - ypos(NX_NUMBER): - doc: Pixel center of mass position y-coordinates. + doc: Image identifier. + axis_y(NX_NUMBER): + doc: Pixel coordinate center of mass along y direction. unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: Label for the y axis. - xpos(NX_NUMBER): - doc: Pixel center of mass position x-coordinates. + doc: Coordinate along y direction. + axis_x(NX_NUMBER): + doc: Pixel coordinate center of mass along x direction. unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: Label for the x axis. + doc: Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml new file mode 100644 index 0000000000..2711ff2a9a --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml @@ -0,0 +1,139 @@ +category: base +symbols: + n_sc: Number of scanned points. Scan point may have none, one, or more pattern. + n_p: Number of diffraction pattern. + n_y: Number of pixel per Kikuchi pattern in the slow direction. + n_x: Number of pixel per Kikuchi pattern in the fast direction. +doc: | + Measured set of electron backscatter diffraction data, aka Kikuchi pattern. + Kikuchi pattern are the raw data for computational workflows in the field + of orientation (imaging) microscopy. The technique is especially used in + materials science and materials engineering. + + Based on a fuse of the `M. A. Jackson et al. `_ + of the DREAM.3D community and the open H5OINA format of Oxford Instruments + `P. Pinard et al. `_ + + EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional + orientation microscopy. So-called serial section analyses. For a detailed + overview of these techniques see e.g. + + * `M. A. Groeber et al. `_ + * `A. J. Schwartz et al. `_ + * `P. A. Rottman et al. `_ + + With serial-sectioning this involves however always a sequence of measuring, + milling. In this regard, each serial section (measuring) and milling + is an own NXevent_data_em instance and thus there such a three-dimensional + characterization should be stored as a set of two-dimensional data, + with as many NXevent_data_em instances as sections were measured. + + These measured serial sectioning images need virtually always post-processing + to arrive at the aligned and cleaned image stack before a respective digital + model of the inspected microstructure can be analyzed. The resulting volume + is often termed a so-called (representative) volume element (RVE). + Several software packages are available for performing this post-processing. + For now we do not consider metadata of these post-processing steps + as a part of this base class because the connection between the large variety + of such post-processing steps and the measured electron microscopy data + is usually very small. + + If we envision a (knowledge) graph for EBSD it consists of individual + sub-graphs which convey information about the specimen preparation, + the measurement of the specimen in the electron microscope, + the indexing of the collected Kikuchi pattern stack, + eventual post-processing of the indexed orientation image + via similarity grouping algorithms to yield (grains, texture). + Conceptually these post-processing steps are most frequently + serving the idea to reconstruct quantitatively so-called + microstructural features (grains, phases, interfaces). Materials scientists + use these features according to the multi-scale materials modeling paradigm + to infer material properties. They do so by quantifying correlations between + the spatial arrangement of the features, their individual properties, + and (macroscopic) properties of materials. +NXimage_set_em_kikuchi: + # a collection of pattern-related metadata + (NXprocess): + doc: | + Details how Kikuchi pattern were processed from the detector readings. + Scientists interested in EBSD should inspect the respective NXem_ebsd + application definition which can be used as a partner application definition + to detail substantially more details to this processing. + stack(NXdata): + doc: | + Collected Kikuchi pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably by the instrument + given the way how the instrument and control software was configured + for your microscope session. + scan_point_identifier(NX_UINT): + doc: | + Array which resolves the scan point to which each pattern belongs. + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belong to which scan point. + In an example we may assume we collected three scan points. For the first + we measure one pattern, for the second we measure three pattern, + for the last we measure no pattern. + The values of scan_point_identifier will be 0, 1, 1, 1, as we have + measured four pattern in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. Use compressed + arrays allows to store the scan_point_identifier efficiently. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + data_counts(NX_NUMBER): + doc: | + Signal intensity. For so-called three-dimensional or serial sectioning + EBSD it is necessary to follow a sequence of specimen surface preparation + and data collection. In this case users should collect the data for each + serial sectioning step in an own instance of NXimage_set_em_kikuchi. + All eventual post-processing of these measured data should be documented + via NXebsd, resulting microstructure representations should be stored + as NXms. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_p], [2, n_y], [3, n_x]] + # n_p fast 2, n_y faster 1, n_x fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: Kikuchi pattern intensity + # \@signal: intensity + # \@axes: [pattern_identifier, ypos, xpos] + # \@xpos_indices: 0 + # \@ypos_indices: 1 + # \@pattern_identifier_indices: 2 + pattern_identifier(NX_UINT): + doc: | + Pattern are enumerated starting from 0 to n_p - 1. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + \@long_name: + doc: Kikuchi pattern identifier + axis_y(NX_NUMBER): + doc: Pixel coordinate along the y direction. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis + axis_x(NX_NUMBER): + doc: Pixel coordinate along the x direction. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis + # maybe time code data when the pattern were taken? + # key is it all happened in between the time defined in NXevent_data_em + # optionally link to NXebsd instance? diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml index 774f27ab77..e3641333c7 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/NXion.yaml @@ -2,9 +2,12 @@ category: base doc: | Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ivecmax: Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - n_ranges: Number of mass-to-charge-state-ratio range intervals for ion type. + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ivecmax: | + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + n_ranges: | + Number of mass-to-charge-state-ratio range intervals for ion type. NXion: ion_type(NX_UINT): doc: | diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml index 8772ffd4b6..69a903a2c8 100644 --- a/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml @@ -43,62 +43,63 @@ NXspectrum_set_em_eels: doc: | Collected EELS spectra for all pixels of a rectangular region-of-interest. This representation supports rectangular scan pattern. - counts(NX_NUMBER): + data_counts(NX_NUMBER): + doc: Counts for one spectrum per each pixel. unit: NX_UNITLESS dimensions: rank: 3 dim: [[1, n_y], [2, n_x], [3, n_energy_loss]] - \@long_name: - doc: EELS counts + \@long_name: + doc: EELS counts # \@signal: counts # \@axes: [ypos, xpos, energy_loss] # \@energy_loss_indices: 2 # \@xpos_indices: 1 # \@ypos_indices: 0 - ypos(NX_NUMBER): + axis_y(NX_NUMBER): doc: Pixel center of mass position y-coordinates. unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: Label for the y axis. - xpos(NX_NUMBER): + doc: Coordinate along y direction. + axis_x(NX_NUMBER): doc: Pixel center of mass position x-coordinates. unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: Label for the x axis. - energy_loss(NX_NUMBER): + doc: Coordinate along x direction. + axis_energy_loss(NX_NUMBER): doc: Pixel center of mass energy loss bins. unit: NX_ENERGY dimensions: rank: 1 dim: [[1, n_energy_loss]] \@long_name: - doc: Label for the energy loss axis. + doc: Coordinate along energy loss axis. summary(NXdata): doc: | - Accumulated EELS spectrum over all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - counts(NX_NUMBER): + Accumulated EELS spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): doc: Counts for specific energy losses. unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_energy_loss]] - \@long_name: - doc: Counts electrons with an energy loss within binned range. + \@long_name: + doc: Counts electrons with an energy loss within binned range. # \@signal: counts # \@axes: [energy_loss] # \@energy_loss_indices: 0 - energy_loss(NX_NUMBER): + axis_energy_loss(NX_NUMBER): doc: Pixel center of mass energy loss bins. unit: NX_ENERGY dimensions: rank: 1 dim: [[1, n_energy_loss]] \@long_name: - doc: Energy loss + doc: Coordinate along energy loss axis. diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml index 1bbaa66b1a..1cdd2f9019 100644 --- a/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml @@ -52,60 +52,60 @@ NXspectrum_set_em_xray: doc: | Collected X-ray spectra for all pixels of a rectangular region-of-interest. This representation supports rectangular scan pattern. - counts(NX_UINT): + data_counts(NX_NUMBER): unit: NX_UNITLESS dimensions: rank: 3 dim: [[1, n_y], [2, n_x], [3, n_photon_energy]] - \@long_name: - doc: X-ray photon counts + \@long_name: + doc: X-ray photon counts # \@signal: counts # \@axes: [ypos, xpos, photon_energy] # \@ypos_indices: 0 # \@xpos_indices: 1 # \@photon_energy_indices: 2 - ypos(NX_NUMBER): + axis_y(NX_NUMBER): unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: Label for the y axis - xpos(NX_NUMBER): + doc: Coordinate along y direction. + axis_x(NX_NUMBER): unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: Label for the x axis - photon_energy(NX_NUMBER): + doc: Coordinate along x direction. + axis_photon_energy(NX_NUMBER): unit: NX_ENERGY dimensions: rank: 1 dim: [[1, n_photon_energy]] \@long_name: - doc: X-ray energy + doc: Photon energy. summary(NXdata): doc: | - Accumulated X-ray spectrum over all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - counts(NX_UINT): + Accumulated X-ray spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_photon_energy]] - \@long_name: - doc: X-ray photon counts + \@long_name: + doc: X-ray photon counts # \@signal: counts # \@axes: [photon_energy] # \@photon_energy_indices: 0 - photon_energy(NX_NUMBER): + axis_photon_energy(NX_NUMBER): unit: NX_ENERGY dimensions: rank: 1 dim: [[1, n_photon_energy]] \@long_name: - doc: X-ray energy + doc: Photon energy # for post-processing of/with the above-defined data entries indexing(NXprocess): @@ -116,10 +116,11 @@ NXspectrum_set_em_xray: Given name of the program that was used to perform this computation. \@version: doc: | - Program 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. + Program 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. (NXpeak): doc: | Name and location of each X-ray line which was indexed as a known ion. @@ -127,18 +128,18 @@ NXspectrum_set_em_xray: the origin of the signal. For each ion also the relevant IUPAC notation X-ray lines should be specified. (NXion): - iupac_line_names(NX_CHAR): + iupac_line_names: doc: | IUPAC notation identifier of the line which the peak represents. This can be a list of IUPAC notations for (the seldom) case that multiple lines are group with the same peak. - element_names(NX_CHAR): + element_names: doc: List of the names of identified elements. dimensions: rank: 1 dim: [[1, n_elements]] - composition_map(NXprocess): + ELEMENTNAME(NXprocess): doc: | Individual element-specific EDX/EDS/EDXS/SXES mapping @@ -149,10 +150,11 @@ NXspectrum_set_em_xray: Given name of the program that was used to perform this computation. \@version: doc: | - Program 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. + Program 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. peaks: doc: | A list of strings of named instances of NXpeak from indexing @@ -163,32 +165,32 @@ NXspectrum_set_em_xray: name: doc: Human-readable, given name to the image. # example how an element-specific pattern could be stored - (NXdata): + summary(NXdata): doc: | Individual element-specific maps. Individual maps should each be a group and be named according to element_names. - counts(NX_NUMBER): + data_counts(NX_NUMBER): unit: NX_UNITLESS dimensions: rank: 2 dim: [[1, n_y], [2, n_x]] - \@long_name: - doc: Accumulated X-ray photon counts + \@long_name: + doc: Accumulated photon counts for observed element. # \@signal: counts # \@axes: [ypos, xpos] # \@xpos_indices: 1 # \@ypos_indices: 0 - ypos(NX_NUMBER): + axis_y(NX_NUMBER): unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: Label for the y axis - xpos(NX_NUMBER): + doc: Coordinate along y direction. + axis_x(NX_NUMBER): unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: Label for the x axis + doc: Coordinate along x direction. From 1f04f9ad4b6b7ecb48972de22599b53b1a57452c Mon Sep 17 00:00:00 2001 From: domna Date: Fri, 10 Feb 2023 13:33:49 +0100 Subject: [PATCH 093/203] Add min/max values for wavelength and energy --- .../NXdispersion_function.nxdl.xml | 20 +++++++++++++++++ .../nyaml/NXdispersion_function.yml | 22 ++++++++++++++++--- 2 files changed, 39 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXdispersion_function.nxdl.xml b/contributed_definitions/NXdispersion_function.nxdl.xml index 5a0bc96c7d..fdaa729e01 100644 --- a/contributed_definitions/NXdispersion_function.nxdl.xml +++ b/contributed_definitions/NXdispersion_function.nxdl.xml @@ -38,12 +38,32 @@ in the formula. It is recommended to use `E`. + + + The minimum energy value at which this formula is valid. + + + + + The maximum energy value at which this formula is valid. + + The identifier useed to represent wavelength in the formula. It is recommended to use `lambda`. + + + The minimum wavelength value at which this formula is valid. + + + + + The maximum wavelength value at which this formula is valid. + + Which representation does the formula evaluate to. diff --git a/contributed_definitions/nyaml/NXdispersion_function.yml b/contributed_definitions/nyaml/NXdispersion_function.yml index 58a572c927..4b78f4cd0c 100644 --- a/contributed_definitions/nyaml/NXdispersion_function.yml +++ b/contributed_definitions/nyaml/NXdispersion_function.yml @@ -8,7 +8,7 @@ NXdispersion_function: model_name(NX_CHAR): doc: | The name of this dispersion model. - formula(NX_CHAR): + formula(NX_CHAR): doc: | This should be a python parsable function. Here we should provide which keywords are available @@ -16,17 +16,33 @@ NXdispersion_function: convention(NX_CHAR): doc: | The sign convention being used (n + or - ik) - enumeration: ['n + ik', 'n - ik'] + enumeration: ["n + ik", "n - ik"] energy_identifier(NX_CHAR): doc: | The identifier used to represent energy in the formula. It is recommended to use `E`. unit: NX_ENERGY + energy_min(NX_CHAR): + doc: | + The minimum energy value at which this formula is valid. + unit: NX_ENERGY + energy_max(NX_CHAR): + doc: | + The maximum energy value at which this formula is valid. + unit: NX_ENERGY wavelength_identifier(NX_CHAR): doc: | The identifier useed to represent wavelength in the formula. It is recommended to use `lambda`. unit: NX_LENGTH + wavelength_min(NX_CHAR): + doc: | + The minimum wavelength value at which this formula is valid. + unit: NX_LENGTH + wavelength_max(NX_CHAR): + doc: | + The maximum wavelength value at which this formula is valid. + unit: NX_LENGTH representation(NX_CHAR): doc: | Which representation does the formula evaluate to. @@ -42,4 +58,4 @@ NXdispersion_function: values(NX_NUMBER): dimensions: rank: 1 - dim: [[1, n_repetitions]] \ No newline at end of file + dim: [[1, n_repetitions]] From 6ed58639142b5e9f5175d0c212ec8868da7d7007 Mon Sep 17 00:00:00 2001 From: domna Date: Fri, 10 Feb 2023 18:13:24 +0100 Subject: [PATCH 094/203] Adds units fields for wavelength and energy --- .../NXdispersion_function.nxdl.xml | 28 +++++++++++++++---- .../NXdispersive_material.nxdl.xml | 12 ++++++-- .../nyaml/NXdispersion_function.yml | 22 +++++++++++---- .../nyaml/NXdispersive_material.yml | 17 +++++++++-- 4 files changed, 63 insertions(+), 16 deletions(-) diff --git a/contributed_definitions/NXdispersion_function.nxdl.xml b/contributed_definitions/NXdispersion_function.nxdl.xml index fdaa729e01..724c9c0fd6 100644 --- a/contributed_definitions/NXdispersion_function.nxdl.xml +++ b/contributed_definitions/NXdispersion_function.nxdl.xml @@ -32,34 +32,50 @@ - + The identifier used to represent energy in the formula. It is recommended to use `E`. - + The minimum energy value at which this formula is valid. - + The maximum energy value at which this formula is valid. - + + + The energy unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. + + + The identifier useed to represent wavelength in the formula. It is recommended to use `lambda`. - + + + The wavelength unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. + + + The minimum wavelength value at which this formula is valid. - + The maximum wavelength value at which this formula is valid. diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index a4ba555b93..58f3b7ae05 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -30,8 +30,8 @@ List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all + that are contained in the sample. + If the sample substance has multiple components, all elements from each component must be included in `atom_types`. @@ -65,7 +65,7 @@ - + Denotes whether the dispersion is calculated or derived from an experiment @@ -108,7 +108,9 @@ + + @@ -144,7 +146,9 @@ + + @@ -181,7 +185,9 @@ + + diff --git a/contributed_definitions/nyaml/NXdispersion_function.yml b/contributed_definitions/nyaml/NXdispersion_function.yml index 4b78f4cd0c..e197e3f507 100644 --- a/contributed_definitions/nyaml/NXdispersion_function.yml +++ b/contributed_definitions/nyaml/NXdispersion_function.yml @@ -21,25 +21,37 @@ NXdispersion_function: doc: | The identifier used to represent energy in the formula. It is recommended to use `E`. - unit: NX_ENERGY - energy_min(NX_CHAR): + energy_min(NX_NUMBER): doc: | The minimum energy value at which this formula is valid. unit: NX_ENERGY - energy_max(NX_CHAR): + energy_max(NX_NUMBER): doc: | The maximum energy value at which this formula is valid. unit: NX_ENERGY + energy_unit(NX_NUMBER): + doc: | + The energy unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. + unit: NX_ENERGY wavelength_identifier(NX_CHAR): doc: | The identifier useed to represent wavelength in the formula. It is recommended to use `lambda`. + wavelength_unit(NX_NUMBER): + doc: | + The wavelength unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. unit: NX_LENGTH - wavelength_min(NX_CHAR): + wavelength_min(NX_NUMBER): doc: | The minimum wavelength value at which this formula is valid. unit: NX_LENGTH - wavelength_max(NX_CHAR): + wavelength_max(NX_NUMBER): doc: | The maximum wavelength value at which this formula is valid. unit: NX_LENGTH diff --git a/contributed_definitions/nyaml/NXdispersive_material.yml b/contributed_definitions/nyaml/NXdispersive_material.yml index c08ecbdb3d..16613789ce 100644 --- a/contributed_definitions/nyaml/NXdispersive_material.yml +++ b/contributed_definitions/nyaml/NXdispersive_material.yml @@ -18,8 +18,8 @@ NXdispersive_material: exists: optional doc: | List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all + that are contained in the sample. + If the sample substance has multiple components, all elements from each component must be included in `atom_types`. colloquial_name(NX_CHAR): exists: optional @@ -42,6 +42,7 @@ NXdispersive_material: such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or if a measurement was done on a thin film or bulk material. dispersion_type(NX_CHAR): + exists: recommended doc: | Denotes whether the dispersion is calculated or derived from an experiment enumeration: ["measured", "simulated"] @@ -78,8 +79,12 @@ NXdispersive_material: convention: energy_identifier: exists: recommended + energy_unit(NX_NUMBER): + exists: recommended wavelength_identifier: exists: recommended + wavelength_unit(NX_NUMBER): + exists: recommended representation: (NXdispersion_single_parameter): name: @@ -114,8 +119,12 @@ NXdispersive_material: convention: energy_identifier: exists: recommended + energy_unit(NX_NUMBER): + exists: recommended wavelength_identifier: exists: recommended + wavelength_unit(NX_NUMBER): + exists: recommended representation: (NXdispersion_single_parameter): name: @@ -151,8 +160,12 @@ NXdispersive_material: convention: energy_identifier: exists: recommended + energy_unit(NX_NUMBER): + exists: recommended wavelength_identifier: exists: recommended + wavelength_unit(NX_NUMBER): + exists: recommended representation: (NXdispersion_single_parameter): name: From 5d18d2b664f596e6abbc252b4155942fa4f9e250 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 13 Feb 2023 12:07:47 +0100 Subject: [PATCH 095/203] Additional base classes used in paraprobe-toolbox --- .../nyaml/NXcg_alpha_complex.yaml | 83 +++++++++++++++ .../nyaml/NXchemical_composition.yaml | 34 ++++++ .../nyaml/NXisocontour.yaml | 30 ++++++ .../nyaml/NXsimilarity_grouping.yaml | 100 ++++++++++++++++++ 4 files changed, 247 insertions(+) create mode 100644 contributed_definitions/nyaml/NXcg_alpha_complex.yaml create mode 100644 contributed_definitions/nyaml/NXchemical_composition.yaml create mode 100644 contributed_definitions/nyaml/NXisocontour.yaml create mode 100644 contributed_definitions/nyaml/NXsimilarity_grouping.yaml diff --git a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml new file mode 100644 index 0000000000..fc033c7574 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml @@ -0,0 +1,83 @@ +category: base +doc: | + Computational geometry description of alpha shapes or wrappings to primitives. + + For details see: + + * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, + * https://dx.doi.org/10.1145/174462.156635 for 3D, + * https://dl.acm.org/doi/10.5555/871114 for weighted, and + * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap + + in CGAL, the Computational Geometry Algorithms Library. + As a starting point, we follow the conventions of the CGAL library. +# weighted alpha shapes +# The so-called spectrum or sets of (weighted) alpha shapes includes the +# convex hull of a point set. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality of the alpha shape, for now 2 or 3. + # generalize to d > 3 + n_e: The number of edges. + n_f: The number of faces. + n_c: The number of cells. +NXcg_alpha_complex: + dimensionality(NX_UINT): + unit: NX_UNITLESS + enumeration: [2, 3] + type: + doc: | + Specify which general type of alpha shape is computed. + Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. + Alpha_wrapping means meshes created using alpha wrapping procedures. + enumeration: [convex_hull, alpha_shape, alpha_wrapping] # , weighted] + mode: + doc: | + Specifically when computed with the CGAL, the mode specifies if singular + faces are removed (regularized) of the alpha complex. + # CHECK THIS AGAIN CAREFULLY + enumeration: [general, regularized] + alpha(NX_NUMBER): + doc: | + The alpha, (radius of the alpha-sphere) parameter to be used for alpha + shapes and alpha wrappings. + unit: NX_LENGTH + offset(NX_NUMBER): + doc: | + The offset distance parameter to be used in addition to alpha + in the case of alpha_wrapping. + unit: NX_LENGTH + # check again carefully the CGAL documentation talks about, for 3D, the square of the radius! + point_set(NXcg_point_set): + doc: Point cloud for which the alpha shape or wrapping should be computed. + # this could also just be implemented as a link but how would this be possible + # unfold the NXcg_point_set and add a + # weight(NX_NUMBER): + # doc: Weights for each point + # In general, an alpha complex is a disconnected and non-pure complex, + # meaning in particular that the alpha complex may have singular faces. + # so the number of cells, faces and edges depends on how a specific alpha complex, + # i.e. an alpha-shape of S for alpha, is filtrated with respect to k < d-dimensional + # simplices. Here we assume that number_of_cells, number_of_faces, number_of_edges + # are reported assuming one filtrates these simplices according to mode. + # also using the assumption the base class reports the unique vertices + # of the specifically filtrated alpha complex. + triangle_set(NXcg_triangle_set): + doc: Triangle soup for which the alpha wrapping should be computed. + triangulation(NXcg_triangle_set): + doc: A meshed representation of the resulting shape. + # should be a mesh + # add for each triangle if desirable a notation of whether the simplex is + # exterior, regular, singular, or interior with respect to the alpha complex + # but a triangulation is more than a triangle (soup)/set because there is + # connectivity information + # customize the NXcg_triangle_set base class members such that connectivity + # information is contained + # we need to find also a better name for this, what people intutive understand + # as the interior, may not even exist for a given alpha value + # more specifically it is the set of filtrated cells acknowledging mode + # e.g. the interior cells of the regularized alpha complex + interior_cells(NXcg_tetrahedron_set): + # document the alpha status + # https://doc.cgal.org/latest/Alpha_shapes_3/classCGAL_1_1Alpha__status.html diff --git a/contributed_definitions/nyaml/NXchemical_composition.yaml b/contributed_definitions/nyaml/NXchemical_composition.yaml new file mode 100644 index 0000000000..316db2aeae --- /dev/null +++ b/contributed_definitions/nyaml/NXchemical_composition.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + (Chemical) composition of a sample or a set of things. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n: The number of samples or things. +NXchemical_composition: + # molecule descriptor + # chemical_formula(NX_CHAR): + # doc: | + # IUPAC chemical formula + total(NX_NUMBER): + doc: | + Total based on which composition information is normalized. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n]] + ION(NXion): + count(NX_NUMBER): + doc: | + Count or weight which, when divided by total yields the composition + of this element, isotope, molecule or ion. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n]] + composition(NX_NUMBER): + doc: | + Count divided by total in atom percent. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n]] diff --git a/contributed_definitions/nyaml/NXisocontour.yaml b/contributed_definitions/nyaml/NXisocontour.yaml new file mode 100644 index 0000000000..cfb693efb9 --- /dev/null +++ b/contributed_definitions/nyaml/NXisocontour.yaml @@ -0,0 +1,30 @@ +category: base +doc: | + Computational geometry description of isocontouring/phase-fields in Euclidean space. + + Iso-contouring algorithms such as MarchingCubes and others are frequently + used to segment d-dimensional regions into regions where intensities are + lower or higher than a threshold value, the so-called isovalue. + + Frequently in computational materials science phase-field methods are + used which generate data on discretized grids. Isocontour algorithms + are often used in such context to pinpoint the locations of microstructural + features from this implicit phase-field-variable-based description. + + One of the key intentions of this base class is to provide a starting point + for scientists from the phase-field community (condensed matter physicists, + and materials engineers) to incentivize that also phase-field simulation + data could be described with NeXus, provided base classes such as the this one + get further extend according to the liking of the phase-field community. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + d: The dimensionality of the description. +NXcg_isocontour: + dimensionality(NX_POSINT): + unit: NX_UNITLESS + grid(NXcg_grid): + doc: | + The discretized grid on which the iso-contour algorithm operates. + isovalue(NX_NUMBER): + doc: The threshold or iso-contour value. + unit: NX_ANY diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml new file mode 100644 index 0000000000..244aa3d64c --- /dev/null +++ b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml @@ -0,0 +1,100 @@ +category: base +doc: | + Metadata to the results of a similarity grouping analysis. + + Similarity grouping analyses can be supervised segmentation or machine learning + clustering algorithms. These are routine methods which partition the member of + a set of objects/geometric primitives into (sub-)groups, features of + different type. A plethora of algorithms have been proposed which can be applied + also on geometric primitives like points, triangles, or (abstract) features aka + objects (including categorical sub-groups). + + This base class considers metadata and results of one similarity grouping + analysis applied to a set in which objects are either categorized as noise + or belonging to a cluster. + As the results of the analysis each similarity group, here called feature + aka object can get a number of numerical and/or categorical labels. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + c: Cardinality of the set. + n_lbl_num: Number of numerical labels per object. + n_lbl_cat: Number of categorical labels per object. + n_features: Total number of similarity groups aka features, objects, clusters. +NXsimilarity_grouping: + cardinality(NX_UINT): + doc: Number of members in the set which is partitioned into features. + unit: NX_UNITLESS + number_of_numeric_labels(NX_UINT): + doc: How many numerical labels does each feature have. + unit: NX_UNITLESS + number_of_categorical_labels(NX_UINT): + doc: How many categorical labels does each feature have. + unit: NX_UNITLESS + # features(NX_CHAR): + # doc: | + # Reference to a set of features investigated in a cluster analysis. + # Features need to have disjoint numeric identifier. + identifier_offset(NX_UINT): + doc: | + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_lbl_num]] + numerical_label(NX_UINT): + doc: | + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the cluster_identifier. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, c], [2, n_lbl_num]] + categorical_label(NX_CHAR): + doc: | + Matrix of categorical attribute data for each member in the set. + # list instances of base classes of an applied cluster algorithm + # e.g. (NXclustering_hdbscan): + dimensions: + rank: 2 + dim: [[1, c], [2, n_lbl_cat]] + statistics(NXprocess): + doc: | + In addition to the detailed storage which members was grouped to which + feature/group summary statistics are stored under this group. + # at the level of the set + number_of_unassigned_members(NX_UINT): + doc: Total number of members in the set which are categorized as unassigned. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_lbl_num]] + noise(NX_UINT): + doc: Total number of members in the set which are categorized as noise. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_lbl_num]] + # at the level of the feature set + number_of_features(NX_UINT): + doc: Total number of clusters (excluding noise and unassigned). + unit: NX_UNITLESS + feature_identifier(NX_UINT): + doc: Array of numerical identifier of each feature (cluster). + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_features], [2, n_lbl_num]] + feature_member_count(NX_UINT): + doc: Array of number of members for each feature. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_features], [2, n_lbl_num]] From 6aba53ba337dc1069c7b8a1fb8211b0e92beab59 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Mon, 13 Feb 2023 14:03:00 +0100 Subject: [PATCH 096/203] Generating yml file from ./applications/*nxdl.xml in ./application/nyaml folder. --- applications/nyaml/NXarchive.yml | 87 +++ applications/nyaml/NXarpes.yml | 78 +++ applications/nyaml/NXcanSAS.yml | 965 +++++++++++++++++++++++++++ applications/nyaml/NXdirecttof.yml | 28 + applications/nyaml/NXfluo.yml | 45 ++ applications/nyaml/NXindirecttof.yml | 34 + applications/nyaml/NXiqproc.yml | 63 ++ applications/nyaml/NXlauetof.yml | 81 +++ applications/nyaml/NXmonopd.yml | 69 ++ applications/nyaml/NXmx.yml | 690 +++++++++++++++++++ applications/nyaml/NXrefscan.yml | 60 ++ applications/nyaml/NXreftof.yml | 66 ++ applications/nyaml/NXsas.yml | 130 ++++ applications/nyaml/NXsastof.yml | 104 +++ applications/nyaml/NXscan.yml | 57 ++ applications/nyaml/NXspe.yml | 45 ++ applications/nyaml/NXsqom.yml | 69 ++ applications/nyaml/NXstxm.yml | 149 +++++ applications/nyaml/NXtas.yml | 128 ++++ applications/nyaml/NXtofnpd.yml | 80 +++ applications/nyaml/NXtofraw.yml | 86 +++ applications/nyaml/NXtofsingle.yml | 81 +++ applications/nyaml/NXtomo.yml | 108 +++ applications/nyaml/NXtomophase.yml | 96 +++ applications/nyaml/NXtomoproc.yml | 69 ++ applications/nyaml/NXxas.yml | 63 ++ applications/nyaml/NXxasproc.yml | 42 ++ applications/nyaml/NXxbase.yml | 107 +++ applications/nyaml/NXxeuler.yml | 52 ++ applications/nyaml/NXxkappa.yml | 53 ++ applications/nyaml/NXxlaue.yml | 30 + applications/nyaml/NXxlaueplate.yml | 16 + applications/nyaml/NXxnb.yml | 47 ++ applications/nyaml/NXxrot.yml | 48 ++ 34 files changed, 3926 insertions(+) create mode 100644 applications/nyaml/NXarchive.yml create mode 100644 applications/nyaml/NXarpes.yml create mode 100644 applications/nyaml/NXcanSAS.yml create mode 100644 applications/nyaml/NXdirecttof.yml create mode 100644 applications/nyaml/NXfluo.yml create mode 100644 applications/nyaml/NXindirecttof.yml create mode 100644 applications/nyaml/NXiqproc.yml create mode 100644 applications/nyaml/NXlauetof.yml create mode 100644 applications/nyaml/NXmonopd.yml create mode 100644 applications/nyaml/NXmx.yml create mode 100644 applications/nyaml/NXrefscan.yml create mode 100644 applications/nyaml/NXreftof.yml create mode 100644 applications/nyaml/NXsas.yml create mode 100644 applications/nyaml/NXsastof.yml create mode 100644 applications/nyaml/NXscan.yml create mode 100644 applications/nyaml/NXspe.yml create mode 100644 applications/nyaml/NXsqom.yml create mode 100644 applications/nyaml/NXstxm.yml create mode 100644 applications/nyaml/NXtas.yml create mode 100644 applications/nyaml/NXtofnpd.yml create mode 100644 applications/nyaml/NXtofraw.yml create mode 100644 applications/nyaml/NXtofsingle.yml create mode 100644 applications/nyaml/NXtomo.yml create mode 100644 applications/nyaml/NXtomophase.yml create mode 100644 applications/nyaml/NXtomoproc.yml create mode 100644 applications/nyaml/NXxas.yml create mode 100644 applications/nyaml/NXxasproc.yml create mode 100644 applications/nyaml/NXxbase.yml create mode 100644 applications/nyaml/NXxeuler.yml create mode 100644 applications/nyaml/NXxkappa.yml create mode 100644 applications/nyaml/NXxlaue.yml create mode 100644 applications/nyaml/NXxlaueplate.yml create mode 100644 applications/nyaml/NXxnb.yml create mode 100644 applications/nyaml/NXxrot.yml diff --git a/applications/nyaml/NXarchive.yml b/applications/nyaml/NXarchive.yml new file mode 100644 index 0000000000..2dd9998d5a --- /dev/null +++ b/applications/nyaml/NXarchive.yml @@ -0,0 +1,87 @@ +doc: | + This is a definition for data to be archived by ICAT (http://www.icatproject.org/). + + .. text from the icatproject.org site + + the database (with supporting software) that provides an + interface to all ISIS experimental data and will provide + a mechanism to link all aspects of ISIS research from + proposal through to publication. +category: application +NXarchive: + entry(NXentry): + \@index: + title: + experiment_identifier(NX_CHAR): + doc: "unique identifier for the experiment" + experiment_description(NX_CHAR): + doc: "Brief description of the experiment and its objectives" + collection_identifier(NX_CHAR): + doc: "ID of user or DAQ define group of data files" + collection_description(NX_CHAR): + doc: "Brief summary of the collection, including grouping criteria" + entry_identifier(NX_CHAR): + doc: "unique identifier for this measurement as provided by the facility" + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + duration(NX_FLOAT): + unit: NX_TIME + doc: "TODO: needs documentation" + collection_time(NX_FLOAT): + unit: NX_TIME + doc: "TODO: needs documentation" + run_cycle(NX_CHAR): + doc: "TODO: needs documentation" + revision(NX_CHAR): + doc: "revision ID of this file, may be after recalibration, reprocessing etc." + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXarchive] + program(NX_CHAR): + doc: "The program and version used for generating this file" + \@version: + release_date(NX_CHAR): + unit: NX_TIME + doc: "when this file is to be released into PD" + user(NXuser): + name(NX_CHAR): + role(NX_CHAR): + doc: "role of the user" + facility_user_id(NX_CHAR): + doc: "ID of the user in the facility burocracy database" + instrument(NXinstrument): + (NXsource): + type(NX_CHAR): + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-Ray Source, Pulsed Muon Source, Rotating Anode X-Ray, Fixed Tube X-Ray] + name: + probe: + enumeration: [neutron, x-ray, electron] + name(NX_CHAR): + description(NX_CHAR): + doc: "Brief description of the instrument" + sample(NXsample): + name: + doc: "Descriptive name of sample" + sample_id(NX_CHAR): + doc: "Unique database id of the sample" + description(NX_CHAR): + type(NX_CHAR): + enumeration: [sample, sample+can, calibration sample, normalisation sample, simulated data, none, sample_environment] + chemical_formula(NX_CHAR): + doc: "Chemical formula formatted according to CIF conventions" + preparation_date(NX_CHAR): + unit: NX_TIME + situation(NX_CHAR): + doc: | + Description of the environment the sample is in: + air, vacuum, oxidizing atmosphere, dehydrated, etc. + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + magnetic_field(NX_FLOAT): + unit: NX_CURRENT + electric_field(NX_FLOAT): + unit: NX_VOLTAGE + stress_field(NX_FLOAT): + unit: NX_UNITLESS + pressure(NX_FLOAT): + unit: NX_PRESSURE diff --git a/applications/nyaml/NXarpes.yml b/applications/nyaml/NXarpes.yml new file mode 100644 index 0000000000..67f7798ae7 --- /dev/null +++ b/applications/nyaml/NXarpes.yml @@ -0,0 +1,78 @@ +doc: | + This is an application definition for angular resolved photo electron spectroscopy. + + It has been drawn up with hemispherical electron analysers in mind. +category: application +NXarpes: + (NXentry): + \@entry: + doc: | + NeXus convention is to use "entry1", "entry2", ... + for analysis software to locate each entry. + title(NX_CHAR): + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms." + enumeration: [NXarpes] + (NXinstrument): + (NXsource): + type(NX_CHAR): + name(NX_CHAR): + probe: + enumeration: [x-ray] + monochromator(NXmonochromator): + energy(NX_NUMBER): + unit: NX_ENERGY + analyser(NXdetector): + data(NX_NUMBER): + lens_mode(NX_CHAR): + doc: "setting for the electron analyser lens" + acquisition_mode: + enumeration: [swept, fixed] + entrance_slit_shape: + enumeration: [curved, straight] + entrance_slit_setting(NX_NUMBER): + unit: NX_ANY + doc: "dial setting of the entrance slit" + entrance_slit_size(NX_NUMBER): + unit: NX_LENGTH + doc: "size of the entrance slit" + pass_energy(NX_NUMBER): + unit: NX_ENERGY + doc: "energy of the electrons on the mean path of the analyser" + time_per_channel(NX_NUMBER): + unit: NX_TIME + doc: "todo: define more clearly" + angles(NX_NUMBER): + unit: NX_ANGLE + doc: | + Angular axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + energies(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + sensor_size(NX_INT): + doc: "number of raw active elements in each dimension" + dimensions: + rank: 1 + dim: [[1, 2]] + region_origin(NX_INT): + doc: "origin of rectangular region selected for readout" + dimensions: + rank: 1 + dim: [[1, 2]] + region_size(NX_INT): + doc: "size of rectangular region selected for readout" + dimensions: + rank: 1 + dim: [[1, 2]] + (NXsample): + name(NX_CHAR): + doc: "Descriptive name of sample" + temperature(NX_NUMBER): + unit: NX_TEMPERATURE + (NXdata): diff --git a/applications/nyaml/NXcanSAS.yml b/applications/nyaml/NXcanSAS.yml new file mode 100644 index 0000000000..2de590b633 --- /dev/null +++ b/applications/nyaml/NXcanSAS.yml @@ -0,0 +1,965 @@ +doc: | + Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. + + .. index:: canSAS + + For more details, see: + + * http://www.cansas.org/ + * http://www.cansas.org/formats/canSAS1d/1.1/doc/ + * http://cansas-org.github.io/canSAS2012/ + * https://github.com/canSAS-org/NXcanSAS_examples + + The minimum requirements for *reduced* small-angle scattering data + as described by canSAS are summarized in the following figure: + + .. _canSAS_2012_minimum: + + .. figure:: canSAS/2012-minimum.png + :width: 60% + + The minimum requirements for *reduced* small-angle scattering data. + (:download:`full image `) + See :ref:`below ` for the minimum required + information for a NeXus data file + written to the NXcanSAS specification. + + .. rubric:: Implementation of canSAS standard in NeXus + + This application definition is an implementation of the canSAS + standard for storing both one-dimensional and multi-dimensional + *reduced* small-angle scattering data. + + * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. + * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` + * External file links are not to be used for the reduced data. + * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. + * There is no need for NXcanSAS to refer to any raw data. + + The canSAS data format has a structure similar to NeXus, not identical. + To allow canSAS data to be expressed in NeXus, yet identifiable + by the canSAS standard, an additional group attribute ``canSAS_class`` + was introduced. Here is the mapping of some common groups. + + =============== ============ ========================== + group (*) NX_class canSAS_class + =============== ============ ========================== + sasentry NXentry SASentry + sasdata NXdata SASdata + sasdetector NXdetector SASdetector + sasinstrument NXinstrument SASinstrument + sasnote NXnote SASnote + sasprocess NXprocess SASprocess + sasprocessnote NXcollection SASprocessnote + sastransmission NXdata SAStransmission_spectrum + sassample NXsample SASsample + sassource NXsource SASsource + =============== ============ ========================== + + (*) The name of each group is a suggestion, + not a fixed requirement and is chosen as fits each data file. + See the section on defining + :ref:`NXDL group and field names `. + + Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) + for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. + + .. _NXcanSAS_minimum: + + .. rubric:: The minimum required information for a NeXus data file + written to the NXcanSAS specification. + + .. literalinclude:: canSAS/minimum-required.txt + :tab-width: 4 + :linenos: + :language: text +category: application +NXcanSAS: + (NXentry): + \@default: + doc: | + .. index:: plotting + + Declares which :ref:`NXdata` group + contains the data to be shown by default. + It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. + The value is the name of the default :ref:`NXdata` group. + Usually, this will be the name of the first *SASdata* group. + doc: | + .. index:: NXcanSAS (applications); SASentry + + Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group + (when data from multiple techniques are being stored) + or as a replacement for the ``NXentry`` group. + + Note: It is required for all numerical objects to provide + a *units* attribute that describes the engineering units. + Use the Unidata UDunits [#]_ specification + as this is compatible with various community standards. + + .. [#] The UDunits specification also includes instructions for derived units. + \@canSAS_class: + doc: | + Official canSAS group: **SASentry** + enumeration: [SASentry] + \@version: + doc: | + Describes the version of the canSAS standard used to write this data. + This must be a text (not numerical) representation. Such as:: + + @version="1.1" + enumeration: [1.1] + definition: + doc: "Official NeXus NXDL schema to which this subentry conforms." + enumeration: [NXcanSAS] + (NXdata): + doc: | + A *SASData* group contains a single reduced small-angle scattering data set + that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. + + *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) + + The name of each *SASdata* group must be unique within a SASentry group. + Suggest using names such as ``sasdata01``. + + NOTE: For the first *SASdata* group, be sure to write the chosen name + into the `SASentry/@default` attribute, as in:: + + SASentry/@default="sasdata01" + + A *SASdata* group has several attributes: + + * I_axes + * Q_indices + * Mask_indices + + To indicate the dependency relationships of other varied parameters, + use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` + or ``@Pressure_indices``). + \@canSAS_class: + doc: "Official canSAS group: :index:`NXcanSAS (applications); SASdata`" + enumeration: [SASdata] + \@signal: + doc: | + Name of the default data field. + enumeration: + I: + doc: "For canSAS **SASdata**, this is always 'I'." + \@I_axes: + doc: | + String array that defines the independent data fields used in + the default plot for all of the dimensions of the *signal* field + (the *signal* field is the field in this group that is named by + the ``signal`` attribute of this group). + One entry is provided for every dimension of the ``I`` data object. + Such as:: + + @I_axes="Temperature", "Time", "Pressure", "Q", "Q" + + Since there are five items in the list, the intensity field of this example + ``I`` must be a five-dimensional array (rank=5). + \@Q_indices: + doc: | + Integer or integer array that describes which indices + (of the :math:`I` data object) are used to + reference the ``Q`` data object. The items in this array + use zero-based indexing. Such as:: + + @Q_indices=1,3,4 + + which indicates that ``Q`` requires three indices + from the :math:`I` data object: one for time and + two for Q position. Thus, in this example, the + ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. + \@mask: + doc: | + Name of the data mask field. + + .. see: https://github.com/nexusformat/definitions/issues/533 + + The data *mask* must have the same shape as the *data* field. + Positions in the mask correspond to positions in the *data* field. + The value of the mask field may be either a boolean array + where ``false`` means *no mask* and ``true`` means *mask* + or a more descriptive array as as defined in :ref:`NXdetector`. + \@Mask_indices: + doc: | + Integer or integer array that describes which indices + (of the :math:`I` data object) are used to + reference the ``Mask`` data object. The items in this + array use zero-based indexing. Such as:: + + @Mask_indices=3,4 + + which indicates that Q requires two indices + from the :math:`I` data object for Q position. + \@timestamp: + doc: | + ISO-8601 time [#iso8601]_ + Q(NX_NUMBER): + unit: NX_PER_LENGTH + doc: | + .. index:: NXcanSAS (applications); Q + + Array of :math:`Q` data to accompany :math:`I`. + + .. figure:: canSAS/Q-geometry.jpg + :width: 60% + + The :math:`\vec{Q}` geometry. + (:download:`full image `) + + :math:`Q` may be represented as either + the three-dimensional scattering vector :math:`\vec{Q}` + or the magnitude of the scattering vector, :math:`|\vec{Q}|`. + + .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) + + When we write :math:`Q`, we may refer to either or both of + :math:`|\vec{Q}|` + or :math:`\vec{Q}`, depending on the context. + \@units: + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units will generate + a warning from validation software and may not + be processed by some analysis software packages. + enumeration: + 1/m: + 1/nm: + doc: "preferred" + 1/angstrom: + \@uncertainties: + doc: | + (optional: for numerical arrays) + + Names the dataset (in this SASdata group) that provides the + uncertainty to be used for data analysis. + The name of the dataset containing the :math:`Q` uncertainty + is flexible. The name must be unique in the *SASdata* group. + + .. comment + see: https://github.com/canSAS-org/canSAS2012/issues/7 + + Such as:: + + @uncertainties="Q_uncertainties" + + The *uncertainties* field will have the same *shape* (dimensions) + as the Q field. + + These values are the estimates of uncertainty of each Q. By default, + this will be interpreted to be the estimated standard deviation. + In special cases, when a standard deviation cannot possibly be used, + its value can specify another measure of distribution width. + + There may also be a subdirectory (optional) with constituent + components. + + .. note:: To report distribution in reported :math:`Q` values, + use the ``@resolutions`` attribute. It is possible for both + ``@resolutions`` and ``uncertainties`` to be reported. + \@resolutions: + doc: | + .. index:: NXcanSAS (applications); resolutions + + (optional: for numerical arrays) + + Names the dataset (in this SASdata group) containing the :math:`Q` resolution. + The name of the dataset containing the :math:`Q` resolution + is flexible. The name must be unique in the *SASdata* group. + + .. comment + see: https://github.com/canSAS-org/canSAS2012/issues/7 + + The *resolutions* field will have the same *shape* (dimensions) + as the Q field. + + Generally, this is the principal resolution of each :math:`Q`. + Names the data object (in this SASdata group) that provides the + :math:`Q` resolution to be used for data analysis. Such as:: + + @resolutions="Qdev" + + To specify two-dimensional resolution for slit-smearing geometry, + such as (*dQw*, *dQl*), use a string array, such as:: + + @resolutions="dQw", "dQl" + + There may also be a subdirectory (optional) with constituent + components. + + This pattern will demonstrate how to introduce further as-yet + unanticipated terms related to the data. + + .. comment + see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 + + By default, the values of the resolutions data object are assumed to be + one standard deviation of any function used to approximate the + resolution function. This equates to the width of the gaussian + distribution if a Gaussian is chosen. See the ``@resolutions_description`` + attribute. + + .. note:: To report uncertainty in reported :math:`Q` values, + use the ``@uncertainties`` attribute. It is possible for both + ``@resolutions`` and ``uncertainties`` to be reported. + \@resolutions_description: + doc: | + (optional) + Generally, this describes the :math:`Q` ``@resolutions`` data object. + By default, the value is assumed to be "Gaussian". These are + suggestions: + + * Gaussian + * Lorentzian + * Square : + note that the full width of the square would be ~2.9 times + the standard deviation specified in the vector + * Triangular + * Sawtooth-outward : vertical edge pointing to larger Q + * Sawtooth-inward vertical edge pointing to smaller Q + * Bin : range of values contributing + (for example, when 2-D detector data have been reduced + to a 1-D :math:`I(|Q|)` dataset) + + For other meanings, it may be necessary to provide further details + such as the function used to assess the resolution. + In such cases, use additional datasets or a :ref:`NXnote` subgroup + to include that detail. + I(NX_NUMBER): + doc: | + .. index:: NXcanSAS (applications); I + + Array of intensity (:math:`I`) data. + + The intensity may be represented in one of these forms: + + **absolute units**: :math:`d\Sigma/d\Omega(Q)` + differential cross-section + per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) + + **absolute units**: :math:`d\sigma/d\Omega(Q)` + differential cross-section + per unit atom per unit solid angle (such as: cm^2 or m^2) + + **arbitrary units**: :math:`I(Q)` + usually a ratio of two detectors + but units are meaningless (such as: a.u. or counts) + + This presents a few problems + for analysis software to sort out when reading the data. + Fortunately, it is possible to analyze the *units* to determine which type of + intensity is being reported and make choices at the time the file is read. But this is + an area for consideration and possible improvement. + + One problem arises with software that automatically converts data into some canonical + units used by that software. The software should not convert units between these different + types of intensity indiscriminately. + + A second problem is that when arbitrary units are used, then the set of possible + analytical results is restricted. With such units, no meaningful volume fraction + or number density can be determined directly from :math:`I(Q)`. + + In some cases, it is possible to apply a factor to convert the arbitrary + units to an absolute scale. This should be considered as a possibility + of the analysis process. + + Where this documentation says *typical units*, it is possible that small-angle + data may be presented in other units and still be consistent with NeXus. + See the :ref:`design-units` section. + \@units: + doc: | + Engineering units to use when expressing + :math:`I` and intensity-related terms. + + Data expressed in other units (or missing a ``@units`` attribute) + will be treated as ``arbitrary`` by some software packages. + + For software using the UDUNITS-2 library, ``arbitrary`` will be + changed to ``unknown`` for handling with that library. + enumeration: + 1/m: + doc: "includes m2/m3 and 1/m/sr" + 1/cm: + doc: "includes cm2/cm3 and 1/cm/sr" + m2/g: + cm2/g: + arbitrary: + \@uncertainties: + doc: | + (optional: for numerical arrays) + + Names the dataset (in this SASdata group) that provides the + uncertainty of :math:`I` to be used for data analysis. + The name of the dataset containing the :math:`I` uncertainty + is flexible. The name must be unique in the *SASdata* group. + + .. comment + see: https://github.com/canSAS-org/canSAS2012/issues/7 + + Generally, this is the estimate of the uncertainty of each :math:`I`. + Typically the estimated standard deviation. + + *Idev* is the canonical name from the 1D standard. + The NXcanSAS standard allows for the name to be described using this attribute. + Such as:: + + @uncertainties="Idev" + \@scaling_factor: + doc: | + (optional) + Names the field (a.k.a. dataset) that contains a factor + to multiply ``I``. By default, this value is unity. + Should an uncertainty be associated with the scaling factor + field, the field containing that uncertainty would be + designated via the ``uncertainties`` attribute. + Such as:: + + I : NX_NUMBER + @uncertainties="Idev" : NX_CHAR + @scaling_factor="I_scaling" : NX_CHAR + Idev : NX_NUMBER + I_scaling : NX_NUMBER + @uncertainties="I_scaling_dev" : NX_CHAR + I_scaling_dev : NX_NUMBER + + The exact names for ``I_scaling`` and ``I_scaling_dev`` are not + defined by NXcanSAS. The user has the flexibility to use names + different than those shown in this example. + Idev(NX_NUMBER): + doc: | + .. index:: NXcanSAS (applications); Idev + + Estimated **uncertainty** (usually standard deviation) + in :math:`I`. Must have the same units as :math:`I`. + + When present, the name of this field is also + recorded in the *uncertainties* attribute of *I*, as in:: + + I/@uncertainties="Idev" + \@units: + doc: | + Engineering units to use when expressing + :math:`I` and intensity-related terms. + + Data expressed in other units (or missing a ``@units`` attribute) + will generate a warning from any validation process + and will be treated as ``arbitrary`` by some analysis software packages. + + For software using the UDUNITS-2 library, ``arbitrary`` will be + changed to ``unknown`` for handling with that library. + enumeration: + 1/m: + doc: "includes m2/m3 and 1/m/sr" + 1/cm: + doc: "includes cm2/cm3 and 1/cm/sr" + m2/g: + cm2/g: + arbitrary: + Qdev(NX_NUMBER): + unit: NX_PER_LENGTH + doc: | + .. index:: NXcanSAS (applications); Qdev + + Estimated :math:`Q` **resolution** (usually standard deviation). + Must have the same units as :math:`Q`. + + When present, the name of this field is also + recorded in the *resolutions* attribute of *Q*, + as in:: + + Q/@resolutions="Qdev" + + or:: + + Q/@resolutions="dQw", "dQl" + \@units: + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units may not be processed by some + software packages. + enumeration: + 1/m: + 1/nm: + doc: "preferred" + 1/angstrom: + dQw(NX_NUMBER): + unit: NX_PER_LENGTH + doc: | + .. index:: NXcanSAS (applications); dQw + + :math:`Q` **resolution** along the axis of scanning + (the high-resolution *slit width* direction). + Useful for defining resolution data from + slit-smearing instruments such as Bonse-Hart geometry. + Must have the same units as :math:`Q`. + + When present, the name of this field is also + recorded in the *resolutions* attribute of *Q*, + as in:: + + Q/@resolutions="dQw", "dQl" + \@units: + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units may not be processed by some + software packages. + enumeration: + 1/m: + 1/nm: + doc: "preferred" + 1/angstrom: + dQl(NX_NUMBER): + unit: NX_PER_LENGTH + doc: | + .. index:: NXcanSAS (applications); dQl + + :math:`Q` **resolution** perpendicular to the axis of scanning + (the low-resolution *slit length* direction). + Useful for defining resolution data from + slit-smearing instruments such as Bonse-Hart geometry. + Must have the same units as :math:`Q`. + + When present, the name of this field is also + recorded in the *resolutions* attribute of *Q*, + as in:: + + Q/@resolutions="dQw", "dQl" + \@units: + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units may not be processed by some + software packages. + enumeration: + 1/m: + 1/nm: + doc: "preferred" + 1/angstrom: + Qmean(NX_NUMBER): + unit: NX_PER_LENGTH + doc: | + Mean value of :math:`Q` for this data point. + Useful when describing data that has been + binned from higher-resolution data. + + It is expected that ``Q`` is provided + and that both ``Q`` and ``Qmean`` will have the same units. + \@units: + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units may not be processed by some + software packages. + enumeration: + 1/m: + 1/nm: + doc: "preferred" + 1/angstrom: + ShadowFactor: + unit: NX_DIMENSIONLESS + doc: | + A numerical factor applied to pixels affected by the beam stop penumbra. + Used in data files from NIST/NCNR instruments. + + See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. + title: + exists: [min, 1, max, 1] + doc: | + Title of this *SASentry*. + Make it so that you can recognize the data by its title. + Could be the name of the sample, + the name for the measured data, or something else representative. + run: + exists: [min, 1, max, unbounded] + doc: | + Run identification for this *SASentry*. + For many facilities, this is an integer, such as en experiment number. + Use multiple instances of ``run`` as needed, keeping + in mind that HDF5 requires unique names for all entities + in a group. + \@name: + doc: | + Optional string attribute to identify this particular *run*. + Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. + (NXinstrument): + \@canSAS_class: + doc: "Official canSAS group: :index:`NXcanSAS (applications); SASinstrument`" + enumeration: [SASinstrument] + doc: | + Description of the small-angle scattering instrument. + + Consider, carefully, the relevance to the SAS data analysis process + when adding subgroups in this **NXinstrument** group. Additional information + can be added but will likely be ignored by standardized data anlysis processes. + + The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** + group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any + point downstream from the source. + (NXaperture): + doc: | + :ref:`NXaperture` is generic and limits the variation in data files. + + Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. + \@canSAS_class: + doc: "Official canSAS group: :index:`NXcanSAS (applications); SASaperture`" + enumeration: [SASaperture] + shape: + doc: | + describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) + x_gap(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "opening along the :math:`x` axis" + y_gap(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "opening along the :math:`y` axis" + (NXcollimator): + \@canSAS_class: + doc: "Official canSAS group: :index:`NXcanSAS (applications); SAScollimation`" + enumeration: [SAScollimation] + doc: | + Description of a collimating element (defines the divergence of the beam) in the instrument. + + To document a slit, pinhole, or the beam, refer to the + documentation of the ``NXinstrument`` group above. + length(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Amount/length of collimation inserted (as on a SANS instrument)" + distance(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Distance from this collimation element to the sample" + (NXdetector): + \@canSAS_class: + doc: "Official canSAS group: :index:`NXcanSAS (applications); SASdetector`" + enumeration: [SASdetector] + doc: | + Description of a detector in the instrument. + name: + doc: "Identifies the name of this detector" + SDD(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: | + Distance between sample and detector. + + Note: In NXdetector, the ``distance`` field records the + distance to the previous component ... most often the sample. + This use is the same as ``SDD`` for most SAS + instruments but not all. For example, Bonse-Hart cameras + have one or more crystals between the sample and detector. + + We define here the field ``SDD`` to document without + ambiguity the distance between sample and detector. + slit_length(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_PER_LENGTH + doc: | + Slit length of the instrument for this detector, + expressed in the same units as :math:`Q`. + x_position(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Location of the detector in :math:`x`" + y_position(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Location of the detector in :math:`y`" + roll(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_ANGLE + doc: "Rotation of the detector about the :math:`z` axis (roll)" + pitch(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_ANGLE + doc: "Rotation of the detector about the :math:`x` axis (roll)" + yaw(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_ANGLE + doc: "Rotation of the detector about the :math:`y` axis (yaw)" + beam_center_x(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: | + Position of the beam center on the detector. + + This is the x position where the direct beam would hit the detector plane. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. The value can be any + real number (positive, zero, or negative). + beam_center_y(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: | + Position of the beam center on the detector. + + This is the y position where the direct beam would hit the detector plane. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. The value can be any + real number (positive, zero, or negative). + x_pixel_size(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Size of each detector pixel. If it is scalar all pixels are the same size" + y_pixel_size(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Size of each detector pixel. If it is scalar all pixels are the same size" + (NXsource): + \@canSAS_class: + doc: "Official canSAS group: :index:`NXcanSAS (applications); SASsource`" + enumeration: [SASsource] + doc: | + Description of the radiation source. + radiation: + doc: | + Name of the radiation used. + Note that this is **not** the name of the facility! + + This field contains a value from either the + ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, + it is redundant with existing NeXus structure. + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + beam_shape: + exists: [min, 0, max, 1] + doc: "Text description of the shape of the beam (incident on the sample)." + incident_wavelength(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_WAVELENGTH + doc: wavelength (:math:`\lambda`) of radiation incident on the sample + wavelength_min(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_WAVELENGTH + doc: | + Some facilities specify wavelength using a range. + This is the lowest wavelength in such a range. + wavelength_max(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_WAVELENGTH + doc: | + Some facilities specify wavelength using a range. + This is the highest wavelength in such a range. + incident_wavelength_spread(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_WAVELENGTH + doc: | + Some facilities specify wavelength using a range. + This is the width (FWHM) of such a range. + beam_size_x(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Size of the incident beam along the x axis." + beam_size_y(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Size of the incident beam along the y axis." + (NXsample): + \@canSAS_class: + doc: "Official canSAS group: :index:`NXcanSAS (applications); SASsample`" + enumeration: [SASsample] + doc: | + Description of the sample. + name: + doc: "**ID**: Text string that identifies this sample." + thickness(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Thickness of this sample" + transmission(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_DIMENSIONLESS + doc: | + Transmission (:math:`I/I_0`) of this sample. + There is no *units* attribute as this number is dimensionless. + + Note: the ability to store a transmission *spectrum*, + instead of a single value, is provided elsewhere in the structure, + in the *SAStransmission_spectrum* element. + temperature(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_TEMPERATURE + doc: "Temperature of this sample." + details: + exists: [min, 0, max, unbounded] + doc: "Any additional sample details." + x_position(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Location of the sample in :math:`x`" + y_position(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Location of the sample in :math:`y`" + roll(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_ANGLE + doc: "Rotation of the sample about the :math:`z` axis (roll)" + pitch(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_ANGLE + doc: "Rotation of the sample about the :math:`x` axis (roll)" + yaw(NX_NUMBER): + exists: [min, 0, max, 1] + unit: NX_ANGLE + doc: "Rotation of the sample about the :math:`y` axis (yaw)" + (NXprocess): + exists: [min, 0, max, unbounded] + \@canSAS_class: + doc: "Official canSAS group: :index:`NXcanSAS (applications); SASprocess`" + enumeration: [SASprocess] + doc: | + Description of a processing or analysis step. + + Add additional fields as needed to describe value(s) of any + variable, parameter, or term related to the *SASprocess* step. + Be sure to include *units* attributes for all numerical fields. + name: + exists: [min, 0, max, 1] + doc: "Optional name for this data processing or analysis step" + date(NX_DATE_TIME): + exists: [min, 0, max, 1] + doc: | + Optional date for this data processing or analysis step. [#iso8601]_ + + + .. [#iso8601] ISO-8601 standard time representation. + + NeXus dates and times are reported in ISO-8601 + (e.g., ``yyyy-mm-ddThh:mm:ss``) + or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). + + See: http://www.w3.org/TR/NOTE-datetime + or http://en.wikipedia.org/wiki/ISO_8601 for more details. + description: + exists: [min, 0, max, 1] + doc: "Optional description for this data processing or analysis step" + term: + exists: [min, 0, max, unbounded] + doc: | + Specifies the value of a single variable, parameter, + or term (while defined here as a string, it could be a number) + related to the *SASprocess* step. + + Note: + The name *term* is not required, it could take any name, + as long as the name is unique within this group. + (NXnote): + exists: [min, 0, max, unbounded] + doc: | + Any additional notes or subprocessing steps will be documented here. + + An **NXnote** group can be added to any NeXus group at or below the + **NXentry** group. It is shown here as a suggestion of a good place + to *consider* its use. + (NXcollection): + exists: [min, 0, max, unbounded] + doc: | + Describes anything about *SASprocess* that is not already described. + + Any content not defined in the canSAS standard can be placed at this point. + + Note: + The name of this group is flexible, it could take any name, + as long as it is unique within the **NXprocess** group. + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` + enumeration: [SASprocessnote] + (NXcollection): + exists: [min, 0, max, unbounded] + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASnote` + enumeration: [SASnote] + doc: | + Free form description of anything not covered by other elements. + TRANSMISSION_SPECTRUM(NXdata): + doc: | + The *SAStransmission_spectrum* element + + This describes certain data obtained from a variable-wavelength source + such as pulsed-neutron source. + + + The name of each *SAStransmission_spectrum* group must be unique within a SASentry group. + Suggest using names such as ``sastransmission_spectrum01``. + \@canSAS_class: + doc: "Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum`" + enumeration: [SAStransmission_spectrum] + \@signal: + doc: | + Name of the default data field. + enumeration: + T: + doc: "For **SAStransmission_spectrum**, this is always 'T'." + \@T_axes: + enumeration: + T: + doc: "the wavelengths field (as a dimension scale) corresponding to this transmission" + \@name: + doc: | + Identify what type of spectrum is being described. + It is expected that this value will take either of these two values: + + ====== ============================================== + value meaning + ====== ============================================== + sample measurement with the sample and container + can measurement with just the container + ====== ============================================== + \@timestamp: + doc: | + ISO-8601 time [#iso8601]_ + lambda(NX_NUMBER): + unit: NX_WAVELENGTH + doc: | + Wavelength of the radiation. + + This array is of the same shape as ``T`` and ``Tdev``. + T(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Transmission values (:math:`I/I_0`) + as a function of wavelength. + + This array is of the same shape as ``lambda`` and ``Tdev``. + \@uncertainties: + doc: | + Names the dataset (in this SASdata group) that provides the + uncertainty of each transmission :math:`T` to be used for data analysis. + The name of the dataset containing the :math:`T` uncertainty + is expected to be ``Tdev``. + + .. comment + see: https://github.com/canSAS-org/canSAS2012/issues/7 + + Typically: + + @uncertainties="Tdev" + Tdev(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + .. index:: NXcanSAS (applications); Tdev + + Estimated uncertainty (usually standard deviation) + in :math:`T`. Must have the same units as :math:`T`. + + This is the field is named in the *uncertainties* attribute of *T*, as in:: + + T/@uncertainties="Tdev" + + This array is of the same shape as ``lambda`` and ``T``. diff --git a/applications/nyaml/NXdirecttof.yml b/applications/nyaml/NXdirecttof.yml new file mode 100644 index 0000000000..c9c47c95db --- /dev/null +++ b/applications/nyaml/NXdirecttof.yml @@ -0,0 +1,28 @@ +doc: | + This is a application definition for raw data from a direct geometry TOF spectrometer +category: application +NXdirecttof(NXtofraw): + entry(NXentry): + title: + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXdirecttof] + (NXinstrument): + fermi_chopper(NXfermi_chopper): + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: "chopper rotation speed" + energy(NX_FLOAT): + unit: NX_ENERGY + doc: "energy selected" + disk_chopper(NXdisk_chopper): + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: "chopper rotation speed" + energy(NX_FLOAT): + unit: NX_ENERGY + doc: "energy selected" + doc: | + We definitly want the rotation_speed and energy of the chopper. Thus either + a fermi_chopper or a disk_chopper group is required. diff --git a/applications/nyaml/NXfluo.yml b/applications/nyaml/NXfluo.yml new file mode 100644 index 0000000000..791a7138b0 --- /dev/null +++ b/applications/nyaml/NXfluo.yml @@ -0,0 +1,45 @@ +doc: | + This is an application definition for raw data from an X-ray fluorescence experiment +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nE: "Number of energies" +category: application +NXfluo: + entry(NXentry): + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms. + enumeration: [NXfluo] + (NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [x-ray] + monochromator(NXmonochromator): + wavelength(NX_FLOAT): + fluorescence(NXdetector): + data(NX_INT): + dimensions: + rank: 1 + dim: [[1, nE]] + energy(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nE]] + (NXsample): + name: + doc: "Descriptive name of sample" + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + data(NX_INT): + data(NXdata): diff --git a/applications/nyaml/NXindirecttof.yml b/applications/nyaml/NXindirecttof.yml new file mode 100644 index 0000000000..ebce9380c1 --- /dev/null +++ b/applications/nyaml/NXindirecttof.yml @@ -0,0 +1,34 @@ +doc: | + This is a application definition for raw data from a direct geometry TOF spectrometer +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nDet: "Number of detectors" +category: application +NXindirecttof(NXtofraw): + entry(NXentry): + title: + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXindirecttof] + (NXinstrument): + analyser(NXmonochromator): + energy(NX_FLOAT): + unit: NX_ENERGY + doc: "analyzed energy" + dimensions: + rank: 1 + dim: [[1, nDet]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "polar angle towards sample" + dimensions: + rank: 1 + dim: [[1, nDet]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "distance from sample" + dimensions: + rank: 1 + dim: [[1, nDet]] diff --git a/applications/nyaml/NXiqproc.yml b/applications/nyaml/NXiqproc.yml new file mode 100644 index 0000000000..d625fbc735 --- /dev/null +++ b/applications/nyaml/NXiqproc.yml @@ -0,0 +1,63 @@ +doc: | + Application definition for any :math:`I(Q)` data. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nVars: "The number of values taken by the varied variable" + nQX: "Number of values for the first dimension of Q" + nQY: "Number of values for the second dimension of Q" +category: application +NXiqproc: + (NXentry): + \@entry: + title: + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXiqproc] + instrument(NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + name(NX_CHAR): + doc: "Name of the instrument from which this data was reduced." + (NXsample): + name: + doc: "Descriptive name of sample" + reduction(NXprocess): + program(NX_CHAR): + version(NX_CHAR): + input(NXparameters): + filenames(NX_CHAR): + doc: "Raw data files used to generate this I(Q)" + doc: "Input parameters for the reduction program used" + output(NXparameters): + doc: "Eventual output parameters from the data reduction program used" + (NXdata): + data(NX_INT): + doc: | + This is I(Q). The client has to analyse the dimensions + of I(Q). Often, multiple I(Q) for various environment + conditions are measured; that would be the first + dimension. Q can be multidimensional, this accounts for + the further dimensions in the data + dimensions: + rank: 3 + dim: [[1, nVars], [2, nQX], [3, nQY]] + variable(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, nVars]] + \@varied_variable: + doc: "The real name of the varied variable in the first dim of data, temperature, P, MF etc..." + qx(NX_NUMBER): + doc: "Values for the first dimension of Q" + dimensions: + rank: 1 + dim: [[1, nQX]] + qy(NX_NUMBER): + doc: "Values for the second dimension of Q" + dimensions: + rank: 1 + dim: [[1, nQY]] diff --git a/applications/nyaml/NXlauetof.yml b/applications/nyaml/NXlauetof.yml new file mode 100644 index 0000000000..52938ea47c --- /dev/null +++ b/applications/nyaml/NXlauetof.yml @@ -0,0 +1,81 @@ +doc: | + This is the application definition for a TOF laue diffractometer +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nXPixels: "Number of X pixels" + nYPixels: "Number of Y pixels" + nTOF: "Time of flight" +category: application +NXlauetof: + entry(NXentry): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXlauetof] + instrument(NXinstrument): + detector(NXdetector): + doc: | + This assumes a planar 2D detector. All angles and distances refer to the center of the + detector. + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "The polar_angle (two theta) where the detector is placed." + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "The azimuthal angle where the detector is placed." + data(NX_INT): + dimensions: + rank: 3 + dim: [[1, nXPixels], [2, nYPixels], [3, nTOF]] + \@signal: + enumeration: [1] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + distance(NX_FLOAT): + unit: NX_LENGTH + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTOF]] + sample(NXsample): + name: + doc: "Descriptive name of sample" + orientation_matrix(NX_FLOAT): + doc: | + The orientation matrix according to Busing and + Levy conventions. This is not strictly necessary as + the UB can always be derived from the data. But + let us bow to common usage which includes thie + UB nearly always. + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + unit_cell(NX_FLOAT): + doc: | + The unit cell, a, b, c, alpha, beta, gamma. + Again, not strictly necessary, but normally written. + dimensions: + rank: 1 + dim: [[1, 6]] + control(NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) or received monitor counts + (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + data(NX_INT): + doc: "use these attributes ``primary=1 signal=1``" + dimensions: + rank: 1 + dim: [[1, nTOF]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTOF]] + name(NXdata): diff --git a/applications/nyaml/NXmonopd.yml b/applications/nyaml/NXmonopd.yml new file mode 100644 index 0000000000..6242d85c02 --- /dev/null +++ b/applications/nyaml/NXmonopd.yml @@ -0,0 +1,69 @@ +doc: | + Monochromatic Neutron and X-Ray Powder diffractometer + + Instrument + definition for a powder diffractometer at a monochromatic neutron + or X-ray beam. This is both suited for a powder diffractometer + with a single detector or a powder diffractometer with a position + sensitive detector. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + i: "i is the number of wavelengths" + nDet: "Number of detectors" +category: application +NXmonopd: + entry(NXentry): + title: + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXmonopd] + (NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + (NXcrystal): + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: "Optimum diffracted wavelength" + dimensions: + rank: 1 + dim: [[1, i]] + (NXdetector): + polar_angle(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nDet]] + data(NX_INT): + doc: | + detector signal (usually counts) are already + corrected for detector efficiency + dimensions: + rank: 1 + dim: [[1, nDet]] + (NXsample): + name: + doc: "Descriptive name of sample" + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder diagram + has been obtained through an omega-2theta scan like from a + traditional single detector powder diffractometer + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + integral(NX_FLOAT): + unit: NX_ANY + doc: "Total integral monitor counts" + (NXdata): + doc: "Link to polar angle in /NXentry/NXinstrument/NXdetector" + doc: "Link to data in /NXentry/NXinstrument/NXdetector" diff --git a/applications/nyaml/NXmx.yml b/applications/nyaml/NXmx.yml new file mode 100644 index 0000000000..fb0567f007 --- /dev/null +++ b/applications/nyaml/NXmx.yml @@ -0,0 +1,690 @@ +doc: | + functional application definition for macromolecular crystallography +symbols: + doc: | + These symbols will be used below to coordinate datasets + with the same shape. Most MX x-ray detectors will produce + two-dimensional images. Some will produce three-dimensional + images, using one of the indices to select a detector module. + dataRank: "Rank of the ``data`` field" + nP: "Number of scan points" + i: "Number of detector pixels in the slowest direction" + j: "Number of detector pixels in the second slowest direction" + k: "Number of detector pixels in the third slowest direction" + m: "Number of channels in the incident beam spectrum, if known" + groupIndex: "An array of the hierarchical levels of the parents of detector + elements or groupings of detector elements. + A top-level element or grouping has parent level -1." +category: application +NXmx: + (NXentry): + doc: | + Note, it is recommended that ``file_name`` and ``file_time`` are included + as attributes at the root of a file that includes :ref:`NXmx`. See + :ref:`NXroot`. + \@version: + doc: | + Describes the version of the NXmx definition used to write this data. + This must be a text (not numerical) representation. Such as:: + + @version="1.0" + enumeration: [1.0] + title(NX_CHAR): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time/date of the first data point collected in UTC, + using the Z suffix to avoid confusion with local time. + Note that the time zone of the beamline should be provided in + NXentry/NXinstrument/time_zone. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time/date of the last data point collected in UTC, + using the Z suffix to avoid confusion with local time. + Note that the time zone of the beamline should be provided in + NXentry/NXinstrument/time_zone. This field should only be + filled when the value is accurately observed. If the data + collection aborts or otherwise prevents accurate recording of + the end_time, this field should be omitted. + end_time_estimated(NX_DATE_TIME): + doc: | + ISO 8601 time/date of the last data point collected in UTC, + using the Z suffix to avoid confusion with local time. + Note that the time zone of the beamline should be provided in + NXentry/NXinstrument/time_zone. This field may be filled + with a value estimated before an observed value is available. + definition: + doc: "NeXus NXDL schema to which this file conforms" + enumeration: [NXmx] + (NXdata): + data(NX_NUMBER): + exists: recommended + doc: | + For a dimension-2 detector, the rank of the data array will be 3. + For a dimension-3 detector, the rank of the data array will be 4. + This allows for the introduction of the frame number as the + first index. + dimensions: + rank: dataRank + dim: [[1, nP], [2, i], [3, j], [4, k]] + (NXsample): + name(NX_CHAR): + doc: "Descriptive name of sample" + depends_on(NX_CHAR): + doc: | + This is a requirement to describe for any scan experiment. + + The axis on which the sample position depends may be stored + anywhere, but is normally stored in the NXtransformations + group within the NXsample group. + + If there is no goniometer, e.g. with a jet, depends_on + should be set to "." + (NXtransformations): + doc: | + This is the recommended location for sample goniometer + and other related axes. + + This is a requirement to describe for any scan experiment. + The reason it is optional is mainly to accommodate XFEL + single shot exposures. + + Use of the depends_on field and the NXtransformations group is + strongly recommended. As noted above this should be an absolute + requirement to have for any scan experiment. + + The reason it is optional is mainly to accommodate XFEL + single shot exposures. + temperature(NX_NUMBER): + unit: NX_TEMPERATURE + (NXinstrument): + name(NX_CHAR): + exists: required + doc: | + Name of instrument. Consistency with the controlled + vocabulary beamline naming in + https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html + and + https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html + is highly recommended. + \@short_name: + doc: "Short name for instrument, perhaps the acronym." + time_zone(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time_zone offset from UTC. + (NXattenuator): + attenuator_transmission(NX_NUMBER): + unit: NX_UNITLESS + (NXdetector_group): + exists: recommended + doc: | + Optional logical grouping of detectors. + + Each detector is represented as an NXdetector + with its own detector data array. Each detector data array + may be further decomposed into array sections by use of + NXdetector_module groups. Detectors can be grouped logically + together using NXdetector_group. Groups can be further grouped + hierarchically in a single NXdetector_group (for example, if + there are multiple detectors at an endstation or multiple + endstations at a facility). Alternatively, multiple + NXdetector_groups can be provided. + + The groups are defined hierarchically, with names given + in the group_names field, unique identifying indices given + in the field group_index, and the level in the hierarchy + given in the group_parent field. For example if an x-ray + detector group, DET, consists of four detectors in a + rectangular array:: + + DTL DTR + DLL DLR + + We could have:: + + group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] + group_index: [1, 2, 3, 4, 5] + group_parent: [-1, 1, 1, 1, 1] + group_names(NX_CHAR): + doc: | + An array of the names of the detectors or the names of + hierarchical groupings of detectors. + group_index(NX_INT): + doc: | + An array of unique identifiers for detectors or groupings + of detectors. + + Each ID is a unique ID for the corresponding detector or group + named in the field group_names. The IDs are positive integers + starting with 1. + dimensions: + rank: 1 + dim: [[1, i]] + group_parent(NX_INT): + doc: | + An array of the hierarchical levels of the parents of detectors + or groupings of detectors. + + A top-level grouping has parent level -1. + dimensions: + rank: 1 + dim: [[1, groupIndex]] + (NXdetector): + doc: | + Normally the detector group will have the name ``detector``. + However, in the case of multiple detectors, each detector + needs a uniquely named NXdetector. + depends_on(NX_CHAR): + doc: | + NeXus path to the detector positioner axis that most directly + supports the detector. In the case of a single-module + detector, the detector axis chain may start here. + (NXtransformations): + doc: | + Location for axes (transformations) to do with the + detector. In the case of a single-module detector, the + axes of the detector axis chain may be stored here. + (NXcollection): + doc: | + Suggested container for detailed non-standard detector + information like corrections applied automatically or + performance settings. + data(NX_NUMBER): + exists: recommended + doc: | + For a dimension-2 detector, the rank of the data array will be 3. + For a dimension-3 detector, the rank of the data array will be 4. + This allows for the introduction of the frame number as the + first index. + dimensions: + rank: dataRank + dim: [[1, nP], [2, i], [3, j], [4, k]] + description: + exists: recommended + doc: | + name/manufacturer/model/etc. information. + time_per_channel: + unit: NX_TIME + doc: | + For a time-of-flight detector this is the scaling + factor to convert from the numeric value reported to + the flight time for a given measurement. + (NXdetector_module): + exists: [min, 1, max, unbounded] + doc: | + Many detectors consist of multiple smaller modules that are + operated in sync and store their data in a common dataset. + To allow consistent parsing of the experimental geometry, + this application definiton requires all detectors to + define a detector module, even if there is only one. + + This group specifies the hyperslab of data in the data + array associated with the detector that contains the + data for this module. If the module is associated with + a full data array, rather than with a hyperslab within + a larger array, then a single module should be defined, + spanning the entire array. + + Note, the pixel size is given as values in the array + fast_pixel_direction and slow_pixel_direction. + data_origin(NX_INT): + doc: | + A dimension-2 or dimension-3 field which gives the indices + of the origin of the hyperslab of data for this module in the + main area detector image in the parent NXdetector module. + + The data_origin is 0-based. + + The frame number dimension (nP) is omitted. Thus the + data_origin field for a dimension-2 dataset with indices (nP, i, j) + will be an array with indices (i, j), and for a dimension-3 + dataset with indices (nP, i, j, k) will be an array with indices + (i, j, k). + + The :ref:`order ` of indices (i, j + or i, j, k) is slow to fast. + data_size(NX_INT): + doc: | + Two or three values for the size of the module in pixels in + each direction. Dimensionality and order of indices is the + same as for data_origin. + data_stride(NX_INT): + doc: | + Two or three values for the stride of the module in pixels in + each direction. By default the stride is [1,1] or [1,1,1], + and this is the most likely case. This optional field is + included for completeness. + module_offset(NX_NUMBER): + unit: NX_LENGTH + doc: | + Offset of the module in regards to the origin of the detector in an + arbitrary direction. + \@transformation_type: + enumeration: [translation] + \@vector: + \@offset: + \@depends_on: + fast_pixel_direction(NX_NUMBER): + unit: NX_LENGTH + doc: | + Values along the direction of :ref:`fastest varying ` + pixel direction. The direction itself is given through the vector + attribute. + \@transformation_type: + enumeration: [translation] + \@vector: + \@offset: + \@depends_on: + slow_pixel_direction(NX_NUMBER): + unit: NX_LENGTH + doc: | + Values along the direction of :ref:`slowest varying ` + pixel direction. The direction itself is given through the vector + attribute. + \@transformation_type: + enumeration: [translation] + \@vector: + \@offset: + \@depends_on: + distance(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + doc: | + Distance from the sample to the beam center. + Normally this value is for guidance only, the proper + geometry can be found following the depends_on axis chain, + But in appropriate cases where the dectector distance + to the sample is observable independent of the axis + chain, that may take precedence over the axis chain + calculation. + distance_derived(NX_BOOLEAN): + exists: recommended + doc: | + Boolean to indicate if the distance is a derived, rather than + a primary observation. If distance_derived true or is not specified, + the distance is assumed to be derived from detector axis + specifications. + dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Detector dead time. + count_time(NX_NUMBER): + exists: recommended + unit: NX_TIME + doc: | + Elapsed actual counting time. + beam_center_derived(NX_BOOLEAN): + doc: | + Boolean to indicate if the distance is a derived, rather than + a primary observation. If true or not provided, that value of + beam_center_derived is assumed to be true. + beam_center_x(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the + detector. This is a length and can be outside of the actual + detector. The length can be in physical units or pixels as + documented by the units attribute. Normally, this should + be derived from the axis chain, but the direct specification + may take precedence if it is not a derived quantity. + beam_center_y(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the + detector. This is a length and can be outside of the actual + detector. The length can be in physical units or pixels as + documented by the units attribute. Normally, this should + be derived from the axis chain, but the direct specification + may take precedence if it is not a derived quantity. + angular_calibration_applied(NX_BOOLEAN): + doc: | + True when the angular calibration has been applied in the + electronics, false otherwise. + angular_calibration(NX_FLOAT): + doc: "Angular calibration data." + dimensions: + rank: dataRank + dim: [[1, i], [2, j], [3, k]] + flatfield_applied(NX_BOOLEAN): + doc: | + True when the flat field correction has been applied in the + electronics, false otherwise. + flatfield(NX_NUMBER): + doc: | + Flat field correction data. If provided, it is recommended + that it be compressed. + dimensions: + rank: dataRank + dim: [[1, i], [2, j], [3, k]] + flatfield_error(NX_NUMBER): + exists: [min, 0, max, 0] + doc: | + *** Deprecated form. Use plural form *** + Errors of the flat field correction data. If provided, it is recommended + that it be compressed. + dimensions: + rank: dataRank + dim: [[1, i], [2, j], [3, k]] + flatfield_errors(NX_NUMBER): + doc: | + Errors of the flat field correction data. If provided, it is recommended + that it be compressed. + dimensions: + rank: dataRank + dim: [[1, i], [2, j], [3, k]] + pixel_mask_applied(NX_BOOLEAN): + doc: | + True when the pixel mask correction has been applied in the + electronics, false otherwise. + pixel_mask(NX_INT): + exists: recommended + doc: | + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices nP, i, j). + + Contains a bit field for each pixel to signal dead, + blind, high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under-responding + * bit 3: over-responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would not take pixels into account + when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper + two bytes would indicate special pixel properties that normally + would not be a sole reason to reject the intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + + If provided, it is recommended that it be compressed. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + countrate_correction_applied(NX_BOOLEAN): + doc: | + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + countrate_correction_lookup_table(NX_NUMBER): + doc: | + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + dimensions: + rank: 1 + dim: [[1, m]] + virtual_pixel_interpolation_applied(NX_BOOLEAN): + doc: | + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + bit_depth_readout(NX_INT): + exists: recommended + doc: | + How many bits the electronics record per pixel. + detector_readout_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + frame_time(NX_FLOAT): + unit: NX_TIME + doc: | + This is time for each frame. This is exposure_time + readout + time. + gain_setting(NX_CHAR): + doc: | + The gain setting of the detector. This influences + background. This is a detector-specific value meant + to document the gain setting of the detector during + data collection, for detectors with multiple + available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + saturation_value(NX_NUMBER): + doc: | + The value at which the detector goes into saturation. + Data above this value is known to be invalid. + + For example, given a saturation_value and an underload_value, + the valid pixels are those less than or equal to the + saturation_value and greater than or equal to the underload_value. + underload_value(NX_NUMBER): + doc: | + The lowest value at which pixels for this detector + would be reasonably be measured. + + For example, given a saturation_value and an underload_value, + the valid pixels are those less than or equal to the + saturation_value and greater than or equal to the underload_value. + sensor_material(NX_CHAR): + exists: required + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + sensor_thickness(NX_FLOAT): + exists: required + unit: NX_LENGTH + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. This is the thickness of this + converter material. + threshold_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Single photon counter detectors can be adjusted for a certain + energy range in which they work optimally. This is the energy + setting for this. If the detector supports multiple thresholds, + this is an array. + type: + doc: | + Description of type such as scintillator, + ccd, pixel, image + plate, CMOS, ... + (NXbeam): + exists: required + \@flux: + doc: | + Which field contains the measured flux. One of ``flux``, + ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. + + Alternatively, the name being indicated could be a link + to a dataset in an NXmonitor group that records per shot beam data. + incident_wavelength(NX_FLOAT): + exists: required + unit: NX_WAVELENGTH + doc: | + In the case of a monchromatic beam this is the scalar + wavelength. + + Several other use cases are permitted, depending on the + presence or absence of other incident_wavelength_X + fields. + + In the case of a polychromatic beam this is an array of + length **m** of wavelengths, with the relative weights + in ``incident_wavelength_weights``. + + In the case of a monochromatic beam that varies shot- + to-shot, this is an array of wavelengths, one for each + recorded shot. Here, ``incident_wavelength_weights`` and + incident_wavelength_spread are not set. + + In the case of a polychromatic beam that varies shot-to- + shot, this is an array of length **m** with the relative + weights in ``incident_wavelength_weights`` as a 2D array. + + In the case of a polychromatic beam that varies shot-to- + shot and where the channels also vary, this is a 2D array + of dimensions **nP** by **m** (slow to fast) with the + relative weights in ``incident_wavelength_weights`` as a 2D + array. + + Note, :ref:`variants ` are a good way + to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value wavelength value is + available along with the original spectrum from which it + was calibrated. + incident_wavelength_weight(NX_FLOAT): + doc: | + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in incident_wavelength. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **nP** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in incident_wavelength. + incident_wavelength_weights(NX_FLOAT): + doc: | + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in ``incident_wavelength``. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **np** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in ``incident_wavelength``. + incident_wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The wavelength spread FWHM for the corresponding + wavelength(s) in incident_wavelength. + + In the case of shot-to-shot variation in the wavelength + spread, this is a 2D array of dimension **nP** by + **m** (slow to fast) of the spreads of the + corresponding wavelengths in incident_wavelength. + incident_wavelength_spectrum(NXdata): + flux(NX_FLOAT): + unit: NX_FLUX + doc: | + Flux density incident on beam plane area in photons + per second per unit area. + + In the case of a beam that varies in flux shot-to-shot, + this is an array of values, one for each recorded shot. + total_flux(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Flux incident on beam plane in photons per second. In other words + this is the :ref:`flux ` integrated + over area. + + Useful where spatial beam profiles are not known. + + In the case of a beam that varies in total flux shot-to-shot, + this is an array of values, one for each recorded shot. + flux_integrated(NX_FLOAT): + unit: NX_PER_AREA + doc: | + Flux density incident on beam plane area in photons + per unit area. In other words this is the :ref:`flux ` + integrated over time. + + Useful where temporal beam profiles of flux are not known. + + In the case of a beam that varies in flux shot-to-shot, + this is an array of values, one for each recorded shot. + total_flux_integrated(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Flux incident on beam plane in photons. In other words this is the :ref:`flux ` + integrated over time and area. + + Useful where temporal beam profiles of flux are not known. + + In the case of a beam that varies in total flux shot-to-shot, + this is an array of values, one for each recorded shot. + incident_beam_size(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + doc: | + Two-element array of FWHM (if Gaussian or Airy function) or + diameters (if top hat) or widths (if rectangular) of the beam + in the order x, y + dimensions: + rank: 1 + dim: [[1, 2]] + profile(NX_CHAR): + exists: recommended + doc: | + The beam profile, Gaussian, Airy function, top-hat or + rectangular. The profile is given in the plane of + incidence of the beam on the sample. + enumeration: [Gaussian, Airy, top-hat, rectangular] + incident_polarisation_stokes(NX_NUMBER): + doc: | + Polarization vector on entering beamline + component using Stokes notation + dimensions: + rank: 2 + dim: [[1, nP], [2, 4]] + incident_polarization_stokes(NX_NUMBER): + exists: recommended + doc: | + Polarization vector on entering beamline + component using Stokes notation. See + incident_polarization_stokes in :ref:`NXbeam` + dimensions: + rank: 2 + dim: [[1, nP], [2, 4]] + (NXsource): + doc: | + The neutron or x-ray storage ring/facility. Note, the NXsource base class + has many more fields available, but at present we only require the name. + name: + exists: required + doc: | + Name of source. Consistency with the naming in + https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html + controlled vocabulary is highly recommended. + \@short_name: + doc: "short name for source, perhaps the acronym" diff --git a/applications/nyaml/NXrefscan.yml b/applications/nyaml/NXrefscan.yml new file mode 100644 index 0000000000..5014f7896c --- /dev/null +++ b/applications/nyaml/NXrefscan.yml @@ -0,0 +1,60 @@ +doc: | + This is an application definition for a monochromatic scanning reflectometer. + + It does not have the information to calculate the resolution + since it does not have any apertures. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" +category: application +NXrefscan: + entry(NXentry): + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXrefscan] + instrument(NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + monochromator(NXmonochromator): + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + (NXdetector): + data(NX_INT): + dimensions: + rank: 1 + dim: [[1, nP]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + sample(NXsample): + name: + doc: "Descriptive name of sample" + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + control(NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + data(NX_FLOAT): + unit: NX_ANY + doc: "Monitor counts for each step" + dimensions: + rank: 1 + dim: [[1, nP]] + data(NXdata): diff --git a/applications/nyaml/NXreftof.yml b/applications/nyaml/NXreftof.yml new file mode 100644 index 0000000000..b4211e1e0e --- /dev/null +++ b/applications/nyaml/NXreftof.yml @@ -0,0 +1,66 @@ +doc: | + This is an application definition for raw data from a TOF reflectometer. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + xSize: "xSize description" + ySize: "ySize description" + nTOF: "nTOF description" +category: application +NXreftof: + entry(NXentry): + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXreftof] + instrument(NXinstrument): + name(NX_CHAR): + chopper(NXdisk_chopper): + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "Distance between chopper and sample" + detector(NXdetector): + data(NX_INT): + dimensions: + rank: 3 + dim: [[1, xSize], [2, ySize], [3, nTOF]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: | + Array of time values for each bin in a time-of-flight + measurement + dimensions: + rank: 1 + dim: [[1, nTOF]] + distance(NX_FLOAT): + unit: NX_LENGTH + polar_angle(NX_FLOAT): + unit: NX_ANGLE + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + sample(NXsample): + name: + doc: "Descriptive name of sample" + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + control(NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + unit: NX_ANY + doc: "preset value for time or monitor" + integral(NX_INT): + doc: "Total integral monitor counts" + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: "Time channels" + data(NX_INT): + doc: "Monitor counts in each time channel" + data(NXdata): diff --git a/applications/nyaml/NXsas.yml b/applications/nyaml/NXsas.yml new file mode 100644 index 0000000000..1f0ea6e5a4 --- /dev/null +++ b/applications/nyaml/NXsas.yml @@ -0,0 +1,130 @@ +doc: | + Raw, monochromatic 2-D SAS data with an area detector. + + This is an application definition for raw data (not processed or reduced data) + from a 2-D small angle scattering instrument collected with a monochromatic + beam and an area detector. It is meant to be suitable both for neutron SANS + and X-ray SAXS data. + + It covers all raw data from any monochromatic SAS techniques that + use an area detector: SAS, WSAS, grazing incidence, GISAS + + It covers all raw data from any SAS techniques that use an area detector and + a monochromatic beam. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate fields with the same shape. + nXPixel: "Number of pixels in x direction." + nYPixel: "Number of pixels in y direction." +category: application +NXsas: + (NXentry): + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms." + enumeration: [NXsas] + (NXinstrument): + (NXsource): + type: + doc: "Type of radiation source." + name: + doc: "Name of the radiation source." + probe: + doc: | + Name of radiation probe, necessary to compute the sample contrast. + enumeration: [neutron, x-ray] + (NXmonochromator): + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The wavelength (:math:`\lambda`) of the radiation. + wavelength_spread(NX_FLOAT): + doc: | + delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): + Important for resolution calculations. + (NXcollimator): + (NXgeometry): + (NXshape): + shape(NX_CHAR): + enumeration: [nxcylinder, nxbox] + size(NX_FLOAT): + unit: NX_LENGTH + doc: "The collimation length." + (NXdetector): + data(NX_NUMBER): + doc: | + This is area detector data, number of x-pixel versus + number of y-pixels. + + Since the beam center is to be determined as a step of data + reduction, it is not necessary to document or assume the position of + the beam center in acquired data. + + It is necessary to define which are the x and y directions, to coordinate + with the pixel size and compute Q. + dimensions: + rank: 2 + dim: [[1, nXPixel], [2, nYPixel]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "The distance between detector and sample." + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: "Physical size of a pixel in x-direction." + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: "Physical size of a pixel in y-direction." + polar_angle(NX_FLOAT): + unit: NX_ANGLE + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + aequatorial_angle(NX_FLOAT): + unit: NX_ANGLE + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. + This is a length, not a pixel position, and can be outside of the + actual detector. + + It is expected that data reduction will determine beam center from + the raw data, thus it is not required here. The instrument can + provide an initial or nominal value to advise data reduction. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. + This is a length, not a pixel position, and can be outside of the + actual detector. + + It is expected that data reduction will determine beam center from + the raw data, thus it is not required here. The instrument can + provide an initial or nominal value to advise data reduction. + name(NX_CHAR): + doc: "Name of the instrument actually used to perform the experiment." + (NXsample): + name: + doc: "Descriptive name of sample." + aequatorial_angle(NX_FLOAT): + unit: NX_ANGLE + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time + (timer) or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "Preset value for time or monitor." + integral(NX_FLOAT): + unit: NX_ANY + doc: "Total integral monitor counts." + (NXdata): + \@signal: + doc: | + Name the *plottable* field. The link here defines this name as + ``data``. + enumeration: [data] diff --git a/applications/nyaml/NXsastof.yml b/applications/nyaml/NXsastof.yml new file mode 100644 index 0000000000..0d68e44e73 --- /dev/null +++ b/applications/nyaml/NXsastof.yml @@ -0,0 +1,104 @@ +doc: | + raw, 2-D SAS data with an area detector with a time-of-flight source + + It covers all raw data from any SAS techniques + that use an area detector + at a time-of-flight source. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nXPixel: "nXPixel description" + nYPixel: "nYPixel description" + nTOF: "nTOF description" +category: application +NXsastof: + (NXentry): + \@entry: + doc: "NeXus convention is to use 'entry1', 'entry2', ... for analysis software to locate each entry" + title: + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXsastof] + instrument(NXinstrument): + source(NXsource): + type: + doc: "type of radiation source" + name: + doc: "Name of the radiation source" + probe: + enumeration: [neutron, x-ray] + collimator(NXcollimator): + geometry(NXgeometry): + shape(NXshape): + shape(NX_CHAR): + enumeration: [nxcylinder, nxbox] + size(NX_FLOAT): + unit: NX_LENGTH + doc: "The collimation length" + detector(NXdetector): + data(NX_NUMBER): + doc: | + This is area detector data, of number of x-pixel versus + number of y-pixels. Since the beam center is to be + determined as a step of data reduction, it is not necessary + to document or assume the position of the beam center in + acquired data. + dimensions: + rank: 3 + dim: [[1, nXPixel], [2, nYPixel], [3, nTOF]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTOF]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "The distance between detector and sample" + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: "Physical size of a pixel in x-direction" + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: "Size of a pixel in y direction" + polar_angle(NX_FLOAT): + unit: NX_ANGLE + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + aequatorial_angle(NX_FLOAT): + unit: NX_ANGLE + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. This is a + length, not a pixel position, and can be outside of the actual detector. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. This is a + length, not a pixel position, and can be outside of the actual detector. + name(NX_CHAR): + doc: "Name of the instrument actually used to perform the experiment" + sample(NXsample): + name: + doc: "Descriptive name of sample" + aequatorial_angle(NX_FLOAT): + unit: NX_ANGLE + control(NXmonitor): + mode: + doc: "Count to a preset value based on either clock time (timer) or received monitor counts (monitor)." + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + data(NX_INT): + dimensions: + rank: 1 + dim: [[1, nTOF]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTOF]] + data(NXdata): diff --git a/applications/nyaml/NXscan.yml b/applications/nyaml/NXscan.yml new file mode 100644 index 0000000000..4d76ed58f4 --- /dev/null +++ b/applications/nyaml/NXscan.yml @@ -0,0 +1,57 @@ +doc: | + Application definition for a generic scan instrument. + + This definition is more an + example then a stringent definition as the content of a given NeXus scan file needs to + differ for different types of scans. This example definition shows a scan like done + on a rotation camera: the sample is rotated and a detector image, the rotation angle + and a monitor value is stored at each step in the scan. In the following, the symbol + ``NP`` is used to represent the number of scan points. These are the rules for + storing scan data in NeXus files which are implemented in this example: + + * Each value varied throughout a scan is stored as an array of + length ``NP`` at its respective location within the NeXus hierarchy. + * For area detectors, ``NP`` is the first dimension, + example for a detector of 256x256: ``data[NP,256,256]`` + * The NXdata group contains links to all variables varied in the scan and the data. + This to give an equivalent to the more familiar classical tabular representation of scans. + + These rules exist for a reason: HDF allows the first dimension of a data set to be + unlimited. This means the data can be appended too. Thus a NeXus file built according + to the rules given above can be used in the following way: + + * At the start of a scan, write all the static information. + * At each scan point, append new data from varied variables + and the detector to the file. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" + xDim: "xDim description" + yDim: "yDim description" +category: application +NXscan: + (NXentry): + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition(NX_CHAR): + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXscan] + (NXinstrument): + (NXdetector): + data(NX_INT): + dimensions: + rank: 3 + dim: [[1, nP], [2, xDim], [3, yDim]] + (NXsample): + rotation_angle(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nP]] + (NXmonitor): + data(NX_INT): + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata): diff --git a/applications/nyaml/NXspe.yml b/applications/nyaml/NXspe.yml new file mode 100644 index 0000000000..6def063470 --- /dev/null +++ b/applications/nyaml/NXspe.yml @@ -0,0 +1,45 @@ +doc: | + NXSPE Inelastic Format. Application definition for NXSPE file format. +category: application +NXspe: + (NXentry): + program_name: + definition: + doc: "Official NeXus NXDL schema to which this file conforms." + \@version: + enumeration: [NXspe] + NXSPE_info(NXcollection): + fixed_energy(NX_FLOAT): + unit: NX_ENERGY + doc: "The fixed energy used for this file." + ki_over_kf_scaling(NX_BOOLEAN): + doc: "Indicates whether ki/kf scaling has been applied or not." + psi(NX_FLOAT): + unit: NX_ANGLE + doc: "Orientation angle as expected in DCS-MSlice" + data(NXdata): + azimuthal(NX_FLOAT): + unit: NX_ANGLE + azimuthal_width(NX_FLOAT): + unit: NX_ANGLE + polar(NX_FLOAT): + unit: NX_ANGLE + polar_width(NX_FLOAT): + unit: NX_ANGLE + distance(NX_FLOAT): + unit: NX_LENGTH + data(NX_NUMBER): + error(NX_NUMBER): + energy(NX_FLOAT): + unit: NX_ENERGY + (NXinstrument): + name(NX_CHAR): + (NXfermi_chopper): + energy(NX_NUMBER): + unit: NX_ENERGY + (NXsample): + rotation_angle(NX_NUMBER): + unit: NX_ANGLE + seblock(NX_CHAR): + temperature(NX_NUMBER): + unit: NX_TEMPERATURE diff --git a/applications/nyaml/NXsqom.yml b/applications/nyaml/NXsqom.yml new file mode 100644 index 0000000000..84e71a4d97 --- /dev/null +++ b/applications/nyaml/NXsqom.yml @@ -0,0 +1,69 @@ +doc: | + This is the application definition for S(Q,OM) processed data. + + As this kind of data is in + general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their + intensity, table like. It is the task of a possible visualisation program to regrid this data in + a sensible way. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" +category: application +NXsqom: + (NXentry): + \@entry: + title: + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXsqom] + instrument(NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + name(NX_CHAR): + doc: "Name of the instrument from which this data was reduced." + (NXsample): + name: + doc: "Descriptive name of sample" + reduction(NXprocess): + program(NX_CHAR): + version(NX_CHAR): + input(NXparameters): + filenames(NX_CHAR): + doc: "Raw data files used to generate this I(Q)" + doc: "Input parameters for the reduction program used" + output(NXparameters): + doc: "Eventual output parameters from the data reduction program used" + (NXdata): + data(NX_INT): + doc: "This is the intensity for each point in QE" + dimensions: + rank: 1 + dim: [[1, nP]] + qx(NX_NUMBER): + unit: NX_WAVENUMBER + doc: "Positions for the first dimension of Q" + dimensions: + rank: 1 + dim: [[1, nP]] + qy(NX_NUMBER): + unit: NX_WAVENUMBER + doc: "Positions for the the second dimension of Q" + dimensions: + rank: 1 + dim: [[1, nP]] + qz(NX_NUMBER): + unit: NX_WAVENUMBER + doc: "Positions for the the third dimension of Q" + dimensions: + rank: 1 + dim: [[1, nP]] + en(NX_FLOAT): + unit: NX_ENERGY + doc: "Values for the energy transfer for each point" + dimensions: + rank: 1 + dim: [[1, nP]] diff --git a/applications/nyaml/NXstxm.yml b/applications/nyaml/NXstxm.yml new file mode 100644 index 0000000000..1bc47a79d2 --- /dev/null +++ b/applications/nyaml/NXstxm.yml @@ -0,0 +1,149 @@ +doc: | + Application definition for a STXM instrument. + + The interferometer + position measurements, monochromator photon energy values and + detector measurements are all treated as NXdetectors and stored + within the NXinstrument group as lists of values stored in + chronological order. The NXdata group then holds another version + of the data in a regular 3D array (NumE by NumY by NumX, for a + total of nP points in a sample image stack type scan). The former + data values should be stored with a minimum loss of precision, while + the latter values can be simplified and/or approximated in order to + fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' + are just sample_image scan types with reduced dimensions in the same way + as single images have reduced E dimensions compared to image 'stacks'. +symbols: + doc: | + These symbols will be used below to coordinate the shapes of the datasets. + nP: "Total number of scan points" + nE: "Number of photon energies scanned" + nX: "Number of pixels in X direction" + nY: "Number of pixels in Y direction" + detectorRank: "Rank of data array provided by the detector for a single measurement" +category: application +NXstxm: + (NXentry): + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition(NX_CHAR): + exists: [min, 1, max, 1] + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXstxm] + (NXinstrument): + exists: [min, 1, max, 1] + (NXsource): + exists: [min, 1, max, 1] + type: + exists: [min, 1, max, 1] + name: + exists: [min, 1, max, 1] + probe: + exists: [min, 1, max, 1] + monochromator(NXmonochromator): + exists: [min, 1, max, 1] + energy(NX_FLOAT): + exists: [min, 1, max, 1] + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdetector): + exists: required + data(NX_NUMBER): + dimensions: + rank: 1+detectorRank + dim: [[1, nP]] + doc: | + Detector data should be presented with the first dimension corresponding to the + scan point and subsequent dimensions corresponding to the output of the detector. + Detectors that provide more than one value per scan point should have + a data array of rank 1+d, where d is the dimensions of the array provided per + scan point. For example, an area detector should have an NXdetector data array + of 3 dimensions, with the first being the set of scan points and the latter + two being the x- and y- extent of the detector. + NOTE: For each dimension > 1 there must exist a dim section such as: + sample_x(NXdetector): + exists: [min, 0, max, 1] + doc: "Measurements of the sample position from the x-axis interferometer." + data(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nP]] + sample_y(NXdetector): + exists: [min, 0, max, 1] + doc: "Measurements of the sample position from the y-axis interferometer." + data(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nP]] + sample_z(NXdetector): + exists: [min, 0, max, 1] + doc: "Measurements of the sample position from the z-axis interferometer." + data(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample): + rotation_angle(NX_FLOAT): + (NXdata): + stxm_scan_type: + exists: [min, 1, max, 1] + doc: | + Label for typical scan types as a convenience for humans. + Each label corresponds to a specific set of axes being scanned + to produce a data array of shape: + + * sample point spectrum: (photon_energy,) + * sample line spectrum: (photon_energy, sample_y/sample_x) + * sample image: (sample_y, sample_x) + * sample image stack: (photon_energy, sample_y, sample_x) + * sample focus: (zoneplate_z, sample_y/sample_x) + * osa image: (osa_y, osa_x) + * osa focus: (zoneplate_z, osa_y/osa_x) + * detector image: (detector_y, detector_x) + + The "generic scan" string is to be used when none of the + other choices are appropriate. + enumeration: [sample point spectrum, sample line spectrum, sample image, sample image stack, sample focus, osa image, osa focus, detector image, generic scan] + data(NX_NUMBER): + doc: | + Detectors that provide more than one value per scan point should be summarised + to a single value per scan point for this array in order to simplify plotting. + + Note that 'Line scans' and focus type scans measure along one spatial dimension + but are not restricted to being parallel to the X or Y axes. Such scans + should therefore use a single dimension for the positions along the spatial + line. The 'sample_x' and 'sample_y' fields should then contain lists of the + x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. + energy(NX_FLOAT): + exists: [min, 1, max, 1] + doc: | + List of photon energies of the X-ray beam. If scanned through multiple values, + then an 'axis' attribute will be required to link the field to the appropriate data array dimension. + dimensions: + rank: 1 + dim: [[1, nE]] + sample_y(NX_FLOAT): + exists: [min, 1, max, 1] + doc: | + List of Y positions on the sample. If scanned through multiple values, + then an 'axis' attribute will be required to link the field to the appropriate data array dimension. + dimensions: + rank: 1 + dim: [[1, nY]] + sample_x(NX_FLOAT): + exists: [min, 1, max, 1] + doc: | + List of X positions on the sample. If scanned through multiple values, + then an 'axis' attribute will be required to link the field to the appropriate data array dimension. + dimensions: + rank: 1 + dim: [[1, nX]] + control(NXmonitor): + exists: [min, 0, max, 1] + data(NX_FLOAT): + doc: | + Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring + electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the + NXdata groups. diff --git a/applications/nyaml/NXtas.yml b/applications/nyaml/NXtas.yml new file mode 100644 index 0000000000..c2f464cdad --- /dev/null +++ b/applications/nyaml/NXtas.yml @@ -0,0 +1,128 @@ +doc: | + This is an application definition for a triple axis spectrometer. + + It is for the trademark scan of the TAS, the Q-E scan. + For your alignment scans use the rules in :ref:`NXscan`. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" +category: application +NXtas: + entry(NXentry): + title(NX_CHAR): + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXtas] + (NXinstrument): + (NXsource): + name: + probe: + enumeration: [neutron, x-ray] + monochromator(NXcrystal): + ei(NX_FLOAT): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, nP]] + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + analyser(NXcrystal): + ef(NX_FLOAT): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, nP]] + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdetector): + data(NX_INT): + dimensions: + rank: 1 + dim: [[1, nP]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample): + name: + doc: "Descriptive name of sample" + qh(NX_FLOAT): + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, nP]] + qk(NX_FLOAT): + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, nP]] + ql(NX_FLOAT): + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, nP]] + en(NX_FLOAT): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, nP]] + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + sgu(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + sgl(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + unit_cell(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 6]] + orientation_matrix(NX_FLOAT): + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, 9]] + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + data(NX_FLOAT): + unit: NX_ANY + doc: "Total integral monitor counts" + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata): + doc: "One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis" diff --git a/applications/nyaml/NXtofnpd.yml b/applications/nyaml/NXtofnpd.yml new file mode 100644 index 0000000000..1e7b30f015 --- /dev/null +++ b/applications/nyaml/NXtofnpd.yml @@ -0,0 +1,80 @@ +doc: | + This is a application definition for raw data from a TOF neutron powder diffractometer +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nDet: "Number of detectors" + nTimeChan: "nTimeChan description" +category: application +NXtofnpd: + entry(NXentry): + title: + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXtofnpd] + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flight path before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + user(NXuser): + name(NX_CHAR): + (NXinstrument): + detector(NXdetector): + data(NX_INT): + dimensions: + rank: 2 + dim: [[1, nDet], [2, nTimeChan]] + detector_number(NX_INT): + dimensions: + rank: 1 + dim: [[1, nDet]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "distance to sample for each detector" + dimensions: + rank: 1 + dim: [[1, nDet]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "polar angle for each detector element" + dimensions: + rank: 1 + dim: [[1, nDet]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "azimuthal angle for each detector element" + dimensions: + rank: 1 + dim: [[1, nDet]] + (NXsample): + name: + doc: "Descriptive name of sample" + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + distance(NX_FLOAT): + unit: NX_LENGTH + data(NX_INT): + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + data(NXdata): diff --git a/applications/nyaml/NXtofraw.yml b/applications/nyaml/NXtofraw.yml new file mode 100644 index 0000000000..2ca9095cbb --- /dev/null +++ b/applications/nyaml/NXtofraw.yml @@ -0,0 +1,86 @@ +doc: | + This is an application definition for raw data from a generic TOF instrument +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nDet: "Number of detectors" + nTimeChan: "nTimeChan description" +category: application +NXtofraw: + entry(NXentry): + title: + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXtofraw] + duration(NX_FLOAT): + run_number(NX_INT): + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flight path before the sample position. This can be determined by a chopper, + by the moderator, or the source itself. In other words: it is the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + user(NXuser): + name(NX_CHAR): + instrument(NXinstrument): + detector(NXdetector): + data(NX_INT): + dimensions: + rank: 2 + dim: [[1, nDet], [2, nTimeChan]] + detector_number(NX_INT): + dimensions: + rank: 1 + dim: [[1, nDet]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "distance to sample for each detector" + dimensions: + rank: 1 + dim: [[1, nDet]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "polar angle for each detector element" + dimensions: + rank: 1 + dim: [[1, nDet]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "azimuthal angle for each detector element" + dimensions: + rank: 1 + dim: [[1, nDet]] + (NXsample): + name: + doc: "Descriptive name of sample" + nature(NX_CHAR): + enumeration: [powder, liquid, single crystal] + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + distance(NX_FLOAT): + unit: NX_LENGTH + data(NX_INT): + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + integral_counts(NX_INT): + unit: NX_UNITLESS + data(NXdata): diff --git a/applications/nyaml/NXtofsingle.yml b/applications/nyaml/NXtofsingle.yml new file mode 100644 index 0000000000..51d16dd2eb --- /dev/null +++ b/applications/nyaml/NXtofsingle.yml @@ -0,0 +1,81 @@ +doc: | + This is a application definition for raw data from a generic TOF instrument +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + xSize: "xSize description" + ySize: "ySize description" + nDet: "Number of detectors" + nTimeChan: "nTimeChan description" +category: application +NXtofsingle: + entry(NXentry): + title: + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXtofsingle] + duration(NX_FLOAT): + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flight path before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + user(NXuser): + name(NX_CHAR): + (NXinstrument): + detector(NXdetector): + data(NX_INT): + dimensions: + rank: 3 + dim: [[1, xSize], [2, ySize], [3, nTimeChan]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "Distance to sample for the center of the detector" + dimensions: + rank: 1 + dim: [[1, 1]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "polar angle for each detector element" + dimensions: + rank: 1 + dim: [[1, nDet]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "azimuthal angle for each detector element" + dimensions: + rank: 1 + dim: [[1, nDet]] + (NXsample): + name: + doc: "Descriptive name of sample" + nature(NX_CHAR): + enumeration: [powder, liquid, single crystal] + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + distance(NX_FLOAT): + unit: NX_LENGTH + data(NX_INT): + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + data(NXdata): diff --git a/applications/nyaml/NXtomo.yml b/applications/nyaml/NXtomo.yml new file mode 100644 index 0000000000..7280be28c0 --- /dev/null +++ b/applications/nyaml/NXtomo.yml @@ -0,0 +1,108 @@ +doc: | + This is the application definition for x-ray or neutron tomography raw data. + + In tomography + a number of dark field images are measured, some bright field images and, of course the sample. + In order to distinguish between them images carry a image_key. +symbols: + doc: | + These symbols will be used below to coordinate datasets with the same shape. + nFrames: "Number of frames" + xSize: "Number of pixels in X direction" + ySize: "Number of pixels in Y direction" +category: application +NXtomo: + entry(NXentry): + title: + exists: [min, 0, max, 1] + start_time(NX_DATE_TIME): + exists: [min, 0, max, 1] + end_time(NX_DATE_TIME): + exists: [min, 0, max, 1] + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXtomo] + instrument(NXinstrument): + (NXsource): + exists: [min, 0, max, 1] + type: + exists: [min, 0, max, 1] + name: + exists: [min, 0, max, 1] + probe: + exists: [min, 0, max, 1] + enumeration: [neutron, x-ray, electron] + detector(NXdetector): + data(NX_INT): + dimensions: + rank: 3 + dim: [[1, nFrames], [2, xSize], [3, ySize]] + image_key(NX_INT): + doc: | + In order + to distinguish between sample projections, dark and flat + images, a magic number is recorded per frame. + The key is as follows: + + * projection = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + dimensions: + rank: 1 + dim: [[1, nFrames]] + x_pixel_size(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + y_pixel_size(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + distance(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + doc: "Distance between detector and sample" + x_rotation_axis_pixel_position(NX_FLOAT): + exists: [min, 0, max, 1] + y_rotation_axis_pixel_position(NX_FLOAT): + exists: [min, 0, max, 1] + sample(NXsample): + name: + doc: "Descriptive name of sample" + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + In practice this axis is always aligned along one pixel direction on the detector and usually vertical. + There are experiments with horizontal rotation axes, so this would need to be indicated somehow. + For now the best way for that is an open question. + dimensions: + rank: 1 + dim: [[1, nFrames]] + x_translation(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, nFrames]] + y_translation(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, nFrames]] + z_translation(NX_FLOAT): + exists: [min, 0, max, 1] + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, nFrames]] + control(NXmonitor): + exists: [min, 0, max, 1] + data(NX_FLOAT): + unit: NX_ANY + doc: | + Total integral monitor counts for each measured frame. Allows a to correction for + fluctuations in the beam between frames. + dimensions: + rank: 1 + dim: [[1, nFrames]] + data(NXdata): diff --git a/applications/nyaml/NXtomophase.yml b/applications/nyaml/NXtomophase.yml new file mode 100644 index 0000000000..2a3937f029 --- /dev/null +++ b/applications/nyaml/NXtomophase.yml @@ -0,0 +1,96 @@ +doc: | + This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. + + In tomography first + some dark field images are measured, some bright field images and, of course the sample. In order + to properly sort the order of the images taken, a sequence number is stored with each image. +symbols: + doc: | + nBrightFrames: "Number of bright frames" + nDarkFrames: "Number of dark frames" + nSampleFrames: "Number of image (sample) frames" + nPhase: "Number of phase settings" + xSize: "Number of pixels in X direction" + ySize: "Number of pixels in Y direction" +category: application +NXtomophase: + entry(NXentry): + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXtomophase] + instrument(NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + bright_field(NXdetector): + data(NX_INT): + dimensions: + rank: 3 + dim: [[1, nBrightFrames], [2, xSize], [3, ySize]] + sequence_number(NX_INT): + dimensions: + rank: 1 + dim: [[1, nBrightFrames]] + dark_field(NXdetector): + data(NX_INT): + dimensions: + rank: 3 + dim: [[1, nDarkFrames], [2, xSize], [3, ySize]] + sequence_number(NX_INT): + dimensions: + rank: 1 + dim: [[1, nDarkFrames]] + sample(NXdetector): + data(NX_INT): + dimensions: + rank: 4 + dim: [[1, nSampleFrames], [2, nPhase], [3, xSize], [4, ySize]] + sequence_number(NX_INT): + dimensions: + rank: 2 + dim: [[1, nSampleFrames], [2, nPhase]] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "Distance between detector and sample" + sample(NXsample): + name: + doc: "Descriptive name of sample" + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nSampleFrames]] + x_translation(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, nSampleFrames]] + y_translation(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, nSampleFrames]] + z_translation(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, nSampleFrames]] + control(NXmonitor): + integral(NX_FLOAT): + unit: NX_ANY + doc: | + Total integral monitor counts for each measured frame. Allows a correction for + fluctuations in the beam between frames. + dimensions: + rank: 1 + dim: [[1, nDarkFrames + nBrightFrames + nSampleFrame]] + data(NXdata): diff --git a/applications/nyaml/NXtomoproc.yml b/applications/nyaml/NXtomoproc.yml new file mode 100644 index 0000000000..7c05cf825d --- /dev/null +++ b/applications/nyaml/NXtomoproc.yml @@ -0,0 +1,69 @@ +doc: | + This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. +symbols: + doc: | + nX: "Number of voxels in X direction" + nY: "Number of voxels in Y direction" + nZ: "Number of voxels in Z direction" +category: application +NXtomoproc: + entry(NXentry): + title: + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXtomoproc] + (NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + (NXsample): + name: + doc: "Descriptive name of sample" + reconstruction(NXprocess): + program(NX_CHAR): + doc: "Name of the program used for reconstruction" + version(NX_CHAR): + doc: "Version of the program used" + date(NX_DATE_TIME): + doc: "Date and time of reconstruction processing." + parameters(NXparameters): + raw_file(NX_CHAR): + doc: "Original raw data file this data was derived from" + data(NXdata): + data(NX_INT): + doc: | + This is the reconstructed volume. This can be different + things. Please indicate in the unit attribute what physical + quantity this really is. + dimensions: + rank: 3 + dim: [[1, nX], [2, nX], [3, nZ]] + \@transform: + \@offset: + \@scaling: + x(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nX]] + y(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nY]] + z(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nZ]] diff --git a/applications/nyaml/NXxas.yml b/applications/nyaml/NXxas.yml new file mode 100644 index 0000000000..c68e8140ec --- /dev/null +++ b/applications/nyaml/NXxas.yml @@ -0,0 +1,63 @@ +doc: | + This is an application definition for raw data from an X-ray absorption spectroscopy experiment. + + This is essentially a scan on energy versus incoming/ + absorbed beam. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" +category: application +NXxas: + (NXentry): + \@entry: + doc: | + NeXus convention is to use "entry1", "entry2", ... + for analysis software to locate each entry. + title: + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXxas] + (NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [x-ray] + monochromator(NXmonochromator): + energy(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nP]] + incoming_beam(NXdetector): + data(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, nP]] + absorbed_beam(NXdetector): + data(NX_NUMBER): + doc: "This data corresponds to the sample signal." + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample): + name: + doc: "Descriptive name of sample" + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + data(NX_NUMBER): + doc: "This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data``" + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata): + mode: + doc: "Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly)" + enumeration: [Total Electron Yield, Partial Electron Yield, Auger Electron Yield, Fluorescence Yield, Transmission] diff --git a/applications/nyaml/NXxasproc.yml b/applications/nyaml/NXxasproc.yml new file mode 100644 index 0000000000..5c450dd7a3 --- /dev/null +++ b/applications/nyaml/NXxasproc.yml @@ -0,0 +1,42 @@ +doc: | + Processed data from XAS. This is energy versus I(incoming)/I(absorbed). +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" +category: application +NXxasproc: + (NXentry): + \@entry: + doc: | + NeXus convention is to use "entry1", "entry2", ... + for analysis software to locate each entry. + title: + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXxasproc] + (NXsample): + name: + doc: "Descriptive name of sample" + XAS_data_reduction(NXprocess): + program(NX_CHAR): + doc: "Name of the program used for reconstruction" + version(NX_CHAR): + doc: "Version of the program used" + date(NX_DATE_TIME): + doc: "Date and time of reconstruction processing." + parameters(NXparameters): + raw_file(NX_CHAR): + doc: "Original raw data file this data was derived from" + (NXdata): + energy: + dimensions: + rank: 1 + dim: [[1, nP]] + data(NX_FLOAT): + doc: | + This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. + Expect attribute ``signal=1`` + dimensions: + rank: 1 + dim: [[1, nP]] diff --git a/applications/nyaml/NXxbase.yml b/applications/nyaml/NXxbase.yml new file mode 100644 index 0000000000..a763c1fa10 --- /dev/null +++ b/applications/nyaml/NXxbase.yml @@ -0,0 +1,107 @@ +doc: | + This definition covers the common parts of all monochromatic single crystal raw data application definitions. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" + nXPixels: "Number of X pixels" + nYPixels: "Number of Y pixels" +category: application +NXxbase: + entry(NXentry): + title: + start_time(NX_DATE_TIME): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXxbase] + instrument(NXinstrument): + source(NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + monochromator(NXmonochromator): + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + detector(NXdetector): + data(NX_INT): + doc: | + The area detector data, the first dimension is always the + number of scan points, the second and third are the number + of pixels in x and y. The origin is always assumed to be + in the center of the detector. maxOccurs is limited to the + the number of detectors on your instrument. + dimensions: + rank: 3 + dim: [[1, nP], [2, nXPixels], [3, nYPixels]] + \@signal: + enumeration: [1] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + The name of the group is detector if there is only one detector, + if there are several, names have to be detector1, + detector2, ...detectorn. + distance(NX_FLOAT): + unit: NX_LENGTH + frame_start_number(NX_INT): + doc: | + This is the start number of the first frame of a scan. In PX one often scans a couple + of frames on a give sample, then does something else, then returns to the same sample + and scans some more frames. Each time with a new data file. + This number helps concatenating such measurements. + sample(NXsample): + name(NX_CHAR): + doc: "Descriptive name of sample" + orientation_matrix(NX_FLOAT): + doc: | + The orientation matrix according to Busing and + Levy conventions. This is not strictly necessary as + the UB can always be derived from the data. But + let us bow to common usage which includes the + UB nearly always. + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + unit_cell(NX_FLOAT): + doc: | + The unit cell, a, b, c, alpha, beta, gamma. + Again, not strictly necessary, but normally written. + dimensions: + rank: 1 + dim: [[1, 6]] + temperature(NX_FLOAT): + doc: | + The sample temperature or whatever sensor represents this value best + dimensions: + rank: 1 + dim: [[1, nP]] + x_translation(NX_FLOAT): + unit: NX_LENGTH + doc: "Translation of the sample along the X-direction of the laboratory coordinate system" + y_translation(NX_FLOAT): + unit: NX_LENGTH + doc: "Translation of the sample along the Y-direction of the laboratory coordinate system" + distance(NX_FLOAT): + unit: NX_LENGTH + doc: "Translation of the sample along the Z-direction of the laboratory coordinate system" + control(NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: "preset value for time or monitor" + integral(NX_FLOAT): + unit: NX_ANY + doc: "Total integral monitor counts" + (NXdata): + doc: | + The name of this group id data if there is only + one detector; if there are several the names will + be data1, data2, data3 and will point + to the corresponding detector groups in the + instrument hierarchy. diff --git a/applications/nyaml/NXxeuler.yml b/applications/nyaml/NXxeuler.yml new file mode 100644 index 0000000000..b16eacd72c --- /dev/null +++ b/applications/nyaml/NXxeuler.yml @@ -0,0 +1,52 @@ +doc: | + raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` + + It extends :ref:`NXxbase`, so the full definition is the content + of :ref:`NXxbase` plus the data defined here. All four angles are + logged in order to support arbitrary scans in reciprocal space. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" +category: application +NXxeuler(NXxbase): + entry(NXentry): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXxeuler] + instrument(NXinstrument): + detector(NXdetector): + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + The polar_angle (two theta) where the detector is placed + at each scan point. + dimensions: + rank: 1 + dim: [[1, nP]] + sample(NXsample): + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is an array holding the sample rotation angle at each + scan point + dimensions: + rank: 1 + dim: [[1, nP]] + chi(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is an array holding the chi angle of the eulerian + cradle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + phi(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is an array holding the phi rotation of the eulerian + cradle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + name(NXdata): diff --git a/applications/nyaml/NXxkappa.yml b/applications/nyaml/NXxkappa.yml new file mode 100644 index 0000000000..670963c95a --- /dev/null +++ b/applications/nyaml/NXxkappa.yml @@ -0,0 +1,53 @@ +doc: | + raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` + + This is the application definition for raw data from a kappa geometry + (CAD4) single crystal + diffractometer. It extends :ref:`NXxbase`, so the full definition is + the content of :ref:`NXxbase` plus the + data defined here. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" +category: application +NXxkappa(NXxbase): + entry(NXentry): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXxkappa] + instrument(NXinstrument): + detector(NXdetector): + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "The polar_angle (two theta) at each scan point" + dimensions: + rank: 1 + dim: [[1, nP]] + sample(NXsample): + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is an array holding the sample rotation angle at each + scan point + dimensions: + rank: 1 + dim: [[1, nP]] + kappa(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is an array holding the kappa angle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + phi(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is an array holding the phi angle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + alpha(NX_FLOAT): + unit: NX_ANGLE + doc: "This holds the inclination angle of the kappa arm." + name(NXdata): diff --git a/applications/nyaml/NXxlaue.yml b/applications/nyaml/NXxlaue.yml new file mode 100644 index 0000000000..269b8f3f18 --- /dev/null +++ b/applications/nyaml/NXxlaue.yml @@ -0,0 +1,30 @@ +doc: | + raw data from a single crystal laue camera, extends :ref:`NXxrot` + + This is the application definition for raw data from a single crystal laue + camera. It extends :ref:`NXxrot`. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nE: "Number of energies" +category: application +NXxlaue(NXxrot): + entry(NXentry): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXxlaue] + instrument(NXinstrument): + source(NXsource): + distribution(NXdata): + data: + doc: "expect ``signal=1 axes='energy'``" + dimensions: + rank: 1 + dim: [[1, nE]] + wavelength: + unit: NX_WAVELENGTH + dimensions: + rank: 1 + dim: [[1, nE]] + doc: | + This is the wavelength distribution of the beam diff --git a/applications/nyaml/NXxlaueplate.yml b/applications/nyaml/NXxlaueplate.yml new file mode 100644 index 0000000000..b10564c724 --- /dev/null +++ b/applications/nyaml/NXxlaueplate.yml @@ -0,0 +1,16 @@ +doc: | + raw data from a single crystal Laue camera, extends :ref:`NXxlaue` + + This is the application definition for raw data from a single crystal Laue + camera with an image plate as a detector. It extends :ref:`NXxlaue`. +category: application +NXxlaueplate(NXxlaue): + entry(NXentry): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXxlaueplate] + instrument(NXinstrument): + detector(NXdetector): + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: "The diameter of a cylindrical detector" diff --git a/applications/nyaml/NXxnb.yml b/applications/nyaml/NXxnb.yml new file mode 100644 index 0000000000..5589d59901 --- /dev/null +++ b/applications/nyaml/NXxnb.yml @@ -0,0 +1,47 @@ +doc: | + raw data from a single crystal diffractometer, extends :ref:`NXxbase` + + This is the application definition for raw data from + a single crystal diffractometer + measuring in normal beam mode. It extends :ref:`NXxbase`, + so the full definition is the content of + :ref:`NXxbase` plus the data defined here. All angles are + logged in order to support arbitrary scans in + reciprocal space. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" +category: application +NXxnb(NXxbase): + entry(NXentry): + definition: + doc: "Official NeXus NXDL schema to which this file conforms" + enumeration: [NXxnb] + instrument(NXinstrument): + detector(NXdetector): + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + The polar_angle (gamma) of the detector for each scan point. + dimensions: + rank: 1 + dim: [[1, nP]] + tilt_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + The angle by which the detector has been tilted out of the + scattering plane. + dimensions: + rank: 1 + dim: [[1, nP]] + sample(NXsample): + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is an array holding the sample rotation angle at each + scan point + dimensions: + rank: 1 + dim: [[1, nP]] + name(NXdata): diff --git a/applications/nyaml/NXxrot.yml b/applications/nyaml/NXxrot.yml new file mode 100644 index 0000000000..3bc1672c6a --- /dev/null +++ b/applications/nyaml/NXxrot.yml @@ -0,0 +1,48 @@ +doc: | + raw data from a rotation camera, extends :ref:`NXxbase` + + This is the application definition for raw data from a rotation camera. + It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` + plus the data defined here. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: "Number of points" +category: application +NXxrot(NXxbase): + entry(NXentry): + definition: + doc: "Official NeXus NXDL schema to which this file conforms." + enumeration: [NXxrot] + instrument(NXinstrument): + detector(NXdetector): + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "The polar_angle (two theta) where the detector is placed." + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. This is a + length, not a pixel position, and can be outside of the actual detector. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. This is a + length, not a pixel position, and can be outside of the actual detector. + attenuator(NXattenuator): + attenuator_transmission(NX_FLOAT): + unit: NX_ANY + sample(NXsample): + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: "This is an array holding the sample rotation start angle at each scan point" + dimensions: + rank: 1 + dim: [[1, nP]] + rotation_angle_step(NX_FLOAT): + unit: NX_ANGLE + doc: "This is an array holding the step made for sample rotation angle at each scan point" + dimensions: + rank: 1 + dim: [[1, nP]] + name(NXdata): From 8440f2827b95b9dc2f64c60ca0f4056689a1eff5 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 13 Feb 2023 17:34:30 +0100 Subject: [PATCH 097/203] Fixed nyaml errors for NXapm_* yamls and added fixes needed for differing file path supports on a request from NFDI-MatWerk IUC09 --- .../nyaml/NXapm_input_ranging.yaml | 32 +- .../nyaml/NXapm_input_reconstruction.yaml | 17 +- .../NXapm_paraprobe_config_distancer.yaml | 9 + .../NXapm_paraprobe_config_intersector.yaml | 9 + .../NXapm_paraprobe_config_nanochem.yaml | 9 + .../nyaml/NXapm_paraprobe_config_ranger.yaml | 9 + .../NXapm_paraprobe_config_spatstat.yaml | 9 + .../NXapm_paraprobe_config_surfacer.yaml | 9 + .../NXapm_paraprobe_config_tessellator.yaml | 9 + .../NXapm_paraprobe_config_transcoder.yaml | 52 +-- .../NXapm_paraprobe_results_clusterer.yaml | 8 + .../NXapm_paraprobe_results_distancer.yaml | 8 + .../NXapm_paraprobe_results_intersector.yaml | 9 +- .../NXapm_paraprobe_results_nanochem.yaml | 30 +- .../nyaml/NXapm_paraprobe_results_ranger.yaml | 15 +- .../NXapm_paraprobe_results_selector.yaml | 1 + .../NXapm_paraprobe_results_spatstat.yaml | 8 + .../NXapm_paraprobe_results_surfacer.yaml | 8 + .../NXapm_paraprobe_results_tessellator.yaml | 21 +- ...Xapm_paraprobe_results_transcoder.nxdl.xml | 350 ------------------ .../NXapm_paraprobe_results_transcoder.yaml | 11 +- .../nyaml/NXcs_profiling.yaml | 3 + 22 files changed, 212 insertions(+), 424 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml diff --git a/contributed_definitions/nyaml/NXapm_input_ranging.yaml b/contributed_definitions/nyaml/NXapm_input_ranging.yaml index f3c07abbc1..17e264bb2e 100644 --- a/contributed_definitions/nyaml/NXapm_input_ranging.yaml +++ b/contributed_definitions/nyaml/NXapm_input_ranging.yaml @@ -1,27 +1,33 @@ category: base doc: | Metadata to ranging definitions made for a dataset in atom probe microscopy. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + which ideally specify the most likely ion/molecular ion evaporated within a + given mass-to-charge-state-ratio value interval. + + The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE + iontype (or unranged ions) represents the default iontype. + The ID of this special iontype is always reserved as 0. Each ion + is assigned to the UNKNOWNTYPE by default. Iontypes are assigned + by checking if the mass-to-charge-state-ratio values of an ion matches + to any of the defined mass-to-charge-state-ratio intervals. # symbols: NXapm_input_ranging: filename: doc: | - Name of (NeXus)/HDF5 file which stores ranging definitions which define - how mass-to-charge-state ratios map to iontypes and which iontypes are - distinguished. The UNKNOWNTYPE iontype (unranged) is the default iontype. - The ID of this special iontype is always reserved as 0. Each ion - is assigned to the UNKNOWNTYPE by default. Iontypes are assigned - by checking if the mass-to-charge-state ratio of an ion matches - to any of the defined mass-to-charge-state ratio intervals. + Path and name of the NeXus/HDF5 file which stores ranging definitions. \@version: doc: | - Version identifier of the file (representing an at least SHA256) hash - which documents the binary state of the file to add an additional layer - of reproducibility for tracking provenance. + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. group_name_iontypes: doc: | - Name of the group (prefix to the individual ranging definitions) - inside the HDF5 file which refers to the ranging definition to use. - A HDF5 file can store multiple ranging definitions. Using an ID is + Name of the group (prefix to the individual ranging definitions) inside + the file referred to by filename which points to the specific ranging + definition to use. + An HDF5 file can store multiple ranging definitions. Using an ID is the mechanism to distinguish which specific ranging (version) will be processed. Reconstruction and ranging IDs can differ. They specify different IDs. diff --git a/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml index 152b71d48d..46e40116a8 100644 --- a/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml +++ b/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml @@ -7,16 +7,15 @@ NXapm_input_reconstruction: doc: | Name of the (NeXus)/HDF5 file which stores reconstructed ion position and mass-to-charge-state ratios. Such an HDF5 file can store multiple - reconstructions. Using an identifier (ID) is the mechanism which - paraprobe uses to distinguish which specific reconstruction will - be processed. With this design it is possible that the same HDF5 - file stores multiple versions of a reconstruction of e.g. the same - or different measured datasets, respectively. + reconstructions. Using the information within the dataset_name fields + is the mechanism whereby paraprobe decides which reconstruction to + process. With this design it is possible that the same HDF5 + file can store multiple versions of a reconstruction. \@version: doc: | - Version identifier of the file (representing an at least SHA256) hash - which documents the binary state of the file to add an additional layer - of reproducibility for tracking provenance. + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. dataset_name_reconstruction: doc: | Name of the dataset inside the HDF5 file which refers to the @@ -24,4 +23,4 @@ NXapm_input_reconstruction: dataset_name_mass_to_charge: doc: | Name of the dataset inside the HDF5 file which refers to the - specific mass-to-charge-state ratios to use for this analysis. + specific mass-to-charge-state-ratio values to use for this analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml index 275287cd48..e5d725e41d 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml @@ -33,6 +33,12 @@ NXapm_paraprobe_config_distancer: analysis_description: exists: optional doc: Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. number_of_processes(NX_UINT): doc: How many individual analyses should the tool execute. unit: NX_UNITLESS @@ -177,3 +183,6 @@ NXapm_paraprobe_config_distancer: # polyhedra_set_to_triangle_set(NXprocess): # doc: | # Compute the (shortest Euclidean) distance of all polyhedra of a set + + performance(NXcs_profiling): + current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml index c7df56b67c..2766a2dfe6 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml @@ -31,6 +31,12 @@ NXapm_paraprobe_config_intersector: analysis_description: exists: optional doc: Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. time_stamp(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to @@ -231,3 +237,6 @@ NXapm_paraprobe_config_intersector: # ##MK::tetrahedra volume intersection and tessellation, and Nef polyhedra intersection # ##MK::are considered guru features and therefore currently supported via modifying the C/C++ source code + + performance(NXcs_profiling): + current_working_directory: \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml index 75ea6b617b..c192d7a352 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml @@ -34,6 +34,12 @@ NXapm_paraprobe_config_nanochem: analysis_description: exists: optional doc: Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. time_stamp(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to @@ -874,3 +880,6 @@ NXapm_paraprobe_config_nanochem: # dimensions: # rank: 1 # dim: [[1, 1]] + + performance(NXcs_profiling): + current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml index 291dac3d5c..9546b302d4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml @@ -37,6 +37,12 @@ NXapm_paraprobe_config_ranger: analysis_description: exists: optional doc: Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. number_of_processes(NX_UINT): doc: How many task to perform? unit: NX_UNITLESS @@ -226,3 +232,6 @@ NXapm_paraprobe_config_ranger: filename: \@version: group_name_iontypes: + + performance(NXcs_profiling): + current_working_directory: \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml index eb9e09e83c..ddc514e0e8 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml @@ -34,6 +34,12 @@ NXapm_paraprobe_config_spatstat: analysis_description: exists: optional doc: Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. time_stamp(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC @@ -253,3 +259,6 @@ NXapm_paraprobe_config_spatstat: dim: [[1, 3]] # NEW ISSUE: ripleyk(NXcollection): # NEW ISSUE: two_point(NXcollection): + + performance(NXcs_profiling): + current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml index 59105c95d3..9de4c92e84 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml @@ -37,6 +37,12 @@ NXapm_paraprobe_config_surfacer: analysis_description: exists: optional doc: Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. number_of_processes(NX_UINT): doc: | For now a support field for the tool to identify how many individual @@ -196,3 +202,6 @@ NXapm_paraprobe_config_surfacer: Specifies if the tool should compute all interior tetrahedra of the alpha complex (currently only for alpha shapes). # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): + + performance(NXcs_profiling): + current_working_directory: \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml index 06bd309294..fb675f722a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml @@ -32,6 +32,12 @@ NXapm_paraprobe_config_tessellator: analysis_description: exists: optional doc: Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. time_stamp(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC @@ -178,3 +184,6 @@ NXapm_paraprobe_config_tessellator: unit: NX_LENGTH # \@units: nm # minValue: EPSILON + + performance(NXcs_profiling): + current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml index cbcb566f96..6bf8a07ebe 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml @@ -5,12 +5,15 @@ symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. NXapm_paraprobe_config_transcoder: (NXentry): + exists: [min, 1, max, 1] # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently \@version: - doc: Version specifier of this application definition. + doc: | + Version specifier of this application definition. definition: - doc: Official NeXus NXDL schema with which this file was written. + doc: | + Official NeXus NXDL schema with which this file was written. enumeration: [NXapm_paraprobe_config_transcoder] program: doc: | @@ -19,10 +22,10 @@ NXapm_paraprobe_config_transcoder: \@version: doc: | Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. + of ideally an ever persistent resource where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this computational + process is recreatable deterministically. analysis_identifier: exists: optional doc: | @@ -31,32 +34,37 @@ NXapm_paraprobe_config_transcoder: analysis_description: exists: optional doc: Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. time_stamp(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC information included when this configuration file was created. + (NXprocess): + # NXapm_input base classes are specialized here because + # paraprobe-transcoder is the entry point for community data + # which are not necessarily NeXus dataset(NXapm_input_reconstruction): filename: doc: | - The absolute path and name of the vendor or community file from which - to read the reconstructed ion positions. Currently POS, ePOS, and APT - files from APSuite are supported. + The path and name of the file (technology partner or community format) + from which to read the reconstructed ion positions. Currently, POS, + ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files + are supported. \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. iontypes(NXapm_input_ranging): filename: doc: | - The absolute path and name of the vendor or community file from which - to read the ranging definitions, i.e. how to map mass-to-charge-state - ratios on iontypes. Currently RRNG and RNG files are supported. + The path and name of the file (technology partner or community format + from which to read the ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. + NeXus/HDF5 files are supported. \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. + + performance(NXcs_profiling): + current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml index 3d15b7b63f..0424b8a7a4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml @@ -10,6 +10,7 @@ NXapm_paraprobe_results_clusterer: (NXentry): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently + exists: [min, 1, max, 1] \@version: doc: Version specifier of this application definition. @@ -55,6 +56,12 @@ NXapm_paraprobe_results_clusterer: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. status(NX_CHAR): doc: | A statement whether the paraprobe-tool executable managed to @@ -345,6 +352,7 @@ NXapm_paraprobe_results_clusterer: # ##MK::end of the tool-specific section performance(NXcs_profiling): exists: recommended + current_working_directory: command_line_call: exists: optional start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml index ee6132b0f0..b06893daed 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml @@ -10,6 +10,7 @@ NXapm_paraprobe_results_distancer: (NXentry): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently + exists: [min, 1, max, 1] \@version: doc: Version specifier of this application definition. @@ -56,6 +57,12 @@ NXapm_paraprobe_results_distancer: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. status(NX_CHAR): doc: | A statement whether the paraprobe-tool executable managed to @@ -236,6 +243,7 @@ NXapm_paraprobe_results_distancer: performance(NXcs_profiling): exists: recommended + current_working_directory: command_line_call: exists: optional start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml index 77a5f43ade..36aa9b81d5 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml @@ -54,6 +54,12 @@ NXapm_paraprobe_results_intersector: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. (NXuser): exists: recommended doc: | @@ -223,13 +229,14 @@ NXapm_paraprobe_results_intersector: unit: NX_UNITLESS dimensions: rank: 1 - dim: [1, n_total], [2, 2]] + dim: [[1, n_total], [2, 2]] # ##MK::add results from NXapm_paraprobe_results_clusterer # ##MK::end of the tool-specific section performance(NXcs_profiling): exists: recommended + current_working_directory: command_line_call: exists: optional start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml index bcb7f2a220..9233d3efec 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml @@ -18,6 +18,7 @@ NXapm_paraprobe_results_nanochem: (NXentry): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently + exists: [min, 1, max, 1] \@version: doc: Version specifier of this application definition. @@ -63,6 +64,12 @@ NXapm_paraprobe_results_nanochem: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. status(NX_CHAR): doc: | A statement whether the paraprobe-tool executable managed to @@ -1218,7 +1225,7 @@ NXapm_paraprobe_results_nanochem: unit: NX_UNITLESS dimensions: rank: 1 - dim: [[1, i] + dim: [[1, i]] proxies_far_from_edge(NXms_three_d_feature_set): exists: optional doc: | @@ -1298,7 +1305,7 @@ NXapm_paraprobe_results_nanochem: unit: NX_UNITLESS dimensions: rank: 1 - dim: [[1, i] + dim: [[1, i]] interface_modelling(NXprocess): exists: optional ion_multiplicity(NX_UINT): @@ -1325,15 +1332,15 @@ NXapm_paraprobe_results_nanochem: exists: optional doc: | The equation of the plane that is fitting initially. - point_normal_form(NX_FLOAT): - doc: | - The four parameter ax + by + cz + d = 0 which define the plane. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 4]] + point_normal_form(NX_FLOAT): + doc: | + The four parameter ax + by + cz + d = 0 which define the plane. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 4]] MESH_CURR_PRE_DCOM_STEP(NXcg_triangle_set): - exists: [min, 0, max infty] + exists: [min, 0, max, infty] doc: | The triangle surface mesh representing the interface model. Exported at some iteration before the next DCOM step. @@ -1447,7 +1454,7 @@ NXapm_paraprobe_results_nanochem: rank: 2 dim: [[1, c], [2, 3]] MESH_CURR_POST_DCOM_STEP(NXcg_triangle_set): - exists: [min, 0, max infty] + exists: [min, 0, max, infty] doc: | The triangle surface mesh representing the interface model. Exported at some iteration after the next DCOM step. @@ -1635,6 +1642,7 @@ NXapm_paraprobe_results_nanochem: performance(NXcs_profiling): exists: recommended + current_working_directory: command_line_call: exists: optional start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml index 1e7f5e8153..bffff42e96 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml @@ -11,6 +11,7 @@ NXapm_paraprobe_results_ranger: (NXentry): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently + exists: [min, 1, max, 1] \@version: doc: Version specifier of this application definition. @@ -52,11 +53,17 @@ NXapm_paraprobe_results_ranger: were completed and the paraprobe-tool executable exited as a process. config_filename: doc: | - The absolute path and name of the config file for this analysis. + The path and name of the config file for this analysis. \@version: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. status(NX_CHAR): doc: | A statement whether the paraprobe-tool executable managed to @@ -126,7 +133,7 @@ NXapm_paraprobe_results_ranger: maximum_number_of_atoms_per_molecular_ion(NX_POSINT): doc: | The length of the isotope_vector used to describe molecular ions. - units: NX_UNITLESS + unit: NX_UNITLESS ION(NXion): exists: [min, 1, max, 256] isotope_vector(NX_UINT): @@ -302,7 +309,7 @@ NXapm_paraprobe_results_ranger: maximum_number_of_atoms_per_molecular_ion(NX_POSINT): doc: | The length of the isotope_vector used to describe molecular ions. - units: NX_UNITLESS + unit: NX_UNITLESS charged_ION(NXion): exists: [min, 1, max, 256] isotope_vector(NX_UINT): @@ -313,7 +320,7 @@ NXapm_paraprobe_results_ranger: # ##MK::end of the tool-specific section performance(NXcs_profiling): - exists: recommended + current_working_directory: command_line_call: exists: optional start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml index 3577368866..13c0ba85ff 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml @@ -9,6 +9,7 @@ NXapm_paraprobe_results_selector: (NXentry): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently + exists: [min, 1, max, 1] \@version: doc: Version specifier of this application definition. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml index c3e7af8ede..827673d547 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml @@ -9,6 +9,7 @@ NXapm_paraprobe_results_spatstat: (NXentry): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently + exists: [min, 1, max, 1] \@version: doc: Version specifier of this application definition. @@ -55,6 +56,12 @@ NXapm_paraprobe_results_spatstat: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. status(NX_CHAR): doc: | A statement whether the paraprobe-tool executable managed to @@ -206,6 +213,7 @@ NXapm_paraprobe_results_spatstat: performance(NXcs_profiling): exists: recommended + current_working_directory: command_line_call: exists: optional start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml index 0473cf9d3e..562d7ae9b2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml @@ -14,6 +14,7 @@ NXapm_paraprobe_results_surfacer: (NXentry): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently + exists: [min, 1, max, 1] \@version: doc: Version specifier of this application definition. @@ -60,6 +61,12 @@ NXapm_paraprobe_results_surfacer: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. status(NX_CHAR): doc: | A statement whether the paraprobe-tool executable managed to @@ -321,6 +328,7 @@ NXapm_paraprobe_results_surfacer: performance(NXcs_profiling): exists: recommended + current_working_directory: command_line_call: exists: optional start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml index dc486643d8..7b0dc27fff 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml @@ -10,6 +10,7 @@ NXapm_paraprobe_results_tessellator: (NXentry): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently + exists: [min, 1, max, 1] \@version: doc: Version specifier of this application definition. @@ -56,6 +57,12 @@ NXapm_paraprobe_results_tessellator: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. status(NX_CHAR): doc: | A statement whether the paraprobe-tool executable managed to @@ -490,23 +497,11 @@ NXapm_paraprobe_results_tessellator: dimensions: rank: 1 dim: [[1, n_f_xdmf]] - - - - - - - - - - - - - # ##MK::end of the tool-specific section performance(NXcs_profiling): exists: recommended + current_working_directory: command_line_call: exists: optional start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml deleted file mode 100644 index e66cdeb45f..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml +++ /dev/null @@ -1,350 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). Needs - to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals mapped on this ion - type. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Results of a paraprobe-transcoder tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. - - - - - - - - - On a mid term perspective we would like to evolve the paraprobe-toolbox - to an implementation stage where it works exclusively with completely - provenance-tracked formats for both the configuration of the workflow step - and/or analysis with each tool and also for the output of these analyses - in the form of so-called tool-specific results files. - Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. - - Different file formats can be used to inject reconstructed datasets and - ranging definitions into the toolbox. Traditionally, these are the POS, - ePOS, and APT files with the tomographic reconstruction and other metadata - and RNG and RRNG file formats for the ranging definitions how mass-to-charge - state-ratio values map on (molecular) ion types. Such input should be - injected via specific NeXus/HDF5 files which are documented - in compliance with the NXapm application definition. - - So far the paraprobe-toolbox was used as a standalone tool. Therefore, it - was not relevant during the development to focus on interoperability. - Essentially paraprobe-transcoder was used as a parser to transcode data - in the above-mentioned file formats into a paraprobe-specific - representation. This transcoding should become deprecated. - Here we describe steps we have taken into this direction. - - With the work in the FAIRmat project and the desire to make the paraprobe- - toolbox also accessible as a cloud-computing capable service in the Nomad - Remote Tools Hub (NORTH) the topic of interoperability became more important - and eventually the NXapm application definition was proposed. - NORTH is a GUI and related service in a NOMAD OASIS instance which allows - to spawn preconfigured docker containers via JupyterHub. - Currently, NORTH includes the so-called apm container. A container with - tools specific for analyzing data from atom probe microscopy as well as - processing of point cloud and mesh data. - - The NXapm application definition and related implementation work within - NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and - RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook - solutions directly into NOMAD OASIS via the uploads section. - The process is automated and yields an NXapm-compliant NeXus/HDF5 file - inside the uploads section in return. - - With these improvements made there is no longer a need for - at least the - users of a NOMAD OASIS and NORTH instance to use the deprecated - PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should - automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 - file and in response work with this file directly. - To remain compliant with users however who do not have or do not wish - to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is - as follows: - - Calling the configuration stage of paraprobe-transcoder is always mandatory. - It is always the first step of working with the toolbox. In this process - the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ - HDF5 file from e.g. the upload section, or such a file that was obtained from - a colleague with a NOMAD OASIS instance. - In all other cases, users can pass the reconstruction and ranging definitions - using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. - - Based on which input the user delivers, the parmsetup-transcoder tool then - creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and - informs the user whether the input was NeXus (and thus if all relevant - input is already available) or whether the paraprobe-transcoder tool needs - to be executed to convert the content of the vendor files first into a - format which paraprobe can provenance track and understand. - In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is - used to communicate to all subsequently used tools from which files - the tools can expect to find the reconstruction and ranging definitions. - - All subsequent analysis steps start also with a tool-specific configuration. - This configuration step reads in (among others) the - PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration - tool identifies automatically whether to read the reconstruction and ranging data - from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant - NeXus/HDF5 file that was created upon preparing the upload or the file shared - from a colleague. This design removes the need for unnecessary copies of the data. - Currently still though users should execute the transcoder step as it will - generate a supplementary XDMF topology field with which the data in either - the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. - Paraview. For this purpose XDMF is used. - - Of course ideally the APT community would at some point converge to use - a common data exchange file format. To this end, AMETEK/Cameca's APT file format - could be a good starting point but so far it is lacking a consistent way of - how to store generalized ranging definitions and post-processing results. - POS, ePOS, Rouen's ATO, as well as other so far used representations of data - like CSV or text files have, to the best of our current knowledge, no - concept of how to marry reconstruction and (optional) ranging data into - one self-descriptive format. - - This summarizes the rationale behind the current choices of the I/O for - paraprobe. Furthermore, this summarizes also why the fundamental design - of splitting an analysis always into steps of configuration (with parmsetup), - task execution (with the respective C/C++ or Python tool of the toolbox), - and post-processing (e.g. with autoreporter) is useful because it offers - a clear description of provenance tracking. This is a necessary step to make - atom probe microscopy data at all better aligned with the aims of the - FAIR principles. - - The internal organization of the data entries in the atom_probe group - in this application definition for paraprobe-transcoder results files - mirror the definitions of the NXapm for consistency reasons. - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml index 8f866fde6b..5b72b00819 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml @@ -13,6 +13,7 @@ NXapm_paraprobe_results_transcoder: (NXentry): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently + exists: [min, 1, max, 1] \@version: doc: Version specifier of this application definition. @@ -59,6 +60,12 @@ NXapm_paraprobe_results_transcoder: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. status(NX_CHAR): doc: | A statement whether the paraprobe-tool executable managed to @@ -326,10 +333,12 @@ NXapm_paraprobe_results_transcoder: exists: recommended charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): + # add further fields coming from using the charge state recovery + # workflow from the ifes_apt_tc_data_modeling library # ##MK::end of the tool-specific section performance(NXcs_profiling): - exists: recommended + current_working_directory: command_line_call: exists: optional start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXcs_profiling.yaml b/contributed_definitions/nyaml/NXcs_profiling.yaml index cb3acc7f35..3e6d431394 100644 --- a/contributed_definitions/nyaml/NXcs_profiling.yaml +++ b/contributed_definitions/nyaml/NXcs_profiling.yaml @@ -44,6 +44,9 @@ symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. NXcs_profiling: # details about queuing systems etc + current_working_directory: + doc: | + Path to the directory from which the tool was called. command_line_call(NX_CHAR): doc: | Command line call with arguments if applicable. From d18723004f53ec871f7e9d1762d9bf8db625ea73 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Tue, 14 Feb 2023 14:37:50 +0100 Subject: [PATCH 098/203] Renaming file extension yml to yaml in ./contrubited_definition/nayml. --- .../{NXcalibration.yml => NXcalibration.yaml} | 0 ...tioncolumn.yml => NXcollectioncolumn.yaml} | 0 .../{NXdeflector.yml => NXdeflector.yaml} | 0 .../{NXdistortion.yml => NXdistortion.yaml} | 0 ...onanalyser.yml => NXelectronanalyser.yaml} | 0 ...dispersion.yml => NXenergydispersion.yaml} | 0 contributed_definitions/nyaml/NXlens_em.yaml | 54 +++++++------------ contributed_definitions/nyaml/NXlens_em.yml | 36 ------------- .../{NXliquid_jet.yml => NXliquid_jet.yaml} | 0 .../{NXmanipulator.yml => NXmanipulator.yaml} | 0 .../nyaml/{NXmpes.yml => NXmpes.yaml} | 0 .../{NXmpes_liquid.yml => NXmpes_liquid.yaml} | 0 ...NXregistration.yml => NXregistration.yaml} | 0 ...indispersion.yml => NXspindispersion.yaml} | 0 ...NXtransmission.yml => NXtransmission.yaml} | 0 15 files changed, 20 insertions(+), 70 deletions(-) rename contributed_definitions/nyaml/{NXcalibration.yml => NXcalibration.yaml} (100%) rename contributed_definitions/nyaml/{NXcollectioncolumn.yml => NXcollectioncolumn.yaml} (100%) rename contributed_definitions/nyaml/{NXdeflector.yml => NXdeflector.yaml} (100%) rename contributed_definitions/nyaml/{NXdistortion.yml => NXdistortion.yaml} (100%) rename contributed_definitions/nyaml/{NXelectronanalyser.yml => NXelectronanalyser.yaml} (100%) rename contributed_definitions/nyaml/{NXenergydispersion.yml => NXenergydispersion.yaml} (100%) delete mode 100644 contributed_definitions/nyaml/NXlens_em.yml rename contributed_definitions/nyaml/{NXliquid_jet.yml => NXliquid_jet.yaml} (100%) rename contributed_definitions/nyaml/{NXmanipulator.yml => NXmanipulator.yaml} (100%) rename contributed_definitions/nyaml/{NXmpes.yml => NXmpes.yaml} (100%) rename contributed_definitions/nyaml/{NXmpes_liquid.yml => NXmpes_liquid.yaml} (100%) rename contributed_definitions/nyaml/{NXregistration.yml => NXregistration.yaml} (100%) rename contributed_definitions/nyaml/{NXspindispersion.yml => NXspindispersion.yaml} (100%) rename contributed_definitions/nyaml/{NXtransmission.yml => NXtransmission.yaml} (100%) diff --git a/contributed_definitions/nyaml/NXcalibration.yml b/contributed_definitions/nyaml/NXcalibration.yaml similarity index 100% rename from contributed_definitions/nyaml/NXcalibration.yml rename to contributed_definitions/nyaml/NXcalibration.yaml diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yml b/contributed_definitions/nyaml/NXcollectioncolumn.yaml similarity index 100% rename from contributed_definitions/nyaml/NXcollectioncolumn.yml rename to contributed_definitions/nyaml/NXcollectioncolumn.yaml diff --git a/contributed_definitions/nyaml/NXdeflector.yml b/contributed_definitions/nyaml/NXdeflector.yaml similarity index 100% rename from contributed_definitions/nyaml/NXdeflector.yml rename to contributed_definitions/nyaml/NXdeflector.yaml diff --git a/contributed_definitions/nyaml/NXdistortion.yml b/contributed_definitions/nyaml/NXdistortion.yaml similarity index 100% rename from contributed_definitions/nyaml/NXdistortion.yml rename to contributed_definitions/nyaml/NXdistortion.yaml diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yml b/contributed_definitions/nyaml/NXelectronanalyser.yaml similarity index 100% rename from contributed_definitions/nyaml/NXelectronanalyser.yml rename to contributed_definitions/nyaml/NXelectronanalyser.yaml diff --git a/contributed_definitions/nyaml/NXenergydispersion.yml b/contributed_definitions/nyaml/NXenergydispersion.yaml similarity index 100% rename from contributed_definitions/nyaml/NXenergydispersion.yml rename to contributed_definitions/nyaml/NXenergydispersion.yaml diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index b5482e9a9a..682d36d7bf 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -1,50 +1,36 @@ category: base doc: | Description of an electro-magnetic lens or a compound lens. - + + Details of an `electro-magnetic 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 `_ + in the center of the lens (its polepiece, pinhole, or another point of + reference. The origin should be specified in the NXtransformations. + + .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 NXlens_em: type: - doc: Qualitative type of lens with respect to the number of pole pieces. - enumeration: [single, double, quadrupole, hexapole, octupole] + doc: "Qualitative type of lens with respect to the number of pole pieces" + enumeration: ["single", "double", "quadrupole", "hexapole", "octupole"] name: - doc: | - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. + doc: "Colloquial or short name for the lens. For manufacturer names and identifiers use respective manufacturer fields." manufacturer_name: - doc: Name of the manufacturer who built/constructed the lens. - (NXfabrication): + doc: "Name of the manufacturer who built/constructed the lens." + (NXmanufacturer): model: - doc: Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens. + doc: "Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens." description: - doc: Ideally an identifier, persistent link, or free text which gives further details about the lens. + doc: "Ideally an identifier, persistent link, or free text which gives further details about the lens." voltage(NX_NUMBER): - doc: Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array. + doc: "Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array." unit: NX_VOLTAGE current(NX_NUMBER): - doc: Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array. + doc: "Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array." unit: NX_CURRENT - value(NX_NUMBER): - doc: | - 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. - unit: NX_ANY depends_on(NX_CHAR): - doc: Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group. + doc: "Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group." (NXtransformations): - doc: | - 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. + doc: + "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/nyaml/NXlens_em.yml b/contributed_definitions/nyaml/NXlens_em.yml deleted file mode 100644 index 682d36d7bf..0000000000 --- a/contributed_definitions/nyaml/NXlens_em.yml +++ /dev/null @@ -1,36 +0,0 @@ -category: base -doc: | - Description of an electro-magnetic lens or a compound lens. - - Details of an `electro-magnetic 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. - - .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 -NXlens_em: - type: - doc: "Qualitative type of lens with respect to the number of pole pieces" - enumeration: ["single", "double", "quadrupole", "hexapole", "octupole"] - name: - doc: "Colloquial or short name for the lens. For manufacturer names and identifiers use respective manufacturer fields." - manufacturer_name: - doc: "Name of the manufacturer who built/constructed the lens." - (NXmanufacturer): - model: - doc: "Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens." - description: - doc: "Ideally an identifier, persistent link, or free text which gives further details about the lens." - voltage(NX_NUMBER): - doc: "Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array." - unit: NX_VOLTAGE - current(NX_NUMBER): - doc: "Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array." - unit: NX_CURRENT - depends_on(NX_CHAR): - doc: "Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group." - (NXtransformations): - doc: - "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/nyaml/NXliquid_jet.yml b/contributed_definitions/nyaml/NXliquid_jet.yaml similarity index 100% rename from contributed_definitions/nyaml/NXliquid_jet.yml rename to contributed_definitions/nyaml/NXliquid_jet.yaml diff --git a/contributed_definitions/nyaml/NXmanipulator.yml b/contributed_definitions/nyaml/NXmanipulator.yaml similarity index 100% rename from contributed_definitions/nyaml/NXmanipulator.yml rename to contributed_definitions/nyaml/NXmanipulator.yaml diff --git a/contributed_definitions/nyaml/NXmpes.yml b/contributed_definitions/nyaml/NXmpes.yaml similarity index 100% rename from contributed_definitions/nyaml/NXmpes.yml rename to contributed_definitions/nyaml/NXmpes.yaml diff --git a/contributed_definitions/nyaml/NXmpes_liquid.yml b/contributed_definitions/nyaml/NXmpes_liquid.yaml similarity index 100% rename from contributed_definitions/nyaml/NXmpes_liquid.yml rename to contributed_definitions/nyaml/NXmpes_liquid.yaml diff --git a/contributed_definitions/nyaml/NXregistration.yml b/contributed_definitions/nyaml/NXregistration.yaml similarity index 100% rename from contributed_definitions/nyaml/NXregistration.yml rename to contributed_definitions/nyaml/NXregistration.yaml diff --git a/contributed_definitions/nyaml/NXspindispersion.yml b/contributed_definitions/nyaml/NXspindispersion.yaml similarity index 100% rename from contributed_definitions/nyaml/NXspindispersion.yml rename to contributed_definitions/nyaml/NXspindispersion.yaml diff --git a/contributed_definitions/nyaml/NXtransmission.yml b/contributed_definitions/nyaml/NXtransmission.yaml similarity index 100% rename from contributed_definitions/nyaml/NXtransmission.yml rename to contributed_definitions/nyaml/NXtransmission.yaml From dc1ac62c62fb8f199b17e91d7e56eb7ff5b5636d Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Tue, 14 Feb 2023 16:11:17 +0100 Subject: [PATCH 099/203] Markus_changes: converting nxdl file from yaml in ./contributed/definitions/nyaml --- contributed_definitions/nyaml/NXapm.nxdl.xml | 173 +- .../nyaml/NXapm_input_ranging.nxdl.xml | 32 +- .../nyaml/NXapm_input_reconstruction.nxdl.xml | 17 +- .../NXapm_paraprobe_config_clusterer.nxdl.xml | 374 ++-- .../NXapm_paraprobe_config_distancer.nxdl.xml | 10 + ...Xapm_paraprobe_config_intersector.nxdl.xml | 457 ++-- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 14 + .../NXapm_paraprobe_config_ranger.nxdl.xml | 20 +- .../NXapm_paraprobe_config_selector.nxdl.xml | 118 ++ .../NXapm_paraprobe_config_spatstat.nxdl.xml | 258 ++- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 53 +- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 10 + ...NXapm_paraprobe_config_transcoder.nxdl.xml | 52 +- ...NXapm_paraprobe_results_clusterer.nxdl.xml | 410 ++++ ...NXapm_paraprobe_results_distancer.nxdl.xml | 354 ++++ ...apm_paraprobe_results_intersector.nxdl.xml | 356 ++++ .../NXapm_paraprobe_results_nanochem.nxdl.xml | 1855 +++++++++++++++++ .../NXapm_paraprobe_results_ranger.nxdl.xml | 167 +- .../NXapm_paraprobe_results_selector.nxdl.xml | 243 +++ .../NXapm_paraprobe_results_spatstat.nxdl.xml | 317 +++ .../NXapm_paraprobe_results_surfacer.nxdl.xml | 471 +++++ ...apm_paraprobe_results_tessellator.nxdl.xml | 632 ++++++ ...Xapm_paraprobe_results_transcoder.nxdl.xml | 383 ++++ .../nyaml/NXcg_alpha_complex.nxdl.xml | 99 + .../nyaml/NXchemical_composition.nxdl.xml | 44 + .../nyaml/NXcs_profiling.nxdl.xml | 5 + contributed_definitions/nyaml/NXem.nxdl.xml | 282 ++- .../nyaml/NXem_ebsd.nxdl.xml | 875 ++++++++ .../nyaml/NXem_ebsd_conventions.nxdl.xml | 467 +++++ ...NXem_ebsd_crystal_structure_model.nxdl.xml | 189 ++ .../nyaml/NXimage_set_em.nxdl.xml | 86 + .../nyaml/NXimage_set_em_adf.nxdl.xml | 23 +- .../nyaml/NXimage_set_em_kikuchi.nxdl.xml | 173 ++ .../nyaml/NXisocontour.nxdl.xml | 43 + .../nyaml/NXlens_em.nxdl.xml | 37 +- .../nyaml/NXsensor_scan_parsed.nxdl.xml | 176 ++ .../nyaml/NXsensor_scan_parsed.yaml | 134 ++ .../nyaml/NXsimilarity_grouping.nxdl.xml | 140 ++ .../nyaml/NXspectrum_set_em_eels.nxdl.xml | 47 +- .../nyaml/NXspectrum_set_em_xray.nxdl.xml | 86 +- 40 files changed, 8898 insertions(+), 784 deletions(-) create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_selector.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_selector.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_alpha_complex.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXchemical_composition.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXem_ebsd_conventions.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXimage_set_em.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_kikuchi.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXisocontour.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXsensor_scan_parsed.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXsensor_scan_parsed.yaml create mode 100644 contributed_definitions/nyaml/NXsimilarity_grouping.nxdl.xml diff --git a/contributed_definitions/nyaml/NXapm.nxdl.xml b/contributed_definitions/nyaml/NXapm.nxdl.xml index 8ad9bf96c4..a111eb0ba3 100644 --- a/contributed_definitions/nyaml/NXapm.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm.nxdl.xml @@ -28,8 +28,7 @@ - Number of mass-to-charge-state-ratio intervals mapped on this ion - type. + Number of mass-to-charge-state-ratio intervals of this ion type. @@ -56,7 +55,7 @@ Application definition for atom probe and field ion microscopy experiments. - + An at least as strong as SHA256 hashvalue of the file @@ -87,8 +86,8 @@ Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. @@ -98,7 +97,7 @@ If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant - - this start time field should be used. + - this start_time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping @@ -286,7 +285,8 @@ Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform @@ -311,7 +311,8 @@ - Account name that is associated with the user in social media platforms. + Account name that is associated with the user + in social media platforms. @@ -386,9 +387,10 @@ - Use Hill's system for listing elements of the periodic table which - are inside or attached to the surface of the specimen, and thus - relevant from a scientific point of view. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret @@ -457,7 +459,7 @@ Consult the work of A. J. Breen and B. Gault and team for further details. - + @@ -489,7 +491,9 @@ Using GEOREF is preferred. - + + + @@ -509,19 +513,6 @@ detected or hit elsewhere in the analysis_chamber. - - - - - - - - - - Average pressure in the analysis chamber. - - - @@ -530,6 +521,8 @@ + + @@ -580,7 +573,8 @@ - Given hardware name/serial number or hash identifier issued by the manufacturer. + Given hardware name/serial number or hash identifier + issued by the manufacturer. @@ -607,12 +601,12 @@ - + - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. If pulse_mode is set to laser or laser_and_voltage (e.g. for LEAP6000-type instruments) having the group/section laser_gun is required and the following of its fields have to be filled: @@ -623,6 +617,8 @@ + + @@ -643,22 +639,26 @@ - + + + - Average pressure in the load_lock_chamber. + Average pressure in the analysis chamber. + + @@ -669,9 +669,26 @@ + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + @@ -679,6 +696,8 @@ + + @@ -686,6 +705,8 @@ + + @@ -892,17 +913,18 @@ - + - Hit multiplicity. + Number of pulses since the start of the atom probe + run/evaporation sequence. - + - Number of pulses since the start of the atom probe run/evaporation sequence. + Hit multiplicity. @@ -936,7 +958,8 @@ - Bitmask which is set to true if the ion is considered and false otherwise. + Bitmask which is set to true if the ion + is considered and false otherwise. @@ -1134,9 +1157,15 @@ - A default three-dimensional histogram of the total number of ions in each bin. + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. - + + + + + Array of counts for each bin. @@ -1146,26 +1175,33 @@ - + - Bin positions along the z axis. + Bin center of mass position along the z axis. + + + + - + - Bin positions along the y axis. + Bin center of mass position along the y axis. + + + + - + - Bin positions along the x axis. + Bin center of mass position along the x axis. + + + + - - - Naive point cloud density map. - - @@ -1196,7 +1232,7 @@ - + How many ion types are distinguished. If no ranging was performed each ion is of the special unknown type. @@ -1252,24 +1288,28 @@ A default histogram aka mass spectrum of the mass-to-charge-state ratio values. - + + + + + Array of counts for each bin. + - + - End of value for each mass-to-charge-state ratio bin. + Right boundary of each mass-to-charge-state ratio value bin. + + + + - - - Mass-to-charge-state histogram. - - @@ -1317,7 +1357,11 @@ - + + + THIS DOCSTRING NEEDS CLARIFICATION. + + @@ -1341,11 +1385,12 @@ - + - + + diff --git a/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml b/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml index 5ccc9567c7..49273f8bc7 100644 --- a/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml @@ -3,30 +3,36 @@ Metadata to ranging definitions made for a dataset in atom probe microscopy. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + which ideally specify the most likely ion/molecular ion evaporated within a + given mass-to-charge-state-ratio value interval. + + The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE + iontype (or unranged ions) represents the default iontype. + The ID of this special iontype is always reserved as 0. Each ion + is assigned to the UNKNOWNTYPE by default. Iontypes are assigned + by checking if the mass-to-charge-state-ratio values of an ion matches + to any of the defined mass-to-charge-state-ratio intervals. - Name of (NeXus)/HDF5 file which stores ranging definitions which define - how mass-to-charge-state ratios map to iontypes and which iontypes are - distinguished. The UNKNOWNTYPE iontype (unranged) is the default iontype. - The ID of this special iontype is always reserved as 0. Each ion - is assigned to the UNKNOWNTYPE by default. Iontypes are assigned - by checking if the mass-to-charge-state ratio of an ion matches - to any of the defined mass-to-charge-state ratio intervals. + Path and name of the NeXus/HDF5 file which stores ranging definitions. - Version identifier of the file (representing an at least SHA256) hash - which documents the binary state of the file to add an additional layer - of reproducibility for tracking provenance. + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. - Name of the group (prefix to the individual ranging definitions) - inside the HDF5 file which refers to the ranging definition to use. - A HDF5 file can store multiple ranging definitions. Using an ID is + Name of the group (prefix to the individual ranging definitions) inside + the file referred to by filename which points to the specific ranging + definition to use. + An HDF5 file can store multiple ranging definitions. Using an ID is the mechanism to distinguish which specific ranging (version) will be processed. Reconstruction and ranging IDs can differ. They specify different IDs. diff --git a/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml index a1d33d25c9..16bceaeac3 100644 --- a/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml @@ -8,17 +8,16 @@ Name of the (NeXus)/HDF5 file which stores reconstructed ion position and mass-to-charge-state ratios. Such an HDF5 file can store multiple - reconstructions. Using an identifier (ID) is the mechanism which - paraprobe uses to distinguish which specific reconstruction will - be processed. With this design it is possible that the same HDF5 - file stores multiple versions of a reconstruction of e.g. the same - or different measured datasets, respectively. + reconstructions. Using the information within the dataset_name fields + is the mechanism whereby paraprobe decides which reconstruction to + process. With this design it is possible that the same HDF5 + file can store multiple versions of a reconstruction. - Version identifier of the file (representing an at least SHA256) hash - which documents the binary state of the file to add an additional layer - of reproducibility for tracking provenance. + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. @@ -31,7 +30,7 @@ Name of the dataset inside the HDF5 file which refers to the - specific mass-to-charge-state ratios to use for this analysis. + specific mass-to-charge-state-ratio values to use for this analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml index 8f0db4b2c2..08feb6647b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -5,14 +5,19 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - + - Number of position values. + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - + - Number of disjoint cluster. + Number of clustering algorithms used. + + + + + Number of different iontypes to distinguish during clustering. @@ -48,6 +53,12 @@ + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + Ideally, a (globally persistent) unique identifier for referring @@ -59,18 +70,12 @@ Possibility for leaving a free-text description about this analysis. - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - How many clustering processes should the tool execute. + How many tasks to perform? - + This process maps results from cluster analyses performed with IVAS/APSuite into an interoperable representation. Specifically in this process @@ -100,118 +105,26 @@ - - - - - + + + AMETEK/Cameca results of cluster analyses, like with the maximum- + separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ + are stored as an improper POS file: This is a matrix of floating + point quadruplets, one for each ion and as many quadruplets as + ions were investigated. The first three values encode the position + of the ion. The fourth value is an improper mass-to-charge-state-ratio + value which encodes the integer identifier of the cluster as a floating + point number. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Name of HDF5 file which stores reconstructed ion positions. - This file should have been generated by from the community or vendor format. - This file not necessarily contains all the of the dataset because - spatial filters might have been applied in commercial software prior - to executing the cluster analysis so that e.g. only positions within a - ROI are reported by the commercial software. - POS files from IVAS have to be converted first. - - - - - Name of the dataset inside the HDF5 file ion_position_filename - which refers to the specific positions to use for this analysis. - The referred to dataset has to be formatted as an array of shape - (n_positions, 3). - - - - - Name of the HDF5 file which stores mass-to-charge-state-ratio values - (in the case of IVAS/APSuite) or other numbers which can be interpreted - as cluster labels. - - - - - Name of the dataset inside the HDF5 file cluster_indices_filename - which refers to the specifically encoded cluster indices. - The referred to dataset has to be formatted as an array of shape - (n_positions, 1). - - - - - The list of all keywords of a dictionary which maps implicit cluster - indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - - - - - - - - The list of all values of a dictionary which maps implicit cluster - indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - The sequences of mapping_dictionary_keyword and mapping_dictionary_value - have to match. - - - - - - + Specifies if the tool should try to recover for each position the closest matching position from dataset/dataset_name_reconstruction (within floating point accuracy). This can be useful for instance when users - wish to recover the original evaporation ID which IVAS/AP Suite drops - for instance when writing their *.indexed.* cluster results files. - - - - - Specifies if the tool should try to recover, after a recovery of the - evaporation IDs a bitmask which identifies which of the positions - in dataset/dataset/dataset_name_reconstruction where covered - by the IVAS/APSuite cluster analysis. This can be useful to recover - the region of interest. + wish to recover the original evaporation ID, which IVAS/AP Suite drops + for instance when writing their *.indexed.* cluster results POS files. @@ -233,8 +146,35 @@ + + + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + - + + + + + @@ -267,17 +207,203 @@ - + - Name of the algorithm. + How should iontypes be interpreted/considered during the cluster analysis. + Different options exist how iontypes are interpreted (if considered at all) + given an iontype represents in general a (molecular) ion with different isotopes + that have individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + This is relevant as in atom probe we have the situation that a ion + of a molecular ion with more than one nuclid, say Ti O for example + is counted such that although there is a single TiO molecular ion + at a position that the cluster has two members. This multiplicity + affects the size of the feature and chemical composition. + + + - + - A text representation like a JSON/YAML dictionary with the - parameter of the clustering_algorithm. + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + Settings for DBScan clustering algorithm. For original details about the + algorithms and (performance-relevant) details consider: + + * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ + * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + As an example we may define eps with ten entries and min_pts with + three entries. If high_throughput_method is tuple the analysis is + invalid as we have an insufficient number of min_pts for the ten + eps values. + By contrast, for combinatorics paraprobe-clusterer will run three + individual min_pts runs for each eps value, resulting in a total + of 30 analyses. + As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ + would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) + eps values, min_pts one, and high_throughput_method set to combinatorics. + + + + + + + + + Array of epsilon (eps) parameter values. + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + + Settings for the OPTICS clustering algorithm. + + * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + Array of maximum epsilon (eps) parameter values. + + + + + + + + + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ + * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + + + + + + + + + Array of min_cluster_size parameter values. + + + + + + + + Array of min_samples parameter values. + + + + + + + + Array of cluster_selection parameter values. + + + + + + + + Array of alpha parameter values. + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml index b653e4a285..7062ba16ed 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml @@ -55,6 +55,13 @@ Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + How many individual analyses should the tool execute. @@ -212,5 +219,8 @@ + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml index 3401650db5..36d9e1d499 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml @@ -5,11 +5,6 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - - - How many elements to use for computing a composition. - - Configuration of a paraprobe-intersector tool run in atom probe microscopy. @@ -54,79 +49,18 @@ Possibility for leaving a free-text description about this analysis. - - - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - - - - - Specifies the method to use which decides if two objects intersect. - For reasons which are detailed in the supplementary material of - `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by - default assumes that two objects intersect if they share at least one - ion with the same evaporation ID - (shared_ion). Alternatively, with specifying tetrahedra_intersections, - the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks - for at least one pair of intersecting tetrahedra to identify if two objects - intersect or not. - - However, we found that these geometrical analyses can result in corner - cases which the currently used library (TetGen) was not unable to - tetrahedralize successfully. These cases were virtually always - associated with complicated non-convex polyhedra - which had portions of the mesh that were connected by almost point like - tubes of triangles. - - - - - - - - - Specifies if the tool should load the volume of each object - (if existent in the input file) to characterize the evolution of the - objects' volume as a function of set identifier (e.g. time). - - This and the has_object_composition option enables to activate - computations in the code which correlate the spatio-temporal tracking - with an object's properties. This is useful to explore/understand how - the object descriptor values evolve as a function of the parameterization - of the object. To arrive at a detailed understanding and quantification - of the differences of a given object as a function of delocalization and - e.g. iso-surfacing settings. - - The point made in M. Kühbach et al. 2022, is that this functionality - can be used to track for instance how the accumulated volume and - composition of an object depends on its segmentation via iso-surfaces. - The benefit of such computations is that users can inspect the - parameter sensitivity of an objects representation rigorously. - - - + - Specifies if the tool should load the composition of each object - (if existent in the input file) to characterize the evolution of the - object's composition as a function of set identifier. See the description - of has_object_volume for further details. In M. Kühbach et al. 2022, both - has_object options were used to characterize e.g. the parameter - sensitivity of computed composition, volume, and shape specifically, - for a carbide that was segmented via different carbon iso-composition - values. + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. - + - List of np.uint16 elements, via their proton number. The whitelist is - evaluated to compute the composition of an object during tracking - when has_object_composition is set to true. + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. - - - @@ -134,45 +68,141 @@ analyses the tool should execute as part of the analysis. - - + + + Tracking volume_volume_spatial_correlation is the process of building logical + relations between volumetric features based on meshes, their proximity and + eventual intersections. Volumetric overlap and proximity of volumetric + features is identified for members of sets of features to members of + other sets of volumetric features. + Specifically, for each time step k pairs of sets are compared: + Members of a so-called current_set to members of a so-called next_set. + Members can be different types of volumetric features. + In the analysis of M. Kuehbach et al. specifically features can be + so-called objects (closed non-degnerated polyhedra representing watertight + parts of an e.g. iso-surface) and/or proxies. Proxies are computed + doppelganger/replacement meshes for parts of an iso-surface which initially + were not resulting in watertight meshes because objects at the edge + of the dataset or incompletely measured or truncated objects. + + + + Specifies the method whereby to decide if two objects intersect volumetrically. + For reasons which are detailed in the supplementary material of + `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by + default assumes that two objects intersect if they share at least one + ion with the same evaporation ID (shared_ion). + Alternatively, with specifying tetrahedra_intersections, + the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks + for at least one pair of intersecting tetrahedra to identify if two objects + intersect or not. + + However, we found that these geometrical analyses can result in corner + cases which the currently used library (TetGen) was not unable to + tetrahedralize successfully. These cases were virtually always + associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + Finding more robust methods for computing intersections between + not necessarily convex polyhedra might improve the situation in the future. + + + + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) intersect volumetrically. + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) lie closer to one another than the + threshold_proximity. + + + + + Specifies if the tool evaluates, ones all tracking tasks were + successfully completed, how intersecting or proximity related + objects build sub-graphs. This is the feature which enabled + M. Kühbach et al. 2022 the high-throughput analyses of how many + objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order. For these analyses to work + has_object_volume needs to be activated. + + + + + The maximum Euclidean distance between two objects below which + both objects are still considered within proximity. + + + + + Specifies if the tool stores the so-called forward relations between + nodes representing members of the current_set to nodes representing + members of the next_set. + + + - For now a support field for the tool to identify how many individual - analyses (i. e. individual current_to_next mappings) the tool should - perform as part of the high-throughput analysis. + Specifies if the tool stores the so-called backward relations between + nodes representing members of the next_set to nodes representing + members of the current_set. - + - Tracking is the process of building logical relations between objects - based on proximity and mesh intersections. For each time step pairs - of sets are compared: members of a current_set and a next_set. - Members have to be objects and eventually can in addition be so-called - proxies. Objects and proxies are non-degenerated closed polyhedra which - are not necessarily convex. Proxies are doppelganger/replacement - meshes of objects which would otherwise be impossible to describe - with a closed mesh. + Current set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the current_set. + The meshes were generated as a result of some other meshing process. - + - Current set stores a set of object geometries that should be checked - for proximity and/or intersection with member of the next_set. + This identifier can be used to label the current set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in M. Kühbach + et al. 2022, this identifier takes the role of the time variable k. - + + + + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + current_set. + + + + - This identifier can be used to label the current set. The label - effectively represents the time/iteration step when the current - set was taken. As it is detailed in M. Kühbach et al. 2022, - this identifier takes the role of the time variable k. + Descriptive category explaining what these features are. + + + + + + - Name of the HDF5 file which contain geometry (vertex coordinates, - facet indices) and properties (ions, composition) of polyhedra - (l objects) which should be included in the current set. - The user has to ensure that the datasets under list_of_dataset_names - (vertices, facet_indices, ions) exist and are formatted consistently. + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. @@ -182,84 +212,69 @@ - - - Paraprobe-intersector loads triangulated surface mesh data of a - set of objects. For each object its mesh is expected to have - three-dimensional position data of the unique vertices and a - matrix of vertex indices which describe the faces. - As each object has to be a polyhedron/closed surface mesh, this - matrix has as many rows as faces, i.e. triangles and three columns. - Vertex indices have to start at zero. - - - - - The default intersection detection method uses shared ions. - Therefore, it is necessary to specify where the results from the - paraprobe-nanochem tool run are located which document which ions - (with their evaporation IDs) are inside or on the surface of each - object. This field points the tool to these evaporation IDs. - - - - - In order to correlate object properties like volume and composition - with tracking data, it is necessary to specify where the results - (object properties) from the paraprobe-nanochem tool run are located. - This field instructs the tool where to load these object property data - from. - - - - - Paraprobe-intersector does not just compare two objects but a set - of sets of objects. This field instructs the tool where to load - the identifiers (names) of each object in a current_set or next_set - respectively from. - - - - - Like groupname_object_geometry_data but for the proxies. - Triangulated surface meshes of proxies have to be formatted - in the same manner as objects. - - - + - Like groupname_proxy_supplementary_data but for the interior proxies. - Leave an empty string if proxies should not be used. + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object<ID>/polyhedron. - + - Like groupname_proxy_supplementary_data but for the exterior proxies. - Leave an empty string if proxies should not be used. + Array of identifier whereby the path to the geometry data + can be interferred automatically. - + + + + Next set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the next_set. + The meshes were generated as a result of some other meshing process. + + - Next set stores a set of object geometries that should be checked - for proximity and/or intersection with (each) member(s) of the - current_set. + This identifier can be used to label the next_set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in M. Kühbach + et al. 2022, this identifier takes the role of the time variable k+1. + + + + + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + next_set. - + + + - This identifier can be used to label the next set. Like for the current_set - the identifier is effectively the time/iteration step when the next set was taken. - As it is detailed in M. Kühbach et al. 2022, this identifier - takes the role of the time variable k+1. + Descriptive category explaining what these features are. + + + + + + - Name of the HDF5 file which contain geometry (vertex coordinates, - facet indices) and properties (ions, composition) of - polyhedra(l objects) which should be included in the current set. - The user has to ensure that the datasets that are referred to - under list_of_dataset_names (vertices, facet_indices, ions). + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. @@ -269,119 +284,23 @@ - - - Paraprobe-intersector loads triangulated surface mesh data of a - set of objects. For each object its mesh is expected to have - three-dimensional position data of the unique vertices and a - matrix of vertex indices which describe the faces. - As each object has to be a polyhedron/closed surface mesh - this matrix has as many rows as faces, i.e. triangles and - three columns. Vertex indices have to start at zero. - - - - - The default intersection detection method uses shared ions. - Therefore, it is necessary to specify where the results from the - paraprobe-nanochem tool run are located which document which ions - (with their identifiers) are inside or on the surface of each object. - This field instructs the tool where to load these - ion evaporation ids from. - - - - - In order to correlate object properties like volume and composition - with tracking data, it is necessary to specify where the results - (object properties) from the paraprobe-nanochem tool run are located. - This field instructs the tool where to load these object property - data from. - - - - - Paraprobe-intersector does not just compare two objects but a set - of sets of objects. This field instructs the tool where to load - the identifiers (names) of each object in a current or next set - respectively from. - - - - - Like groupname_object_geometry_data but for the proxies. - Triangulated surface meshes of proxies have to be formatted - in the same manner. Leave an empty string if proxies should not - be used. - - - + - Like groupname_proxy_supplementary_data but for the interior proxies. - Leave an empty string if proxies should not be used. + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object<ID>/polyhedron. - + - Like groupname_proxy_supplementary_data but for the exterior proxies. - Leave an empty string if proxies should not be used. + Array of identifier whereby the path to the geometry data + can be interferred automatically. - - - Specifies if, in the case of small finite datasets, objects which are - located at the edge of the dataset should be accounted for or not. - If these so-called proxy/doppelganger objects are accounted for, the - respective groupname_proxy and dataset_proxy fields have to be - filled to tell the tool where to load which proxy meshes from. - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) intersect volumetrically. - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) lie closer to one another than the - threshold_proximity. - - - - - Specifies if the tool evaluates, ones all tracking tasks were - successfully completed, how intersecting or proximity related - objects build sub-graphs. This is the feature which enabled - M. Kühbach et al. 2022 the high-throughput analyses of how many - objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order. For these analyses to work - has_object_volume needs to be activated. - - - - - The maximum Euclidean distance between two objects below which - both objects are still considered within proximity. - - - - - Specifies if the tool stores the so-called forward relations between - nodes representing members of the current_set to nodes representing - members of the next_set. - - - - - Specifies if the tool stores the so-called backward relations between - nodes representing members of the next_set to nodes representing - members of the current_set. - - + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml index 34f6168404..876cfcf8a3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -74,6 +74,13 @@ Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + ISO 8601 formatted time code with local time zone offset to @@ -947,6 +954,10 @@ normals of the facets. + + + + @@ -1001,5 +1012,8 @@ + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml index 84b97864e8..26985cac81 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml @@ -66,6 +66,13 @@ Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + How many task to perform? @@ -84,7 +91,7 @@ the tool execute as part of the analysis. - + @@ -243,6 +250,17 @@ + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.nxdl.xml new file mode 100644 index 0000000000..0af1328cc9 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.nxdl.xml @@ -0,0 +1,118 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration of a paraprobe-selector tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many roi_selection processes should the tool execute. + + + + + This process identifies which of the points/ions in the datasets are + inside or on the surface of geometric primitives and meet optionally + specific other filtering constraints. + A typical use case of a roi_selection is to restrict analyses to + specific regions of the dataset, eventually regions with a complicated + shape. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml index c0a76168cf..8b2fb9b708 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -64,6 +64,13 @@ Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + ISO 8601 formatted time code with local time zone offset to UTC @@ -144,6 +151,22 @@ and dataset_name_mass_to_charge respectively. + + + Threshold to define how large an ion has to lay at least far away + from the edge of the dataset so that the ion can act as a source, + i.e. that an ROI is placed at the location of the ion and its + neighbors are analyzed how they contribute to the computed statistics. + + The ion_to_edge_distances threshold can be combined with a threshold + for the ion_to_feature_distances. + Specifically, if ion_to_feature_distances are loaded an ion only + acts as a source if both threshold criteria are met. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + + @@ -163,122 +186,149 @@ ion-to-feature distance values for each ion. - - - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - - - - - - - - + - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. + Recall that the ion_to_feature_distances threshold is combined + with the ion_to_edge_distances threshold. - - - - - - - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - - - - - - - - - - + + + + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + + + + + + + + + + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + + + + + + + + + Specifies which spatial statistics to compute. + + - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. + Compute k-th nearest neighbour statistics. - - - - - - + + + Order k. + + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + - Specifies which spatial statistics to compute. + Compute radial distribution function. - + - Compute k-th nearest neighbour statistics. + Minimum value, increment, and maximum value of the histogram binning. - - - Order k. - - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml index 7c3878ed78..bd2762de92 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -10,6 +10,11 @@ Number of alpha values (and offset values) to probe. + + + How many different match values does the filter specify. + + Configuration of a paraprobe-surfacer tool run in atom probe microscopy. @@ -60,6 +65,13 @@ Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + For now a support field for the tool to identify how many individual @@ -111,9 +123,29 @@ - - - + + + + + + + + + + + + + + + + + + + + + + + @@ -148,8 +180,13 @@ Specifies which method to use to define the alpha value. - By default, the tool uses a fast specialized algorithm for - computing only the convex hull. + The value convex_hull_naive is the default. This instructs the tool + to use a fast specialized algorithm for computing only the convex + hull. The resulting triangles can be skinny. + + The value convex_hull_refine computes first also a convex_hull_naive + but refines the mesh by triangle flipping and splitting to improve + the quality of the mesh. The value smallest_solid instructs the CGAL library to choose a value which realizes an alpha-shape that is the smallest solid. @@ -169,7 +206,8 @@ resulting wrapping. - + + @@ -215,5 +253,8 @@ + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml index 9a62f065fb..b1112e28db 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -49,6 +49,13 @@ Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + ISO 8601 formatted time code with local time zone offset to UTC @@ -176,5 +183,8 @@ + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml index eb52a23f27..e594e3214c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -9,7 +9,7 @@ Configurations of a paraprobe-transcoder tool run in atom probe microscopy. - + Version specifier of this application definition. @@ -31,10 +31,10 @@ Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. + of ideally an ever persistent resource where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this computational + process is recreatable deterministically. @@ -49,6 +49,13 @@ Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + ISO 8601 formatted time code with local time zone offset to UTC @@ -59,37 +66,28 @@ - The absolute path and name of the vendor or community file from which - to read the reconstructed ion positions. Currently POS, ePOS, and APT - files from APSuite are supported. + The path and name of the file (technology partner or community format) + from which to read the reconstructed ion positions. Currently, POS, + ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files + are supported. - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - + - The absolute path and name of the vendor or community file from which - to read the ranging definitions, i.e. how to map mass-to-charge-state - ratios on iontypes. Currently RRNG and RNG files are supported. + The path and name of the file (technology partner or community format + from which to read the ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. + NeXus/HDF5 files are supported. - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.nxdl.xml new file mode 100644 index 0000000000..8fd679a516 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.nxdl.xml @@ -0,0 +1,410 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of entries in the restricted_identifier dictionary. + + + + + Results of a paraprobe-clusterer tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + + + + + + + + + The result of a cluster analyses. These include typically the label for + each ion/point documenting to which feature (if any) an ion is assigned. + Typically, each analysis/run yields only a single cluster. + In cases of fuzzy clustering it can be possible that an ion is assigned + to multiple cluster (eventually with different) weight/probability. + + + + Results of a DBScan clustering analysis. + + + + The epsilon (eps) parameter. + + + + + The minimum points (min_pts) parameter. + + + + + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset. Cardinality here is not the total number of ions in the + dataset. + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + + + + + The evaporation sequence identifier to figure out which ions + from the reconstruction were considered targets. + + + + + + + + The raw labels from the DBScan clustering backend process. + + + + + + + + The raw array of core sample indices which specify which of the + targets are core points. + + + + + + + + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the cluster_identifier. + + + + + + + + The array of weight which specifies how surely/likely the + cluster is associated/assigned to a specific identifier as + is specified in the cluster_identifier array. + For the DBScan and atom probe tomography the multiplicity + of each ion with respect to the cluster. That is how many times + should the position of the ion be accounted for because the ion + is e.g. a molecular ion with several elements or isotope of + requested type. + + + + + + + + Optional bitmask encoding if members of the set are assigned to as noise or not. + + + + + + + + Optional bitmask encoding if member of the set are a core point. + For details to which feature/cluster an ion/point is a core point + consider numerical_label. + + + + + + + + In addition to the detailed storage which members was grouped to + which feature/group summary statistics are stored under this group. + + + + Total number of members in the set which are categorized as noise. + + + + + Total number of members in the set which are categorized as a core point. + + + + + Total number of clusters (excluding noise and unassigned). + + + + + Array of numerical identifier of each feature (cluster). + + + + + + + + Array of number of members for each feature. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.nxdl.xml new file mode 100644 index 0000000000..a32c6b8d1f --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.nxdl.xml @@ -0,0 +1,354 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of triangles in the set. + + + + + Results of a paraprobe-distancer tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + The tool can be used to compute the analytical distance of each ion + to a set of triangles. + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of the triangles in the set + were considered. Usually these are all but sometimes users may + wish to filter certain portions of the triangles out. + + + + Number of triangles covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + The closest analytical distance of the ions to their respectively + closest triangle from the triangle set. + + + + + + + + A bitmask which identifies which of the distance values + can be assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + For points whose bit is set 0 the distance is correct but the + sign is not reliable. + + + + Number of triangles covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. + + + + + + + + + The identifier of the triangle that is closest for each ion. + + + + + + + + A support field to visualize each ion and with this the distance + informations using XDMF and e.g. Paraview. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.nxdl.xml new file mode 100644 index 0000000000..e747b8b5a1 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.nxdl.xml @@ -0,0 +1,356 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of links pointing from current to next. + + + + + The total number of links pointing from next to current. + + + + + The total number of members in the current_set. + + + + + The total number of members in the next_set. + + + + + The total number of cluster found for coprecipitation analysis. + + + + + The number of rows in the table/matrix for coprecipitation stats. + + + + + Results of a paraprobe-intersector tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this results file was created. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + The results of an overlap/intersection analysis. + + + + A matrix of feature_identifier which specifies which named features + from the current set have directed link(s) pointing to which named + feature(s) from the next set. + + + + + + + + + For each link/pair in current_to_next a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + + + + + + + + A matrix of feature_identifier which specifies which named feature(s) + from the next set have directed link(s) pointing to which named + feature(s) from the current set. Only if the mapping whereby the + links is symmetric next_to_current maps the links in current_to_next + in the opposite direction. + + + + + + + + + For each link/pair in next_to_current a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + + + + + + + + For each pair of links in current_to_next the volume of the + intersection, i.e. how much volume do the two features share. + If features do not intersect the volume is zero. + + + + + + + + During coprecipitation analysis the current and next set are analyzed + for links in a special way. Three set comparisons are made. Members + of the set in each comparison are analyzed for overlap and proximity: + + The first comparison is the current_set against the current_set. + The second comparison is the next_set against the next_set. + The third comparison is the current_set against the next_set. + + Once the (forward) links for these comparisons are ready the + pair relations are analyzed with respect to which feature identifier + cluster in identifier space. Thereby a logical connection (link) is + established between the features in the current_set and next_set. + Recall that these two set typically represent different features + within an observed system for otherwise the same parameterization. + Examples include two sets of e.g. precipitates with differing + chemical composition that were characterized in the same material + volume representing a snapshot of an e.g. microstructure at the same + point in time. Researchers may have performed two analyses, one to + characterize precipitates A and another one to characterize percipitates + B. Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + precipitates spatial arrangement. + + + + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the current_set. + + + + + + + + + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the next_set. + + + + + + + + + The identifier (names) of the cluster. + + + + + + + + Pivot table as a matrix. The first column encodes how many + members from the current_set are in each cluster, one row per cluster. + The second column encodes how many members from the next_set are + in each cluster, in the same row per cluster respectively. + The last column encodes the total number of members in the cluster. + + + + + + + + + Pivot table as a matrix. The first column encodes the different + types of clusters based on their number of members in the sub-graph. + The second column encodes how many clusters with as many members + exist. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.nxdl.xml new file mode 100644 index 0000000000..abf2722d3f --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -0,0 +1,1855 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of atoms in the atomic_decomposition match filter. + + + + + The total number of isotopes in the isotopic_decomposition match + filter. + + + + + The dimensionality of the delocalization grid. + + + + + The cardinality/total number of cells/grid points in the + delocalization grid. + + + + + The total number of XDMF values to represent all faces of triangles + via XDMF. + + + + + The total number of entries in a feature dictionary. + + + + + The total number of member distinguished when reporting composition. + + + + + Results of a paraprobe-nanochem tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + + + + + + + + + + + The weighting model specifies how mark data are mapped to a weight + per point/ion. For atom probe microscopy (APM) mark data are e.g. + which iontype an ion has. As an example, different models are used + which account differently for the multiplicity of a point/ion + during delocalization: + + * unity, all points/ions get the same weight 1. + * atomic_decomposition, points get as much weight as they + have atoms of a type in atomic_decomposition_rule, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotopic_decomposition_rule. + + + + + + + + + + A list of elements (via proton number) to consider for the + atomic_decomposition weighting model. + Elements must exist in the periodic table of elements and be + specified by their number of protons. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + In the case of elements this hashing rule has the advantage + that for elements the proton number is their hash value because + N is zero. + + + + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + + + + + + + + + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + + + + + + + + + A list of isotopes (via proton and neutron number) to consider + for the isotopic_decomposition weighting model. + Isotopes must exist in the nuclid table. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + + + + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + + + + + + + + + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + + + + + + + + + How results of the kernel-density estimation were computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + + + + + + + + + + + Weighting factor, in atom probe, often termed multiplicity. + The weighting factor is the multiplier with which the integrated + intensity contribution from the point/ion gets multiplied. + The delocalization computes the integrated intensity for each + grid cell. Effectively, this is an explicitly evaluated kernel + method where each specific position of an ion is replaced by a + smoothing kernel. For atom probe weights are positive and integer + specifically the multiplicity of the ion, in accordance with the + respective rulesets as defined by weighting_model. + + + + + + + + The discretized domain/grid on which the delocalization is applied. + + + + + + + + + + + The total number of cells/voxels of the grid. + + + + + + + + + + The symmetry of the lattice defining the shape of the unit cell. + + + + + + + + The unit cell dimensions according to the coordinate system + defined under coordinate_system. + + + + + + + + Number of unit cells along each of the d unit vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Integer which specifies the first index to be used for + distinguishing identifiers for cells. Identifiers are defined + either implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + A tight axis-aligned bounding box about the grid. + + + + For atom probe should be set to true. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + The result of the delocalization based on which subsequent + iso-surfaces will be computed. In commercial software so far + there is not a possibility to export such grid. + + + + + + + + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + Intensity of the field at given point + + + + + + + + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + + + + + + + + + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + + + + + + + + + The three-dimensional gradient nabla operator applied to + scalar_field_magnitude. + + + + + + + + + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + The gradient vector. + + + + + + + + + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + + + + + + + + + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + + + + + + + + + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. + + + + + + + + Sigma of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + Expectation value of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + + An iso-surface is the boundary between two regions across which + the magnitude of a scalar field falls below/exceeds a threshold + magnitude phi. + For applications in atom probe microscopy the location and shape + of such a boundary (set) is typically approximated by + discretization. + This yields a complex of not necessarily connected geometric + primitives. Paraprobe-nanochem approximates this complex with + a soup of triangles. + + + + + The threshold or iso-contour value. + + + + + Details about the specific marching cubes algorithm + which was taken to compute the iso-surface. + The grid is the delocalization grid. + + + + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. + + + + + + The resulting triangle soup computed via marching cubes. + + + + + + Integer which specifies the first index to be used for + distinguishing triangles. Identifiers are defined either + implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + + + + + + Number of vertices. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + + + + + + + Direction of each normal. + + + + + + + + + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + Direction of each normal. + + + + + + + + + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :mathref:`$\sum_{x, y, z} {\nabla{c}_i}^2$`. + + + + + + + + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose projection is almost perpendicular. + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. + + + + + + + + + The center of mass of each triangle. + + + + + + + + + + Iso-surfaces of arbitrary scalar three-dimensional fields + can show a complicated topology. Paraprobe-nanochem can run + a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup. This yields a + set of connected features with their surfaces discretized + by triangles. Currently, the tool distinguishes at most + three types of features: + + 1. So-called objects, i.e. not necessarily watertight features + convex polyhedra + 2. So-called proxies, i.e. features that were replaced by a + proxy mesh and made watertight. + 3. Remaining triangle surface meshes of arbitrary shape and + cardinality. + + These features can be interpreted as microstructural features. + Some of them may be precipitates, some of them may be poles, + some of them may be segments of dislocation lines or other + crystal defects which are decorated (or not) with solutes. + + Each type of feature needs to be registered in the feature_type + dictionary. Type identifiers (keywords are integer), values + are human-readable names like object, proxy, undefined + + + + The identifier which the triangle_soup connectivity analysis + returned, which constitutes the first step of the + volumetric_feature identification process. + + + + + + + + The array of keywords of feature_type dictionary. + + + + + + + + The array of values for each keyword of the + feature_type dictionary. + + + + + + + + The array of controlled keywords, need to be from + feature_type_dict_keyword, which specify which type + each feature triangle cluster belongs to. + Keep in mind that not each feature is an object or proxy. + + + + + + + + The explicit identifier of features. + + + + + + + + Details for features which are (closed) objects. + Identifier have to exist in feature_identifier + `:mathcal:$identifier \in feature_identifier$`. + + + + + + + + + + + + + + An oriented bounding box (OBB) to each object. + + + + Edge length of the oriented bounding box from largest + to smallest value. + + + + + + + + + Oriented bounding box aspect ratio. YX versus ZY. + + + + + + + + + Position of the geometric center, which often is but + not necessarily has to be the center_of_mass of the + hexahedrally-shaped sample/sample part. + + + + + + + + + A simple approach to describe the entire set of hexahedra + when the main intention is to store the shape of the + hexahedra for visualization. + + + + + + + + + + + + + + + + + + + + + + Details for all those objects close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + + + Count or weight which, when divided by total, + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + Details for all those objects far from edge, i.e. those + whose ions lay all at least threshold distant from a + modelled edge of the dataset. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + + + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + + Details for features which are so-called proxies, i.e. objects + which have been reconstructed and combinatorially closed with + processing their partial triangulated_surface_mesh + (hole filling, refinement). + Identifier have to exist in feature_identifier + `:mathcal:$identifier \in feature_identifier$`. + + + + + + + + + + + + + + Details for those proxies close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + Identifier have to exist in feature_identifier + `:mathcal:$identifier \in feature_identifier$`. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + Details for those proxies far from edge, i.e. those whose + ions lay all at least threshold distant from a + modelled edge of the dataset. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + + + + + + + + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + + + + + + + + The multiplicity whereby the ion position is accounted + for when the ion is considered´one which is a decorator + of the interface. + + + + + + + + The equation of the plane that is fitting initially. + + + + + The four parameter ax + by + cz + d = 0 which define the plane. + + + + + + + + The triangle surface mesh representing the interface model. + Exported at some iteration before the next DCOM step. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + + The triangle surface mesh representing the interface model. + Exported at some iteration after the next DCOM step. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + + + + The ROIs are defined as cylinders for the computations. + To visualize these though we discretize them into regular n-gons. + Using for instance a 360-gon, i.e. a regular n-gon with 360 + edges resolves the lateral surface of each cylinder very finely + so that they are rendered smoothly in visualization software. + + + + + + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + ROI cylinder. Identifiers are defined explicitly. + + + + + + + + + + + + + + The number of atoms in each ROI. + + + + + + + + The number of ions in each ROI. + + + + + + + + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. + + + + + + + + + + In the direction of the ROI. + + + + + Hashvalue + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml index adfe091c0f..cb36afdec4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml @@ -10,16 +10,17 @@ The total number of ions in the reconstruction. - + - The maximum number of atoms per molecular ion type. + Maximum number of allowed atoms per (molecular) ion (fragment). Needs + to match maximum_number_of_atoms_per_molecular_ion. - Results of a paraprobe-ranger tool run in atom probe microscopy. + Results of a paraprobe-ranger tool run. - + Version specifier of this application definition. @@ -59,15 +60,23 @@ Possibility for leaving a free-text description about this analysis. - + ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. - The absolute path and name of the config file for this analysis. + The path and name of the config file for this analysis. @@ -76,6 +85,30 @@ + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + If used, contact information and eventually details @@ -98,10 +131,11 @@ - The individual coordinate systems which used. - fields should be prefixed with a prefix taken from an - enumeration which details the individual coordinate systems: + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + * paraprobe * lab * specimen * laser @@ -112,14 +146,25 @@ - + Paraprobe-ranger loads the iontypes and evaluates for each ion on which iontype it matches. If it matches on none, the ion is considered of the default unknown type with a 0 as its respective value in the iontypes array. - + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + @@ -128,12 +173,80 @@ The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. + order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + is build are considered. By contrast, charged_iontypes takes + into account also the charge state. + + + + + + + + The iontype ID for each ion that was best matching, stored in the + order of the evaporation sequence ID. For the here computed + charged_iontypes the information for each (molecular) ion defined + in e.g. RNG or RRNG files is analyzed for which differently charge + states are possible. As an example while iontypes might only consider + if an ion is Al charged_iontypes will resolve if it is Al1+, Al2+, or + Al3+. To decide the charge state a recursive algorithm is used which + enumerates first all possible isotopic variants of a given molecular + ion build from a specific set of elements. All variants are then + analyzed for their natural abundance and filtered. The sub-set of + all significantly abundant variants is inspected if their charge + states are all the same. If only one significant variant is found + its charge state is assumed the relevant. If multiple significant + variants are found and all their charge states is the same this + charge state will be the decisive one. However, if multiple variants + are found and their charge state differs such a case highlights that + the charge state analysis is underconstrained and thus the charge + state is set to 0. Underconstrained cases are possible because + an arbitrary combination of elements into a molecular ion that is + constrained only by an additional single interval of mass-to-charge + state ratios is not necessarily sufficient. + + + A bitmask which identifies exactly all those ions ranged irrespective + the type they ended up with. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + @@ -215,8 +328,30 @@ + + + Paraprobe-ranger loads iontypes and evaluates for each ion on which + iontype it matches. If it matches on none, the ion is considered of + the default unknown type with a 0 as its respective value in the + iontypes array. In contrast to use_existent_ranging this process + does neither needs measured ion position nor mass-to-charge-state + ratio values. + + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + - + + @@ -271,13 +406,13 @@ - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.nxdl.xml new file mode 100644 index 0000000000..1b77a54689 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Results of a paraprobe-selector tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + A bitmask which identifies which of the ions in the dataset + were selected to become included in the region-of-interest (ROI). + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.nxdl.xml new file mode 100644 index 0000000000..87470cebe4 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.nxdl.xml @@ -0,0 +1,317 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Results of a paraprobe-spatstat tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + The iontype ID for each ion that was assigned to each ion during + the randomization of the ionlabels. Iontype labels are just permuted + but the total number of values for each iontype stay the same. + + The order matches the iontypes array from a given ranging results + as is specified in the configuration settings inside the specific + config_filename that was used for this spatstat analysis. + + + + + + + + K-nearest neighbor statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated + + + + + + + + + Radial distribution statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.nxdl.xml new file mode 100644 index 0000000000..187d0ec526 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.nxdl.xml @@ -0,0 +1,471 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The number of vertices of the alpha complex. + + + + + The number of faces of the alpha complex. + + + + + The total number of XDMF values to represent all faces of triangles + via XDMF. + + + + + The total number of XDMF values to represent all faces of tetrahedra + via XDMF. + + + + + Results of a paraprobe-surfacer tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. Computations of alpha complexes may have filtered this + ion set further but this process is deterministic. + + + + Number of ions covered by the mask. The mask may be 0 for most. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. + + + + + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + the alpha complex was then in fact computed. This window + can be different to the entire window as irrelevant ions might + have been filtered out to reduce the computational costs of the + alpha complex analysis. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. + + + + Integer which specifies the first index to be used for distin- + guishing triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined + on the interval [identifier_offset, identifier_offset+c-1]. + + + + + + + Number of vertices. + + + + + Number of faces. + + + + + + + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + + + + + + + Do the triangles define a triangulated surface mesh which + is watertight? + + + + + The volume which the triangulated surface mesh encloses + provided that the mesh is watertight. + + + + + + The set of tetrahedra which represent the interior volume of the + complex if that is a closed 2-manifold. + + + + Integer which specifies the first index to be used for distin- + guishing tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined + on the interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + The accumulated volume of all interior tetrahedra. + + + + + + Number of vertices. + + + + + Number of faces. + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). + + + + + + + + + + + + In the future we may want to wrap other primitives + like triangles or polylines. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.nxdl.xml new file mode 100644 index 0000000000..6a90e5ac71 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.nxdl.xml @@ -0,0 +1,632 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of facets/polygons defining the tessellation. + + + + + Results of a paraprobe-tessellator tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + The tool can be used to compute a Voronoi tessellation the entire + or a sub-set of the reconstruction. The point cloud in the ROI is + wrapped into a tight axis-aligned bounding box. The tool detects if + Voronoi cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by the global axis-aligned bounding box, i.e. boundaries + of the threads are ignored. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative x axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The right wall has the positive x axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The front wall has the negative y axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The rear wall has the positive y axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative z axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the positive z axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + Interior volume + + + + + + + + By which MPI process was the Voronoi cell computed. + + + + + + + + By which OpenMP thread was the Voronoi cell computed. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + A simple approach to describe the entire set of polyhedra when + the main intention is to store the shape of the polyhedra for + visualization. + + + + + Number of vertices. + + + + + Number of faces. + + + + + + + + + + + + + A sequence of always first an XDMF topology type key, followed + by the XDMF number of vertices of the polygon, followed by + the vertex identifier which define the facet polygon. First + we store the polygon of the first facet of the first cell, then + the second facet of the first cell, until the last facet of the + first cell, followed by the first facet of the second cell, + and so on and so forth. + + + + + + + + A sequence of cell identifier so that each facet is associated + with its cell because of which it is then possible to segment + out cells three-dimensionally based on cell i.e. evaporation_id. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml new file mode 100644 index 0000000000..5314b30dae --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). Needs + to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals mapped on this ion + type. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Results of a paraprobe-transcoder tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + + + + + + + + + On a mid term perspective we would like to evolve the paraprobe-toolbox + to an implementation stage where it works exclusively with completely + provenance-tracked formats for both the configuration of the workflow step + and/or analysis with each tool and also for the output of these analyses + in the form of so-called tool-specific results files. + Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. + + Different file formats can be used to inject reconstructed datasets and + ranging definitions into the toolbox. Traditionally, these are the POS, + ePOS, and APT files with the tomographic reconstruction and other metadata + and RNG and RRNG file formats for the ranging definitions how mass-to-charge + state-ratio values map on (molecular) ion types. Such input should be + injected via specific NeXus/HDF5 files which are documented + in compliance with the NXapm application definition. + + So far the paraprobe-toolbox was used as a standalone tool. Therefore, it + was not relevant during the development to focus on interoperability. + Essentially paraprobe-transcoder was used as a parser to transcode data + in the above-mentioned file formats into a paraprobe-specific + representation. This transcoding should become deprecated. + Here we describe steps we have taken into this direction. + + With the work in the FAIRmat project and the desire to make the paraprobe- + toolbox also accessible as a cloud-computing capable service in the Nomad + Remote Tools Hub (NORTH) the topic of interoperability became more important + and eventually the NXapm application definition was proposed. + NORTH is a GUI and related service in a NOMAD OASIS instance which allows + to spawn preconfigured docker containers via JupyterHub. + Currently, NORTH includes the so-called apm container. A container with + tools specific for analyzing data from atom probe microscopy as well as + processing of point cloud and mesh data. + + The NXapm application definition and related implementation work within + NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and + RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook + solutions directly into NOMAD OASIS via the uploads section. + The process is automated and yields an NXapm-compliant NeXus/HDF5 file + inside the uploads section in return. + + With these improvements made there is no longer a need for - at least the + users of a NOMAD OASIS and NORTH instance to use the deprecated + PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should + automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 + file and in response work with this file directly. + To remain compliant with users however who do not have or do not wish + to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is + as follows: + + Calling the configuration stage of paraprobe-transcoder is always mandatory. + It is always the first step of working with the toolbox. In this process + the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ + HDF5 file from e.g. the upload section, or such a file that was obtained from + a colleague with a NOMAD OASIS instance. + In all other cases, users can pass the reconstruction and ranging definitions + using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. + + Based on which input the user delivers, the parmsetup-transcoder tool then + creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and + informs the user whether the input was NeXus (and thus if all relevant + input is already available) or whether the paraprobe-transcoder tool needs + to be executed to convert the content of the vendor files first into a + format which paraprobe can provenance track and understand. + In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is + used to communicate to all subsequently used tools from which files + the tools can expect to find the reconstruction and ranging definitions. + + All subsequent analysis steps start also with a tool-specific configuration. + This configuration step reads in (among others) the + PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration + tool identifies automatically whether to read the reconstruction and ranging data + from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant + NeXus/HDF5 file that was created upon preparing the upload or the file shared + from a colleague. This design removes the need for unnecessary copies of the data. + Currently still though users should execute the transcoder step as it will + generate a supplementary XDMF topology field with which the data in either + the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. + Paraview. For this purpose XDMF is used. + + Of course ideally the APT community would at some point converge to use + a common data exchange file format. To this end, AMETEK/Cameca's APT file format + could be a good starting point but so far it is lacking a consistent way of + how to store generalized ranging definitions and post-processing results. + POS, ePOS, Rouen's ATO, as well as other so far used representations of data + like CSV or text files have, to the best of our current knowledge, no + concept of how to marry reconstruction and (optional) ranging data into + one self-descriptive format. + + This summarizes the rationale behind the current choices of the I/O for + paraprobe. Furthermore, this summarizes also why the fundamental design + of splitting an analysis always into steps of configuration (with parmsetup), + task execution (with the respective C/C++ or Python tool of the toolbox), + and post-processing (e.g. with autoreporter) is useful because it offers + a clear description of provenance tracking. This is a necessary step to make + atom probe microscopy data at all better aligned with the aims of the + FAIR principles. + + The internal organization of the data entries in the atom_probe group + in this application definition for paraprobe-transcoder results files + mirror the definitions of the NXapm for consistency reasons. + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/nyaml/NXcg_alpha_complex.nxdl.xml new file mode 100644 index 0000000000..65a20d31c6 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_alpha_complex.nxdl.xml @@ -0,0 +1,99 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the alpha shape, for now 2 or 3. + + + + + The number of edges. + + + + + The number of faces. + + + + + The number of cells. + + + + + Computational geometry description of alpha shapes or wrappings to primitives. + + For details see: + + * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, + * https://dx.doi.org/10.1145/174462.156635 for 3D, + * https://dl.acm.org/doi/10.5555/871114 for weighted, and + * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap + + in CGAL, the Computational Geometry Algorithms Library. + As a starting point, we follow the conventions of the CGAL library. + + + + + + + + + + Specify which general type of alpha shape is computed. + Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. + Alpha_wrapping means meshes created using alpha wrapping procedures. + + + + + + + + + + Specifically when computed with the CGAL, the mode specifies if singular + faces are removed (regularized) of the alpha complex. + + + + + + + + + The alpha, (radius of the alpha-sphere) parameter to be used for alpha + shapes and alpha wrappings. + + + + + The offset distance parameter to be used in addition to alpha + in the case of alpha_wrapping. + + + + + Point cloud for which the alpha shape or wrapping should be computed. + + + + + Triangle soup for which the alpha wrapping should be computed. + + + + + A meshed representation of the resulting shape. + + + + diff --git a/contributed_definitions/nyaml/NXchemical_composition.nxdl.xml b/contributed_definitions/nyaml/NXchemical_composition.nxdl.xml new file mode 100644 index 0000000000..4d05f3b46b --- /dev/null +++ b/contributed_definitions/nyaml/NXchemical_composition.nxdl.xml @@ -0,0 +1,44 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of samples or things. + + + + + (Chemical) composition of a sample or a set of things. + + + + Total based on which composition information is normalized. + + + + + + + + + Count or weight which, when divided by total yields the composition + of this element, isotope, molecule or ion. + + + + + + + + Count divided by total in atom percent. + + + + + + + diff --git a/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml b/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml index 8877494263..c498d07755 100644 --- a/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml @@ -48,6 +48,11 @@ references to e.g. more detailed performance data to which they wish to link the metadata in this base class. + + + Path to the directory from which the tool was called. + + Command line call with arguments if applicable. diff --git a/contributed_definitions/nyaml/NXem.nxdl.xml b/contributed_definitions/nyaml/NXem.nxdl.xml index e044a10c31..526bf94bd3 100644 --- a/contributed_definitions/nyaml/NXem.nxdl.xml +++ b/contributed_definitions/nyaml/NXem.nxdl.xml @@ -279,9 +279,10 @@ research data management systems to show a visual representation of some aspect of the content of the EM session. Default plottables not intended to serve every possible analysis and - visualization demand but be a preview. We made this choice because what constitutes - a useful default plot is often a matter of interpretation, somewhat of personal taste, - and community standards. In effect, default plottables are case- and method-specific. + visualization demand but be a preview. We made this choice because what + constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. Usually a session at a microscope is used to collect multiple signals and images. Examples for possible default plottables could be arbitrarily @@ -304,16 +305,16 @@ field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) * Spectra (X-ray quanta or Auger electron counts) * These data are in virtually all cases a result of some numerical processing. - It makes sense to name these data and processing tasks with a controlled vocabulary, - e.g. SE (secondary electron), BSE (back-scattered electron), Kikuchi, - X-ray, Auger, Cathodolum(inescence) etc. + It makes sense to name these data and processing tasks with a controlled + vocabulary, e.g. SE (secondary electron), BSE (back-scattered electron), + Kikuchi, X-ray, Auger, Cathodolum(inescence) etc. A key question often asked with EM experiments is how the actual (meta)data should be stored (in memory or on disk). To this end the schema, here makes no specific assumptions, not even that all the fields/group of a schema instance have to be stored at all into a single file. Instead, the schema specifies the - relations between metadata, some of the constraints and conditions on how the data - should be formatted, what the data conceptually represent, and which terms + relations between metadata, some of the constraints and conditions on how the + data should be formatted, what the data conceptually represent, and which terms (controlled vocabulary) is practical to store to index specific quantities. In effect, the application definition is a graph which describes how @@ -360,7 +361,7 @@ when the microscope session started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact - duration is not relevant - this start time field should be used. + duration is not relevant - this start_time field should be used. Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and @@ -462,7 +463,8 @@ Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform @@ -541,15 +543,16 @@ was placed into the microscope at the beginning of the session. In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a sub-set - of the entire sample history, i.e. what you would consider are the key steps - and relevant information about the specimen, its material, microstructure, - thermo-chemo-mechanical processing state, and the details of the preparation. + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. Specific details about eventual physically-connected material like embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly discouraged - because it leads to eventually non-machine-actionable + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable data. @@ -560,8 +563,8 @@ Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over for - the analysis. At the point it enters the microscope the session starts. + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. At the point it enters the microscope the session starts. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as @@ -578,11 +581,14 @@ - Use Hill's system for listing elements of the periodic table which are inside or attached - to the surface of the specimen and thus relevant from a scientific point of view. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. - The purpose of the field is to offer materials database systems an opportunity to parse - the relevant elements without having to interpret these from the sample history. + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. @@ -596,12 +602,6 @@ surface normal of the specimen is parallel to the optical axis. - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - (Measured) density of the specimen. For multi-layered specimens this @@ -613,6 +613,12 @@ of the specimen. + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + @@ -621,7 +627,7 @@ - + @@ -639,8 +645,8 @@ For example it is not relevant to store in each event's electron_gun group again the details of the gun type and manufacturer but only the high-voltage if for that event the high-voltage was different. If for all events - the high-voltage was the same it is not even necessary to include an electron_gun - section in the event. + the high-voltage was the same it is not even necessary to include an + electron_gun section in the event. Individual sections of specific type should have the following names: @@ -666,35 +672,51 @@ + + + + + + - + + + + + + + - + + + - + If the lens is described at least one of the fields voltage, current, or value should be defined. + + @@ -705,6 +727,8 @@ + + @@ -726,23 +750,30 @@ + + + + - - + + + + + @@ -760,14 +791,18 @@ - + + + - + + + @@ -780,7 +815,7 @@ - + Description of the type of the detector. @@ -801,6 +836,8 @@ + + @@ -929,21 +966,168 @@ instance called ebsd_camera. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - + @@ -956,7 +1140,7 @@ - + @@ -977,10 +1161,10 @@ - - - + + + @@ -1009,7 +1193,7 @@ - + diff --git a/contributed_definitions/nyaml/NXem_ebsd.nxdl.xml b/contributed_definitions/nyaml/NXem_ebsd.nxdl.xml new file mode 100644 index 0000000000..d5c4c33887 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_ebsd.nxdl.xml @@ -0,0 +1,875 @@ + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a + rediscretized, i.e. standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Application definition for indexing Kikuchi pattern into orientation maps. + + For so-called three-dimensional or serial sectioning EBSD it is necessary to + follow a sequence of specimen, surface preparation, and data collection steps. + Results from individual measurements are combined into one reconstructed stack. + In this case, users should collect the data for each serial sectioning step + via an own instance of NXebsd. To report the resulting post-processing of this + set of EBSD (and/or orientation per scanned material point) users should use + an instance of the NXms application definition. This application definition + enables users to describe three-dimensional microstructures and features + identified in these microstructures. The term microstructure is used here + but is not restricted to features at the micron scale. + Eventual tomography methods also use such a workflow because first diffraction + images are collected and then these are indexed and composed into a 3D + orientation mapping. The here proposed NXebsd application definition can + give some conceptual ideas how this splitting between measurement and + post-processing can be granularized also for these techniques. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Commercial, parser, or otherwise given name to the program + which was used to process the workflow. + + + + Program 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. + + + + + + Optional contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + An inspection of the availability of EBSD datasets with an open-source + license stored on public archive services like Zenodo revealed during + the implementation of a generic parser for EBSD data that such data are + in most cases stored in two ways: Case one was via a file in format used + by technology partners. This file contains result of an on-the-fly + executed indexing, i.e. processing of the Kikuchi pattern into scan point + positions, indexing solutions per scan point, and some quality descriptors + for the solutions as well as crystal structure and phase metadata. + Case two were raw pattern in some custom format often without a detailed + description of what the individual fields and data arrays resolve + except for some references to publications. + Therefore, we first need to collect how these files have been + generated. Ideally one would do so by creating a complete set of + information via e.g. NXem that could then be used via reading from + the information in the measurement group (see below) of this application + definition. However, in most cases this is not available. + + Therefore, this group stores key metadata about which results file + contain the EBSD mapping and which software was used (software name + and version with build number). These pieces of information support + the interpretation of specific metadata in these results file which + currently cannot or be interpreted completely or conceptually uniquely. + + Thereby this NXem_ebsd application definition solves two key documentation + tasks which are so far missing in the EBSD community. An instance + of the application definition (e.g. a NeXus/HDF5 file formatted according + to this application definition) stores the connection between the + microscope session and thus the sample and microscope settings, and + Kikuchi pattern, overview images etc. Furthermore, this application definition + connects these data to the conventions used, and the results file + which would otherwise also be ripped out of their context when using + many traditional procedures where EBSD data are indexed on-the-fly + and shared by just sharing the results file in the technology partner + specific formatting. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing. This is the usual production workflow + how scanning electron microscopes are used when collecting + EBSD data. + + + + Program version plus build number, commit hash, or other description + of an ever persistent resource where the source code of the program and + build instructions can be found or at least more information about the + program in this version can be found. If all such information is not + available, like for commercial software, here the version number + and build number should be named. Use semantic versioning if possible. + + + + + + Name of the results file. + + + + Hash of that file. + + + + + + + Connection between the measurement of the Kikuchi pattern and the + processing of these into an orientation microscopy image. + + + + Name or link to an existent instance of an EBSD raw dataset inside an + NXem which has at least one NXimage_set_em_kikuchi instance. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the field in the EBSD community is that many of the metadata + fields are not in all cases fully documented. In addition, it is common + practice in the research field of EBSD that users transcode their raw + data into other formats so that these data can be interpreted by + specific software tools including commercial software from technology + partners other than the one which delivered the system that was e.g. + used when the raw data were collected. + As many of the file formats are not designed to communicate also then + the specifically and most importantly the eventually different context + of the metadata, we have opted for the first iteration of the implementation + to discard these metadata. + + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions, should not be our authority and necessarily + demands profits from feedback from the technology partners we have + opted for this intermediate approach. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + The EBSD system, that is the electron gun, pole-piece, stage tilting, + and EBSD detector, as well as the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, + the gnomonic projection has to be calibrated. + + In most practical cases, especially in engineering, there is a substantial + larger number of sessions where such a calibrated system is used + rather than recalibrated. + + In the first case the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software is well calibrated. Consequently, users only pick + from an existent library of NXem_ebsd_crystal_structure_model + instances and use them to measure and index their data on-the-fly. + As a result an indexing is performed after/between the beam scanning + the specimen (depends on configuration). + Specifically, users load their specimen, typically create a coarse image + of the surface, set an approximate value for the calibrated working distance + then tilt, configure the microscope for collection quality data, then + configure the settings used for the calibrated EBSD system, pick one or + multiple ROIs and then measure (nowadays this is virtually always an + automated process which is in most cases unsupervised, running within the + allocated microscope session time slot, data are indexed on-the-fly, and + results file often automatically copied and/or archived in certain places. + The result of such an EBSD measurement is a set of usually proprietary + or open files from technology partners (EBSD system and microscope + manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. + + + + A link/cross reference to an existent instance of NXebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientations. Fundamentally different algorithms + can be used to index EBSD/EBSP pattern. + + Pattern indexing is comparing of diffraction pattern, measured + against assumed or simulated pattern. Quality descriptor are defined + based on which an indexing algorithms yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Dictionary-based indexing methods are most increasingly becoming used also. + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + Binning i.e. downsampling of the pattern. + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + + + + + + Overview + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase interpolated on a rectangular/cuboidal domain with square + pixels/voxels and the orientations colored according + to the coloring scheme used in the respective ipf_color_modelID/program. + + Most importantly as the parser is not performing the inverse pole figure + mapping it requires that this computation is stored inside the results_file + that is referred to under commercial_on_the_fly_indexing. + This example clearly shows the key limitation that is when the computational + steps of collecting the raw data and post-processing these with some + custom scripts like MTex or commercial tools. The limitation is that + the program which consumes this file, here the parser of the research + data management system, has not necessarily sufficient information + available to check if the injected orientation data and color models + are matching the conventions which get injected from the electronic + lab notebook into an instance of this application definition, such + as a NeXus/HDF5 file that is formatted according to NXem_ebsd. + + Ideally, the parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientations + eventually. Thereafter, convention-compliant default plot(s) could + be created and served for purposes of data exploration within the RDMS. + + Given the variety of post-processing tools used for EBSD however, and + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option because + at least one developer who would pursue such task would first have to + create a library for performing such tasks for the parser. + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies different players in the field have + implemement slightly different approaches each of which misses + one consistent view of the entire workflow that is EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The default plot does so far not + yet apply relevant rotations but takes the orientation + values as. Ideally with all conventions defined it can + be possible to develop a converter which rotates the + input data but this is here not yet assumed to happen. + + The key point is that the conventions however are captured + first of all because then such conversions for improving + interoperability can be achieved. + + This default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created. + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the beam + illuminates certain positions for a certain amount time (usually equally- + spaced and same time spent at each position). + + Scan positions can be such regular flight plans mapping lines, + line stacks, rectangular regions-of-interests, but also could instruct + spiral, random, or adaptive scans instead of square or hexagon grids. + + The majority of EBSD maps is reporting results for a regular grid + (square, hexagon). What matters though in terms of damage induced by + the electron beam and signal quality is the real electron dose history, + i.e. for how long the beam exposed which location for how long. + + Specifically the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Which IPF definition computation according to backend. + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively this program is the backend + which performs the computation of the inverse pole figure mappings + to reflect what the EBSD community expects and solve also eventual + limitation of research data management system that their data + ingestion backends parsers do not have sophisticated software tools + in place to compute such community-specific default plots. + Seeing first of all that different tools may yield different color + maps may help to convince the community to work towards a common + library which transcodes between all possible relations. + In fact while working on this example I found as many different as + in backend. + + This is why it is critical to store all rotation_conventions + and reference frame details as detailed as possible because + then one can always post-process the data. + + + + + + + + + + + + Version of the program i.e. backend used. + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + IPF color coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), (fundamental zone) of + the orientation space, it is possible to define a color model which + assigns an orientation in the fundamental zone a color. + + For details see: + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web. + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + Naive IPF color map + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + diff --git a/contributed_definitions/nyaml/NXem_ebsd_conventions.nxdl.xml b/contributed_definitions/nyaml/NXem_ebsd_conventions.nxdl.xml new file mode 100644 index 0000000000..cada44a8ec --- /dev/null +++ b/contributed_definitions/nyaml/NXem_ebsd_conventions.nxdl.xml @@ -0,0 +1,467 @@ + + + + + Conventions for rotations and coordinate systems to interpret EBSD data. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Mathematical conventions and materials-science-specific conventions + required for interpreting every collection of orientation data. + + + + 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, etc.) 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. + + + + + + + + + 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 the sample/specimen reference frame. + + + + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + The reference frame for the sample surface reference is used for + identifying positions on a (virtual) image which is formed by + information collected from an electron beam scanning the + sample surface. We assume the configuration is inspected by + looking towards the sample surface from a position that is + located behind the detector. + Reference DOI: 10.1016/j.matchar.2016.04.008 + The sample surface reference frame has coordinates Xs, Ys, Zs. + In three dimensions these coordinates are not necessarily + located on the surface of the sample as there are multiple + faces/sides of the sample. Most frequently though the coordinate + system here is used to define the surface which the electron + beam scans. + + + + + + + + + + Direction of the positively pointing x-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Location of the origin of the sample surface reference frame. + This specifies the location Xs = 0, Ys = 0, Zs = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + + Details about the detector reference frame. + + + + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Where is the origin of the detector space reference + frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.nxdl.xml b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.nxdl.xml new file mode 100644 index 0000000000..7bafab25e2 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.nxdl.xml @@ -0,0 +1,189 @@ + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Crystal structure phase models used for indexing Kikuchi pattern. + + This base class contains key metadata relevant to every physical + kinematic or dynamic diffraction model to be used for simulating + Kikuchi diffraction pattern. + The actual indexing of Kikuchi pattern however maybe use different + algorithms which build on these simulation results but evaluate different + workflows of comparing simulated and measured Kikuchi pattern to make + suggestions which orientation is the most likely (if any) for each + scan point investigated. + + Traditionally Hough transform based indexing has been the most frequently + used algorithm. More and more dictionary based alternatives are used. + Either way both algorithm need a crystal structure model. + + + + Identifier of an entry from crystallographic_database which was used + for creating this structure model. + + + + + Name of the crystallographic database to resolve + crystallographic_database_identifier e.g. COD or others. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Volume of the unit cell + + + + + Crystallographic space group + + + + + 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. + + + + + Laue group + + + + + Point group using International Notation. + + + + + Crystal system + + + + + + + + + + + + + + Numeric identifier for each phase. + The value 0 is reversed for the unknown phase essentially representing the + null-model that no phase model was sufficiently significantly confirmed. + Consequently, the value 0 must not be used as a phase_identifier. + + + + + Name of the phase/alias. + + + + + Labels for each atom position + + + + + + + + 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>`_ + + + + + + + + Atom positions x, y, z. + + + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. Value has to be n_hkl. + + + + + Miller indices :math:`(hkl)`. + + + + + + + + + D-spacing. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + diff --git a/contributed_definitions/nyaml/NXimage_set_em.nxdl.xml b/contributed_definitions/nyaml/NXimage_set_em.nxdl.xml new file mode 100644 index 0000000000..97e8f292dd --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em.nxdl.xml @@ -0,0 +1,86 @@ + + + + + + + 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 with an electron microscope. + + + + + Imaging mode in which the instrument was and with which the images + were captured. + + + + + + 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/nyaml/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml index 5bf3f42f7c..8b63290f68 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml @@ -77,7 +77,7 @@ Annular dark field image stack. - + Image intensity values. @@ -87,12 +87,7 @@ - - - Image intensities - - - + Image identifier @@ -101,33 +96,33 @@ - Image ID. + Image identifier. - + - Pixel center of mass position y-coordinates. + Pixel coordinate center of mass along y direction. - Label for the y axis. + Coordinate along y direction. - + - Pixel center of mass position x-coordinates. + Pixel coordinate center of mass along x direction. - Label for the x axis. + Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.nxdl.xml new file mode 100644 index 0000000000..23bd4bb351 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + + Number of scanned points. Scan point may have none, one, or more + pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per Kikuchi pattern in the slow direction. + + + + + Number of pixel per Kikuchi pattern in the fast direction. + + + + + Measured set of electron backscatter diffraction data, aka Kikuchi pattern. + Kikuchi pattern are the raw data for computational workflows in the field + of orientation (imaging) microscopy. The technique is especially used in + materials science and materials engineering. + + Based on a fuse of the `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + of the DREAM.3D community and the open H5OINA format of Oxford Instruments + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ + + EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional + orientation microscopy. So-called serial section analyses. For a detailed + overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + With serial-sectioning this involves however always a sequence of measuring, + milling. In this regard, each serial section (measuring) and milling + is an own NXevent_data_em instance and thus there such a three-dimensional + characterization should be stored as a set of two-dimensional data, + with as many NXevent_data_em instances as sections were measured. + + These measured serial sectioning images need virtually always post-processing + to arrive at the aligned and cleaned image stack before a respective digital + model of the inspected microstructure can be analyzed. The resulting volume + is often termed a so-called (representative) volume element (RVE). + Several software packages are available for performing this post-processing. + For now we do not consider metadata of these post-processing steps + as a part of this base class because the connection between the large variety + of such post-processing steps and the measured electron microscopy data + is usually very small. + + If we envision a (knowledge) graph for EBSD it consists of individual + sub-graphs which convey information about the specimen preparation, + the measurement of the specimen in the electron microscope, + the indexing of the collected Kikuchi pattern stack, + eventual post-processing of the indexed orientation image + via similarity grouping algorithms to yield (grains, texture). + Conceptually these post-processing steps are most frequently + serving the idea to reconstruct quantitatively so-called + microstructural features (grains, phases, interfaces). Materials scientists + use these features according to the multi-scale materials modeling paradigm + to infer material properties. They do so by quantifying correlations between + the spatial arrangement of the features, their individual properties, + and (macroscopic) properties of materials. + + + + Details how Kikuchi pattern were processed from the detector readings. + Scientists interested in EBSD should inspect the respective NXem_ebsd + application definition which can be used as a partner application definition + to detail substantially more details to this processing. + + + + + Collected Kikuchi pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably by the instrument + given the way how the instrument and control software was configured + for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belong to which scan point. + In an example we may assume we collected three scan points. For the first + we measure one pattern, for the second we measure three pattern, + for the last we measure no pattern. + The values of scan_point_identifier will be 0, 1, 1, 1, as we have + measured four pattern in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. Use compressed + arrays allows to store the scan_point_identifier efficiently. + + + + + + + + Signal intensity. For so-called three-dimensional or serial sectioning + EBSD it is necessary to follow a sequence of specimen surface preparation + and data collection. In this case users should collect the data for each + serial sectioning step in an own instance of NXimage_set_em_kikuchi. + All eventual post-processing of these measured data should be documented + via NXebsd, resulting microstructure representations should be stored + as NXms. + + + + + + + + + Kikuchi pattern intensity + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Kikuchi pattern identifier + + + + + + Pixel coordinate along the y direction. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the x direction. + + + + + + + Label for the x axis + + + + + diff --git a/contributed_definitions/nyaml/NXisocontour.nxdl.xml b/contributed_definitions/nyaml/NXisocontour.nxdl.xml new file mode 100644 index 0000000000..b11f04e6e9 --- /dev/null +++ b/contributed_definitions/nyaml/NXisocontour.nxdl.xml @@ -0,0 +1,43 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the description. + + + + + Computational geometry description of isocontouring/phase-fields in Euclidean space. + + Iso-contouring algorithms such as MarchingCubes and others are frequently + used to segment d-dimensional regions into regions where intensities are + lower or higher than a threshold value, the so-called isovalue. + + Frequently in computational materials science phase-field methods are + used which generate data on discretized grids. Isocontour algorithms + are often used in such context to pinpoint the locations of microstructural + features from this implicit phase-field-variable-based description. + + One of the key intentions of this base class is to provide a starting point + for scientists from the phase-field community (condensed matter physicists, + and materials engineers) to incentivize that also phase-field simulation + data could be described with NeXus, provided base classes such as the this one + get further extend according to the liking of the phase-field community. + + + + + The discretized grid on which the iso-contour algorithm operates. + + + + + The threshold or iso-contour value. + + + diff --git a/contributed_definitions/nyaml/NXlens_em.nxdl.xml b/contributed_definitions/nyaml/NXlens_em.nxdl.xml index 88aff9b2b2..c4b6257096 100644 --- a/contributed_definitions/nyaml/NXlens_em.nxdl.xml +++ b/contributed_definitions/nyaml/NXlens_em.nxdl.xml @@ -4,16 +4,17 @@ Description of an electro-magnetic lens or a compound lens. + Details of an `electro-magnetic 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. + 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>`_ + .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 - Qualitative type of lens with respect to the number of pole pieces. + Qualitative type of lens with respect to the number of pole pieces @@ -25,8 +26,8 @@ - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. + Colloquial or short name for the lens. For manufacturer names and identifiers + use respective manufacturer fields. @@ -34,7 +35,7 @@ Name of the manufacturer who built/constructed the lens. - + Hardware name, hash identifier, or serial number that was given by the @@ -59,17 +60,6 @@ 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 @@ -78,11 +68,10 @@ - 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. + 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/nyaml/NXsensor_scan_parsed.nxdl.xml b/contributed_definitions/nyaml/NXsensor_scan_parsed.nxdl.xml new file mode 100644 index 0000000000..ed8b513052 --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor_scan_parsed.nxdl.xml @@ -0,0 +1,176 @@ + + + + + + Variables used to set a common size for collected sensor data. + + + + The number of scan points measured in this scan. + + + + + Application definition for a generic scan using sensors. + + In this application definition, times should be specified always together + with an UTC offset. + + + + + + + + + + + + + + + Define the program that was used to generate the results file(s) + with measured data and metadata. + + + + Commercial or otherwise defined given name of the program + (or a link to the instrument software). + + + + Either version with build number, commit hash, or description of an + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when + the experiment was performed. + + + + + Full address (street, street number, ZIP, city, country) + of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + Official telephone number of the user. + + + + + + + Describes an environment setup for the experiment. + + All the setting values of the independently scanned controllers are listed under corresponding + NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each + measurement sensor. + + For example, in a temperature-dependent IV measurement, the temperature and voltage must be + present as independently scanned controllers and the current sensor must also be present with + its readings. + + + + + Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. + + + + + For each point in the scan space, either the nominal setpoint of an independently scanned controller + or a representative average value of a measurement sensor is registered. + + The length of each sensor's data value array stored in this group should be equal to the number of scan points + probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. + This allows the scan to be made in any order as the user describes above in the experiment. We get matching + values simply using the index of the scan point. + + + + + + + + Timestamp for when the values provided in the value field were registered. + + Individual readings can be stored with their timestamps under value_log. This is to timestamp + the nominal setpoint or average reading values listed above in the value field. + + + + + + Free-text describing the data acquisition control: an internal + sweep using the built-in functionality of the controller device, + or a set/wait/read/repeat mechanism. + + + + + + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. + + + + + + + A list of names of NXsensor groups used as independently scanned controllers. + + + + + A list of names of NXsensor groups used as measurement sensors. + + + + + + + + + + A scan specific representation of the measured signals as a function of the independently controlled environment settings. + Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. + + + + diff --git a/contributed_definitions/nyaml/NXsensor_scan_parsed.yaml b/contributed_definitions/nyaml/NXsensor_scan_parsed.yaml new file mode 100644 index 0000000000..c4ecf78594 --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor_scan_parsed.yaml @@ -0,0 +1,134 @@ +doc: | + Application definition for a generic scan using sensors. + + In this application definition, times should be specified always together + with an UTC offset. +symbols: + doc: | + Variables used to set a common size for collected sensor data. + + N_scanpoints: | + The number of scan points measured in this scan. + +category: application +NXsensor_scan: + (NXentry): + definition(NX_CHAR): + \@version: + enumeration: [NXsensor_scan] + experiment_identifier(NX_CHAR): + exists: recommended + experiment_description(NX_CHAR): + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + (NXprocess): + doc: | + Define the program that was used to generate the results file(s) + with measured data and metadata. + program(NX_CHAR): + doc: | + Commercial or otherwise defined given name of the program + (or a link to the instrument software). + \@version: + doc: | + Either version with build number, commit hash, or description of an + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@program_url: + doc: | + Website of the software. + (NXuser): + doc: | + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. + name(NX_CHAR): + doc: | + Name of the user. + affiliation(NX_CHAR): + exists: recommended + doc: | + Name of the affiliation of the user at the point in time when + the experiment was performed. + address(NX_CHAR): + exists: recommended + doc: | + Full address (street, street number, ZIP, city, country) + of the user's affiliation. + email(NX_CHAR): + exists: recommended + doc: | + Email address of the user. + orcid(NX_CHAR): + exists: recommended + doc: | + Author ID defined by https://orcid.org/. + telephone_number(NX_CHAR): + exists: recommended + doc: | + Official telephone number of the user. + (NXinstrument): + (NXenvironment): + doc: | + Describes an environment setup for the experiment. + + All the setting values of the independently scanned controllers are listed under corresponding + NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each + measurement sensor. + + For example, in a temperature-dependent IV measurement, the temperature and voltage must be + present as independently scanned controllers and the current sensor must also be present with + its readings. + (NXsensor): + (NXdata): + exists: recommended + doc: | + Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. + value(NX_FLOAT): + unit: NX_ANY + doc: | + For each point in the scan space, either the nominal setpoint of an independently scanned controller + or a representative average value of a measurement sensor is registered. + + The length of each sensor's data value array stored in this group should be equal to the number of scan points + probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. + This allows the scan to be made in any order as the user describes above in the experiment. We get matching + values simply using the index of the scan point. + dimensions: + rank: 1 + dim: [[1, N_scanpoints]] + value_timestamp(NX_DATE_TIME): + exists: recommended + doc: | + Timestamp for when the values provided in the value field were registered. + + Individual readings can be stored with their timestamps under value_log. This is to timestamp + the nominal setpoint or average reading values listed above in the value field. + run_control(NX_CHAR): + exists: recommended + \@description: + doc: | + Free-text describing the data acquisition control: an internal + sweep using the built-in functionality of the controller device, + or a set/wait/read/repeat mechanism. + calibration_time(NX_DATE_TIME): + doc: | + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. + (NXpid): + independent_controllers(NX_CHAR): + doc: | + A list of names of NXsensor groups used as independently scanned controllers. + measurement_sensors(NX_CHAR): + doc: | + A list of names of NXsensor groups used as measurement sensors. + (NXsample): + name(NX_CHAR): + (NXdata): + doc: | + A scan specific representation of the measured signals as a function of the independently controlled environment settings. + Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/nyaml/NXsimilarity_grouping.nxdl.xml new file mode 100644 index 0000000000..03b6eaf74e --- /dev/null +++ b/contributed_definitions/nyaml/NXsimilarity_grouping.nxdl.xml @@ -0,0 +1,140 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Cardinality of the set. + + + + + Number of numerical labels per object. + + + + + Number of categorical labels per object. + + + + + Total number of similarity groups aka features, objects, clusters. + + + + + Metadata to the results of a similarity grouping analysis. + + Similarity grouping analyses can be supervised segmentation or machine learning + clustering algorithms. These are routine methods which partition the member of + a set of objects/geometric primitives into (sub-)groups, features of + different type. A plethora of algorithms have been proposed which can be applied + also on geometric primitives like points, triangles, or (abstract) features aka + objects (including categorical sub-groups). + + This base class considers metadata and results of one similarity grouping + analysis applied to a set in which objects are either categorized as noise + or belonging to a cluster. + As the results of the analysis each similarity group, here called feature + aka object can get a number of numerical and/or categorical labels. + + + + Number of members in the set which is partitioned into features. + + + + + How many numerical labels does each feature have. + + + + + How many categorical labels does each feature have. + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + + + + + + + + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the cluster_identifier. + + + + + + + + + Matrix of categorical attribute data for each member in the set. + + + + + + + + + In addition to the detailed storage which members was grouped to which + feature/group summary statistics are stored under this group. + + + + Total number of members in the set which are categorized as unassigned. + + + + + + + + Total number of members in the set which are categorized as noise. + + + + + + + + Total number of clusters (excluding noise and unassigned). + + + + + Array of numerical identifier of each feature (cluster). + + + + + + + + + Array of number of members for each feature. + + + + + + + + diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml index 4952128e6e..c1c06e0c72 100644 --- a/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml @@ -68,19 +68,22 @@ Collected EELS spectra for all pixels of a rectangular region-of-interest. This representation supports rectangular scan pattern. - + + + Counts for one spectrum per each pixel. + + + + EELS counts + + - - - EELS counts - - - + Pixel center of mass position y-coordinates. @@ -89,11 +92,11 @@ - Label for the y axis. + Coordinate along y direction. - + Pixel center of mass position x-coordinates. @@ -102,11 +105,11 @@ - Label for the x axis. + Coordinate along x direction. - + Pixel center of mass energy loss bins. @@ -115,30 +118,30 @@ - Label for the energy loss axis. + Coordinate along energy loss axis. - Accumulated EELS spectrum over all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. + Accumulated EELS spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. - + Counts for specific energy losses. + + + Counts electrons with an energy loss within binned range. + + - - - Counts electrons with an energy loss within binned range. - - - + Pixel center of mass energy loss bins. @@ -147,7 +150,7 @@ - Energy loss + Coordinate along energy loss axis. diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml index 95ddca359a..d58c59b593 100644 --- a/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml @@ -81,71 +81,71 @@ Collected X-ray spectra for all pixels of a rectangular region-of-interest. This representation supports rectangular scan pattern. - + + + + X-ray photon counts + + - - - X-ray photon counts - - - + - Label for the y axis + Coordinate along y direction. - + - Label for the x axis + Coordinate along x direction. - + - X-ray energy + Photon energy. - Accumulated X-ray spectrum over all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. + Accumulated X-ray spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. - + + + + X-ray photon counts + + - - - X-ray photon counts - - - + - X-ray energy + Photon energy @@ -160,10 +160,11 @@ - Program 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. + Program 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. @@ -193,7 +194,7 @@ - + Individual element-specific EDX/EDS/EDXS/SXES mapping @@ -206,10 +207,11 @@ - Program 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. + Program 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. @@ -227,39 +229,39 @@ Human-readable, given name to the image. - + Individual element-specific maps. Individual maps should each be a group and be named according to element_names. - + + + + Accumulated photon counts for observed element. + + - - - Accumulated X-ray photon counts - - - + - Label for the y axis + Coordinate along y direction. - + - Label for the x axis + Coordinate along x direction. From 32fad81d752e7d3b7309952a9b2fda684a6df915 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Wed, 15 Feb 2023 12:19:06 +0100 Subject: [PATCH 100/203] Generating .yaml using modified nyaml2nxdl converter. Renaming .yml to .yaml file in ./application/nyaml --- .../nyaml/{NXarchive.yml => NXarchive.yaml} | 54 ++++--- .../nyaml/{NXarpes.yml => NXarpes.yaml} | 30 ++-- .../nyaml/{NXcanSAS.yml => NXcanSAS.yaml} | 147 ++++++++++++------ .../{NXdirecttof.yml => NXdirecttof.yaml} | 15 +- .../nyaml/{NXfluo.yml => NXfluo.yaml} | 15 +- .../{NXindirecttof.yml => NXindirecttof.yaml} | 21 ++- .../nyaml/{NXiqproc.yml => NXiqproc.yaml} | 44 ++++-- .../nyaml/{NXlauetof.yml => NXlauetof.yaml} | 35 +++-- .../nyaml/{NXmonopd.yml => NXmonopd.yaml} | 34 ++-- applications/nyaml/{NXmx.yml => NXmx.yaml} | 58 ++++--- .../nyaml/{NXrefscan.yml => NXrefscan.yaml} | 21 ++- .../nyaml/{NXreftof.yml => NXreftof.yaml} | 38 +++-- applications/nyaml/{NXsas.yml => NXsas.yaml} | 48 ++++-- .../nyaml/{NXsastof.yml => NXsastof.yaml} | 53 +++++-- .../nyaml/{NXscan.yml => NXscan.yaml} | 20 ++- applications/nyaml/{NXspe.yml => NXspe.yaml} | 12 +- .../nyaml/{NXsqom.yml => NXsqom.yaml} | 42 +++-- .../nyaml/{NXstxm.yml => NXstxm.yaml} | 37 +++-- applications/nyaml/{NXtas.yml => NXtas.yaml} | 24 ++- .../nyaml/{NXtofnpd.yml => NXtofnpd.yaml} | 31 ++-- .../nyaml/{NXtofraw.yml => NXtofraw.yaml} | 31 ++-- .../{NXtofsingle.yml => NXtofsingle.yaml} | 39 +++-- .../nyaml/{NXtomo.yml => NXtomo.yaml} | 26 +++- .../{NXtomophase.yml => NXtomophase.yaml} | 37 +++-- .../nyaml/{NXtomoproc.yml => NXtomoproc.yaml} | 34 ++-- applications/nyaml/{NXxas.yml => NXxas.yaml} | 27 ++-- .../nyaml/{NXxasproc.yml => NXxasproc.yaml} | 27 ++-- .../nyaml/{NXxbase.yml => NXxbase.yaml} | 38 +++-- .../nyaml/{NXxeuler.yml => NXxeuler.yaml} | 12 +- .../nyaml/{NXxkappa.yml => NXxkappa.yaml} | 18 ++- .../nyaml/{NXxlaue.yml => NXxlaue.yaml} | 15 +- .../{NXxlaueplate.yml => NXxlaueplate.yaml} | 6 +- applications/nyaml/{NXxnb.yml => NXxnb.yaml} | 12 +- .../nyaml/{NXxrot.yml => NXxrot.yaml} | 21 ++- 34 files changed, 760 insertions(+), 362 deletions(-) rename applications/nyaml/{NXarchive.yml => NXarchive.yaml} (64%) rename applications/nyaml/{NXarpes.yml => NXarpes.yaml} (73%) rename applications/nyaml/{NXcanSAS.yml => NXcanSAS.yaml} (90%) rename applications/nyaml/{NXdirecttof.yml => NXdirecttof.yaml} (72%) rename applications/nyaml/{NXfluo.yml => NXfluo.yaml} (79%) rename applications/nyaml/{NXindirecttof.yml => NXindirecttof.yaml} (64%) rename applications/nyaml/{NXiqproc.yml => NXiqproc.yaml} (55%) rename applications/nyaml/{NXlauetof.yml => NXlauetof.yaml} (75%) rename applications/nyaml/{NXmonopd.yml => NXmonopd.yaml} (71%) rename applications/nyaml/{NXmx.yml => NXmx.yaml} (96%) rename applications/nyaml/{NXrefscan.yml => NXrefscan.yaml} (77%) rename applications/nyaml/{NXreftof.yml => NXreftof.yaml} (69%) rename applications/nyaml/{NXsas.yml => NXsas.yaml} (80%) rename applications/nyaml/{NXsastof.yml => NXsastof.yaml} (70%) rename applications/nyaml/{NXscan.yml => NXscan.yaml} (87%) rename applications/nyaml/{NXspe.yml => NXspe.yaml} (77%) rename applications/nyaml/{NXsqom.yml => NXsqom.yaml} (58%) rename applications/nyaml/{NXstxm.yml => NXstxm.yaml} (88%) rename applications/nyaml/{NXtas.yml => NXtas.yaml} (85%) rename applications/nyaml/{NXtofnpd.yml => NXtofnpd.yaml} (77%) rename applications/nyaml/{NXtofraw.yml => NXtofraw.yaml} (79%) rename applications/nyaml/{NXtofsingle.yml => NXtofsingle.yaml} (75%) rename applications/nyaml/{NXtomo.yml => NXtomo.yaml} (87%) rename applications/nyaml/{NXtomophase.yml => NXtomophase.yaml} (80%) rename applications/nyaml/{NXtomoproc.yml => NXtomoproc.yaml} (72%) rename applications/nyaml/{NXxas.yml => NXxas.yaml} (68%) rename applications/nyaml/{NXxasproc.yml => NXxasproc.yaml} (61%) rename applications/nyaml/{NXxbase.yml => NXxbase.yaml} (80%) rename applications/nyaml/{NXxeuler.yml => NXxeuler.yaml} (86%) rename applications/nyaml/{NXxkappa.yml => NXxkappa.yaml} (78%) rename applications/nyaml/{NXxlaue.yml => NXxlaue.yaml} (70%) rename applications/nyaml/{NXxlaueplate.yml => NXxlaueplate.yaml} (75%) rename applications/nyaml/{NXxnb.yml => NXxnb.yaml} (85%) rename applications/nyaml/{NXxrot.yml => NXxrot.yaml} (72%) diff --git a/applications/nyaml/NXarchive.yml b/applications/nyaml/NXarchive.yaml similarity index 64% rename from applications/nyaml/NXarchive.yml rename to applications/nyaml/NXarchive.yaml index 2dd9998d5a..7b56c66182 100644 --- a/applications/nyaml/NXarchive.yml +++ b/applications/nyaml/NXarchive.yaml @@ -13,42 +13,56 @@ NXarchive: \@index: title: experiment_identifier(NX_CHAR): - doc: "unique identifier for the experiment" + doc: | + unique identifier for the experiment experiment_description(NX_CHAR): - doc: "Brief description of the experiment and its objectives" + doc: | + Brief description of the experiment and its objectives collection_identifier(NX_CHAR): - doc: "ID of user or DAQ define group of data files" + doc: | + ID of user or DAQ define group of data files collection_description(NX_CHAR): - doc: "Brief summary of the collection, including grouping criteria" + doc: | + Brief summary of the collection, including grouping criteria entry_identifier(NX_CHAR): - doc: "unique identifier for this measurement as provided by the facility" + doc: | + unique identifier for this measurement as provided by the facility start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): duration(NX_FLOAT): unit: NX_TIME - doc: "TODO: needs documentation" + doc: | + TODO: needs documentation collection_time(NX_FLOAT): unit: NX_TIME - doc: "TODO: needs documentation" + doc: | + TODO: needs documentation run_cycle(NX_CHAR): - doc: "TODO: needs documentation" + doc: | + TODO: needs documentation revision(NX_CHAR): - doc: "revision ID of this file, may be after recalibration, reprocessing etc." + doc: | + revision ID of this file, may be after recalibration, reprocessing etc. definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXarchive] program(NX_CHAR): - doc: "The program and version used for generating this file" + doc: | + The program and version used for generating this file \@version: release_date(NX_CHAR): unit: NX_TIME - doc: "when this file is to be released into PD" + doc: | + when this file is to be released into PD user(NXuser): name(NX_CHAR): role(NX_CHAR): - doc: "role of the user" + doc: | + role of the user facility_user_id(NX_CHAR): - doc: "ID of the user in the facility burocracy database" + doc: | + ID of the user in the facility burocracy database instrument(NXinstrument): (NXsource): type(NX_CHAR): @@ -58,17 +72,21 @@ NXarchive: enumeration: [neutron, x-ray, electron] name(NX_CHAR): description(NX_CHAR): - doc: "Brief description of the instrument" + doc: | + Brief description of the instrument sample(NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample sample_id(NX_CHAR): - doc: "Unique database id of the sample" + doc: | + Unique database id of the sample description(NX_CHAR): type(NX_CHAR): enumeration: [sample, sample+can, calibration sample, normalisation sample, simulated data, none, sample_environment] chemical_formula(NX_CHAR): - doc: "Chemical formula formatted according to CIF conventions" + doc: | + Chemical formula formatted according to CIF conventions preparation_date(NX_CHAR): unit: NX_TIME situation(NX_CHAR): diff --git a/applications/nyaml/NXarpes.yml b/applications/nyaml/NXarpes.yaml similarity index 73% rename from applications/nyaml/NXarpes.yml rename to applications/nyaml/NXarpes.yaml index 67f7798ae7..48a8d2ab41 100644 --- a/applications/nyaml/NXarpes.yml +++ b/applications/nyaml/NXarpes.yaml @@ -12,7 +12,8 @@ NXarpes: title(NX_CHAR): start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms." + doc: | + Official NeXus NXDL schema to which this file conforms. enumeration: [NXarpes] (NXinstrument): (NXsource): @@ -26,23 +27,28 @@ NXarpes: analyser(NXdetector): data(NX_NUMBER): lens_mode(NX_CHAR): - doc: "setting for the electron analyser lens" + doc: | + setting for the electron analyser lens acquisition_mode: enumeration: [swept, fixed] entrance_slit_shape: enumeration: [curved, straight] entrance_slit_setting(NX_NUMBER): unit: NX_ANY - doc: "dial setting of the entrance slit" + doc: | + dial setting of the entrance slit entrance_slit_size(NX_NUMBER): unit: NX_LENGTH - doc: "size of the entrance slit" + doc: | + size of the entrance slit pass_energy(NX_NUMBER): unit: NX_ENERGY - doc: "energy of the electrons on the mean path of the analyser" + doc: | + energy of the electrons on the mean path of the analyser time_per_channel(NX_NUMBER): unit: NX_TIME - doc: "todo: define more clearly" + doc: | + todo: define more clearly angles(NX_NUMBER): unit: NX_ANGLE doc: | @@ -56,23 +62,27 @@ NXarpes: which dimension the axis applies to is defined using the normal NXdata methods. sensor_size(NX_INT): - doc: "number of raw active elements in each dimension" + doc: | + number of raw active elements in each dimension dimensions: rank: 1 dim: [[1, 2]] region_origin(NX_INT): - doc: "origin of rectangular region selected for readout" + doc: | + origin of rectangular region selected for readout dimensions: rank: 1 dim: [[1, 2]] region_size(NX_INT): - doc: "size of rectangular region selected for readout" + doc: | + size of rectangular region selected for readout dimensions: rank: 1 dim: [[1, 2]] (NXsample): name(NX_CHAR): - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample temperature(NX_NUMBER): unit: NX_TEMPERATURE (NXdata): diff --git a/applications/nyaml/NXcanSAS.yml b/applications/nyaml/NXcanSAS.yaml similarity index 90% rename from applications/nyaml/NXcanSAS.yml rename to applications/nyaml/NXcanSAS.yaml index 2de590b633..bc4baf5616 100644 --- a/applications/nyaml/NXcanSAS.yml +++ b/applications/nyaml/NXcanSAS.yaml @@ -110,7 +110,8 @@ NXcanSAS: @version="1.1" enumeration: [1.1] definition: - doc: "Official NeXus NXDL schema to which this subentry conforms." + doc: | + Official NeXus NXDL schema to which this subentry conforms. enumeration: [NXcanSAS] (NXdata): doc: | @@ -137,14 +138,16 @@ NXcanSAS: use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` or ``@Pressure_indices``). \@canSAS_class: - doc: "Official canSAS group: :index:`NXcanSAS (applications); SASdata`" + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASdata` enumeration: [SASdata] \@signal: doc: | Name of the default data field. enumeration: I: - doc: "For canSAS **SASdata**, this is always 'I'." + doc: | + For canSAS **SASdata**, this is always "I". \@I_axes: doc: | String array that defines the independent data fields used in @@ -229,7 +232,8 @@ NXcanSAS: enumeration: 1/m: 1/nm: - doc: "preferred" + doc: | + preferred 1/angstrom: \@uncertainties: doc: | @@ -382,9 +386,11 @@ NXcanSAS: changed to ``unknown`` for handling with that library. enumeration: 1/m: - doc: "includes m2/m3 and 1/m/sr" + doc: | + includes m2/m3 and 1/m/sr 1/cm: - doc: "includes cm2/cm3 and 1/cm/sr" + doc: | + includes cm2/cm3 and 1/cm/sr m2/g: cm2/g: arbitrary: @@ -453,9 +459,11 @@ NXcanSAS: changed to ``unknown`` for handling with that library. enumeration: 1/m: - doc: "includes m2/m3 and 1/m/sr" + doc: | + includes m2/m3 and 1/m/sr 1/cm: - doc: "includes cm2/cm3 and 1/cm/sr" + doc: | + includes cm2/cm3 and 1/cm/sr m2/g: cm2/g: arbitrary: @@ -486,7 +494,8 @@ NXcanSAS: enumeration: 1/m: 1/nm: - doc: "preferred" + doc: | + preferred 1/angstrom: dQw(NX_NUMBER): unit: NX_PER_LENGTH @@ -514,7 +523,8 @@ NXcanSAS: enumeration: 1/m: 1/nm: - doc: "preferred" + doc: | + preferred 1/angstrom: dQl(NX_NUMBER): unit: NX_PER_LENGTH @@ -542,7 +552,8 @@ NXcanSAS: enumeration: 1/m: 1/nm: - doc: "preferred" + doc: | + preferred 1/angstrom: Qmean(NX_NUMBER): unit: NX_PER_LENGTH @@ -563,7 +574,8 @@ NXcanSAS: enumeration: 1/m: 1/nm: - doc: "preferred" + doc: | + preferred 1/angstrom: ShadowFactor: unit: NX_DIMENSIONLESS @@ -593,7 +605,8 @@ NXcanSAS: Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. (NXinstrument): \@canSAS_class: - doc: "Official canSAS group: :index:`NXcanSAS (applications); SASinstrument`" + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` enumeration: [SASinstrument] doc: | Description of the small-angle scattering instrument. @@ -611,7 +624,8 @@ NXcanSAS: Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. \@canSAS_class: - doc: "Official canSAS group: :index:`NXcanSAS (applications); SASaperture`" + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASaperture` enumeration: [SASaperture] shape: doc: | @@ -619,14 +633,17 @@ NXcanSAS: x_gap(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "opening along the :math:`x` axis" + doc: | + opening along the :math:`x` axis y_gap(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "opening along the :math:`y` axis" + doc: | + opening along the :math:`y` axis (NXcollimator): \@canSAS_class: - doc: "Official canSAS group: :index:`NXcanSAS (applications); SAScollimation`" + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` enumeration: [SAScollimation] doc: | Description of a collimating element (defines the divergence of the beam) in the instrument. @@ -636,19 +653,23 @@ NXcanSAS: length(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Amount/length of collimation inserted (as on a SANS instrument)" + doc: | + Amount/length of collimation inserted (as on a SANS instrument) distance(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Distance from this collimation element to the sample" + doc: | + Distance from this collimation element to the sample (NXdetector): \@canSAS_class: - doc: "Official canSAS group: :index:`NXcanSAS (applications); SASdetector`" + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASdetector` enumeration: [SASdetector] doc: | Description of a detector in the instrument. name: - doc: "Identifies the name of this detector" + doc: | + Identifies the name of this detector SDD(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH @@ -672,23 +693,28 @@ NXcanSAS: x_position(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Location of the detector in :math:`x`" + doc: | + Location of the detector in :math:`x` y_position(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Location of the detector in :math:`y`" + doc: | + Location of the detector in :math:`y` roll(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_ANGLE - doc: "Rotation of the detector about the :math:`z` axis (roll)" + doc: | + Rotation of the detector about the :math:`z` axis (roll) pitch(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_ANGLE - doc: "Rotation of the detector about the :math:`x` axis (roll)" + doc: | + Rotation of the detector about the :math:`x` axis (roll) yaw(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_ANGLE - doc: "Rotation of the detector about the :math:`y` axis (yaw)" + doc: | + Rotation of the detector about the :math:`y` axis (yaw) beam_center_x(NX_FLOAT): exists: [min, 0, max, 1] unit: NX_LENGTH @@ -714,14 +740,17 @@ NXcanSAS: x_pixel_size(NX_FLOAT): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Size of each detector pixel. If it is scalar all pixels are the same size" + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size y_pixel_size(NX_FLOAT): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Size of each detector pixel. If it is scalar all pixels are the same size" + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size (NXsource): \@canSAS_class: - doc: "Official canSAS group: :index:`NXcanSAS (applications); SASsource`" + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASsource` enumeration: [SASsource] doc: | Description of the radiation source. @@ -736,11 +765,13 @@ NXcanSAS: enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] beam_shape: exists: [min, 0, max, 1] - doc: "Text description of the shape of the beam (incident on the sample)." + doc: | + Text description of the shape of the beam (incident on the sample). incident_wavelength(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_WAVELENGTH - doc: wavelength (:math:`\lambda`) of radiation incident on the sample + doc: | + wavelength (:math:`\lambda`) of radiation incident on the sample wavelength_min(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_WAVELENGTH @@ -762,23 +793,28 @@ NXcanSAS: beam_size_x(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Size of the incident beam along the x axis." + doc: | + Size of the incident beam along the x axis. beam_size_y(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Size of the incident beam along the y axis." + doc: | + Size of the incident beam along the y axis. (NXsample): \@canSAS_class: - doc: "Official canSAS group: :index:`NXcanSAS (applications); SASsample`" + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASsample` enumeration: [SASsample] doc: | Description of the sample. name: - doc: "**ID**: Text string that identifies this sample." + doc: | + **ID**: Text string that identifies this sample. thickness(NX_FLOAT): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Thickness of this sample" + doc: | + Thickness of this sample transmission(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_DIMENSIONLESS @@ -792,34 +828,42 @@ NXcanSAS: temperature(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_TEMPERATURE - doc: "Temperature of this sample." + doc: | + Temperature of this sample. details: exists: [min, 0, max, unbounded] - doc: "Any additional sample details." + doc: | + Any additional sample details. x_position(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Location of the sample in :math:`x`" + doc: | + Location of the sample in :math:`x` y_position(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Location of the sample in :math:`y`" + doc: | + Location of the sample in :math:`y` roll(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_ANGLE - doc: "Rotation of the sample about the :math:`z` axis (roll)" + doc: | + Rotation of the sample about the :math:`z` axis (roll) pitch(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_ANGLE - doc: "Rotation of the sample about the :math:`x` axis (roll)" + doc: | + Rotation of the sample about the :math:`x` axis (roll) yaw(NX_NUMBER): exists: [min, 0, max, 1] unit: NX_ANGLE - doc: "Rotation of the sample about the :math:`y` axis (yaw)" + doc: | + Rotation of the sample about the :math:`y` axis (yaw) (NXprocess): exists: [min, 0, max, unbounded] \@canSAS_class: - doc: "Official canSAS group: :index:`NXcanSAS (applications); SASprocess`" + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASprocess` enumeration: [SASprocess] doc: | Description of a processing or analysis step. @@ -829,7 +873,8 @@ NXcanSAS: Be sure to include *units* attributes for all numerical fields. name: exists: [min, 0, max, 1] - doc: "Optional name for this data processing or analysis step" + doc: | + Optional name for this data processing or analysis step date(NX_DATE_TIME): exists: [min, 0, max, 1] doc: | @@ -846,7 +891,8 @@ NXcanSAS: or http://en.wikipedia.org/wiki/ISO_8601 for more details. description: exists: [min, 0, max, 1] - doc: "Optional description for this data processing or analysis step" + doc: | + Optional description for this data processing or analysis step term: exists: [min, 0, max, unbounded] doc: | @@ -898,18 +944,21 @@ NXcanSAS: The name of each *SAStransmission_spectrum* group must be unique within a SASentry group. Suggest using names such as ``sastransmission_spectrum01``. \@canSAS_class: - doc: "Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum`" + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` enumeration: [SAStransmission_spectrum] \@signal: doc: | Name of the default data field. enumeration: T: - doc: "For **SAStransmission_spectrum**, this is always 'T'." + doc: | + For **SAStransmission_spectrum**, this is always "T". \@T_axes: enumeration: T: - doc: "the wavelengths field (as a dimension scale) corresponding to this transmission" + doc: | + the wavelengths field (as a dimension scale) corresponding to this transmission \@name: doc: | Identify what type of spectrum is being described. diff --git a/applications/nyaml/NXdirecttof.yml b/applications/nyaml/NXdirecttof.yaml similarity index 72% rename from applications/nyaml/NXdirecttof.yml rename to applications/nyaml/NXdirecttof.yaml index c9c47c95db..372ff87e9f 100644 --- a/applications/nyaml/NXdirecttof.yml +++ b/applications/nyaml/NXdirecttof.yaml @@ -6,23 +6,28 @@ NXdirecttof(NXtofraw): title: start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXdirecttof] (NXinstrument): fermi_chopper(NXfermi_chopper): rotation_speed(NX_FLOAT): unit: NX_FREQUENCY - doc: "chopper rotation speed" + doc: | + chopper rotation speed energy(NX_FLOAT): unit: NX_ENERGY - doc: "energy selected" + doc: | + energy selected disk_chopper(NXdisk_chopper): rotation_speed(NX_FLOAT): unit: NX_FREQUENCY - doc: "chopper rotation speed" + doc: | + chopper rotation speed energy(NX_FLOAT): unit: NX_ENERGY - doc: "energy selected" + doc: | + energy selected doc: | We definitly want the rotation_speed and energy of the chopper. Thus either a fermi_chopper or a disk_chopper group is required. diff --git a/applications/nyaml/NXfluo.yml b/applications/nyaml/NXfluo.yaml similarity index 79% rename from applications/nyaml/NXfluo.yml rename to applications/nyaml/NXfluo.yaml index 791a7138b0..c0aab01e47 100644 --- a/applications/nyaml/NXfluo.yml +++ b/applications/nyaml/NXfluo.yaml @@ -1,9 +1,12 @@ doc: | This is an application definition for raw data from an X-ray fluorescence experiment symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nE: "Number of energies" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nE: | + Number of energies + category: application NXfluo: entry(NXentry): @@ -32,7 +35,8 @@ NXfluo: dim: [[1, nE]] (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample (NXmonitor): mode: doc: | @@ -40,6 +44,7 @@ NXfluo: or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor data(NX_INT): data(NXdata): diff --git a/applications/nyaml/NXindirecttof.yml b/applications/nyaml/NXindirecttof.yaml similarity index 64% rename from applications/nyaml/NXindirecttof.yml rename to applications/nyaml/NXindirecttof.yaml index ebce9380c1..cfd75cba61 100644 --- a/applications/nyaml/NXindirecttof.yml +++ b/applications/nyaml/NXindirecttof.yaml @@ -1,34 +1,41 @@ doc: | This is a application definition for raw data from a direct geometry TOF spectrometer symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: "Number of detectors" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nDet: | + Number of detectors + category: application NXindirecttof(NXtofraw): entry(NXentry): title: start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXindirecttof] (NXinstrument): analyser(NXmonochromator): energy(NX_FLOAT): unit: NX_ENERGY - doc: "analyzed energy" + doc: | + analyzed energy dimensions: rank: 1 dim: [[1, nDet]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: "polar angle towards sample" + doc: | + polar angle towards sample dimensions: rank: 1 dim: [[1, nDet]] distance(NX_FLOAT): unit: NX_LENGTH - doc: "distance from sample" + doc: | + distance from sample dimensions: rank: 1 dim: [[1, nDet]] diff --git a/applications/nyaml/NXiqproc.yml b/applications/nyaml/NXiqproc.yaml similarity index 55% rename from applications/nyaml/NXiqproc.yml rename to applications/nyaml/NXiqproc.yaml index d625fbc735..84cd45981c 100644 --- a/applications/nyaml/NXiqproc.yml +++ b/applications/nyaml/NXiqproc.yaml @@ -1,18 +1,26 @@ doc: | Application definition for any :math:`I(Q)` data. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nVars: "The number of values taken by the varied variable" - nQX: "Number of values for the first dimension of Q" - nQY: "Number of values for the second dimension of Q" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nVars: | + The number of values taken by the varied variable + + nQX: | + Number of values for the first dimension of Q + + nQY: | + Number of values for the second dimension of Q + category: application NXiqproc: (NXentry): \@entry: title: definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXiqproc] instrument(NXinstrument): (NXsource): @@ -21,19 +29,24 @@ NXiqproc: probe: enumeration: [neutron, x-ray, electron] name(NX_CHAR): - doc: "Name of the instrument from which this data was reduced." + doc: | + Name of the instrument from which this data was reduced. (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample reduction(NXprocess): program(NX_CHAR): version(NX_CHAR): input(NXparameters): filenames(NX_CHAR): - doc: "Raw data files used to generate this I(Q)" - doc: "Input parameters for the reduction program used" + doc: | + Raw data files used to generate this I(Q) + doc: | + Input parameters for the reduction program used output(NXparameters): - doc: "Eventual output parameters from the data reduction program used" + doc: | + Eventual output parameters from the data reduction program used (NXdata): data(NX_INT): doc: | @@ -50,14 +63,17 @@ NXiqproc: rank: 1 dim: [[1, nVars]] \@varied_variable: - doc: "The real name of the varied variable in the first dim of data, temperature, P, MF etc..." + doc: | + The real name of the varied variable in the first dim of data, temperature, P, MF etc... qx(NX_NUMBER): - doc: "Values for the first dimension of Q" + doc: | + Values for the first dimension of Q dimensions: rank: 1 dim: [[1, nQX]] qy(NX_NUMBER): - doc: "Values for the second dimension of Q" + doc: | + Values for the second dimension of Q dimensions: rank: 1 dim: [[1, nQY]] diff --git a/applications/nyaml/NXlauetof.yml b/applications/nyaml/NXlauetof.yaml similarity index 75% rename from applications/nyaml/NXlauetof.yml rename to applications/nyaml/NXlauetof.yaml index 52938ea47c..62095cfa88 100644 --- a/applications/nyaml/NXlauetof.yml +++ b/applications/nyaml/NXlauetof.yaml @@ -1,16 +1,24 @@ doc: | This is the application definition for a TOF laue diffractometer symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nXPixels: "Number of X pixels" - nYPixels: "Number of Y pixels" - nTOF: "Time of flight" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nXPixels: | + Number of X pixels + + nYPixels: | + Number of Y pixels + + nTOF: | + Time of flight + category: application NXlauetof: entry(NXentry): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXlauetof] instrument(NXinstrument): detector(NXdetector): @@ -19,10 +27,12 @@ NXlauetof: detector. polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: "The polar_angle (two theta) where the detector is placed." + doc: | + The polar_angle (two theta) where the detector is placed. azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: "The azimuthal angle where the detector is placed." + doc: | + The azimuthal angle where the detector is placed. data(NX_INT): dimensions: rank: 3 @@ -42,7 +52,8 @@ NXlauetof: dim: [[1, nTOF]] sample(NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample orientation_matrix(NX_FLOAT): doc: | The orientation matrix according to Busing and @@ -67,9 +78,11 @@ NXlauetof: (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor data(NX_INT): - doc: "use these attributes ``primary=1 signal=1``" + doc: | + use these attributes ``primary=1 signal=1`` dimensions: rank: 1 dim: [[1, nTOF]] diff --git a/applications/nyaml/NXmonopd.yml b/applications/nyaml/NXmonopd.yaml similarity index 71% rename from applications/nyaml/NXmonopd.yml rename to applications/nyaml/NXmonopd.yaml index 6242d85c02..e0a6351566 100644 --- a/applications/nyaml/NXmonopd.yml +++ b/applications/nyaml/NXmonopd.yaml @@ -7,17 +7,23 @@ doc: | with a single detector or a powder diffractometer with a position sensitive detector. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - i: "i is the number of wavelengths" - nDet: "Number of detectors" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + i: | + i is the number of wavelengths + + nDet: | + Number of detectors + category: application NXmonopd: entry(NXentry): title: start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXmonopd] (NXinstrument): (NXsource): @@ -28,7 +34,8 @@ NXmonopd: (NXcrystal): wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: "Optimum diffracted wavelength" + doc: | + Optimum diffracted wavelength dimensions: rank: 1 dim: [[1, i]] @@ -46,7 +53,8 @@ NXmonopd: dim: [[1, nDet]] (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE doc: | @@ -60,10 +68,14 @@ NXmonopd: or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor integral(NX_FLOAT): unit: NX_ANY - doc: "Total integral monitor counts" + doc: | + Total integral monitor counts (NXdata): - doc: "Link to polar angle in /NXentry/NXinstrument/NXdetector" - doc: "Link to data in /NXentry/NXinstrument/NXdetector" + doc: | + Link to polar angle in /NXentry/NXinstrument/NXdetector + doc: | + Link to data in /NXentry/NXinstrument/NXdetector diff --git a/applications/nyaml/NXmx.yml b/applications/nyaml/NXmx.yaml similarity index 96% rename from applications/nyaml/NXmx.yml rename to applications/nyaml/NXmx.yaml index fb0567f007..30e4f904f4 100644 --- a/applications/nyaml/NXmx.yml +++ b/applications/nyaml/NXmx.yaml @@ -1,20 +1,35 @@ doc: | functional application definition for macromolecular crystallography symbols: - doc: | - These symbols will be used below to coordinate datasets - with the same shape. Most MX x-ray detectors will produce - two-dimensional images. Some will produce three-dimensional - images, using one of the indices to select a detector module. - dataRank: "Rank of the ``data`` field" - nP: "Number of scan points" - i: "Number of detector pixels in the slowest direction" - j: "Number of detector pixels in the second slowest direction" - k: "Number of detector pixels in the third slowest direction" - m: "Number of channels in the incident beam spectrum, if known" - groupIndex: "An array of the hierarchical levels of the parents of detector - elements or groupings of detector elements. - A top-level element or grouping has parent level -1." + doc: | + These symbols will be used below to coordinate datasets + with the same shape. Most MX x-ray detectors will produce + two-dimensional images. Some will produce three-dimensional + images, using one of the indices to select a detector module. + + dataRank: | + Rank of the ``data`` field + + nP: | + Number of scan points + + i: | + Number of detector pixels in the slowest direction + + j: | + Number of detector pixels in the second slowest direction + + k: | + Number of detector pixels in the third slowest direction + + m: | + Number of channels in the incident beam spectrum, if known + + groupIndex: | + An array of the hierarchical levels of the parents of detector + elements or groupings of detector elements. + A top-level element or grouping has parent level -1. + category: application NXmx: (NXentry): @@ -53,7 +68,8 @@ NXmx: NXentry/NXinstrument/time_zone. This field may be filled with a value estimated before an observed value is available. definition: - doc: "NeXus NXDL schema to which this file conforms" + doc: | + NeXus NXDL schema to which this file conforms enumeration: [NXmx] (NXdata): data(NX_NUMBER): @@ -68,7 +84,8 @@ NXmx: dim: [[1, nP], [2, i], [3, j], [4, k]] (NXsample): name(NX_CHAR): - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample depends_on(NX_CHAR): doc: | This is a requirement to describe for any scan experiment. @@ -107,7 +124,8 @@ NXmx: https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html is highly recommended. \@short_name: - doc: "Short name for instrument, perhaps the acronym." + doc: | + Short name for instrument, perhaps the acronym. time_zone(NX_DATE_TIME): exists: recommended doc: | @@ -343,7 +361,8 @@ NXmx: True when the angular calibration has been applied in the electronics, false otherwise. angular_calibration(NX_FLOAT): - doc: "Angular calibration data." + doc: | + Angular calibration data. dimensions: rank: dataRank dim: [[1, i], [2, j], [3, k]] @@ -687,4 +706,5 @@ NXmx: https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html controlled vocabulary is highly recommended. \@short_name: - doc: "short name for source, perhaps the acronym" + doc: | + short name for source, perhaps the acronym diff --git a/applications/nyaml/NXrefscan.yml b/applications/nyaml/NXrefscan.yaml similarity index 77% rename from applications/nyaml/NXrefscan.yml rename to applications/nyaml/NXrefscan.yaml index 5014f7896c..5c3bfc11b0 100644 --- a/applications/nyaml/NXrefscan.yml +++ b/applications/nyaml/NXrefscan.yaml @@ -4,9 +4,12 @@ doc: | It does not have the information to calculate the resolution since it does not have any apertures. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + category: application NXrefscan: entry(NXentry): @@ -14,7 +17,8 @@ NXrefscan: start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXrefscan] instrument(NXinstrument): (NXsource): @@ -37,7 +41,8 @@ NXrefscan: dim: [[1, nP]] sample(NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE dimensions: @@ -50,10 +55,12 @@ NXrefscan: or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor data(NX_FLOAT): unit: NX_ANY - doc: "Monitor counts for each step" + doc: | + Monitor counts for each step dimensions: rank: 1 dim: [[1, nP]] diff --git a/applications/nyaml/NXreftof.yml b/applications/nyaml/NXreftof.yaml similarity index 69% rename from applications/nyaml/NXreftof.yml rename to applications/nyaml/NXreftof.yaml index b4211e1e0e..7c30a104b6 100644 --- a/applications/nyaml/NXreftof.yml +++ b/applications/nyaml/NXreftof.yaml @@ -1,11 +1,18 @@ doc: | This is an application definition for raw data from a TOF reflectometer. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - xSize: "xSize description" - ySize: "ySize description" - nTOF: "nTOF description" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + xSize: | + xSize description + + ySize: | + ySize description + + nTOF: | + nTOF description + category: application NXreftof: entry(NXentry): @@ -13,14 +20,16 @@ NXreftof: start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXreftof] instrument(NXinstrument): name(NX_CHAR): chopper(NXdisk_chopper): distance(NX_FLOAT): unit: NX_LENGTH - doc: "Distance between chopper and sample" + doc: | + Distance between chopper and sample detector(NXdetector): data(NX_INT): dimensions: @@ -44,7 +53,8 @@ NXreftof: unit: NX_LENGTH sample(NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE control(NXmonitor): @@ -55,12 +65,16 @@ NXreftof: enumeration: [monitor, timer] preset(NX_FLOAT): unit: NX_ANY - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor integral(NX_INT): - doc: "Total integral monitor counts" + doc: | + Total integral monitor counts time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT - doc: "Time channels" + doc: | + Time channels data(NX_INT): - doc: "Monitor counts in each time channel" + doc: | + Monitor counts in each time channel data(NXdata): diff --git a/applications/nyaml/NXsas.yml b/applications/nyaml/NXsas.yaml similarity index 80% rename from applications/nyaml/NXsas.yml rename to applications/nyaml/NXsas.yaml index 1f0ea6e5a4..703938291e 100644 --- a/applications/nyaml/NXsas.yml +++ b/applications/nyaml/NXsas.yaml @@ -12,10 +12,15 @@ doc: | It covers all raw data from any SAS techniques that use an area detector and a monochromatic beam. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate fields with the same shape. - nXPixel: "Number of pixels in x direction." - nYPixel: "Number of pixels in y direction." + doc: | + The symbol(s) listed here will be used below to coordinate fields with the same shape. + + nXPixel: | + Number of pixels in x direction. + + nYPixel: | + Number of pixels in y direction. + category: application NXsas: (NXentry): @@ -23,14 +28,17 @@ NXsas: start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms." + doc: | + Official NeXus NXDL schema to which this file conforms. enumeration: [NXsas] (NXinstrument): (NXsource): type: - doc: "Type of radiation source." + doc: | + Type of radiation source. name: - doc: "Name of the radiation source." + doc: | + Name of the radiation source. probe: doc: | Name of radiation probe, necessary to compute the sample contrast. @@ -38,7 +46,7 @@ NXsas: (NXmonochromator): wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | The wavelength (:math:`\lambda`) of the radiation. wavelength_spread(NX_FLOAT): doc: | @@ -51,7 +59,8 @@ NXsas: enumeration: [nxcylinder, nxbox] size(NX_FLOAT): unit: NX_LENGTH - doc: "The collimation length." + doc: | + The collimation length. (NXdetector): data(NX_NUMBER): doc: | @@ -69,13 +78,16 @@ NXsas: dim: [[1, nXPixel], [2, nYPixel]] distance(NX_FLOAT): unit: NX_LENGTH - doc: "The distance between detector and sample." + doc: | + The distance between detector and sample. x_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: "Physical size of a pixel in x-direction." + doc: | + Physical size of a pixel in x-direction. y_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: "Physical size of a pixel in y-direction." + doc: | + Physical size of a pixel in y-direction. polar_angle(NX_FLOAT): unit: NX_ANGLE azimuthal_angle(NX_FLOAT): @@ -105,10 +117,12 @@ NXsas: the raw data, thus it is not required here. The instrument can provide an initial or nominal value to advise data reduction. name(NX_CHAR): - doc: "Name of the instrument actually used to perform the experiment." + doc: | + Name of the instrument actually used to perform the experiment. (NXsample): name: - doc: "Descriptive name of sample." + doc: | + Descriptive name of sample. aequatorial_angle(NX_FLOAT): unit: NX_ANGLE (NXmonitor): @@ -118,10 +132,12 @@ NXsas: (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "Preset value for time or monitor." + doc: | + Preset value for time or monitor. integral(NX_FLOAT): unit: NX_ANY - doc: "Total integral monitor counts." + doc: | + Total integral monitor counts. (NXdata): \@signal: doc: | diff --git a/applications/nyaml/NXsastof.yml b/applications/nyaml/NXsastof.yaml similarity index 70% rename from applications/nyaml/NXsastof.yml rename to applications/nyaml/NXsastof.yaml index 0d68e44e73..5b1ba08df2 100644 --- a/applications/nyaml/NXsastof.yml +++ b/applications/nyaml/NXsastof.yaml @@ -5,27 +5,38 @@ doc: | that use an area detector at a time-of-flight source. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nXPixel: "nXPixel description" - nYPixel: "nYPixel description" - nTOF: "nTOF description" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nXPixel: | + nXPixel description + + nYPixel: | + nYPixel description + + nTOF: | + nTOF description + category: application NXsastof: (NXentry): \@entry: - doc: "NeXus convention is to use 'entry1', 'entry2', ... for analysis software to locate each entry" + doc: | + NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry title: start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXsastof] instrument(NXinstrument): source(NXsource): type: - doc: "type of radiation source" + doc: | + type of radiation source name: - doc: "Name of the radiation source" + doc: | + Name of the radiation source probe: enumeration: [neutron, x-ray] collimator(NXcollimator): @@ -35,7 +46,8 @@ NXsastof: enumeration: [nxcylinder, nxbox] size(NX_FLOAT): unit: NX_LENGTH - doc: "The collimation length" + doc: | + The collimation length detector(NXdetector): data(NX_NUMBER): doc: | @@ -54,13 +66,16 @@ NXsastof: dim: [[1, nTOF]] distance(NX_FLOAT): unit: NX_LENGTH - doc: "The distance between detector and sample" + doc: | + The distance between detector and sample x_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: "Physical size of a pixel in x-direction" + doc: | + Physical size of a pixel in x-direction y_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: "Size of a pixel in y direction" + doc: | + Size of a pixel in y direction polar_angle(NX_FLOAT): unit: NX_ANGLE azimuthal_angle(NX_FLOAT): @@ -80,18 +95,22 @@ NXsastof: This is the y position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. name(NX_CHAR): - doc: "Name of the instrument actually used to perform the experiment" + doc: | + Name of the instrument actually used to perform the experiment sample(NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample aequatorial_angle(NX_FLOAT): unit: NX_ANGLE control(NXmonitor): mode: - doc: "Count to a preset value based on either clock time (timer) or received monitor counts (monitor)." + doc: | + Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor data(NX_INT): dimensions: rank: 1 diff --git a/applications/nyaml/NXscan.yml b/applications/nyaml/NXscan.yaml similarity index 87% rename from applications/nyaml/NXscan.yml rename to applications/nyaml/NXscan.yaml index 4d76ed58f4..cc4a6d3a9e 100644 --- a/applications/nyaml/NXscan.yml +++ b/applications/nyaml/NXscan.yaml @@ -24,11 +24,18 @@ doc: | * At each scan point, append new data from varied variables and the detector to the file. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" - xDim: "xDim description" - yDim: "yDim description" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + + xDim: | + xDim description + + yDim: | + yDim description + category: application NXscan: (NXentry): @@ -36,7 +43,8 @@ NXscan: start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition(NX_CHAR): - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXscan] (NXinstrument): (NXdetector): diff --git a/applications/nyaml/NXspe.yml b/applications/nyaml/NXspe.yaml similarity index 77% rename from applications/nyaml/NXspe.yml rename to applications/nyaml/NXspe.yaml index 6def063470..eaab805a07 100644 --- a/applications/nyaml/NXspe.yml +++ b/applications/nyaml/NXspe.yaml @@ -5,18 +5,22 @@ NXspe: (NXentry): program_name: definition: - doc: "Official NeXus NXDL schema to which this file conforms." + doc: | + Official NeXus NXDL schema to which this file conforms. \@version: enumeration: [NXspe] NXSPE_info(NXcollection): fixed_energy(NX_FLOAT): unit: NX_ENERGY - doc: "The fixed energy used for this file." + doc: | + The fixed energy used for this file. ki_over_kf_scaling(NX_BOOLEAN): - doc: "Indicates whether ki/kf scaling has been applied or not." + doc: | + Indicates whether ki/kf scaling has been applied or not. psi(NX_FLOAT): unit: NX_ANGLE - doc: "Orientation angle as expected in DCS-MSlice" + doc: | + Orientation angle as expected in DCS-MSlice data(NXdata): azimuthal(NX_FLOAT): unit: NX_ANGLE diff --git a/applications/nyaml/NXsqom.yml b/applications/nyaml/NXsqom.yaml similarity index 58% rename from applications/nyaml/NXsqom.yml rename to applications/nyaml/NXsqom.yaml index 84e71a4d97..5089617351 100644 --- a/applications/nyaml/NXsqom.yml +++ b/applications/nyaml/NXsqom.yaml @@ -6,16 +6,20 @@ doc: | intensity, table like. It is the task of a possible visualisation program to regrid this data in a sensible way. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + category: application NXsqom: (NXentry): \@entry: title: definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXsqom] instrument(NXinstrument): (NXsource): @@ -24,46 +28,56 @@ NXsqom: probe: enumeration: [neutron, x-ray, electron] name(NX_CHAR): - doc: "Name of the instrument from which this data was reduced." + doc: | + Name of the instrument from which this data was reduced. (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample reduction(NXprocess): program(NX_CHAR): version(NX_CHAR): input(NXparameters): filenames(NX_CHAR): - doc: "Raw data files used to generate this I(Q)" - doc: "Input parameters for the reduction program used" + doc: | + Raw data files used to generate this I(Q) + doc: | + Input parameters for the reduction program used output(NXparameters): - doc: "Eventual output parameters from the data reduction program used" + doc: | + Eventual output parameters from the data reduction program used (NXdata): data(NX_INT): - doc: "This is the intensity for each point in QE" + doc: | + This is the intensity for each point in QE dimensions: rank: 1 dim: [[1, nP]] qx(NX_NUMBER): unit: NX_WAVENUMBER - doc: "Positions for the first dimension of Q" + doc: | + Positions for the first dimension of Q dimensions: rank: 1 dim: [[1, nP]] qy(NX_NUMBER): unit: NX_WAVENUMBER - doc: "Positions for the the second dimension of Q" + doc: | + Positions for the the second dimension of Q dimensions: rank: 1 dim: [[1, nP]] qz(NX_NUMBER): unit: NX_WAVENUMBER - doc: "Positions for the the third dimension of Q" + doc: | + Positions for the the third dimension of Q dimensions: rank: 1 dim: [[1, nP]] en(NX_FLOAT): unit: NX_ENERGY - doc: "Values for the energy transfer for each point" + doc: | + Values for the energy transfer for each point dimensions: rank: 1 dim: [[1, nP]] diff --git a/applications/nyaml/NXstxm.yml b/applications/nyaml/NXstxm.yaml similarity index 88% rename from applications/nyaml/NXstxm.yml rename to applications/nyaml/NXstxm.yaml index 1bc47a79d2..2420cbab16 100644 --- a/applications/nyaml/NXstxm.yml +++ b/applications/nyaml/NXstxm.yaml @@ -14,13 +14,24 @@ doc: | are just sample_image scan types with reduced dimensions in the same way as single images have reduced E dimensions compared to image 'stacks'. symbols: - doc: | - These symbols will be used below to coordinate the shapes of the datasets. - nP: "Total number of scan points" - nE: "Number of photon energies scanned" - nX: "Number of pixels in X direction" - nY: "Number of pixels in Y direction" - detectorRank: "Rank of data array provided by the detector for a single measurement" + doc: | + These symbols will be used below to coordinate the shapes of the datasets. + + nP: | + Total number of scan points + + nE: | + Number of photon energies scanned + + nX: | + Number of pixels in X direction + + nY: | + Number of pixels in Y direction + + detectorRank: | + Rank of data array provided by the detector for a single measurement + category: application NXstxm: (NXentry): @@ -29,7 +40,8 @@ NXstxm: end_time(NX_DATE_TIME): definition(NX_CHAR): exists: [min, 1, max, 1] - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXstxm] (NXinstrument): exists: [min, 1, max, 1] @@ -65,21 +77,24 @@ NXstxm: NOTE: For each dimension > 1 there must exist a dim section such as: sample_x(NXdetector): exists: [min, 0, max, 1] - doc: "Measurements of the sample position from the x-axis interferometer." + doc: | + Measurements of the sample position from the x-axis interferometer. data(NX_FLOAT): dimensions: rank: 1 dim: [[1, nP]] sample_y(NXdetector): exists: [min, 0, max, 1] - doc: "Measurements of the sample position from the y-axis interferometer." + doc: | + Measurements of the sample position from the y-axis interferometer. data(NX_FLOAT): dimensions: rank: 1 dim: [[1, nP]] sample_z(NXdetector): exists: [min, 0, max, 1] - doc: "Measurements of the sample position from the z-axis interferometer." + doc: | + Measurements of the sample position from the z-axis interferometer. data(NX_FLOAT): dimensions: rank: 1 diff --git a/applications/nyaml/NXtas.yml b/applications/nyaml/NXtas.yaml similarity index 85% rename from applications/nyaml/NXtas.yml rename to applications/nyaml/NXtas.yaml index c2f464cdad..f9ed34031a 100644 --- a/applications/nyaml/NXtas.yml +++ b/applications/nyaml/NXtas.yaml @@ -4,16 +4,20 @@ doc: | It is for the trademark scan of the TAS, the Q-E scan. For your alignment scans use the rules in :ref:`NXscan`. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + category: application NXtas: entry(NXentry): title(NX_CHAR): start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXtas] (NXinstrument): (NXsource): @@ -59,7 +63,8 @@ NXtas: dim: [[1, nP]] (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample qh(NX_FLOAT): unit: NX_DIMENSIONLESS dimensions: @@ -117,12 +122,15 @@ NXtas: or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor data(NX_FLOAT): unit: NX_ANY - doc: "Total integral monitor counts" + doc: | + Total integral monitor counts dimensions: rank: 1 dim: [[1, nP]] (NXdata): - doc: "One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis" + doc: | + One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis diff --git a/applications/nyaml/NXtofnpd.yml b/applications/nyaml/NXtofnpd.yaml similarity index 77% rename from applications/nyaml/NXtofnpd.yml rename to applications/nyaml/NXtofnpd.yaml index 1e7b30f015..c6229fd02b 100644 --- a/applications/nyaml/NXtofnpd.yml +++ b/applications/nyaml/NXtofnpd.yaml @@ -1,17 +1,23 @@ doc: | This is a application definition for raw data from a TOF neutron powder diffractometer symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: "Number of detectors" - nTimeChan: "nTimeChan description" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nDet: | + Number of detectors + + nTimeChan: | + nTimeChan description + category: application NXtofnpd: entry(NXentry): title: start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXtofnpd] pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH @@ -34,7 +40,8 @@ NXtofnpd: dim: [[1, nDet]] distance(NX_FLOAT): unit: NX_LENGTH - doc: "distance to sample for each detector" + doc: | + distance to sample for each detector dimensions: rank: 1 dim: [[1, nDet]] @@ -45,19 +52,22 @@ NXtofnpd: dim: [[1, nTimeChan]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: "polar angle for each detector element" + doc: | + polar angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: "azimuthal angle for each detector element" + doc: | + azimuthal angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample (NXmonitor): mode: doc: | @@ -65,7 +75,8 @@ NXtofnpd: or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor distance(NX_FLOAT): unit: NX_LENGTH data(NX_INT): diff --git a/applications/nyaml/NXtofraw.yml b/applications/nyaml/NXtofraw.yaml similarity index 79% rename from applications/nyaml/NXtofraw.yml rename to applications/nyaml/NXtofraw.yaml index 2ca9095cbb..25309dfc00 100644 --- a/applications/nyaml/NXtofraw.yml +++ b/applications/nyaml/NXtofraw.yaml @@ -1,17 +1,23 @@ doc: | This is an application definition for raw data from a generic TOF instrument symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: "Number of detectors" - nTimeChan: "nTimeChan description" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nDet: | + Number of detectors + + nTimeChan: | + nTimeChan description + category: application NXtofraw: entry(NXentry): title: start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXtofraw] duration(NX_FLOAT): run_number(NX_INT): @@ -36,7 +42,8 @@ NXtofraw: dim: [[1, nDet]] distance(NX_FLOAT): unit: NX_LENGTH - doc: "distance to sample for each detector" + doc: | + distance to sample for each detector dimensions: rank: 1 dim: [[1, nDet]] @@ -47,19 +54,22 @@ NXtofraw: dim: [[1, nTimeChan]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: "polar angle for each detector element" + doc: | + polar angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: "azimuthal angle for each detector element" + doc: | + azimuthal angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample nature(NX_CHAR): enumeration: [powder, liquid, single crystal] (NXmonitor): @@ -69,7 +79,8 @@ NXtofraw: or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor distance(NX_FLOAT): unit: NX_LENGTH data(NX_INT): diff --git a/applications/nyaml/NXtofsingle.yml b/applications/nyaml/NXtofsingle.yaml similarity index 75% rename from applications/nyaml/NXtofsingle.yml rename to applications/nyaml/NXtofsingle.yaml index 51d16dd2eb..49e247b907 100644 --- a/applications/nyaml/NXtofsingle.yml +++ b/applications/nyaml/NXtofsingle.yaml @@ -1,19 +1,29 @@ doc: | This is a application definition for raw data from a generic TOF instrument symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - xSize: "xSize description" - ySize: "ySize description" - nDet: "Number of detectors" - nTimeChan: "nTimeChan description" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + xSize: | + xSize description + + ySize: | + ySize description + + nDet: | + Number of detectors + + nTimeChan: | + nTimeChan description + category: application NXtofsingle: entry(NXentry): title: start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXtofsingle] duration(NX_FLOAT): pre_sample_flightpath(NX_FLOAT): @@ -33,7 +43,8 @@ NXtofsingle: dim: [[1, xSize], [2, ySize], [3, nTimeChan]] distance(NX_FLOAT): unit: NX_LENGTH - doc: "Distance to sample for the center of the detector" + doc: | + Distance to sample for the center of the detector dimensions: rank: 1 dim: [[1, 1]] @@ -44,19 +55,22 @@ NXtofsingle: dim: [[1, nTimeChan]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: "polar angle for each detector element" + doc: | + polar angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: "azimuthal angle for each detector element" + doc: | + azimuthal angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample nature(NX_CHAR): enumeration: [powder, liquid, single crystal] (NXmonitor): @@ -66,7 +80,8 @@ NXtofsingle: or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor distance(NX_FLOAT): unit: NX_LENGTH data(NX_INT): diff --git a/applications/nyaml/NXtomo.yml b/applications/nyaml/NXtomo.yaml similarity index 87% rename from applications/nyaml/NXtomo.yml rename to applications/nyaml/NXtomo.yaml index 7280be28c0..82eb07c8b9 100644 --- a/applications/nyaml/NXtomo.yml +++ b/applications/nyaml/NXtomo.yaml @@ -5,11 +5,18 @@ doc: | a number of dark field images are measured, some bright field images and, of course the sample. In order to distinguish between them images carry a image_key. symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. - nFrames: "Number of frames" - xSize: "Number of pixels in X direction" - ySize: "Number of pixels in Y direction" + doc: | + These symbols will be used below to coordinate datasets with the same shape. + + nFrames: | + Number of frames + + xSize: | + Number of pixels in X direction + + ySize: | + Number of pixels in Y direction + category: application NXtomo: entry(NXentry): @@ -20,7 +27,8 @@ NXtomo: end_time(NX_DATE_TIME): exists: [min, 0, max, 1] definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXtomo] instrument(NXinstrument): (NXsource): @@ -60,14 +68,16 @@ NXtomo: distance(NX_FLOAT): exists: [min, 0, max, 1] unit: NX_LENGTH - doc: "Distance between detector and sample" + doc: | + Distance between detector and sample x_rotation_axis_pixel_position(NX_FLOAT): exists: [min, 0, max, 1] y_rotation_axis_pixel_position(NX_FLOAT): exists: [min, 0, max, 1] sample(NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE doc: | diff --git a/applications/nyaml/NXtomophase.yml b/applications/nyaml/NXtomophase.yaml similarity index 80% rename from applications/nyaml/NXtomophase.yml rename to applications/nyaml/NXtomophase.yaml index 2a3937f029..597404f74d 100644 --- a/applications/nyaml/NXtomophase.yml +++ b/applications/nyaml/NXtomophase.yaml @@ -5,13 +5,27 @@ doc: | some dark field images are measured, some bright field images and, of course the sample. In order to properly sort the order of the images taken, a sequence number is stored with each image. symbols: - doc: | - nBrightFrames: "Number of bright frames" - nDarkFrames: "Number of dark frames" - nSampleFrames: "Number of image (sample) frames" - nPhase: "Number of phase settings" - xSize: "Number of pixels in X direction" - ySize: "Number of pixels in Y direction" + doc: | + These symbols will be used below to coordinate datasets with the same shape. + + nBrightFrames: | + Number of bright frames + + nDarkFrames: | + Number of dark frames + + nSampleFrames: | + Number of image (sample) frames + + nPhase: | + Number of phase settings + + xSize: | + Number of pixels in X direction + + ySize: | + Number of pixels in Y direction + category: application NXtomophase: entry(NXentry): @@ -19,7 +33,8 @@ NXtomophase: start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXtomophase] instrument(NXinstrument): (NXsource): @@ -60,10 +75,12 @@ NXtomophase: unit: NX_LENGTH distance(NX_FLOAT): unit: NX_LENGTH - doc: "Distance between detector and sample" + doc: | + Distance between detector and sample sample(NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE dimensions: diff --git a/applications/nyaml/NXtomoproc.yml b/applications/nyaml/NXtomoproc.yaml similarity index 72% rename from applications/nyaml/NXtomoproc.yml rename to applications/nyaml/NXtomoproc.yaml index 7c05cf825d..64c1b9ec4e 100644 --- a/applications/nyaml/NXtomoproc.yml +++ b/applications/nyaml/NXtomoproc.yaml @@ -1,16 +1,25 @@ doc: | This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. symbols: - doc: | - nX: "Number of voxels in X direction" - nY: "Number of voxels in Y direction" - nZ: "Number of voxels in Z direction" + doc: | + These symbols will be used below to coordinate datasets with the same shape. + + nX: | + Number of voxels in X direction + + nY: | + Number of voxels in Y direction + + nZ: | + Number of voxels in Z direction + category: application NXtomoproc: entry(NXentry): title: definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXtomoproc] (NXinstrument): (NXsource): @@ -20,17 +29,22 @@ NXtomoproc: enumeration: [neutron, x-ray, electron] (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample reconstruction(NXprocess): program(NX_CHAR): - doc: "Name of the program used for reconstruction" + doc: | + Name of the program used for reconstruction version(NX_CHAR): - doc: "Version of the program used" + doc: | + Version of the program used date(NX_DATE_TIME): - doc: "Date and time of reconstruction processing." + doc: | + Date and time of reconstruction processing. parameters(NXparameters): raw_file(NX_CHAR): - doc: "Original raw data file this data was derived from" + doc: | + Original raw data file this data was derived from data(NXdata): data(NX_INT): doc: | diff --git a/applications/nyaml/NXxas.yml b/applications/nyaml/NXxas.yaml similarity index 68% rename from applications/nyaml/NXxas.yml rename to applications/nyaml/NXxas.yaml index c68e8140ec..341aab3580 100644 --- a/applications/nyaml/NXxas.yml +++ b/applications/nyaml/NXxas.yaml @@ -4,9 +4,12 @@ doc: | This is essentially a scan on energy versus incoming/ absorbed beam. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + category: application NXxas: (NXentry): @@ -17,7 +20,8 @@ NXxas: title: start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXxas] (NXinstrument): (NXsource): @@ -37,13 +41,15 @@ NXxas: dim: [[1, nP]] absorbed_beam(NXdetector): data(NX_NUMBER): - doc: "This data corresponds to the sample signal." + doc: | + This data corresponds to the sample signal. dimensions: rank: 1 dim: [[1, nP]] (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample (NXmonitor): mode: doc: | @@ -51,13 +57,16 @@ NXxas: or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor data(NX_NUMBER): - doc: "This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data``" + doc: | + This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` dimensions: rank: 1 dim: [[1, nP]] (NXdata): mode: - doc: "Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly)" + doc: | + Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) enumeration: [Total Electron Yield, Partial Electron Yield, Auger Electron Yield, Fluorescence Yield, Transmission] diff --git a/applications/nyaml/NXxasproc.yml b/applications/nyaml/NXxasproc.yaml similarity index 61% rename from applications/nyaml/NXxasproc.yml rename to applications/nyaml/NXxasproc.yaml index 5c450dd7a3..6954367493 100644 --- a/applications/nyaml/NXxasproc.yml +++ b/applications/nyaml/NXxasproc.yaml @@ -1,9 +1,12 @@ doc: | Processed data from XAS. This is energy versus I(incoming)/I(absorbed). symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + category: application NXxasproc: (NXentry): @@ -13,21 +16,27 @@ NXxasproc: for analysis software to locate each entry. title: definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXxasproc] (NXsample): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample XAS_data_reduction(NXprocess): program(NX_CHAR): - doc: "Name of the program used for reconstruction" + doc: | + Name of the program used for reconstruction version(NX_CHAR): - doc: "Version of the program used" + doc: | + Version of the program used date(NX_DATE_TIME): - doc: "Date and time of reconstruction processing." + doc: | + Date and time of reconstruction processing. parameters(NXparameters): raw_file(NX_CHAR): - doc: "Original raw data file this data was derived from" + doc: | + Original raw data file this data was derived from (NXdata): energy: dimensions: diff --git a/applications/nyaml/NXxbase.yml b/applications/nyaml/NXxbase.yaml similarity index 80% rename from applications/nyaml/NXxbase.yml rename to applications/nyaml/NXxbase.yaml index a763c1fa10..a948d58d3d 100644 --- a/applications/nyaml/NXxbase.yml +++ b/applications/nyaml/NXxbase.yaml @@ -1,18 +1,26 @@ doc: | This definition covers the common parts of all monochromatic single crystal raw data application definitions. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" - nXPixels: "Number of X pixels" - nYPixels: "Number of Y pixels" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + + nXPixels: | + Number of X pixels + + nYPixels: | + Number of Y pixels + category: application NXxbase: entry(NXentry): title: start_time(NX_DATE_TIME): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXxbase] instrument(NXinstrument): source(NXsource): @@ -54,7 +62,8 @@ NXxbase: This number helps concatenating such measurements. sample(NXsample): name(NX_CHAR): - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample orientation_matrix(NX_FLOAT): doc: | The orientation matrix according to Busing and @@ -80,13 +89,16 @@ NXxbase: dim: [[1, nP]] x_translation(NX_FLOAT): unit: NX_LENGTH - doc: "Translation of the sample along the X-direction of the laboratory coordinate system" + doc: | + Translation of the sample along the X-direction of the laboratory coordinate system y_translation(NX_FLOAT): unit: NX_LENGTH - doc: "Translation of the sample along the Y-direction of the laboratory coordinate system" + doc: | + Translation of the sample along the Y-direction of the laboratory coordinate system distance(NX_FLOAT): unit: NX_LENGTH - doc: "Translation of the sample along the Z-direction of the laboratory coordinate system" + doc: | + Translation of the sample along the Z-direction of the laboratory coordinate system control(NXmonitor): mode: doc: | @@ -94,10 +106,12 @@ NXxbase: or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: "preset value for time or monitor" + doc: | + preset value for time or monitor integral(NX_FLOAT): unit: NX_ANY - doc: "Total integral monitor counts" + doc: | + Total integral monitor counts (NXdata): doc: | The name of this group id data if there is only diff --git a/applications/nyaml/NXxeuler.yml b/applications/nyaml/NXxeuler.yaml similarity index 86% rename from applications/nyaml/NXxeuler.yml rename to applications/nyaml/NXxeuler.yaml index b16eacd72c..3ad4ff9e5d 100644 --- a/applications/nyaml/NXxeuler.yml +++ b/applications/nyaml/NXxeuler.yaml @@ -5,14 +5,18 @@ doc: | of :ref:`NXxbase` plus the data defined here. All four angles are logged in order to support arbitrary scans in reciprocal space. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + category: application NXxeuler(NXxbase): entry(NXentry): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXxeuler] instrument(NXinstrument): detector(NXdetector): diff --git a/applications/nyaml/NXxkappa.yml b/applications/nyaml/NXxkappa.yaml similarity index 78% rename from applications/nyaml/NXxkappa.yml rename to applications/nyaml/NXxkappa.yaml index 670963c95a..5923a43f4b 100644 --- a/applications/nyaml/NXxkappa.yml +++ b/applications/nyaml/NXxkappa.yaml @@ -7,20 +7,25 @@ doc: | the content of :ref:`NXxbase` plus the data defined here. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + category: application NXxkappa(NXxbase): entry(NXentry): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXxkappa] instrument(NXinstrument): detector(NXdetector): polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: "The polar_angle (two theta) at each scan point" + doc: | + The polar_angle (two theta) at each scan point dimensions: rank: 1 dim: [[1, nP]] @@ -49,5 +54,6 @@ NXxkappa(NXxbase): dim: [[1, nP]] alpha(NX_FLOAT): unit: NX_ANGLE - doc: "This holds the inclination angle of the kappa arm." + doc: | + This holds the inclination angle of the kappa arm. name(NXdata): diff --git a/applications/nyaml/NXxlaue.yml b/applications/nyaml/NXxlaue.yaml similarity index 70% rename from applications/nyaml/NXxlaue.yml rename to applications/nyaml/NXxlaue.yaml index 269b8f3f18..c5ce9d10df 100644 --- a/applications/nyaml/NXxlaue.yml +++ b/applications/nyaml/NXxlaue.yaml @@ -4,20 +4,25 @@ doc: | This is the application definition for raw data from a single crystal laue camera. It extends :ref:`NXxrot`. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nE: "Number of energies" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nE: | + Number of energies + category: application NXxlaue(NXxrot): entry(NXentry): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXxlaue] instrument(NXinstrument): source(NXsource): distribution(NXdata): data: - doc: "expect ``signal=1 axes='energy'``" + doc: | + expect ``signal=1 axes="energy"`` dimensions: rank: 1 dim: [[1, nE]] diff --git a/applications/nyaml/NXxlaueplate.yml b/applications/nyaml/NXxlaueplate.yaml similarity index 75% rename from applications/nyaml/NXxlaueplate.yml rename to applications/nyaml/NXxlaueplate.yaml index b10564c724..9994427bb2 100644 --- a/applications/nyaml/NXxlaueplate.yml +++ b/applications/nyaml/NXxlaueplate.yaml @@ -7,10 +7,12 @@ category: application NXxlaueplate(NXxlaue): entry(NXentry): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXxlaueplate] instrument(NXinstrument): detector(NXdetector): diameter(NX_FLOAT): unit: NX_LENGTH - doc: "The diameter of a cylindrical detector" + doc: | + The diameter of a cylindrical detector diff --git a/applications/nyaml/NXxnb.yml b/applications/nyaml/NXxnb.yaml similarity index 85% rename from applications/nyaml/NXxnb.yml rename to applications/nyaml/NXxnb.yaml index 5589d59901..4a895b13b2 100644 --- a/applications/nyaml/NXxnb.yml +++ b/applications/nyaml/NXxnb.yaml @@ -9,14 +9,18 @@ doc: | logged in order to support arbitrary scans in reciprocal space. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + category: application NXxnb(NXxbase): entry(NXentry): definition: - doc: "Official NeXus NXDL schema to which this file conforms" + doc: | + Official NeXus NXDL schema to which this file conforms enumeration: [NXxnb] instrument(NXinstrument): detector(NXdetector): diff --git a/applications/nyaml/NXxrot.yml b/applications/nyaml/NXxrot.yaml similarity index 72% rename from applications/nyaml/NXxrot.yml rename to applications/nyaml/NXxrot.yaml index 3bc1672c6a..0b44ab840a 100644 --- a/applications/nyaml/NXxrot.yml +++ b/applications/nyaml/NXxrot.yaml @@ -5,20 +5,25 @@ doc: | It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` plus the data defined here. symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: "Number of points" + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + category: application NXxrot(NXxbase): entry(NXentry): definition: - doc: "Official NeXus NXDL schema to which this file conforms." + doc: | + Official NeXus NXDL schema to which this file conforms. enumeration: [NXxrot] instrument(NXinstrument): detector(NXdetector): polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: "The polar_angle (two theta) where the detector is placed." + doc: | + The polar_angle (two theta) where the detector is placed. beam_center_x(NX_FLOAT): unit: NX_LENGTH doc: | @@ -35,13 +40,15 @@ NXxrot(NXxbase): sample(NXsample): rotation_angle(NX_FLOAT): unit: NX_ANGLE - doc: "This is an array holding the sample rotation start angle at each scan point" + doc: | + This is an array holding the sample rotation start angle at each scan point dimensions: rank: 1 dim: [[1, nP]] rotation_angle_step(NX_FLOAT): unit: NX_ANGLE - doc: "This is an array holding the step made for sample rotation angle at each scan point" + doc: | + This is an array holding the step made for sample rotation angle at each scan point dimensions: rank: 1 dim: [[1, nP]] From b79b76ce077e8d269317ea6d486fb99b9fb6e99b Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 15 Feb 2023 15:23:16 +0100 Subject: [PATCH 101/203] Renams to yaml and regenerates nxdls --- base_classes/nyaml/NXaperture.nxdl.xml | 2 +- .../nyaml/{NXaperture.yml => NXaperture.yaml} | 0 base_classes/nyaml/NXbeam.nxdl.xml | 2 +- .../nyaml/{NXbeam.yml => NXbeam.yaml} | 0 base_classes/nyaml/NXdetector.nxdl.xml | 2 +- .../nyaml/{NXdetector.yml => NXdetector.yaml} | 0 base_classes/nyaml/NXentry.nxdl.xml | 2 +- .../nyaml/{NXentry.yml => NXentry.yaml} | 0 base_classes/nyaml/NXinstrument.nxdl.xml | 2 +- .../{NXinstrument.yml => NXinstrument.yaml} | 0 base_classes/nyaml/NXprocess.nxdl.xml | 2 +- .../nyaml/{NXprocess.yml => NXprocess.yaml} | 0 base_classes/nyaml/NXsample.nxdl.xml | 2 +- .../nyaml/{NXsample.yml => NXsample.yaml} | 0 base_classes/nyaml/NXsource.nxdl.xml | 2 +- .../nyaml/{NXsource.yml => NXsource.yaml} | 0 .../nyaml/NXaperture_em.nxdl.xml | 2 +- contributed_definitions/nyaml/NXapm.nxdl.xml | 222 +++++------ .../nyaml/NXapm_input_ranging.nxdl.xml | 2 +- .../nyaml/NXapm_input_reconstruction.nxdl.xml | 2 +- .../NXapm_paraprobe_config_clusterer.nxdl.xml | 46 +-- .../NXapm_paraprobe_config_distancer.nxdl.xml | 26 +- ...Xapm_paraprobe_config_intersector.nxdl.xml | 20 +- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 40 +- .../NXapm_paraprobe_config_ranger.nxdl.xml | 30 +- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 34 +- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 24 +- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 26 +- ...NXapm_paraprobe_config_transcoder.nxdl.xml | 6 +- .../NXapm_paraprobe_results_ranger.nxdl.xml | 106 +++--- ...Xapm_paraprobe_results_transcoder.nxdl.xml | 92 ++--- .../nyaml/NXatom_set.nxdl.xml | 2 +- .../nyaml/NXcalibration.nxdl.xml | 2 +- .../{NXcalibration.yml => NXcalibration.yaml} | 0 .../nyaml/NXcg_alpha_shape.nxdl.xml | 2 +- .../nyaml/NXcg_cylinder_set.nxdl.xml | 2 +- .../nyaml/NXcg_ellipsoid_set.nxdl.xml | 2 +- .../NXcg_face_list_data_structure.nxdl.xml | 2 +- .../nyaml/NXcg_geodesic_mesh.nxdl.xml | 2 +- .../nyaml/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- .../nyaml/NXcg_hexahedron_set.nxdl.xml | 2 +- .../nyaml/NXcg_isocontour.nxdl.xml | 2 +- .../nyaml/NXcg_marching_cubes.nxdl.xml | 2 +- .../nyaml/NXcg_parallelogram_set.nxdl.xml | 2 +- .../nyaml/NXcg_point_set.nxdl.xml | 2 +- .../nyaml/NXcg_polygon_set.nxdl.xml | 2 +- .../nyaml/NXcg_polyhedron_set.nxdl.xml | 2 +- .../nyaml/NXcg_polyline_set.nxdl.xml | 2 +- .../nyaml/NXcg_roi_set.nxdl.xml | 2 +- .../nyaml/NXcg_sphere_set.nxdl.xml | 2 +- .../nyaml/NXcg_tetrahedron_set.nxdl.xml | 2 +- .../nyaml/NXcg_triangle_set.nxdl.xml | 2 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- .../nyaml/NXcg_unit_normal_set.nxdl.xml | 2 +- .../nyaml/NXchamber.nxdl.xml | 2 +- .../nyaml/NXclustering.nxdl.xml | 2 +- .../nyaml/NXcollectioncolumn.nxdl.xml | 2 +- ...tioncolumn.yml => NXcollectioncolumn.yaml} | 0 .../nyaml/NXcoordinate_system_set.nxdl.xml | 2 +- .../nyaml/NXcorrector_cs.nxdl.xml | 2 +- .../nyaml/NXcs_computer.nxdl.xml | 2 +- .../nyaml/NXcs_cpu.nxdl.xml | 2 +- .../nyaml/NXcs_filter_boolean_mask.nxdl.xml | 2 +- .../nyaml/NXcs_gpu.nxdl.xml | 2 +- .../nyaml/NXcs_io_obj.nxdl.xml | 2 +- .../nyaml/NXcs_io_sys.nxdl.xml | 2 +- .../nyaml/NXcs_mm_sys.nxdl.xml | 2 +- .../nyaml/NXcs_prng.nxdl.xml | 2 +- .../nyaml/NXcs_profiling.nxdl.xml | 2 +- .../nyaml/NXcs_profiling_event.nxdl.xml | 2 +- .../nyaml/NXdeflector.nxdl.xml | 2 +- .../{NXdeflector.yml => NXdeflector.yaml} | 0 .../nyaml/NXdelocalization.nxdl.xml | 2 +- .../nyaml/NXdistortion.nxdl.xml | 2 +- .../{NXdistortion.yml => NXdistortion.yaml} | 0 .../nyaml/NXebeam_column.nxdl.xml | 2 +- .../nyaml/NXelectronanalyser.nxdl.xml | 2 +- ...onanalyser.yml => NXelectronanalyser.yaml} | 0 .../nyaml/NXellipsometry.nxdl.xml | 92 ++--- contributed_definitions/nyaml/NXem.nxdl.xml | 360 +++++++++--------- .../nyaml/NXenergydispersion.nxdl.xml | 2 +- ...dispersion.yml => NXenergydispersion.yaml} | 0 .../nyaml/NXevent_data_em.nxdl.xml | 2 +- .../nyaml/NXevent_data_em_set.nxdl.xml | 2 +- .../nyaml/NXfabrication.nxdl.xml | 8 +- .../nyaml/NXgraph_edge_set.nxdl.xml | 2 +- .../nyaml/NXgraph_node_set.nxdl.xml | 2 +- .../nyaml/NXgraph_root.nxdl.xml | 2 +- .../nyaml/NXibeam_column.nxdl.xml | 2 +- .../nyaml/NXimage_set_em_adf.nxdl.xml | 2 +- contributed_definitions/nyaml/NXion.nxdl.xml | 2 +- .../nyaml/NXiv_temp.nxdl.xml | 2 +- .../nyaml/NXlens_em.nxdl.xml | 39 +- contributed_definitions/nyaml/NXlens_em.yaml | 54 +-- contributed_definitions/nyaml/NXlens_em.yml | 36 -- .../nyaml/NXliquid_jet.nxdl.xml | 2 +- .../{NXliquid_jet.yml => NXliquid_jet.yaml} | 0 .../nyaml/NXmanipulator.nxdl.xml | 2 +- .../{NXmanipulator.yml => NXmanipulator.yaml} | 0 .../nyaml/NXmatch_filter.nxdl.xml | 6 +- contributed_definitions/nyaml/NXmpes.nxdl.xml | 66 ++-- .../nyaml/{NXmpes.yml => NXmpes.yaml} | 0 .../nyaml/NXmpes_liquid.nxdl.xml | 66 ++-- .../{NXmpes_liquid.yml => NXmpes_liquid.yaml} | 0 .../nyaml/NXms_crystal_set.nxdl.xml | 2 +- .../nyaml/NXms_dislocation_set.nxdl.xml | 2 +- .../nyaml/NXms_interface_set.nxdl.xml | 2 +- .../nyaml/NXms_snapshot.nxdl.xml | 2 +- .../nyaml/NXms_snapshot_set.nxdl.xml | 2 +- .../nyaml/NXoptical_system_em.nxdl.xml | 2 +- .../nyaml/NXorientation_set.nxdl.xml | 2 +- contributed_definitions/nyaml/NXpeak.nxdl.xml | 2 +- contributed_definitions/nyaml/NXpid.nxdl.xml | 2 +- .../nyaml/NXpulser_apm.nxdl.xml | 2 +- contributed_definitions/nyaml/NXpump.nxdl.xml | 2 +- .../nyaml/NXreflectron.nxdl.xml | 2 +- .../nyaml/NXregistration.nxdl.xml | 2 +- ...NXregistration.yml => NXregistration.yaml} | 0 .../nyaml/NXscanbox_em.nxdl.xml | 2 +- .../nyaml/NXsensor_scan.nxdl.xml | 24 +- .../nyaml/NXslip_system_set.nxdl.xml | 2 +- .../nyaml/NXspatial_filter.nxdl.xml | 2 +- .../nyaml/NXspectrum_set_em_eels.nxdl.xml | 2 +- .../nyaml/NXspectrum_set_em_xray.nxdl.xml | 2 +- .../nyaml/NXspindispersion.nxdl.xml | 2 +- ...indispersion.yml => NXspindispersion.yaml} | 0 .../nyaml/NXstage_lab.nxdl.xml | 2 +- .../nyaml/NXsubsampling_filter.nxdl.xml | 4 +- .../nyaml/NXtransmission.nxdl.xml | 32 +- ...NXtransmission.yml => NXtransmission.yaml} | 0 131 files changed, 785 insertions(+), 846 deletions(-) rename base_classes/nyaml/{NXaperture.yml => NXaperture.yaml} (100%) rename base_classes/nyaml/{NXbeam.yml => NXbeam.yaml} (100%) rename base_classes/nyaml/{NXdetector.yml => NXdetector.yaml} (100%) rename base_classes/nyaml/{NXentry.yml => NXentry.yaml} (100%) rename base_classes/nyaml/{NXinstrument.yml => NXinstrument.yaml} (100%) rename base_classes/nyaml/{NXprocess.yml => NXprocess.yaml} (100%) rename base_classes/nyaml/{NXsample.yml => NXsample.yaml} (100%) rename base_classes/nyaml/{NXsource.yml => NXsource.yaml} (100%) rename contributed_definitions/nyaml/{NXcalibration.yml => NXcalibration.yaml} (100%) rename contributed_definitions/nyaml/{NXcollectioncolumn.yml => NXcollectioncolumn.yaml} (100%) rename contributed_definitions/nyaml/{NXdeflector.yml => NXdeflector.yaml} (100%) rename contributed_definitions/nyaml/{NXdistortion.yml => NXdistortion.yaml} (100%) rename contributed_definitions/nyaml/{NXelectronanalyser.yml => NXelectronanalyser.yaml} (100%) rename contributed_definitions/nyaml/{NXenergydispersion.yml => NXenergydispersion.yaml} (100%) delete mode 100644 contributed_definitions/nyaml/NXlens_em.yml rename contributed_definitions/nyaml/{NXliquid_jet.yml => NXliquid_jet.yaml} (100%) rename contributed_definitions/nyaml/{NXmanipulator.yml => NXmanipulator.yaml} (100%) rename contributed_definitions/nyaml/{NXmpes.yml => NXmpes.yaml} (100%) rename contributed_definitions/nyaml/{NXmpes_liquid.yml => NXmpes_liquid.yaml} (100%) rename contributed_definitions/nyaml/{NXregistration.yml => NXregistration.yaml} (100%) rename contributed_definitions/nyaml/{NXspindispersion.yml => NXspindispersion.yaml} (100%) rename contributed_definitions/nyaml/{NXtransmission.yml => NXtransmission.yaml} (100%) diff --git a/base_classes/nyaml/NXaperture.nxdl.xml b/base_classes/nyaml/NXaperture.nxdl.xml index 6877dc01a6..ff461163a0 100644 --- a/base_classes/nyaml/NXaperture.nxdl.xml +++ b/base_classes/nyaml/NXaperture.nxdl.xml @@ -1,6 +1,6 @@ - + A beamline aperture diff --git a/base_classes/nyaml/NXaperture.yml b/base_classes/nyaml/NXaperture.yaml similarity index 100% rename from base_classes/nyaml/NXaperture.yml rename to base_classes/nyaml/NXaperture.yaml diff --git a/base_classes/nyaml/NXbeam.nxdl.xml b/base_classes/nyaml/NXbeam.nxdl.xml index 14b560bf19..d96252f722 100644 --- a/base_classes/nyaml/NXbeam.nxdl.xml +++ b/base_classes/nyaml/NXbeam.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/base_classes/nyaml/NXbeam.yml b/base_classes/nyaml/NXbeam.yaml similarity index 100% rename from base_classes/nyaml/NXbeam.yml rename to base_classes/nyaml/NXbeam.yaml diff --git a/base_classes/nyaml/NXdetector.nxdl.xml b/base_classes/nyaml/NXdetector.nxdl.xml index d5df7c8c66..f2bb8fbb8d 100644 --- a/base_classes/nyaml/NXdetector.nxdl.xml +++ b/base_classes/nyaml/NXdetector.nxdl.xml @@ -1,6 +1,6 @@ - + These symbols will be used below to coordinate datasets with the same diff --git a/base_classes/nyaml/NXdetector.yml b/base_classes/nyaml/NXdetector.yaml similarity index 100% rename from base_classes/nyaml/NXdetector.yml rename to base_classes/nyaml/NXdetector.yaml diff --git a/base_classes/nyaml/NXentry.nxdl.xml b/base_classes/nyaml/NXentry.nxdl.xml index b062a10d3d..7f6ac069a3 100644 --- a/base_classes/nyaml/NXentry.nxdl.xml +++ b/base_classes/nyaml/NXentry.nxdl.xml @@ -1,6 +1,6 @@ - + (**required**) :ref:`NXentry` describes the measurement. diff --git a/base_classes/nyaml/NXentry.yml b/base_classes/nyaml/NXentry.yaml similarity index 100% rename from base_classes/nyaml/NXentry.yml rename to base_classes/nyaml/NXentry.yaml diff --git a/base_classes/nyaml/NXinstrument.nxdl.xml b/base_classes/nyaml/NXinstrument.nxdl.xml index bec81c7a30..17b41d660d 100644 --- a/base_classes/nyaml/NXinstrument.nxdl.xml +++ b/base_classes/nyaml/NXinstrument.nxdl.xml @@ -1,6 +1,6 @@ - + Collection of the components of the instrument or beamline. Template of instrument descriptions comprising various beamline components. Each component diff --git a/base_classes/nyaml/NXinstrument.yml b/base_classes/nyaml/NXinstrument.yaml similarity index 100% rename from base_classes/nyaml/NXinstrument.yml rename to base_classes/nyaml/NXinstrument.yaml diff --git a/base_classes/nyaml/NXprocess.nxdl.xml b/base_classes/nyaml/NXprocess.nxdl.xml index 5b12ff4776..97701c4fa7 100644 --- a/base_classes/nyaml/NXprocess.nxdl.xml +++ b/base_classes/nyaml/NXprocess.nxdl.xml @@ -1,6 +1,6 @@ - + Document an event of data processing, reconstruction, or analysis for this data. diff --git a/base_classes/nyaml/NXprocess.yml b/base_classes/nyaml/NXprocess.yaml similarity index 100% rename from base_classes/nyaml/NXprocess.yml rename to base_classes/nyaml/NXprocess.yaml diff --git a/base_classes/nyaml/NXsample.nxdl.xml b/base_classes/nyaml/NXsample.nxdl.xml index 9c74b79383..240a31938a 100644 --- a/base_classes/nyaml/NXsample.nxdl.xml +++ b/base_classes/nyaml/NXsample.nxdl.xml @@ -1,6 +1,6 @@ - + symbolic array lengths to be coordinated between various fields diff --git a/base_classes/nyaml/NXsample.yml b/base_classes/nyaml/NXsample.yaml similarity index 100% rename from base_classes/nyaml/NXsample.yml rename to base_classes/nyaml/NXsample.yaml diff --git a/base_classes/nyaml/NXsource.nxdl.xml b/base_classes/nyaml/NXsource.nxdl.xml index ae24b92e00..5fafb8acff 100644 --- a/base_classes/nyaml/NXsource.nxdl.xml +++ b/base_classes/nyaml/NXsource.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/base_classes/nyaml/NXsource.yml b/base_classes/nyaml/NXsource.yaml similarity index 100% rename from base_classes/nyaml/NXsource.yml rename to base_classes/nyaml/NXsource.yaml diff --git a/contributed_definitions/nyaml/NXaperture_em.nxdl.xml b/contributed_definitions/nyaml/NXaperture_em.nxdl.xml index e07b704b13..97d5323395 100644 --- a/contributed_definitions/nyaml/NXaperture_em.nxdl.xml +++ b/contributed_definitions/nyaml/NXaperture_em.nxdl.xml @@ -1,6 +1,6 @@ - + Details of an individual aperture for beams in electron microscopy. diff --git a/contributed_definitions/nyaml/NXapm.nxdl.xml b/contributed_definitions/nyaml/NXapm.nxdl.xml index 8ad9bf96c4..90488b7be0 100644 --- a/contributed_definitions/nyaml/NXapm.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -81,7 +81,7 @@ experiments to e.g. proposals. - + Free-text description about the experiment. @@ -91,7 +91,7 @@ experiment into this free-text description field. - + ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. @@ -111,7 +111,7 @@ collected to compute this event chain during the experiment. - + ISO 8601 time code with local time zone offset to UTC included when the microscope session ended. @@ -210,7 +210,7 @@ contact the respective people in the FAIRmat team to fix this. - + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. @@ -222,7 +222,7 @@ respective groups and sections. - + A small image that is representative of the entry; this can be an image taken from the dataset like a thumbnail of a spectrum. @@ -254,7 +254,7 @@ - + Contact information and eventually details of at least one person involved in the taking of the microscope session. This can be the @@ -266,42 +266,42 @@ Given (first) name and surname of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Postal address of the affiliation. - + Email address of the user at the point in time when the experiment was performed. Writing the most permanently used email is recommended. - + Globally unique identifier of the user as offered by services like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform - + Name of the OrcID or ResearcherID where the account under orcid is registered. - + (Business) (tele)phone number of the user at the point in time when the experiment was performed. - + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating @@ -309,12 +309,12 @@ are common examples. - + Account name that is associated with the user in social media platforms. - + Name of the social media platform where the account under social_media_name is registered. @@ -379,7 +379,7 @@ better be placed in resources which describe the sample_history. - + Possibility to give an abbreviation of the specimen name field. @@ -395,20 +395,20 @@ these from the sample history or from other data sources. - + Discouraged free-text field in case properly designed records for the sample_history are not available. - + Hard link to a location in the hierarchy of the NeXus file where the data for default plotting are stored. - + Container to hold different coordinate systems conventions. @@ -457,9 +457,9 @@ Consult the work of A. J. Breen and B. Gault and team for further details. - + - + Metadata and numerical data of the atom probe and the lab in which it @@ -483,15 +483,15 @@ etc. - + Location of the lab or place where the instrument is installed. Using GEOREF is preferred. - - + + @@ -501,7 +501,7 @@ THIS DOCSTRING NEEDS CLARIFICATION. - + The nominal diameter of the specimen ROI which is measured in the experiment. It is important to mention that the physical specimen @@ -510,12 +510,12 @@ - - - - + + + + - + Average pressure in the analysis chamber. @@ -528,12 +528,12 @@ Is a reflectron installed and was it used? - - - - + + + + - + @@ -544,13 +544,13 @@ Identifier of the local_electrode in an e.g. database. - - - - - + + + + + - + @@ -568,27 +568,27 @@ the detector type via free-text. - + Given name/alias. - + Given brand or model name by the manufacturer. - + Given hardware name/serial number or hash identifier issued by the manufacturer. - + Given name of the manufacturer. - + Amplitude of the signal detected on the multi-channel plate (MCP). @@ -605,9 +605,9 @@ - - - + + + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the @@ -622,17 +622,17 @@ * energy - - - + + + - - - + + + - - - + + + @@ -643,54 +643,54 @@ - - - - - + + + + + - + Average pressure in the load_lock_chamber. - - - - - + + + + + - + Average pressure in the buffer chamber. - - - - - + + + + + - - - - - + + + + + - - - - - + + + + + - + A place where details about the initial shape of the specimen can be stored. Ideally, here also data about the shape evolution @@ -780,26 +780,26 @@ - + Track time-dependent details over the course of the measurement about the buffer_chamber. - + Track time-dependent details over the course of the measurement about the load_lock_chamber. - + Track time-dependent details over the course of the measurement about the analysis_chamber. - + Details about where ions hit the ion_detector and data processing steps related to analog-to-digital conversion of detector signals @@ -828,7 +828,7 @@ - + Raw readings from the analog-to-digital-converter timing circuits of the detector wires. @@ -851,7 +851,7 @@ - + Data post-processing step which is, like the impact position analyses, usually executed in the integrated control software. This processing @@ -883,7 +883,7 @@ - + Number of pulses since the last detected ion pulse. For multi-hit records, after the first record, this is zero. @@ -892,7 +892,7 @@ - + Hit multiplicity. @@ -900,7 +900,7 @@ - + Number of pulses since the start of the atom probe run/evaporation sequence. @@ -909,7 +909,7 @@ - + Like impact position and hit multiplicity computations, ion filtering is a data post-processing step with which users @@ -943,7 +943,7 @@ - + Data post-processing step to correct for ion impact position flight path differences, detector biases, @@ -966,7 +966,7 @@ - + Raw time-of-flight data as read out from the acquisition software if these data are available and accessible. @@ -983,7 +983,7 @@ - + The key idea and algorithm of the voltage-and-bowl correction is qualitatively similar for instruments of different manufacturers @@ -1009,7 +1009,7 @@ - + Data post-processing step in which calibrated time-of-flight data (ToF) are interpreted into mass-to-charge-state ratios. @@ -1030,7 +1030,7 @@ - + Store vendor-specific calibration models here (if available). @@ -1044,7 +1044,7 @@ - + Data post-processing step to create a tomographic reconstruction of the specimen based on selected calibrated ion hit positions, @@ -1169,7 +1169,7 @@ - + Data post-processing step in which elemental, isotopic, and/or molecular identities are assigned to the ions. @@ -1211,7 +1211,7 @@ Currently a value of 32 is used. - + Specifies the computation of the mass-to-charge histogram. Usually mass-to-charge values are studied as an ensemble quantity, @@ -1272,7 +1272,7 @@ - + Details of the background model which was used to correct the total counts per bin into counts. @@ -1294,7 +1294,7 @@ - + How where peaks in the background-corrected in the histogram of mass-to-charge-state ratio values identified? @@ -1315,12 +1315,12 @@ - - + + - + Details about how peaks, with taking into account error models, were interpreted as ion types or not. @@ -1343,7 +1343,7 @@ - + diff --git a/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml b/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml index 5ccc9567c7..ef70f931c7 100644 --- a/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml @@ -1,6 +1,6 @@ - + Metadata to ranging definitions made for a dataset in atom probe microscopy. diff --git a/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml index a1d33d25c9..01d27cba0d 100644 --- a/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml @@ -1,6 +1,6 @@ - + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml index 8f0db4b2c2..cf4dcd5eca 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -48,13 +48,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -70,7 +70,7 @@ How many clustering processes should the tool execute. - + This process maps results from cluster analyses performed with IVAS/APSuite into an interoperable representation. Specifically in this process @@ -108,9 +108,9 @@ - - - + + + @@ -118,7 +118,7 @@ - + @@ -126,22 +126,22 @@ - + - + - - - + + + Name of HDF5 file which stores reconstructed ion positions. @@ -215,7 +215,7 @@ - + This process performs a cluster analysis on a reconstructed dataset or a portion of the reconstruction. @@ -233,9 +233,9 @@ - - - + + + @@ -243,7 +243,7 @@ - + @@ -251,22 +251,22 @@ - + - + - - - + + + Name of the algorithm. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml index b653e4a285..62e1a5b672 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -44,13 +44,13 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -74,9 +74,9 @@ - - - + + + @@ -84,7 +84,7 @@ - + @@ -92,22 +92,22 @@ - + - + - - - + + + Compute for all filtered points, e.g. ions of the point set @@ -180,7 +180,7 @@ specifies the array of facet indices. - + Absolute HDF5 path to the dataset which specifies the array of facet normal vectors. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml index 3401650db5..78ace96211 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,13 +43,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -142,7 +142,7 @@ perform as part of the high-throughput analysis. - + Tracking is the process of building logical relations between objects based on proximity and mesh intersections. For each time step pairs @@ -219,20 +219,20 @@ respectively from. - + Like groupname_object_geometry_data but for the proxies. Triangulated surface meshes of proxies have to be formatted in the same manner as objects. - + Like groupname_proxy_supplementary_data but for the interior proxies. Leave an empty string if proxies should not be used. - + Like groupname_proxy_supplementary_data but for the exterior proxies. Leave an empty string if proxies should not be used. @@ -307,7 +307,7 @@ respectively from. - + Like groupname_object_geometry_data but for the proxies. Triangulated surface meshes of proxies have to be formatted @@ -315,13 +315,13 @@ be used. - + Like groupname_proxy_supplementary_data but for the interior proxies. Leave an empty string if proxies should not be used. - + Like groupname_proxy_supplementary_data but for the exterior proxies. Leave an empty string if proxies should not be used. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml index 34f6168404..283786be82 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -63,13 +63,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -99,9 +99,9 @@ - - - + + + @@ -109,7 +109,7 @@ - + @@ -117,25 +117,25 @@ - + - + - - + + - + The tool enables to inject a previously computed triangle soup or @@ -170,7 +170,7 @@ - + The tool enables to inject precomputed distance information for each point/ion which can be used for further post-processing and analysis. @@ -200,7 +200,7 @@ files are executed as part of the high-throughput analysis. - + Discretization of the ion point cloud on a three-dimensional grid. @@ -298,7 +298,7 @@ Specifies if the tool should report the delocalization 3D field values. - + Optional computation of iso-surfaces after each computed delocalization to identify for instance objects in the microstructure @@ -565,7 +565,7 @@ - + Analyses of interfacial excess. @@ -643,7 +643,7 @@ - + The interface model is the result of a previous (set of) processing steps as a result of which the user has created a triangulated @@ -725,7 +725,7 @@ - + Create a simple principle component analysis (PCA) to mesh a free-standing interface patch through a point cloud of decorating solutes. @@ -865,7 +865,7 @@ - + Functionalities for placing regions-of-interest (ROIs) in the dataset or at specific microstructural features to characterize composition @@ -948,7 +948,7 @@ - + The tool enables to inject precomputed distance information for each point which can be used for further post-processing and analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml index 84b97864e8..7a501c184f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -55,13 +55,13 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -71,7 +71,7 @@ How many task to perform? - + How many range_with_existent_iontypes processes should @@ -84,7 +84,7 @@ the tool execute as part of the analysis. - + @@ -98,9 +98,9 @@ - - - + + + @@ -108,7 +108,7 @@ - + @@ -116,24 +116,24 @@ - + - + - - - + + + - + A list of pairs of number of protons and either the value 0 (per row) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml index c0a76168cf..ab0fad6e93 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,13 +53,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -76,7 +76,7 @@ the tool execute as part of the analysis. - + @@ -90,9 +90,9 @@ - - - + + + @@ -100,7 +100,7 @@ - + @@ -108,23 +108,23 @@ - + - + - - - - + + + + The tool enables to inject precomputed distances of each ion to a representation of the edge of the dataset which can be used to @@ -145,7 +145,7 @@ - + In addition to spatial filtering, and considering how far ions lie to the edge of the dataset, it is possible to restrict the analyses @@ -171,7 +171,7 @@ iontype labels randomly across the entire set of ions. - + @@ -259,7 +259,7 @@ Specifies which spatial statistics to compute. - + Compute k-th nearest neighbour statistics. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml index 7c3878ed78..be912d2151 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -49,13 +49,13 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -80,9 +80,9 @@ - - - + + + @@ -90,7 +90,7 @@ - + @@ -98,22 +98,22 @@ - + - + - - - + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml index 9a62f065fb..222d79fb02 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -38,13 +38,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -74,9 +74,9 @@ - - - + + + @@ -84,7 +84,7 @@ - + @@ -92,23 +92,23 @@ - + - + - - - - + + + + The tool enables to inject precomputed distance information for each point which can be used for further post-processing and analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml index eb52a23f27..f81c2d7fac 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -38,13 +38,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml index adfe091c0f..45b31c42f2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -48,13 +48,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -76,27 +76,27 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - + + + + + + + + + - + Details about the coordinate system conventions used. - + The individual coordinate systems which used. fields should be prefixed with a prefix taken from an @@ -111,17 +111,17 @@ - - + + Paraprobe-ranger loads the iontypes and evaluates for each ion on which iontype it matches. If it matches on none, the ion is considered of the default unknown type with a 0 as its respective value in the iontypes array. - + - + @@ -135,7 +135,7 @@ - + Paraprobe-ranger performs a combinatorial search over all possible or a reduced set of nuclids to identify @@ -161,7 +161,7 @@ - + The mass of each molecular ion without considering relativistic or quantum effects. @@ -178,7 +178,7 @@ - + The product of the natural abundance of the isotopes building each molecular ion. Further details are available in @@ -188,7 +188,7 @@ - + The product of the natural abundance of the isotopes building each molecular ion. Further details are available in @@ -198,7 +198,7 @@ - + The number of disjoint nuclids for each molecular ion. @@ -206,7 +206,7 @@ - + The number of nuclids for each molecular ion. @@ -216,51 +216,51 @@ - - - - + + + + - - + + - - - - - - + + + + + + - - - - - + + + + + - + - - + + - - - - + + + + - - + + @@ -281,8 +281,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml index e66cdeb45f..5d56f97b48 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -60,13 +60,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -88,27 +88,27 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - + + + + + + + + + Details about the coordinate system conventions used. - + The individual coordinate systems which should be used. Field names should be prefixed with the following controlled terms @@ -124,8 +124,8 @@ - - + + An array of triplets of integers which can serve as a supplementary array for Paraview to display the reconstruction. The XDMF datatype @@ -267,60 +267,60 @@ Details about how peaks, with taking into account error models, were interpreted as ion types or not. - + - + - - - - + + + + - - + + - - - - - - + + + + + + - - - - - + + + + + - + - - + + - - - - + + + + - - + + @@ -341,8 +341,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/nyaml/NXatom_set.nxdl.xml b/contributed_definitions/nyaml/NXatom_set.nxdl.xml index 5d0997de0b..3c6e88652e 100644 --- a/contributed_definitions/nyaml/NXatom_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXatom_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcalibration.nxdl.xml b/contributed_definitions/nyaml/NXcalibration.nxdl.xml index 16e54bd054..f5bbee3412 100644 --- a/contributed_definitions/nyaml/NXcalibration.nxdl.xml +++ b/contributed_definitions/nyaml/NXcalibration.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/contributed_definitions/nyaml/NXcalibration.yml b/contributed_definitions/nyaml/NXcalibration.yaml similarity index 100% rename from contributed_definitions/nyaml/NXcalibration.yml rename to contributed_definitions/nyaml/NXcalibration.yaml diff --git a/contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml b/contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml index 82271950d3..ca0b4467a4 100644 --- a/contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml index d1628ba45c..8cf1c2fb2b 100644 --- a/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml index 34fb36bcb2..26edc57d28 100644 --- a/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml index abe8d791e7..1cbbc56d88 100644 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml index 67c969d3e0..da110c3645 100644 --- a/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_grid.nxdl.xml b/contributed_definitions/nyaml/NXcg_grid.nxdl.xml index 92e86a4abe..f26e4fb98c 100644 --- a/contributed_definitions/nyaml/NXcg_grid.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_grid.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml index fe3a1bc18e..46722e18de 100644 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml index 887c34fbdc..43976dc71f 100644 --- a/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml b/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml index b11f04e6e9..9164f7c68a 100644 --- a/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml index 09037986a5..10604d1867 100644 --- a/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml index 9f6bc830e1..8b9f7bcc09 100644 --- a/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml index 889c296035..21967d7df5 100644 --- a/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml index e84ad842f6..ab50c22e8f 100644 --- a/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml index ded991b30c..d037b06337 100644 --- a/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml index e8f67207a4..cda26aeee0 100644 --- a/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml index 246bfbcc6d..d9c4e9a275 100644 --- a/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml index c267c04dd6..94143d5290 100644 --- a/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml index 40a555b63d..c9972fda6c 100644 --- a/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml index cbbdf3e1c8..547619af98 100644 --- a/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml index 8b38e0736d..3b68642b7c 100644 --- a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml index 278021f38c..9ca1d2cf8f 100644 --- a/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXchamber.nxdl.xml b/contributed_definitions/nyaml/NXchamber.nxdl.xml index f146141a4e..af9dcc11d5 100644 --- a/contributed_definitions/nyaml/NXchamber.nxdl.xml +++ b/contributed_definitions/nyaml/NXchamber.nxdl.xml @@ -1,6 +1,6 @@ - + Component of an instrument to store or place objects and specimens. diff --git a/contributed_definitions/nyaml/NXclustering.nxdl.xml b/contributed_definitions/nyaml/NXclustering.nxdl.xml index 475b21e477..b720d1c892 100644 --- a/contributed_definitions/nyaml/NXclustering.nxdl.xml +++ b/contributed_definitions/nyaml/NXclustering.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml b/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml index 13e0d213f3..393de7efb6 100644 --- a/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml @@ -1,6 +1,6 @@ - + Subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yml b/contributed_definitions/nyaml/NXcollectioncolumn.yaml similarity index 100% rename from contributed_definitions/nyaml/NXcollectioncolumn.yml rename to contributed_definitions/nyaml/NXcollectioncolumn.yaml diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml index 3e1d15e101..87d6d5dee7 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml @@ -1,6 +1,6 @@ - + Container to hold different coordinate systems conventions. diff --git a/contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml b/contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml index 8b6516486a..0cf6de7b48 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml @@ -1,6 +1,6 @@ - + Corrector for aberrations in an electron microscope. diff --git a/contributed_definitions/nyaml/NXcs_computer.nxdl.xml b/contributed_definitions/nyaml/NXcs_computer.nxdl.xml index eb94e16498..9412c92a45 100644 --- a/contributed_definitions/nyaml/NXcs_computer.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_computer.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_cpu.nxdl.xml b/contributed_definitions/nyaml/NXcs_cpu.nxdl.xml index 33045fdc71..1ea1ad4740 100644 --- a/contributed_definitions/nyaml/NXcs_cpu.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_cpu.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml index fd360d2982..ab05cc23b4 100644 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml b/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml index 178671d13a..8cb1190ad2 100644 --- a/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml b/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml index 90fe381cce..b811a80d44 100644 --- a/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml b/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml index 4a06897cdd..ef30143753 100644 --- a/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml b/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml index 45d07c2e98..30d33b03f6 100644 --- a/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_prng.nxdl.xml b/contributed_definitions/nyaml/NXcs_prng.nxdl.xml index 72ab372fa1..2b5d430b1a 100644 --- a/contributed_definitions/nyaml/NXcs_prng.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_prng.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml b/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml index 8877494263..305a061445 100644 --- a/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml b/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml index b4779cb6c4..53fa4e4874 100644 --- a/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXdeflector.nxdl.xml b/contributed_definitions/nyaml/NXdeflector.nxdl.xml index 1af741055d..8ad0e331e4 100644 --- a/contributed_definitions/nyaml/NXdeflector.nxdl.xml +++ b/contributed_definitions/nyaml/NXdeflector.nxdl.xml @@ -1,6 +1,6 @@ - + Deflectors as they are used e.g. in an electron analyser. diff --git a/contributed_definitions/nyaml/NXdeflector.yml b/contributed_definitions/nyaml/NXdeflector.yaml similarity index 100% rename from contributed_definitions/nyaml/NXdeflector.yml rename to contributed_definitions/nyaml/NXdeflector.yaml diff --git a/contributed_definitions/nyaml/NXdelocalization.nxdl.xml b/contributed_definitions/nyaml/NXdelocalization.nxdl.xml index 993baa9401..327eeca6e3 100644 --- a/contributed_definitions/nyaml/NXdelocalization.nxdl.xml +++ b/contributed_definitions/nyaml/NXdelocalization.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXdistortion.nxdl.xml b/contributed_definitions/nyaml/NXdistortion.nxdl.xml index 679d63a48b..88e1202ff0 100644 --- a/contributed_definitions/nyaml/NXdistortion.nxdl.xml +++ b/contributed_definitions/nyaml/NXdistortion.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/contributed_definitions/nyaml/NXdistortion.yml b/contributed_definitions/nyaml/NXdistortion.yaml similarity index 100% rename from contributed_definitions/nyaml/NXdistortion.yml rename to contributed_definitions/nyaml/NXdistortion.yaml diff --git a/contributed_definitions/nyaml/NXebeam_column.nxdl.xml b/contributed_definitions/nyaml/NXebeam_column.nxdl.xml index 697766a35b..e526c3e4bc 100644 --- a/contributed_definitions/nyaml/NXebeam_column.nxdl.xml +++ b/contributed_definitions/nyaml/NXebeam_column.nxdl.xml @@ -1,6 +1,6 @@ - + Container for components to form a controlled beam in electron microscopy. diff --git a/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml b/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml index 7b40cd372e..34772fcd68 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yml b/contributed_definitions/nyaml/NXelectronanalyser.yaml similarity index 100% rename from contributed_definitions/nyaml/NXelectronanalyser.yml rename to contributed_definitions/nyaml/NXelectronanalyser.yaml diff --git a/contributed_definitions/nyaml/NXellipsometry.nxdl.xml b/contributed_definitions/nyaml/NXellipsometry.nxdl.xml index 3a4df7cb89..093341990f 100644 --- a/contributed_definitions/nyaml/NXellipsometry.nxdl.xml +++ b/contributed_definitions/nyaml/NXellipsometry.nxdl.xml @@ -1,6 +1,6 @@ - + Variables used throughout the document, e.g. dimensions and important @@ -118,7 +118,7 @@ ii) The identifier enables to link experiments to e.g. proposals. - + A free-text description of the experiment. What is the aim of the experiment? The general procedure. @@ -129,7 +129,7 @@ Start time of the experiment. UTC offset should be specified. - + Commercial or otherwise defined given name to the program that was used to @@ -152,7 +152,7 @@ - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -179,12 +179,12 @@ Email address of the user. - + Author ID defined by https://orcid.org/. - + Official telephone number of the user. @@ -205,12 +205,12 @@ - + Name of the company which build the instrument - + ISO8601 date when the instrument was constructed. UTC offset should be specified. @@ -242,12 +242,12 @@ Were focussing probes (lenses) used? - + Were the recorded data corrected by the window effects of the lenses? - + Specify the angular spread caused by the focussing probes @@ -284,12 +284,12 @@ - + Ellipsometers require regular calibration to adjust the hardware parameters for proper zero values and background light compensation. - + If calibtration status is 'calibration time provided', specify the ISO8601 date when calibration was last performed before this measurement. UTC offset should @@ -391,19 +391,19 @@ - + A free-text field to provide information about the stage. - + The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with the angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). This transformation brings us from the NEXUS coordinates to the stage coordinates. Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) Last, provide the rotations of the sample - + If there is no motorized stage, we should at least qualify where the beam hits the sample and in what direction the sample stands in a free-text description, @@ -412,7 +412,7 @@ - + For environmental measurements, the environment (liquid, vapor, vacuum etc.) is enclosed in a cell or cryostat, which has windows both in the direction of the @@ -435,7 +435,7 @@ - + If you specified 'other' as window material, decsribe here what it is. @@ -471,7 +471,7 @@ - + Recorded data of a reference surface with and without window/medium. @@ -505,12 +505,12 @@ - + If you specified 'other' as detector type, please write down what it is. - + Define how many rotations of the rotating element were taken into account per spectrum. @@ -527,12 +527,12 @@ - + Rotation rate, if the revolution does not change during the measurement. - + Specify maximum and minimum values for the revolution. @@ -540,12 +540,12 @@ - + Minimum signal for which dynamic averaging is performed. - + Value for the minimum intensity chosen. Data points below this value might be skipped by the instrument @@ -569,7 +569,7 @@ - + Diffraction grating, as could be used in a monochromator. If two or more gratings were used, define the angular dispersion and the wavelength range @@ -577,37 +577,37 @@ do not overlap. The dispersion should be defined for the entire wavelength range of the experiment. - + Dispersion of the grating in nm/mm used. - + Minimum wavelength of the grating. - + Maximum wavelength of the grating. - + Spectral resolution of the instrument. - + Define the width of the monochromator slit in the subfield x_gap. - + Was the slit width fixed? - + If slit width was not fixed, define the maximum slit width. @@ -645,7 +645,7 @@ details of the sample and its preparation. - + ISO8601 date with time zone (UTC offset) specified. @@ -703,7 +703,7 @@ - + Specified uncertainties (errors) of the data described by data type. The structure is the same as for the measured data. @@ -716,7 +716,7 @@ - + An array of relative time points if a time series was recorded. @@ -736,7 +736,7 @@ air, UHV, etc.). - + Array of pairs of complex refractive indices of the medium for every measured wavelength. Only necessary if the measurement was performed not in air, or @@ -747,14 +747,14 @@ - + How many measurements were done varying the parameters? This forms an extra dimension beyond incident angle, time points and energy/wavelength (this is the length of the 4th dimension of the data). Defaults to 1. - + Indicates which parameter was changed. Its definition must exist below. The specified variable has to be number_of_runs long, providing the parameters for @@ -774,7 +774,7 @@ - + Was the sample modified using an optical source? Describe in this group the parameters of the optical excitation used. @@ -786,23 +786,23 @@ types, such as pulsed lasers, or lamps, a range may describe the source better. - + Specify the FWHM of the excitation - + How long was the sample excited. - + The integrated energy of light pulse. - + A sensor used to monitor an external condition. The value field contains the measured values. If it is constant within an error for every run then use only @@ -811,17 +811,17 @@ - + What parameters are derived from the above data. - + Light loss due to depolarization as a value in [0-1]. - + A default view of the data, in this case Psi vs. wavelength and the angles of incidence. If Psi does not exist, use other Mueller matrix elements, such as N, diff --git a/contributed_definitions/nyaml/NXem.nxdl.xml b/contributed_definitions/nyaml/NXem.nxdl.xml index e044a10c31..6980e40252 100644 --- a/contributed_definitions/nyaml/NXem.nxdl.xml +++ b/contributed_definitions/nyaml/NXem.nxdl.xml @@ -1,6 +1,6 @@ - + Characterization and session with one sample in an electron microscope. @@ -319,7 +319,7 @@ In effect, the application definition is a graph which describes how numerical data and (meta)data for EM research are related to one another. - + An at least as strong as SHA256 hashvalue of the file @@ -344,7 +344,7 @@ The identifier enables to link experiments to e.g. proposals. - + Free-text description about the experiment. @@ -354,7 +354,7 @@ into this free-text description field. - + ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. If the application demands that time @@ -374,7 +374,7 @@ provide additional pieces of information. - + ISO 8601 time code with local time zone offset to UTC included when the microscope session ended. @@ -412,14 +412,14 @@ - + Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold a compressed archive. - + A small image that is representative of the entry; this can be an image taken from the dataset like a thumbnail of a spectrum. @@ -430,7 +430,7 @@ - + Contact information and eventually details of at least one person involved in the taking of the microscope session. This can be the @@ -442,42 +442,42 @@ Given (first) name and surname of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Postal address of the affiliation. - + Email address of the user at the point in time when the experiment was performed. Writing the most permanently used email is recommended. - + Globally unique identifier of the user as offered by services like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform - + Name of the OrcID or ResearcherID where the account under orcid is registered. - + (Business) (tele)phone number of the user at the point in time when the experiment was performed. - + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating @@ -485,12 +485,12 @@ are common examples. - + Account name that is associated with the user in social media platforms. - + Name of the social media platform where the account under social_media_name is registered. @@ -571,7 +571,7 @@ describe the sample_history. - + Possibility to give an abbreviation or alias of the specimen name field. @@ -596,13 +596,13 @@ surface normal of the specimen is parallel to the optical axis. - + Discouraged free-text field in case properly designed records for the sample_history are not available. - + (Measured) density of the specimen. For multi-layered specimens this field should only be used to describe the density of the excited @@ -614,16 +614,16 @@ - + Hard link to a location in the hierarchy of the NeXus file where the data for default plotting are stored. - + - + Metadata and numerical data of the microscope and the lab in which it stands. @@ -659,128 +659,128 @@ Examples could be NionHermes, Titan, JEOL, Gemini, etc. - + Location of the lab or place where the instrument is installed. Using GEOREF is preferred. - - + + - - - + + + - - - + + + - - - + + + - + - + If the lens is described at least one of the fields voltage, current, or value should be defined. - - + + - - - + + + - + - - - + + + - - - - - - - - - - - - - - + + + + + + + + + + + + + + - - - + + + - - - + + + - + - - - + + + - + If the lens is described at least one of the fields voltage, current, or value should be defined. - - + + - - - + + + - - - + + + - + - - - + + + - - - - - - - - + + + + + + + + - + Description of the type of the detector. @@ -793,26 +793,26 @@ Free text option to write further details about the detector. - - + + - + - - - + + + - - - - - - + + + + + + - + A container to structure a set of NXevent_data_em instances. @@ -833,7 +833,7 @@ Furthermore, NXevent_dat_em instances can document specific values and settings of the microscope during the snapshot/event. - + A container holding a specific result of the measurement and eventually metadata how that result was obtained numerically. @@ -912,15 +912,15 @@ transcoded by some software tool(s) while storing the data in an instance of this schema. - - - + + + Reference to a specific state and setting of the microscope components. - - + + The detector or set of detectors that was used to collect this signal. The name of the detector has to match one of the names of available @@ -929,97 +929,97 @@ instance called ebsd_camera. - - - - - - - - - - - - - - + + + + + + + + + + + + + + - - + + - + - - - - + + + + - + - - - - - - - - - - - - - - + + + + + + + + + + + + + + - - - - - - + + + + + + - - + + - - + + - - - - + + + + - - + + - - - - - - - - - + + + + + + + + + - - + + - - - - + + + + - + - + diff --git a/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml b/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml index def450232e..c7aac11023 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml @@ -1,6 +1,6 @@ - + Subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. diff --git a/contributed_definitions/nyaml/NXenergydispersion.yml b/contributed_definitions/nyaml/NXenergydispersion.yaml similarity index 100% rename from contributed_definitions/nyaml/NXenergydispersion.yml rename to contributed_definitions/nyaml/NXenergydispersion.yaml diff --git a/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml b/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml index 06000fa95d..a4c1c280da 100644 --- a/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml @@ -1,6 +1,6 @@ - + Metadata and settings of an electron microscope for scans and images. diff --git a/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml b/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml index 030f21c18c..20776cd618 100644 --- a/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml @@ -1,6 +1,6 @@ - + Container to hold NXevent_data_em instances of an electron microscope session. diff --git a/contributed_definitions/nyaml/NXfabrication.nxdl.xml b/contributed_definitions/nyaml/NXfabrication.nxdl.xml index 15187d07f5..2c86c961dc 100644 --- a/contributed_definitions/nyaml/NXfabrication.nxdl.xml +++ b/contributed_definitions/nyaml/NXfabrication.nxdl.xml @@ -1,20 +1,20 @@ - + Details about a component as defined by its manufacturer. - + Company name of the manufacturer. - + Version or model of the component named by the manufacturer. - + Ideally, (globally) unique persistent identifier, i.e. a serial number or hash identifier of the component. diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml b/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml index e140483346..229bac7c03 100644 --- a/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml b/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml index 85b26b99ed..7d5514447e 100644 --- a/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXgraph_root.nxdl.xml b/contributed_definitions/nyaml/NXgraph_root.nxdl.xml index 169cd51519..3afc941e8e 100644 --- a/contributed_definitions/nyaml/NXgraph_root.nxdl.xml +++ b/contributed_definitions/nyaml/NXgraph_root.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXibeam_column.nxdl.xml b/contributed_definitions/nyaml/NXibeam_column.nxdl.xml index 22b67688c3..8ea3088bab 100644 --- a/contributed_definitions/nyaml/NXibeam_column.nxdl.xml +++ b/contributed_definitions/nyaml/NXibeam_column.nxdl.xml @@ -1,6 +1,6 @@ - + Container for components of a focused-ion-beam (FIB) system. diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml index 5bf3f42f7c..2eb9e32b21 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/nyaml/NXion.nxdl.xml b/contributed_definitions/nyaml/NXion.nxdl.xml index 08de2c9c52..9e6e3be437 100644 --- a/contributed_definitions/nyaml/NXion.nxdl.xml +++ b/contributed_definitions/nyaml/NXion.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXiv_temp.nxdl.xml b/contributed_definitions/nyaml/NXiv_temp.nxdl.xml index 5370bb2425..568148ea74 100644 --- a/contributed_definitions/nyaml/NXiv_temp.nxdl.xml +++ b/contributed_definitions/nyaml/NXiv_temp.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/nyaml/NXlens_em.nxdl.xml b/contributed_definitions/nyaml/NXlens_em.nxdl.xml index 88aff9b2b2..3ca0140a49 100644 --- a/contributed_definitions/nyaml/NXlens_em.nxdl.xml +++ b/contributed_definitions/nyaml/NXlens_em.nxdl.xml @@ -1,19 +1,20 @@ - + Description of an electro-magnetic lens or a compound lens. + Details of an `electro-magnetic 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. + 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>`_ + .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 - Qualitative type of lens with respect to the number of pole pieces. + Qualitative type of lens with respect to the number of pole pieces @@ -25,8 +26,8 @@ - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. + Colloquial or short name for the lens. For manufacturer names and identifiers + use respective manufacturer fields. @@ -34,7 +35,7 @@ Name of the manufacturer who built/constructed the lens. - + Hardware name, hash identifier, or serial number that was given by the @@ -59,17 +60,6 @@ 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 @@ -78,11 +68,10 @@ - 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. + 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/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index b5482e9a9a..682d36d7bf 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -1,50 +1,36 @@ category: base doc: | Description of an electro-magnetic lens or a compound lens. - + + Details of an `electro-magnetic 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 `_ + in the center of the lens (its polepiece, pinhole, or another point of + reference. The origin should be specified in the NXtransformations. + + .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 NXlens_em: type: - doc: Qualitative type of lens with respect to the number of pole pieces. - enumeration: [single, double, quadrupole, hexapole, octupole] + doc: "Qualitative type of lens with respect to the number of pole pieces" + enumeration: ["single", "double", "quadrupole", "hexapole", "octupole"] name: - doc: | - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. + doc: "Colloquial or short name for the lens. For manufacturer names and identifiers use respective manufacturer fields." manufacturer_name: - doc: Name of the manufacturer who built/constructed the lens. - (NXfabrication): + doc: "Name of the manufacturer who built/constructed the lens." + (NXmanufacturer): model: - doc: Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens. + doc: "Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens." description: - doc: Ideally an identifier, persistent link, or free text which gives further details about the lens. + doc: "Ideally an identifier, persistent link, or free text which gives further details about the lens." voltage(NX_NUMBER): - doc: Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array. + doc: "Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array." unit: NX_VOLTAGE current(NX_NUMBER): - doc: Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array. + doc: "Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array." unit: NX_CURRENT - value(NX_NUMBER): - doc: | - 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. - unit: NX_ANY depends_on(NX_CHAR): - doc: Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group. + doc: "Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group." (NXtransformations): - doc: | - 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. + doc: + "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/nyaml/NXlens_em.yml b/contributed_definitions/nyaml/NXlens_em.yml deleted file mode 100644 index 682d36d7bf..0000000000 --- a/contributed_definitions/nyaml/NXlens_em.yml +++ /dev/null @@ -1,36 +0,0 @@ -category: base -doc: | - Description of an electro-magnetic lens or a compound lens. - - Details of an `electro-magnetic 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. - - .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 -NXlens_em: - type: - doc: "Qualitative type of lens with respect to the number of pole pieces" - enumeration: ["single", "double", "quadrupole", "hexapole", "octupole"] - name: - doc: "Colloquial or short name for the lens. For manufacturer names and identifiers use respective manufacturer fields." - manufacturer_name: - doc: "Name of the manufacturer who built/constructed the lens." - (NXmanufacturer): - model: - doc: "Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens." - description: - doc: "Ideally an identifier, persistent link, or free text which gives further details about the lens." - voltage(NX_NUMBER): - doc: "Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array." - unit: NX_VOLTAGE - current(NX_NUMBER): - doc: "Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array." - unit: NX_CURRENT - depends_on(NX_CHAR): - doc: "Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group." - (NXtransformations): - doc: - "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/nyaml/NXliquid_jet.nxdl.xml b/contributed_definitions/nyaml/NXliquid_jet.nxdl.xml index e66ef2fe29..5294ed80d2 100644 --- a/contributed_definitions/nyaml/NXliquid_jet.nxdl.xml +++ b/contributed_definitions/nyaml/NXliquid_jet.nxdl.xml @@ -1,6 +1,6 @@ - + Description of a liquid jet diff --git a/contributed_definitions/nyaml/NXliquid_jet.yml b/contributed_definitions/nyaml/NXliquid_jet.yaml similarity index 100% rename from contributed_definitions/nyaml/NXliquid_jet.yml rename to contributed_definitions/nyaml/NXliquid_jet.yaml diff --git a/contributed_definitions/nyaml/NXmanipulator.nxdl.xml b/contributed_definitions/nyaml/NXmanipulator.nxdl.xml index d961e331bc..a1dd3ee95d 100644 --- a/contributed_definitions/nyaml/NXmanipulator.nxdl.xml +++ b/contributed_definitions/nyaml/NXmanipulator.nxdl.xml @@ -1,6 +1,6 @@ - + Extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. diff --git a/contributed_definitions/nyaml/NXmanipulator.yml b/contributed_definitions/nyaml/NXmanipulator.yaml similarity index 100% rename from contributed_definitions/nyaml/NXmanipulator.yml rename to contributed_definitions/nyaml/NXmanipulator.yaml diff --git a/contributed_definitions/nyaml/NXmatch_filter.nxdl.xml b/contributed_definitions/nyaml/NXmatch_filter.nxdl.xml index 8ccc82cd31..9b73cb51d3 100644 --- a/contributed_definitions/nyaml/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/nyaml/NXmatch_filter.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -14,7 +14,7 @@ Settings of a filter to select or remove entries based on their value. - + Meaning of the filter: Whitelist specifies which entries with said value to include. @@ -28,7 +28,7 @@ - + Array of values to filter according to method. For example if the filter specifies [1, 5, 6] and method is whitelist, only entries with values diff --git a/contributed_definitions/nyaml/NXmpes.nxdl.xml b/contributed_definitions/nyaml/NXmpes.nxdl.xml index 1711826f5f..468c203e5c 100644 --- a/contributed_definitions/nyaml/NXmpes.nxdl.xml +++ b/contributed_definitions/nyaml/NXmpes.nxdl.xml @@ -1,6 +1,6 @@ - + This is the most general application definition for multidimensional photoelectron spectroscopy. @@ -28,13 +28,13 @@ Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. @@ -45,7 +45,7 @@ Email address of the user. - + Author ID defined by https://orcid.org/. @@ -93,19 +93,19 @@ - - + + - + Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. - - + + @@ -120,15 +120,15 @@ - - - + + + The size and position of the field aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. - + The size and position of the contrast aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. @@ -148,13 +148,13 @@ - + Size, position and shape of the entrance slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. - + Size, position and shape of the exit slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. @@ -162,7 +162,7 @@ - + Type of electron amplifier in the first amplification step. @@ -171,7 +171,7 @@ - + Description of the detector type. @@ -184,7 +184,7 @@ - + @@ -198,13 +198,13 @@ - + Manipulator for positioning of the sample. - - - + + + @@ -213,49 +213,49 @@ Describe the appropriate axis calibrations for your experiment using one or more of the following NXcalibrations - + Has an energy calibration been applied? - + This is the calibrated energy axis to be used for data plotting. - + Has an angular calibration been applied? - + This is the calibrated angular axis to be used for data plotting. - + Has an spatial calibration been applied? - + This is the calibrated spatial axis to be used for data plotting. - + Has an momentum calibration been applied? - + This is the momentum axis to be used for data plotting. @@ -264,13 +264,13 @@ - + The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead. - + A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. Ideally, a full report of the previous operations, in @@ -279,7 +279,7 @@ case these are not available, free-text description. - + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). diff --git a/contributed_definitions/nyaml/NXmpes.yml b/contributed_definitions/nyaml/NXmpes.yaml similarity index 100% rename from contributed_definitions/nyaml/NXmpes.yml rename to contributed_definitions/nyaml/NXmpes.yaml diff --git a/contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml b/contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml index 52eb835d3c..2c9b2603fc 100644 --- a/contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml +++ b/contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml @@ -1,6 +1,6 @@ - + This is the application definition for multidimensional photoelectron spectroscopy on liquids @@ -28,13 +28,13 @@ Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. @@ -45,7 +45,7 @@ Email address of the user. - + Author ID defined by https://orcid.org/. @@ -93,19 +93,19 @@ - - + + - + Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. - - + + @@ -120,15 +120,15 @@ - - - + + + The size and position of the field aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. - + The size and position of the contrast aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. @@ -148,13 +148,13 @@ - + Size, position and shape of the entrance slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. - + Size, position and shape of the exit slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. @@ -162,7 +162,7 @@ - + Type of electron amplifier in the first amplification step. @@ -171,7 +171,7 @@ - + Description of the detector type. @@ -184,7 +184,7 @@ - + @@ -197,13 +197,13 @@ - + Manipulator for positioning of the sample. - - - + + + @@ -213,49 +213,49 @@ Describe the appropriate axis calibrations for your experiment using one or more of the following NXcalibrations - + Has an energy calibration been applied? - + This is the calibrated energy axis to be used for data plotting. - + Has an angular calibration been applied? - + This is the calibrated angular axis to be used for data plotting. - + Has an spatial calibration been applied? - + This is the calibrated spatial axis to be used for data plotting. - + Has an momentum calibration been applied? - + This is the momentum axis to be used for data plotting. @@ -265,13 +265,13 @@ - + The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead. - + A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. Ideally, a full report of the previous operations, in @@ -280,7 +280,7 @@ case these are not available, free-text description. - + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). diff --git a/contributed_definitions/nyaml/NXmpes_liquid.yml b/contributed_definitions/nyaml/NXmpes_liquid.yaml similarity index 100% rename from contributed_definitions/nyaml/NXmpes_liquid.yml rename to contributed_definitions/nyaml/NXmpes_liquid.yaml diff --git a/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml b/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml index 58ea100bc4..a2a62fa0aa 100644 --- a/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml b/contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml index d5766da5bd..0530dd0676 100644 --- a/contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXms_interface_set.nxdl.xml b/contributed_definitions/nyaml/NXms_interface_set.nxdl.xml index d4dc82624e..fcec3c35bb 100644 --- a/contributed_definitions/nyaml/NXms_interface_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXms_interface_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml b/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml index 302e425335..86e38a165b 100644 --- a/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml +++ b/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml b/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml index 5198b90af0..da814d5ac9 100644 --- a/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml b/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml index 1a1cf7ed1a..ee48e025bf 100644 --- a/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml @@ -1,6 +1,6 @@ - + A container for qualifying an electron optical system. diff --git a/contributed_definitions/nyaml/NXorientation_set.nxdl.xml b/contributed_definitions/nyaml/NXorientation_set.nxdl.xml index f3316e8152..913f0c62c3 100644 --- a/contributed_definitions/nyaml/NXorientation_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXorientation_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXpeak.nxdl.xml b/contributed_definitions/nyaml/NXpeak.nxdl.xml index 4eaffed5de..4d549511cd 100644 --- a/contributed_definitions/nyaml/NXpeak.nxdl.xml +++ b/contributed_definitions/nyaml/NXpeak.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXpid.nxdl.xml b/contributed_definitions/nyaml/NXpid.nxdl.xml index 7e779c91ff..f1c70fd066 100644 --- a/contributed_definitions/nyaml/NXpid.nxdl.xml +++ b/contributed_definitions/nyaml/NXpid.nxdl.xml @@ -1,6 +1,6 @@ - + Contains the settings of a PID controller. diff --git a/contributed_definitions/nyaml/NXpulser_apm.nxdl.xml b/contributed_definitions/nyaml/NXpulser_apm.nxdl.xml index 6097cff7fd..6c13e37a60 100644 --- a/contributed_definitions/nyaml/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/nyaml/NXpulser_apm.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXpump.nxdl.xml b/contributed_definitions/nyaml/NXpump.nxdl.xml index 17075281a0..347fffca6d 100644 --- a/contributed_definitions/nyaml/NXpump.nxdl.xml +++ b/contributed_definitions/nyaml/NXpump.nxdl.xml @@ -1,6 +1,6 @@ - + Device to reduce an atmosphere to a controlled remaining pressure level. diff --git a/contributed_definitions/nyaml/NXreflectron.nxdl.xml b/contributed_definitions/nyaml/NXreflectron.nxdl.xml index 0f0a164173..565f1e219d 100644 --- a/contributed_definitions/nyaml/NXreflectron.nxdl.xml +++ b/contributed_definitions/nyaml/NXreflectron.nxdl.xml @@ -1,6 +1,6 @@ - + Device for reducing flight time differences of ions in ToF experiments. diff --git a/contributed_definitions/nyaml/NXregistration.nxdl.xml b/contributed_definitions/nyaml/NXregistration.nxdl.xml index 8ddd155260..ae4a48bbf5 100644 --- a/contributed_definitions/nyaml/NXregistration.nxdl.xml +++ b/contributed_definitions/nyaml/NXregistration.nxdl.xml @@ -1,6 +1,6 @@ - + Describes image registration procedures. diff --git a/contributed_definitions/nyaml/NXregistration.yml b/contributed_definitions/nyaml/NXregistration.yaml similarity index 100% rename from contributed_definitions/nyaml/NXregistration.yml rename to contributed_definitions/nyaml/NXregistration.yaml diff --git a/contributed_definitions/nyaml/NXscanbox_em.nxdl.xml b/contributed_definitions/nyaml/NXscanbox_em.nxdl.xml index 60f9b74870..8cb0b1d604 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/nyaml/NXscanbox_em.nxdl.xml @@ -1,6 +1,6 @@ - + Scan box and coils which deflect an electron beam in a controlled manner. diff --git a/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml b/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml index 2d6ce487ca..07b48907ef 100644 --- a/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml @@ -1,6 +1,6 @@ - + Variables used to set a common size for collected sensor data. @@ -24,10 +24,10 @@ - + - - + + Define the program that was used to generate the results file(s) @@ -65,29 +65,29 @@ Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. - + Email address of the user. - + Author ID defined by https://orcid.org/. - + Official telephone number of the user. @@ -107,7 +107,7 @@ its readings. - + Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. @@ -126,7 +126,7 @@ - + Timestamp for when the values provided in the value field were registered. @@ -134,7 +134,7 @@ the nominal setpoint or average reading values listed above in the value field. - + Free-text describing the data acquisition control: an internal diff --git a/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml b/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml index 71d1fcf7b0..ff4dc83920 100644 --- a/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml +++ b/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXspatial_filter.nxdl.xml b/contributed_definitions/nyaml/NXspatial_filter.nxdl.xml index 4245459eab..c000065ed6 100644 --- a/contributed_definitions/nyaml/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/nyaml/NXspatial_filter.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml index 4952128e6e..882901cd37 100644 --- a/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml index 95ddca359a..3e9d60eb26 100644 --- a/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml @@ -1,6 +1,6 @@ - + diff --git a/contributed_definitions/nyaml/NXspindispersion.nxdl.xml b/contributed_definitions/nyaml/NXspindispersion.nxdl.xml index 71668a6480..0b281dbfc9 100644 --- a/contributed_definitions/nyaml/NXspindispersion.nxdl.xml +++ b/contributed_definitions/nyaml/NXspindispersion.nxdl.xml @@ -1,6 +1,6 @@ - + Subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. diff --git a/contributed_definitions/nyaml/NXspindispersion.yml b/contributed_definitions/nyaml/NXspindispersion.yaml similarity index 100% rename from contributed_definitions/nyaml/NXspindispersion.yml rename to contributed_definitions/nyaml/NXspindispersion.yaml diff --git a/contributed_definitions/nyaml/NXstage_lab.nxdl.xml b/contributed_definitions/nyaml/NXstage_lab.nxdl.xml index c34a57e790..0c076ac970 100644 --- a/contributed_definitions/nyaml/NXstage_lab.nxdl.xml +++ b/contributed_definitions/nyaml/NXstage_lab.nxdl.xml @@ -1,6 +1,6 @@ - + A stage lab can be used to hold, align, orient, and prepare a specimen. diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml b/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml index 7613a30b4e..ccf2f2a63b 100644 --- a/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml @@ -1,6 +1,6 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,7 +9,7 @@ Settings of a filter to sample entries based on their value. - + Triplet of the minimum, increment, and maximum value which will be included in the analysis. The increment controls which n-th entry to take. diff --git a/contributed_definitions/nyaml/NXtransmission.nxdl.xml b/contributed_definitions/nyaml/NXtransmission.nxdl.xml index 23898fe9e7..f19f5f11dd 100644 --- a/contributed_definitions/nyaml/NXtransmission.nxdl.xml +++ b/contributed_definitions/nyaml/NXtransmission.nxdl.xml @@ -1,6 +1,6 @@ - + Variables used throughout the experiment @@ -58,14 +58,14 @@ * The identifier enables to link experiments to e.g. proposals. - + An optional free-text description of the experiment. However, details of the experiment should be defined in the specific fields of this application definition rather than in this experiment description. - + Commercial or otherwise defined given name to the program that was @@ -84,7 +84,7 @@ - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -110,19 +110,19 @@ Email address of the user. - + Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). - + Telephone number of the user. - + Manufacturer of the instrument. @@ -169,7 +169,7 @@ - + Overall spectral resolution of this spectrometer. If several gratings are employed the spectral resoultion @@ -177,7 +177,7 @@ NXgrating group of this spectrometer. - + Diffraction grating, as could be used in a monochromator. If two or more gratings were used, define the angular @@ -186,17 +186,17 @@ do not overlap. The dispersion should be defined for the entire wavelength range of the experiment. - + Dispersion of the grating in nm/mm used. - + The blaze wavelength of the grating used. - + Overall spectral resolution of the instrument when this grating is used. @@ -231,12 +231,12 @@ - + Response time of the detector - + Detector gain @@ -253,7 +253,7 @@ - + An array of relative scan start time points. @@ -287,7 +287,7 @@ - + The spectrum of the lamp used diff --git a/contributed_definitions/nyaml/NXtransmission.yml b/contributed_definitions/nyaml/NXtransmission.yaml similarity index 100% rename from contributed_definitions/nyaml/NXtransmission.yml rename to contributed_definitions/nyaml/NXtransmission.yaml From 0db2d8fada7d604a716dfd9ff79f3f76d91b6d06 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Fri, 3 Mar 2023 23:06:14 +0100 Subject: [PATCH 102/203] add in an elaborated xml examlple --- Example_definition/NXexamlple.nxdl.xml | 474 +++++++++++++++++++++++++ 1 file changed, 474 insertions(+) create mode 100644 Example_definition/NXexamlple.nxdl.xml diff --git a/Example_definition/NXexamlple.nxdl.xml b/Example_definition/NXexamlple.nxdl.xml new file mode 100644 index 0000000000..a431087ce7 --- /dev/null +++ b/Example_definition/NXexamlple.nxdl.xml @@ -0,0 +1,474 @@ + + + + + + This is doc for root level. + + + + This is doc for symbol. + + + + This is doc for symbol_1. + + + + + This is doc for symbol_2. + + + + + + This is for attribute + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + + + This is for attribute + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + This is doc for field. + + + This is for attribute + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + + + + This is for attribute + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + This is doc for field. + + + This is for attribute + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + + + + + This is for attribute + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + This is doc for field. + + + This is for attribute + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + + + + This is for attribute + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + This is doc for field. + + + This is for attribute + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + This is doc for dimensions. + + + This is doc for dim_1 + + + This is doc for dim_1 + + + + + + This is doc for item_1. + + + + + This is doc for item_2. + + + + + + + + \ No newline at end of file From 84480cf420fb93df318a05783e52dd4bac6655ba Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Fri, 3 Mar 2023 23:12:25 +0100 Subject: [PATCH 103/203] Edit the NXexample.nxdl.xml file --- Example_definition/NXexamlple.nxdl.xml | 56 +++++++++++--------------- 1 file changed, 24 insertions(+), 32 deletions(-) diff --git a/Example_definition/NXexamlple.nxdl.xml b/Example_definition/NXexamlple.nxdl.xml index a431087ce7..dbfa415c52 100644 --- a/Example_definition/NXexamlple.nxdl.xml +++ b/Example_definition/NXexamlple.nxdl.xml @@ -1,18 +1,7 @@ - - - - - - This is doc for root level. - + + + + This is doc for symbol. @@ -28,6 +17,9 @@ + + This is doc for root level. + This is for attribute @@ -49,7 +41,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -79,7 +71,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -109,7 +101,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -133,7 +125,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -164,7 +156,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -194,7 +186,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -218,7 +210,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -242,7 +234,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -274,7 +266,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -304,7 +296,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -328,7 +320,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -352,7 +344,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -383,7 +375,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -413,7 +405,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -437,7 +429,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -461,7 +453,7 @@ This is doc for item_1. - + This is doc for item_2. @@ -471,4 +463,4 @@ - \ No newline at end of file + From 4f885ffc5db16a417141aa3bc416cda73f00280d Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Sat, 4 Mar 2023 17:30:00 +0100 Subject: [PATCH 104/203] Adding NXexample.yaml and the corresponsding nxdl --- ...NXexamlple.nxdl.xml => NXexample.nxdl.xml} | 4 +- Example_definition/NXexample.yaml | 420 ++++++++++++++++++ 2 files changed, 422 insertions(+), 2 deletions(-) rename Example_definition/{NXexamlple.nxdl.xml => NXexample.nxdl.xml} (99%) create mode 100644 Example_definition/NXexample.yaml diff --git a/Example_definition/NXexamlple.nxdl.xml b/Example_definition/NXexample.nxdl.xml similarity index 99% rename from Example_definition/NXexamlple.nxdl.xml rename to Example_definition/NXexample.nxdl.xml index dbfa415c52..0f4c9d5eb7 100644 --- a/Example_definition/NXexamlple.nxdl.xml +++ b/Example_definition/NXexample.nxdl.xml @@ -1,7 +1,7 @@ - + - + This is doc for symbol. diff --git a/Example_definition/NXexample.yaml b/Example_definition/NXexample.yaml new file mode 100644 index 0000000000..0d7f58df1c --- /dev/null +++ b/Example_definition/NXexample.yaml @@ -0,0 +1,420 @@ +doc: | + This is doc for root level. +symbols: + doc: | + This is doc for symbol. + + symbol_1: | + This is doc for symbol_1. + + symbol_2: | + This is doc for symbol_2. + +category: base +ignoreExtraAttributes: value_ignoreExtraAttributes +ignoreExtraFields: vlaue_ignoreExtraFields +ignoreExtraGroups: ignoreExtraGroups +restricts: restricts +NXgrating: + \@doc_attribute1: + recommended: ture + optional: ture + doc: | + This is for attribute + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + link1(link): + target: target_1 + napimount: napimount_1 + link2(link): + target: target_2 + napimount: napimount_2 + \@doc_attribute_2(NX_INT): + recommended: ture + optional: ture + doc: | + This is for attribute + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + field_x(NX_INT): + exists: [min, 3, max, 4] + unit: NX_LENGTH + nameType: nameType_1 + axis: 1 + signal: signal + doc: | + This is doc for field. + \@doc_attribute_2(NX_INT): + recommended: ture + optional: ture + doc: | + This is for attribute + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + link1(link): + target: target_1 + napimount: napimount_1 + link2(link): + target: target_2 + napimount: napimount_2 + group_1: + exists: [min, 1, max, 2] + \@doc_attribute1: + recommended: ture + optional: ture + doc: | + This is for attribute + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + field_1(NX_INT): + exists: [min, 3, max, 4] + unit: NX_LENGTH + nameType: nameType_1 + axis: 1 + signal: signal + doc: | + This is doc for field. + \@doc_attribute_2(NX_INT): + recommended: ture + optional: ture + doc: | + This is for attribute + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + link1(link): + target: target_1 + napimount: napimount_1 + link2(link): + target: target_2 + napimount: napimount_2 + choice_name_1(choice): + group_2: + exists: [min, 1, max, 2] + \@doc_attribute1: + recommended: ture + optional: ture + doc: | + This is for attribute + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + field2(NX_INT): + exists: [min, 3, max, 4] + unit: NX_LENGTH + nameType: nameType_1 + axis: 1 + signal: signal + doc: | + This is doc for field. + \@doc_attribute_2(NX_INT): + recommended: ture + optional: ture + doc: | + This is for attribute + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + link1(link): + target: target_1 + napimount: napimount_1 + link2(link): + target: target_2 + napimount: napimount_2 + group_3: + exists: [min, 1, max, 2] + \@doc_attribute1: + recommended: ture + optional: ture + doc: | + This is for attribute + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + fiel4(NX_INT): + exists: [min, 3, max, 4] + unit: NX_LENGTH + nameType: nameType_1 + axis: 1 + signal: signal + doc: | + This is doc for field. + \@doc_attribute_2(NX_INT): + recommended: ture + optional: ture + doc: | + This is for attribute + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + dimensions: + rank: someRank + dim: [[1, dim_value_1], [2, dim_value_2]] + dim_doc: | + ['This is doc for dim_1', 'This is doc for dim_1'] + incr: ['di_incr_1', 'di_incr_2'] + refindex: ['refindex_1', 'refindex_2'] + required: ['required_1', 'required_2'] + ref: ['dim_ref_1', 'dim_ref_2'] + doc: | + This is doc for dimensions. + enumeration: + itme_value_1: + doc: | + This is doc for item_1. + itme_value_2: + doc: | + This is doc for item_2. + link1(link): + target: target_1 + napimount: napimount_1 + link2(link): + target: target_2 + napimount: napimount_2 From 5240a309bdddf9a12e17f789d1b1dbf64f2e2f9f Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Sun, 5 Mar 2023 17:03:23 +0100 Subject: [PATCH 105/203] Removing 'required=false' from dim in NXmx.nxdl.xml. --- applications/NXmx.nxdl.xml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/applications/NXmx.nxdl.xml b/applications/NXmx.nxdl.xml index 0c71dab11f..6c159203fc 100644 --- a/applications/NXmx.nxdl.xml +++ b/applications/NXmx.nxdl.xml @@ -139,7 +139,7 @@ - + @@ -316,7 +316,7 @@ - + @@ -521,7 +521,7 @@ - + @@ -541,7 +541,7 @@ - + @@ -554,7 +554,7 @@ - + @@ -566,7 +566,7 @@ - + From ca998b0d5855dc62b7abf831cbd85f994c1cbe49 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Tue, 7 Mar 2023 11:23:56 +0100 Subject: [PATCH 106/203] Adding doc in NXample.nxdl.xml --- Example_definition/NXexample.nxdl.xml | 21 +++++++++++++++++++++ Example_definition/NXexample.yaml | 3 ++- 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/Example_definition/NXexample.nxdl.xml b/Example_definition/NXexample.nxdl.xml index 0f4c9d5eb7..c477dcd934 100644 --- a/Example_definition/NXexample.nxdl.xml +++ b/Example_definition/NXexample.nxdl.xml @@ -1,5 +1,26 @@ + diff --git a/Example_definition/NXexample.yaml b/Example_definition/NXexample.yaml index 0d7f58df1c..c4c80bf8b9 100644 --- a/Example_definition/NXexample.yaml +++ b/Example_definition/NXexample.yaml @@ -15,7 +15,8 @@ ignoreExtraAttributes: value_ignoreExtraAttributes ignoreExtraFields: vlaue_ignoreExtraFields ignoreExtraGroups: ignoreExtraGroups restricts: restricts -NXgrating: +type: group +(NXobject)NXgrating: \@doc_attribute1: recommended: ture optional: ture From 31a410e3a8e4d159083c18504e5c9293fb3b3ad6 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 16 Mar 2023 16:15:35 +0100 Subject: [PATCH 107/203] Adds html frontpage docs for dispersive material --- manual/source/ellipsometry-structure.rst | 149 ++++++++++++++++++----- 1 file changed, 116 insertions(+), 33 deletions(-) diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst index 4fc29edc3b..943b7d9c97 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/ellipsometry-structure.rst @@ -5,53 +5,32 @@ B4: Optical spectroscopy ======================== .. index:: - IntroductionEllipsometry - EllNewAppDef - EllExtendedBC + Ellipsometry + DispersiveMaterial -.. _IntroductionEllipsometry: +.. _Ellipsometry: -Introduction +Ellipsometry ############## Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. The measurements are based on determining how the polarization state of light changes upon transmission and reflection. Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. In the application definition we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. -.. _EllNewAppDef: -New Application Definitions -############################ +Application Definitions +----------------------- We created one application definition: :ref:`NXellipsometry`: A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. -.. .. _NewBC: -.. EllNew Base Classes -.. #################### - -.. We developed entirely new base classes: - -.. :ref:`NXelectronanalyser`: -.. A base class to describe... - -.. New Common Base Classes -.. ####################### - -.. We developed two classes that are common to other techniques: - - :ref:`NXlens`: - A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. - - -.. _ExtendedBC: Base Classes Extended in Application Definitions -################################################### +------------------------------------------------ We use existent base classes in application definitions and add descriptors: @@ -67,8 +46,112 @@ We use existent base classes in application definitions and add descriptors: :ref:`NXsample` Added fields to specify the sample and material properties, as well as the sample environment (e.g. refractive index of surrounding medium) and experimental conditions (e.g. temperature, pressure, pH value etc.). -.. :ref:`NXentry` -.. Added fields to describe an ellipsometry experiment. - -.. :ref:`NXsubentry` -.. Used to describe calibration, sample stage, reference data for a window, and optical excitation. +.. _DispersiveMaterial: + + +Dispersive Material +################### + +A dispersive material is a description for the optical dispersion of materials. +This description may be used to store optical model data from an ellipsometric analysis +(or any other technique) or to build a database of optical constants for optical properties of materials. + +Application Definition +---------------------- + + :ref:`NXdispersive_material`: + An application definition to describe the dispersive properties of a material. + The material may be isotropic, uniaxial or biaxial. Hence, it may contain up + to three dispersive functions or tables. + + + +Base Classes +------------ + +There is a set of base classes for describing a dispersion. + + :ref:`NXdispersion` + This is an umbrella base class for a group of dispersion functions to describe the material. + For a simple dispersion it may contain only on NXdispersion_function or NXdispersion_table entry. + If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. + This allows for, e.g. splitting real and imaginary parts and describing them seperately or + adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). + + :ref:`NXdispersion_function` + This dispersion is described by a function and its single and repeated parameter values. + It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` + (Sellmeier formula). See the formula grammer below for an ebnf grammar for this form. + + :ref:`NXdispersion_single_parameter` + This denotes a parameter which is used outside the summed part of a dispersion function, + e.g. ``eps_inf`` in the formula example above. + + :ref:`NXdispersion_repeated_parameter` + This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. + ``A`` and ``B`` are repeated parameters in the formula above. + + :ref:`NXdispersion_table` + This describes a tabular dispersion where the dielectric function is an array versus wavelength or energy. + +Formula Grammar +--------------- + +Below you find a grammar to which the formula should adhere and which can be used to parse and +evaluate the dispersion function. The terms ``single_param_name`` and ``param_name`` should be +filled with the respective single and repeated params from the stored data. + +.. code-block:: + + ?assignment: "eps" "=" kkr_expression -> eps + | "n" "=" kkr_expression -> n + + ?kkr_expression: expression + | "" "+" "1j" "*" term -> kkr_term + + ?expression: term + | expression "+" term -> add + | expression "-" term -> sub + + ?term: factor + | term "*" factor -> mul + | term "/" factor -> div + + ?factor: power + | power "**" power -> power + + + ?power: "(" expression ")" + | FUNC "(" expression ")" -> func + | "sum" "[" repeated_expression "]" -> sum_expr + | NAME -> single_param_name + | SIGNED_NUMBER -> number + | BUILTIN -> builtin + + ?repeated_expression: repeated_term + | repeated_expression "+" repeated_term -> add + | repeated_expression "-" repeated_term -> sub + + + ?repeated_term: repeated_factor + | repeated_term "*" repeated_factor -> mul + | repeated_term "/" repeated_factor -> div + + ?repeated_factor: repeated_power + | repeated_power "**" repeated_power -> power + + ?repeated_power: "(" repeated_expression ")" + | FUNC "(" repeated_expression ")" -> func + | SIGNED_NUMBER -> number + | NAME -> param_name + | BUILTIN -> builtin + + FUNC.1: "sin" | "cos" | "tan" | "sqrt" | "dawsn" | "ln" | "log" | "heaviside" + BUILTIN.1: "1j" | "pi" | "eps_0" | "hbar" | "h" | "c" + + %import common.CNAME -> NAME + %import common.SIGNED_NUMBER + %import common.WS_INLINE + + %ignore WS_INLINE + \ No newline at end of file From d076dc442550607d4a9bb3dec36caa3a67104712 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Thu, 16 Mar 2023 16:50:51 +0100 Subject: [PATCH 108/203] Base_classes: Producing yaml from nxdl in 'nyaml' folder --- base_classes/nyaml/NXaperture.nxdl.xml | 87 -- base_classes/nyaml/NXaperture.yaml | 99 ++- base_classes/nyaml/NXattenuator.yaml | 78 ++ base_classes/nyaml/NXbeam.nxdl.xml | 286 ------- base_classes/nyaml/NXbeam.yaml | 380 +++++---- base_classes/nyaml/NXbeam_stop.yaml | 79 ++ base_classes/nyaml/NXbending_magnet.yaml | 87 ++ base_classes/nyaml/NXcapillary.yaml | 59 ++ base_classes/nyaml/NXcite.yaml | 40 + base_classes/nyaml/NXcollection.yaml | 18 + base_classes/nyaml/NXcollimator.yaml | 81 ++ base_classes/nyaml/NXcrystal.yaml | 290 +++++++ .../nyaml/NXcylindrical_geometry.yaml | 63 ++ base_classes/nyaml/NXdata.yaml | 374 ++++++++ base_classes/nyaml/NXdetector.nxdl.xml | 801 ------------------ base_classes/nyaml/NXdetector.yaml | 609 ++++++++----- base_classes/nyaml/NXdetector_group.yaml | 77 ++ base_classes/nyaml/NXdetector_module.yaml | 120 +++ base_classes/nyaml/NXdisk_chopper.yaml | 142 ++++ base_classes/nyaml/NXentry.nxdl.xml | 270 ------ base_classes/nyaml/NXentry.yaml | 231 ++--- base_classes/nyaml/NXenvironment.yaml | 44 + base_classes/nyaml/NXevent_data.yaml | 94 ++ base_classes/nyaml/NXfermi_chopper.yaml | 91 ++ base_classes/nyaml/NXfilter.yaml | 169 ++++ base_classes/nyaml/NXflipper.yaml | 64 ++ base_classes/nyaml/NXfresnel_zone_plate.yaml | 72 ++ base_classes/nyaml/NXgeometry.yaml | 46 + base_classes/nyaml/NXgrating.yaml | 86 ++ base_classes/nyaml/NXguide.yaml | 177 ++++ base_classes/nyaml/NXinsertion_device.yaml | 87 ++ base_classes/nyaml/NXinstrument.nxdl.xml | 82 -- base_classes/nyaml/NXinstrument.yaml | 49 +- base_classes/nyaml/NXlog.yaml | 111 +++ base_classes/nyaml/NXmirror.yaml | 115 +++ base_classes/nyaml/NXmoderator.yaml | 72 ++ base_classes/nyaml/NXmonitor.yaml | 130 +++ base_classes/nyaml/NXmonochromator.yaml | 84 ++ base_classes/nyaml/NXnote.yaml | 42 + base_classes/nyaml/NXobject.yaml | 6 + base_classes/nyaml/NXoff_geometry.yaml | 74 ++ base_classes/nyaml/NXorientation.yaml | 37 + base_classes/nyaml/NXparameters.yaml | 22 + base_classes/nyaml/NXpdb.yaml | 131 +++ base_classes/nyaml/NXpinhole.yaml | 45 + base_classes/nyaml/NXpolarizer.yaml | 50 ++ base_classes/nyaml/NXpositioner.yaml | 87 ++ base_classes/nyaml/NXprocess.nxdl.xml | 64 -- base_classes/nyaml/NXprocess.yaml | 48 +- base_classes/nyaml/NXreflections.yaml | 605 +++++++++++++ base_classes/nyaml/NXroot.yaml | 73 ++ base_classes/nyaml/NXsample.nxdl.xml | 599 ------------- base_classes/nyaml/NXsample.yaml | 326 +++---- base_classes/nyaml/NXsample_component.yaml | 124 +++ base_classes/nyaml/NXsensor.yaml | 127 +++ base_classes/nyaml/NXshape.yaml | 47 + base_classes/nyaml/NXslit.yaml | 51 ++ base_classes/nyaml/NXsource.nxdl.xml | 274 ------ base_classes/nyaml/NXsource.yaml | 199 +++-- base_classes/nyaml/NXsubentry.yaml | 148 ++++ base_classes/nyaml/NXtransformations.yaml | 182 ++++ base_classes/nyaml/NXtranslation.yaml | 34 + base_classes/nyaml/NXuser.yaml | 54 ++ base_classes/nyaml/NXvelocity_selector.yaml | 87 ++ base_classes/nyaml/NXxraylens.yaml | 86 ++ 65 files changed, 6214 insertions(+), 3252 deletions(-) delete mode 100644 base_classes/nyaml/NXaperture.nxdl.xml create mode 100644 base_classes/nyaml/NXattenuator.yaml delete mode 100644 base_classes/nyaml/NXbeam.nxdl.xml create mode 100644 base_classes/nyaml/NXbeam_stop.yaml create mode 100644 base_classes/nyaml/NXbending_magnet.yaml create mode 100644 base_classes/nyaml/NXcapillary.yaml create mode 100644 base_classes/nyaml/NXcite.yaml create mode 100644 base_classes/nyaml/NXcollection.yaml create mode 100644 base_classes/nyaml/NXcollimator.yaml create mode 100644 base_classes/nyaml/NXcrystal.yaml create mode 100644 base_classes/nyaml/NXcylindrical_geometry.yaml create mode 100644 base_classes/nyaml/NXdata.yaml delete mode 100644 base_classes/nyaml/NXdetector.nxdl.xml create mode 100644 base_classes/nyaml/NXdetector_group.yaml create mode 100644 base_classes/nyaml/NXdetector_module.yaml create mode 100644 base_classes/nyaml/NXdisk_chopper.yaml delete mode 100644 base_classes/nyaml/NXentry.nxdl.xml create mode 100644 base_classes/nyaml/NXenvironment.yaml create mode 100644 base_classes/nyaml/NXevent_data.yaml create mode 100644 base_classes/nyaml/NXfermi_chopper.yaml create mode 100644 base_classes/nyaml/NXfilter.yaml create mode 100644 base_classes/nyaml/NXflipper.yaml create mode 100644 base_classes/nyaml/NXfresnel_zone_plate.yaml create mode 100644 base_classes/nyaml/NXgeometry.yaml create mode 100644 base_classes/nyaml/NXgrating.yaml create mode 100644 base_classes/nyaml/NXguide.yaml create mode 100644 base_classes/nyaml/NXinsertion_device.yaml delete mode 100644 base_classes/nyaml/NXinstrument.nxdl.xml create mode 100644 base_classes/nyaml/NXlog.yaml create mode 100644 base_classes/nyaml/NXmirror.yaml create mode 100644 base_classes/nyaml/NXmoderator.yaml create mode 100644 base_classes/nyaml/NXmonitor.yaml create mode 100644 base_classes/nyaml/NXmonochromator.yaml create mode 100644 base_classes/nyaml/NXnote.yaml create mode 100644 base_classes/nyaml/NXobject.yaml create mode 100644 base_classes/nyaml/NXoff_geometry.yaml create mode 100644 base_classes/nyaml/NXorientation.yaml create mode 100644 base_classes/nyaml/NXparameters.yaml create mode 100644 base_classes/nyaml/NXpdb.yaml create mode 100644 base_classes/nyaml/NXpinhole.yaml create mode 100644 base_classes/nyaml/NXpolarizer.yaml create mode 100644 base_classes/nyaml/NXpositioner.yaml delete mode 100644 base_classes/nyaml/NXprocess.nxdl.xml create mode 100644 base_classes/nyaml/NXreflections.yaml create mode 100644 base_classes/nyaml/NXroot.yaml delete mode 100644 base_classes/nyaml/NXsample.nxdl.xml create mode 100644 base_classes/nyaml/NXsample_component.yaml create mode 100644 base_classes/nyaml/NXsensor.yaml create mode 100644 base_classes/nyaml/NXshape.yaml create mode 100644 base_classes/nyaml/NXslit.yaml delete mode 100644 base_classes/nyaml/NXsource.nxdl.xml create mode 100644 base_classes/nyaml/NXsubentry.yaml create mode 100644 base_classes/nyaml/NXtransformations.yaml create mode 100644 base_classes/nyaml/NXtranslation.yaml create mode 100644 base_classes/nyaml/NXuser.yaml create mode 100644 base_classes/nyaml/NXvelocity_selector.yaml create mode 100644 base_classes/nyaml/NXxraylens.yaml diff --git a/base_classes/nyaml/NXaperture.nxdl.xml b/base_classes/nyaml/NXaperture.nxdl.xml deleted file mode 100644 index ff461163a0..0000000000 --- a/base_classes/nyaml/NXaperture.nxdl.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - A beamline aperture - - - - 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. - - - - - Absorbing material of the aperture. - - - - - Description of the aperture. - - - - - Shape of the aperture. - - - - - - - - - - - - - - - - - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter - - - - - Specifies the position of the aperture 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 - 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. - - - - - Stores the raw positions of aperture motors. - - - - - Location and shape of the aperture. - - - - - Location and shape of each blade. - - - - - Describes any additional information. - - - diff --git a/base_classes/nyaml/NXaperture.yaml b/base_classes/nyaml/NXaperture.yaml index 62c345e06b..9d5fa64eda 100644 --- a/base_classes/nyaml/NXaperture.yaml +++ b/base_classes/nyaml/NXaperture.yaml @@ -1,49 +1,64 @@ category: base -doc: "A beamline aperture" -NXaperture: - \@default(NX_CHAR): - doc: | - Declares which child group contains a path leading to a :ref:`NXdata` group. +doc: | + A beamline aperture. This group is deprecated, use NXslit instead. - | 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. - material(NX_CHAR): - doc: "Absorbing material of the aperture." - description(NX_CHAR): - doc: "Description of the aperture." - shape: - doc: "Shape of the aperture." - enumeration: - [ - "straight slit", - "curved slit", - "pinhole", - "circle", - "square", - "hexagon", - "octagon", - "bladed", - "open", - "grid", - ] - size(NX_NUMBER): - doc: - "The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter" - unit: NX_LENGTH +type: group +NXaperture(NXobject): depends_on(NX_CHAR): - doc: "Specifies the position of the aperture by pointing to the last transformation in the transformation chain in the NXtransformations group." + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the + surface of the aperture pointing towards the source. + + In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + + .. image':'':' aperture/aperture.png + ':'width':' 40% (NXtransformations): - doc: "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 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." - (NXpositioner): - doc: "Stores the raw positions of aperture motors." + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. (NXgeometry): - doc: "Location and shape of the aperture." + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the aperture and ':'ref':'`NXoff_geometry` to describe its shape + doc: | + location and shape of aperture + + .. TODO':' documentation needs improvement, contributions welcome + + * description of terms is poor and leaves much to interpretation + * Describe what is meant by translation _here_ and ... + * Similar throughout base classes + * Some base classes do this much better + * Such as where is the gap written? BLADE_GEOMETRY(NXgeometry): - doc: "Location and shape of each blade." + deprecated: Use ':'ref':'`NXoff_geometry` instead to describe the shape of the aperture + doc: | + location and shape of each blade + material: + doc: | + Absorbing material of the aperture + description: + doc: | + Description of aperture (NXnote): - doc: "Describes any additional information." + doc: | + describe any additional information in a note* + \@default: + doc: | + .. 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/nyaml/NXattenuator.yaml b/base_classes/nyaml/NXattenuator.yaml new file mode 100644 index 0000000000..1783187059 --- /dev/null +++ b/base_classes/nyaml/NXattenuator.yaml @@ -0,0 +1,78 @@ +category: base +doc: | + A device that reduces the intensity of a beam by attenuation. + + If uncertain whether to use ':'ref':'`NXfilter` (band-pass filter) + or ':'ref':'`NXattenuator` (reduces beam intensity), then choose + ':'ref':'`NXattenuator`. + +type: group +NXattenuator(NXobject): + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance from sample. Note, it is recommended to use NXtransformations instead. + type: + doc: | + Type or composition of attenuator, e.g. polythene + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of attenuator along beam direction + scattering_cross_section(NX_FLOAT): + unit: NX_CROSS_SECTION + doc: | + Scattering cross section (coherent+incoherent) + absorption_cross_section(NX_FLOAT): + unit: NX_CROSS_SECTION + doc: | + Absorption cross section + attenuator_transmission(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The nominal amount of the beam that gets through + (transmitted intensity)/(incident intensity) + status: + doc: | + In or out or moving of the beam + \@time: + type: NX_DATE_TIME + doc: | + time stamp for this observation + enumeration: [in, out, moving] + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the attenuator is its center in the x and y axis. The reference point on the z axis is the + surface of the attenuator pointing towards the source. + + In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + + .. image':'':' attenuator/attenuator.png + ':'width':' 40% + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + shape(NXoff_geometry): + doc: | + Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. diff --git a/base_classes/nyaml/NXbeam.nxdl.xml b/base_classes/nyaml/NXbeam.nxdl.xml deleted file mode 100644 index d96252f722..0000000000 --- a/base_classes/nyaml/NXbeam.nxdl.xml +++ /dev/null @@ -1,286 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of pixels of the horizontal axis (e.g. delay) of a FROG trace - - - - - Number of pixels of the vertical axis (e.g. frequency) of a FROG trace - - - - - Properties of the neutron or X-ray beam at a given location. - - It will be referenced by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. - Note that variables such as the incident energy could be scalar values or arrays. - This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, - time distribution etc. at each beamline component. - Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - - - Distance from sample - - - - - In the case of a monchromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - - - - - - - - The energy spread FWHM for the corresponding energy(ies) in incident_energy. In - the case of shot-to-shot variation in the energy spread, this is a 2D array of - dimension nP by m (slow to fast) of the spreads of the corresponding wavelength - in incident_wavelength. - - - - - In the case of a polychromatic beam this is an array of length m of the relative - weights of the corresponding energies in incident_energy. In the case of a - polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np - by m (slow to fast) of the relative weights of the corresponding energies in - incident_energy. - - - - - Energy on leaving beamline component - - - - - - - - Energy change caused by beamline component - - - - - - - - In the case of a monchromatic beam this is the scalar wavelength. - Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. - - * In the case of a polychromatic beam this is an array of length m of wavelengths, - with the relative weights in incident_wavelength_weights. - * In the case of a monochromatic beam that varies shot-to-shot, - this is an array of wavelengths, one for each recorded shot. - Here, incident_wavelength_weights and incident_wavelength_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, - single-value wavelength value is available along with the original spectrum from which it was calibrated. - - - - - - - - Wavelength spread FWHM on entering component - - - - - - - - Divergence of beam entering this component - - - - - - - - - Size of the beam entering this component - - - - - - - - - Wavelength on leaving beamline component - - - - - - - - Incident polarization as a Stokes vector - - - - - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. - Correct parsing can still be implemented by using this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: 'farad' for capacitance). - * A string describing the units according to unidata unit operation notation, - if the unit is a complex combination of named units and does not have a name. - - Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. - Here: SI units are 'V2/m2'. - - - - - - Polarization as Stokes vector on leaving beamline component - - - - - - - Here: SI units are 'V2/m2'. - - - - - - Wavelength spread FWHM of beam leaving this component - - - - - - - - Divergence FWHM of beam leaving this component - - - - - - - - - flux incident on beam plane area - - - - - - - - Energy of a single pulse at the diagnostic point - - - - - Average power at the diagnostic point - - - - - Incident fluence at the diagnostic point - - - - Here: SI units are ''J/m2'', customary ''mJ/cm2''. - - - - - - FWHM duration of the pulses at the diagnostic point - - - - - FROG trace of the pulse. - - - - - - - - - Horizontal axis of a FROG trace, i.e. delay. - - - - - - - - Vertical axis of a FROG trace, i.e. frequency. - - - - - - - - The type of chirp implemented - - - - - Group delay dispersion of the pulse for linear chirp - - - - - Distribution of beam with respect to relevant variable e.g. wavelength. This is - mainly useful for simulations which need to store plottable information at each - beamline component. - - - - - .. 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/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml index 27096b72ff..a46245c593 100644 --- a/base_classes/nyaml/NXbeam.yaml +++ b/base_classes/nyaml/NXbeam.yaml @@ -1,206 +1,286 @@ -doc: | - Properties of the neutron or X-ray beam at a given location. - - It will be referenced by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. - Note that variables such as the incident energy could be scalar values or arrays. - This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, - time distribution etc. at each beamline component. - Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. -symbols: - doc: "The symbols used in the schema to specify e.g. dimensions of arrays" - nx: "Number of pixels of the horizontal axis (e.g. delay) of a FROG trace" - ny: "Number of pixels of the vertical axis (e.g. frequency) of a FROG trace" category: base -NXbeam: +doc: | + Properties of the neutron or X-ray beam at a given location. + + This group is intended to be referenced + by beamline component groups within the ':'ref':'`NXinstrument` group or by the ':'ref':'`NXsample` group. This group is + especially valuable in storing the results of instrument simulations in which it is useful + to specify the beam profile, time distribution etc. at each beamline component. Otherwise, + its most likely use is in the ':'ref':'`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. + + Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. + To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred + by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. + +symbols: + doc: | + These symbols coordinate datasets with the same shape. + + nP: | + Number of scan points. + + m: | + Number of channels in the incident beam spectrum, if known + + c: | + Number of moments representing beam divergence (x, y, xy, etc.) + +type: group +NXbeam(NXobject): distance(NX_FLOAT): unit: NX_LENGTH - doc: "Distance from sample" + doc: | + Distance from sample. Note, it is recommended to use NXtransformations instead. incident_energy(NX_FLOAT): unit: NX_ENERGY - doc: | - In the case of a monchromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + doc: | + Energy carried by each particle of the beam on entering the beamline component dimensions: rank: 1 - dim: [[1, i]] - incident_energy_spread(NX_NUMBER): - unit: NX_ENERGY - doc: - "The energy spread FWHM for the corresponding energy(ies) in incident_energy. - In the case of shot-to-shot variation in the energy spread, - this is a 2D array of dimension nP by m (slow to fast) of the spreads of the corresponding wavelength in incident_wavelength." - incident_energy_weights(NX_NUMBER): - unit: NX_ENERGY - doc: - "In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding energies in incident_energy. - In the case of a polychromatic beam that varies shot-to-shot, - this is a 2D array of dimensions np by m (slow to fast) of the relative weights of the corresponding energies in incident_energy." + dim: [[1, m]] final_energy(NX_FLOAT): unit: NX_ENERGY - doc: "Energy on leaving beamline component" + doc: | + Energy carried by each particle of the beam on leaving the beamline component dimensions: rank: 1 - dim: [[1, i]] + dim: [[1, m]] energy_transfer(NX_FLOAT): unit: NX_ENERGY - doc: "Energy change caused by beamline component" + doc: | + Change in particle energy caused by the beamline component dimensions: rank: 1 - dim: [[1, i]] + dim: [[1, m]] incident_wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | - In the case of a monchromatic beam this is the scalar wavelength. - Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. - - * In the case of a polychromatic beam this is an array of length m of wavelengths, - with the relative weights in incident_wavelength_weights. - * In the case of a monochromatic beam that varies shot-to-shot, - this is an array of wavelengths, one for each recorded shot. - Here, incident_wavelength_weights and incident_wavelength_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, - single-value wavelength value is available along with the original spectrum from which it was calibrated. - dimensions: - rank: 1 - dim: [[1, i]] + doc: | + In the case of a monochromatic beam this is the scalar + wavelength. + + Several other use cases are permitted, depending on the + presence or absence of other incident_wavelength_X + fields. + + In the case of a polychromatic beam this is an array of + length **m** of wavelengths, with the relative weights + in ``incident_wavelength_weights``. + + In the case of a monochromatic beam that varies shot- + to-shot, this is an array of wavelengths, one for each + recorded shot. Here, ``incident_wavelength_weights`` and + incident_wavelength_spread are not set. + + In the case of a polychromatic beam that varies shot-to- + shot, this is an array of length **m** with the relative + weights in ``incident_wavelength_weights`` as a 2D array. + + In the case of a polychromatic beam that varies shot-to- + shot and where the channels also vary, this is a 2D array + of dimensions **nP** by **m** (slow to fast) with the + relative weights in ``incident_wavelength_weights`` as a 2D + array. + + Note, ':'ref':'`variants ` are a good way + to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value wavelength value is + available along with the original spectrum from which it + was calibrated. + Wavelength on entering beamline component + incident_wavelength_weights(NX_FLOAT): + doc: | + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in ``incident_wavelength``. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **nP** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in ``incident_wavelength``. incident_wavelength_spread(NX_FLOAT): unit: NX_WAVELENGTH - doc: "Wavelength spread FWHM on entering component" + doc: | + The wavelength spread FWHM for the corresponding + wavelength(s) in incident_wavelength. + + In the case of shot-to-shot variation in the wavelength + spread, this is a 2D array of dimension **nP** by + **m** (slow to fast) of the spreads of the + corresponding wavelengths in incident_wavelength. dimensions: rank: 1 - dim: [[1, i]] + dim: [[1, nP]] incident_beam_divergence(NX_FLOAT): unit: NX_ANGLE - doc: "Divergence of beam entering this component" + doc: | + Beam crossfire in degrees parallel to the laboratory X axis + + The dimension **c** is a series of moments of that represent + the standard uncertainty (e.s.d.) of the directions of + of the beam. The first and second moments are in the XZ and YZ + planes around the mean source beam direction, respectively. + + Further moments in **c** characterize co-variance terms, so + the next moment is the product of the first two, and so on. dimensions: rank: 2 - dim: [[1, 2], [2, j]] + dim: [[1, nP], [2, c]] extent(NX_FLOAT): unit: NX_LENGTH - doc: "Size of the beam entering this component" + doc: | + Size of the beam entering this component. Note this represents + a rectangular beam aperture, and values represent FWHM dimensions: rank: 2 - dim: [[1, 2], [2, j]] + dim: [[1, nP], [2, 2]] final_wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: "Wavelength on leaving beamline component" + doc: | + Wavelength on leaving beamline component dimensions: rank: 1 - dim: [[1, i]] - incident_polarization(NX_FLOAT): + dim: [[1, m]] + incident_polarization(NX_NUMBER): unit: NX_ANY - doc: "Incident polarization as a Stokes vector" + doc: | + Polarization vector on entering beamline component dimensions: - rank: 1 - dim: [[1, 4]] - \@units: - doc: | - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. - Correct parsing can still be implemented by using this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: 'farad' for capacitance). - * A string describing the units according to unidata unit operation notation, - if the unit is a complex combination of named units and does not have a name. - - Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. - Here: SI units are 'V2/m2'. - final_polarization(NX_FLOAT): + rank: 2 + dim: [[1, nP], [2, 2]] + final_polarization(NX_NUMBER): unit: NX_ANY - doc: "Polarization as Stokes vector on leaving beamline component" + doc: | + Polarization vector on leaving beamline component dimensions: - rank: 1 - dim: [[1, 4]] - \@units: - doc: "Here: SI units are 'V2/m2'." + rank: 2 + dim: [[1, nP], [2, 2]] + incident_polarization_stokes(NX_NUMBER): + unit: NX_ANY + doc: | + Polarization vector on entering beamline component using Stokes notation + + The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. + These are defined with the standard Nexus coordinate frame unless it is + overridden by an NXtransformations field pointed to by a depends_on attribute. + The last component, describing the circular polarization state, is positive + for a right-hand circular state - that is the electric field vector rotates + clockwise at the sample and over time when observed from the source. + + I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale + linearly with the total degree of polarization, and indicate the relative + magnitudes of the pure linear and circular orientation contributions. + + Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). + + U (S_2) is linearly polarized along the x==y axis (U > 0) or the + -x==y axis (U < 0). + + V (S_3) is circularly polarized. V > 0 when the electric field vector rotates + clockwise at the sample with respect to time when observed from the source; + V < 0 indicates the opposite rotation. + dimensions: + rank: 2 + dim: [[1, nP], [2, 4]] + final_polarization_stokes(NX_NUMBER): + unit: NX_ANY + doc: | + Polarization vector on leaving beamline component using Stokes notation + (see incident_polarization_stokes). + dimensions: + rank: 2 + dim: [[1, nP], [2, 4]] final_wavelength_spread(NX_FLOAT): unit: NX_WAVELENGTH - doc: "Wavelength spread FWHM of beam leaving this component" + doc: | + Wavelength spread FWHM of beam leaving this component dimensions: rank: 1 - dim: [[1, i]] + dim: [[1, m]] final_beam_divergence(NX_FLOAT): unit: NX_ANGLE - doc: "Divergence FWHM of beam leaving this component" + doc: | + Divergence FWHM of beam leaving this component dimensions: rank: 2 - dim: [[1, 2], [2, j]] + dim: [[1, nP], [2, 2]] flux(NX_FLOAT): unit: NX_FLUX - doc: "flux incident on beam plane area" + doc: | + flux incident on beam plane area dimensions: rank: 1 - dim: [[1, i]] - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: "Energy of a single pulse at the diagnostic point" - average_power(NX_FLOAT): - unit: NX_POWER - doc: "Average power at the diagnostic point" - fluence(NX_FLOAT): - unit: NX_ANY - doc: "Incident fluence at the diagnostic point" - \@units: - doc: "Here: SI units are - ''J/m2'', customary ''mJ/cm2''." - pulse_duration(NX_FLOAT): - unit: NX_TIME - doc: "FWHM duration of the pulses at the diagnostic point" - frog_trace(NX_FLOAT): - doc: "FROG trace of the pulse." - dimensions: - rank: 2 - dim: [[1, nx], [1, ny]] - frog_delays(NX_FLOAT): - unit: NX_TIME - doc: "Horizontal axis of a FROG trace, i.e. delay." - dimensions: - rank: 1 - dim: [[1, nx]] - frog_frequencies(NX_FLOAT): - unit: NX_FREQUENCY - doc: "Vertical axis of a FROG trace, i.e. frequency." - dimensions: - rank: 1 - dim: [[1, ny]] - chirp_type(NX_CHAR): - doc: "The type of chirp implemented" - chirp_GDD(NX_FLOAT): - unit: NX_TIME - doc: "Group delay dispersion of the pulse for linear chirp" + dim: [[1, nP]] (NXdata): - doc: - "Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly + doc: | + Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly useful for simulations which need to store plottable information at each beamline - component." + component. \@default: - doc: | - .. index:: plotting - + doc: | + .. index':'':' plotting + Declares which child group contains a path leading - to a :ref:`NXdata` group. - + 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + depends_on(NX_CHAR): + exists: ['min', '0'] + doc: | + The NeXus coordinate system defines the Z axis to be along the nominal beam + direction. This is the same as the McStas coordinate system (see ':'ref':'Design-CoordinateSystem). + However, the additional transformations needed to represent an altered beam + direction can be provided using this depends_on field that contains the path + to a NXtransformations group. This could represent redirection of the beam, + or a refined beam direction. + (NXtransformations): + exists: ['min', '0'] + doc: | + Direction (and location) for the beam. The location of the beam can be given by + any point which it passes through as its offset attribute. + DIRECTION(NX_NUMBER): + nameType: any + unit: NX_TRANSFORMATION + doc: | + Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] + and passes through the origin + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the direction of beam vector + \@offset: + type: NX_NUMBER + doc: | + Three values that define the location of a point through which the beam passes + \@depends_on: + type: NX_CHAR + doc: | + Points to the path to a field defining the location on which this + depends or the string "." for origin. + reference_plane(NX_NUMBER): + nameType: any + unit: NX_TRANSFORMATION + doc: | + Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. + This also defines the parallel and perpendicular components of the beam's polarization. + If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the direction of reference plane normal + \@offset: + type: NX_NUMBER + doc: | + Not required as beam direction offset locates the plane + \@depends_on: + type: NX_CHAR + doc: | + Points to the path to a field defining the location on which this + depends or the string "." for origin. diff --git a/base_classes/nyaml/NXbeam_stop.yaml b/base_classes/nyaml/NXbeam_stop.yaml new file mode 100644 index 0000000000..c087e899d8 --- /dev/null +++ b/base_classes/nyaml/NXbeam_stop.yaml @@ -0,0 +1,79 @@ +category: base +doc: | + A device that blocks the beam completely, usually to protect a detector. + + Beamstops and their positions are important for SANS + and SAXS experiments. + +type: group +NXbeam_stop(NXobject): + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + engineering shape, orientation and position of the beam stop. + description: + doc: | + description of beamstop + enumeration: [circular, rectangular] + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + (NXcylindrical_geometry): + exists: ['min', '0'] + doc: | + This group is an alternative to NXoff_geometry for describing the shape + of the beam stop. + size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of beamstop. If this is not sufficient to describe the beam stop use + NXoff_geometry instead. + x(NX_FLOAT): + unit: NX_LENGTH + doc: | + x position of the beamstop in relation to the detector. + Note, it is recommended to use NXtransformations instead. + y(NX_FLOAT): + unit: NX_LENGTH + doc: | + y position of the beamstop in relation to the detector. + Note, it is recommended to use NXtransformations instead. + distance_to_detector(NX_FLOAT): + unit: NX_LENGTH + doc: | + distance of the beamstop to the detector. + Note, it is recommended to use NXtransformations instead. + status: + enumeration: [in, out] + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the beam stop is its center in the x and y axis. The reference point on the z axis is the + surface of the beam stop pointing towards the source. + + .. image':'':' beam_stop/beam_stop.png + ':'width':' 40% + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXbending_magnet.yaml b/base_classes/nyaml/NXbending_magnet.yaml new file mode 100644 index 0000000000..001e98304e --- /dev/null +++ b/base_classes/nyaml/NXbending_magnet.yaml @@ -0,0 +1,87 @@ +category: base +doc: | + A bending magnet + +type: group +NXbending_magnet(NXobject): + critical_energy(NX_FLOAT): + unit: NX_ENERGY + bending_radius(NX_FLOAT): + unit: NX_LENGTH + magnetic_field(NX_FLOAT): + unit: NX_CURRENT + doc: | + strength of magnetic field of dipole magnets + accepted_photon_beam_divergence(NX_FLOAT): + unit: NX_LENGTH + doc: | + An array of four numbers giving X+, X-, Y+ and Y- half divergence + source_distance_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance of source point from particle beam waist in X (horizontal) direction. + Note, it is recommended to use NXtransformations instead to place component. + source_distance_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance of source point from particle beam waist in Y (vertical) direction. + Note, it is recommended to use NXtransformations instead to place component. + divergence_x_plus(NX_FLOAT): + unit: NX_ANGLE + doc: | + Accepted photon beam divergence in X+ (horizontal outboard) direction. + Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. + divergence_x_minus(NX_FLOAT): + unit: NX_ANGLE + doc: | + Accepted photon beam divergence in X- (horizontal inboard) direction. + Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. + divergence_y_plus(NX_FLOAT): + unit: NX_ANGLE + doc: | + Accepted photon beam divergence in Y+ (vertical upward) direction. + Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. + divergence_y_minus(NX_FLOAT): + unit: NX_ANGLE + doc: | + Accepted photon beam divergence in Y- (vertical downward) direction. + Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. + spectrum(NXdata): + doc: | + bending magnet spectrum + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the bending magnet and NXoff_geometry to describe its shape instead + doc: | + "Engineering" position of bending magnet + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a bending magnet. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXcapillary.yaml b/base_classes/nyaml/NXcapillary.yaml new file mode 100644 index 0000000000..79bb1c8e7a --- /dev/null +++ b/base_classes/nyaml/NXcapillary.yaml @@ -0,0 +1,59 @@ +category: base +doc: | + A capillary lens to focus the X-ray beam. + + Based on information provided by Gerd Wellenreuther (DESY). + +type: group +NXcapillary(NXobject): + type(NX_CHAR): + doc: | + Type of the capillary + enumeration: [single_bounce, polycapillary, conical_capillary] + manufacturer(NX_CHAR): + doc: | + The manufacturer of the capillary. This is actually important as + it may have an impact on performance. + maximum_incident_angle(NX_FLOAT): + unit: NX_ANGLE + accepting_aperture(NX_FLOAT): + unit: NX_ANGLE + (NXdata)gain: + doc: | + The gain of the capillary as a function of energy + (NXdata)transmission: + doc: | + The transmission of the capillary as a function of energy + working_distance(NX_FLOAT): + unit: NX_LENGTH + focal_size(NX_FLOAT): + doc: | + The focal size in FWHM + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a capillary lens. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXcite.yaml b/base_classes/nyaml/NXcite.yaml new file mode 100644 index 0000000000..aca73c14eb --- /dev/null +++ b/base_classes/nyaml/NXcite.yaml @@ -0,0 +1,40 @@ +category: base +doc: | + A literature reference + + Definition to include references for example for detectors, + manuals, instruments, acquisition or analysis software used. + + The idea would be to include this in the relevant NeXus object':' + ':'ref':'`NXdetector` for detectors, ':'ref':'`NXinstrument` for instruments, etc. + +type: group +NXcite(NXobject): + description(NX_CHAR): + doc: | + This should describe the reason for including this reference. + For example':' The dataset in this group was normalised using the method + which is described in detail in this reference. + url(NX_CHAR): + doc: | + URL referencing the document or data. + doi(NX_CHAR): + doc: | + DOI referencing the document or data. + endnote(NX_CHAR): + doc: | + Bibliographic reference data in EndNote format. + bibtex(NX_CHAR): + doc: | + Bibliographic reference data in BibTeX format. + \@default: + doc: | + .. 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/nyaml/NXcollection.yaml b/base_classes/nyaml/NXcollection.yaml new file mode 100644 index 0000000000..e086b9e074 --- /dev/null +++ b/base_classes/nyaml/NXcollection.yaml @@ -0,0 +1,18 @@ +category: base +doc: | + An unvalidated set of terms, such as the description of a beam line. + + Use ':'ref':'`NXcollection` to gather together any set of terms. + The original suggestion is to use this as a container + class for the description of a beamline. + + For NeXus validation, ':'ref':'`NXcollection` will always generate + a warning since it is always an optional group. + Anything (groups, fields, or attributes) placed in + an ':'ref':'`NXcollection` group will not be validated. + +type: group +ignoreExtraGroups: true +ignoreExtraFields: true +ignoreExtraAttributes: true +NXcollection(NXobject): diff --git a/base_classes/nyaml/NXcollimator.yaml b/base_classes/nyaml/NXcollimator.yaml new file mode 100644 index 0000000000..0f15239665 --- /dev/null +++ b/base_classes/nyaml/NXcollimator.yaml @@ -0,0 +1,81 @@ +category: base +doc: | + A beamline collimator. + +type: group +NXcollimator(NXobject): + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the collimator and NXoff_geometry to describe its shape instead + doc: | + position, shape and size + type: + enumeration: [Soller, radial, oscillating, honeycomb] + soller_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular divergence of Soller collimator + divergence_x(NX_FLOAT): + unit: NX_ANGLE + doc: | + divergence of collimator in local x direction + divergence_y(NX_FLOAT): + unit: NX_ANGLE + doc: | + divergence of collimator in local y direction + frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency of oscillating collimator + (NXlog)frequency_log: + doc: | + Log of frequency + blade_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + blade thickness + blade_spacing(NX_FLOAT): + unit: NX_LENGTH + doc: | + blade spacing + absorbing_material: + doc: | + name of absorbing material + transmitting_material: + doc: | + name of transmitting material + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + Assuming a collimator with a "flat" entry surface, the reference plane is the plane which contains this surface. The reference + point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal + to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. + + .. image':'':' collimator/collimator.png + ':'width':' 40% + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXcrystal.yaml b/base_classes/nyaml/NXcrystal.yaml new file mode 100644 index 0000000000..b40a39f94c --- /dev/null +++ b/base_classes/nyaml/NXcrystal.yaml @@ -0,0 +1,290 @@ +category: base +doc: | + A crystal monochromator or analyzer. + + Permits double bent + monochromator comprised of multiple segments with anisotropic + Gaussian mosaic. + + If curvatures are set to zero or are absent, array + is considered to be flat. + + Scattering vector is perpendicular to surface. Crystal is oriented + parallel to beam incident on crystal before rotation, and lies in + vertical plane. + +symbols: + doc: | + These symbols will be used below to coordinate dimensions with the same lengths. + + n_comp: | + number of different unit cells to be described + + i: | + number of wavelengths + +type: group +NXcrystal(NXobject): + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the crystal and NXoff_geometry to describe its shape instead + doc: | + Position of crystal + usage(NX_CHAR): + doc: | + How this crystal is used. Choices are in the list. + enumeration: + Bragg: + doc: | + reflection geometry + Laue: + doc: | + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard':' + * 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. + This is the *Hill* system used by Chemical Abstracts. + See, for example':' + http':'//www.iucr.org/__data/iucr/cif/standard/cifstd15.html or + http':'//www.cas.org/training/stneasytips/subinforformula1.html. + type: + doc: | + Type or material of monochromating substance. + Chemical formula can be specified separately. + Use the "reflection" field to indicate the (hkl) orientation. + Use the "d_spacing" field to record the lattice plane spacing. + + This field was changed (2010-11-17) from an enumeration to + a string since common usage showed a wider variety of use + than a simple list. These are the items in the list at + the time of the change':' PG (Highly Oriented Pyrolytic Graphite) | + Ge | Si | Cu | Fe3Si | CoFe | Cu2MnAl (Heusler) | Multilayer | + Diamond. + chemical_formula: + doc: | + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard':' + + * 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. + * This is the *Hill* system used by Chemical Abstracts. + order_no(NX_INT): + doc: | + A number which describes if this is the first, second,.. + ':'math':'`n^{th}` crystal in a multi crystal monochromator + cut_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Cut angle of reflecting Bragg plane and plane of crystal surface + space_group: + doc: | + Space group of crystal structure + unit_cell(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell parameters (lengths and angles) + dimensions: + rank: 2 + dim: [[1, n_comp], [2, 6]] + unit_cell_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell lattice parameter':' length of side a + unit_cell_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell lattice parameter':' length of side b + unit_cell_c(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell lattice parameter':' length of side c + unit_cell_alpha(NX_FLOAT): + unit: NX_ANGLE + doc: | + Unit cell lattice parameter':' angle alpha + unit_cell_beta(NX_FLOAT): + unit: NX_ANGLE + doc: | + Unit cell lattice parameter':' angle beta + unit_cell_gamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Unit cell lattice parameter':' angle gamma + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention':' + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Optimum diffracted wavelength + dimensions: + dim: [[1, i]] + d_spacing(NX_FLOAT): + unit: NX_LENGTH + doc: | + spacing between crystal planes of the reflection + scattering_vector(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Scattering vector, Q, of nominal reflection + reflection(NX_INT): + unit: NX_UNITLESS + doc: | + Miller indices (hkl) values of nominal reflection + dimensions: + dim: [[1, 3]] + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the crystal. (Required for Laue orientations - see "usage" field) + density(NX_NUMBER): + unit: NX_MASS_DENSITY + doc: | + mass density of the crystal + segment_width(NX_FLOAT): + unit: NX_LENGTH + doc: | + Horizontal width of individual segment + segment_height(NX_FLOAT): + unit: NX_LENGTH + doc: | + Vertical height of individual segment + segment_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of individual segment + segment_gap(NX_FLOAT): + unit: NX_LENGTH + doc: | + Typical gap between adjacent segments + segment_columns(NX_FLOAT): + unit: NX_LENGTH + doc: | + number of segment columns in horizontal direction + segment_rows(NX_FLOAT): + unit: NX_LENGTH + doc: | + number of segment rows in vertical direction + mosaic_horizontal(NX_FLOAT): + unit: NX_ANGLE + doc: | + horizontal mosaic Full Width Half Maximum + mosaic_vertical(NX_FLOAT): + unit: NX_ANGLE + doc: | + vertical mosaic Full Width Half Maximum + curvature_horizontal(NX_FLOAT): + unit: NX_ANGLE + doc: | + Horizontal curvature of focusing crystal + curvature_vertical(NX_FLOAT): + unit: NX_ANGLE + doc: | + Vertical curvature of focusing crystal + is_cylindrical(NX_BOOLEAN): + doc: | + Is this crystal bent cylindrically? + cylindrical_orientation_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + If cylindrical':' cylinder orientation angle + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Polar (scattering) angle at which crystal assembly is positioned. + Note':' some instrument geometries call this term 2theta. + Note':' it is recommended to use NXtransformations instead. + dimensions: + dim: [[1, i]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Azimuthal angle at which crystal assembly is positioned. + Note':' it is recommended to use NXtransformations instead. + dimensions: + dim: [[1, i]] + bragg_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Bragg angle of nominal reflection + dimensions: + dim: [[1, i]] + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + average/nominal crystal temperature + temperature_coefficient(NX_FLOAT): + unit: NX_ANY + doc: | + how lattice parameter changes with temperature + (NXlog)temperature_log: + doc: | + log file of crystal temperature + (NXdata)reflectivity: + doc: | + crystal reflectivity versus wavelength + (NXdata)transmission: + doc: | + crystal transmission versus wavelength + (NXshape)shape: + deprecated: Use NXoff_geometry instead to describe the shape of the monochromator + doc: | + A NXshape group describing the shape of the crystal arrangement + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a crystal. + (NXtransformations): + doc: | + Transformations used by this component to define its position and orientation. diff --git a/base_classes/nyaml/NXcylindrical_geometry.yaml b/base_classes/nyaml/NXcylindrical_geometry.yaml new file mode 100644 index 0000000000..b8b1ed3b98 --- /dev/null +++ b/base_classes/nyaml/NXcylindrical_geometry.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Geometry description for cylindrical shapes. + This class can be used in place of ``NXoff_geometry`` when an exact + representation for cylinders is preferred. + For example, for Helium-tube, neutron detectors. + It can be used to describe the shape of any beamline component, including detectors. + In the case of detectors it can be used to define the shape of a single pixel, or, + if the pixel shapes are non-uniform, to describe the shape of the whole detector. + +symbols: + doc: | + These symbols will be used below. + + i: | + number of vertices required to define all cylinders in the shape + + j: | + number of cylinders in the shape + + k: | + number cylinders which are detectors + +type: group +NXcylindrical_geometry(NXobject): + vertices(NX_NUMBER): + unit: NX_LENGTH + doc: | + List of x,y,z coordinates for vertices. + The origin of the coordinates is the position of the parent component, for + example the NXdetector which the geometry describes. + If the shape describes a single pixel for a detector with uniform pixel shape + then the origin is the position of each pixel as described by the + ``x/y/z_pixel_offset`` datasets in ``NXdetector``. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + cylinders(NX_INT): + doc: | + List of indices of vertices in the ``vertices`` dataset to form each cylinder. + Each cylinder is described by three vertices A, B, C. + First vertex A lies on the cylinder axis and circular face, second point B + on edge of the same face as A, and third point C at the other face and on axis. + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + detector_number(NX_INT): + doc: | + Maps cylinders in ``cylinder``, by index, with a detector id. + dimensions: + rank: 1 + dim: [[1, k]] + \@default: + doc: | + .. 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/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml new file mode 100644 index 0000000000..637124fe5d --- /dev/null +++ b/base_classes/nyaml/NXdata.yaml @@ -0,0 +1,374 @@ +category: base +doc: | + ':'ref':'`NXdata` describes the plottable data and related dimension scales. + + .. index':'':' plotting + + It is strongly recommended that there is at least one ':'ref':'`NXdata` + group in each ':'ref':'`NXentry` group. + Note that the fields named ``AXISNAME`` and ``DATA`` + can be defined with different names. + (Upper case is used to indicate that the actual name is left to the user.) + The ``signal`` and ``axes`` attributes of the + ``data`` group define which items + are plottable data and which are *dimension scales*, respectively. + + ':'ref':'`NXdata` is used to implement one of the basic motivations in NeXus, + to provide a default plot for the data of this ':'ref':'`NXentry`. The actual data + might be stored in another group and (hard) linked to the ':'ref':'`NXdata` group. + + * Each ':'ref':'`NXdata` group will define one field as the default + plottable data. The value of the ``signal`` attribute names this field. + Additional fields may be used to describe the dimension scales and + uncertainities. + The ``auxiliary_signals`` attribute is a list of the other fields + to be plotted with the ``signal`` data. + * The plottable data may be of arbitrary rank up to a maximum + of ``NX_MAXRANK=32`` (for compatibility with backend file formats). + * The plottable data will be named as the value of + the group ``signal`` attribute, such as':'':' + + data':'NXdata + @signal = "counts" + @axes = "mr" + @mr_indices = 0 + counts':' float[100] --> the default dependent data + mr':' float[100] --> the default independent data + + The field named in the ``signal`` attribute **must** exist, either + directly as a NeXus field or defined through a link. + + * The group ``axes`` attribute will name the + *dimension scale* associated with the plottable data. + + If available, the standard deviations of the data are to be + stored in a data set of the same rank and dimensions, with the name ``errors``. + + * For each data dimension, there should be a one-dimensional array + of the same length. + * These one-dimensional arrays are the *dimension scales* of the + data, *i.e*. the values of the independent variables at which the data + is measured, such as scattering angle or energy transfer. + + .. index':'':' link + .. index':'':' axes (attribute) + + The preferred method to associate each data dimension with + its respective dimension scale is to specify the field name + of each dimension scale in the group ``axes`` attribute as a string list. + Here is an example for a 2-D data set *data* plotted + against *time*, and *pressure*. (An additional *temperature* data set + is provided and could be selected as an alternate for the *pressure* axis.)':'':' + + data_2d':'NXdata + @signal="data" + @axes=["time", "pressure"] + @pressure_indices=1 + @temperature_indices=1 + @time_indices=0 + data':' float[1000,20] + pressure':' float[20] + temperature':' float[20] + time':' float[1000] + + .. rubric':'':' Old methods to identify the plottable data + + There are two older methods of associating + each data dimension to its respective dimension scale. + Both are now out of date and + should not be used when writing new data files. + However, client software should expect to see data files + written with any of these methods. + + * One method uses the ``axes`` + attribute to specify the names of each *dimension scale*. + + * The oldest method uses the ``axis`` attribute on each + *dimension scale* to identify + with an integer the axis whose value is the number of the dimension. + + .. index':' !plot; axis label + plot, axis units + units + dimension scale + + Each axis of the plot may be labeled with information from the + dimension scale for that axis. The optional ``@long_name`` attribute + is provided as the axis label default. If ``@long_name`` is not + defined, then use the name of the dimension scale. A ``@units`` attribute, + if available, may be added to the axis label for further description. + See the section ':'ref':'`Design-Units` for more information. + + .. index':' !plot; axis title + + The optional ``title`` field, if available, provides a suggested + title for the plot. If no ``title`` field is found in the ':'ref':'`NXdata` + group, look for a ``title`` field in the parent ':'ref':'`NXentry` group, + with a fallback to displaying the path to the ':'ref':'`NXdata` group. + + NeXus is about how to find and annotate the data to be plotted + but not to describe how the data is to be plotted. + (https':'//www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) + +symbols: + doc: | + These symbols will be used below to coordinate fields with the same shape. + + dataRank: | + rank of the ``DATA`` field + + n: | + length of the ``AXISNAME`` field + + nx: | + length of the ``x`` field + + ny: | + length of the ``y`` field + + nz: | + length of the ``z`` field + +type: group +ignoreExtraFields: true +ignoreExtraAttributes: true +NXdata(NXobject): + \@auxiliary_signals: + doc: | + .. index':'':' plotting + + Array of strings holding the ':'ref':'`names ` of additional + signals to be plotted with the default ':'ref':'`signal `. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. + + .. NIAC2018':' + https':'//www.nexusformat.org/NIAC2018Minutes.html + \@signal: + doc: | + .. index':'':' find the default plottable data + .. index':'':' plotting + .. index':'':' signal attribute value + + Declares which NeXus field is the default. + The value is the ':'ref':'`name ` of the data field to be plotted. + This field or link *must* exist and be a direct child of this NXdata group. + + It is recommended (as of NIAC2014) to use this attribute + rather than adding a signal attribute to the field. + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + \@axes: + doc: | + .. index':'':' plotting + + Array of strings holding the ':'ref':'`names ` of + the independent data fields used in the default plot for all of + the dimensions of the ':'ref':'`signal ` + as well as any ':'ref':'`auxiliary signals `. + + One name is provided for every dimension in the *signal* or *auxiliary signal* fields. + + The *axes* values are the names of fields or links that *must* exist and be direct + children of this NXdata group. + + An axis slice is specified using a field named ``AXISNAME_indices`` + as described below (where the text shown here as ``AXISNAME`` is to be + replaced by the actual field name). + + When no default axis is available for a particular dimension + of the plottable data, use a "." in that position. + Such as':'':' + + @axes=["time", ".", "."] + + Since there are three items in the list, the *signal* field + must be a three-dimensional array (rank=3). The first dimension + is described by the values of a one-dimensional array named ``time`` + while the other two dimensions have no fields to be used as dimension scales. + + See examples provided on the NeXus wiki':' + https':'//www.nexusformat.org/2014_axes_and_uncertainties.html + + If there are no axes at all (such as with a stack of images), + the axes attribute can be omitted. + \@AXISNAME_indices: + type: NX_INT + doc: | + Each ``AXISNAME_indices`` attribute indicates the dependency + relationship of the ``AXISNAME`` field (where ``AXISNAME`` + is the name of a field that exists in this ``NXdata`` group) + with one or more dimensions of the plottable data. + + Integer array that defines the indices of the *signal* field + (that field will be a multidimensional array) + which need to be used in the *AXISNAME* field in + order to reference the corresponding axis value. + + The first index of an array is ``0`` (zero). + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + An example with 2-D data, ':'math':'`d(t,P)`, will illustrate':'':' + + data_2d':'NXdata + @signal="data" + @axes=["time", "pressure"] + @time_indices=0 + @pressure_indices=1 + data':' float[1000,20] + time':' float[1000] + pressure':' float[20] + + This attribute is to be provided in all situations. + However, if the indices attributes are missing + (such as for data files written before this specification), + file readers are encouraged to make their best efforts + to plot the data. + Thus the implementation of the + ``AXISNAME_indices`` attribute is based on the model of + "strict writer, liberal reader". + + .. note':'':' Attributes potentially containing multiple values + (axes and _indices) are to be written as string or integer arrays, + to avoid string parsing in reading applications. + AXISNAME(NX_NUMBER): + nameType: any + doc: | + Dimension scale defining an axis of the data. + Client is responsible for defining the dimensions of the data. + The name of this field may be changed to fit the circumstances. + Standard NeXus client tools will use the attributes to determine + how to use this field. + dimensions: + rank: 1 + doc: | + A *dimension scale* must have a rank of 1 and has length ``n``. + dim: [[1, n]] + \@long_name: + doc: | + Axis label + \@distribution: + type: NX_BOOLEAN + doc: | + ``0|false``':' single value, + ``1|true``':' multiple values + \@first_good: + type: NX_INT + doc: | + Index of first good value + \@last_good: + type: NX_INT + doc: | + Index of last good value + \@axis: + type: NX_POSINT + deprecated: Use the group ``axes`` attribute (NIAC2014) + doc: | + Index (positive integer) identifying this specific set of numbers. + + N.B. The ``axis`` attribute is the old way of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + The ``axes`` *group* attribute is now preferred. + FIELDNAME_errors(NX_NUMBER): + nameType: any + doc: | + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. + DATA(NX_NUMBER): + nameType: any + doc: | + .. index':'':' plotting + + This field contains the data values to be used as the + NeXus *plottable data*. + Client is responsible for defining the dimensions of the data. + The name of this field may be changed to fit the circumstances. + Standard NeXus client tools will use the attributes to determine + how to use this field. + dimensions: + rank: dataRank + doc: | + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + At least one ``dim`` must have length ``n``. + dim: [] + \@signal: + type: NX_POSINT + deprecated: Use the group ``signal`` attribute (NIAC2014) + doc: | + .. index':'':' plotting + + Plottable (independent) axis, indicate index number. + Only one field in a ':'ref':'`NXdata` group may have the + ``signal=1`` attribute. + Do not use the ``signal`` attribute with the ``axis`` attribute. + \@axes: + deprecated: Use the group ``axes`` attribute (NIAC2014) + doc: | + Defines the names of the dimension scales + (independent axes) for this data set + as a colon-delimited array. + NOTE':' The ``axes`` attribute is the preferred + method of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + \@long_name: + doc: | + data label + errors(NX_NUMBER): + deprecated: Use ``DATA_errors`` instead (NIAC2018) + doc: | + Standard deviations of data values - + the data array is identified by the group attribute ``signal``. + The ``errors`` array must have the same dimensions as ``DATA``. + Client is responsible for defining the dimensions of the data. + dimensions: + rank: dataRank + doc: | + The ``errors`` must have + the same rank (``dataRank``) + as the ``data``. + At least one ``dim`` must have length "n". + dim: [] + scaling_factor(NX_FLOAT): + doc: | + The elements in data are usually float values really. For + efficiency reasons these are usually stored as integers + after scaling with a scale factor. This value is the scale + factor. It is required to get the actual physical value, + when necessary. + offset(NX_FLOAT): + doc: | + An optional offset to apply to the values in data. + title: + doc: | + Title for the plot. + x(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nx]] + y(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, ny]] + z(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nz]] diff --git a/base_classes/nyaml/NXdetector.nxdl.xml b/base_classes/nyaml/NXdetector.nxdl.xml deleted file mode 100644 index f2bb8fbb8d..0000000000 --- a/base_classes/nyaml/NXdetector.nxdl.xml +++ /dev/null @@ -1,801 +0,0 @@ - - - - - - These symbols will be used below to coordinate datasets with the same - shape. - - - - number of scan points (only present in scanning measurements) - - - - - number of detector pixels in the first (slowest) direction - - - - - number of detector pixels in the second (faster) direction - - - - - number of detector pixels in the third (if necessary, fastest) - direction - - - - - number of bins in the time-of-flight histogram - - - - - A detector, detector bank, or multidetector. - - - - Total time of flight - - - - - - - - - - - - - - - - - Total time of flight - - - - - - In DAQ clock pulses - - - - - - - Clock frequency in Hz - - - - - - Identifier for detector (pixels) Can be multidimensional, if needed - - - - - Data values from the detector. - - - - - - - - - - Title of measurement - - - - - Integral of data as check of data integrity - - - - - - The best estimate of the uncertainty in the data value. Where possible, this - should be the standard deviation, which has the same units as the data. The form - data_error is deprecated. - - - - - - - - - - - Offset from the detector center in x-direction. Can be multidimensional when - needed. - - - - - - - - - - - - - - x-axis offset from detector center - - - - - - Offset from the detector center in the y-direction. Can be multidimensional when - different values are required for each pixel. - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - Offset from the detector center in the z-direction. Can be multidimensional when - different values are required for each pixel. - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - This is the distance to the previous component in the instrument; most often the - sample. The usage depends on the nature of the detector: Most often it is the - distance of the detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - - - - - - - - - This is the polar angle of the detector towards the previous component in the - instrument; most often the sample. The usage depends on the nature of the - detector. Most often it is the polar_angle of the detector assembly. But there - are irregular detectors. In this case, the polar_angle must be specified for - each detector pixel. - - - - - - - - - - This is the azimuthal angle angle of the detector towards the previous component - in the instrument; most often the sample. The usage depends on the nature of the - detector. Most often it is the azimuthal_angle of the detector assembly. But - there are irregular detectors. In this case, the azimuthal_angle must be - specified for each detector pixel. - - - - - - - - - - name/manufacturer/model/etc. information - - - - - Serial number for the detector - - - - - Local name for the detector - - - - - Position and orientation of detector - - - - - Solid angle subtended by the detector at the sample - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size. - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size - - - - - - - - - Detector dead time - - - - - - - - - - Detector gas pressure - - - - - - - - - maximum drift space dimension - - - - - Crate number of detector - - - - - - - - Equivalent local term - - - - - - Slot number of detector - - - - - - - - Equivalent local term - - - - - - Input number of detector - - - - - - - - Equivalent local term - - - - - - Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission - chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, ... - - - - - Spectral efficiency of detector with respect to e.g. wavelength - - - - - - - - - - - - - - - - - - - - - - - efficiency of the detector - - - - - - - - - - This field can be two things: - - #. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - #. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - - - - - - - - - - - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - - - - - - - - - - Start time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - stop time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - date of last calibration (geometry and/or efficiency) measurements - - - - - summary of conversion of array data to pixels (e.g. polynomial approximations) - and location of details of the calibrations - - - - - How the detector is represented - - - - - - - - - - Elapsed actual counting time - - - - - - - - - Use this group to provide other data related to this NXdetector group. - - - - - In order to properly sort the order of the images taken in (for example) a - tomography experiment, a sequence number is stored with each image. - - - - - - - - This is the x position where the direct beam would hit the detector. This is a - length and can be outside of the actual detector. The length can be in physical - units or pixels as documented by the units attribute. - - - - - This is the y position where the direct beam would hit the detector. This is a - length and can be outside of the actual detector. The length can be in physical - units or pixels as documented by the units attribute. - - - - - This is the start number of the first frame of a scan. In PX one often scans a - couple of frames on a give sample, then does something else, then returns to the - same sample and scans some more frames. Each time with a new data file. This - number helps concatenating such measurements. - - - - - The diameter of a cylindrical detector - - - - - The acquisition mode of the detector. - - - - - - - - - - - - - True when the angular calibration has been applied in the electronics, false - otherwise. - - - - - Angular calibration data. - - - - - - - - - True when the flat field correction has been applied in the electronics, false - otherwise. - - - - - Flat field correction data. - - - - - - - - - Errors of the flat field correction data. The form flatfield_error is - deprecated. - - - - - - - - - True when the pixel mask correction has been applied in the electronics, false - otherwise. - - - - - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - - - - - - - - - True when a count-rate correction has already been applied in the electronics, - false otherwise. - - - - - How many bits the electronics reads per pixel. With CCD's and single photon - counting detectors, this must not align with traditional integer sizes. This can - be 4, 8, 12, 14, 16, ... - - - - - Time it takes to read the detector (typically milliseconds). This is important - to know for time resolved experiments. - - - - - Time it takes to start exposure after a trigger signal has been received. This - is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set - delay.. This is important to know for time resolved experiments. - - - - - User-specified trigger delay. - - - - - Time it takes to start exposure after a trigger signal has been received. This - is the reaction time of the detector hardware after receiving the trigger signal - to when the detector starts to acquire the exposure. It forms the lower boundary - of the trigger_delay_time when the user does not request an additional delay. - - - - - Time during which no new trigger signal can be accepted. Typically this is the - trigger_delay_time + exposure_time + readout_time. This is important to know for - time resolved experiments. - - - - - This is time for each frame. This is exposure_time + readout time. - - - - - - - - The gain setting of the detector. This influences background etc. - - - - - - - - - - - The value at which the detector goes into saturation. Especially common to CCD - detectors, the data is known to be invalid above this value. For example, given - a saturation_value and an underload_value, the valid pixels are those less than - or equal to the saturation_value and greater than or equal to the - underload_value. - - - - - The lowest value at which pixels for this detector would be reasonably measured. - The data is known to be invalid below this value. For example, given a - saturation_value and an underload_value, the valid pixels are those less than or - equal to the saturation_value and greater than or equal to the underload_value. - - - - - CCD images are sometimes constructed by summing together multiple short - exposures in the electronics. This reduces background etc. This is the number of - short exposures used to sum images for an image. - - - - - At times, radiation is not directly sensed by the detector. Rather, the detector - might sense the output from some converter like a scintillator. This is the name - of this converter material. - - - - - At times, radiation is not directly sensed by the detector. Rather, the detector - might sense the output from some converter like a scintillator. This is the - thickness of this converter material. - - - - - Single photon counter detectors can be adjusted for a certain energy range in - which they work optimally. This is the energy setting for this. - - - - - For use in special cases where the data in NXdetector is represented in several - parts, each with a separate geometry. Use one or more instances of the - NXdetector_module group to declare regions of interest or some other subdivision - of a detector. - - - - Shape description of the whole detector. Use only if pixels in the detector are - not of uniform shape. - - - - - Shape description of the whole detector. Use only if pixels in the detector are - not of uniform shape and require being described by cylinders. - - - - - - .. 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. - - - - - Type of electron amplifier, MCP, channeltron, etc. - - - - - Description of the detector type, DLD, Phosphor+CCD, CMOS. - - - - - Voltage applied to detector. - - - - - Voltage applied to the amplifier. - - - - - The low voltage of the amplifier migh not be the ground. - - - - - Size of each imaging sensor chip on the detector. - - - - - Number of imaging sensor chips on the detector. - - - - - Physical size of the pixels of the imaging chip on the detector. - - - - - Number of raw active elements in each dimension. Important for swept scans. - - - - - raw data output from the detector - - - diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml index 6e38945a95..10c01743e1 100644 --- a/base_classes/nyaml/NXdetector.yaml +++ b/base_classes/nyaml/NXdetector.yaml @@ -1,188 +1,297 @@ -doc: "A detector, detector bank, or multidetector." -symbols: - doc: "These symbols will be used below to coordinate datasets with the same shape." - np: "number of scan points (only present in scanning measurements)" - i: "number of detector pixels in the first (slowest) direction" - j: "number of detector pixels in the second (faster) direction" - k: "number of detector pixels in the third (if necessary, fastest) direction" - tof: "number of bins in the time-of-flight histogram" category: base -NXdetector: +doc: | + A detector, detector bank, or multidetector. + +symbols: + doc: | + These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the + preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering principle is slowest to fastest. + The type of each dimension should follow the order of scan points, detector output (e.g. pixels), + then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited + to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced + by a detector at each trigger. + + nP: | + number of scan points (only present in scanning measurements) + + i: | + number of detector pixels in the first (slowest) direction + + j: | + number of detector pixels in the second (faster) direction + + tof: | + number of bins in the time-of-flight histogram + +type: group +(NXobject)NXdetector: time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT - doc: "Total time of flight" + doc: | + Total time of flight dimensions: rank: 1 dim: [[1, tof+1]] \@axis: + type: NX_POSINT + deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 enumeration: [3] \@primary: + type: NX_POSINT + deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: - doc: "Total time of flight" + doc: | + Total time of flight raw_time_of_flight(NX_INT): unit: NX_PULSES - doc: "In DAQ clock pulses" + doc: | + In DAQ clock pulses dimensions: rank: 1 dim: [[1, tof+1]] \@frequency: - doc: "Clock frequency in Hz" + type: NX_NUMBER + doc: | + Clock frequency in Hz detector_number(NX_INT): - doc: "Identifier for detector (pixels) - Can be multidimensional, if needed" + doc: | + Identifier for detector (pixels) + Can be multidimensional, if needed data(NX_NUMBER): unit: NX_ANY - doc: "Data values from the detector." + doc: | + Data values from the detector. The rank and dimension ordering should follow a principle of + slowest to fastest measurement axes and may be explicitly specified in application definitions. + + Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be + the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions + of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single + scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. + Repetition of an experiment in a time series tends to be used similar to a slow scan axis + and so will often be in the first dimension of the data array. + + The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions + (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an + imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data + will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to + be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. + + Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift + detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. + + The type of each dimension should should follow the order of scan points, detector pixels, + then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) + shown here are merely illustrative of coordination between related datasets. dimensions: rank: 4 - dim: [[1, np], [2, i], [3, j], [4, tof]] + dim: [[1, nP], [2, i], [3, j], [4, tof]] \@long_name: - doc: "Title of measurement" + doc: | + Title of measurement \@check_sum: - doc: "Integral of data as check of data integrity" + type: NX_INT + doc: | + Integral of data as check of data integrity data_errors(NX_NUMBER): unit: NX_ANY - doc: "The best estimate of the uncertainty in the data value. Where + doc: | + The best estimate of the uncertainty in the data value (array size should match the data field). Where possible, this should be the standard deviation, which has the same units - as the data. The form data_error is deprecated." + as the data. The form data_error is deprecated. dimensions: rank: 4 - dim: [[1, np], [2, i], [3, j], [4, tof]] + dim: [[1, nP], [2, i], [3, j], [4, tof]] x_pixel_offset(NX_FLOAT): unit: NX_LENGTH - doc: "Offset from the detector center in x-direction. - Can be multidimensional when needed." + doc: | + Offset from the detector center in x-direction. + Can be multidimensional when needed. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] \@axis: + type: NX_POSINT + deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 enumeration: [1] \@primary: + type: NX_POSINT + deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: - doc: "x-axis offset from detector center" + doc: | + x-axis offset from detector center y_pixel_offset(NX_FLOAT): unit: NX_LENGTH - doc: "Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel." + doc: | + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] \@axis: + type: NX_POSINT + deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 enumeration: [2] \@primary: + type: NX_POSINT + deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: - doc: "y-axis offset from detector center" + doc: | + y-axis offset from detector center z_pixel_offset(NX_FLOAT): unit: NX_LENGTH - doc: "Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel." + doc: | + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] \@axis: + type: NX_POSINT + deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 enumeration: [3] \@primary: + type: NX_POSINT + deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: - doc: "y-axis offset from detector center" + doc: | + y-axis offset from detector center distance(NX_FLOAT): unit: NX_LENGTH - doc: "This is the distance to the previous component in the + doc: | + This is the distance to the previous component in the instrument; most often the sample. The usage depends on the - nature of the detector: Most often it is the distance of the + nature of the detector':' Most often it is the distance of the detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel." + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. dimensions: rank: 3 - dim: [[1, np], [2, i], [3, j]] + dim: [[1, nP], [2, i], [3, j]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: "This is the polar angle of the detector towards the previous + doc: | + This is the polar angle of the detector towards the previous component in the instrument; most often the sample. The usage depends on the nature of the detector. Most often it is the polar_angle of the detector assembly. But there are irregular detectors. In this - case, the polar_angle must be specified for each detector pixel." + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. dimensions: rank: 3 - dim: [[1, np], [2, i], [3, j]] + dim: [[1, nP], [2, i], [3, j]] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: "This is the azimuthal angle angle of the detector towards + doc: | + This is the azimuthal angle angle of the detector towards the previous component in the instrument; most often the sample. The usage depends on the nature of the detector. Most often it is the azimuthal_angle of the detector assembly. But there are irregular detectors. In this - case, the azimuthal_angle must be specified for each detector pixel." + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. dimensions: rank: 3 - dim: [[1, np], [2, i], [3, j]] + dim: [[1, nP], [2, i], [3, j]] description: - doc: "name/manufacturer/model/etc. information" + doc: | + name/manufacturer/model/etc. information serial_number: - doc: "Serial number for the detector" + doc: | + Serial number for the detector local_name: - doc: "Local name for the detector" + doc: | + Local name for the detector (NXgeometry): - doc: "Position and orientation of detector" + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead + doc: | + Position and orientation of detector solid_angle(NX_FLOAT): unit: NX_SOLID_ANGLE - doc: "Solid angle subtended by the detector at the sample" + doc: | + Solid angle subtended by the detector at the sample dimensions: rank: 2 dim: [[1, i], [2, j]] x_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: "Size of each detector pixel. If it is scalar all pixels are the same size." + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size. dimensions: rank: 2 dim: [[1, i], [2, j]] y_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: "Size of each detector pixel. If it is scalar all pixels are the same size" + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size dimensions: rank: 2 dim: [[1, i], [2, j]] dead_time(NX_FLOAT): unit: NX_TIME - doc: "Detector dead time" + doc: | + Detector dead time dimensions: rank: 3 - dim: [[1, np], [2, i], [3, j]] + dim: [[1, nP], [2, i], [3, j]] gas_pressure(NX_FLOAT): unit: NX_PRESSURE - doc: "Detector gas pressure" + doc: | + Detector gas pressure dimensions: rank: 2 dim: [[1, i], [2, j]] detection_gas_path(NX_FLOAT): unit: NX_LENGTH - doc: "maximum drift space dimension" + doc: | + maximum drift space dimension crate(NX_INT): - doc: "Crate number of detector" + doc: | + Crate number of detector dimensions: rank: 2 dim: [[1, i], [2, j]] \@local_name: - doc: "Equivalent local term" + doc: | + Equivalent local term slot(NX_INT): - doc: "Slot number of detector" + doc: | + Slot number of detector dimensions: rank: 2 dim: [[1, i], [2, j]] \@local_name: - doc: "Equivalent local term" + doc: | + Equivalent local term input(NX_INT): - doc: "Input number of detector" + doc: | + Input number of detector dimensions: rank: 2 dim: [[1, i], [2, j]] \@local_name: - doc: "Equivalent local term" + doc: | + Equivalent local term type: - doc: "Description of type such as He3 gas cylinder, He3 PSD, scintillator, + doc: | + Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ..." + CMOS, ... efficiency(NXdata): - doc: "Spectral efficiency of detector with respect to e.g. wavelength" + doc: | + Spectral efficiency of detector with respect to e.g. wavelength \@signal: enumeration: [efficiency] \@axes: @@ -191,18 +300,19 @@ NXdetector: enumeration: [0] efficiency(NX_FLOAT): unit: NX_DIMENSIONLESS - doc: "efficiency of the detector" + doc: | + efficiency of the detector dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] + rank: 2 + dim: [[1, i], [2, j]] wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | - This field can be two things: - + doc: | + This field can be two things':' + #. For a pixel detector it provides the nominal wavelength for which the detector has been calibrated. - + #. For other detectors this field has to be seen together with the efficiency field above. For some detectors, the efficiency is wavelength dependent. @@ -210,14 +320,14 @@ NXdetector: In this use case, the efficiency and wavelength arrays must have the same dimensionality. dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] + rank: 2 + dim: [[1, i], [2, j]] real_time(NX_NUMBER): unit: NX_TIME - doc: | + doc: | Real-time of the exposure (use this if exposure time varies for each array element, otherwise use ``count_time`` field). - + Most often there is a single real time value that is constant across an entire image frame. In such cases, only a 1-D array is needed. But there are detectors in which the real time @@ -225,118 +335,139 @@ NXdetector: the rank of this field should be less than or equal to (detector rank + 1). dimensions: rank: 3 - dim: [[1, np], [2, i], [3, j]] + dim: [[1, nP], [2, i], [3, j]] start_time(NX_FLOAT): unit: NX_TIME - doc: "Start time for each frame, with the ``start`` attribute as absolute reference" + doc: | + start time for each frame, with the ``start`` attribute as absolute reference dimensions: rank: 1 - dim: [[1, np]] + dim: [[1, nP]] \@start: + type: NX_DATE_TIME stop_time(NX_FLOAT): unit: NX_TIME - doc: "stop time for each frame, with the ``start`` attribute as absolute reference" + doc: | + stop time for each frame, with the ``start`` attribute as absolute reference dimensions: rank: 1 - dim: [[1, np]] + dim: [[1, nP]] \@start: + type: NX_DATE_TIME calibration_date(NX_DATE_TIME): - doc: "date of last calibration (geometry and/or efficiency) measurements" + doc: | + date of last calibration (geometry and/or efficiency) measurements calibration_method(NXnote): - doc: "summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations" + doc: | + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations layout: - doc: "How the detector is represented" + doc: | + How the detector is represented enumeration: [point, linear, area] count_time(NX_NUMBER): unit: NX_TIME - doc: "Elapsed actual counting time" + doc: | + Elapsed actual counting time dimensions: rank: 1 - dim: [[1, np]] + dim: [[1, nP]] data_file(NXnote): (NXcollection): - doc: "Use this group to provide other data related to this NXdetector group." + doc: | + Use this group to provide other data related to this NXdetector group. sequence_number(NX_INT): - doc: "In order to properly sort the order of the images taken in (for + doc: | + In order to properly sort the order of the images taken in (for example) a tomography experiment, a sequence number is stored with each - image." + image. dimensions: rank: 1 - dim: [[1, nBrightFrames]] + dim: [[1, nP]] beam_center_x(NX_FLOAT): unit: NX_LENGTH - doc: "This is the x position where the direct beam would hit the detector. + doc: | + This is the x position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels - as documented by the units attribute." + as documented by the units attribute. beam_center_y(NX_FLOAT): unit: NX_LENGTH - doc: "This is the y position where the direct beam would hit the detector. + doc: | + This is the y position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels - as documented by the units attribute." + as documented by the units attribute. frame_start_number(NX_INT): - doc: "This is the start number of the first frame of a scan. In PX one + doc: | + This is the start number of the first frame of a scan. In protein crystallography measurements one often scans a couple of frames on a give sample, then does something else, then returns to the same sample and scans some more frames. Each time with - a new data file. This number helps concatenating such measurements." + a new data file. This number helps concatenating such measurements. diameter(NX_FLOAT): unit: NX_LENGTH - doc: "The diameter of a cylindrical detector" + doc: | + The diameter of a cylindrical detector acquisition_mode(NX_CHAR): - doc: "The acquisition mode of the detector." + doc: | + The acquisition mode of the detector. enumeration: [gated, triggered, summed, event, histogrammed, decimated] angular_calibration_applied(NX_BOOLEAN): - doc: "True when the angular calibration has been applied in the - electronics, false otherwise." + doc: | + True when the angular calibration has been applied in the + electronics, false otherwise. angular_calibration(NX_FLOAT): - doc: "Angular calibration data." + doc: | + Angular calibration data. dimensions: rank: 2 dim: [[1, i], [2, j]] flatfield_applied(NX_BOOLEAN): - doc: "True when the flat field correction has been applied in the - electronics, false otherwise." + doc: | + True when the flat field correction has been applied in the + electronics, false otherwise. flatfield(NX_FLOAT): - doc: "Flat field correction data." + doc: | + Flat field correction data. dimensions: rank: 2 dim: [[1, i], [2, j]] flatfield_errors(NX_FLOAT): - doc: "Errors of the flat field correction data. - The form flatfield_error is deprecated." + doc: | + Errors of the flat field correction data. + The form flatfield_error is deprecated. dimensions: rank: 2 dim: [[1, i], [2, j]] pixel_mask_applied(NX_BOOLEAN): - doc: "True when the pixel mask correction has been applied in the - electronics, false otherwise." + doc: | + True when the pixel mask correction has been applied in the + electronics, false otherwise. pixel_mask(NX_INT): - doc: | + doc: | The 32-bit pixel mask for the detector. Can be either one mask for the whole dataset (i.e. an array with indices i, j) or each frame can have its own mask (in which case it would be an array with indices np, i, j). - + Contains a bit field for each pixel to signal dead, blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - + They have the following meaning':' + .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - + + * bit 0':' gap (pixel with no sensor) + * bit 1':' dead + * bit 2':' under responding + * bit 3':' over responding + * bit 4':' noisy + * bit 5':' -undefined- + * bit 6':' pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7':' -undefined- + * bit 8':' user defined mask (e.g. around beamstop) + * bits 9-30':' -undefined- + * bit 31':' virtual pixel (corner pixel with interpolated value) + Normal data analysis software would not take pixels into account when a bit in (mask & 0x0000FFFF) is @@ -346,10 +477,10 @@ NXdetector: would not be a sole reason to reject the intensity value (unless lower bits are set. - + If the full bit depths is not required, providing a mask with fewer bits is permissible. - + If needed, additional pixel masks can be specified by including additional entries named pixel_mask_N, where N is an integer. For example, a general bad pixel mask @@ -361,137 +492,211 @@ NXdetector: dimensions: rank: 2 dim: [[1, i], [2, j]] + image_key(NX_INT): + doc: | + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`':'ref':'`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows':' + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type ':'ref':'`NXlog` this can also be an NXlog. + dimensions: + rank: 1 + dim: [[1, np]] countrate_correction_applied(NX_BOOLEAN): - doc: "True when a count-rate correction has already been applied in the - electronics, false otherwise." + doc: | + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + countrate_correction_lookup_table(NX_NUMBER): + doc: | + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count ':'math':'`c` to its corrected value + ':'math':'`countrate\_correction\_lookup\_table[c]`. + + ':'math':'`m` denotes the length of the table. + dimensions: + rank: 1 + dim: [[1, m]] + virtual_pixel_interpolation_applied(NX_BOOLEAN): + doc: | + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. bit_depth_readout(NX_INT): - doc: "How many bits the electronics reads per pixel. + doc: | + How many bits the electronics reads per pixel. With CCD's and single photon counting detectors, this must not align with traditional integer sizes. - This can be 4, 8, 12, 14, 16, ..." + This can be 4, 8, 12, 14, 16, ... detector_readout_time(NX_FLOAT): unit: NX_TIME - doc: "Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments." + doc: | + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. trigger_delay_time(NX_FLOAT): unit: NX_TIME - doc: "Time it takes to start exposure after a trigger signal has been received. + doc: | + Time it takes to start exposure after a trigger signal has been received. This is the reaction time of the detector firmware after receiving the trigger signal to when the detector starts to acquire the exposure, including any user set delay.. - This is important to know for time resolved experiments." + This is important to know for time resolved experiments. trigger_delay_time_set(NX_FLOAT): unit: NX_TIME - doc: "User-specified trigger delay." + doc: | + User-specified trigger delay. trigger_internal_delay_time(NX_FLOAT): unit: NX_TIME - doc: "Time it takes to start exposure after a trigger signal has been received. + doc: | + Time it takes to start exposure after a trigger signal has been received. This is the reaction time of the detector hardware after receiving the trigger signal to when the detector starts to acquire the exposure. It forms the lower boundary of the trigger_delay_time when the user - does not request an additional delay." + does not request an additional delay. trigger_dead_time(NX_FLOAT): unit: NX_TIME - doc: "Time during which no new trigger signal can be accepted. + doc: | + Time during which no new trigger signal can be accepted. Typically this is the trigger_delay_time + exposure_time + readout_time. - This is important to know for time resolved experiments." + This is important to know for time resolved experiments. frame_time(NX_FLOAT): unit: NX_TIME - doc: "This is time for each frame. This is exposure_time + readout time." + doc: | + This is time for each frame. This is exposure_time + readout time. dimensions: rank: 1 - dim: [[1, NP]] + dim: [[1, nP]] gain_setting(NX_CHAR): - doc: "The gain setting of the detector. This influences background etc." - enumeration: [high, standard, fast, auto] - saturation_value(NX_INT): - doc: "The value at which the detector goes into saturation. + doc: | + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include':' + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + saturation_value(NX_NUMBER): + doc: | + The value at which the detector goes into saturation. Especially common to CCD detectors, the data is known to be invalid above this value. + For example, given a saturation_value and an underload_value, the valid pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value." - underload_value(NX_INT): - doc: "The lowest value at which pixels for this detector would be reasonably + than or equal to the underload_value. + + The precise type should match the type of the data. + underload_value(NX_NUMBER): + doc: | + The lowest value at which pixels for this detector would be reasonably measured. The data is known to be invalid below this value. + For example, given a saturation_value and an underload_value, the valid pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value." + than or equal to the underload_value. + + The precise type should match the type of the data. number_of_cycles(NX_INT): - doc: "CCD images are sometimes constructed by summing + doc: | + CCD images are sometimes constructed by summing together multiple short exposures in the electronics. This reduces background etc. This is the number of short exposures used to sum - images for an image." + images for an image. sensor_material(NX_CHAR): - doc: "At times, radiation is not directly sensed by the detector. + doc: | + At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. - This is the name of this converter material." + This is the name of this converter material. sensor_thickness(NX_FLOAT): unit: NX_LENGTH - doc: "At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the thickness of this converter material." + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. threshold_energy(NX_FLOAT): unit: NX_ENERGY - doc: "Single photon counter detectors can be adjusted + doc: | + Single photon counter detectors can be adjusted for a certain energy range in which they - work optimally. This is the energy setting for this." + work optimally. This is the energy setting for this. (NXdetector_module): - doc: "For use in special cases where the data in NXdetector + doc: | + For use in special cases where the data in NXdetector is represented in several parts, each with a separate geometry. - Use one or more instances of the NXdetector_module - group to declare regions of interest or some other - subdivision of a detector." + pixel_shape(choice): (NXoff_geometry): - doc: "Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape." + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. (NXcylindrical_geometry): - doc: "Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders." + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + detector_shape(choice): (NXoff_geometry): - doc: "Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape." + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. (NXcylindrical_geometry): - doc: "Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders." + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. + doc: | + .. 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. - amplifier_type(NX_CHAR): - doc: "Type of electron amplifier, MCP, channeltron, etc." - detector_type(NX_CHAR): - doc: "Description of the detector type, DLD, Phosphor+CCD, CMOS." - detector_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: "Voltage applied to detector." - amplifier_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: "Voltage applied to the amplifier." - amplifier_bias(NX_FLOAT): - unit: NX_VOLTAGE - doc: "The low voltage of the amplifier migh not be the ground." - sensor_size(NX_FLOAT): - unit: NX_LENGTH - doc: "Size of each imaging sensor chip on the detector." - sensor_count(NX_INT): - unit: NX_UNITLESS - doc: "Number of imaging sensor chips on the detector." - sensor_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: "Physical size of the pixels of the imaging chip on the detector." - sensor_pixels(NX_INT): - unit: NX_UNITLESS - doc: "Number of raw active elements in each dimension. Important for swept scans." - (NXdata): - doc: "raw data output from the detector" + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXdetector_group.yaml b/base_classes/nyaml/NXdetector_group.yaml new file mode 100644 index 0000000000..f6903e382b --- /dev/null +++ b/base_classes/nyaml/NXdetector_group.yaml @@ -0,0 +1,77 @@ +category: base +doc: | + Logical grouping of detectors. When used, describes a group of detectors. + + Each detector is represented as an NXdetector + with its own detector data array. Each detector data array + may be further decomposed into array sections by use of + NXdetector_module groups. Detectors can be grouped logically + together using NXdetector_group. Groups can be further grouped + hierarchically in a single NXdetector_group (for example, if + there are multiple detectors at an endstation or multiple + endstations at a facility). Alternatively, multiple + NXdetector_groups can be provided. + + The groups are defined hierarchically, with names given + in the group_names field, unique identifying indices given + in the field group_index, and the level in the hierarchy + given in the group_parent field. For example if an x-ray + detector group, DET, consists of four detectors in a + rectangular array':'':' + + DTL DTR + DLL DLR + + We could have':'':' + + group_names':' ["DET", "DTL", "DTR", "DLL", "DLR"] + group_index':' [1, 2, 3, 4, 5] + group_parent':' [-1, 1, 1, 1, 1] + +type: group +NXdetector_group(NXobject): + group_names(NX_CHAR): + doc: | + An array of the names of the detectors given in NXdetector + groups or the names of hierarchical groupings of detectors + given as names of NXdetector_group groups or in + NXdetector_group group_names and group_parent fields as + having children. + group_index(NX_INT): + doc: | + An array of unique identifiers for detectors or groupings + of detectors. + + Each ID is a unique ID for the corresponding detector or group + named in the field group_names. The IDs are positive integers + starting with 1. + dimensions: + dim: [[1, i]] + group_parent(NX_INT): + doc: | + An array of the hierarchical levels of the parents of detectors + or groupings of detectors. + + A top-level grouping has parent level -1. + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['group_index'] + group_type(NX_INT): + doc: | + Code number for group type, e.g. bank=1, tube=2 etc. + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['group_index'] + \@default: + doc: | + .. 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/nyaml/NXdetector_module.yaml b/base_classes/nyaml/NXdetector_module.yaml new file mode 100644 index 0000000000..7e5b95cee6 --- /dev/null +++ b/base_classes/nyaml/NXdetector_module.yaml @@ -0,0 +1,120 @@ +category: base +doc: | + Geometry and logical description of a detector module. When used, child group to NXdetector. + + Many detectors consist of multiple + smaller modules. Sometimes it is important to know the exact position of such + modules. + This is the purpose of this group. It is a child group to NXdetector. + + Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. + +type: group +NXdetector_module(NXobject): + data_origin(NX_INT): + doc: | + A dimension-2 or dimension-3 field which gives the indices + of the origin of the hyperslab of data for this module in the + main area detector image in the parent NXdetector module. + + The data_origin is 0-based. + + The frame number dimension (np) is omitted. Thus the + data_origin field for a dimension-2 dataset with indices (np, i, j) + will be an array with indices (i, j), and for a dimension-3 + dataset with indices (np, i, j, k) will be an array with indices + (i, j, k). + + The ':'ref':'`order ` of indices (i, j or i, j, k) is slow to fast. + data_size(NX_INT): + doc: | + Two or three values for the size of the module in pixels in + each direction. Dimensionality and order of indices is the + same as for data_origin. + module_offset(NX_NUMBER): + unit: NX_LENGTH + doc: | + Offset of the module in regards to the origin of the detector in an + arbitrary direction. + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the axis for this transformation + \@offset: + type: NX_NUMBER + doc: | + A fixed offset applied before the transformation (three vector components). + \@offset_units: + type: NX_CHAR + doc: | + Units of the offset. + \@depends_on: + type: NX_CHAR + doc: | + Points to the path of the next element in the geometry chain. + fast_pixel_direction(NX_NUMBER): + unit: NX_LENGTH + doc: | + Values along the direction of ':'ref':'`fastest varying ` ':'index':'`pixel direction`. Each value in this + array is the size of a pixel in the units specified. Alternatively, if only one + value is given, all pixels in this direction have the same value. The direction + itself is given through the vector attribute. + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the axis for this transformation + \@offset: + type: NX_NUMBER + doc: | + A fixed offset applied before the transformation (three vector components). + \@offset_units: + type: NX_CHAR + doc: | + Units of the offset. + \@depends_on: + type: NX_CHAR + doc: | + Points to the path of the next element in the geometry chain. + slow_pixel_direction(NX_NUMBER): + unit: NX_LENGTH + doc: | + Values along the direction of ':'ref':'`slowest varying` ':'index':'`pixel direction`. Each value in this + array is the size of a pixel in the units specified. Alternatively, if only one + value is given, all pixels in this direction have the same value. The direction + itself is given through the vector attribute. + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the axis for this transformation + \@offset: + type: NX_NUMBER + doc: | + A fixed offset applied before the transformation (three vector components). + \@offset_units: + type: NX_CHAR + doc: | + Units of the offset. + \@depends_on: + type: NX_CHAR + doc: | + Points to the path of the next element in the geometry chain. + depends_on(NX_CHAR): + doc: | + Points to the start of the dependency chain for this module. + \@default: + doc: | + .. 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/nyaml/NXdisk_chopper.yaml b/base_classes/nyaml/NXdisk_chopper.yaml new file mode 100644 index 0000000000..45a786e60f --- /dev/null +++ b/base_classes/nyaml/NXdisk_chopper.yaml @@ -0,0 +1,142 @@ +category: base +doc: | + A device blocking the beam in a temporal periodic pattern. + + A disk which blocks the beam but has one or more slits to periodically + let neutrons through as the disk rotates. Often used in pairs, one + NXdisk_chopper should be defined for each disk. + + The rotation of the disk is commonly monitored by recording a timestamp for + each full rotation of disk, by having a sensor in the stationary disk housing + sensing when it is aligned with a feature (such as a magnet) on the disk. + We refer to this below as the "top-dead-center signal". + + Angles and positive rotation speeds are measured in an anticlockwise + direction when facing away from the source. + +symbols: + doc: | + This symbol will be used below to coordinate datasets with the same shape. + + n: | + Number of slits in the disk + +type: group +NXdisk_chopper(NXobject): + type: + doc: | + Type of the disk-chopper':' only one from the enumerated list (match text exactly) + enumeration: [Chopper type single, contra_rotating_pair, synchro_pair] + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Chopper rotation speed. Positive for anticlockwise rotation when + facing away from the source, negative otherwise. + slits(NX_INT): + doc: | + Number of slits + slit_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular opening + pair_separation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Disk spacing in direction of beam + slit_edges(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle of each edge of every slit from the position of the + top-dead-center timestamp sensor, anticlockwise when facing + away from the source. + The first edge must be the opening edge of a slit, thus the last edge + may have an angle greater than 360 degrees. + dimensions: + dim: [[1, 2n]] + top_dead_center(NX_NUMBER): + unit: NX_TIME + doc: | + Timestamps of the top-dead-center signal. The times are relative + to the "start" attribute and in the units specified in the "units" + attribute. Please note that absolute + timestamps under unix are relative to ``1970-01-01T00':'00':'00.0Z``. + \@start: + type: NX_DATE_TIME + beam_position(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular separation of the center of the beam and the + top-dead-center timestamp sensor, anticlockwise when facing + away from the source. + radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + Radius of the disk + slit_height(NX_FLOAT): + unit: NX_LENGTH + doc: | + Total slit height + phase(NX_FLOAT): + unit: NX_ANGLE + doc: | + Chopper phase angle + delay(NX_NUMBER): + unit: NX_TIME + doc: | + Time difference between timing system t0 and chopper driving clock signal + ratio(NX_INT): + doc: | + Pulse reduction factor of this chopper in relation to other + choppers/fastest pulse in the instrument + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Effective distance to the origin. + Note, it is recommended to use NXtransformations instead. + wavelength_range(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Low and high values of wavelength range transmitted + dimensions: + dim: [[1, 2]] + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference plane of the disk chopper includes the surface of the spinning disk which faces + the source. The reference point in the x and y axis is the point on this surface which is the + centre of the axle which the disk is spinning around. The reference plane is orthogonal to + the z axis and its position is the reference point on that axis. + + Note':' This reference point in almost all practical cases is not where the beam passes though. + + .. image':'':' disk_chopper/disk_chopper.png + ':'width':' 40% + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXentry.nxdl.xml b/base_classes/nyaml/NXentry.nxdl.xml deleted file mode 100644 index 7f6ac069a3..0000000000 --- a/base_classes/nyaml/NXentry.nxdl.xml +++ /dev/null @@ -1,270 +0,0 @@ - - - - - (**required**) :ref:`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. - - - - .. index:: plotting - - Declares which :ref:`NXdata` (or :ref:`NXsubentry`) group - contains the data to be shown by default. - It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. - The value is the name of the default :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. - - .. [#] NIAC2014 discussion summary: - https://www.nexusformat.org/2014_How_to_find_default_data.html - - - - - The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 - - - - - ISIS Muon IDF_Version - - - - - Extended title for entry - - - - - Unique identifier for the experiment, defined by the facility, possibly linked - to the proposals - - - - - Brief summary of the experiment, including key objectives. - - - - - Description of the full experiment (document in pdf, latex, ...) - - - - - User or Data Acquisition defined group of NeXus files or NXentry - - - - - Brief summary of the collection, including grouping criteria. - - - - - Unique identifier for the measurement, defined by the facility. - - - - - UUID identifier for the measurement. - - - - Version of UUID used - - - - - - Reserved for future use by NIAC. See - https://github.com/nexusformat/definitions/issues/382 - - - - - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms. - This field is provided so that :ref:`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Local NXDL schema extended from the entry specified in the ``definition`` field. - This contains any locally-defined, additional fields in the entry. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Starting time of measurement - - - - - Ending time of measurement - - - - - Duration of measurement - - - - - Time transpired actually collecting data i.e. taking out time when collection - was suspended due to e.g. temperature out of range - - - - - Such as '2007-3'. Some user facilities organize their beam time into run cycles. - - - - - Name of program used to generate this file - - - - Program version number - - - - - configuration of the program - - - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a - chopper, by the moderator or the source itself. In other words: it the distance - to the component which gives the T0 signal to the detector electronics. If - another component in the NXinstrument hierarchy provides this information, this - should be a link. - - - - - City and country where the experiment took place - - - - - Start time of experimental run that includes the current measurement, for - example a beam time. - - - - - End time of experimental run that includes the current measurement, for example - a beam time. - - - - - Name of the institution hosting the facility - - - - - Name of the experimental facility - - - - - Name of the laboratory or beamline - - - - - Notes describing entry - - - - - A small image that is representative of the entry. An example of this is a - 640x480 jpeg image automatically produced by a low resolution plot of the - NXdata. - - - - The mime type should be an ``image/*`` - - - - - - - - - - - - - - - diff --git a/base_classes/nyaml/NXentry.yaml b/base_classes/nyaml/NXentry.yaml index 4c92bc208d..e6ae50514d 100644 --- a/base_classes/nyaml/NXentry.yaml +++ b/base_classes/nyaml/NXentry.yaml @@ -1,156 +1,181 @@ -doc: | - (**required**) :ref:`NXentry` describes the measurement. - +category: base +doc: | + (**required**) ':'ref':'`NXentry` describes the measurement. + The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. + information that comprise a single measurement. It is mandatory that there is at least one group of this type in the NeXus file. -category: base -NXentry: - \@default: - doc: | - .. index:: plotting - - Declares which :ref:`NXdata` (or :ref:`NXsubentry`) group - contains the data to be shown by default. - It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. - The value is the name of the default :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. - .. [#] NIAC2014 discussion summary: - https://www.nexusformat.org/2014_How_to_find_default_data.html +type: group +NXentry(NXobject): + \@default: + doc: | + .. index':'':' find the default plottable data + .. index':'':' plotting + .. index':'':' default attribute value + + Declares which ':'ref':'`NXdata` group contains the data + to be shown by default. + It is used to resolve ambiguity when + one ':'ref':'`NXdata` group exists. + The value ':'ref':'`names ` a child group. If that group + itself has a ``default`` attribute, continue this chain until an + ':'ref':'`NXdata` group is reached. + + For more information about how NeXus identifies the default + plottable data, see the + ':'ref':'`Find Plottable Data, v3 ` + section. (NXdata): - doc: | + doc: | The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that + + .. note':'':' Before the NIAC2016 meeting [#]_, at least one + ':'ref':'`NXdata` group was required in each ':'ref':'`NXentry` group. + At the NIAC2016 meeting, it was decided to make ':'ref':'`NXdata` + an optional group in ':'ref':'`NXentry` groups for data files that do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when defining the default plot is not practical or possible from the available data. - - For example, neutron event data may not have anything that + + For example, neutron event data may not have anything that makes a useful plot without extensive processing. - + Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group + require an ':'ref':'`NXdata` group + in the ':'ref':'`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + ':'ref':'`NXdata` group is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 + + .. [#] NIAC2016':' + https':'//www.nexusformat.org/NIAC2016.html, + https':'//github.com/nexusformat/NIAC/issues/16 \@IDF_Version: - doc: "ISIS Muon IDF_Version" + doc: | + ISIS Muon IDF_Version title: - doc: "Extended title for entry" + doc: | + Extended title for entry experiment_identifier: - doc: "Unique identifier for the experiment, + doc: | + Unique identifier for the experiment, defined by the facility, - possibly linked to the proposals" + possibly linked to the proposals experiment_description: - doc: "Brief summary of the experiment, including key objectives." - experiment_documentation(NXnote): - doc: "Description of the full experiment (document in pdf, latex, ...)" + doc: | + Brief summary of the experiment, including key objectives. + (NXnote)experiment_documentation: + doc: | + Description of the full experiment (document in pdf, latex, ...) collection_identifier: - doc: "User or Data Acquisition defined group of NeXus files or NXentry" + doc: | + User or Data Acquisition defined group of NeXus files or NXentry collection_description: - doc: "Brief summary of the collection, including grouping criteria." + doc: | + Brief summary of the collection, including grouping criteria. entry_identifier: - doc: "Unique identifier for the measurement, defined by the facility." + doc: | + unique identifier for the measurement, defined by the facility. entry_identifier_uuid: - doc: "UUID identifier for the measurement." + doc: | + UUID identifier for the measurement. \@version: - doc: "Version of UUID used" + doc: | + Version of UUID used features: - doc: "Reserved for future use by NIAC. - See https://github.com/nexusformat/definitions/issues/382" + doc: | + Reserved for future use by NIAC. + + See https':'//github.com/nexusformat/definitions/issues/382 definition: - doc: | - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms. - This field is provided so that :ref:`NXentry` can be the overlay position + doc: | + (alternate use':' see same field in ':'ref':'`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms which must be + the name of the NXDL file (case sensitive without the file extension) + that the NXDL schema is defined in. + + For example the ``definition`` field for a file that conformed to the + *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. + + This field is provided so that ':'ref':'`NXentry` can be the overlay position in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + set of groups, fields, and attributes. + + *It is advised* to use ':'ref':'`NXsubentry`, instead, as the overlay position. \@version: - doc: "NXDL version number" + doc: | + NXDL version number \@URL: - doc: "URL of NXDL file" + doc: | + URL of NXDL file definition_local: - doc: "Local NXDL schema extended from the entry + deprecated: see same field in ':'ref':'`NXsubentry` for preferred use + doc: | + Local NXDL schema extended from the entry specified in the ``definition`` field. This contains any locally-defined, - additional fields in the entry." + additional fields in the entry. \@version: - doc: "NXDL version number" + doc: | + NXDL version number \@URL: - doc: "URL of NXDL file" + doc: | + URL of NXDL file start_time(NX_DATE_TIME): - doc: "Starting time of measurement" + doc: | + Starting time of measurement end_time(NX_DATE_TIME): - doc: "Ending time of measurement" + doc: | + Ending time of measurement duration(NX_INT): unit: NX_TIME - doc: "Duration of measurement" + doc: | + Duration of measurement collection_time(NX_FLOAT): unit: NX_TIME - doc: - "Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range" + doc: | + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range run_cycle: - doc: "Such as '2007-3'. Some user facilities organize their beam time into run cycles." + doc: | + Such as "2007-3". Some user facilities organize their beam time into run cycles. program_name: - doc: "Name of program used to generate this file" + doc: | + Name of program used to generate this file \@version: - doc: "Program version number" + doc: | + Program version number \@configuration: - doc: "configuration of the program" + doc: | + configuration of the program revision: - doc: - "Revision id of the file due to re-calibration, reprocessing, new analysis, - new instrument definition format, ..." + doc: | + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... \@comment: pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH - doc: - "This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component + doc: | + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words':' it the distance to the component which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link." - experiment_location(NX_CHAR): - doc: "City and country where the experiment took place" - experiment_start_date(NX_DATE_TIME): - doc: "Start time of experimental run that includes the current measurement, - for example a beam time." - experiment_end_date(NX_DATE_TIME): - doc: "End time of experimental run that includes the current measurement, - for example a beam time." - experiment_institution(NX_CHAR): - doc: "Name of the institution hosting the facility" - experiment_facility(NX_CHAR): - doc: "Name of the experimental facility" - experiment_laboratory(NX_CHAR): - doc: "Name of the laboratory or beamline" + NXinstrument hierarchy provides this information, this should be a link. notes(NXnote): - doc: "Notes describing entry" + doc: | + Notes describing entry thumbnail(NXnote): - doc: - "A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata." + doc: | + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. \@type: - doc: "The mime type should be an ``image/*``" + doc: | + The mime type should be an ``image/*`` enumeration: [image/*] (NXuser): (NXsample): diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml new file mode 100644 index 0000000000..efb083eb15 --- /dev/null +++ b/base_classes/nyaml/NXenvironment.yaml @@ -0,0 +1,44 @@ +category: base +doc: | + Parameters for controlling external conditions + +type: group +NXenvironment(NXobject): + name: + doc: | + Apparatus identification code/model number; e.g. OC100 011 + short_name: + doc: | + Alternative short name, perhaps for dashboard display like a present Seblock name + type: + doc: | + Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 + description: + doc: | + Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump + program: + doc: | + Program controlling the apparatus; e.g. LabView VI name + position(NXgeometry): + doc: | + The position and orientation of the apparatus. + Note, it is recommended to use NXtransformations instead. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + (NXtransformations): + exists: ['min', '0'] + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + (NXnote): + doc: | + Additional information, LabView logs, digital photographs, etc + (NXsensor): diff --git a/base_classes/nyaml/NXevent_data.yaml b/base_classes/nyaml/NXevent_data.yaml new file mode 100644 index 0000000000..f2d8d628fc --- /dev/null +++ b/base_classes/nyaml/NXevent_data.yaml @@ -0,0 +1,94 @@ +category: base +doc: | + NXevent_data is a special group for storing data from neutron + detectors in event mode. In this mode, the detector electronics + emits a stream of detectorID, timestamp pairs. With detectorID + describing the detector element in which the neutron was detected + and timestamp the timestamp at which the neutron event was + detected. In NeXus detectorID maps to event_id, event_time_offset + to the timestamp. + + As this kind of data is common at pulsed neutron + sources, the timestamp is almost always relative to the start of a + neutron pulse. Thus the pulse timestamp is recorded too together + with an index in the event_id, event_time_offset pair at which data for + that pulse starts. At reactor source the same pulsed data effect + may be achieved through the use of choppers or in stroboscopic + measurement setups. + + In order to make random access to timestamped data + faster there is an optional array pair of + cue_timestamp_zero and cue_index. The cue_timestamp_zero will + contain courser timestamps then in the time array, say + every five minutes. The cue_index will then contain the + index into the event_id,event_time_offset pair of arrays for that + courser cue_timestamp_zero. + +type: group +NXevent_data(NXobject): + event_time_offset(NX_NUMBER): + unit: NX_TIME_OF_FLIGHT + doc: | + A list of timestamps for each event as it comes in. + dimensions: + rank: 1 + dim: [[1, i]] + event_id(NX_INT): + unit: NX_DIMENSIONLESS + doc: | + There will be extra information in the NXdetector to convert + event_id to detector_number. + dimensions: + rank: 1 + dim: [[1, i]] + event_time_zero(NX_NUMBER): + unit: NX_TIME + doc: | + The time that each pulse started with respect to the offset + dimensions: + rank: 1 + dim: [[1, j]] + \@offset: + type: NX_DATE_TIME + doc: | + ISO8601 + event_index(NX_INT): + unit: NX_DIMENSIONLESS + doc: | + The index into the event_time_offset, event_id pair for + the pulse occurring at the matching entry in event_time_zero. + dimensions: + rank: 1 + dim: [[1, j]] + pulse_height(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + If voltages from the ends of the detector are read out this + is where they go. This list is for all events with information + to attach to a particular pulse height. The information to + attach to a particular pulse is located in events_per_pulse. + dimensions: + rank: 2 + dim: [[1, i], [2, k]] + cue_timestamp_zero(NX_DATE_TIME): + unit: NX_TIME + doc: | + Timestamps matching the corresponding cue_index into the + event_id, event_time_offset pair. + \@start: + type: NX_DATE_TIME + cue_index(NX_INT): + doc: | + Index into the event_id, event_time_offset pair matching the corresponding + cue_timestamp. + \@default: + doc: | + .. 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/nyaml/NXfermi_chopper.yaml b/base_classes/nyaml/NXfermi_chopper.yaml new file mode 100644 index 0000000000..4665e5a978 --- /dev/null +++ b/base_classes/nyaml/NXfermi_chopper.yaml @@ -0,0 +1,91 @@ +category: base +doc: | + A Fermi chopper, possibly with curved slits. + +type: group +NXfermi_chopper(NXobject): + type: + doc: | + Fermi chopper type + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + chopper rotation speed + radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + radius of chopper + slit(NX_FLOAT): + unit: NX_LENGTH + doc: | + width of an individual slit + r_slit(NX_FLOAT): + unit: NX_LENGTH + doc: | + radius of curvature of slits + number(NX_INT): + unit: NX_UNITLESS + doc: | + number of slits + height(NX_FLOAT): + unit: NX_LENGTH + doc: | + input beam height + width(NX_FLOAT): + unit: NX_LENGTH + doc: | + input beam width + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + distance. Note, it is recommended to use NXtransformations instead. + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Wavelength transmitted by chopper + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + energy selected + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead + doc: | + geometry of the fermi chopper + absorbing_material: + doc: | + absorbing material + transmitting_material: + doc: | + transmitting material + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a fermi chopper. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXfilter.yaml b/base_classes/nyaml/NXfilter.yaml new file mode 100644 index 0000000000..e887b13e2f --- /dev/null +++ b/base_classes/nyaml/NXfilter.yaml @@ -0,0 +1,169 @@ +category: base +doc: | + For band pass beam filters. + + If uncertain whether to use ':'ref':'`NXfilter` (band-pass filter) + or ':'ref':'`NXattenuator` (reduces beam intensity), then use + ':'ref':'`NXattenuator`. + +type: group +NXfilter(NXobject): + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to filter the beamstop and NXoff_geometry to describe its shape instead + doc: | + Geometry of the filter + description: + doc: | + Composition of the filter. Chemical formula can be specified separately. + + This field was changed (2010-11-17) from an enumeration to + a string since common usage showed a wider variety of use + than a simple list. These are the items in the list at + the time of the change':' Beryllium | Pyrolytic Graphite | + Graphite | Sapphire | Silicon | Supermirror. + status: + doc: | + position with respect to in or out of the beam (choice of only "in" or "out") + enumeration: + in: + doc: | + in the beam + out: + doc: | + out of the beam + transmission(NXdata): + doc: | + Wavelength transmission profile of filter + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + average/nominal filter temperature + temperature_log(NXlog): + doc: | + Linked temperature_log for the filter + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the filter + density(NX_NUMBER): + unit: NX_MASS_DENSITY + doc: | + mass density of the filter + chemical_formula: + doc: | + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard':' + + * 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. + + * This is the *Hill* system used by Chemical Abstracts. + sensor_type(NXsensor): + doc: | + Sensor(s)used to monitor the filter temperature + unit_cell_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell lattice parameter':' length of side a + unit_cell_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell lattice parameter':' length of side b + unit_cell_c(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell lattice parameter':' length of side c + unit_cell_alpha(NX_FLOAT): + unit: NX_ANGLE + doc: | + Unit cell lattice parameter':' angle alpha + unit_cell_beta(NX_FLOAT): + unit: NX_ANGLE + doc: | + Unit cell lattice parameter':' angle beta + unit_cell_gamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Unit cell lattice parameter':' angle gamma + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Unit cell + dimensions: + rank: 1 + dim: [[1, n_comp]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal filter using Busing-Levy convention':' + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + m_value(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + m value of supermirror filter + substrate_material: + doc: | + substrate material of supermirror filter + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + substrate thickness of supermirror filter + coating_material: + doc: | + coating material of supermirror filter + substrate_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + substrate roughness (RMS) of supermirror filter + coating_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + coating roughness (RMS) of supermirror filter + dimensions: + rank: 1 + dim: [[1, nsurf]] + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a filter. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXflipper.yaml b/base_classes/nyaml/NXflipper.yaml new file mode 100644 index 0000000000..70a4416bcc --- /dev/null +++ b/base_classes/nyaml/NXflipper.yaml @@ -0,0 +1,64 @@ +category: base +doc: | + A spin flipper. + +type: group +NXflipper(NXobject): + type: + enumeration: [coil, current-sheet] + flip_turns(NX_FLOAT): + unit: NX_PER_LENGTH + doc: | + Linear density of turns (such as number of turns/cm) in flipping field coils + comp_turns(NX_FLOAT): + unit: NX_PER_LENGTH + doc: | + Linear density of turns (such as number of turns/cm) in compensating field coils + guide_turns(NX_FLOAT): + unit: NX_PER_LENGTH + doc: | + Linear density of turns (such as number of turns/cm) in guide field coils + flip_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Flipping field coil current in "on" state" + comp_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Compensating field coil current in "on" state" + guide_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Guide field coil current in "on" state + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + thickness along path of neutron travel + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a spin flipper. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXfresnel_zone_plate.yaml b/base_classes/nyaml/NXfresnel_zone_plate.yaml new file mode 100644 index 0000000000..d227bc83db --- /dev/null +++ b/base_classes/nyaml/NXfresnel_zone_plate.yaml @@ -0,0 +1,72 @@ +category: base +doc: | + A fresnel zone plate + +type: group +NXfresnel_zone_plate(NXobject): + focus_parameters(NX_FLOAT): + doc: | + list of polynomial coefficients describing the focal length of the zone plate, in increasing powers of photon energy, + that describes the focal length of the zone plate (in microns) at an X-ray photon energy (in electron volts). + dimensions: + rank: 1 + dim: [] + outer_diameter(NX_FLOAT): + unit: NX_LENGTH + outermost_zone_width(NX_FLOAT): + unit: NX_LENGTH + central_stop_diameter(NX_FLOAT): + unit: NX_LENGTH + fabrication: + doc: | + how the zone plate was manufactured + enumeration: [etched, plated, zone doubled, other] + zone_height(NX_FLOAT): + unit: NX_LENGTH + zone_material: + doc: | + Material of the zones themselves + zone_support_material: + doc: | + Material present between the zones. This is usually only present for the "zone doubled" fabrication process + central_stop_material: + central_stop_thickness(NX_FLOAT): + unit: NX_LENGTH + mask_thickness(NX_FLOAT): + unit: NX_LENGTH + mask_material: + doc: | + If no mask is present, set mask_thickness to 0 and omit the mask_material field + support_membrane_material: + support_membrane_thickness(NX_FLOAT): + unit: NX_LENGTH + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a fresnel zone plate. + (NXtransformations): + doc: | + "Engineering" position of the fresnel zone plate + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXgeometry.yaml b/base_classes/nyaml/NXgeometry.yaml new file mode 100644 index 0000000000..f22aa83cee --- /dev/null +++ b/base_classes/nyaml/NXgeometry.yaml @@ -0,0 +1,46 @@ +category: base +doc: | + legacy class - recommend to use ':'ref':'`NXtransformations` now + + It is recommended that instances of ':'ref':'`NXgeometry` be converted to + use ':'ref':'`NXtransformations`. + + This is the description for a general position of a component. + It is recommended to name an instance of ':'ref':'`NXgeometry` as "geometry" + to aid in the use of the definition in simulation codes such as McStas. + Also, in HDF, linked items must share the same name. + However, it might not be possible or practical in all situations. + +type: group +deprecated: as decided at 2014 NIAC meeting, convert to use :ref:`NXtransformations` +NXgeometry(NXobject): + (NXshape): + doc: | + shape/size information of component + (NXtranslation): + doc: | + translation of component + (NXorientation): + doc: | + orientation of component + description: + doc: | + Optional description/label. Probably only present if we are + an additional reference point for components rather than the + location of a real component. + component_index(NX_INT): + doc: | + Position of the component along the beam path. The sample is at 0, components upstream + have negative component_index, components downstream have positive + component_index. + \@default: + doc: | + .. 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/nyaml/NXgrating.yaml b/base_classes/nyaml/NXgrating.yaml new file mode 100644 index 0000000000..d9a59f03f4 --- /dev/null +++ b/base_classes/nyaml/NXgrating.yaml @@ -0,0 +1,86 @@ +category: base +doc: | + A diffraction grating, as could be used in a soft X-ray monochromator + +type: group +NXgrating(NXobject): + angles(NX_FLOAT): + unit: NX_ANGLE + doc: | + Blaze or trapezoidal angles, with the angle of the upstream facing edge listed first. Blazed gratings can be identified by the low value of the first-listed angle. + dimensions: + rank: 1 + dim: [[1, 2]] + period(NX_FLOAT): + unit: NX_LENGTH + doc: | + List of polynomial coefficients describing the spatial separation of lines/grooves as a function of position along the grating, in increasing powers of position. Gratings which do not have variable line spacing will only have a single coefficient (constant). + dimensions: + rank: 1 + dim: [] + duty_cycle(NX_FLOAT): + unit: NX_UNITLESS + depth(NX_FLOAT): + unit: NX_LENGTH + diffraction_order(NX_INT): + unit: NX_UNITLESS + deflection_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle between the incident beam and the utilised outgoing beam. + interior_atmosphere: + enumeration: [vacuum, helium, argon] + substrate_material: + doc: | + substrate_density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + coating_material: + substrate_roughness(NX_FLOAT): + unit: NX_LENGTH + coating_roughness(NX_FLOAT): + unit: NX_LENGTH + layer_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + An array describing the thickness of each layer + (NXshape)shape: + deprecated: Use NXoff_geometry to describe the shape of grating + doc: | + A NXshape group describing the shape of the mirror + figure_data(NXdata): + doc: | + Numerical description of the surface figure of the mirror. + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a bending grating. + (NXtransformations): + doc: | + "Engineering" position of the grating + Transformations used by this component to define its position and orientation. diff --git a/base_classes/nyaml/NXguide.yaml b/base_classes/nyaml/NXguide.yaml new file mode 100644 index 0000000000..bd12a29c7c --- /dev/null +++ b/base_classes/nyaml/NXguide.yaml @@ -0,0 +1,177 @@ +category: base +doc: | + A neutron optical element to direct the path of the beam. + + ':'ref':'`NXguide` is used by neutron instruments to describe + a guide consists of several mirrors building a shape through which + neutrons can be guided or directed. The simplest such form is box shaped + although elliptical guides are gaining in popularity. + The individual parts of a guide usually have common characteristics + but there are cases where they are different. + For example, a neutron guide might consist of 2 or 4 coated walls or + a supermirror bender with multiple, coated vanes. + + To describe polarizing supermirrors such as used in neutron reflection, + it may be necessary to revise this definition of ':'ref':'`NXguide` + to include ':'ref':'`NXpolarizer` and/or ':'ref':'`NXmirror`. + + When even greater complexity exists in the definition of what + constitutes a *guide*, it has been suggested that ':'ref':'`NXguide` + be redefined as a ':'ref':'`NXcollection` of ':'ref':'`NXmirror` each + having their own ':'ref':'`NXgeometry` describing their location(s). + + For the more general case when describing mirrors, consider using + ':'ref':'`NXmirror`. + + NOTE':' The NeXus International Advisory Committee welcomes + comments for revision and improvement of + this definition of ':'ref':'`NXguide`. + +symbols: + nsurf: | + number of reflecting surfaces + + nwl: | + number of wavelengths + +type: group +NXguide(NXobject): + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the guid and NXoff_geometry to describe its shape instead + doc: | + TODO':' Explain what this NXgeometry group means. What is intended here? + description: + doc: | + A description of this particular instance of ``NXguide``. + incident_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + TODO':' documentation needed + (NXdata)reflectivity: + doc: | + Reflectivity as function of reflecting surface and wavelength + \@signal: + enumeration: [data] + \@axes: + enumeration: [surface wavelength] + \@surface_indices: + enumeration: [0] + \@wavelength_indices: + enumeration: [1] + data(NX_NUMBER): + doc: | + reflectivity of each surface as a function of wavelength + dimensions: + rank: 2 + dim: [[1, nsurf], [2, nwl]] + surface(NX_NUMBER): + unit: NX_ANY + doc: | + List of surfaces. Probably best to use index + numbers but the specification is very loose. + dimensions: + rank: 1 + dim: [[1, nsurf]] + wavelength(NX_NUMBER): + unit: NX_WAVELENGTH + doc: | + wavelengths at which reflectivity was measured + dimensions: + rank: 1 + dim: [[1, nwl]] + bend_angle_x(NX_FLOAT): + unit: NX_ANGLE + doc: | + TODO':' documentation needed + bend_angle_y(NX_FLOAT): + unit: NX_ANGLE + doc: | + TODO':' documentation needed + interior_atmosphere: + doc: | + enumeration: [vacuum, helium, argon] + external_material: + doc: | + external material outside substrate + m_value(NX_FLOAT): + doc: | + The ``m`` value for a supermirror, which defines the supermirror + regime in multiples of the critical angle of Nickel. + dimensions: + rank: 1 + dim: [[1, nsurf]] + substrate_material(NX_FLOAT): + doc: | + TODO':' documentation needed + dimensions: + rank: 1 + dim: [[1, nsurf]] + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + TODO':' documentation needed + dimensions: + rank: 1 + dim: [[1, nsurf]] + coating_material(NX_FLOAT): + doc: | + TODO':' documentation needed + dimensions: + rank: 1 + dim: [[1, nsurf]] + substrate_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + TODO':' documentation needed + dimensions: + rank: 1 + dim: [[1, nsurf]] + coating_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + TODO':' documentation needed + dimensions: + rank: 1 + dim: [[1, nsurf]] + number_sections(NX_INT): + unit: NX_UNITLESS + doc: | + number of substrate sections (also called ``nsurf`` as an + index in the ``NXguide`` specification) + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The entry opening of the guide lies on the reference plane. The center of the opening on that plane is + the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the + reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends + in the positive direction of the z axis. + + .. image':'':' guide/guide.png + ':'width':' 40% + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXinsertion_device.yaml b/base_classes/nyaml/NXinsertion_device.yaml new file mode 100644 index 0000000000..7e8a0439f8 --- /dev/null +++ b/base_classes/nyaml/NXinsertion_device.yaml @@ -0,0 +1,87 @@ +category: base +doc: | + An insertion device, as used in a synchrotron light source. + +type: group +NXinsertion_device(NXobject): + type: + enumeration: [undulator, wiggler] + gap(NX_FLOAT): + unit: NX_LENGTH + doc: | + separation between opposing pairs of magnetic poles + taper(NX_FLOAT): + unit: NX_ANGLE + doc: | + angular of gap difference between upstream and downstream ends of the insertion device + phase(NX_FLOAT): + unit: NX_ANGLE + poles(NX_INT): + unit: NX_UNITLESS + doc: | + number of poles + magnetic_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + k(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + beam displacement parameter + length(NX_FLOAT): + unit: NX_LENGTH + doc: | + length of insertion device + power(NX_FLOAT): + unit: NX_POWER + doc: | + total power delivered by insertion device + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + energy of peak intensity in output spectrum + bandwidth(NX_FLOAT): + unit: NX_ENERGY + doc: | + bandwidth of peak energy + harmonic(NX_INT): + unit: NX_UNITLESS + doc: | + harmonic number of peak + (NXdata)spectrum: + doc: | + spectrum of insertion device + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the device and NXoff_geometry to describe its shape instead + doc: | + "Engineering" position of insertion device + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a insertion device. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXinstrument.nxdl.xml b/base_classes/nyaml/NXinstrument.nxdl.xml deleted file mode 100644 index 17b41d660d..0000000000 --- a/base_classes/nyaml/NXinstrument.nxdl.xml +++ /dev/null @@ -1,82 +0,0 @@ - - - - - Collection of the components of the instrument or beamline. Template of - instrument descriptions comprising various beamline components. Each component - will also be a NeXus group defined by its distance from the sample. Negative - distances represent beamline components that are before the sample while - positive distances represent components that are after the sample. This device - allows the unique identification of beamline components in a way that is valid - for both reactor and pulsed instrumentation. - - - - Name of instrument - - - - short name for instrument, perhaps the acronym - - - - - - Energy resolution of the experiment (FWHM or gaussian broadening) - - - - - Momentum resolution of the experiment (FWHM) - - - - - Angular resolution of the experiment (FWHM) - - - - - Spatial resolution of the experiment (Airy disk radius) - - - - - Temporal resolution of the experiment (FWHM) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .. 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/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml index 91e292ee8f..b9912d9b54 100644 --- a/base_classes/nyaml/NXinstrument.yaml +++ b/base_classes/nyaml/NXinstrument.yaml @@ -1,31 +1,22 @@ -doc: "Collection of the components of the instrument or beamline. +category: base +doc: | + Collection of the components of the instrument or beamline. + Template of instrument descriptions comprising various beamline components. Each component will also be a NeXus group defined by its distance from the sample. Negative distances represent beamline components that are before the sample while positive distances represent components that are after the sample. This device allows the unique identification of beamline components in a way - that is valid for both reactor and pulsed instrumentation." -category: base -NXinstrument: + that is valid for both reactor and pulsed instrumentation. + +type: group +NXinstrument(NXobject): name: - doc: "Name of instrument" + doc: | + Name of instrument \@short_name: - doc: "short name for instrument, perhaps the acronym" - energy_resolution(NX_FLOAT): - doc: "Energy resolution of the experiment (FWHM or gaussian broadening)" - unit: NX_ENERGY - momentum_resolution(NX_FLOAT): - doc: "Momentum resolution of the experiment (FWHM)" - unit: NX_WAVENUMBER - angular_resolution(NX_FLOAT): - doc: "Angular resolution of the experiment (FWHM)" - unit: NX_ANGLE - spatial_resolution(NX_FLOAT): - doc: "Spatial resolution of the experiment (Airy disk radius)" - unit: NX_LENGTH - temporal_resolution(NX_FLOAT): - doc: "Temporal resolution of the experiment (FWHM)" - unit: NX_TIME + doc: | + short name for instrument, perhaps the acronym (NXaperture): (NXattenuator): (NXbeam): @@ -50,16 +41,18 @@ NXinstrument: (NXpolarizer): (NXpositioner): (NXsource): - DIFFRACTOMETER(NXtransformations): + (NXtransformations)DIFFRACTOMETER: (NXvelocity_selector): (NXxraylens): + (NXenvironment): \@default: - doc: ".. index:: plotting - + doc: | + .. index':'':' plotting + Declares which child group contains a path leading - to a :ref:`NXdata` group. - + 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." + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/nyaml/NXlog.yaml b/base_classes/nyaml/NXlog.yaml new file mode 100644 index 0000000000..6848474dd7 --- /dev/null +++ b/base_classes/nyaml/NXlog.yaml @@ -0,0 +1,111 @@ +category: base +doc: | + Information recorded as a function of time. + + Description of information that is recorded against + time. There are two common use cases for this':' + + - When logging data such as temperature during a run + - When data is taken in streaming mode data acquisition, + i.e. just timestamp, value pairs are stored and + correlated later in data reduction with other data, + + + In both cases, NXlog contains + the logged or streamed values and the times at which they were measured as elapsed time since a starting + time recorded in ISO8601 format. The time units are + specified in the units attribute. An optional scaling attribute + can be used to accomodate non standard clocks. + + + This method of storing logged data helps to distinguish + instances in which a variable is a dimension scale of the data, in which case it is stored + in an ':'ref':'`NXdata` group, and instances in which it is logged during the + run, when it should be stored in an ':'ref':'`NXlog` group. + + In order to make random access to timestamped data faster there is an optional array pair of + ``cue_timestamp_zero`` and ``cue_index``. The ``cue_timestamp_zero`` will + contain coarser timestamps than in the time array, say + every five minutes. The ``cue_index`` will then contain the + index into the time,value pair of arrays for that + coarser ``cue_timestamp_zero``. + +type: group +NXlog(NXobject): + time(NX_NUMBER): + unit: NX_TIME + doc: | + Time of logged entry. The times are relative to the "start" attribute + and in the units specified in the "units" + attribute. Please note that absolute + timestamps under unix are relative to ``1970-01-01T00':'00':'00.0Z``. + + The scaling_factor, when present, has to be applied to the time values in order + to arrive at the units specified in the units attribute. The scaling_factor allows + for arbitrary time units such as ticks of some hardware clock. + \@start: + type: NX_DATE_TIME + \@scaling_factor: + type: NX_NUMBER + value(NX_NUMBER): + unit: NX_ANY + doc: | + Array of logged value, such as temperature. If this is + a single value the dimensionality is + nEntries. However, NXlog can also be used to store + multi dimensional time stamped data such as images. In + this example the dimensionality of values would be value[nEntries,xdim,ydim]. + raw_value(NX_NUMBER): + unit: NX_ANY + doc: | + Array of raw information, such as thermocouple voltage + description: + doc: | + Description of logged value + average_value(NX_FLOAT): + unit: NX_ANY + average_value_error(NX_FLOAT): + unit: NX_ANY + deprecated: see':' https':'//github.com/nexusformat/definitions/issues/639 + doc: | + estimated uncertainty (often used':' standard deviation) of average_value + average_value_errors(NX_FLOAT): + unit: NX_ANY + doc: | + estimated uncertainty (often used':' standard deviation) of average_value + minimum_value(NX_FLOAT): + unit: NX_ANY + maximum_value(NX_FLOAT): + unit: NX_ANY + duration(NX_FLOAT): + unit: NX_ANY + doc: | + Total time log was taken + cue_timestamp_zero(NX_NUMBER): + unit: NX_TIME + doc: | + Timestamps matching the corresponding cue_index into the + time, value pair. + \@start: + type: NX_DATE_TIME + doc: | + If missing start is assumed to be the same as for "time". + \@scaling_factor: + type: NX_NUMBER + doc: | + If missing start is assumed to be the same as for "time". + cue_index(NX_INT): + doc: | + Index into the time, value pair matching the corresponding + cue_timestamp_zero. + \@default: + doc: | + .. 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/nyaml/NXmirror.yaml b/base_classes/nyaml/NXmirror.yaml new file mode 100644 index 0000000000..1901e760c8 --- /dev/null +++ b/base_classes/nyaml/NXmirror.yaml @@ -0,0 +1,115 @@ +category: base +doc: | + A beamline mirror or supermirror. + +type: group +NXmirror(NXobject): + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the mirror and NXoff_geometry to describe its shape instead + doc: | + type: + enumeration: + single: + doc: | + mirror with a single material as a reflecting surface + multi: + doc: | + mirror with stacked, multiple layers as a reflecting surface + description: + doc: | + description of this mirror + incident_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + (NXdata)reflectivity: + doc: | + Reflectivity as function of wavelength + bend_angle_x(NX_FLOAT): + unit: NX_ANGLE + doc: | + bend_angle_y(NX_FLOAT): + unit: NX_ANGLE + doc: | + interior_atmosphere: + enumeration: [vacuum, helium, argon] + external_material: + doc: | + external material outside substrate + m_value(NX_FLOAT): + unit: NX_UNITLESS + doc: | + The m value for a supermirror, which defines the supermirror + regime in multiples of the critical angle of Nickel. + substrate_material: + doc: | + substrate_density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + coating_material: + doc: | + substrate_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + coating_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + even_layer_material: + doc: | + even_layer_density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + odd_layer_material: + doc: | + odd_layer_density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + layer_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + An array describing the thickness of each layer + (NXshape)shape: + deprecated: Use NXoff_geometry instead + doc: | + A NXshape group describing the shape of the mirror + figure_data(NXdata): + doc: | + Numerical description of the surface figure of the mirror. + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + Given a flat mirror, the reference plane is the plane which contains the "entry" surface of the mirror. The reference + point of the mirror in the x and y axis is the centre of the mirror on that plane. The reference plane is orthogonal + to the z axis and the location of this plane is the reference point on the z axis. The mirror faces negative z values. + + .. image':'':' mirror/mirror.png + ':'width':' 40% + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXmoderator.yaml b/base_classes/nyaml/NXmoderator.yaml new file mode 100644 index 0000000000..d58bfc5386 --- /dev/null +++ b/base_classes/nyaml/NXmoderator.yaml @@ -0,0 +1,72 @@ +category: base +doc: | + A neutron moderator + +type: group +NXmoderator(NXobject): + (NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the moderator and NXoff_geometry to describe its shape instead + doc: | + "Engineering" position of moderator + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Effective distance as seen by measuring radiation. + Note, it is recommended to use NXtransformations instead. + type: + enumeration: [H20, D20, Liquid H2, Liquid CH4, Liquid D2, Solid D2, C, Solid CH4, Solid H2] + poison_depth(NX_FLOAT): + unit: NX_LENGTH + coupled(NX_BOOLEAN): + doc: | + whether the moderator is coupled + coupling_material: + doc: | + The material used for coupling. Usually Cd. + poison_material: + enumeration: [Gd, Cd] + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + average/nominal moderator temperature + (NXlog)temperature_log: + doc: | + log file of moderator temperature + (NXdata)pulse_shape: + doc: | + moderator pulse shape + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the moderator + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the moderator is its center in the x and y axis. The reference point on the z axis is the + surface of the moderator pointing towards the source (the negative part of the z axis). + + .. image':'':' moderator/moderator.png + ':'width':' 40% + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXmonitor.yaml b/base_classes/nyaml/NXmonitor.yaml new file mode 100644 index 0000000000..ca625ffa6a --- /dev/null +++ b/base_classes/nyaml/NXmonitor.yaml @@ -0,0 +1,130 @@ +category: base +doc: | + A monitor of incident beam data. + + It is similar to the ':'ref':'`NXdata` groups containing + monitor data and its associated dimension scale, e.g. time_of_flight or + wavelength in pulsed neutron instruments. However, it may also include + integrals, or scalar monitor counts, which are often used in both in both + pulsed and steady-state instrumentation. + +type: group +NXmonitor(NXobject): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + start_time(NX_DATE_TIME): + doc: | + Starting time of measurement + end_time(NX_DATE_TIME): + doc: | + Ending time of measurement + preset(NX_NUMBER): + unit: NX_ANY + doc: | + preset value for time or monitor + distance(NX_FLOAT): + unit: NX_LENGTH + deprecated: Use transformations/distance instead + doc: | + Distance of monitor from sample + range(NX_FLOAT): + unit: NX_ANY + doc: | + Range (X-axis, Time-of-flight, etc.) over which the integral was calculated + dimensions: + dim: [[1, 2]] + nominal(NX_NUMBER): + unit: NX_ANY + doc: | + Nominal reading to be used for normalisation purposes. + integral(NX_NUMBER): + unit: NX_ANY + doc: | + Total integral monitor counts + integral_log(NXlog): + doc: | + Time variation of monitor counts + type: + enumeration: [Fission Chamber, Scintillator] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: | + Time-of-flight + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['efficiency'] + efficiency(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Monitor efficiency + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['i'] + data(NX_NUMBER): + unit: NX_ANY + doc: | + Monitor data + dimensions: + rank: dataRank + doc: | + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + At least one ``dim`` must have length ``n``. + dim: [] + sampled_fraction(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Proportion of incident beam sampled by the monitor (0 - - - - Document an event of data processing, reconstruction, or analysis for this data. - - - - Name of the program used - - - - - Sequence index of processing, for determining the order of multiple - **NXprocess** steps. Starts with 1. - - - - - Version of the program used - - - - - Date and time of processing. - - - - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - - - - Notes contain information about how the data was processed or anything about the - data provenance. The contents of the note can be anything that the processing - code can understand, or simple text. The name will be numbered to allow for - ordering of steps. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - diff --git a/base_classes/nyaml/NXprocess.yaml b/base_classes/nyaml/NXprocess.yaml index 3ddceebbc3..6d7fc3a7eb 100644 --- a/base_classes/nyaml/NXprocess.yaml +++ b/base_classes/nyaml/NXprocess.yaml @@ -1,37 +1,39 @@ -doc: "Document an event of data processing, reconstruction, or analysis for this data." category: base -NXprocess: +doc: | + Document an event of data processing, reconstruction, or analysis for this data. + +type: group +NXprocess(NXobject): program(NX_CHAR): - doc: "Name of the program used" + doc: | + Name of the program used sequence_index(NX_POSINT): - doc: "Sequence index of processing, + doc: | + Sequence index of processing, for determining the order of multiple **NXprocess** steps. - Starts with 1." + Starts with 1. version(NX_CHAR): - doc: "Version of the program used" + doc: | + Version of the program used date(NX_DATE_TIME): - doc: "Date and time of processing." - (NXregistration): - doc: "Describes the operations of image registration" - (NXdistortion): - doc: "Describes the operations of image distortion correction" - (NXcalibration): - doc: "Describes the operations of calibration procedures, - e.g. axis calibrations." + doc: | + Date and time of processing. (NXnote): - doc: "Notes contain information about how the data was processed + doc: | + The note will contain information about how the data was processed or anything about the data provenance. The contents of the note can be anything that the processing code can understand, or simple text. - The name will be numbered to allow for ordering of steps." + + The name will be numbered to allow for ordering of steps. \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - + doc: | + .. 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/base_classes/nyaml/NXreflections.yaml b/base_classes/nyaml/NXreflections.yaml new file mode 100644 index 0000000000..bf88aa6200 --- /dev/null +++ b/base_classes/nyaml/NXreflections.yaml @@ -0,0 +1,605 @@ +category: base +doc: | + Reflection data from diffraction experiments + +symbols: + n: | + number of reflections + + m: | + number of experiments + +type: group +NXreflections(NXobject): + experiments: + exists: ['min', '1'] + doc: | + The experiments from which the reflection data derives + dimensions: + rank: 1 + dim: [[1, m]] + h(NX_NUMBER): + exists: ['min', '1'] + doc: | + The h component of the miller index + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + k(NX_NUMBER): + exists: ['min', '1'] + doc: | + The k component of the miller index + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + l(NX_NUMBER): + exists: ['min', '1'] + doc: | + The l component of the miller index + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + id(NX_INT): + exists: ['min', '1'] + doc: | + The id of the experiment which resulted in the reflection. If the value + is greater than 0, the experiments must link to a multi-experiment NXmx + group + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + reflection_id(NX_INT): + exists: ['min', '1'] + doc: | + The id of the reflection. Multiple partials from the same reflection + should all have the same id + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + entering(NX_BOOLEAN): + exists: ['min', '1'] + doc: | + Is the reflection entering or exiting the Ewald sphere + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + det_module(NX_INT): + exists: ['min', '1'] + doc: | + The detector module on which the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + flags(NX_INT): + exists: ['min', '1'] + doc: | + Status flags describing the reflection. + + This is a bit mask. The bits in the mask follow the convention + used by DIALS, and have the following names':' + + === ========================================== + bit name + === ========================================== + 0 ``predicted`` + 1 ``observed`` + 2 ``indexed`` + 3 ``used_in_refinement`` + 4 ``strong`` + 5 ``reference_spot`` + 6 ``dont_integrate`` + 7 ``integrated_sum`` + 8 ``integrated_prf`` + 9 ``integrated`` + 10 ``overloaded`` + 11 ``overlapped`` + 12 ``overlapped_fg`` + 13 ``in_powder_ring`` + 14 ``foreground_includes_bad_pixels`` + 15 ``background_includes_bad_pixels`` + 16 ``includes_bad_pixels`` + 17 ``bad_shoebox`` + 18 ``bad_spot`` + 19 ``used_in_modelling`` + 20 ``centroid_outlier`` + 21 ``failed_during_background_modelling`` + 22 ``failed_during_summation`` + 23 ``failed_during_profile_fitting`` + 24 ``bad_reference`` + === ========================================== + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + d(NX_FLOAT): + exists: ['min', '1'] + doc: | + The resolution of the reflection + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + partiality(NX_FLOAT): + exists: ['min', '1'] + doc: | + The partiality of the reflection. + Dividing by this number will inflate the measured + intensity to the full reflection equivalent. + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_frame(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The frame on which the bragg peak of the reflection is predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_x(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The x position at which the bragg peak of the reflection + is predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_y(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The y position at which the bragg peak of the reflection + is predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_phi(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '1'] + doc: | + The phi angle at which the bragg peak of the reflection is predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_px_x(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The x pixel position at which the bragg peak of the reflection is + predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_px_y(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The y pixel position at which the bragg peak of the reflection is + predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_frame(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The estimate of the frame at which the central impact of the + reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_frame_var(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The variance on the estimate of the frame at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_frame_errors(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the frame at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_x(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The estimate of the pixel x position at which the central impact of + the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_x_var(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The variance on the estimate of the pixel x position at which the + central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_x_errors(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the pixel x position at which the + central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_y(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The estimate of the pixel y position at which the central impact of + the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_y_var(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The variance on the estimate of the pixel y position at which the + central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_y_errors(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the pixel y position at which the + central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_phi(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '1'] + doc: | + The estimate of the phi angle at which the central impact of the + reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_phi_var(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '1'] + doc: | + The variance on the estimate of the phi angle at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_phi_errors(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the phi angle at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_x(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The estimate of the x position at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_x_var(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The variance on the estimate of the x position at which + the central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_x_errors(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the x position at which + the central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_y(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The estimate of the y position at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_y_var(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The variance on the estimate of the y position at which + the central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_y_errors(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the y position at which + the central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + bounding_box(NX_INT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The bounding box around the recorded recorded reflection. + Should be an integer array of length 6, where the 6 values + are pixel positions or frame numbers, as follows':' + + ===== =========================== + index meaning + ===== =========================== + 0 The lower pixel x position + 1 The upper pixel x position + 2 The lower pixel y position + 3 The upper pixel y position + 4 The lower frame number + 5 The upper frame number + ===== =========================== + dimensions: + rank: 2 + dim: [[1, n], [2, 6]] + \@description: + doc: | + Describes the dataset + background_mean(NX_FLOAT): + exists: ['min', '1'] + doc: | + The mean background under the reflection peak + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_prf(NX_FLOAT): + exists: ['min', '0'] + doc: | + The estimate of the reflection intensity by profile fitting + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_prf_var(NX_FLOAT): + exists: ['min', '0'] + doc: | + The variance on the estimate of the reflection intensity by profile + fitting + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_prf_errors(NX_FLOAT): + exists: ['min', '0'] + doc: | + The standard deviation of the estimate of the reflection intensity by profile + fitting + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_sum(NX_FLOAT): + exists: ['min', '1'] + doc: | + The estimate of the reflection intensity by summation + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_sum_var(NX_FLOAT): + exists: ['min', '1'] + doc: | + The variance on the estimate of the reflection intensity by + summation + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_sum_errors(NX_FLOAT): + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the reflection intensity by + summation + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + lp(NX_FLOAT): + exists: ['min', '1'] + doc: | + The LP correction factor to be applied to the reflection intensities + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + prf_cc(NX_FLOAT): + exists: ['min', '0'] + doc: | + The correlation of the reflection profile with the reference profile + used in profile fitting + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + overlaps(NX_INT): + exists: ['min', '0'] + doc: | + An adjacency list specifying the spatial overlaps of reflections. The + adjacency list is specified using an array data type where the elements + of the array are the indices of the adjacent overlapped reflection + \@description: + doc: | + Describes the dataset + polar_angle(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '0'] + doc: | + Polar angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '0'] + doc: | + Azimuthal angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + \@default: + doc: | + .. 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/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml new file mode 100644 index 0000000000..4e5af85fd6 --- /dev/null +++ b/base_classes/nyaml/NXroot.yaml @@ -0,0 +1,73 @@ +category: base +doc: | + Definition of the root NeXus group. + +type: group +NXroot(NXobject): + \@NX_class: + doc: | + The root of any NeXus data file is an ``NXroot`` class + (no other choice is allowed for a valid NeXus data file). + This attribute cements that definition. + enumeration: [NXroot] + \@file_time: + type: NX_DATE_TIME + doc: | + Date and time file was originally created + \@file_name: + doc: | + File name of original NeXus file + \@file_update_time: + type: NX_DATE_TIME + doc: | + Date and time of last file change at close + \@NeXus_version: + doc: | + Version of NeXus API used in writing the file. + + Only used when the NAPI has written the file. + Note that this is different from the version of the + base class or application definition version number. + \@HDF_version: + doc: | + Version of HDF (version 4) library used in writing the file + \@HDF5_Version: + doc: | + Version of HDF5 library used in writing the file. + + Note this attribute is spelled with uppercase "V", + different than other version attributes. + \@XML_version: + doc: | + Version of XML support library used in writing the XML file + \@h5py_version: + doc: | + Version of h5py Python package used in writing the file + \@creator: + doc: | + facility or program where file originated + \@creator_version: + doc: | + Version of facility or program used in writing the file + (NXentry): + exists: ['min', '1'] + doc: | + entries + \@default: + doc: | + .. index':'':' find the default plottable data + .. index':'':' plotting + .. index':'':' default attribute value + + Declares which ':'ref':'`NXentry` group contains + the data to be shown by default. + It is used to resolve ambiguity when + more than one ':'ref':'`NXentry` group exists. + The value ':'ref':'`names ` the default ':'ref':'`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus 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/nyaml/NXsample.nxdl.xml b/base_classes/nyaml/NXsample.nxdl.xml deleted file mode 100644 index 240a31938a..0000000000 --- a/base_classes/nyaml/NXsample.nxdl.xml +++ /dev/null @@ -1,599 +0,0 @@ - - - - - - symbolic array lengths to be coordinated between various fields - - - - number of compositions - - - - - number of temperatures - - - - - number of values in applied electric field - - - - - number of values in applied magnetic field - - - - - number of values in applied pressure field - - - - - number of values in applied stress field - - - - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - - - - Descriptive name of sample - - - - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * 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. - * This is the *Hill* system used by Chemical Abstracts. - - - - - Sample temperature. This could be a scanned variable - - - - - - - - Applied electric field - - - - - - - - - - - - - - - Applied magnetic field - - - - - - - - - - - - - - - Applied external stress field - - - - - - - - - - - - - - - Applied pressure - - - - - - - - Sample changer position - - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - Unit cell parameters (lengths and angles) - - - - - - - - - Volume of the unit cell - - - - - - - - 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. - - - - - - - - - - Mass of sample - - - - - - - - Density of sample - - - - - - - - Relative Molecular Mass of sample - - - - - - - - - - - - - - - - - - - - - - The atmosphere will be one of the components, which is where its details will be - stored; the relevant components will be indicated by the entry in the - sample_component member. - - - - - - - - - - - - - - Description of the sample - - - - - Date of preparation of the sample - - - - - The position and orientation of the center of mass of the sample - - - - - Details of beam incident on sample - used to calculate sample/beam interaction - point - - - - - One group per sample component This is the perferred way of recording per - component information over the n_comp arrays - - - - - Details of the component of the sample and/or can - - - - - - - - Type of component - - - - - - - - - - - - - - Concentration of each component - - - - - - - - Volume fraction of each component - - - - - - - - Scattering length density of each component - - - - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - - Crystallographic space group - - - - - - - - Crystallographic point group, deprecated if space_group present - - - - - - - - Path length through sample/can for simple case when it does not vary with - scattering direction - - - - - Thickness of a beam entry/exit window on the can (mm). It is assumed to be the - same for entry and exit - - - - - sample thickness - - - - - Identification number or signatures of the sample used. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (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 - - - - - Physical state of the sample - - - - - Chemical purity of the sample - - - - - Surface termination of the sample (if crystalline) - - - - - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - - - - - Full chemical name of the sample - - - - - CAS registry number of the sample chemical content. - - - - - Gases might be fluxed on the surface for various reasons. Chemical designation, - or residual. - - - - - In the case of a fixed pressure measurement this is the scalar pressure. In the - case of an experiment in which pressure changes, or anyway is recorded, this is - an array of length m of pressures. - - - - - Element of evaporated surface dopant such as alkali or other - - - - - Nominal thickness of the evaporated dopant - - - - - Voltage applied to sample and sample holder. - - - - - Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition - etc.) - - - - - Name of the sample vendor (company or research group) - - - - - Material of the substrate in direct contact with the sample. - - - - - Physical state of the substrate, similar options to sample_state - - - - - Current to neutralize the photoemission current. This field may also be found in - NXmanpulator if present. - - - - - Possible bias of the sample with respect to analyser ground. This field may also - be found as sample_bias in NXmanipulator if present. - - - - - Further notes. - - - - - As a function of Wavelength - - - - - temperature.value is a link to e.g. temperature_env.sensor1.value - - - - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - - - - - Additional sample temperature environment information - - - - - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - - - - - magnetic_field_log.value is a link to e.g. - magnetic_field_env.sensor1.value_log.value - - - - - Additional sample magnetic environment information - - - - - value sent to user's sample setup - - - - - logged value (or logic state) read from user's setup - - - - - 20 character fixed length sample description for legends - - - - - Optional rotation angle for the case when the powder diagram has been obtained - through an omega-2theta scan like from a traditional single detector powder - diffractometer - - - - - Translation of the sample along the X-direction of the laboratory coordinate - system - - - - - Translation of the sample along the Z-direction of the laboratory coordinate - system - - - - - Any positioner (motor, PZT, ...) used to locate the sample - - - - - 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 sample 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/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 37e7201e88..c65363dae0 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -1,315 +1,333 @@ -doc: | +category: base +doc: | Any information on the sample. This could include scanned variables that are associated with one of the data dimensions, e.g. the magnetic field, or logged data, e.g. monitored temperature vs elapsed time. + symbols: - doc: "symbolic array lengths to be coordinated between various fields" - n_comp: "number of compositions" - n_Temp: "number of temperatures" - n_eField: "number of values in applied electric field" - n_mField: "number of values in applied magnetic field" - n_pField: "number of values in applied pressure field" - n_sField: "number of values in applied stress field" -category: base -NXsample: + doc: | + symbolic array lengths to be coordinated between various fields + + n_comp: | + number of compositions + + n_Temp: | + number of temperatures + + n_eField: | + number of values in applied electric field + + n_mField: | + number of values in applied magnetic field + + n_pField: | + number of values in applied pressure field + + n_sField: | + number of values in applied stress field + +type: group +NXsample(NXobject): name: - doc: "Descriptive name of sample" + doc: | + Descriptive name of sample chemical_formula: - doc: | + doc: | The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: + Abbreviated version of CIF standard':' * 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 + * 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 + * 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. + * 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. + * This is the *Hill* system used by Chemical Abstracts. temperature(NX_FLOAT): unit: NX_TEMPERATURE - doc: "Sample temperature. This could be a scanned variable" + doc: | + Sample temperature. This could be a scanned variable dimensions: rank: anyRank dim: [[1, n_Temp]] electric_field(NX_FLOAT): unit: NX_VOLTAGE - doc: "Applied electric field" + doc: | + Applied electric field dimensions: dim: [[1, n_eField]] \@direction: enumeration: [x, y, z] magnetic_field(NX_FLOAT): unit: NX_ANY - doc: "Applied magnetic field" + doc: | + Applied magnetic field dimensions: dim: [[1, n_mField]] \@direction: enumeration: [x, y, z] stress_field(NX_FLOAT): unit: NX_ANY - doc: "Applied external stress field" + doc: | + Applied external stress field dimensions: dim: [[1, n_sField]] \@direction: enumeration: [x, y, z] pressure(NX_FLOAT): unit: NX_PRESSURE - doc: "Applied pressure" + doc: | + Applied pressure dimensions: dim: [[1, n_pField]] changer_position(NX_INT): unit: NX_UNITLESS - doc: "Sample changer position" + doc: | + Sample changer position unit_cell_abc(NX_FLOAT): unit: NX_LENGTH - doc: "Crystallography unit cell parameters a, b, and c" + doc: | + Crystallography unit cell parameters a, b, and c dimensions: dim: [[1, 3]] unit_cell_alphabetagamma(NX_FLOAT): unit: NX_ANGLE - doc: "Crystallography unit cell parameters alpha, beta, and gamma" + doc: | + Crystallography unit cell parameters alpha, beta, and gamma dimensions: dim: [[1, 3]] unit_cell(NX_FLOAT): unit: NX_LENGTH - doc: "Unit cell parameters (lengths and angles)" + doc: | + Unit cell parameters (lengths and angles) dimensions: rank: 2 dim: [[1, n_comp], [2, 6]] unit_cell_volume(NX_FLOAT): unit: NX_VOLUME - doc: "Volume of the unit cell" + doc: | + Volume of the unit cell dimensions: rank: 1 dim: [[1, n_comp]] sample_orientation(NX_FLOAT): unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention: - + doc: | + This will follow the Busing-Levy convention':' W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 dimensions: rank: 1 dim: [[1, 3]] orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention: - + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention':' W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 dimensions: rank: 3 dim: [[1, n_comp], [2, 3], [3, 3]] ub_matrix(NX_FLOAT): - doc: | - 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. + doc: | + 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. dimensions: rank: 3 dim: [[1, n_comp], [2, 3], [3, 3]] mass(NX_FLOAT): unit: NX_MASS - doc: "Mass of sample" + doc: | + Mass of sample dimensions: rank: 1 dim: [[1, n_comp]] density(NX_FLOAT): unit: NX_MASS_DENSITY - doc: "Density of sample" + doc: | + Density of sample dimensions: rank: 1 dim: [[1, n_comp]] relative_molecular_mass(NX_FLOAT): unit: NX_MASS - doc: "Relative Molecular Mass of sample" + doc: | + Relative Molecular Mass of sample dimensions: rank: 1 dim: [[1, n_comp]] type: enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] situation: - doc: "The atmosphere will be one of the components, which is where - its details will be stored; the relevant components will be - indicated by the entry in the sample_component member." + doc: | + The atmosphere will be one of the components, which is where + its details will be stored; the relevant components will be + indicated by the entry in the sample_component member. enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] description: - doc: "Description of the sample" + doc: | + Description of the sample preparation_date(NX_DATE_TIME): - doc: "Date of preparation of the sample" + doc: | + Date of preparation of the sample geometry(NXgeometry): - doc: "The position and orientation of the center of mass of the sample" + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead + doc: | + The position and orientation of the center of mass of the sample (NXbeam): - doc: "Details of beam incident on sample - used to calculate sample/beam interaction point" + doc: | + Details of beam incident on sample - used to calculate sample/beam interaction point (NXsample_component): - doc: "One group per sample component - This is the perferred way of recording per component information over the n_comp arrays" + doc: | + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays component: - doc: "Details of the component of the sample and/or can" + doc: | + Details of the component of the sample and/or can dimensions: rank: 1 dim: [[1, n_comp]] sample_component: - doc: "Type of component" + doc: | + Type of component dimensions: rank: 1 dim: [[1, n_comp]] enumeration: [sample, can, atmosphere, kit] concentration(NX_FLOAT): unit: NX_MASS_DENSITY - doc: "Concentration of each component" + doc: | + Concentration of each component dimensions: rank: 1 dim: [[1, n_comp]] volume_fraction(NX_FLOAT): - doc: "Volume fraction of each component" + doc: | + Volume fraction of each component dimensions: rank: 1 dim: [[1, n_comp]] scattering_length_density(NX_FLOAT): unit: NX_SCATTERING_LENGTH_DENSITY - doc: "Scattering length density of each component" + doc: | + Scattering length density of each component dimensions: rank: 1 dim: [[1, n_comp]] unit_cell_class: - doc: "In case it is all we know and we want to record/document it" + doc: | + In case it is all we know and we want to record/document it enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] space_group: - doc: "Crystallographic space group" + doc: | + Crystallographic space group dimensions: dim: [[1, n_comp]] point_group: - doc: "Crystallographic point group, deprecated if space_group present" + doc: | + Crystallographic point group, deprecated if space_group present dimensions: dim: [[1, n_comp]] path_length(NX_FLOAT): unit: NX_LENGTH - doc: "Path length through sample/can for simple case when - it does not vary with scattering direction" + doc: | + Path length through sample/can for simple case when + it does not vary with scattering direction path_length_window(NX_FLOAT): unit: NX_LENGTH - doc: "Thickness of a beam entry/exit window on the can (mm). - It is assumed to be the same for entry and exit" + doc: | + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit thickness(NX_FLOAT): unit: NX_LENGTH - doc: "sample thickness" - sample_id(NX_CHAR): - doc: "Identification number or signatures of the sample used." - sample_history(NXnote): - doc: "A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. - Ideally, a full report of the previous operations, in any format (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" - state(NX_CHAR): - doc: "Physical state of the sample" - purity(NX_FLOAT): - unit: NX_UNITLESS - doc: "Chemical purity of the sample" - orientation(NX_CHAR): - doc: "Surface termination of the sample (if crystalline)" - layer(NX_CHAR): - doc: "Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.)" - chemical_name(NX_CHAR): - doc: "Full chemical name of the sample" - chem_id_cas(NX_CHAR): - doc: "CAS registry number of the sample chemical content." - gas(NX_CHAR): - doc: "Gases might be fluxed on the surface for various reasons. Chemical designation, or residual." - gas_pressure(NX_NUMBER): - doc: "In the case of a fixed pressure measurement this is the scalar pressure. - In the case of an experiment in which pressure changes, or anyway is recorded, - this is an array of length m of pressures." - unit: NX_PRESSURE - surface_dopant(NX_CHAR): - doc: "Element of evaporated surface dopant such as alkali or other" - surface_dopant_coverage(NX_FLOAT): - unit: NX_LENGTH - doc: "Nominal thickness of the evaporated dopant" - bias(NX_FLOAT): - unit: NX_VOLTAGE - doc: "Voltage applied to sample and sample holder." - growth_method(NX_CHAR): - doc: "Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition etc.)" - vendor(NX_CHAR): - doc: "Name of the sample vendor (company or research group)" - substrate_material(NX_CHAR): - doc: "Material of the substrate in direct contact with the sample." - substrate_state(NX_CHAR): - doc: "Physical state of the substrate, similar options to sample_state" - drain_current(NX_FLOAT): - doc: "Current to neutralize the photoemission current. - This field may also be found in NXmanpulator if present." - unit: NX_CURRENT - bias_voltage(NX_FLOAT): - doc: "Possible bias of the sample with respect to analyser ground. - This field may also be found as sample_bias in NXmanipulator if present." - unit: NX_VOLTAGE - notes(NXnote): - doc: "Further notes." + doc: | + sample thickness transmission(NXdata): - doc: "As a function of Wavelength" - temperature(NXlog): - doc: "temperature.value is a link to e.g. temperature_env.sensor1.value" + doc: | + As a function of Wavelength temperature_log(NXlog): - doc: "temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value" + deprecated: use ``temperature``, see':' https':'//github.com/nexusformat/definitions/issues/816 + doc: | + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value temperature_env(NXenvironment): - doc: "Additional sample temperature environment information" + doc: | + Additional sample temperature environment information magnetic_field(NXlog): - doc: "magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value" + doc: | + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value magnetic_field_log(NXlog): - doc: "magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value" + deprecated: use ``magnetic_field``, see':' https':'//github.com/nexusformat/definitions/issues/816 + doc: | + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value magnetic_field_env(NXenvironment): - doc: "Additional sample magnetic environment information" + doc: | + Additional sample magnetic environment information external_DAC(NX_FLOAT): unit: NX_ANY - doc: "value sent to user's sample setup" + doc: | + value sent to user's sample setup external_ADC(NXlog): - doc: "logged value (or logic state) read from user's setup" + doc: | + logged value (or logic state) read from user's setup short_title: - doc: "20 character fixed length sample description for legends" + doc: | + 20 character fixed length sample description for legends rotation_angle(NX_FLOAT): unit: NX_ANGLE - doc: "Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer" + doc: | + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. x_translation(NX_FLOAT): unit: NX_LENGTH - doc: "Translation of the sample along the X-direction of the laboratory coordinate system" + doc: | + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. distance(NX_FLOAT): unit: NX_LENGTH - doc: "Translation of the sample along the Z-direction of the laboratory coordinate system" + doc: | + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. (NXpositioner): - doc: "Any positioner (motor, PZT, ...) used to locate the sample" - depends_on(NX_CHAR): - doc: "Refers to the last transformation specifying the positon of the manipulator in the NXtransformations chain." - (NXtransformations): - doc: - "Collection of axis-based translations and rotations to describe the location and geometry of the sample 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." + doc: | + Any positioner (motor, PZT, ...) used to locate the sample + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sample \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. + doc: | + .. 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml new file mode 100644 index 0000000000..0723818866 --- /dev/null +++ b/base_classes/nyaml/NXsample_component.yaml @@ -0,0 +1,124 @@ +category: base +doc: | + One group like this per component can be recorded For a sample consisting of multiple components. + +symbols: + doc: | + symbolic array lengths to be coordinated between various fields + + n_Temp: | + number of temperatures + + n_eField: | + number of values in applied electric field + + n_mField: | + number of values in applied magnetic field + + n_pField: | + number of values in applied pressure field + + n_sField: | + number of values in applied stress field + +type: group +NXsample_component(NXobject): + name: + doc: | + Descriptive name of sample component + chemical_formula: + doc: | + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard':' + + * 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. + + * This is the *Hill* system used by Chemical Abstracts. + unit_cell_abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample component. + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample component + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample component + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample component + description: + doc: | + Description of the sample component + volume_fraction(NX_FLOAT): + doc: | + Volume fraction of component + scattering_length_density(NX_FLOAT): + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of component + unit_cell_class: + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + doc: | + Crystallographic space group + point_group: + doc: | + Crystallographic point group, deprecated if space_group present + transmission(NXdata): + doc: | + As a function of Wavelength + \@default: + doc: | + .. 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/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml new file mode 100644 index 0000000000..2a07d35a13 --- /dev/null +++ b/base_classes/nyaml/NXsensor.yaml @@ -0,0 +1,127 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in ':'ref':'`NXenvironment`. + +type: group +NXsensor(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, current, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions)':' + + ':'Temperature':' + J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe + ':'pH':' + Hg/Hg2Cl2 | Ag/AgCl | ISFET + ':'Ion selective electrode':' + specify species; e.g. Ca2+ + ':'Magnetic field':' + Hall + ':'Surface pressure':' + wilhelmy plate + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity':' + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXshape.yaml b/base_classes/nyaml/NXshape.yaml new file mode 100644 index 0000000000..2679d37772 --- /dev/null +++ b/base_classes/nyaml/NXshape.yaml @@ -0,0 +1,47 @@ +category: base +doc: | + legacy class - (used by ':'ref':'`NXgeometry`) - the shape and size of a component. + + This is the description of the general shape and size of a + component, which may be made up of ``numobj`` separate + elements - it is used by the ':'ref':'`NXgeometry` class + +type: group +NXshape(NXobject): + shape: + doc: | + general shape of a component + enumeration: [nxflat, nxcylinder, nxbox, nxsphere, nxcone, nxelliptical, nxtoroidal, nxparabolic, nxpolynomial] + size(NX_FLOAT): + unit: NX_LENGTH + doc: | + physical extent of the object along its local axes (after NXorientation) + with the center of mass at the local origin (after NXtranslation). + The meaning and location of these axes will vary according to the value + of the "shape" variable. + ``nshapepar`` defines how many parameters':' + + - For "nxcylinder" type the parameters are (diameter,height) and a three value orientation vector of the cylinder. + - For the "nxbox" type the parameters are (length,width,height). + - For the "nxsphere" type the parameters are (diameter). + - For nxcone cone half aperture + - For nxelliptical, semi-major axis, semi-minor-axis, angle of major axis and pole + - For nxtoroidal, major radius, minor radius + - For nxparabolic, parabolic parameter a + - For nxpolynomial, an array of polynom coefficients, the dimension of the array + encodes the degree of the polynom + dimensions: + dim: [[1, numobj], [2, nshapepar]] + direction: + enumeration: [concave, convex] + \@default: + doc: | + .. 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/nyaml/NXslit.yaml b/base_classes/nyaml/NXslit.yaml new file mode 100644 index 0000000000..e56fbb2798 --- /dev/null +++ b/base_classes/nyaml/NXslit.yaml @@ -0,0 +1,51 @@ +category: base +doc: | + A simple slit. + + For more complex geometries, ':'ref':'`NXaperture` should be used. + +type: group +NXslit(NXobject): + depends_on(NX_CHAR): + doc: | + Points to the path of the last element in the geometry chain that places + this object in space. + When followed through that chain is supposed to end at an element depending + on "." i.e. the origin of the coordinate system. + If desired the location of the slit can also be described relative to + an NXbeam, which will allow a simple description of a non-centred slit. + + The reference plane of the slit is orthogonal to the z axis and includes the + surface that is the entry surface of the slit. The reference point of the slit + is the centre of the slit opening in the x and y axis on the reference plane. + The reference point on the z axis is the reference plane. + + .. image':'':' slit/slit.png + ':'width':' 40% + x_gap(NX_NUMBER): + unit: NX_LENGTH + doc: | + Size of the gap opening in the first dimension of the local + coordinate system. + y_gap(NX_NUMBER): + unit: NX_LENGTH + doc: | + Size of the gap opening in the second dimension of the local + coordinate system. + \@default: + doc: | + .. 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. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXsource.nxdl.xml b/base_classes/nyaml/NXsource.nxdl.xml deleted file mode 100644 index 5fafb8acff..0000000000 --- a/base_classes/nyaml/NXsource.nxdl.xml +++ /dev/null @@ -1,274 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of points in a spectrum - - - - - The neutron or x-ray storage ring/facility. - - - - Effective distance from sample Distance as seen by radiation from sample. This - number should be negative to signify that it is upstream of the sample. - - - - - Name of source - - - - short name for source, perhaps the acronym - - - - - - Type of radiation source (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - - - - - - - - - - - Type of radiation probe (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - - - Source power - - - - - Source emittance (nm-rad) in X (horizontal) direction. - - - - - Source emittance (nm-rad) in Y (horizontal) direction. - - - - - Particle beam size in x - - - - - Particle beam size in y - - - - - Source intensity/area (example: s-1 cm-2) - - - - - Source energy. For storage rings, this would be the particle beam energy. For - X-ray tubes, this would be the excitation voltage. - - - - - Accelerator, X-ray tube, or storage ring current - - - - - Accelerator voltage - - - - - Frequency of pulsed source - - - - - Period of pulsed source - - - - - Pulsed source target material or other material used to generate light, e.g. He, - Ar gas for lasers, Xe or Hg/Cd vapor for arc lamps, etc. - - - - - - - - - - - - - - - - - - - Any source/facility related messages/events that occurred during the experiment - - - - - For storage rings, description of the bunch pattern. This is useful to describe - irregular bunch patterns. - - - - name of the bunch pattern - - - - - - For storage rings, the number of bunches in use. - - - - - For storage rings, temporal length of the bunch - - - - - For storage rings, time between bunches - - - - - Temporal width of source pulse - - - - - Source pulse shape - - - - - Source operating mode - - - - - For storage rings - - - - - For storage rings - - - - - - - Is the synchrotron operating in top_up mode? - - - - - For storage rings, the current at the end of the most recent injection. - - - - Date and time of the most recent injection. - - - - - - The center photon energy of the source, before it is monochromatized or - converted - - - - - The center wavelength of the source, before it is monochromatized or converted - - - - - For pulsed sources, the energy of a single pulse - - - - - For pulsed sources, the pulse energy divided by the pulse duration - - - - - Some facilities tag each bunch. First bunch of the measurement - - - - - Last bunch of the measurement - - - - - 'Engineering' location of source - - - - - The wavelength or energy distribution of the source - - - - - .. 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/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index 8aa002b513..cfc3ce8f2f 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -1,143 +1,168 @@ -doc: "The neutron or x-ray storage ring/facility." -symbols: - doc: "The symbols used in the schema to specify e.g. dimensions of arrays" - nx: "Number of points in a spectrum" category: base -NXsource: +doc: | + The neutron or x-ray storage ring/facility. + +type: group +NXsource(NXobject): distance(NX_FLOAT): unit: NX_LENGTH - doc: "Effective distance from sample - Distance as seen by radiation from sample. This number should be negative - to signify that it is upstream of the sample." + doc: | + Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample. name: - doc: "Name of source" + doc: | + Name of source \@short_name: - doc: "short name for source, perhaps the acronym" + doc: | + short name for source, perhaps the acronym type: - doc: "Type of radiation source (pick one from the enumerated list and spell exactly)" - enumeration: [ - Spallation Neutron Source, - Pulsed Reactor Neutron Source, - Reactor Neutron Source, - Synchrotron X-ray Source, - Pulsed Muon Source, - Rotating Anode X-ray, - Fixed Tube X-ray, - UV Laser, - Free-Electron Laser, - Optical Laser, - Ion Source, - UV Plasma Source, - Metal Jet X-ray, - arc lamp, - halogen lamp, - LED - ] + doc: | + type of radiation source (pick one from the enumerated list and spell exactly) + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] probe: - doc: "Type of radiation probe (pick one from the enumerated list and spell exactly)" + doc: | + type of radiation probe (pick one from the enumerated list and spell exactly) enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] power(NX_FLOAT): unit: NX_POWER - doc: "Source power" + doc: | + Source power emittance_x(NX_FLOAT): unit: NX_EMITTANCE - doc: "Source emittance (nm-rad) in X (horizontal) direction." + doc: | + Source emittance (nm-rad) in X (horizontal) direction. emittance_y(NX_FLOAT): unit: NX_EMITTANCE - doc: "Source emittance (nm-rad) in Y (horizontal) direction." + doc: | + Source emittance (nm-rad) in Y (horizontal) direction. sigma_x(NX_FLOAT): unit: NX_LENGTH - doc: "Particle beam size in x" + doc: | + particle beam size in x sigma_y(NX_FLOAT): unit: NX_LENGTH - doc: "Particle beam size in y" + doc: | + particle beam size in y flux(NX_FLOAT): unit: NX_FLUX - doc: "Source intensity/area (example: s-1 cm-2)" + doc: | + Source intensity/area (example':' s-1 cm-2) energy(NX_FLOAT): unit: NX_ENERGY - doc: "Source energy. - For storage rings, this would be the particle beam energy. - For X-ray tubes, this would be the excitation voltage." + doc: | + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. current(NX_FLOAT): unit: NX_CURRENT - doc: "Accelerator, X-ray tube, or storage ring current" + doc: | + Accelerator, X-ray tube, or storage ring current voltage(NX_FLOAT): unit: NX_VOLTAGE - doc: "Accelerator voltage" + doc: | + Accelerator voltage frequency(NX_FLOAT): unit: NX_FREQUENCY - doc: "Frequency of pulsed source" + doc: | + Frequency of pulsed source period(NX_FLOAT): unit: NX_PERIOD - doc: "Period of pulsed source" + doc: | + Period of pulsed source target_material: - doc: "Pulsed source target material or other material used to generate light, e.g. - He, Ar gas for lasers, Xe or Hg/Cd vapor for arc lamps, etc." - enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C, Ar, He, Xe, Hg/Cd, H] + doc: | + Pulsed source target material + enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] notes(NXnote): - doc: "Any source/facility related messages/events that - occurred during the experiment" + doc: | + any source/facility related messages/events that + occurred during the experiment bunch_pattern(NXdata): - doc: "For storage rings, description of the bunch pattern. - This is useful to describe irregular bunch patterns." + doc: | + For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns. title: - doc: "name of the bunch pattern" + doc: | + name of the bunch pattern number_of_bunches(NX_INT): - doc: "For storage rings, the number of bunches in use." + doc: | + For storage rings, the number of bunches in use. bunch_length(NX_FLOAT): unit: NX_TIME - doc: "For storage rings, temporal length of the bunch" + doc: | + For storage rings, temporal length of the bunch bunch_distance(NX_FLOAT): unit: NX_TIME - doc: "For storage rings, time between bunches" + doc: | + For storage rings, time between bunches pulse_width(NX_FLOAT): unit: NX_TIME - doc: "Temporal width of source pulse" + doc: | + temporal width of source pulse pulse_shape(NXdata): - doc: "Source pulse shape" + doc: | + source pulse shape mode: - doc: "Source operating mode" + doc: | + source operating mode enumeration: Single Bunch: - doc: "For storage rings" + doc: | + for storage rings Multi Bunch: - doc: "For storage rings" + doc: | + for storage rings top_up(NX_BOOLEAN): - doc: "Is the synchrotron operating in top_up mode?" + doc: | + Is the synchrotron operating in top_up mode? last_fill(NX_NUMBER): unit: NX_CURRENT - doc: "For storage rings, the current at the end of the most recent injection." + doc: | + For storage rings, the current at the end of the most recent injection. \@time: - doc: "Date and time of the most recent injection." - photon_energy(NX_FLOAT): - unit: NX_ENERGY - doc: "The center photon energy of the source, before it is monochromatized or converted" - center_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: "The center wavelength of the source, before it is monochromatized or converted" - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: "For pulsed sources, the energy of a single pulse" - peak_power(NX_FLOAT): - unit: NX_POWER - doc: "For pulsed sources, the pulse energy divided by the pulse duration" - bunch_number_start(NX_INT): - doc: "Some facilities tag each bunch. First bunch of the measurement" - bunch_number_end(NX_INT): - doc: "Last bunch of the measurement" + type: NX_DATE_TIME + doc: | + date and time of the most recent injection. geometry(NXgeometry): - doc: "'Engineering' location of source" - distribution(NXdata): - doc: "The wavelength or energy distribution of the source" + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the source and NXoff_geometry to describe its shape instead + doc: | + "Engineering" location of source. + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + (NXdata)distribution: + doc: | + The wavelength or energy distribution of the source \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. + doc: | + .. 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image':'':' source/source.png + ':'width':' 40% + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXsubentry.yaml b/base_classes/nyaml/NXsubentry.yaml new file mode 100644 index 0000000000..840297cfbf --- /dev/null +++ b/base_classes/nyaml/NXsubentry.yaml @@ -0,0 +1,148 @@ +category: base +doc: | + Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. + + ``NXsubentry`` is a base class virtually identical to ':'ref':'`NXentry` + and is used as the (overlay) location for application definitions. + Use a separate ``NXsubentry`` for each application definition. + + To use ``NXsubentry`` with a hypothetical application definition + called ``NXmyappdef``':' + + * Create a group with attribute ``NX_class="NXsubentry"`` + * Within that group, create a field called ``definition="NXmyappdef"``. + * There are two optional attributes of definition':' ``version`` and ``URL`` + + The intended use is to define application definitions for a + multi-modal (a.k.a. multi-technique) ':'ref':'`NXentry`. + Previously, an application definition + replaced ':'ref':'`NXentry` with its own definition. + With the increasing popularity of instruments combining + multiple techniques for data collection (such as SAXS/WAXS instruments), + it was recognized the application definitions must be entered in the NeXus + data file tree as children of ':'ref':'`NXentry`. + +type: group +NXsubentry(NXobject): + \@default: + doc: | + .. index':'':' find the default plottable data + .. index':'':' plotting + .. index':'':' default attribute value + + Declares which ':'ref':'`NXdata` group contains the data + to be shown by default. + It is used to resolve ambiguity when + one ':'ref':'`NXdata` group exists. + The value ':'ref':'`names ` the default ':'ref':'`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + For more information about how NeXus identifies the default + plottable data, see the + ':'ref':'`Find Plottable Data, v3 ` + section. + \@IDF_Version: + doc: | + ISIS Muon IDF_Version + title: + doc: | + Extended title for entry + experiment_identifier: + doc: | + Unique identifier for the experiment, defined by + the facility, possibly linked to the proposals + experiment_description: + doc: | + Brief summary of the experiment, including key objectives. + (NXnote)experiment_documentation: + doc: | + Description of the full experiment (document in pdf, latex, ...) + collection_identifier: + doc: | + User or Data Acquisition defined group of NeXus files or ':'ref':'`NXentry` + collection_description: + doc: | + Brief summary of the collection, including grouping criteria. + entry_identifier: + doc: | + unique identifier for the measurement, defined by the facility. + definition: + doc: | + Official NeXus NXDL schema to which this subentry conforms + \@version: + doc: | + NXDL version number + \@URL: + doc: | + URL of NXDL file + definition_local: + doc: | + Local NXDL schema extended from the subentry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the subentry. + \@version: + doc: | + NXDL version number + \@URL: + doc: | + URL of NXDL file + start_time(NX_DATE_TIME): + doc: | + Starting time of measurement + end_time(NX_DATE_TIME): + doc: | + Ending time of measurement + duration(NX_INT): + unit: NX_TIME + doc: | + Duration of measurement + collection_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + run_cycle: + doc: | + Such as "2007-3". Some user facilities organize their beam time into run cycles. + program_name: + doc: | + Name of program used to generate this file + \@version: + doc: | + Program version number + \@configuration: + doc: | + configuration of the program + revision: + doc: | + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + \@comment: + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words':' it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + notes(NXnote): + doc: | + Notes describing entry + thumbnail(NXnote): + doc: | + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + \@mime_type: + doc: | + The value should be an ``image/*`` + enumeration: [image/*] + (NXuser): + (NXsample): + (NXinstrument): + (NXcollection): + (NXmonitor): + (NXdata): + (NXparameters): + (NXprocess): diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml new file mode 100644 index 0000000000..e27b95ac1f --- /dev/null +++ b/base_classes/nyaml/NXtransformations.yaml @@ -0,0 +1,182 @@ +category: base +doc: | + Collection of axis-based translations and rotations to describe a geometry. + May also contain axes that do not move and therefore do not have a transformation + type specified, but are useful in understanding coordinate frames within which + transformations are done, or in documenting important directions, such as the + direction of gravity. + + A nested sequence of transformations lists the translation and rotation steps + needed to describe the position and orientation of any movable or fixed device. + + There will be one or more transformations (axes) defined by one or more fields + for each transformation. Transformations can also be described by NXlog groups when + the values change with time. The all-caps name ``AXISNAME`` designates the + particular axis generating a transformation (e.g. a rotation axis or a translation + axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the + units will be appropriate to the ``transformation_type`` attribute':' + + * ``NX_LENGTH`` for ``translation`` + * ``NX_ANGLE`` for ``rotation`` + * ``NX_UNITLESS`` for axes for which no transformation type is specified + + This class will usually contain all axes of a sample stage or goniometer or + a detector. The NeXus default McSTAS coordinate frame is assumed, but additional + useful coordinate axes may be defined by using axes for which no transformation + type has been specified. + + The entry point (``depends_on``) will be outside of this class and point to a + field in here. Following the chain may also require following ``depends_on`` + links to transformations outside, for example to a common base table. If + a relative path is given, it is relative to the group enclosing the ``depends_on`` + specification. + + For a chain of three transformations, where ':'math':'`T_1` depends on ':'math':'`T_2` + and that in turn depends on ':'math':'`T_3`, the final transformation ':'math':'`T_f` is + + .. math':'':' T_f = T_3 T_2 T_1 + + In explicit terms, the transformations are a subset of affine transformations + expressed as 4x4 matrices that act on homogeneous coordinates, ':'math':'`w=(x,y,z,1)^T`. + + For rotation and translation, + + .. math':'':' T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} + + where ':'math':'`R` is the usual 3x3 rotation matrix, ':'math':'`o` is an offset vector, + ':'math':'`0_3` is a row of 3 zeros, ':'math':'`I_3` is the 3x3 identity matrix and + ':'math':'`t` is the translation vector. + + ':'math':'`o` is given by the ``offset`` attribute, ':'math':'`t` is given by the ``vector`` + attribute multiplied by the field value, and ':'math':'`R` is defined as a rotation + about an axis in the direction of ``vector``, of angle of the field value. + + NOTE + + One possible use of ``NXtransformations`` is to define the motors and + transformations for a diffractometer (goniometer). Such use is mentioned + in the ``NXinstrument`` base class. Use one ``NXtransformations`` group + for each diffractometer and name the group appropriate to the device. + Collecting the motors of a sample table or xyz-stage in an NXtransformations + group is equally possible. + + + Following the section on the general dscription of axis in NXtransformations is a section which + documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever + there is a need for positioning a beam line component please use the existing names. Use as many fields + as needed in order to position the component. Feel free to add more axis if required. In the description + given below, only those atttributes which are defined through the name are spcified. Add the other attributes + of the full set':' + + * vector + * offset + * transformation_type + * depends_on + + as needed. + +type: group +ignoreExtraGroups: true +ignoreExtraFields: true +ignoreExtraAttributes: true +NXtransformations(NXobject): + AXISNAME(NX_NUMBER): + nameType: any + unit: NX_TRANSFORMATION + exists: ['max', 'unbounded'] + doc: | + Units need to be appropriate for translation or rotation + + The name of this field is not forced. The user is free to use any name + that does not cause confusion. When using more than one ``AXISNAME`` field, + make sure that each field name is unique in the same group, as required + by HDF5. + + The values given should be the start points of exposures for the corresponding + frames. The end points should be given in ``AXISNAME_end``. + \@transformation_type: + exists: optional + doc: | + The transformation_type may be ``translation``, in which case the + values are linear displacements along the axis, ``rotation``, + in which case the values are angular rotations around the axis. + + If this attribute is omitted, this is an axis for which there + is no motion to be specifies, such as the direction of gravity, + or the direction to the source, or a basis vector of a + coordinate frame. + enumeration: [translation, rotation] + \@vector: + exists: optional + type: NX_NUMBER + doc: | + Three values that define the axis for this transformation. + The axis should be normalized to unit length, making it + dimensionless. For ``rotation`` axes, the direction should be + chosen for a right-handed rotation with increasing angle. + For ``translation`` axes the direction should be chosen for + increasing displacement. For general axes, an appropriate direction + should be chosen. + dimensions: + rank: 1 + dim: [[1, 3]] + \@offset: + type: NX_NUMBER + doc: | + A fixed offset applied before the transformation (three vector components). + This is not intended to be a substitute for a fixed ``translation`` axis but, for example, + as the mechanical offset from mounting the axis to its dependency. + dimensions: + rank: 1 + dim: [[1, 3]] + \@offset_units: + type: NX_CHAR + doc: | + Units of the offset. Values should be consistent with NX_LENGTH. + \@depends_on: + type: NX_CHAR + doc: | + Points to the path to a field defining the axis on which this + depends or the string ".". + \@equipment_component: + type: NX_CHAR + doc: | + An arbitrary identifier of a component of the equipment to which + the transformation belongs, such as 'detector_arm' or 'detector_module'. + NXtransformations with the same equipment_component label form a logical + grouping which can be combined together into a single change-of-basis + operation. + AXISNAME_end(NX_NUMBER): + unit: NX_TRANSFORMATION + nameType: any + exists: ['min', '0'] + doc: | + ``AXISNAME_end`` is a placeholder for a name constructed from the actual + name of an axis to which ``_end`` has been appended. + + The values in this field are the end points of the motions that start + at the corresponding positions given in the ``AXISNAME`` field. + AXISNAME_increment_set(NX_NUMBER): + unit: NX_TRANSFORMATION + nameType: any + exists: ['min', '0'] + doc: | + ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual + name of an axis to which ``_increment_set`` has been appended. + + The value of this optional field is the intended average range through which + the corresponding axis moves during the exposure of a frame. Ideally, the + value of this field added to each value of ``AXISNAME`` would agree with the + corresponding values of ``AXISNAME_end``, but there is a possibility of significant + differences. Use of ``AXISNAME_end`` is recommended. + \@default: + doc: | + .. 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/nyaml/NXtranslation.yaml b/base_classes/nyaml/NXtranslation.yaml new file mode 100644 index 0000000000..5a0337be14 --- /dev/null +++ b/base_classes/nyaml/NXtranslation.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + legacy class - (used by ':'ref':'`NXgeometry`) - general spatial location of a component. + +type: group +NXtranslation(NXobject): + geometry(NXgeometry): + doc: | + Link to other object if we are relative, else absent + distances(NX_FLOAT): + unit: NX_LENGTH + doc: | + (x,y,z) + This field describes the lateral movement of a component. + The pair of groups NXtranslation and NXorientation together + describe the position of a component. + For absolute position, the origin is the scattering center (where a perfectly + aligned sample would be) with the z-axis pointing downstream and the y-axis + pointing gravitationally up. For a relative position the NXtranslation is + taken into account before the NXorientation. The axes are right-handed and + orthonormal. + dimensions: + dim: [[1, numobj], [2, 3]] + \@default: + doc: | + .. 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/nyaml/NXuser.yaml b/base_classes/nyaml/NXuser.yaml new file mode 100644 index 0000000000..b0dbe8ed04 --- /dev/null +++ b/base_classes/nyaml/NXuser.yaml @@ -0,0 +1,54 @@ +category: base +doc: | + Contact information for a user. + + The format allows more + than one user with the same affiliation and contact information, + but a second ':'ref':'`NXuser` group should be used if they have different + affiliations, etc. + +type: group +NXuser(NXobject): + name: + doc: | + Name of user responsible for this entry + role: + doc: | + Role of user responsible for this entry. + Suggested roles are "local_contact", + "principal_investigator", and "proposer" + affiliation: + doc: | + Affiliation of user + address: + doc: | + Address of user + telephone_number: + doc: | + Telephone number of user + fax_number: + doc: | + Fax number of user + email: + doc: | + Email of user + facility_user_id: + doc: | + facility based unique identifier for this person + e.g. their identification code on the facility + address/contact database + ORCID: + doc: | + an author code, Open Researcher and Contributor ID, + defined by https':'//orcid.org and expressed as a URI + \@default: + doc: | + .. 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/nyaml/NXvelocity_selector.yaml b/base_classes/nyaml/NXvelocity_selector.yaml new file mode 100644 index 0000000000..76079fd503 --- /dev/null +++ b/base_classes/nyaml/NXvelocity_selector.yaml @@ -0,0 +1,87 @@ +category: base +doc: | + A neutron velocity selector + +type: group +NXvelocity_selector(NXobject): + type: + doc: | + velocity selector type + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + velocity selector rotation speed + radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + radius at beam centre + spwidth(NX_FLOAT): + unit: NX_LENGTH + doc: | + spoke width at beam centre + length(NX_FLOAT): + unit: NX_LENGTH + doc: | + rotor length + num(NX_INT): + unit: NX_UNITLESS + doc: | + number of spokes/lamella + twist(NX_FLOAT): + unit: NX_ANGLE + doc: | + twist angle along axis + table(NX_FLOAT): + unit: NX_ANGLE + doc: | + offset vertical angle + height(NX_FLOAT): + unit: NX_LENGTH + doc: | + input beam height + width(NX_FLOAT): + unit: NX_LENGTH + doc: | + input beam width + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + wavelength + wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + deviation FWHM /Wavelength + (NXgeometry)geometry: + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the velocity selector and NXoff_geometry to describe its shape instead + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a velocity selector. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/nyaml/NXxraylens.yaml b/base_classes/nyaml/NXxraylens.yaml new file mode 100644 index 0000000000..5c46e87fc1 --- /dev/null +++ b/base_classes/nyaml/NXxraylens.yaml @@ -0,0 +1,86 @@ +category: base +doc: | + An X-ray lens, typically at a synchrotron X-ray beam line. + + Based on information provided by Gerd Wellenreuther (DESY). + +type: group +NXxraylens(NXobject): + lens_geometry(NX_CHAR): + doc: | + Geometry of the lens + enumeration: [paraboloid, spherical, elliptical, hyperbolical] + symmetric(NX_BOOLEAN): + doc: | + Is the device symmetric? + cylindrical(NX_BOOLEAN): + doc: | + Is the device cylindrical? + cylinder_orientation(NXnote): + doc: | + Orientation of the cylinder axis. + focus_type(NX_CHAR): + doc: | + The type of focus of the lens + enumeration: [line, point] + lens_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the lens + lens_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Length of the lens + curvature(NX_FLOAT): + unit: NX_LENGTH + doc: | + Radius of the curvature as measured in the middle of the lens + aperture(NX_FLOAT): + unit: NX_LENGTH + doc: | + Diameter of the lens. + number_of_lenses(NX_INT): + doc: | + Number of lenses that make up the compound lens. + lens_material(NX_CHAR): + doc: | + Material used to make the lens. + gas(NX_CHAR): + doc: | + Gas used to fill the lens + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Gas pressure in the lens + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. 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. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a x-ray lens. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. From 1deaacdddd2a2a4e8ac04d95a79f494259d2a7b8 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Thu, 16 Mar 2023 18:28:28 +0100 Subject: [PATCH 109/203] Contributed_definition: Generating nxdl file from yaml in contributed_definition/nyaml. And Some definitions do not have any yaml files but nxdl file. In that case yaml file has been created from nxdl file. Note that this nxdl files are original with comments --- .../NXaperture_em.nxdl.xml | 29 +- contributed_definitions/NXapm.nxdl.xml | 281 ++-- .../NXapm_input_ranging.nxdl.xml | 63 +- .../NXapm_input_reconstruction.nxdl.xml | 50 +- .../NXapm_paraprobe_config_clusterer.nxdl.xml | 429 +++-- .../NXapm_paraprobe_config_distancer.nxdl.xml | 73 +- ...Xapm_paraprobe_config_intersector.nxdl.xml | 500 +++--- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 131 +- .../NXapm_paraprobe_config_ranger.nxdl.xml | 75 +- .../NXapm_paraprobe_config_selector.nxdl.xml | 69 +- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 317 ++-- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 108 +- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 69 +- ...NXapm_paraprobe_config_transcoder.nxdl.xml | 91 +- ...NXapm_paraprobe_results_clusterer.nxdl.xml | 145 +- ...NXapm_paraprobe_results_distancer.nxdl.xml | 141 +- ...apm_paraprobe_results_intersector.nxdl.xml | 143 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 288 ++-- .../NXapm_paraprobe_results_ranger.nxdl.xml | 258 ++- .../NXapm_paraprobe_results_selector.nxdl.xml | 133 +- .../NXapm_paraprobe_results_spatstat.nxdl.xml | 141 +- .../NXapm_paraprobe_results_surfacer.nxdl.xml | 163 +- ...apm_paraprobe_results_tessellator.nxdl.xml | 147 +- ...Xapm_paraprobe_results_transcoder.nxdl.xml | 149 +- contributed_definitions/NXatom_set.nxdl.xml | 25 +- .../NXcalibration.nxdl.xml | 28 +- .../{nyaml => }/NXcg_alpha_complex.nxdl.xml | 29 +- .../NXcg_alpha_shape.nxdl.xml | 29 +- .../NXcg_cylinder_set.nxdl.xml | 25 +- .../NXcg_ellipsoid_set.nxdl.xml | 28 +- .../NXcg_face_list_data_structure.nxdl.xml | 25 +- .../NXcg_geodesic_mesh.nxdl.xml | 25 +- contributed_definitions/NXcg_grid.nxdl.xml | 27 +- .../NXcg_half_edge_data_structure.nxdl.xml | 25 +- .../NXcg_hexahedron_set.nxdl.xml | 25 +- .../NXcg_isocontour.nxdl.xml | 25 +- .../NXcg_marching_cubes.nxdl.xml | 31 +- .../NXcg_parallelogram_set.nxdl.xml | 25 +- .../NXcg_point_set.nxdl.xml | 25 +- .../NXcg_polygon_set.nxdl.xml | 25 +- .../NXcg_polyhedron_set.nxdl.xml | 25 +- .../NXcg_polyline_set.nxdl.xml | 25 +- contributed_definitions/NXcg_roi_set.nxdl.xml | 25 +- .../NXcg_sphere_set.nxdl.xml | 25 +- .../NXcg_tetrahedron_set.nxdl.xml | 25 +- .../NXcg_triangle_set.nxdl.xml | 25 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 25 +- .../NXcg_unit_normal_set.nxdl.xml | 25 +- contributed_definitions/NXchamber.nxdl.xml | 29 +- .../NXchemical_composition.nxdl.xml | 25 +- contributed_definitions/NXclustering.nxdl.xml | 25 +- .../NXcollectioncolumn.nxdl.xml | 28 +- .../NXcoordinate_system_set.nxdl.xml | 25 +- .../NXcorrector_cs.nxdl.xml | 29 +- .../NXcs_computer.nxdl.xml | 33 +- contributed_definitions/NXcs_cpu.nxdl.xml | 27 +- .../NXcs_filter_boolean_mask.nxdl.xml | 25 +- contributed_definitions/NXcs_gpu.nxdl.xml | 27 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 29 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 25 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 25 +- contributed_definitions/NXcs_prng.nxdl.xml | 31 +- .../NXcs_profiling.nxdl.xml | 30 +- .../NXcs_profiling_event.nxdl.xml | 27 +- contributed_definitions/NXdeflector.nxdl.xml | 38 +- .../NXdelocalization.nxdl.xml | 31 +- contributed_definitions/NXdistortion.nxdl.xml | 37 +- .../NXebeam_column.nxdl.xml | 37 +- .../NXelectronanalyser.nxdl.xml | 48 +- .../NXellipsometry.nxdl.xml | 121 +- contributed_definitions/NXem.nxdl.xml | 283 ++-- .../{nyaml => }/NXem_ebsd.nxdl.xml | 199 +-- .../NXem_ebsd_conventions.nxdl.xml | 73 +- ...NXem_ebsd_crystal_structure_model.nxdl.xml | 41 +- .../NXenergydispersion.nxdl.xml | 28 +- .../NXevent_data_em.nxdl.xml | 33 +- .../NXevent_data_em_set.nxdl.xml | 25 +- .../NXfabrication.nxdl.xml | 33 +- .../NXgraph_edge_set.nxdl.xml | 25 +- .../NXgraph_node_set.nxdl.xml | 28 +- contributed_definitions/NXgraph_root.nxdl.xml | 25 +- .../NXibeam_column.nxdl.xml | 31 +- .../NXimage_set_em.nxdl.xml | 33 +- .../NXimage_set_em_adf.nxdl.xml | 39 +- .../NXimage_set_em_kikuchi.nxdl.xml | 372 ++--- contributed_definitions/NXion.nxdl.xml | 30 +- .../{nyaml => }/NXisocontour.nxdl.xml | 25 +- contributed_definitions/NXiv_temp.nxdl.xml | 30 +- contributed_definitions/NXlens_em.nxdl.xml | 72 +- .../{nyaml => }/NXliquid_jet.nxdl.xml | 37 +- .../NXmanipulator.nxdl.xml | 30 +- .../NXmatch_filter.nxdl.xml | 29 +- contributed_definitions/NXmpes.nxdl.xml | 82 +- .../{nyaml => }/NXmpes_liquid.nxdl.xml | 91 +- .../NXms_crystal_set.nxdl.xml | 29 +- .../{nyaml => }/NXms_dislocation_set.nxdl.xml | 25 +- .../{nyaml => }/NXms_interface_set.nxdl.xml | 25 +- .../NXms_snapshot.nxdl.xml | 27 +- .../NXms_snapshot_set.nxdl.xml | 27 +- .../NXoptical_system_em.nxdl.xml | 25 +- .../NXorientation_set.nxdl.xml | 25 +- contributed_definitions/NXpeak.nxdl.xml | 29 +- contributed_definitions/NXpid.nxdl.xml | 27 +- contributed_definitions/NXpulser_apm.nxdl.xml | 29 +- contributed_definitions/NXpump.nxdl.xml | 27 +- contributed_definitions/NXreflectron.nxdl.xml | 29 +- .../NXregistration.nxdl.xml | 28 +- contributed_definitions/NXscanbox_em.nxdl.xml | 27 +- .../NXsensor_scan.nxdl.xml | 79 +- .../{nyaml => }/NXsensor_scan_parsed.nxdl.xml | 55 +- .../NXsimilarity_grouping.nxdl.xml | 25 +- .../NXslip_system_set.nxdl.xml | 27 +- .../NXspatial_filter.nxdl.xml | 27 +- .../NXspectrum_set_em_eels.nxdl.xml | 45 +- .../NXspectrum_set_em_xray.nxdl.xml | 67 +- .../NXspindispersion.nxdl.xml | 32 +- contributed_definitions/NXstage_lab.nxdl.xml | 31 +- .../NXsubsampling_filter.nxdl.xml | 27 +- .../NXtransmission.nxdl.xml | 74 +- .../nyaml/NXaberration.yaml | 65 + contributed_definitions/nyaml/NXaperture.yaml | 55 + .../nyaml/NXaperture_em.nxdl.xml | 37 - contributed_definitions/nyaml/NXapm.nxdl.xml | 1399 ----------------- .../nyaml/NXapm_input_ranging.nxdl.xml | 41 - .../nyaml/NXapm_input_reconstruction.nxdl.xml | 36 - .../NXapm_paraprobe_config_clusterer.nxdl.xml | 409 ----- .../NXapm_paraprobe_config_distancer.nxdl.xml | 226 --- ...Xapm_paraprobe_config_intersector.nxdl.xml | 306 ---- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 1019 ------------ .../NXapm_paraprobe_config_ranger.nxdl.xml | 266 ---- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 334 ---- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 260 --- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 190 --- ...NXapm_paraprobe_config_transcoder.nxdl.xml | 93 -- .../NXapm_paraprobe_results_ranger.nxdl.xml | 425 ----- ...Xapm_paraprobe_results_transcoder.nxdl.xml | 383 ----- .../nyaml/NXatom_set.nxdl.xml | 17 - contributed_definitions/nyaml/NXbeam.yaml | 242 +++ .../nyaml/NXcalibration.nxdl.xml | 90 -- .../nyaml/NXcg_alpha_shape.nxdl.xml | 98 -- .../nyaml/NXcg_cylinder_set.nxdl.xml | 132 -- .../nyaml/NXcg_ellipsoid_set.nxdl.xml | 112 -- .../NXcg_face_list_data_structure.nxdl.xml | 219 --- .../nyaml/NXcg_geodesic_mesh.nxdl.xml | 35 - .../nyaml/NXcg_grid.nxdl.xml | 151 -- .../NXcg_half_edge_data_structure.nxdl.xml | 147 -- .../nyaml/NXcg_hexahedron_set.nxdl.xml | 207 --- .../nyaml/NXcg_isocontour.nxdl.xml | 43 - .../nyaml/NXcg_marching_cubes.nxdl.xml | 50 - .../nyaml/NXcg_parallelogram_set.nxdl.xml | 156 -- .../nyaml/NXcg_point_set.nxdl.xml | 77 - .../nyaml/NXcg_polygon_set.nxdl.xml | 135 -- .../nyaml/NXcg_polyhedron_set.nxdl.xml | 150 -- .../nyaml/NXcg_polyline_set.nxdl.xml | 153 -- .../nyaml/NXcg_roi_set.nxdl.xml | 16 - .../nyaml/NXcg_sphere_set.nxdl.xml | 98 -- .../nyaml/NXcg_tetrahedron_set.nxdl.xml | 132 -- .../nyaml/NXcg_triangle_set.nxdl.xml | 107 -- .../NXcg_triangulated_surface_mesh.nxdl.xml | 22 - .../nyaml/NXcg_unit_normal_set.nxdl.xml | 46 - .../nyaml/NXchamber.nxdl.xml | 19 - .../nyaml/NXclustering.nxdl.xml | 100 -- .../nyaml/NXcollectioncolumn.nxdl.xml | 83 - .../nyaml/NXcontainer.yaml | 123 ++ .../nyaml/NXcoordinate_system_set.nxdl.xml | 62 - .../nyaml/NXcorrector_cs.nxdl.xml | 40 - .../nyaml/NXcs_computer.nxdl.xml | 57 - .../nyaml/NXcs_cpu.nxdl.xml | 18 - .../nyaml/NXcs_filter_boolean_mask.nxdl.xml | 83 - .../nyaml/NXcs_gpu.nxdl.xml | 18 - .../nyaml/NXcs_io_obj.nxdl.xml | 33 - .../nyaml/NXcs_io_sys.nxdl.xml | 13 - .../nyaml/NXcs_mm_sys.nxdl.xml | 17 - .../nyaml/NXcs_prng.nxdl.xml | 61 - .../nyaml/NXcs_profiling.nxdl.xml | 120 -- .../nyaml/NXcs_profiling_event.nxdl.xml | 74 - contributed_definitions/nyaml/NXcsg.yaml | 32 + .../nyaml/NXcxi_ptycho.yaml | 211 +++ .../nyaml/NXdeflector.nxdl.xml | 71 - .../nyaml/NXdelocalization.nxdl.xml | 109 -- contributed_definitions/nyaml/NXdetector.yaml | 589 +++++++ .../nyaml/NXdistortion.nxdl.xml | 90 -- .../nyaml/NXebeam_column.nxdl.xml | 82 - .../nyaml/NXelectronanalyser.nxdl.xml | 136 -- .../nyaml/NXelectrostatic_kicker.yaml | 43 + .../nyaml/NXellipsometry.nxdl.xml | 839 ---------- contributed_definitions/nyaml/NXem.nxdl.xml | 1210 -------------- .../nyaml/NXenergydispersion.nxdl.xml | 69 - contributed_definitions/nyaml/NXentry.yaml | 202 +++ .../nyaml/NXevent_data_em.nxdl.xml | 221 --- .../nyaml/NXevent_data_em_set.nxdl.xml | 11 - .../nyaml/NXfabrication.nxdl.xml | 29 - .../nyaml/NXgraph_edge_set.nxdl.xml | 92 -- .../nyaml/NXgraph_node_set.nxdl.xml | 66 - .../nyaml/NXgraph_root.nxdl.xml | 14 - .../nyaml/NXibeam_column.nxdl.xml | 99 -- .../nyaml/NXimage_set_em.nxdl.xml | 86 - .../nyaml/NXimage_set_em.yaml | 68 +- .../nyaml/NXimage_set_em_adf.nxdl.xml | 130 -- .../nyaml/NXimage_set_em_bf.yaml | 8 + .../nyaml/NXimage_set_em_bse.yaml | 8 + .../nyaml/NXimage_set_em_chamber.yaml | 8 + .../nyaml/NXimage_set_em_df.yaml | 8 + .../nyaml/NXimage_set_em_diffrac.yaml | 8 + .../nyaml/NXimage_set_em_ecci.yaml | 8 + .../nyaml/NXimage_set_em_kikuchi.nxdl.xml | 173 -- .../nyaml/NXimage_set_em_kikuchi.yaml | 80 +- .../nyaml/NXimage_set_em_ronchigram.yaml | 11 + .../nyaml/NXimage_set_em_se.yaml | 111 ++ .../nyaml/NXinstrument.yaml | 71 + .../nyaml/NXinteraction_vol_em.yaml | 36 + contributed_definitions/nyaml/NXion.nxdl.xml | 110 -- .../nyaml/NXiv_temp.nxdl.xml | 63 - .../nyaml/NXlens_em.nxdl.xml | 77 - .../nyaml/NXmagnetic_kicker.yaml | 43 + .../nyaml/NXmanipulator.nxdl.xml | 79 - .../nyaml/NXmatch_filter.nxdl.xml | 42 - contributed_definitions/nyaml/NXmpes.nxdl.xml | 331 ---- .../nyaml/NXms_crystal_set.nxdl.xml | 123 -- .../nyaml/NXms_snapshot.nxdl.xml | 32 - .../nyaml/NXms_snapshot.yaml | 22 +- .../nyaml/NXms_snapshot_set.nxdl.xml | 35 - .../nyaml/NXoptical_system_em.nxdl.xml | 55 - .../nyaml/NXorientation_set.nxdl.xml | 94 -- contributed_definitions/nyaml/NXpeak.nxdl.xml | 66 - contributed_definitions/nyaml/NXpid.nxdl.xml | 63 - contributed_definitions/nyaml/NXprocess.yaml | 45 + .../nyaml/NXpulser_apm.nxdl.xml | 117 -- contributed_definitions/nyaml/NXpump.nxdl.xml | 19 - contributed_definitions/nyaml/NXquadric.yaml | 27 + .../nyaml/NXquadrupole_magnet.yaml | 31 + .../nyaml/NXreflectron.nxdl.xml | 31 - contributed_definitions/nyaml/NXregion.yaml | 148 ++ .../nyaml/NXregistration.nxdl.xml | 34 - contributed_definitions/nyaml/NXsample.yaml | 412 +++++ .../nyaml/NXscanbox_em.nxdl.xml | 20 - .../nyaml/NXsensor_scan.nxdl.xml | 176 --- .../nyaml/NXseparator.yaml | 48 + .../nyaml/NXslip_system_set.nxdl.xml | 56 - contributed_definitions/nyaml/NXsnsevent.yaml | 294 ++++ contributed_definitions/nyaml/NXsnshisto.yaml | 315 ++++ .../nyaml/NXsolenoid_magnet.yaml | 31 + .../nyaml/NXsolid_geometry.yaml | 18 + contributed_definitions/nyaml/NXsource.yaml | 172 ++ .../nyaml/NXspatial_filter.nxdl.xml | 60 - .../nyaml/NXspectrum_set_em_auger.yaml | 8 + .../nyaml/NXspectrum_set_em_cathodolum.yaml | 8 + .../nyaml/NXspectrum_set_em_eels.nxdl.xml | 158 -- .../nyaml/NXspectrum_set_em_xray.nxdl.xml | 271 ---- .../nyaml/NXspin_rotator.yaml | 48 + .../nyaml/NXspindispersion.nxdl.xml | 76 - .../nyaml/NXstage_lab.nxdl.xml | 137 -- .../nyaml/NXsubsampling_filter.nxdl.xml | 26 - .../nyaml/NXtransmission.nxdl.xml | 327 ---- contributed_definitions/nyaml/NXxpcs.yaml | 465 ++++++ 255 files changed, 9357 insertions(+), 17514 deletions(-) rename contributed_definitions/{nyaml => }/NXapm_paraprobe_config_selector.nxdl.xml (62%) rename contributed_definitions/{nyaml => }/NXapm_paraprobe_results_clusterer.nxdl.xml (79%) rename contributed_definitions/{nyaml => }/NXapm_paraprobe_results_distancer.nxdl.xml (76%) rename contributed_definitions/{nyaml => }/NXapm_paraprobe_results_intersector.nxdl.xml (75%) rename contributed_definitions/{nyaml => }/NXapm_paraprobe_results_nanochem.nxdl.xml (90%) rename contributed_definitions/{nyaml => }/NXapm_paraprobe_results_selector.nxdl.xml (67%) rename contributed_definitions/{nyaml => }/NXapm_paraprobe_results_spatstat.nxdl.xml (72%) rename contributed_definitions/{nyaml => }/NXapm_paraprobe_results_surfacer.nxdl.xml (80%) rename contributed_definitions/{nyaml => }/NXapm_paraprobe_results_tessellator.nxdl.xml (86%) rename contributed_definitions/{nyaml => }/NXcg_alpha_complex.nxdl.xml (74%) rename contributed_definitions/{nyaml => }/NXchemical_composition.nxdl.xml (53%) rename contributed_definitions/{nyaml => }/NXem_ebsd.nxdl.xml (88%) rename contributed_definitions/{nyaml => }/NXem_ebsd_conventions.nxdl.xml (90%) rename contributed_definitions/{nyaml => }/NXem_ebsd_crystal_structure_model.nxdl.xml (81%) rename contributed_definitions/{nyaml => }/NXisocontour.nxdl.xml (62%) rename contributed_definitions/{nyaml => }/NXliquid_jet.nxdl.xml (57%) rename contributed_definitions/{nyaml => }/NXmpes_liquid.nxdl.xml (86%) rename contributed_definitions/{nyaml => }/NXms_dislocation_set.nxdl.xml (81%) rename contributed_definitions/{nyaml => }/NXms_interface_set.nxdl.xml (82%) rename contributed_definitions/{nyaml => }/NXsensor_scan_parsed.nxdl.xml (77%) rename contributed_definitions/{nyaml => }/NXsimilarity_grouping.nxdl.xml (83%) create mode 100644 contributed_definitions/nyaml/NXaberration.yaml create mode 100644 contributed_definitions/nyaml/NXaperture.yaml delete mode 100644 contributed_definitions/nyaml/NXaperture_em.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXatom_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXbeam.yaml delete mode 100644 contributed_definitions/nyaml/NXcalibration.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_grid.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_point_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXchamber.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXclustering.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcontainer.yaml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_computer.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_cpu.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_gpu.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_prng.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_profiling.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcsg.yaml create mode 100644 contributed_definitions/nyaml/NXcxi_ptycho.yaml delete mode 100644 contributed_definitions/nyaml/NXdeflector.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXdelocalization.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXdetector.yaml delete mode 100644 contributed_definitions/nyaml/NXdistortion.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXebeam_column.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXelectrostatic_kicker.yaml delete mode 100644 contributed_definitions/nyaml/NXellipsometry.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXem.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXentry.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_data_em.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXfabrication.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXgraph_root.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXibeam_column.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_bf.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_bse.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_chamber.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_df.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_ecci.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_kikuchi.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_se.yaml create mode 100644 contributed_definitions/nyaml/NXinstrument.yaml create mode 100644 contributed_definitions/nyaml/NXinteraction_vol_em.yaml delete mode 100644 contributed_definitions/nyaml/NXion.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXiv_temp.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXlens_em.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXmagnetic_kicker.yaml delete mode 100644 contributed_definitions/nyaml/NXmanipulator.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXmatch_filter.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXmpes.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXms_snapshot.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXorientation_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXpeak.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXpid.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXprocess.yaml delete mode 100644 contributed_definitions/nyaml/NXpulser_apm.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXpump.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXquadric.yaml create mode 100644 contributed_definitions/nyaml/NXquadrupole_magnet.yaml delete mode 100644 contributed_definitions/nyaml/NXreflectron.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXregion.yaml delete mode 100644 contributed_definitions/nyaml/NXregistration.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXsample.yaml delete mode 100644 contributed_definitions/nyaml/NXscanbox_em.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXsensor_scan.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXseparator.yaml delete mode 100644 contributed_definitions/nyaml/NXslip_system_set.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXsnsevent.yaml create mode 100644 contributed_definitions/nyaml/NXsnshisto.yaml create mode 100644 contributed_definitions/nyaml/NXsolenoid_magnet.yaml create mode 100644 contributed_definitions/nyaml/NXsolid_geometry.yaml create mode 100644 contributed_definitions/nyaml/NXsource.yaml delete mode 100644 contributed_definitions/nyaml/NXspatial_filter.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml create mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXspin_rotator.yaml delete mode 100644 contributed_definitions/nyaml/NXspindispersion.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXstage_lab.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXtransmission.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXxpcs.yaml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 0151ef8aff..1c3d7a3a0e 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -1,10 +1,31 @@ - + - + + Details of an individual aperture for beams in electron microscopy. - + Given name/alias of the aperture. @@ -21,7 +42,7 @@ in more detail. - + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. Alternatively a free-text field. diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 2e636b9d6f..ae4a598dc3 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -22,8 +43,8 @@ - Maximum number of allowed atoms per (molecular) ion (fragment). Needs - to match maximum_number_of_atoms_per_molecular_ion. + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. @@ -62,7 +83,7 @@ that specifies the application definition. - + NeXus NXDL schema to which this file conforms. @@ -70,7 +91,7 @@ - + Ideally, a (globally) unique persistent identifier for referring to this experiment. @@ -80,7 +101,7 @@ experiments to e.g. proposals. - + Free-text description about the experiment. @@ -116,7 +137,7 @@ when the microscope session ended. - + Commercial or otherwise given name to the program which was used to create the original results file of the atom probe experiment. @@ -176,7 +197,7 @@ a substantial larger number of eventually metadata that so far are not publicly documented and accessible in an open-source manner. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and @@ -186,7 +207,7 @@ - + Neither the specimen_name nor the experiment_identifier but the identifier through which the experiment is referred to in the control software. @@ -232,7 +253,7 @@ - + What type of atom probe microscopy experiment is performed. This field is primarily meant to inform materials database systems @@ -244,7 +265,7 @@ which should be specified with the atmosphere in the analysis_chamber group. * apt_fim should be used for combinations of the two imaging modes. * other should be used in combination with the user specifying details in the - experiment_documentation field. + experiment_documentation field. @@ -260,48 +281,48 @@ principle investigator who performed this experiment. Adding multiple users if relevant is recommended. - + Given (first) name and surname of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Postal address of the affiliation. - + Email address of the user at the point in time when the experiment was performed. Writing the most permanently used email is recommended. - + Globally unique identifier of the user as offered by services like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform - + Name of the OrcID or ResearcherID where the account under orcid is registered. - + (Business) (tele)phone number of the user at the point in time when the experiment was performed. - + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating @@ -309,13 +330,13 @@ are common examples. - + Account name that is associated with the user in social media platforms. - + Name of the social media platform where the account under social_media_name is registered. @@ -323,7 +344,7 @@ - + Descriptive name or ideally (globally) unique persistent identifier. The name distinguishes the specimen from all others and especially the @@ -346,7 +367,7 @@ sample history. - + Ideally, a reference to the location of or a (globally) unique persistent identifier of e.g. another file which should document @@ -380,12 +401,12 @@ better be placed in resources which describe the sample_history. - + Possibility to give an abbreviation of the specimen name field. - + List of comma-separated elements from the periodic table that are contained in the sample. @@ -397,7 +418,7 @@ these from the sample history or from other data sources. - + Discouraged free-text field in case properly designed records for the sample_history are not available. @@ -476,26 +497,26 @@ microscopy) are accelerated towards a position-sensitive and time-of-flight taking detector system. Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. + * Second, the specimen is the lens of the microscope. - + Given name of the atom probe at the hosting institution. This is an alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, etc. - + Location of the lab or place where the instrument is installed. Using GEOREF is preferred. - - - - + + + + @@ -519,29 +540,29 @@ Is a reflectron installed and was it used? - + - - - - + + + + - + A local electrode guiding the ion flight path. - + Identifier of the local_electrode in an e.g. database. - + - - + + @@ -551,7 +572,7 @@ Detector for taking raw time-of-flight and ion/hit impact positions data. - + Description of the detector type. Specify if the detector is not the usual type, i.e. not a delay-line detector. @@ -561,23 +582,23 @@ the detector type via free-text. - + Given name/alias. - + Given brand or model name by the manufacturer. - + Given hardware name/serial number or hash identifier issued by the manufacturer. - + Given name of the manufacturer. @@ -596,7 +617,7 @@ - + @@ -613,14 +634,14 @@ * name * wavelength - * energy + * energy - + - - - - + + + + @@ -640,14 +661,14 @@ - + - - - - + + + + - + Average pressure in the analysis chamber. @@ -655,14 +676,14 @@ - + - - - - + + + + - + Average pressure in the buffer chamber. @@ -670,14 +691,14 @@ - + - - - - + + + + - + Average pressure in the load_lock_chamber. @@ -685,30 +706,30 @@ - + - - - - + + + + - + - - - - + + + + - + - - - - + + + + @@ -733,7 +754,7 @@ correlative electron microscopy/atom probe experiment is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. + here is where such spatio-temporally data could be stored. @@ -786,12 +807,12 @@ groups to begin with. Holding heterogeneous, not yet standardized but relevant pieces of information is the purpose of this collection. - + Name of the control software of the microscope used during acquisition (e.g. IVAS/APSuite). - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and @@ -833,13 +854,13 @@ like the Oxcart instrument, individual timing data from the delay-line detector are openly accessible. - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -888,13 +909,13 @@ ion contains (which is instead encoded with the isotope_vector field of each NXion instance). - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -940,13 +961,13 @@ This post-processing is usually performed via GUI interaction in the reconstruction pipeline of IVAS/APSuite. - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -973,13 +994,13 @@ and nonlinearities. This step is usually performed with commercial software. - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -1037,13 +1058,13 @@ Data post-processing step in which calibrated time-of-flight data (ToF) are interpreted into mass-to-charge-state ratios. - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -1077,12 +1098,12 @@ i.e. numerical recipes how to compute x, y, z atomic positions from the input data. - + Given name of the program that was used to perform this computation. Similar comments as voltage_and_bowl_correction apply. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -1092,7 +1113,7 @@ - + Qualitative statement about which reconstruction protocol was used. @@ -1104,7 +1125,7 @@ - + Different reconstruction protocols exist. Although these approaches are qualitatively similar, each protocol uses different parameters @@ -1113,7 +1134,7 @@ in a collection. - + Different strategies for crystallographic calibration of the reconstruction are possible. The field is required and details @@ -1139,13 +1160,13 @@ of the ion density using one nanometer cubic bins without applying smoothening algorithms on this histogram. - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -1164,7 +1185,7 @@ - + Array of counts for each bin. @@ -1182,7 +1203,7 @@ - + @@ -1191,7 +1212,7 @@ - + @@ -1200,7 +1221,7 @@ - + @@ -1214,15 +1235,15 @@ * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -1254,13 +1275,13 @@ specifically these values are binned. This (NXprocess) stores the settings of this binning. - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -1291,7 +1312,7 @@ - + Array of counts for each bin. @@ -1299,7 +1320,7 @@ - + @@ -1308,7 +1329,7 @@ - + @@ -1317,13 +1338,13 @@ Details of the background model which was used to correct the total counts per bin into counts. - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -1339,13 +1360,13 @@ How where peaks in the background-corrected in the histogram of mass-to-charge-state ratio values identified? - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -1356,8 +1377,8 @@ - - + + THIS DOCSTRING NEEDS CLARIFICATION. @@ -1369,13 +1390,13 @@ Details about how peaks, with taking into account error models, were interpreted as ion types or not. - + Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -1390,7 +1411,7 @@ - + diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml index e08fe38a0e..2f44bec9a8 100644 --- a/contributed_definitions/NXapm_input_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_input_ranging.nxdl.xml @@ -1,32 +1,59 @@ - + - + + Metadata to ranging definitions made for a dataset in atom probe microscopy. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + which ideally specify the most likely ion/molecular ion evaporated within a + given mass-to-charge-state-ratio value interval. + + The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE + iontype (or unranged ions) represents the default iontype. + The ID of this special iontype is always reserved as 0. Each ion + is assigned to the UNKNOWNTYPE by default. Iontypes are assigned + by checking if the mass-to-charge-state-ratio values of an ion matches + to any of the defined mass-to-charge-state-ratio intervals. - + - Name of (NeXus)/HDF5 file which stores ranging definitions which define - how mass-to-charge-state ratios map to iontypes and which iontypes are - distinguished. The UNKNOWNTYPE iontype (unranged) is the default iontype. - The ID of this special iontype is always reserved as 0. Each ion - is assigned to the UNKNOWNTYPE by default. Iontypes are assigned - by checking if the mass-to-charge-state ratio of an ion matches - to any of the defined mass-to-charge-state ratio intervals. + Path and name of the NeXus/HDF5 file which stores ranging definitions. - + - Version identifier of the file (representing an at least SHA256) hash - which documents the binary state of the file to add an additional layer - of reproducibility for tracking provenance. + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. - + - Name of the group (prefix to the individual ranging definitions) - inside the HDF5 file which refers to the ranging definition to use. - A HDF5 file can store multiple ranging definitions. Using an ID is + Name of the group (prefix to the individual ranging definitions) inside + the file referred to by filename which points to the specific ranging + definition to use. + An HDF5 file can store multiple ranging definitions. Using an ID is the mechanism to distinguish which specific ranging (version) will be processed. Reconstruction and ranging IDs can differ. They specify different IDs. diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml index bd1b74d43e..c6d9401be5 100644 --- a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml @@ -1,37 +1,57 @@ - + - + + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. - + Name of the (NeXus)/HDF5 file which stores reconstructed ion position and mass-to-charge-state ratios. Such an HDF5 file can store multiple - reconstructions. Using an identifier (ID) is the mechanism which - paraprobe uses to distinguish which specific reconstruction will - be processed. With this design it is possible that the same HDF5 - file stores multiple versions of a reconstruction of e.g. the same - or different measured datasets, respectively. + reconstructions. Using the information within the dataset_name fields + is the mechanism whereby paraprobe decides which reconstruction to + process. With this design it is possible that the same HDF5 + file can store multiple versions of a reconstruction. - + - Version identifier of the file (representing an at least SHA256) hash - which documents the binary state of the file to add an additional layer - of reproducibility for tracking provenance. + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. - + Name of the dataset inside the HDF5 file which refers to the specific reconstructed ion positions to use for this analysis. - + Name of the dataset inside the HDF5 file which refers to the - specific mass-to-charge-state ratios to use for this analysis. + specific mass-to-charge-state-ratio values to use for this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml index 653fee81cb..c1bee3f943 100644 --- a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -1,18 +1,44 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. - + - Number of position values. + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - + - Number of disjoint cluster. + Number of clustering algorithms used. + + + + + Number of different iontypes to distinguish during clustering. @@ -25,7 +51,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -33,12 +59,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -48,29 +74,29 @@ - + - Ideally, a (globally persistent) unique identifier for referring - to this analysis. + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. - + - Possibility for leaving a free-text description about this analysis. + Ideally, a (globally persistent) unique identifier for referring + to this analysis. - + - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. + Possibility for leaving a free-text description about this analysis. - How many clustering processes should the tool execute. + How many tasks to perform? - + This process maps results from cluster analyses performed with IVAS/APSuite into an interoperable representation. Specifically in this process @@ -96,122 +122,30 @@ clusters start at 1. - - + + - - - - - - + + + + AMETEK/Cameca results of cluster analyses, like with the maximum- + separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ + are stored as an improper POS file: This is a matrix of floating + point quadruplets, one for each ion and as many quadruplets as + ions were investigated. The first three values encode the position + of the ion. The fourth value is an improper mass-to-charge-state-ratio + value which encodes the integer identifier of the cluster as a floating + point number. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Name of HDF5 file which stores reconstructed ion positions. - This file should have been generated by from the community or vendor format. - This file not necessarily contains all the of the dataset because - spatial filters might have been applied in commercial software prior - to executing the cluster analysis so that e.g. only positions within a - ROI are reported by the commercial software. - POS files from IVAS have to be converted first. - - - - - Name of the dataset inside the HDF5 file ion_position_filename - which refers to the specific positions to use for this analysis. - The referred to dataset has to be formatted as an array of shape - (n_positions, 3). - - - - - Name of the HDF5 file which stores mass-to-charge-state-ratio values - (in the case of IVAS/APSuite) or other numbers which can be interpreted - as cluster labels. - - - - - Name of the dataset inside the HDF5 file cluster_indices_filename - which refers to the specifically encoded cluster indices. - The referred to dataset has to be formatted as an array of shape - (n_positions, 1). - - - - - The list of all keywords of a dictionary which maps implicit cluster - indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - - - - - - - - The list of all values of a dictionary which maps implicit cluster - indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - The sequences of mapping_dictionary_keyword and mapping_dictionary_value - have to match. - - - - - - + Specifies if the tool should try to recover for each position the closest matching position from dataset/dataset_name_reconstruction (within floating point accuracy). This can be useful for instance when users - wish to recover the original evaporation ID which IVAS/AP Suite drops - for instance when writing their *.indexed.* cluster results files. - - - - - Specifies if the tool should try to recover, after a recovery of the - evaporation IDs a bitmask which identifies which of the positions - in dataset/dataset/dataset_name_reconstruction where covered - by the IVAS/APSuite cluster analysis. This can be useful to recover - the region of interest. + wish to recover the original evaporation ID, which IVAS/AP Suite drops + for instance when writing their *.indexed.* cluster results POS files. @@ -221,20 +155,47 @@ or a portion of the reconstruction. - - + + - - + + - - + + + + + + + + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + - - + + + + + @@ -267,17 +228,203 @@ - + - Name of the algorithm. + How should iontypes be interpreted/considered during the cluster analysis. + Different options exist how iontypes are interpreted (if considered at all) + given an iontype represents in general a (molecular) ion with different isotopes + that have individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + This is relevant as in atom probe we have the situation that a ion + of a molecular ion with more than one nuclid, say Ti O for example + is counted such that although there is a single TiO molecular ion + at a position that the cluster has two members. This multiplicity + affects the size of the feature and chemical composition. + + + - + - A text representation like a JSON/YAML dictionary with the - parameter of the clustering_algorithm. + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + Settings for DBScan clustering algorithm. For original details about the + algorithms and (performance-relevant) details consider: + + * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ + * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + As an example we may define eps with ten entries and min_pts with + three entries. If high_throughput_method is tuple the analysis is + invalid as we have an insufficient number of min_pts for the ten + eps values. + By contrast, for combinatorics paraprobe-clusterer will run three + individual min_pts runs for each eps value, resulting in a total + of 30 analyses. + As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ + would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) + eps values, min_pts one, and high_throughput_method set to combinatorics. + + + + + + + + + Array of epsilon (eps) parameter values. + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + + Settings for the OPTICS clustering algorithm. + + * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + Array of maximum epsilon (eps) parameter values. + + + + + + + + + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ + * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + + + + + + + + + Array of min_cluster_size parameter values. + + + + + + + + Array of min_samples parameter values. + + + + + + + + Array of cluster_selection parameter values. + + + + + + + + Array of alpha parameter values. + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml index 3d4bff927a..ffb71a285c 100644 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -15,7 +36,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -23,12 +44,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -44,17 +65,24 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + How many individual analyses should the tool execute. @@ -62,20 +90,20 @@ - - + + - - + + - - + + - + - + @@ -155,12 +183,12 @@ List of triangle sets. This design allows users to combine multiple triangle sets. - + Name of the HDF5 file(s) which contain(s) vertex coordinates and facet indices to describe the desired set of triangles. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional @@ -168,19 +196,19 @@ - + Absolute HDF5 path to the dataset which specifies the array of vertex positions. - + Absolute HDF5 path to the dataset which specifies the array of facet indices. - + Absolute HDF5 path to the dataset which specifies the array of facet normal vectors. @@ -188,7 +216,7 @@ - + Specifies for which ions/points the tool will compute distances. The purpose of this setting is to avoid unnecessary computations @@ -212,5 +240,8 @@ + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml index 1a678869c8..5dcd3fa915 100644 --- a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml @@ -1,15 +1,31 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. - - - How many elements to use for computing a composition. - - Configuration of a paraprobe-intersector tool run in atom probe microscopy. @@ -20,7 +36,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -28,12 +44,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -43,90 +59,29 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. - - - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - - - - - Specifies the method to use which decides if two objects intersect. - For reasons which are detailed in the supplementary material of - `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by - default assumes that two objects intersect if they share at least one - ion with the same evaporation ID - (shared_ion). Alternatively, with specifying tetrahedra_intersections, - the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks - for at least one pair of intersecting tetrahedra to identify if two objects - intersect or not. - - However, we found that these geometrical analyses can result in corner - cases which the currently used library (TetGen) was not unable to - tetrahedralize successfully. These cases were virtually always - associated with complicated non-convex polyhedra - which had portions of the mesh that were connected by almost point like - tubes of triangles. - - - - - - - - - Specifies if the tool should load the volume of each object - (if existent in the input file) to characterize the evolution of the - objects' volume as a function of set identifier (e.g. time). - - This and the has_object_composition option enables to activate - computations in the code which correlate the spatio-temporal tracking - with an object's properties. This is useful to explore/understand how - the object descriptor values evolve as a function of the parameterization - of the object. To arrive at a detailed understanding and quantification - of the differences of a given object as a function of delocalization and - e.g. iso-surfacing settings. - - The point made in M. Kühbach et al. 2022, is that this functionality - can be used to track for instance how the accumulated volume and - composition of an object depends on its segmentation via iso-surfaces. - The benefit of such computations is that users can inspect the - parameter sensitivity of an objects representation rigorously. - - - + - Specifies if the tool should load the composition of each object - (if existent in the input file) to characterize the evolution of the - object's composition as a function of set identifier. See the description - of has_object_volume for further details. In M. Kühbach et al. 2022, both - has_object options were used to characterize e.g. the parameter - sensitivity of computed composition, volume, and shape specifically, - for a carbide that was segmented via different carbon iso-composition - values. + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. - + - List of np.uint16 elements, via their proton number. The whitelist is - evaluated to compute the composition of an object during tracking - when has_object_composition is set to true. + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. - - - @@ -134,47 +89,143 @@ analyses the tool should execute as part of the analysis. - - + + + Tracking volume_volume_spatial_correlation is the process of building logical + relations between volumetric features based on meshes, their proximity and + eventual intersections. Volumetric overlap and proximity of volumetric + features is identified for members of sets of features to members of + other sets of volumetric features. + Specifically, for each time step k pairs of sets are compared: + Members of a so-called current_set to members of a so-called next_set. + Members can be different types of volumetric features. + In the analysis of M. Kuehbach et al. specifically features can be + so-called objects (closed non-degnerated polyhedra representing watertight + parts of an e.g. iso-surface) and/or proxies. Proxies are computed + doppelganger/replacement meshes for parts of an iso-surface which initially + were not resulting in watertight meshes because objects at the edge + of the dataset or incompletely measured or truncated objects. + + + + Specifies the method whereby to decide if two objects intersect volumetrically. + For reasons which are detailed in the supplementary material of + `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by + default assumes that two objects intersect if they share at least one + ion with the same evaporation ID (shared_ion). + Alternatively, with specifying tetrahedra_intersections, + the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks + for at least one pair of intersecting tetrahedra to identify if two objects + intersect or not. + + However, we found that these geometrical analyses can result in corner + cases which the currently used library (TetGen) was not unable to + tetrahedralize successfully. These cases were virtually always + associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + Finding more robust methods for computing intersections between + not necessarily convex polyhedra might improve the situation in the future. + + + + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) intersect volumetrically. + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) lie closer to one another than the + threshold_proximity. + + + + + Specifies if the tool evaluates, ones all tracking tasks were + successfully completed, how intersecting or proximity related + objects build sub-graphs. This is the feature which enabled + M. Kühbach et al. 2022 the high-throughput analyses of how many + objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order. For these analyses to work + has_object_volume needs to be activated. + + + + + The maximum Euclidean distance between two objects below which + both objects are still considered within proximity. + + + + + Specifies if the tool stores the so-called forward relations between + nodes representing members of the current_set to nodes representing + members of the next_set. + + + - For now a support field for the tool to identify how many individual - analyses (i. e. individual current_to_next mappings) the tool should - perform as part of the high-throughput analysis. + Specifies if the tool stores the so-called backward relations between + nodes representing members of the next_set to nodes representing + members of the current_set. - + - Tracking is the process of building logical relations between objects - based on proximity and mesh intersections. For each time step pairs - of sets are compared: members of a current_set and a next_set. - Members have to be objects and eventually can in addition be so-called - proxies. Objects and proxies are non-degenerated closed polyhedra which - are not necessarily convex. Proxies are doppelganger/replacement - meshes of objects which would otherwise be impossible to describe - with a closed mesh. + Current set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the current_set. + The meshes were generated as a result of some other meshing process. - + - Current set stores a set of object geometries that should be checked - for proximity and/or intersection with member of the next_set. + This identifier can be used to label the current set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in M. Kühbach + et al. 2022, this identifier takes the role of the time variable k. - + + + + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + current_set. + + + + - This identifier can be used to label the current set. The label - effectively represents the time/iteration step when the current - set was taken. As it is detailed in M. Kühbach et al. 2022, - this identifier takes the role of the time variable k. + Descriptive category explaining what these features are. + + + + + + - + - Name of the HDF5 file which contain geometry (vertex coordinates, - facet indices) and properties (ions, composition) of polyhedra - (l objects) which should be included in the current set. - The user has to ensure that the datasets under list_of_dataset_names - (vertices, facet_indices, ions) exist and are formatted consistently. + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of @@ -182,86 +233,71 @@ - - - Paraprobe-intersector loads triangulated surface mesh data of a - set of objects. For each object its mesh is expected to have - three-dimensional position data of the unique vertices and a - matrix of vertex indices which describe the faces. - As each object has to be a polyhedron/closed surface mesh, this - matrix has as many rows as faces, i.e. triangles and three columns. - Vertex indices have to start at zero. - - - - - The default intersection detection method uses shared ions. - Therefore, it is necessary to specify where the results from the - paraprobe-nanochem tool run are located which document which ions - (with their evaporation IDs) are inside or on the surface of each - object. This field points the tool to these evaporation IDs. - - - - - In order to correlate object properties like volume and composition - with tracking data, it is necessary to specify where the results - (object properties) from the paraprobe-nanochem tool run are located. - This field instructs the tool where to load these object property data - from. - - - - - Paraprobe-intersector does not just compare two objects but a set - of sets of objects. This field instructs the tool where to load - the identifiers (names) of each object in a current_set or next_set - respectively from. - - - - - Like groupname_object_geometry_data but for the proxies. - Triangulated surface meshes of proxies have to be formatted - in the same manner as objects. - - - + - Like groupname_proxy_supplementary_data but for the interior proxies. - Leave an empty string if proxies should not be used. + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object<ID>/polyhedron. - + - Like groupname_proxy_supplementary_data but for the exterior proxies. - Leave an empty string if proxies should not be used. + Array of identifier whereby the path to the geometry data + can be interferred automatically. - + + + + Next set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the next_set. + The meshes were generated as a result of some other meshing process. + + - Next set stores a set of object geometries that should be checked - for proximity and/or intersection with (each) member(s) of the - current_set. + This identifier can be used to label the next_set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in M. Kühbach + et al. 2022, this identifier takes the role of the time variable k+1. + + + + + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + next_set. - + + + - This identifier can be used to label the next set. Like for the current_set - the identifier is effectively the time/iteration step when the next set was taken. - As it is detailed in M. Kühbach et al. 2022, this identifier - takes the role of the time variable k+1. + Descriptive category explaining what these features are. + + + + + + - + - Name of the HDF5 file which contain geometry (vertex coordinates, - facet indices) and properties (ions, composition) of - polyhedra(l objects) which should be included in the current set. - The user has to ensure that the datasets that are referred to - under list_of_dataset_names (vertices, facet_indices, ions). + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of @@ -269,119 +305,23 @@ - - - Paraprobe-intersector loads triangulated surface mesh data of a - set of objects. For each object its mesh is expected to have - three-dimensional position data of the unique vertices and a - matrix of vertex indices which describe the faces. - As each object has to be a polyhedron/closed surface mesh - this matrix has as many rows as faces, i.e. triangles and - three columns. Vertex indices have to start at zero. - - - - - The default intersection detection method uses shared ions. - Therefore, it is necessary to specify where the results from the - paraprobe-nanochem tool run are located which document which ions - (with their identifiers) are inside or on the surface of each object. - This field instructs the tool where to load these - ion evaporation ids from. - - - - - In order to correlate object properties like volume and composition - with tracking data, it is necessary to specify where the results - (object properties) from the paraprobe-nanochem tool run are located. - This field instructs the tool where to load these object property - data from. - - - - - Paraprobe-intersector does not just compare two objects but a set - of sets of objects. This field instructs the tool where to load - the identifiers (names) of each object in a current or next set - respectively from. - - - - - Like groupname_object_geometry_data but for the proxies. - Triangulated surface meshes of proxies have to be formatted - in the same manner. Leave an empty string if proxies should not - be used. - - - + - Like groupname_proxy_supplementary_data but for the interior proxies. - Leave an empty string if proxies should not be used. + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object<ID>/polyhedron. - + - Like groupname_proxy_supplementary_data but for the exterior proxies. - Leave an empty string if proxies should not be used. + Array of identifier whereby the path to the geometry data + can be interferred automatically. - - - Specifies if, in the case of small finite datasets, objects which are - located at the edge of the dataset should be accounted for or not. - If these so-called proxy/doppelganger objects are accounted for, the - respective groupname_proxy and dataset_proxy fields have to be - filled to tell the tool where to load which proxy meshes from. - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) intersect volumetrically. - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) lie closer to one another than the - threshold_proximity. - - - - - Specifies if the tool evaluates, ones all tracking tasks were - successfully completed, how intersecting or proximity related - objects build sub-graphs. This is the feature which enabled - M. Kühbach et al. 2022 the high-throughput analyses of how many - objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order. For these analyses to work - has_object_volume needs to be activated. - - - - - The maximum Euclidean distance between two objects below which - both objects are still considered within proximity. - - - - - Specifies if the tool stores the so-called forward relations between - nodes representing members of the current_set to nodes representing - members of the next_set. - - - - - Specifies if the tool stores the so-called backward relations between - nodes representing members of the next_set to nodes representing - members of the current_set. - - + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml index 9befaccc86..cc54d8b3c7 100644 --- a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -40,7 +61,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -48,12 +69,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -63,17 +84,24 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + ISO 8601 formatted time code with local time zone offset to @@ -87,20 +115,20 @@ - - + + - - + + - - + + - + - + @@ -132,7 +160,7 @@ - + @@ -143,13 +171,13 @@ the edge of the dataset. This model can be used to detect and control various sources of bias in the analyses. - + Name of the HDF5 file which contains vertex coordinates and facet indices to describe the desired set of triangles which represents the edge of the dataset. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of @@ -157,13 +185,13 @@ - + Absolute path to the HDF5 dataset in the respectively specified HDF5 file under filename which details the array of vertex positions. - + Absolute path to the HDF5 dataset in the respective specified HDF5 file under filename which details the array of facet indices. @@ -175,11 +203,11 @@ The tool enables to inject precomputed distance information for each point/ion which can be used for further post-processing and analysis. - + Name of an HDF5 file which contains the ion distances. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of @@ -187,7 +215,7 @@ - + Absolute HDF5 path to the dataset with distance values for each ion. @@ -204,7 +232,7 @@ Discretization of the ion point cloud on a three-dimensional grid. - + Delocalization in the field of atom probe microscopy is the process of discretizing a point cloud. By default the tool computes a full @@ -278,7 +306,7 @@ Variance of the Gaussian Ansatz kernel sigma_x = sigma_y = 2*sigma_z. - + How should the results of the kernel-density estimation be computed into quantities. By default the tool computes the total number @@ -304,7 +332,7 @@ to identify for instance objects in the microstructure (line features, interfaces, precipitates). - + As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., the handling of triangles at the edge of the dataset requires @@ -385,7 +413,7 @@ * total, total number of ions, irrespective their iontype * candidates, total number of ions with type in the isotope_whitelist. * composition, candidates but normalized by composition, i.e. at.-% - * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 @@ -569,7 +597,7 @@ Analyses of interfacial excess. - + Interfacial excess computations are performed for local regions-of-interests (ROIs) at selected facets or interface patch. @@ -656,7 +684,7 @@ gradient detectable across the interface. It is then the users' responsibility to deliver a triangle mesh of the interface model. - + Filename to HDF5 file which contain vertex coordinates, facet indices, facet unit normals. The user is responsible for the triangle @@ -672,7 +700,7 @@ must not exceed Nvertices - 1, i.e. the identifier_offset is 0 and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional @@ -681,25 +709,25 @@ - + Absolute HDF5 path to the dataset which specifies the array of vertex positions. - + Absolute HDF5 path to the dataset which specifies the array of facet indices. - + Absolute HDF5 path to the dataset which specifies the array of facet signed unit normals. - + Absolute HDF5 path to the dataset which specifies the array of vertex signed unit normals. @@ -751,7 +779,7 @@ resulting DCOM mesh. This is what paraprobe-nanochem implements via the Computational Geometry Algorithms Library. - + Method how to initialize the PCA: @@ -769,11 +797,11 @@ - + The name of the control point file to use. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional @@ -792,7 +820,7 @@ - + Method used for identifying and refining the location of the interface. Currently, paraprobe-nanochem implements a PCA followed @@ -914,13 +942,13 @@ soup or mesh data. Such a mesh can be the model for a grain- or phase boundary patch (from e.g. interface_meshing) jobs. - + Name of the HDF5 file which contains vertex coordinates and facet indices to describe the desired set of triangles which represents the feature. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of @@ -928,36 +956,40 @@ - + Absolute path to the HDF5 dataset in the respectively specified HDF5 file under filename which details the array of vertex positions. - + Absolute path to the HDF5 dataset in the respective specified HDF5 file under filename which details the array of facet indices. - + Absolute path to the HDF5 dataset in the respective specified HDF5 file under filename which details consistently oriented facet normals of the facets. + + + + The tool enables to inject precomputed distance information for each point which can be used for further post-processing and analysis. - + Name of an HDF5 file which contains ion distances. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional @@ -966,13 +998,13 @@ - + Absolute HDF5 path to the dataset with distance values for each ion. - + Which type of distance should be reported for the profile. @@ -980,7 +1012,7 @@ - + In which directions should the tool probe for each ROI. @@ -1001,5 +1033,8 @@ + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml index 7752e4bf94..62550c5fdf 100644 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -1,14 +1,35 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. - The number of isotopes to consider as building blocks for searching - molecular ions. + The number of isotopes to consider as building blocks for searching molecular + ions. @@ -26,7 +47,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -34,12 +55,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -55,17 +76,24 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + How many task to perform? @@ -84,22 +112,22 @@ the tool execute as part of the analysis. - + - - + + - - + + - - + + - + - + @@ -243,6 +271,17 @@ + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml similarity index 62% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_selector.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml index 0af1328cc9..bb3799a57a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -15,7 +36,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -23,12 +44,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -38,13 +59,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -60,7 +81,7 @@ How many roi_selection processes should the tool execute. - + This process identifies which of the points/ions in the datasets are inside or on the surface of geometric primitives and meet optionally @@ -70,47 +91,47 @@ shape. - - + + - - + + - - + + - + - - + + - + - + - + - - + + - - + + diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml index 32c1051c19..f60ce3566f 100644 --- a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,7 +51,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -38,12 +59,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -53,17 +74,24 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + ISO 8601 formatted time code with local time zone offset to UTC @@ -78,20 +106,20 @@ - - + + - - + + - - + + - + - + @@ -130,12 +158,12 @@ representation of the edge of the dataset which can be used to control and substantially reduce edge effects when computing spatial statistics. - + Name of an HDF5 file which contains ion-to-edge distances. - + Absolute HDF5 path to the dataset with the ion-to-edge distance values for each ion. @@ -144,6 +172,22 @@ and dataset_name_mass_to_charge respectively. + + + Threshold to define how large an ion has to lay at least far away + from the edge of the dataset so that the ion can act as a source, + i.e. that an ROI is placed at the location of the ion and its + neighbors are analyzed how they contribute to the computed statistics. + + The ion_to_edge_distances threshold can be combined with a threshold + for the ion_to_feature_distances. + Specifically, if ion_to_feature_distances are loaded an ion only + acts as a source if both threshold criteria are met. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + + @@ -152,133 +196,160 @@ to a sub-set of ions within a distance not farther away to a feature than a threshold value. - + Name of an HDF5 file which contains ion-to-feature distances. - + Absolute HDF5 path to the dataset with the ion-to-feature distance values for each ion. - - - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - - - - - - - - + - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. + Recall that the ion_to_feature_distances threshold is combined + with the ion_to_edge_distances threshold. - - - - - - - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - - - - - - - - - - + + + + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + + + + + + + + + + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + + + + + + + + + Specifies which spatial statistics to compute. + + - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. + Compute k-th nearest neighbour statistics. - - - - - - + + + Order k. + + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + - Specifies which spatial statistics to compute. + Compute radial distribution function. - + - Compute k-th nearest neighbour statistics. + Minimum value, increment, and maximum value of the histogram binning. - - - Order k. - - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml index b73134ac33..e498d88448 100644 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -10,6 +31,11 @@ Number of alpha values (and offset values) to probe. + + + How many different match values does the filter specify. + + Configuration of a paraprobe-surfacer tool run in atom probe microscopy. @@ -20,7 +46,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -28,12 +54,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -49,17 +75,24 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + For now a support field for the tool to identify how many individual @@ -68,20 +101,20 @@ - - + + - - + + - - + + - + - + @@ -111,11 +144,31 @@ - - - + + + + + + + + + + + + + + + + + + + + + + + - + Specifies the method that is used to preprocess the point cloud. The main purpose of this setting is to specify whether the point @@ -145,11 +198,16 @@ edge of the point cloud. - + Specifies which method to use to define the alpha value. - By default, the tool uses a fast specialized algorithm for - computing only the convex hull. + The value convex_hull_naive is the default. This instructs the tool + to use a fast specialized algorithm for computing only the convex + hull. The resulting triangles can be skinny. + + The value convex_hull_refine computes first also a convex_hull_naive + but refines the mesh by triangle flipping and splitting to improve + the quality of the mesh. The value smallest_solid instructs the CGAL library to choose a value which realizes an alpha-shape that is the smallest solid. @@ -169,7 +227,8 @@ resulting wrapping. - + + @@ -215,5 +274,8 @@ + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml index 76357a0ed6..d186fa3476 100644 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -15,7 +36,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -23,12 +44,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -38,17 +59,24 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + ISO 8601 formatted time code with local time zone offset to UTC @@ -62,20 +90,20 @@ - - + + - - + + - - + + - + - + @@ -113,13 +141,13 @@ The tool enables to inject precomputed distance information for each point which can be used for further post-processing and analysis. - + Name of an HDF5 file which contains the ion distances. Users are responsible this file and referred to dataset under dataset_name have an ion_distance value for each ion. - + Version identifier of the file such as a secure hash which documents the binary state of the file to add an additional layer of @@ -127,14 +155,14 @@ - + Absolute HDF5 path to the dataset with distance values for each ion. - + Specifies for which points the tool will compute the tessellation. By default, a Voronoi tessellation is computed for all ions in the @@ -176,5 +204,8 @@ + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml index d2f823505c..d7f66157d7 100644 --- a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,13 +30,13 @@ Configurations of a paraprobe-transcoder tool run in atom probe microscopy. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -23,32 +44,39 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. + of ideally an ever persistent resource where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this computational + process is recreatable deterministically. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + ISO 8601 formatted time code with local time zone offset to UTC @@ -57,39 +85,30 @@ - + - The absolute path and name of the vendor or community file from which - to read the reconstructed ion positions. Currently POS, ePOS, and APT - files from APSuite are supported. + The path and name of the file (technology partner or community format) + from which to read the reconstructed ion positions. Currently, POS, + ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files + are supported. - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - + - + - The absolute path and name of the vendor or community file from which - to read the ranging definitions, i.e. how to map mass-to-charge-state - ratios on iontypes. Currently RRNG and RNG files are supported. + The path and name of the file (technology partner or community format + from which to read the ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. + NeXus/HDF5 files are supported. - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml similarity index 79% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml index 8fd679a516..a6214b3e6b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -19,13 +40,13 @@ Results of a paraprobe-clusterer tool run. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -33,12 +54,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -48,13 +69,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -73,18 +94,18 @@ were completed and the paraprobe-tool executable exited as a process. - + The absolute path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. - + Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the @@ -108,21 +129,21 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + @@ -132,7 +153,7 @@ paraprobe defined, which specifies the coordinate system. In which all positions are defined. - + The individual coordinate systems which should be used. Field names should be prefixed with the following controlled terms @@ -148,7 +169,7 @@ - + A bitmask which identifies which of the ions in the dataset were @@ -184,7 +205,7 @@ - + The result of a cluster analyses. These include typically the label for each ion/point documenting to which feature (if any) an ion is assigned. @@ -192,7 +213,7 @@ In cases of fuzzy clustering it can be possible that an ion is assigned to multiple cluster (eventually with different) weight/probability. - + Results of a DBScan clustering analysis. @@ -262,7 +283,7 @@ - + The array of weight which specifies how surely/likely the cluster is associated/assigned to a specific identifier as @@ -277,7 +298,7 @@ - + Optional bitmask encoding if members of the set are assigned to as noise or not. @@ -285,7 +306,7 @@ - + Optional bitmask encoding if member of the set are a core point. For details to which feature/cluster an ion/point is a core point @@ -335,53 +356,53 @@ - - - - - + + + + + - - - - + + + + - - - - - - + + + + + + - - - - - + + + + + - + - - - + + + - - - - + + + + - - - + + + @@ -401,8 +422,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml similarity index 76% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml index a32c6b8d1f..8ca1655e15 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -19,13 +40,13 @@ Results of a paraprobe-distancer tool run. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -33,12 +54,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -48,13 +69,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -73,18 +94,18 @@ were completed and the paraprobe-tool executable exited as a process. - + The absolute path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. - + Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the @@ -108,27 +129,27 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + Details about the coordinate system conventions used. - + The individual coordinate systems which should be used. Field names should be prefixed with the following controlled terms @@ -144,7 +165,7 @@ - + The tool can be used to compute the analytical distance of each ion @@ -230,7 +251,7 @@ - + A bitmask which identifies which of the distance values can be assumed to have a consistent sign because the closest @@ -260,7 +281,7 @@ - + The identifier of the triangle that is closest for each ion. @@ -268,7 +289,7 @@ - + A support field to visualize each ion and with this the distance informations using XDMF and e.g. Paraview. @@ -279,53 +300,53 @@ - - - - - + + + + + - - - - + + + + - - - - - - + + + + + + - - - - - + + + + + - + - - - + + + - - - - + + + + - - - + + + @@ -345,8 +366,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml similarity index 75% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml index e747b8b5a1..83085fa9eb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -45,7 +66,7 @@ Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -53,12 +74,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -68,13 +89,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -85,45 +106,45 @@ information included when this results file was created. - + The absolute path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. - + Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + - + Details about the coordinate system conventions used. - + The individual coordinate systems which should be used. Field names should be prefixed with the following controlled terms @@ -140,7 +161,7 @@ - + The results of an overlap/intersection analysis. @@ -165,7 +186,7 @@ - + A matrix of feature_identifier which specifies which named feature(s) from the next set have directed link(s) pointing to which named @@ -178,7 +199,7 @@ - + For each link/pair in next_to_current a characterization whether the link is due to a volumetric overlap (0x00 == 0), @@ -188,7 +209,7 @@ - + For each pair of links in current_to_next the volume of the intersection, i.e. how much volume do the two features share. @@ -198,7 +219,7 @@ - + During coprecipitation analysis the current and next set are analyzed for links in a special way. Three set comparisons are made. Members @@ -281,53 +302,53 @@ - - - - - + + + + + - - - - + + + + - - - - - - + + + + + + - - - - - + + + + + - + - - - + + + - - - - + + + + - - - + + + @@ -347,8 +368,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml similarity index 90% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index abf2722d3f..2857ae7904 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -17,8 +38,7 @@ - The total number of isotopes in the isotopic_decomposition match - filter. + The total number of isotopes in the isotopic_decomposition match filter. @@ -28,14 +48,12 @@ - The cardinality/total number of cells/grid points in the - delocalization grid. + The cardinality/total number of cells/grid points in the delocalization grid. - The total number of XDMF values to represent all faces of triangles - via XDMF. + The total number of XDMF values to represent all faces of triangles via XDMF. @@ -52,13 +70,13 @@ Results of a paraprobe-nanochem tool run. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -66,12 +84,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -81,13 +99,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -106,18 +124,18 @@ were completed and the paraprobe-tool executable exited as a process. - + The absolute path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. - + Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the @@ -141,21 +159,21 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + @@ -165,7 +183,7 @@ paraprobe defined, which specifies the coordinate system. In which all positions are defined. - + The individual coordinate systems which should be used. Field names should be prefixed with the following controlled terms @@ -181,7 +199,7 @@ - + A bitmask which identifies which of the ions in the dataset were @@ -217,9 +235,9 @@ - + - + The weighting model specifies how mark data are mapped to a weight per point/ion. For atom probe microscopy (APM) mark data are e.g. @@ -239,7 +257,7 @@ - + A list of elements (via proton number) to consider for the atomic_decomposition weighting model. @@ -252,7 +270,7 @@ that for elements the proton number is their hash value because N is zero. - + Meaning of the filter: Whitelist specifies which entries with said value to include. @@ -278,7 +296,7 @@ - + A list of isotopes (via proton and neutron number) to consider for the isotopic_decomposition weighting model. @@ -287,7 +305,7 @@ hashing rule $H = Z + 256*N$ with $Z$ the number of protons and $N$ the number of neutrons of the isotope. - + Meaning of the filter: Whitelist specifies which entries with said value to include. @@ -328,7 +346,7 @@ - + Weighting factor, in atom probe, often termed multiplicity. The weighting factor is the multiplier with which the integrated @@ -365,7 +383,7 @@ - + The symmetry of the lattice defining the shape of the unit cell. @@ -395,7 +413,7 @@ - + Reference to or definition of a coordinate system with which the positions and directions are interpretable. @@ -495,7 +513,7 @@ - + How many distinct boundaries are distinguished? Most grids discretize a cubic or cuboidal region. In this case @@ -503,7 +521,7 @@ - + Name of the boundaries. E.g. left, right, front, back, bottom, top, The field must have as many entries as there are number_of_boundaries. @@ -512,7 +530,7 @@ - + The boundary conditions for each boundary: @@ -571,7 +589,7 @@ - + Intensity of the field at given point @@ -579,7 +597,7 @@ - + Center of mass positions of each voxel for rendering the scalar field via XDMF in e.g. @@ -590,7 +608,7 @@ - + XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDFM in e.g. Paraview. @@ -603,7 +621,7 @@ The three-dimensional gradient nabla operator applied to - scalar_field_magnitude. + scalar_field_magnitude. @@ -643,7 +661,7 @@ - + The gradient vector. @@ -652,7 +670,7 @@ - + Center of mass positions of each voxel for rendering the scalar field via XDMF in e.g. @@ -663,7 +681,7 @@ - + XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDFM in e.g. Paraview. @@ -702,7 +720,7 @@ - + An iso-surface is the boundary between two regions across which the magnitude of a scalar field falls below/exceeds a threshold @@ -726,7 +744,7 @@ which was taken to compute the iso-surface. The grid is the delocalization grid. - + Reference to the specific implementation of marching cubes used. The value placed here should be a DOI. If there are no specific @@ -736,7 +754,7 @@ - + The resulting triangle soup computed via marching cubes. @@ -822,7 +840,7 @@ - + Direction of each normal. @@ -832,7 +850,7 @@ - + Qualifier how which specifically oriented normal to its primitive each normal represents. @@ -846,7 +864,7 @@ - + Direction of each normal. @@ -856,7 +874,7 @@ - + Qualifier how which specifically oriented normal to its primitive each normal represents. @@ -895,12 +913,12 @@ - + - + Array of edge length values. For each triangle the edge length is reported for the edges traversed according to the sequence @@ -911,7 +929,7 @@ - + Array of interior angle values. For each triangle the angle is reported for the angle opposite to the edges which are @@ -923,7 +941,7 @@ - + The center of mass of each triangle. @@ -933,7 +951,7 @@ - + Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. Paraprobe-nanochem can run @@ -969,7 +987,7 @@ - + The array of keywords of feature_type dictionary. @@ -977,7 +995,7 @@ - + The array of values for each keyword of the feature_type dictionary. @@ -1005,7 +1023,7 @@ - + Details for features which are (closed) objects. Identifier have to exist in feature_identifier @@ -1021,11 +1039,11 @@ - + An oriented bounding box (OBB) to each object. - + Edge length of the oriented bounding box from largest to smallest value. @@ -1035,7 +1053,7 @@ - + Oriented bounding box aspect ratio. YX versus ZY. @@ -1044,7 +1062,7 @@ - + Position of the geometric center, which often is but not necessarily has to be the center_of_mass of the @@ -1079,7 +1097,7 @@ - + Details for all those objects close to edge, i.e. those which have at least one ion which lays closer to a modelled edge @@ -1095,7 +1113,7 @@ - + Total (count) relevant for normalization. @@ -1104,7 +1122,7 @@ - + @@ -1120,7 +1138,7 @@ - + @@ -1150,7 +1168,7 @@ - + Array of evaporation_identifier / ion_identifier which specify ions laying inside or on the surface of the feature. @@ -1162,7 +1180,7 @@ - + Details for all those objects far from edge, i.e. those whose ions lay all at least threshold distant from a @@ -1178,7 +1196,7 @@ - + Total (count) relevant for normalization. @@ -1187,7 +1205,7 @@ - + @@ -1203,7 +1221,7 @@ - + @@ -1233,7 +1251,7 @@ - + Array of evaporation_identifier / ion_identifier which specify ions laying inside or on the surface of the feature. @@ -1246,7 +1264,7 @@ - + Details for features which are so-called proxies, i.e. objects which have been reconstructed and combinatorially closed with @@ -1265,7 +1283,7 @@ - + Details for those proxies close to edge, i.e. those which have at least one ion which lays closer to a modelled edge @@ -1283,7 +1301,7 @@ - + Total (count) relevant for normalization. @@ -1292,7 +1310,7 @@ - + Count or weight which, when divided by total @@ -1305,7 +1323,7 @@ - + @@ -1335,7 +1353,7 @@ - + Array of evaporation_identifier / ion_identifier which specify ions laying inside or on the surface of the feature. @@ -1347,7 +1365,7 @@ - + Details for those proxies far from edge, i.e. those whose ions lay all at least threshold distant from a @@ -1363,7 +1381,7 @@ - + Total (count) relevant for normalization. @@ -1372,7 +1390,7 @@ - + Count or weight which, when divided by total @@ -1385,7 +1403,7 @@ - + @@ -1415,7 +1433,7 @@ - + Array of evaporation_identifier / ion_identifier which specify ions laying inside or on the surface of the feature. @@ -1433,8 +1451,8 @@ - - + + The multiplicity whereby the ion position is accounted for irrespective whether the ion is considered as a decorator @@ -1444,7 +1462,7 @@ - + The multiplicity whereby the ion position is accounted for when the ion is considered´one which is a decorator @@ -1454,7 +1472,7 @@ - + The equation of the plane that is fitting initially. @@ -1467,7 +1485,7 @@ - + The triangle surface mesh representing the interface model. Exported at some iteration before the next DCOM step. @@ -1585,7 +1603,7 @@ - + The triangle surface mesh representing the interface model. Exported at some iteration after the next DCOM step. @@ -1703,7 +1721,7 @@ - + The ROIs are defined as cylinders for the computations. @@ -1733,13 +1751,13 @@ - - + + - + The number of atoms in each ROI. @@ -1747,7 +1765,7 @@ - + The number of ions in each ROI. @@ -1755,7 +1773,7 @@ - + The orientation of the ROI defined via a vector which points along the cylinder axis and whose length is the height of the cylinder. @@ -1765,7 +1783,7 @@ - + In the direction of the ROI. @@ -1780,53 +1798,53 @@ - - - - - + + + + + - - - - + + + + - - - - - - + + + + + + - - - - - + + + + + - + - - - + + + - - - - + + + + - - - + + + @@ -1846,8 +1864,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml index 10a7ab1dfb..a7a22f42ef 100644 --- a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -10,22 +31,23 @@ The total number of ions in the reconstruction. - + - The maximum number of atoms per molecular ion type. + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. - Results of a paraprobe-ranger tool run in atom probe microscopy. + Results of a paraprobe-ranger tool run. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -33,12 +55,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -48,49 +70,81 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. - + ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. - + - The absolute path and name of the config file for this analysis. + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + @@ -98,10 +152,11 @@ - The individual coordinate systems which used. - fields should be prefixed with a prefix taken from an - enumeration which details the individual coordinate systems: + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + * paraprobe * lab * specimen * laser @@ -112,14 +167,25 @@ - + Paraprobe-ranger loads the iontypes and evaluates for each ion on which iontype it matches. If it matches on none, the ion is considered of the default unknown type with a 0 as its respective value in the iontypes array. - + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + @@ -128,12 +194,80 @@ The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. + order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + is build are considered. By contrast, charged_iontypes takes + into account also the charge state. + + + + + + + + The iontype ID for each ion that was best matching, stored in the + order of the evaporation sequence ID. For the here computed + charged_iontypes the information for each (molecular) ion defined + in e.g. RNG or RRNG files is analyzed for which differently charge + states are possible. As an example while iontypes might only consider + if an ion is Al charged_iontypes will resolve if it is Al1+, Al2+, or + Al3+. To decide the charge state a recursive algorithm is used which + enumerates first all possible isotopic variants of a given molecular + ion build from a specific set of elements. All variants are then + analyzed for their natural abundance and filtered. The sub-set of + all significantly abundant variants is inspected if their charge + states are all the same. If only one significant variant is found + its charge state is assumed the relevant. If multiple significant + variants are found and all their charge states is the same this + charge state will be the decisive one. However, if multiple variants + are found and their charge state differs such a case highlights that + the charge state analysis is underconstrained and thus the charge + state is set to 0. Underconstrained cases are possible because + an arbitrary combination of elements into a molecular ion that is + constrained only by an additional single interval of mass-to-charge + state ratios is not necessarily sufficient. + + + A bitmask which identifies exactly all those ions ranged irrespective + the type they ended up with. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + @@ -215,9 +349,31 @@ + + + Paraprobe-ranger loads iontypes and evaluates for each ion on which + iontype it matches. If it matches on none, the ion is considered of + the default unknown type with a 0 as its respective value in the + iontypes array. In contrast to use_existent_ranging this process + does neither needs measured ion position nor mass-to-charge-state + ratio values. + + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + - - + + + @@ -225,23 +381,23 @@ - - - + + + - + - + - - + + - + - - + + @@ -249,19 +405,19 @@ - + - + - - + + - + @@ -271,13 +427,13 @@ - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml similarity index 67% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_selector.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml index 1b77a54689..70c38c656d 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -14,13 +35,13 @@ Results of a paraprobe-selector tool run. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -28,12 +49,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -43,13 +64,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -68,11 +89,11 @@ were completed and the paraprobe-tool executable exited as a process. - + The absolute path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. @@ -96,27 +117,27 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + - + Details about the coordinate system conventions used. - + The individual coordinate systems which should be used. Field names should be prefixed with the following controlled terms @@ -132,7 +153,7 @@ - + A bitmask which identifies which of the ions in the dataset @@ -169,52 +190,52 @@ - - - - + + + + - - - - + + + + - - - - - - + + + + + + - - - - - + + + + + - + - - - + + + - - - - + + + + - - - + + + @@ -234,8 +255,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml similarity index 72% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml index 87470cebe4..31e55ad32c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -14,13 +35,13 @@ Results of a paraprobe-spatstat tool run. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -28,12 +49,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -43,13 +64,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -68,18 +89,18 @@ were completed and the paraprobe-tool executable exited as a process. - + The absolute path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. - + Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the @@ -103,27 +124,27 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + - + Details about the coordinate system conventions used. - + The individual coordinate systems which should be used. Field names should be prefixed with the following controlled terms @@ -139,7 +160,7 @@ - + A bitmask which identifies which of the ions in the dataset were @@ -189,7 +210,7 @@ - + K-nearest neighbor statistics. @@ -215,7 +236,7 @@ - + Radial distribution statistics. @@ -242,53 +263,53 @@ - - - - - + + + + + - - - - + + + + - - - - - - + + + + + + - - - - - + + + + + - + - - - + + + - - - - + + + + - - - + + + @@ -308,8 +329,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml similarity index 80% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml index 187d0ec526..9a07bf5138 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -22,27 +43,25 @@ - The total number of XDMF values to represent all faces of triangles - via XDMF. + The total number of XDMF values to represent all faces of triangles via XDMF. - The total number of XDMF values to represent all faces of tetrahedra - via XDMF. + The total number of XDMF values to represent all faces of tetrahedra via XDMF. Results of a paraprobe-surfacer tool run. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -50,12 +69,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -65,13 +84,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -90,18 +109,18 @@ were completed and the paraprobe-tool executable exited as a process. - + The absolute path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. - + Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the @@ -125,27 +144,27 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + Details about the coordinate system conventions used. - + The individual coordinate systems which should be used. Field names should be prefixed with the following controlled terms @@ -161,7 +180,7 @@ - + A bitmask which identifies which of the ions in the dataset were @@ -197,7 +216,7 @@ - + Paraprobe-surfacer can be used to load a ROI that is the entire or a sub-set of the ion point cloud. In the point_cloud_wrapping process @@ -211,7 +230,7 @@ This polyhedron is not necessarily convex. For some algorithms there is no guarantee that the resulting mesh yields a watertight mesh. - + A bitmask which identifies exactly all those ions whose positions @@ -257,7 +276,7 @@ - + @@ -266,15 +285,15 @@ - + - - + + The set of triangles in the coordinate system paraprobe which discretizes the exterior surface of the alpha complex. @@ -324,20 +343,20 @@ - + Do the triangles define a triangulated surface mesh which is watertight? - + The volume which the triangulated surface mesh encloses provided that the mesh is watertight. - + The set of tetrahedra which represent the interior volume of the complex if that is a closed 2-manifold. @@ -351,7 +370,7 @@ For explicit indexing the identifier array has to be defined. - + The accumulated volume of all interior tetrahedra. @@ -389,60 +408,60 @@ - + In the future we may want to wrap other primitives like triangles or polylines. - - - - - + + + + + - - - - + + + + - - - - - - + + + + + + - - - - - + + + + + - + - - - + + + - - - - + + + + - - - + + + @@ -462,8 +481,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml similarity index 86% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml index 6a90e5ac71..952fead4b8 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -19,13 +40,13 @@ Results of a paraprobe-tessellator tool run. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -33,12 +54,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -48,13 +69,13 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. @@ -73,18 +94,18 @@ were completed and the paraprobe-tool executable exited as a process. - + The absolute path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. - + Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the @@ -108,27 +129,27 @@ - + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + Details about the coordinate system conventions used. - + The individual coordinate systems which should be used. Field names should be prefixed with the following controlled terms @@ -144,7 +165,7 @@ - + The tool can be used to compute a Voronoi tessellation the entire @@ -446,7 +467,7 @@ - + @@ -461,7 +482,7 @@ - + By which MPI process was the Voronoi cell computed. @@ -469,7 +490,7 @@ - + By which OpenMP thread was the Voronoi cell computed. @@ -477,7 +498,7 @@ - + The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. This field can be used to interpret @@ -496,7 +517,7 @@ For explicit indexing the identifier array has to be defined. - + Integer used to distinguish polyhedra for explicit indexing. @@ -504,7 +525,7 @@ - + A simple approach to describe the entire set of polyhedra when the main intention is to store the shape of the polyhedra for @@ -557,53 +578,53 @@ - - - - - + + + + + - - - - + + + + - - - - - - + + + + + + - - - - - + + + + + - + - - - + + + - - - - + + + + - - - + + + @@ -623,8 +644,8 @@ in the NXcs_profiling super class. - - + + diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml index 12e9fdf3b6..877dd230bf 100644 --- a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -1,25 +1,45 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. - Total number of ions collected. + The total number of ions in the reconstruction. - Maximum number of allowed atoms per (molecular) ion (fragment). Needs - to match maximum_number_of_atoms_per_molecular_ion. + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. - Number of mass-to-charge-state-ratio intervals mapped on this ion - type. + Number of mass-to-charge-state-ratio intervals mapped on this ion type. @@ -29,15 +49,15 @@ - Results of a paraprobe-transcoder tool run in atom probe microscopy. + Results of a paraprobe-transcoder tool run. - + Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -45,12 +65,12 @@ - + Given name of the program/software/tool with which this NeXus (configuration) file was generated. - + Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and @@ -60,49 +80,81 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. - + Possibility for leaving a free-text description about this analysis. - + ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. - + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + The absolute path and name of the config file for this analysis. - + At least SHA256 strong hash of the specific config_file for tracking provenance. + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + + + + + + + @@ -125,7 +177,7 @@ - + An array of triplets of integers which can serve as a supplementary array for Paraview to display the reconstruction. The XDMF datatype @@ -276,8 +328,9 @@ - - + + + @@ -285,23 +338,23 @@ - - - + + + - + - + - - + + - + - - + + @@ -309,19 +362,19 @@ - + - + - - + + - + @@ -331,13 +384,13 @@ - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - Specify if it was different from the number_of_threads + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXatom_set.nxdl.xml b/contributed_definitions/NXatom_set.nxdl.xml index f49e5c4dc3..83b826d33c 100644 --- a/contributed_definitions/NXatom_set.nxdl.xml +++ b/contributed_definitions/NXatom_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 16e54bd054..112ede463b 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays @@ -21,8 +42,7 @@ - - Subclass of NXprocess to describe post-processing calibrations. + Subclass of NXprocess to describe post-processing calibrations. diff --git a/contributed_definitions/nyaml/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml similarity index 74% rename from contributed_definitions/nyaml/NXcg_alpha_complex.nxdl.xml rename to contributed_definitions/NXcg_alpha_complex.nxdl.xml index 65a20d31c6..a7e2d7828c 100644 --- a/contributed_definitions/nyaml/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -46,7 +67,7 @@ - + Specify which general type of alpha shape is computed. Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. @@ -58,7 +79,7 @@ - + Specifically when computed with the CGAL, the mode specifies if singular faces are removed (regularized) of the alpha complex. diff --git a/contributed_definitions/NXcg_alpha_shape.nxdl.xml b/contributed_definitions/NXcg_alpha_shape.nxdl.xml index 2429e8e130..96d211dbe9 100644 --- a/contributed_definitions/NXcg_alpha_shape.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_shape.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -46,7 +67,7 @@ - + Specify which general type of alpha shape is computed. Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. @@ -57,7 +78,7 @@ - + Specifically when computed with the CGAL, the mode specifies if singular faces are removed (regularized) of the alpha complex. diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index 5ff552a32e..e71adff6fd 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 6875ba0f3f..bcc121fe9c 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,8 +33,7 @@ - The cardinality of the set, i.e. the number of ellipses, or - ellipsoids. + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 5782567362..270582a939 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index d6960c7a6e..2ad1e03bb8 100644 --- a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index 0a42909c37..e3929b098b 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -41,7 +62,7 @@ - + The symmetry of the lattice defining the shape of the unit cell. diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index c05af5e868..ea731f4f38 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index efd4770c94..f9ff489f56 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_isocontour.nxdl.xml b/contributed_definitions/NXcg_isocontour.nxdl.xml index 8796deb1d9..c426f20dea 100644 --- a/contributed_definitions/NXcg_isocontour.nxdl.xml +++ b/contributed_definitions/NXcg_isocontour.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index 27c4eeacdc..25a58d5b53 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -18,7 +39,7 @@ marching cubes algorithm implementation is operating. - + Reference to the specific implementation of marching cubes used. @@ -33,11 +54,11 @@ description. - + Commercial or otherwise given name to the program which was used. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index f43337b4fd..2486ad7ad8 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml index cc39bbe4a7..29863ab4ba 100644 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 5d2350bd5c..efa99c5d1c 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 51be47e636..5525812aa7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index 983f127c28..fc85478336 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml index 8451c44d9a..96b299aa8d 100644 --- a/contributed_definitions/NXcg_roi_set.nxdl.xml +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 31e3d41865..80f53d17e4 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 95ab5ed1d2..4cae3e4229 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index b9e1ff78f0..8bf4467570 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index aad509f715..06210e334b 100644 --- a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index 705e6fb0f8..cf2213b4ac 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml index 5411658cd0..795cbac192 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -1,15 +1,36 @@ - + - + + Component of an instrument to store or place objects and specimens. - + Given name/alias. - + Free-text field for describing details about the chamber. For example out of which material was the chamber built. diff --git a/contributed_definitions/nyaml/NXchemical_composition.nxdl.xml b/contributed_definitions/NXchemical_composition.nxdl.xml similarity index 53% rename from contributed_definitions/nyaml/NXchemical_composition.nxdl.xml rename to contributed_definitions/NXchemical_composition.nxdl.xml index 4d05f3b46b..4b6309c258 100644 --- a/contributed_definitions/nyaml/NXchemical_composition.nxdl.xml +++ b/contributed_definitions/NXchemical_composition.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml index 3d3d785819..1192a9289f 100644 --- a/contributed_definitions/NXclustering.nxdl.xml +++ b/contributed_definitions/NXclustering.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 13e0d213f3..7afb20afee 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -1,8 +1,28 @@ - + - - - Subclass of NXelectronanalyser to describe the electron collection column of a + + + Subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index 91402c8229..17fc4368f6 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container to hold different coordinate systems conventions. diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index e4585c9404..31e9f4a54e 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Corrector for aberrations in an electron microscope. @@ -21,13 +42,13 @@ Was the corrector used? - + Given name/alias. - + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. If this does not exist diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index 316e4ca373..be45aa4453 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,16 +30,16 @@ 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 @@ -28,7 +49,7 @@ - + Ideally a (globally) unique persistent identifier of the computer, i.e. the Universally Unique Identifier (UUID) of the computing node. diff --git a/contributed_definitions/NXcs_cpu.nxdl.xml b/contributed_definitions/NXcs_cpu.nxdl.xml index 7e9d153f88..603c352ddd 100644 --- a/contributed_definitions/NXcs_cpu.nxdl.xml +++ b/contributed_definitions/NXcs_cpu.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,7 +30,7 @@ Computer science description of a central processing unit (CPU) of a computer. - + Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 40700ebf98..9256b02c88 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml index e73dc05bd7..1bf1d91032 100644 --- a/contributed_definitions/NXcs_gpu.nxdl.xml +++ b/contributed_definitions/NXcs_gpu.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,7 +30,7 @@ Computer science description of a graphic processing unit (GPU) of a computer. - + Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index c5a999dbec..aa1b2bd32f 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,7 +30,7 @@ Computer science description of a storage object in an input/output system. - + Qualifier for the type of storage medium used. @@ -24,7 +45,7 @@ Total amount of data which the medium can hold. - + Given name to the I/O unit. diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 6d7dfaba0f..517fd99016 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index eb4bf12748..fc25da0a1a 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml index 1b1e98f593..99bbcec883 100644 --- a/contributed_definitions/NXcs_prng.nxdl.xml +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,7 +33,7 @@ The purpose of such metadata is to identify if exactly the same sequence can be reproduced, like for a PRNG or not (for a true physically random source). - + Different approaches for generating random numbers with a computer exists. Some use a dedicated physical device where the state is unpredictable (physically). @@ -32,13 +53,13 @@ - + Name of the PRNG implementation and version. If such information is not available or if the PRNG type was set to other the DOI to the publication or the source code should be given. - + Version and build number, or commit hash. diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml index 9fc5c53c2e..3d8d5eec34 100644 --- a/contributed_definitions/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -48,6 +69,11 @@ references to e.g. more detailed performance data to which they wish to link the metadata in this base class. + + + Path to the directory from which the tool was called. + + Command line call with arguments if applicable. diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9c22dc560a..53b4854579 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -26,7 +47,7 @@ included when the event tracking ended. - + Free-text description what was monitored/executed during the event. diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml index 1af741055d..9b185b773e 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -1,10 +1,30 @@ - + - - - Deflectors as they are used e.g. in an electron analyser. + + + Deflectors as they are used e.g. in an electron analyser. - + Qualitative type of deflector with respect to the number of pole pieces @@ -15,24 +35,24 @@ - + 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. - + Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the deflector. - + Ideally an identifier, persistent link, or free text which gives further details about the deflector. diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 28e3d35f1e..7487e80c86 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -34,17 +55,17 @@ computing of point density, composition, or concentration values, obtain scalar fields, and compute gradients of these fields. - + Reference or link to the grid on which the delocalization is applied. - + Reference or link to the points which are delocalized on the grid. - + The weighting model specifies how mark data are mapped to a weight per point. For atom probe microscopy (APM) as an example, different models are used which diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml index 5189d5e3b0..dc5e235e0d 100644 --- a/contributed_definitions/NXdistortion.nxdl.xml +++ b/contributed_definitions/NXdistortion.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays @@ -21,8 +42,7 @@ - - Subclass of NXprocess to describe post-processing distortion correction. + Subclass of NXprocess to describe post-processing distortion correction. @@ -37,11 +57,10 @@ For `symmetry-guided distortion correction`_, - where a pattern of features is mapped to the regular geometric structure - expected from the symmetry. Here we record the number of elementary symmetry - operations. - - .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub + where a pattern of features is mapped to the regular geometric structure expected + from the symmetry. Here we record the number of elementary symmetry operations. + + .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index de433ed732..ff72728eaa 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for components to form a controlled beam in electron microscopy. @@ -9,7 +30,7 @@ The source which creates the electron beam. - + Given name/alias. @@ -21,7 +42,7 @@ immediately after they left the gun. - + Type of radiation. @@ -29,7 +50,7 @@ - + Emitter type used to create the beam. @@ -43,12 +64,12 @@ - + Material of which the emitter is build, e.g. the filament material. - + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. @@ -76,7 +97,7 @@ and characteristics of the electron beam. NXtransformations should be used to specify the location - of the position at which the beam was probed. + of the position at which the beam was probed. diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index c08d6649f7..3b50270044 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -1,14 +1,35 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays - Number of fast axes (axes acquired symultaneously, without scanning a - pysical quantity) + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) @@ -17,12 +38,11 @@ - - Subclass of NXinstrument to describe a photoelectron analyser. + Subclass of NXinstrument to describe a photoelectron analyser. - Free text description of the type of the detector + Free text description of the type of the detector @@ -94,13 +114,13 @@ 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. + geometry of the electron analyser 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/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 5db2f3bdae..8308f14b5d 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Variables used throughout the document, e.g. dimensions and important @@ -14,23 +35,22 @@ - How many variables are saved in a measurement. e.g. 2 for Psi and - Delta, 16 for Mueller matrix elements, 15 for normalized Mueller - matrix, 3 for NCS, the length of NXsample/column_names + How many variables are saved in a measurement. e.g. 2 for Psi and Delta, 16 for + Mueller matrix elements, 15 for normalized Mueller matrix, 3 for NCS, the length + of NXsample/column_names - Number of incident angles used, the length of - NXinstrument/angle_of_incidence array + Number of incident angles used, the length of NXinstrument/angle_of_incidence + array - Number of sample parameters scanned, if you varied any of the - parameters such as temperature, pressure, or pH, the maximal length of - the arrays specified by NXsample/environment_conditions/SENSOR/value - if it exists. + Number of sample parameters scanned, if you varied any of the parameters such as + temperature, pressure, or pH, the maximal length of the arrays specified by + NXsample/environment_conditions/SENSOR/value if it exists. @@ -90,17 +110,17 @@ * parameters used to tune the state of the sample * sample description - + An application definition for ellipsometry. - + Version number to identify which definition of this application definition was used for this entry/data. - + URL where to find further material (documentation, examples) relevant to the application definition @@ -110,7 +130,7 @@ - + Unique identifier of the experiment, such as a (globally persistent) unique identifier. @@ -118,7 +138,7 @@ ii) The identifier enables to link experiments to e.g. proposals. - + A free-text description of the experiment. What is the aim of the experiment? The general procedure. @@ -130,7 +150,7 @@ - + Commercial or otherwise defined given name to the program that was used to generate the result file(s) with measured data and metadata. This program @@ -138,7 +158,7 @@ provide the actual steps in the NOTE subfield here. - + Either version with build number, commit hash, or description of a (online) repository where the source code of the program and build instructions can be @@ -157,34 +177,34 @@ Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. - + Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. - + Email address of the user. - + Author ID defined by https://orcid.org/. - + Official telephone number of the user. @@ -194,18 +214,18 @@ General properties of the ellipsometry equipment - + The name of the instrument - + The used version of the hardware if available. If not a commercial instrument use date of completion of the hardware. - + Name of the company which build the instrument @@ -216,17 +236,17 @@ specified. - + Commercial or otherwise defined name of the software that was used for the measurement - + Version and build number or commit hash of the software source code - + Website of the software. @@ -252,7 +272,7 @@ Specify the angular spread caused by the focussing probes - + What type of ellipsometry was used? See Fujiwara Table 4.2 @@ -305,7 +325,7 @@ measured for your data, also provide Psi and Delta here and use the same wavelenghts as for the measured data. - + What data were recorded for the calibration? The number of variables (N_variables) have to be set to the number of provided data columns accordingly, @@ -391,7 +411,7 @@ - + A free-text field to provide information about the stage. @@ -403,7 +423,7 @@ Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) Last, provide the rotations of the sample - + If there is no motorized stage, we should at least qualify where the beam hits the sample and in what direction the sample stands in a free-text description, @@ -457,7 +477,7 @@ the substrate (e.g. silicon with thermal oxide layer) in air without window and in a known medium with the window. - + What sample was used to estimate the window effect? @@ -491,7 +511,7 @@ the whole detector unit goes in here. Integration time is the count time field, or the real time field. See their definition. - + What kind of detector module is used, e.g. CCD-spectrometer, CCD camera, PMT, photodiode, etc. @@ -505,7 +525,7 @@ - + If you specified 'other' as detector type, please write down what it is. @@ -516,7 +536,7 @@ spectrum. - + Define which element rotates, e.g. polarizer or analyzer. @@ -621,20 +641,21 @@ conditions (e.g. surrounding medium, temperature, pressure etc.), along with the data (data type, wavelength array, measured data). - + - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. + Use Hill's system for listing elements of the periodic table which are inside or + attached to the surface of the specimen and thus relevant from a scientific + point. The purpose of this field is to allow material databases to parse the + relevant elements without having to interpret the sample history or other + fields. - + Descriptive name of the sample - + Ideally, a reference to the location or a unique (globally persistent) identifier (e.g.) of e.g. another file which gives as many as possible details @@ -649,7 +670,7 @@ ISO8601 date with time zone (UTC offset) specified. - + Qualitative description of the layer structure for the sample. For example: Si/native oxide/thermal oxide/polymer/peptide @@ -661,7 +682,7 @@ used in this measurement; typically an index of 0 - N - + Select which type of data was recorded, for example Psi and Delta (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It is possible to @@ -678,7 +699,7 @@ - + Please list in this array the column names used in your actual data. That is ['psi', 'delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for a full Mueller matrix, @@ -727,7 +748,7 @@ Specify external parameters that have influenced the sample. - + Describe what was the medium above or around the sample. The common model is built up from the substrate to the medium on the other side. Both boundaries are @@ -753,7 +774,7 @@ length of the 4th dimension of the data). Defaults to 1. - + Indicates which parameter was changed. Its definition must exist below. The specified variable has to be number_of_runs long, providing the parameters for diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index aafb0b6ea9..23c77743f6 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Characterization and session with one sample in an electron microscope. @@ -327,7 +348,7 @@ that specifies the application definition. - + NeXus NXDL schema to which this file conforms. @@ -335,7 +356,7 @@ - + Ideally, a (globally) unique persistent identifier for referring to this experiment. @@ -345,7 +366,7 @@ The identifier enables to link experiments to e.g. proposals. - + Free-text description about the experiment. @@ -381,7 +402,7 @@ the microscope session ended. - + Commercial or otherwise given name to the program which was used to create the file. @@ -403,7 +424,7 @@ mentioned in this field, the NXprocess needs to hold an own program and version. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -438,48 +459,48 @@ principle investigator who performed this experiment. Adding multiple users if relevant is recommended. - + Given (first) name and surname of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Postal address of the affiliation. - + Email address of the user at the point in time when the experiment was performed. Writing the most permanently used email is recommended. - + Globally unique identifier of the user as offered by services like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform - + Name of the OrcID or ResearcherID where the account under orcid is registered. - + (Business) (tele)phone number of the user at the point in time when the experiment was performed. - + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating @@ -487,12 +508,12 @@ are common examples. - + Account name that is associated with the user in social media platforms. - + Name of the social media platform where the account under social_media_name is registered. @@ -504,7 +525,7 @@ A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. - + A qualifier whether the sample is a real one or a virtual one (in a computer simulation) @@ -514,7 +535,7 @@ - + Ideally (globally) unique persistent identifier. The name distinguishes the specimen from all others and especially the predecessor/origin @@ -532,7 +553,7 @@ sample history. - + Ideally, a reference to a (globally) unique persistent identifier, representing a data artifact which documents ideally as many details @@ -574,12 +595,12 @@ describe the sample_history. - + Possibility to give an abbreviation or alias of the specimen name field. - + List of comma-separated elements from the periodic table that are contained in the sample. @@ -613,7 +634,7 @@ of the specimen. - + Discouraged free-text field in case properly designed records for the sample_history are not available. @@ -657,51 +678,57 @@ eventual additional component for applying external stimuli on the sample * NXdetector: several possible names like secondary_electron, backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram + cathodoluminescence, camera, ronchigram - + Given name of the microscope at the hosting institution. This is an alias. Examples could be NionHermes, Titan, JEOL, Gemini, etc. - + Location of the lab or place where the instrument is installed. Using GEOREF is preferred. - - - - + + + + - - - + + + - + - - - + + + - + + + + + + + - - - + + + - - + + @@ -709,9 +736,9 @@ voltage, current, or value should be defined. - - - + + + @@ -719,11 +746,11 @@ - + - - - + + + @@ -744,31 +771,31 @@ - - - + + + - + - - - + + + - + - + - - - + + + @@ -778,7 +805,7 @@ voltage, current, or value should be defined. - + @@ -787,17 +814,17 @@ - - - + + + - - - + + + @@ -807,7 +834,7 @@ - + @@ -817,26 +844,26 @@ Different technologies are in use like CCD, scintillator, direct electron, CMOS, or image plate to name but a few. - + Free text option to write further details about the detector. - + - + - - - - + + + + - - + + @@ -945,13 +972,13 @@ - + Reference to a specific state and setting of the microscope components. - - + + The detector or set of detectors that was used to collect this signal. The name of the detector has to match one of the names of available @@ -962,24 +989,24 @@ - + - + - + - + - + - + @@ -992,18 +1019,18 @@ - + - + - + - + - + @@ -1012,30 +1039,30 @@ - + - + - + - + - + - + - + - + @@ -1044,15 +1071,15 @@ - + - + - + - + @@ -1063,38 +1090,58 @@ - + - + - + - + - + - + - + - + + + + + + + + + + + + + + + + + + + + + + - @@ -1115,7 +1162,7 @@ - + @@ -1138,7 +1185,7 @@ - + @@ -1163,7 +1210,7 @@ - + @@ -1175,7 +1222,7 @@ - + diff --git a/contributed_definitions/nyaml/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml similarity index 88% rename from contributed_definitions/nyaml/NXem_ebsd.nxdl.xml rename to contributed_definitions/NXem_ebsd.nxdl.xml index d5c4c33887..213c67660e 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -1,6 +1,27 @@ - + - + + @@ -14,8 +35,8 @@ - Number of pixel along the slowest changing dimension for a - rediscretized, i.e. standardized default orientation mapping. + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. @@ -50,14 +71,14 @@ give some conceptual ideas how this splitting between measurement and post-processing can be granularized also for these techniques. - + An at least as strong as SHA256 hashvalue of the file that specifies the application definition. - + NeXus NXDL schema to which this file conforms. @@ -65,7 +86,7 @@ - + Ideally, a (globally) unique persistent identifier for referring to this workflow. @@ -75,7 +96,7 @@ workflows/experiments to e.g. proposals. - + Free-text description about the workflow. @@ -85,7 +106,7 @@ details into the experiment_description free-text description field. - + ISO 8601 time code with local time zone offset to UTC information included when the processing of the workflow started. @@ -99,18 +120,18 @@ and interpretation of the workflow. - + ISO 8601 time code with local time zone offset to UTC included when the processing of the workflow ended. - + Commercial, parser, or otherwise given name to the program which was used to process the workflow. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and @@ -120,55 +141,55 @@ - + Optional contact information and eventually details of at least one person involved in performing the workflow. This can be the principle investigator who performed this experiment. Adding multiple users if relevant is recommended. - + Given (first) name and surname of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Postal address of the affiliation. - + Email address of the user at the point in time when the experiment was performed. Writing the most permanently used email is recommended. - + Globally unique identifier of the user as offered by services like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform - + Name of the OrcID or ResearcherID where the account under orcid is registered. - + (Business) (tele)phone number of the user at the point in time when the experiment was performed. - + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating @@ -176,13 +197,13 @@ are common examples. - + Account name that is associated with the user in social media platforms. - + Name of the social media platform where the account under social_media_name is registered. @@ -226,7 +247,7 @@ and shared by just sharing the results file in the technology partner specific formatting. - + Commercial program which was used to index the EBSD data incrementally after they have been captured and while the @@ -234,7 +255,7 @@ how scanning electron microscopes are used when collecting EBSD data. - + Program version plus build number, commit hash, or other description of an ever persistent resource where the source code of the program and @@ -245,11 +266,11 @@ - + Name of the results file. - + Hash of that file. @@ -261,7 +282,7 @@ Connection between the measurement of the Kikuchi pattern and the processing of these into an orientation microscopy image. - + Name or link to an existent instance of an EBSD raw dataset inside an NXem which has at least one NXimage_set_em_kikuchi instance. @@ -293,20 +314,20 @@ demands profits from feedback from the technology partners we have opted for this intermediate approach. - + Commit identifying this resource. - + Path which resolves which specific NXimage_set_em_kikuchi instance was used as the raw data to this EBSD data (post)-processing workflow. - + The EBSD system, that is the electron gun, pole-piece, stage tilting, and EBSD detector, as well as the gnomonic projection have to be @@ -341,19 +362,19 @@ There is usually one person in each lab responsible for doing such calibrations. - + A link/cross reference to an existent instance of NXebsd with ideally an associated instance of NXem detailed under measurement which informs about the calibration procedures. - + Commit identifying this resource. - + Path which resolves which specific NXimage_set_em_kikuchi instance was used as the raw data to this EBSD data (post)-processing workflow @@ -363,38 +384,38 @@ - - - - - + + + + + - - - - - + + + + + - - - - - + + + + + - - - - - + + + + + - - - - + + + + @@ -415,7 +436,7 @@ and Hough transforms and how they relate by M. van Ginkel et al.). Dictionary-based indexing methods are most increasingly becoming used also. - + Principal algorithm used for indexing. @@ -427,30 +448,30 @@ - + Details about the background correction applied to each Kikuchi pattern. - + Binning i.e. downsampling of the pattern. - + Specific parameter relevant only for certain algorithms used - - - + + + - + - - + + @@ -459,7 +480,7 @@ - + Which return value did the indexing algorithm yield for each scan point. Practically useful is to use an uint8 mask. @@ -468,7 +489,7 @@ * 1 - Too high angular deviation * 2 - No solution * 100 - Success - * 255 - Unexpected errors + * 255 - Unexpected errors @@ -525,7 +546,7 @@ - + One-dimensional array, pattern by pattern labelling the solutions found. The array n_phases_per_scan_point has to be specified because it details @@ -536,7 +557,7 @@ - + Phase_matching is a descriptor for how well the solution matches or not. Examples can be confidence index (ci), mean angular deviation (mad), @@ -549,7 +570,7 @@ - + How are orientations parameterized? Inspect euler_angle_convention in case of using euler to clarify the sequence of rotations assumed. @@ -584,18 +605,18 @@ - + Fraction of successfully indexed pattern of the set averaged over entire set. - + An overview of the entire area which was scanned. For details about what defines the image contrast inspect descriptor. - + Descriptor representing the image contrast. @@ -610,7 +631,7 @@ - + Overview @@ -623,7 +644,7 @@ - + Label for the y axis @@ -636,7 +657,7 @@ - + Label for the x axis @@ -644,7 +665,7 @@ - + Default inverse pole figure (IPF) plot of the data specific for each phase interpolated on a rectangular/cuboidal domain with square @@ -719,7 +740,7 @@ Specifying which phase this IPF mapping visualizes. - + Which IPF definition computation according to backend. @@ -737,7 +758,7 @@ Bitdepth used for the RGB color model. Usually 8 bit. - + The tool/implementation used for creating the IPF color map from the orientation data. Effectively this program is the backend @@ -764,7 +785,7 @@ - + Version of the program i.e. backend used. @@ -780,7 +801,7 @@ - + IPF color coded orientation mapping @@ -793,7 +814,7 @@ - + Label for the y axis @@ -806,7 +827,7 @@ - + Label for the x axis @@ -836,7 +857,7 @@ - + Naive IPF color map @@ -849,7 +870,7 @@ - + Label for the y axis @@ -862,7 +883,7 @@ - + Label for the x axis diff --git a/contributed_definitions/nyaml/NXem_ebsd_conventions.nxdl.xml b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml similarity index 90% rename from contributed_definitions/nyaml/NXem_ebsd_conventions.nxdl.xml rename to contributed_definitions/NXem_ebsd_conventions.nxdl.xml index cada44a8ec..cb27931193 100644 --- a/contributed_definitions/nyaml/NXem_ebsd_conventions.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Conventions for rotations and coordinate systems to interpret EBSD data. @@ -15,7 +36,7 @@ Mathematical conventions and materials-science-specific conventions required for interpreting every collection of orientation data. - + Convention how a positive rotation angle is defined when viewing from the end of the rotation unit vector towards its origin, @@ -30,7 +51,7 @@ - + How are rotations interpreted into an orientation according to convention 3 of @@ -42,7 +63,7 @@ - + How are Euler angles interpreted given that there are several choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of @@ -55,7 +76,7 @@ - + To which angular range is the rotation angle argument of an axis-angle pair parameterization constrained according to @@ -66,7 +87,7 @@ - + Which sign convention is followed when converting orientations between different parameterizations/representations according @@ -83,7 +104,7 @@ Details about the sample/specimen reference frame. - + Type of coordinate system and reference frame according to convention 1 of DOI: 10.1088/0965-0393/23/8/083501. @@ -107,7 +128,7 @@ - + Direction of the positively pointing x-axis base vector of the sample surface reference frame. We assume the configuration @@ -131,7 +152,7 @@ - + Direction of the positively pointing y-axis base vector of the sample surface reference frame. We assume the configuration @@ -149,7 +170,7 @@ - + Direction of the positively pointing z-axis base vector of the sample surface reference frame. We assume the configuration @@ -167,7 +188,7 @@ - + Location of the origin of the sample surface reference frame. This specifies the location Xs = 0, Ys = 0, Zs = 0. @@ -194,7 +215,7 @@ Details about the detector reference frame. - + Type of coordinate system/reference frame used for identifying positions in detector space Xd, Yd, Zd, @@ -206,7 +227,7 @@ - + Direction of the positively pointing x-axis base vector of the detector space reference frame. We assume the configuration @@ -230,7 +251,7 @@ - + Direction of the positively pointing y-axis base vector of the detector space reference frame. We assume the configuration @@ -249,7 +270,7 @@ - + Direction of the positively pointing z-axis base vector of the detector space reference frame. We assume the configuration @@ -268,7 +289,7 @@ - + Where is the origin of the detector space reference frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. @@ -295,7 +316,7 @@ Details about the gnomonic projection reference frame. - + Type of coordinate system/reference frame used for identifying positions in the gnomonic projection space Xg, Yg, Zg @@ -307,7 +328,7 @@ - + Direction of the positively pointing "gnomomic" x-axis base vector when viewing how the diffraction pattern looks on the @@ -332,7 +353,7 @@ - + Direction of the positively pointing "gnomomic" y-axis base vector when viewing how the diffraction pattern looks on the @@ -352,7 +373,7 @@ - + Direction of the positively pointing "gnomomic" z-axis base vector when viewing how the diffraction pattern looks on the @@ -372,7 +393,7 @@ - + Is the origin of the gnomonic coordinate system located where we assume the location of the pattern centre. @@ -390,7 +411,7 @@ Details about the definition of the pattern centre as a special point in the gnomonic projection reference frame. - + From which border of the EBSP (in the detector reference frame) is the pattern centre's x-position (PCx) measured? @@ -407,7 +428,7 @@ - + In which direction are positive values for PCx measured from the specified boundary. Keep in mind that the gnomonic space @@ -433,7 +454,7 @@ - + From which border of the EBSP (in the detector reference frame) is the pattern centre's y-position (PCy) measured? @@ -448,7 +469,7 @@ - + In which direction are positive values for PCy measured from the specified boundary. diff --git a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.nxdl.xml b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml similarity index 81% rename from contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.nxdl.xml rename to contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml index 7bafab25e2..ecb402203e 100644 --- a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml @@ -1,6 +1,27 @@ - + - + + @@ -29,13 +50,13 @@ used algorithm. More and more dictionary based alternatives are used. Either way both algorithm need a crystal structure model. - + Identifier of an entry from crystallographic_database which was used for creating this structure model. - + Name of the crystallographic database to resolve crystallographic_database_identifier e.g. COD or others. @@ -62,7 +83,7 @@ Volume of the unit cell - + Crystallographic space group @@ -83,17 +104,17 @@ False if space group is consider a non-chiral one. - + Laue group - + Point group using International Notation. - + Crystal system @@ -115,12 +136,12 @@ Consequently, the value 0 must not be used as a phase_identifier. - + Name of the phase/alias. - + Labels for each atom position diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index def450232e..69efa4e8e8 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -1,8 +1,28 @@ - + - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index cbe764fe94..6f3c087f93 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Metadata and settings of an electron microscope for scans and images. @@ -144,12 +165,12 @@ when the snapshot time interval ended. - + Reference to a specific state and setting of the microscope components. - + Which specific event/measurement type. Examples are: @@ -166,10 +187,10 @@ * Auger, spectrum, (low Z contrast element composition) * Cathodoluminescence (optical spectra) * Ronchigram, image, alignment utility specifically in TEM - * Chamber, e.g. TV camera inside the chamber, education purposes. + * Chamber, e.g. TV camera inside the chamber, education purposes. - + The detector or set of detectors that was used to collect this signal. The name of the detector has to match the names used for available diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml index f396f3c2a0..1af6d974c0 100644 --- a/contributed_definitions/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container to hold NXevent_data_em instances of an electron microscope session. diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index f29254c3ca..d687950d02 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,26 +1,47 @@ - + - + + Details about a component as defined by its manufacturer. - + Company name of the manufacturer. - + Version or model of the component named by the manufacturer. - + Ideally, (globally) unique persistent identifier, i.e. a serial number or hash identifier of the component. - + Free-text list with eventually multiple terms of functionalities which the component offers. diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 93472732e7..376c4ea37d 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 545343b83d..f6fc7561fd 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,8 +33,7 @@ - The cardinality of the set, i.e. the number of nodes/vertices of the - graph. + The cardinality of the set, i.e. the number of nodes/vertices of the graph. diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index f355c0958c..1ed723f89a 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml index 58b594372a..7d3d2e03dd 100644 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for components of a focused-ion-beam (FIB) system. @@ -29,12 +50,12 @@ The source which creates the ion beam. - + Given name/alias for the ion gun. - + Emitter type used to create the ion beam. @@ -48,7 +69,7 @@ - + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. diff --git a/contributed_definitions/NXimage_set_em.nxdl.xml b/contributed_definitions/NXimage_set_em.nxdl.xml index 6a8e009aac..5d46b05415 100644 --- a/contributed_definitions/NXimage_set_em.nxdl.xml +++ b/contributed_definitions/NXimage_set_em.nxdl.xml @@ -1,6 +1,27 @@ - + - + + @@ -22,7 +43,7 @@ Container for reporting a set of images taken with an electron microscope. - + Imaging mode in which the instrument was and with which the images were captured. @@ -50,7 +71,7 @@ - + Image identifier. @@ -63,7 +84,7 @@ - + Coordinate along y direction. @@ -76,7 +97,7 @@ - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index b776f4731b..d7c0a63091 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -1,6 +1,27 @@ - + - + + @@ -34,25 +55,25 @@ Details how (HA)ADF images were processed from the detector readings. - + Typically the name of the input, (vendor) file from which all the NXdata instances in this NXimage_set_em_adf were loaded during parsing to represent them in e.g. databases. - + An at least as strong as SHA256 hashvalue of the dataset/file which represents the source digitally to support provenance tracking. - + Commercial or otherwise given name to the program which was used to process detector data into the adf image(s). - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -94,7 +115,7 @@ - + Image identifier. @@ -107,7 +128,7 @@ - + Coordinate along y direction. @@ -120,7 +141,7 @@ - + Coordinate along x direction. diff --git a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml index 42cfa824a7..8d052150de 100644 --- a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml @@ -1,29 +1,54 @@ - + - + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + - Number of scan points, one pattern per scan point. + Number of diffraction pattern. - Number of pixel per Kikuchi pattern in the slow direction + Number of pixel per Kikuchi pattern in the slow direction. - Number of pixel per Kikuchi pattern in the fast direction + Number of pixel per Kikuchi pattern in the fast direction. - Electron backscatter diffraction (EBSD) Kikuchi pattern. - - The container can also store data related to a post-processing of these - Kikuchi pattern, which is the backbone of orientation microscopy - especially in materials science and materials engineering. + Measured set of electron backscatter diffraction data, aka Kikuchi pattern. + Kikuchi pattern are the raw data for computational workflows in the field + of orientation (imaging) microscopy. The technique is especially used in + materials science and materials engineering. Based on a fuse of the `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ of the DREAM.3D community and the open H5OINA format of Oxford Instruments @@ -37,291 +62,132 @@ * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - With serial-sectioning this involves however always a sequence of - measuring, milling. In this regard, each serial section (measuring) and milling + With serial-sectioning this involves however always a sequence of measuring, + milling. In this regard, each serial section (measuring) and milling is an own NXevent_data_em instance and thus there such a three-dimensional characterization should be stored as a set of two-dimensional data, with as many NXevent_data_em instances as sections were measured. These measured serial sectioning images need virtually always post-processing - to arrive at the aligned and cleaned image stack respective digital - microstructure representation as (a representative) volume element. - Several software packages are available for this post-processing. + to arrive at the aligned and cleaned image stack before a respective digital + model of the inspected microstructure can be analyzed. The resulting volume + is often termed a so-called (representative) volume element (RVE). + Several software packages are available for performing this post-processing. For now we do not consider metadata of these post-processing steps - as a part of this base class. + as a part of this base class because the connection between the large variety + of such post-processing steps and the measured electron microscopy data + is usually very small. + + If we envision a (knowledge) graph for EBSD it consists of individual + sub-graphs which convey information about the specimen preparation, + the measurement of the specimen in the electron microscope, + the indexing of the collected Kikuchi pattern stack, + eventual post-processing of the indexed orientation image + via similarity grouping algorithms to yield (grains, texture). + Conceptually these post-processing steps are most frequently + serving the idea to reconstruct quantitatively so-called + microstructural features (grains, phases, interfaces). Materials scientists + use these features according to the multi-scale materials modeling paradigm + to infer material properties. They do so by quantifying correlations between + the spatial arrangement of the features, their individual properties, + and (macroscopic) properties of materials. - + - Collected Kikuchi pattern as an image stack. + Details how Kikuchi pattern were processed from the detector readings. + Scientists interested in EBSD should inspect the respective NXem_ebsd + application definition which can be used as a partner application definition + to detail substantially more details to this processing. - + + + + Collected Kikuchi pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably by the instrument + given the way how the instrument and control software was configured + for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belong to which scan point. + In an example we may assume we collected three scan points. For the first + we measure one pattern, for the second we measure three pattern, + for the last we measure no pattern. + The values of scan_point_identifier will be 0, 1, 1, 1, as we have + measured four pattern in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. Use compressed + arrays allows to store the scan_point_identifier efficiently. + + + + + + + + Signal intensity. For so-called three-dimensional or serial sectioning + EBSD it is necessary to follow a sequence of specimen surface preparation + and data collection. In this case users should collect the data for each + serial sectioning step in an own instance of NXimage_set_em_kikuchi. + All eventual post-processing of these measured data should be documented + via NXebsd, resulting microstructure representations should be stored + as NXms. + - + Kikuchi pattern intensity - + + + Pattern are enumerated starting from 0 to n_p - 1. + - + Kikuchi pattern identifier - + + + Pixel coordinate along the y direction. + - + Label for the y axis - + + + Pixel coordinate along the x direction. + - + Label for the x axis - - - Which pixel primitive shape is used. - - - - - - - - - The prescribed step size. First value is for the slow changing, - second value is for the fast changing dimension. - - - - - - - - - OIM, orientation imaging microscopy. - Post-processing of the Kikuchi pattern to identify orientations. - - - - - - - - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - How are Kikuchi bands detected - - - - - - - - - - - - - - - - - - How many bands were detected in the pattern. - - - - - - - - - - Lattice planes used as reflectors for indexing pattern - in electron-backscatter diffraction (EBSD). - One collection for each reflector. - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - - - - - - - - - - - - Crystallographic space group - - - - - Laue group - - - - - Numeral identifier for each phase. The value 0 is reversed for the unknown - phase. - - - - - Name of the phase/alias. - - - - - - Miller indices :math:`(hkl)[uvw]`. - - - - - - - - - - How are pattern being indexed? - - - - - - - - Minimum number of bands required to index the pattern - - - - - - - - Which return value did the indexing algorithm yield for each pattern. - - * Details about bad pixels - * Too high angular deviation - * No solution - * Not analyzed - * Success - * Unexpected errors - - - - - - - - Labels referring to the phase_identifier for each pattern (from reflectors) that - matched best. - - - - - - - - - - - - - - - - - - - - - Free-text description for instrument specific settings - - - - - How is the camera signal binned. - First the number of pixel along the slow direction. - Second the number of pixel along the fast direction. - - - - - - - - - - - - - Average number of patterns taken on average. - - - - - Wall-clock time the acquisition took. - - - - - Fraction of successfully indexed pattern of the set. - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 9e6e3be437..c8c157827b 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -1,14 +1,34 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. - Maximum number of atoms/isotopes allowed per (molecular) ion - (fragment). + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). @@ -84,7 +104,7 @@ 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, diff --git a/contributed_definitions/nyaml/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml similarity index 62% rename from contributed_definitions/nyaml/NXisocontour.nxdl.xml rename to contributed_definitions/NXisocontour.nxdl.xml index b11f04e6e9..c426f20dea 100644 --- a/contributed_definitions/nyaml/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 261a0d91c6..876db0de5e 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -1,6 +1,27 @@ - + - + + @@ -53,8 +74,9 @@ - - + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 5eca5ce343..d49659a1d6 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -1,19 +1,41 @@ - + - + + Description of an electro-magnetic lens or a compound lens. + Details of an `electro-magnetic 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. + 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>`_ + .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 - + - Qualitative type of lens with respect to the number of pole pieces. + Qualitative type of lens with respect to the number of pole pieces @@ -23,25 +45,25 @@ - + - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. + 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. @@ -59,17 +81,6 @@ 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 @@ -78,11 +89,10 @@ - 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. + 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/nyaml/NXliquid_jet.nxdl.xml b/contributed_definitions/NXliquid_jet.nxdl.xml similarity index 57% rename from contributed_definitions/nyaml/NXliquid_jet.nxdl.xml rename to contributed_definitions/NXliquid_jet.nxdl.xml index 5294ed80d2..94e038bbba 100644 --- a/contributed_definitions/nyaml/NXliquid_jet.nxdl.xml +++ b/contributed_definitions/NXliquid_jet.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Description of a liquid jet @@ -28,9 +49,9 @@ - - - + + + @@ -38,9 +59,9 @@ - - - + + + diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index d961e331bc..395f0c0682 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -1,8 +1,28 @@ - + - - - Extension of NXpositioner to include fields to describe the use of manipulators + + + Extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. @@ -17,7 +37,7 @@ - Type of manipulator, Hexapod, Rod, etc. + Type of manipulator, Hexapod, Rod, etc. diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index a48bed0c57..9f1562c1b0 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -14,7 +35,7 @@ Settings of a filter to select or remove entries based on their value. - + Meaning of the filter: Whitelist specifies which entries with said value to include. @@ -28,7 +49,7 @@ - + Array of values to filter according to method. For example if the filter specifies [1, 5, 6] and method is whitelist, only entries with values diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index e17a9097cc..ef796edb60 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -1,19 +1,39 @@ - + - - - This is the most general application definition for multidimensional + + + This is the most general application definition for multidimensional photoelectron spectroscopy. - + Datetime of the start of the measurement. - - + + @@ -23,29 +43,29 @@ Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. - + Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. - + Email address of the user. - + Author ID defined by https://orcid.org/. @@ -60,7 +80,7 @@ source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. - + @@ -73,8 +93,8 @@ - - + + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. @@ -97,7 +117,7 @@ - + Energy resolution of the analyser with the current setting. May be linked from a @@ -105,9 +125,9 @@ - + - + Scheme of the electron collection column. @@ -120,8 +140,8 @@ - - + + The size and position of the field aperture inserted in the column. To add @@ -136,7 +156,7 @@ - + @@ -147,7 +167,7 @@ - + Size, position and shape of the entrance slit in dispersive analyzers. To add @@ -162,7 +182,7 @@ - + Type of electron amplifier in the first amplification step. @@ -171,7 +191,7 @@ - + Description of the detector type. @@ -263,8 +283,8 @@ - - + + The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead. @@ -279,14 +299,6 @@ case these are not available, free-text description. - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last @@ -310,7 +322,7 @@ /entry/instrument/manipulator/sample_temperature. - + diff --git a/contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml b/contributed_definitions/NXmpes_liquid.nxdl.xml similarity index 86% rename from contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml rename to contributed_definitions/NXmpes_liquid.nxdl.xml index 2c9b2603fc..501c7768b0 100644 --- a/contributed_definitions/nyaml/NXmpes_liquid.nxdl.xml +++ b/contributed_definitions/NXmpes_liquid.nxdl.xml @@ -1,19 +1,39 @@ - + - - - This is the application definition for multidimensional photoelectron + + + This is the application definition for multidimensional photoelectron spectroscopy on liquids - + Datetime of the start of the measurement. - - + + @@ -23,29 +43,29 @@ Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. - + Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. - + Email address of the user. - + Author ID defined by https://orcid.org/. @@ -60,7 +80,7 @@ source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. - + @@ -73,8 +93,8 @@ - - + + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. @@ -97,7 +117,7 @@ - + Energy resolution of the analyser with the current setting. May be linked from a @@ -105,9 +125,9 @@ - + - + Scheme of the electron collection column. @@ -120,8 +140,8 @@ - - + + The size and position of the field aperture inserted in the column. To add @@ -136,7 +156,7 @@ - + @@ -147,7 +167,7 @@ - + Size, position and shape of the entrance slit in dispersive analyzers. To add @@ -162,7 +182,7 @@ - + Type of electron amplifier in the first amplification step. @@ -171,7 +191,7 @@ - + Description of the detector type. @@ -263,9 +283,9 @@ - - - + + + The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead. @@ -303,7 +323,7 @@ /entry/instrument/manipulator/sample_temperature. - + @@ -348,26 +368,25 @@ - + Solvent material of the liquidjet. This also accounts for multiple jets if more than one solvent is given. - - - + + + - - - - + + + diff --git a/contributed_definitions/NXms_crystal_set.nxdl.xml b/contributed_definitions/NXms_crystal_set.nxdl.xml index ce7b59758c..ae57ebde28 100644 --- a/contributed_definitions/NXms_crystal_set.nxdl.xml +++ b/contributed_definitions/NXms_crystal_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,8 +33,8 @@ - The number of objects, which can be crystals, grains, phases or phase - field regions. + The number of objects, which can be crystals, grains, phases or phase field + regions. diff --git a/contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml b/contributed_definitions/NXms_dislocation_set.nxdl.xml similarity index 81% rename from contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml rename to contributed_definitions/NXms_dislocation_set.nxdl.xml index 0530dd0676..18dec9ace5 100644 --- a/contributed_definitions/nyaml/NXms_dislocation_set.nxdl.xml +++ b/contributed_definitions/NXms_dislocation_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXms_interface_set.nxdl.xml b/contributed_definitions/NXms_interface_set.nxdl.xml similarity index 82% rename from contributed_definitions/nyaml/NXms_interface_set.nxdl.xml rename to contributed_definitions/NXms_interface_set.nxdl.xml index fcec3c35bb..5c02478505 100644 --- a/contributed_definitions/nyaml/NXms_interface_set.nxdl.xml +++ b/contributed_definitions/NXms_interface_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXms_snapshot.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml index b9247097bf..f22be2334e 100644 --- a/contributed_definitions/NXms_snapshot.nxdl.xml +++ b/contributed_definitions/NXms_snapshot.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,7 +30,7 @@ Base class for data on the state of the microstructure at a given time/iteration. - + Is this time for a measurement or a simulation. diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml index 90d9ddc115..1f68d4dc86 100644 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,7 +30,7 @@ A collection of spatiotemporal microstructure data. - + Is this set describing a measurement or a simulation? diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 1b0694612c..4ddb466d73 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -1,6 +1,27 @@ - + - + + A container for qualifying an electron optical system. diff --git a/contributed_definitions/NXorientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml index ab86630eb9..026aab2fba 100644 --- a/contributed_definitions/NXorientation_set.nxdl.xml +++ b/contributed_definitions/NXorientation_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index e4a04b81a4..f723dd7e7c 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -14,13 +35,13 @@ 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 diff --git a/contributed_definitions/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml index 7e779c91ff..01f72626e7 100644 --- a/contributed_definitions/NXpid.nxdl.xml +++ b/contributed_definitions/NXpid.nxdl.xml @@ -1,10 +1,31 @@ - + - + + Contains the settings of a PID controller. - + Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index 0e463008b3..cfeb2c915f 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -15,7 +36,7 @@ Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - + How is field evaporation physically triggered. @@ -62,7 +83,7 @@ excitation and eventual field evaporation/emission of an ion during an experiment. - + Given name/alias. diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index 8070c7f1e0..b536259d6b 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -1,11 +1,32 @@ - + - + + Device to reduce an atmosphere to a controlled remaining pressure level. - + Principle type of the pump. diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml index 8cc18002fa..5b53b8a794 100644 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -1,16 +1,37 @@ - + - + + Device for reducing flight time differences of ions in ToF experiments. - + Given name/alias. - + Free-text field to specify further details about the reflectron. The field can be used to inform e. g. if the reflectron is flat or curved. diff --git a/contributed_definitions/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml index 8ddd155260..9c37e69a55 100644 --- a/contributed_definitions/NXregistration.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -1,8 +1,28 @@ - + - - - Describes image registration procedures. + + + Describes image registration procedures. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 10140019b1..4bb59f8bf1 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Scan box and coils which deflect an electron beam in a controlled manner. @@ -8,7 +29,7 @@ control software. This component directs the probe to controlled locations according to a scan scheme and plan. - + diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index 817f308c49..24754f5e2d 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -1,6 +1,37 @@ - + - + + + + + Variables used to set a common size for collected sensor data. + + + + The number of scan points measured in this scan. + + + Application definition for a generic scan using sensors. @@ -9,15 +40,15 @@ - + - + - - + + Define the program that was used to generate the results file(s) @@ -28,7 +59,7 @@ Commercial or otherwise defined given name of the program (or a link to the instrument software). - + Either version with build number, commit hash, or description of an (online) repository where the source code of the program and build @@ -37,7 +68,7 @@ deterministic manner. - + Website of the software. @@ -55,29 +86,29 @@ Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. - + Email address of the user. - + Author ID defined by https://orcid.org/. - + Official telephone number of the user. @@ -97,7 +128,7 @@ its readings. - + Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. @@ -106,11 +137,17 @@ For each point in the scan space, either the nominal setpoint of an independently scanned controller or a representative average value of a measurement sensor is registered. - In case of a full multi-dimensional scan, the length of the scan space [n] is the product of the number - of setpoints along all independently scanned controllers. + + The length of each sensor's data value array stored in this group should be equal to the number of scan points + probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. + This allows the scan to be made in any order as the user describes above in the experiment. We get matching + values simply using the index of the scan point. + + + - + Timestamp for when the values provided in the value field were registered. @@ -118,8 +155,8 @@ the nominal setpoint or average reading values listed above in the value field. - - + + Free-text describing the data acquisition control: an internal sweep using the built-in functionality of the controller device, @@ -135,12 +172,12 @@ - + A list of names of NXsensor groups used as independently scanned controllers. - + A list of names of NXsensor groups used as measurement sensors. diff --git a/contributed_definitions/nyaml/NXsensor_scan_parsed.nxdl.xml b/contributed_definitions/NXsensor_scan_parsed.nxdl.xml similarity index 77% rename from contributed_definitions/nyaml/NXsensor_scan_parsed.nxdl.xml rename to contributed_definitions/NXsensor_scan_parsed.nxdl.xml index ed8b513052..e868b86f9d 100644 --- a/contributed_definitions/nyaml/NXsensor_scan_parsed.nxdl.xml +++ b/contributed_definitions/NXsensor_scan_parsed.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Variables used to set a common size for collected sensor data. @@ -19,15 +40,15 @@ - + - + - - + + Define the program that was used to generate the results file(s) @@ -38,7 +59,7 @@ Commercial or otherwise defined given name of the program (or a link to the instrument software). - + Either version with build number, commit hash, or description of an (online) repository where the source code of the program and build @@ -47,7 +68,7 @@ deterministic manner. - + Website of the software. @@ -65,29 +86,29 @@ Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Full address (street, street number, ZIP, city, country) of the user's affiliation. - + Email address of the user. - + Author ID defined by https://orcid.org/. - + Official telephone number of the user. @@ -107,7 +128,7 @@ its readings. - + Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. @@ -126,7 +147,7 @@ - + Timestamp for when the values provided in the value field were registered. @@ -134,8 +155,8 @@ the nominal setpoint or average reading values listed above in the value field. - - + + Free-text describing the data acquisition control: an internal sweep using the built-in functionality of the controller device, diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml similarity index 83% rename from contributed_definitions/nyaml/NXsimilarity_grouping.nxdl.xml rename to contributed_definitions/NXsimilarity_grouping.nxdl.xml index 03b6eaf74e..1813e2d194 100644 --- a/contributed_definitions/nyaml/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXslip_system_set.nxdl.xml b/contributed_definitions/NXslip_system_set.nxdl.xml index 62d159c03e..12f064ce2c 100644 --- a/contributed_definitions/NXslip_system_set.nxdl.xml +++ b/contributed_definitions/NXslip_system_set.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -14,7 +35,7 @@ Base class for describing a set of crystallographic slip systems. - + diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index dbb8694642..28d2e2c518 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -24,7 +45,7 @@ Spatial filter to filter entries within a region-of-interest based on their position. - + Qualitative statement which specifies which spatial filtering with respective geometric primitives or bitmask is used. These settings are possible: diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml index 4c3f7d3784..dd6df8264d 100644 --- a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -1,6 +1,27 @@ - + - + + @@ -34,25 +55,25 @@ Details how EELS spectra were processed from the detector readings. - + Typically the name of the input, (vendor) file from which all the NXdata instances in this NXspectrum_set_em_eels were loaded during parsing to represent them in e.g. databases. - + An at least as strong as SHA256 hashvalue of the dataset/file which represents the source digitally to support provenance tracking. - + Commercial or otherwise given name to the program which was used to process detector data into the EELS spectra stack and summary. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -77,7 +98,7 @@ - + EELS counts @@ -90,7 +111,7 @@ - + Coordinate along y direction. @@ -103,7 +124,7 @@ - + Coordinate along x direction. @@ -116,7 +137,7 @@ - + Coordinate along energy loss axis. @@ -135,7 +156,7 @@ - + Counts electrons with an energy loss within binned range. @@ -148,7 +169,7 @@ - + Coordinate along energy loss axis. diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml index 08a3c9d458..af0e8dccd4 100644 --- a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -1,6 +1,27 @@ - + - + + @@ -47,25 +68,25 @@ Details how X-ray spectra were processed from the detector readings. - + Typically the name of the input, (vendor) file from which all the NXdata instances in this NXspectrum_set_em_xray were loaded during parsing to represent them in e.g. databases. - + An at least as strong as SHA256 hashvalue of the dataset/file which represents the source digitally to support provenance tracking. - + Commercial or otherwise given name to the program which was used to process detector data into the X-ray spectra stack and summary. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program @@ -87,7 +108,7 @@ - + X-ray photon counts @@ -97,7 +118,7 @@ - + Coordinate along y direction. @@ -107,7 +128,7 @@ - + Coordinate along x direction. @@ -117,7 +138,7 @@ - + Photon energy. @@ -133,7 +154,7 @@ - + X-ray photon counts @@ -143,7 +164,7 @@ - + Photon energy @@ -154,11 +175,11 @@ Details about computational steps how peaks were indexed as elements. - + Given name of the program that was used to perform this computation. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and @@ -176,7 +197,7 @@ X-ray lines should be specified. - + IUPAC notation identifier of the line which the peak represents. @@ -186,7 +207,7 @@ - + List of the names of identified elements. @@ -201,11 +222,11 @@ A composition map is an image whose intensities for each pixel are the accumulated X-ray quanta *under the curve(s)* of a set of peaks. - + Given name of the program that was used to perform this computation. - + Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and @@ -215,7 +236,7 @@ - + A list of strings of named instances of NXpeak from indexing whose X-ray quanta where accumulated for each pixel. @@ -224,7 +245,7 @@ - + Human-readable, given name to the image. @@ -239,7 +260,7 @@ - + Accumulated photon counts for observed element. @@ -249,7 +270,7 @@ - + Coordinate along y direction. @@ -259,7 +280,7 @@ - + Coordinate along x direction. diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index 71668a6480..4e8673932c 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -1,13 +1,33 @@ - + - - - Subclass of NXelectronanalyser to describe the spin filters in photoemission + + + Subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. - Type of spin detector, VLEED, SPLEED, Mott, etc. + Type of spin detector, VLEED, SPLEED, Mott, etc. @@ -22,7 +42,7 @@ - Energy of the spin-selective scattering + Energy of the spin-selective scattering diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 65eb616382..308a23cc6d 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -1,6 +1,27 @@ - + - + + A stage lab can be used to hold, align, orient, and prepare a specimen. @@ -75,7 +96,7 @@ * `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. @@ -86,13 +107,13 @@ 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. diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index b438e2d329..4939c368c1 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,7 +30,7 @@ Settings of a filter to sample entries based on their value. - + Triplet of the minimum, increment, and maximum value which will be included in the analysis. The increment controls which n-th entry to take. diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 23898fe9e7..d7b29a8bab 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Variables used throughout the experiment @@ -16,24 +37,23 @@ - - Application definition for transmission experiments + Application definition for transmission experiments This application definition - + An application definition for transmission. - + Version number to identify which definition of this application definition was used for this entry/data. - + URL where to find further material (documentation, examples) relevant to the application definition. @@ -58,14 +78,14 @@ * The identifier enables to link experiments to e.g. proposals. - + An optional free-text description of the experiment. However, details of the experiment should be defined in the specific fields of this application definition rather than in this experiment description. - + Commercial or otherwise defined given name to the program that was @@ -78,51 +98,51 @@ file(s) with measured data and metadata. - + Website of the software - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. - + Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - + Street address of the user's affiliation. - + Email address of the user. - + Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). - + Telephone number of the user. - + Manufacturer of the instrument. @@ -169,7 +189,7 @@ - + Overall spectral resolution of this spectrometer. If several gratings are employed the spectral resoultion @@ -177,7 +197,7 @@ NXgrating group of this spectrometer. - + Diffraction grating, as could be used in a monochromator. If two or more gratings were used, define the angular @@ -186,17 +206,17 @@ do not overlap. The dispersion should be defined for the entire wavelength range of the experiment. - + Dispersion of the grating in nm/mm used. - + The blaze wavelength of the grating used. - + Overall spectral resolution of the instrument when this grating is used. @@ -231,12 +251,12 @@ - + Response time of the detector - + Detector gain @@ -253,7 +273,7 @@ - + An array of relative scan start time points. @@ -287,7 +307,7 @@ - + The spectrum of the lamp used diff --git a/contributed_definitions/nyaml/NXaberration.yaml b/contributed_definitions/nyaml/NXaberration.yaml new file mode 100644 index 0000000000..f20e29c778 --- /dev/null +++ b/contributed_definitions/nyaml/NXaberration.yaml @@ -0,0 +1,65 @@ +category: base +doc: | + Models for aberrations of electro-magnetic lenses in electron microscopy. + + The notation follows `O. Krivanek et al. (1999) `_ + and `O. Krivanek et al. (2003) `_ + See also `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) + for further details, additional literature, and the unit of the coefficients. + Consult Table 7-2 of Ibid. publication on how to convert between + conventions of different groups/vendors. + +type: group +(NXobject)NXaberration: + c_1_0(NX_FLOAT): + unit: NX_LENGTH + doc: | + Defocus + c_1_2_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Two-fold astigmatism + c_1_2_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Two-fold astigmatism + c_2_1_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Second-order axial coma + c_2_1_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Second-order axial coma + c_2_3_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Threefold astigmatism + c_2_3_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Threefold astigmatism + c_3_0(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spherical aberration + c_3_2_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Star aberration + c_3_2_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Star aberration + c_3_4_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Fourfold astigmatism + c_3_4_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Fourfold astigmatism + c_5_0(NX_FLOAT): + unit: NX_LENGTH + doc: | + Fifth-order spherical aberration diff --git a/contributed_definitions/nyaml/NXaperture.yaml b/contributed_definitions/nyaml/NXaperture.yaml new file mode 100644 index 0000000000..4fea9d7800 --- /dev/null +++ b/contributed_definitions/nyaml/NXaperture.yaml @@ -0,0 +1,55 @@ +category: base +doc: | + A beamline aperture + +type: group +(NXobject)NXaperture: + \@default: + doc: | + 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. + material(NX_CHAR): + doc: | + Absorbing material of the aperture. + description(NX_CHAR): + doc: | + Description of the aperture. + shape(NX_CHAR): + doc: | + Shape of the aperture. + enumeration: [straight slit, curved slit, pinhole, circle, square, hexagon, octagon, bladed, open, grid] + size(NX_NUMBER): + unit: NX_LENGTH + doc: | + The relevant dimension for the aperture, i.e. slit width, pinhole and iris + diameter + depends_on(NX_CHAR): + doc: | + Specifies the position of the aperture by pointing to the last transformation in + the transformation chain in the NXtransformations group. + (NXtransformations): + doc: | + 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 + 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. + (NXpositioner): + doc: | + Stores the raw positions of aperture motors. + (NXgeometry): + doc: | + Location and shape of the aperture. + BLADE_GEOMETRY(NXgeometry): + doc: | + Location and shape of each blade. + (NXnote): + doc: | + Describes any additional information. diff --git a/contributed_definitions/nyaml/NXaperture_em.nxdl.xml b/contributed_definitions/nyaml/NXaperture_em.nxdl.xml deleted file mode 100644 index 97d5323395..0000000000 --- a/contributed_definitions/nyaml/NXaperture_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Details of an individual aperture for beams in electron microscopy. - - - - Given name/alias of the aperture. - - - - - Relevant value from the control software. - - This is not always just the diameter of (not even in the case) - of a circular aperture. Usually it is a mode setting value which - is selected in the control software. - Which settings are behind the value should be defined - for now in the description field, if these are known - in more detail. - - - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details. Alternatively a free-text field. - - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - diff --git a/contributed_definitions/nyaml/NXapm.nxdl.xml b/contributed_definitions/nyaml/NXapm.nxdl.xml deleted file mode 100644 index 4f5163c6ff..0000000000 --- a/contributed_definitions/nyaml/NXapm.nxdl.xml +++ /dev/null @@ -1,1399 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). Needs - to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Application definition for atom probe and field ion microscopy experiments. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - Commercial or otherwise given name to the program which was used - to create the original results file of the atom probe experiment. - This file and program should not be confused with downstream - processing operations and file format conversion tasks. - - Atom probe microscopy experiments are except for still very much cases - controlled via commercial software. Such software is designed as an - integrated acquisition and instrument control software. - - For AMETEK/Cameca local electrode atom probe (LEAP) instruments the - least processed (rawest) numerical results and metadata are stored - in so-called RHIT and HITS files, which are proprietary and the - specifications of which are not publicly documented. - - Supplementary metadata are kept in a database which is connected - to the instrument control software and synced with the experiment - while signal is being detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also to resolve isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - Therefore, this application definition documents not only the measurement - but also the key post-processing steps which transform the proprietary - data into a tomographic reconstruction with ranging definitions. - - Future guidance by the vendors could improve this description to cover - a substantial larger number of eventually metadata that so far - are not publicly documented and accessible in an open-source manner. - - - - Program 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. - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow to store the - entire set of such interrupted runs to be stored and covered. However, - this is not because of a technical limitation within NeXus but - because we have not seen a covering use case based on which we could - have implemented and conceptualized this. Atom probers are invited to - contact the respective people in the FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin from where the specimen was cut. - In cases where the specimen was e.g. site-specifically cut from - samples or in cases of an instrument session during which multiple - specimens are loaded, the name has to be descriptive enough to resolve - which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how specimens were - cut/prepared from samples in the sample history. This field must - not be used for an alias of the specimen. Instead, use short_title. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Possibility to give an abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - A local electrode guiding the ion flight path. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - Given name/alias. - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - Name of the control software of the microscope - used during acquisition (e.g. IVAS/APSuite). - - - - Program 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. - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - - - - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - Given name of the program that was used to perform this computation. - Similar comments as voltage_and_bowl_correction apply. - - - - Program 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. - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml b/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml deleted file mode 100644 index 78ce6703d2..0000000000 --- a/contributed_definitions/nyaml/NXapm_input_ranging.nxdl.xml +++ /dev/null @@ -1,41 +0,0 @@ - - - - - Metadata to ranging definitions made for a dataset in atom probe microscopy. - - Ranging is the process of labeling time-of-flight data with so-called iontypes - which ideally specify the most likely ion/molecular ion evaporated within a - given mass-to-charge-state-ratio value interval. - - The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE - iontype (or unranged ions) represents the default iontype. - The ID of this special iontype is always reserved as 0. Each ion - is assigned to the UNKNOWNTYPE by default. Iontypes are assigned - by checking if the mass-to-charge-state-ratio values of an ion matches - to any of the defined mass-to-charge-state-ratio intervals. - - - - Path and name of the NeXus/HDF5 file which stores ranging definitions. - - - - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - - - - - - Name of the group (prefix to the individual ranging definitions) inside - the file referred to by filename which points to the specific ranging - definition to use. - An HDF5 file can store multiple ranging definitions. Using an ID is - the mechanism to distinguish which specific ranging (version) will - be processed. Reconstruction and ranging IDs can differ. - They specify different IDs. - - - diff --git a/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml deleted file mode 100644 index 2b8397512b..0000000000 --- a/contributed_definitions/nyaml/NXapm_input_reconstruction.nxdl.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - - - Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. - - - - Name of the (NeXus)/HDF5 file which stores reconstructed ion position - and mass-to-charge-state ratios. Such an HDF5 file can store multiple - reconstructions. Using the information within the dataset_name fields - is the mechanism whereby paraprobe decides which reconstruction to - process. With this design it is possible that the same HDF5 - file can store multiple versions of a reconstruction. - - - - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - - - - - - Name of the dataset inside the HDF5 file which refers to the - specific reconstructed ion positions to use for this analysis. - - - - - Name of the dataset inside the HDF5 file which refers to the - specific mass-to-charge-state-ratio values to use for this analysis. - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml deleted file mode 100644 index 05f703d1a2..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.nxdl.xml +++ /dev/null @@ -1,409 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - - - - - Number of clustering algorithms used. - - - - - Number of different iontypes to distinguish during clustering. - - - - - Configuration of a paraprobe-clusterer tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - How many tasks to perform? - - - - - This process maps results from cluster analyses performed with IVAS/APSuite - into an interoperable representation. Specifically in this process - paraprobe-clusterer takes results from clustering methods from other tools - of the APM community, like IVAS/APSuite. These results are usually reported - in two ways. Either as an explicit list of reconstructed ion positions. - In the case of IVAS these positions are reported through a text file - with a cluster label for each position. - - Alternatively, the list of positions is reported, as it is the case for - AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly - only in the following way: The mass-to-charge-state ratio column of a - what is effectively a file formatted like POS is used to assign a hypothetical - mass-to-charge value which resolves a floating point representation - of the cluster ID. - - Another case can occur where all disjoint floating point values, - i.e. here cluster labels, are reported and then a dictionary is created - how each value matches to a cluster ID. - - In general the cluster ID zero is reserved for marking the dataset - as to not be assigned to any cluster. Therefore, indices of disjoint - clusters start at 1. - - - - - - - - - AMETEK/Cameca results of cluster analyses, like with the maximum- - separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ - are stored as an improper POS file: This is a matrix of floating - point quadruplets, one for each ion and as many quadruplets as - ions were investigated. The first three values encode the position - of the ion. The fourth value is an improper mass-to-charge-state-ratio - value which encodes the integer identifier of the cluster as a floating - point number. - - - - - - Specifies if the tool should try to recover for each position the closest - matching position from dataset/dataset_name_reconstruction (within - floating point accuracy). This can be useful for instance when users - wish to recover the original evaporation ID, which IVAS/AP Suite drops - for instance when writing their *.indexed.* cluster results POS files. - - - - - - This process performs a cluster analysis on a reconstructed dataset - or a portion of the reconstruction. - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains the ion distances. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How should iontypes be interpreted/considered during the cluster analysis. - Different options exist how iontypes are interpreted (if considered at all) - given an iontype represents in general a (molecular) ion with different isotopes - that have individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - - This is relevant as in atom probe we have the situation that a ion - of a molecular ion with more than one nuclid, say Ti O for example - is counted such that although there is a single TiO molecular ion - at a position that the cluster has two members. This multiplicity - affects the size of the feature and chemical composition. - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - - - - - - - - - Settings for DBScan clustering algorithm. For original details about the - algorithms and (performance-relevant) details consider: - - * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ - * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ - - For details about how the DBScan algorithms is the key behind the - specific modification known as the maximum-separation method in the - atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - As an example we may define eps with ten entries and min_pts with - three entries. If high_throughput_method is tuple the analysis is - invalid as we have an insufficient number of min_pts for the ten - eps values. - By contrast, for combinatorics paraprobe-clusterer will run three - individual min_pts runs for each eps value, resulting in a total - of 30 analyses. - As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ - would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) - eps values, min_pts one, and high_throughput_method set to combinatorics. - - - - - - - - - Array of epsilon (eps) parameter values. - - - - - - - - Array of minimum points (min_pts) parameter values. - - - - - - - - - Settings for the OPTICS clustering algorithm. - - * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - - - - - - - - - Array of minimum points (min_pts) parameter values. - - - - - - - - Array of maximum epsilon (eps) parameter values. - - - - - - - - - Settings for the HPDBScan clustering algorithm. - - * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ - * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ - - See also this documentation for details about the parameter. - Here we use the terminology of the hdbscan documentation. - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - - - - - - - - - Array of min_cluster_size parameter values. - - - - - - - - Array of min_samples parameter values. - - - - - - - - Array of cluster_selection parameter values. - - - - - - - - Array of alpha parameter values. - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml deleted file mode 100644 index dcee7fae96..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.nxdl.xml +++ /dev/null @@ -1,226 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration/settings of a paraprobe-distancer software tool run. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - How many individual analyses should the tool execute. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Compute for all filtered points, e.g. ions of the point set - the shortest Euclidean distance to the closest triangle of the - set of triangles. The triangles can formed a closed surface mesh. - Distances are not simple distances based on normal projections but - giving an exact solution. - - - - Paraprobe-distancer enables the computation of the Euclidean shortest - distance for each member of a set of points against a set of triangles. - In contrast to comparable methods used in atom probe the here computed - distance is not simply the projected distance to one of the triangles - but the more costly but robust computation of the distance between - a point and a triangle. - - The triangles can represent for instance the facets of a triangulated - surface mesh of a model for the edge of the dataset. Such a model can - be computed with paraprobe-surfacer. Alternatively, the triangles can - be those from the set of all facets for a set of convex hulls, alpha-shapes, - or alpha wrappings about three-dimensional objects like precipitates - (computed with e.g. paraprobe-nanochem). - - Currently, the tool does not check if the respectively specified - triangle sets are consistent, what their topology is, or whether or - not they are consistently oriented. - Each dataset that is referred to in the list_of _dataset_names_vertices - should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred - to in the list_of_dataset_names_facet_indices should be an - (Nfacets, 3) array of NX_UINT. - Facet indices refer to vertex indices. These need to start at zero - and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and vertices are indexed thus implicitly. - Facet normal vectors have to be also an array - of shape (Nfacets, 3) of NX_FLOAT. - - - - How many triangle sets to consider. - - - - - List of triangle sets. This design allows users to combine - multiple triangle sets. - - - - Name of the HDF5 file(s) which contain(s) vertex coordinates - and facet indices to describe the desired set of triangles. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility. - - - - - - Absolute HDF5 path to the dataset which - specifies the array of vertex positions. - - - - - Absolute HDF5 path to the dataset which - specifies the array of facet indices. - - - - - Absolute HDF5 path to the dataset which - specifies the array of facet normal vectors. - - - - - - - Specifies for which ions/points the tool will compute distances. - The purpose of this setting is to avoid unnecessary computations - when the user requests to only compute distances of ions within a - threshold distance to the triangle soup. - - By default the distances are computed for all ions; however - the setting skin enables to compute distances only for those - ions which are not farther away located to a triangle - than threshold_distance. - - - - - - - - - Maximum distance for which distances are computed when method is skin. - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml deleted file mode 100644 index d25de29237..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.nxdl.xml +++ /dev/null @@ -1,306 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-intersector tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - - - - - For now a support field for the tool to identify how many individual - analyses the tool should execute as part of the analysis. - - - - - Tracking volume_volume_spatial_correlation is the process of building logical - relations between volumetric features based on meshes, their proximity and - eventual intersections. Volumetric overlap and proximity of volumetric - features is identified for members of sets of features to members of - other sets of volumetric features. - Specifically, for each time step k pairs of sets are compared: - Members of a so-called current_set to members of a so-called next_set. - Members can be different types of volumetric features. - In the analysis of M. Kuehbach et al. specifically features can be - so-called objects (closed non-degnerated polyhedra representing watertight - parts of an e.g. iso-surface) and/or proxies. Proxies are computed - doppelganger/replacement meshes for parts of an iso-surface which initially - were not resulting in watertight meshes because objects at the edge - of the dataset or incompletely measured or truncated objects. - - - - Specifies the method whereby to decide if two objects intersect volumetrically. - For reasons which are detailed in the supplementary material of - `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by - default assumes that two objects intersect if they share at least one - ion with the same evaporation ID (shared_ion). - Alternatively, with specifying tetrahedra_intersections, - the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks - for at least one pair of intersecting tetrahedra to identify if two objects - intersect or not. - - However, we found that these geometrical analyses can result in corner - cases which the currently used library (TetGen) was not unable to - tetrahedralize successfully. These cases were virtually always - associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. - Finding more robust methods for computing intersections between - not necessarily convex polyhedra might improve the situation in the future. - - - - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) intersect volumetrically. - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) lie closer to one another than the - threshold_proximity. - - - - - Specifies if the tool evaluates, ones all tracking tasks were - successfully completed, how intersecting or proximity related - objects build sub-graphs. This is the feature which enabled - M. Kühbach et al. 2022 the high-throughput analyses of how many - objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order. For these analyses to work - has_object_volume needs to be activated. - - - - - The maximum Euclidean distance between two objects below which - both objects are still considered within proximity. - - - - - Specifies if the tool stores the so-called forward relations between - nodes representing members of the current_set to nodes representing - members of the next_set. - - - - - Specifies if the tool stores the so-called backward relations between - nodes representing members of the next_set to nodes representing - members of the current_set. - - - - - Current set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the current_set. - The meshes were generated as a result of some other meshing process. - - - - This identifier can be used to label the current set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in M. Kühbach - et al. 2022, this identifier takes the role of the time variable k. - - - - - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - current_set. - - - - - - Descriptive category explaining what these features are. - - - - - - - - - - - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object<ID>/polyhedron. - - - - - Array of identifier whereby the path to the geometry data - can be interferred automatically. - - - - - - - Next set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the next_set. - The meshes were generated as a result of some other meshing process. - - - - This identifier can be used to label the next_set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in M. Kühbach - et al. 2022, this identifier takes the role of the time variable k+1. - - - - - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - next_set. - - - - - - Descriptive category explaining what these features are. - - - - - - - - - - - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object<ID>/polyhedron. - - - - - Array of identifier whereby the path to the geometry data - can be interferred automatically. - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml deleted file mode 100644 index a06d90cd75..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.nxdl.xml +++ /dev/null @@ -1,1019 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - How many iontypes does the delocalization filter specify. - - - - - How many disjoint control points are defined. - - - - - How many iontypes does the interface meshing iontype filter specify. - - - - - How many DCOM iterations. - - - - - Maximum number of atoms per molecular ion. - - - - - Configuration of a paraprobe-nanochem tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - - - - - How many individual analyses should the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject a previously computed triangle soup or - triangulated surface mesh representing a model (of the surface) of - the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - - - - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the edge of the dataset. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - - - - - - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains the ion distances. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - For now a support field for the tool to identify how many individual - delocalization analyses for the above-mentioned dataset and supplementary - files are executed as part of the high-throughput analysis. - - - - - Discretization of the ion point cloud on a three-dimensional grid. - - - - Delocalization in the field of atom probe microscopy is the process - of discretizing a point cloud. By default the tool computes a full - kernel density estimation of decomposed ions to create one discretized - field for each element. - - Although, this uses an efficient multithreaded algorithm, - the computation is costly. Therefore, it can be advantageous for users - to load an already computed delocalization. This can be achieved with - the load_existent option. - When using this option the user is responsible to assure that the - settings which were used for computing this already existent delocalization - are specified in the same manner as they were. - - - - - - - - - Matrix of isotope vectors representing iontypes. - The filter specifies a matrix of isotope_vectors which is the most - general approach to define if and how many times an ion is counted. - Currently, paraprobe_nanochem performs a so-called atomic decomposition - of all iontypes. Specifically, the tool interprets of how many - elements/atoms a molecular ion is composed; and thus determines the - atoms multiplicity with respect to the iontype. - - Let's take the hydroxonium H3O+ molecular ion as an example: - It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen - is three whereas that of oxygen is one. Therefore in an atomic - decomposition computation of the iso-surface each H3O+ ion adds - three hydrogen counts. This is a practical solution which accepts - the situation that during an atom probe experiment not each bond - of each ion/a group of neighboring atoms is broken but molecular - ions get detected. The exact ab-initio details depend on the local - field conditions and thus also the detailed spatial arrangement - of the atoms and their own electronic state and that of the neighbors - before and upon launch. - Being able to measure the information for such sites only as - molecular ions causes an inherent information loss with respect to the - detailed spatial arrangement. This information loss is more relevant - for local electrode atom probe than for field ion microscopy setting - how precisely the atomic positions can be reconstructed. - Accounting for multiplicities assures that at least the - compositional information is analyzed. - - - - - - - - - List of individual grid resolutions to analyse. - Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with - an edge length of values in gridresolutions. - - - - - Half the width of a (2n+1)^3 cubic kernel of voxel beyond - which the Gaussian Ansatz function will be truncated. - Intensity beyond the kernel is refactored into the kernel via - a normalization procedure. - - - - - Variance of the Gaussian Ansatz kernel sigma_x = sigma_y = 2*sigma_z. - - - - - How should the results of the kernel-density estimation be computed - into quantities. By default the tool computes the total number - (intensity) of ions or elements. Alternatively the tool can compute - the total intensity, the composition, or the concentration of the - ions/elements specified by the white list of elements in each voxel. - - - - - - - - - - - Specifies if the tool should report the delocalization 3D field values. - - - - - Optional computation of iso-surfaces after each computed delocalization - to identify for instance objects in the microstructure - (line features, interfaces, precipitates). - - - - As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., - the handling of triangles at the edge of the dataset requires - special attention. Especially for composition-normalized - delocalization it is possible that the composition increases - towards the edge of the dataset because the quotient of two numbers - which are both smaller than one is larger instead of smaller than - the counter. By default, the tool uses a modified marching cubes - algorithm of Lewiner et al. which detects if voxels face such a - situation. In this case, no triangles are generated for such voxels. - Alternatively, (via setting keep_edge_triangles) the user can - instruct the tool to not remove these triangles at the cost of bias. - - Specifically, in this case the user should understand that all - objects/microstructural features in contact with the edge of the - dataset get usually artificial enlarged and their surface mesh - often closed during the marching. This closure however is artificial! - It can result in biased shape analyses for those objects. - The reason why this should in general be avoided is a similar - argument as when one analyzes grain shapes in orientation microscopy - via e.g. SEM/EBSD. Namely, these grains, here the objects at the - edge of the dataset, were not fully captured during e.g. limited - field of view. - Therefore, it is questionable if one would like to make - substantiated quantitative statements about them. - - Thanks to collaboration with the V. V. Rielli and S. Primig, though, - paraprobe-nanochem implements a complete pipeline to - process even these objects at the edge of the dataset. Specifically, - the objects are replaced by so-called proxies, i.e. replacement - objects whose holes on the surface mesh have been closed if possible - via iterative mesh and hole-filling procedures with fairing operations. - In the results of each paraprobe-nanochem run, these proxy objects - are listed separately to allow users to quantify and analyze in - detail the differences when accounting for these objects or not. - Especially this is relevant in atom probe microscopy are small - in the sense that they contain few (many a few dozen) objects. - Even though such a dataset may give statistically significant - results for compositions this does not mean it necessarily yields - also statistically significant and unbiased results for three-dimensional - object analyses. Being able to quantify these effects and making - atom probers aware of these subtleties was one of the main reasons - why the paraprobe-nanochem tool was implemented. - - - - - - - - - The ion-to-edge-distance that is used in the analyses of objects - (and proxies) to identify whether these are inside the dataset or - close to the edge of the dataset. If an object has at least one ion - with an ion-to-edge-distance below this threshold, the object is - considered as one which lies close to the edge of the dataset. - This implements essentially a distance-based approach to solve - the in general complicated and involved treatment of computing - volumetric intersections between not-necessarily convex - closed 2-manifolds. In fact, such computational geometry analyses - can face numerical robustness issues as a consequence of which a - mesh can be detected as lying completely inside a dataset although - in reality it is epsilon-close only, i.e. almost touching only - the edge (e.g. from inside). - Practically, humans would state in such case that the object is - close to the edge of the dataset; however mathematically the object - is indeed completely inside. - In short, a distance-based approach is rigorous and more flexible. - - - - - Array of iso-contour values. For each value the tool computes - an iso-surface and performs subsequent analyses. - The unit depends on the choice for the normalization of the - accumulated ion intensity values per voxel: - - * total, total number of ions, irrespective their iontype - * candidates, total number of ions with type in the isotope_whitelist. - * composition, candidates but normalized by composition, i.e. at.-% - * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - - - - - Specifies if the tool should report the triangle soup which represents - each triangle of the iso-surface complex. - Each triangle is reported with an ID specifying to which triangle - cluster (with IDs starting at zero) the triangle belongs. - The clustering is performed with a modified DBScan algorithm. - - - - - Specifies if the tool should analyze for each cluster of triangles - how they can be combinatorially processed to describe a closed - polyhedron. Such a closed polyhedron (not-necessarily convex!) - can be used to describe objects with relevance in the microstructure. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In fact, inaccuracies in the - reconstructed positions cause inaccuracies in all downstream - processing operations. Especially the effect on one-dimensional - spatial statistics like nearest neighbor correlation functions these - effects were discussed in the literature - `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_ - In continuation of these thoughts this applies also to reconstructed - objects. A well-known example is the discussion of shape deviations - of Al3Sc precipitates in aluminium alloys which in reconstructions - can appear as ellipsoids although they should be almost spherical, - depending on their size. - - - - - Specifies if the tool should report a triangulated surface mesh - for each identified closed polyhedron. It is common that a - marching cubes algorithm creates iso-surfaces with a fraction of very - small sub-complexes (e.g. small isolated tetrahedra). - - These can be for instance be small tetrahedra/polyhedra about the - center of a voxel of the support grid on which marching cubes operates. - When these objects are small, it is possible that they contain no ion; - especially when considering that delocalization procedures smoothen - the positions of the ions. Although these small objects are interesting - from a numerical point of view, scientists may argue they are not worth - to be reported: - Physically a microstructural feature should contain at least a few - atoms to become relevant. Therefore, paraprobe-nanochem by default - does not report closed objects which bound not at least one ion. - - - - - Specifies if the tool should report properties of each closed - polyhedron, such as volume and other details. - - - - - Specifies if the tool should report for each closed polyhedron an - approximately optimal bounding box fitted to all triangles of the - surface mesh of the object and ion positions inside or on the - surface of the mesh. - This bounding box informs about the closed object's shape - (aspect ratios). - - - - - Specifies if the tool should report for each closed polyhedron - all evaporation IDs of those ions which lie inside or on the - boundary of the polyhedron. This information can be used e.g. - in the paraprobe-intersector tool to infer if two objects share - common ions, which can be interpreted as an argument to assume - that the two objects intersect. - - Users should be aware that two arbitrarily closed polyhedra - in three-dimensional space can intersect but not share a common ion. - In fact, the volume bounded by the polyhedron has sharp edges. - When taking two objects, an edge of one object may for instance - pierce into the surface of another object. In this case the - objects partially overlap / intersect volumetrically; - however this piercing might be so small or happening in the volume - between two ion positions and thus sharing ions is a sufficient - but not a necessary condition for object intersections. - - Paraprobe-intersector implements a rigorous alternative to handle - such intersections using a tetrahedralization of closed objects. - However, in many practical cases, we found through examples that there - are polyhedra (especially when they are non-convex and have almost - point-like) connected channels, where tetrahedralization libraries - have challenges dealing with. In this case checking intersections - via shared_ions is a more practical alternative. - - - - - Specifies if the tool should report if a (closed) object has - contact with the edge of the dataset. For this the tool currently - inspects if the shortest distance between the set of triangles of the - surface mesh and the triangles of the edge model is larger than the - edge_threshold. If this is the case, the object is assumed to be - deeply embedded in the interior of the dataset. Otherwise, the object - is considered to have an edge contact, i.e. it is likely affected - by the fact that the dataset is finite. - - - - - Specifies if the tool should analyze a doppelganger/proxy mesh for - each cluster of triangles whose combinatorial analysis according - to has_object showed that the object is not a closed polyhedron. - Such proxies are closed via iterative hole-filling, mesh refinement, - and fairing operations. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In most cases objects, - like precipitates in atom probe end up as open objects because - they have been clipped by the edge of the dataset. Using a proxy is - then a strategy to still be able to account for these objects. - Nevertheless users should make themselves familiar with the - potential consequences and biases which this can introduce - into the analysis. - - - - - Like has_object_geometry but for the proxies. - - - - - Like has_object_properties but for the proxies. - - - - - Like has_object_obb but for the proxies. - - - - - Like has_object_ions but for the proxies. - - - - - Like has_object_edge_contact but for the proxies. - - - - - Specifies if the tool should report for each closed object a - (cylindrical) region of interest placed, centered, and align - with the local normal for each triangle of the object. - - - - - Specifies if the tool should report for each ROI that was placed - at a triangle of each object if this ROI intersects the edge of - the dataset. Currently paraprobe-nanochem supports cylindrical - ROIs. A possible intersection of these with the edge of the - dataset, i.e. the triangulated surface mesh model for the edge - is performed. This test checks if the cylinder intersects with - a triangle of the surface mesh. If this is the case, the ROI is - assumed to make edge contact, else, the ROI is assumed to have - no edge contact. - - This approach does not work if the ROI would be completely - outside the dataset. Also in this case there would be - no intersection. For atom probe this case is practically - irrelevant because for such a ROI there would also be no ion - laying inside the ROI. Clearly it has thus to be assumed that - the edge model culls the entire dataset. Instead, if one would - cut a portion of the dataset, compute an edge model for this - point cloud, it might make sense to place a ROI but in this - case the edge contact detection is not expected to work properly. - - - - - - Analyses of interfacial excess. - - - - Interfacial excess computations are performed for local regions-of-interests - (ROIs) at selected facets or interface patch. - For instance many scientist compute the interfacial excess for - selected triangle facets of a created iso-surface. In this case, - computed iso-surfaces of paraprobe could be used. An example are triangle - facet sets about closed polyhedra, for instance to compute interfacial - excess related to phase boundaries of second-phase precipitates. - - Another example are free-standing triangle patches of the iso- - surfaces which paraprobe creates. These could be characterized - for interfacial excess. The sub-routines during iso-surface - computations already include a procedure to automatically align - local triangle normals based on the gradients of e.g. composition - fields. In this case, these triangulated surface patches - could also be used as a source for computing interfacial - excess. - - Often scientists face situations, though, in which there is no - immediately evident composition gradient across the interface - (grain or phase boundary) and orientation information about the - adjoining crystal is neither available nor reliable enough. - - In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method - to manually place control points and run an automated tessellation-based - algorithm to create a triangulated surface patch, i.e. a model of the - location of the interface. In a post-processing step this triangle - set can then be used to compute again interfacial excess in an - automated manner by placing ROIs and aligning them with - consistently precomputed triangle normals. - - A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ - They used first a deep-learning method to locate planar triangulated - grain boundary patches. These are eventually processed further - with manual editing of the mesh via tools like Blender. - Once the user is satisfied with the mesh, the computations of interfacial - excess reduce again to an automated placing of ROIs, computations - of the distributing of ions to respective ROIs and - reporting the findings via plotting. - - Yet another approach for constructing an triangulated surface patch - of an interface is to use point cloud processing methods which have - been proposed in the laser-scanning, geoinformatics, and CAD community. - Different computational geometry methods are available for fitting - a parameterized surface to a set of points, using e.g. non-uniform - rational B-splines (NURBS) and triangulating these according - to prescribed mesh quality demands. - - The advantage of these methods is that they can be automated and - pick up curved interface segments. The disadvantage is their often - strong sensitivity to parameterization. As a result also such methods - can be post-processed to yield a triangulated surface patch, - and thus enable to run again automated ROI placement methods. - For example like these which were explored for the use case of - iso-surfaces with closed objects and free-standing - surface patches that delineate regions of the dataset with a - pronounced composition gradient normal to the interface. - - This summary of the situations which atom probers can face when - requesting for interfacial excess computations, substantiates there - exists a common set of settings which can describe all of these methods - and, specifically, as here exemplified, the automated placing - and alignment functionalities for ROIs that is an important - step all these workflows. - - Specifically, paraprobe-nanochem operates on an already existent - triangle set. - - - - - - - - - The interface model is the result of a previous (set of) processing - steps as a result of which the user has created a triangulated - surface mesh (or a set of, eventually connected such meshes). - These interface models are useful, if not required, in cases when - there is no other independent approach to locate an interface. - - These are cases when insufficient crystallographic latent - information is available and also no consistent concentration - gradient detectable across the interface. It is then the users' - responsibility to deliver a triangle mesh of the interface model. - - - - Filename to HDF5 file which contain vertex coordinates, facet indices, - facet unit normals. The user is responsible for the triangle - and winding order to be consistent. - Input is expected as a matrix of the coordinates for all disjoint - vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. - Input is expected to include also a matrix of facet indices - referring to these disjoint vertices. This matrix should be a - (Nfacets, 3)-shaped array of NX_UINT. Further required input - is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit - normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed - vertex unit normals. Vertex indices need to start at zero and - must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - - - - - Absolute HDF5 path to the dataset which specifies the - array of vertex positions. - - - - - Absolute HDF5 path to the dataset which specifies the - array of facet indices. - - - - - Absolute HDF5 path to the dataset which specifies the - array of facet signed unit normals. - - - - - Absolute HDF5 path to the dataset which specifies the - array of vertex signed unit normals. - - Users should be aware that triangulated surface meshes are - only approximations to a given complex, eventually curved shape. - Consequently, computations of normals show differences between - the vertex and facet normals. Vertex normals have to be - interpolated from normals of neighboring facets. Consequently, - these normals are affected by the underlying parameterization - and curvature estimation algorithms, irrespective of how - contributions from neighboring facets are weighted. By contrast, - facet normals are clearly defined by the associated triangle. - Their disadvantage is that they the normal field has discontinuities - at the edges. In general the coarser an object is triangulated - the more significant the difference becomes between computations - based on facet or vertex normals. - Paraprobe-nanochem works with facet normals as it can use - parts of the numerical performance gained by using cutting - edge libraries to work rather with finer meshes. - - - - - - - - Create a simple principle component analysis (PCA) to mesh a - free-standing interface patch through a point cloud of decorating solutes. - These models can be useful for quantification of Gibbsian - interfacial excess for interfaces where iso-surface based methods - may fail or closed objects from iso-surfaces are not desired or - when e.g. there are no substantial or consistently oriented - concentration gradients across the interface patch. - - The interface_meshing functionality of paraprobe-nanochem can be useful - when there is also insufficient latent crystallographic information - available that could otherwise support modelling the interface, - via e.g. ion density traces in field-desorption maps, as were used and - discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ - or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ - - It is noteworthy that the method here used is conceptually very similar - in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ - Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. - However, both of these previous works neither discuss in detail - nor implement inspection functionalities which enable a detection of - potential geometric inconsistencies or self-interactions of the - resulting DCOM mesh. This is what paraprobe-nanochem implements - via the Computational Geometry Algorithms Library. - - - - Method how to initialize the PCA: - - * default, means based on segregated solutes in the ROI - * control_point_file, means based on reading an external list of - control points, currently coming from the Leoben APT_Analyzer. - - The control_point_file is currently expected with a specific format. - The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ - to create a control_point_file which can be parsed by paraprobe-parmsetup - to match the here required formatting in control_points. - - - - - - - - - The name of the control point file to use. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - - - - - X, Y, Z coordinates of disjoint control point read from - an HDF5 file named according to control_point_file. - - - - - - - - - Method used for identifying and refining the location of the - interface. Currently, paraprobe-nanochem implements a PCA followed - by an iterative loop of isotropic mesh refinement and DCOM step(s), - paired with self-intersection detection in a more robust - implementation. - - - - - - - - Specify the types of those ions which decorate the interface and - can thus be assumed as markers for locating the interface and - refining its local curvature. - - - - Array of iontypes to filter. The list is interpreted as a whitelist, - i.e. ions of these types are considered the decorating species (solutes). - - - - - - - - - How many times should the DCOM and mesh refinement be applied? - - - - - Array of decreasing positive not smaller than one nanometer real values - which specify how the initial triangles of the mesh should be iteratively - refined by edge splitting and related mesh refinement operations. - - - - - - - - Array of decreasing positive not smaller than one nanometer real values - which specify the radius of the spherical region of interest within - which the DCOM algorithm decides for each vertex how the vertex will - be eventually relocated. The larger the DCOM radius is relative to - the target_edge_length the more likely it is that vertices will be - relocated so substantially that eventually triangle self-intersections - can occur. - - - - - - - - Array of integers which specify for each DCOM step how many times - the mesh should be iteratively smoothened. - - Users should be aware the three array target_edge_length, - target_dcom_radius, and target_smoothing_step are interpreted in the - same sequence, i.e. the zeroth entry of each array specifies the - values to be used in the first DCOM iteration. The first entry of - each array those for the second DCOM iteration and so on and so forth. - - - - - - - - - Functionalities for placing regions-of-interest (ROIs) in the dataset - or at specific microstructural features to characterize composition - profiles and cumulated profiles for quantification of interfacial excess. - Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed - across the triangulated surface of a user-defined mesh. - ROIs are placed at the barycenter of the triangular facet. - - The tool can be instructed to orient the profile for each ROIs with - the positive normal of the triangle facet normals. Profiles are - computed for each ROI and facet triangle. The code will test which - ROIs are completely embedded in the dataset. - Specifically, in this test the tool evaluates if the ROI cuts at least - one triangle of the triangulated surface mesh of the edge of the dataset. - If this is the case the ROI will be considered close to the edge - (of the dataset) and not analyzed further; else the ROI will be - processed further. - Users should be aware that the latter intersection analysis is strictly - speaking not a volumetric intersection analysis as such one is much - more involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder piercing - or laying completely inside the polyhedron. For this the polyhedron has - to be tessellated into convex polyhedra as otherwise tests like the - Gilbert-Johnson-Keerthi algorithm would not be applicable. - - Specifically, the tool computes atomically decomposed profiles. - This means molecular ions are split into atoms/isotopes with respective - multiplicity. As an example an H3O+ molecular ion contains three - hydrogen and one oxygen atom respectively. The tool then evaluates - how many ions are located inside the ROI or on the surface of the - ROI respectively. All atom types and the unranged ions are distinguished. - As a result, the analyses yield for each ROI a set of sorted lists of - signed distance values. Currently, the distance is the projected - distance of the ion position to the barycenter of the triangle - and triangle plane. - - This will return a one-dimensional profile. Post-processing the set - of atom-type-specific profiles into cumulated profiles enable the - classical Krakauer/Seidman-style interfacial excess analyses. - Furthermore, the tool can be instructed to compute for each - (or a selected sub-set of facet) a set of differently oriented profiles. - - - - The feature mesh enables the injection of previously computed triangle - soup or mesh data. Such a mesh can be the model for a grain- or phase - boundary patch (from e.g. interface_meshing) jobs. - - - - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the feature. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details consistently oriented facet - normals of the facets. - - - - - - - - - - The tool enables to inject precomputed distance information for each - point which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains ion distances. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically contains - these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - Which type of distance should be reported for the profile. - - - - - - - - In which directions should the tool probe for each ROI. - - - - - - - - For each ROI, how high (projected on the cylinder axis) - should the cylindrical ROI be. - - - - - For each ROI, how wide (radius) should the cylindrical ROI be. - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml deleted file mode 100644 index f65ab05e6b..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.nxdl.xml +++ /dev/null @@ -1,266 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of isotopes to consider as building blocks for searching - molecular ions. - - - - - The number of compositions to consider for molecular ion search tasks. - - - - - Configuration of a paraprobe-ranger tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - How many task to perform? - - - - - - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - - - - - How many molecular_ion_search processes should - the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A list of pairs of number of protons and either the value 0 (per row) - or the mass number for all those isotopes which are assumed present - in a virtual specimen. - The purpose of this field is to compute also composition-weighted - products to yield a simple estimation which could potentially help - scientists to judge if certain molecular ions are to be expected. - The corresponding setting store_composition_weighted_product should be - activated. - - - - - - - - - A list of pairs of number of protons and mass number for all isotopes - to consider that can be composed into (molecular) ions, during the - recursive molecular_ion_search. - - - - - - - - - The mass-to-charge-state ratio interval in which - all molecular ions are searched. - - - - - - - - The maximum charge that a molecular ion should have. - - - - - The maximum number of isotopes of which the molecular ion - should be composed. Currently this must not be larger than 32. - - Users should be warned that the larger the maximum_charge and - especially the larger the maximum_number_of_isotopes is chosen, - the eventually orders of magnitude more costly the search becomes. - - This is because paraprobe-ranger computes really all (at least) - theoretically possible combinations that would have likely a - mass-to-charge-state ratio in the specified mass_to_charge_interval. - It is the challenge in atom probe to judge which of these (molecular) - ions are feasible and also practically possible. This tool does not - answer this question. - - Namely, which specific molecular ion will evaporate, remain stable - during flight and becomes detected is a complicated and in many cases - not yet in detail understood phenomenon. The ab-initio conditions - before and during launch, the local environment, arrangement and field - as well as the flight phase in an evacuated but not analysis chamber - with a complex electrical field, eventual laser pulsing in place, - temperature and remaining atoms or molecules all can have an effect - which iontypes are really physically evaporating and detected. - - - - - Report the accumulated atomic mass from each isotope building the ion. - Accounts for each identified ion. - Relatistic effects are not accounted for. - - - - - Report the product of the natural abundances from each isotope building - the ion. Accounts for each identified ion. - - The value zero indicates it is not possible to build such molecular ion - from nuclids which are all observationally stable. - Very small values can give an idea/about how likely such a molecular ion - is expected to form assuming equal probabilities. - - However in atom probe experiments this product has to be modified - by the (spatially-correlated) local composition in the region from - which the ions launch because the formation of a molecular ion depends - as summarized under maximum_number_of_isotopes on the specific - quantum-mechanical configuration and field state upon launch - or/and (early state) of flight respectively. - We are aware that this modified product can have a substantially - different value than the natural_abundance_product. - - Natural abundancies folded with the estimated compositions of the - specimen can differ by orders of magnitude. - - - - - Report the charge state of the ions. - - - - - Report if identified ions should be characterized - wrt to their number of disjoint isotopes. - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml deleted file mode 100644 index da279e84cf..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.nxdl.xml +++ /dev/null @@ -1,334 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - - - - - Number of different sources iontypes to distinguish. - - - - - Number of different target iontypes to distinguish. - - - - - Configuration of a paraprobe-spatstat tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distances of each ion to a - representation of the edge of the dataset which can be used to - control and substantially reduce edge effects when computing spatial statistics. - - - - Name of an HDF5 file which contains ion-to-edge distances. - - - - - Absolute HDF5 path to the dataset with the - ion-to-edge distance values for each ion. - The shape of the distance values has to match the length - of the ion positions array in dataset/dataset_name_reconstruction - and dataset_name_mass_to_charge respectively. - - - - - Threshold to define how large an ion has to lay at least far away - from the edge of the dataset so that the ion can act as a source, - i.e. that an ROI is placed at the location of the ion and its - neighbors are analyzed how they contribute to the computed statistics. - - The ion_to_edge_distances threshold can be combined with a threshold - for the ion_to_feature_distances. - Specifically, if ion_to_feature_distances are loaded an ion only - acts as a source if both threshold criteria are met. - - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. - - - - - - In addition to spatial filtering, and considering how far ions lie - to the edge of the dataset, it is possible to restrict the analyses - to a sub-set of ions within a distance not farther away to a feature than - a threshold value. - - - - Name of an HDF5 file which contains ion-to-feature distances. - - - - - Absolute HDF5 path to the dataset with the - ion-to-feature distance values for each ion. - - - - - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that the ion_to_feature_distances threshold is combined - with the ion_to_edge_distances threshold. - - - - - - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - - - - - - - - - - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - - - - - - - - - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - - - - - - - - - Specifies which spatial statistics to compute. - - - - Compute k-th nearest neighbour statistics. - - - - Order k. - - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - - - - Compute radial distribution function. - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml deleted file mode 100644 index e3587c870e..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.nxdl.xml +++ /dev/null @@ -1,260 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of alpha values (and offset values) to probe. - - - - - How many different match values does the filter specify. - - - - - Configuration of a paraprobe-surfacer tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - For now a support field for the tool to identify how many individual - analyses the tool should executed as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specifies the method that is used to preprocess the point cloud. - The main purpose of this setting is to specify whether the point - cloud should be segmented or not during the preprocessing - to identify which points are more likely lying close to the edge - of the point cloud. These points could be more relevant than the - interior points for certain alpha-shape constructions. - - By default no such filtering is used during pre-processing. - By contrast, the option kuehbach activates a preprocessing - during which a Hoshen-Kopelman percolation analysis is used - to identify which points are closer to the edge of the dataset. - This can reduce the number of points in the alpha-shape - computation and thus improve performance substantially. - Details about the methods are reported in - `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. - - - - - - - - - When using the kuehbach preprocessing, this is the width of the - kernel for identifying which ions are in voxels close to the - edge of the point cloud. - - - - - Specifies which method to use to define the alpha value. - The value convex_hull_naive is the default. This instructs the tool - to use a fast specialized algorithm for computing only the convex - hull. The resulting triangles can be skinny. - - The value convex_hull_refine computes first also a convex_hull_naive - but refines the mesh by triangle flipping and splitting to improve - the quality of the mesh. - - The value smallest_solid instructs the CGAL library to choose a - value which realizes an alpha-shape that is the smallest solid. - - The value cgal_optimal instructs the library to choose a value - which the library considers as an optimal value. Details are - define in the respective section of the CGAL library on 3D alpha - shapes. - - The value set_of_values instructs to compute a list of - alpha-shapes for the specified alpha-values. - - The value set_of_alpha_wrappings instructs the library to generate - a set of so-called alpha wrappings. These are a method - which is similar to alpha shapes but provide additional guarantees - though such as watertightness and proximity constraints on the - resulting wrapping. - - - - - - - - - - - - - Array of alpha values to use when alpha_value_choice is set_of_values - or when alpha_value_choice is set_of_alpha_wrappings. - - - - - - - - Array of offset values to use when alpha_value_choice is - set_of_alpha_wrappings. The array of alpha_values and offset_values - define a sequence of (alpha and offset value). - - - - - - - - Specifies if the tool should compute the set of exterior triangle - facets for each alpha complex (for convex hull, alpha shapes, and wrappings) - - - - - Specifies if the tool should check if the alpha complex of exterior - triangular facets is a closed polyhedron. - - - - - Specifies if the tool should compute all interior tetrahedra - of the alpha complex (currently only for alpha shapes). - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml deleted file mode 100644 index 5b2e1ee5d7..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.nxdl.xml +++ /dev/null @@ -1,190 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-tessellator tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many individual analyses should the tool execute. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distance information for - each point which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains the ion distances. - Users are responsible this file and referred to dataset under - dataset_name have an ion_distance value for each ion. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional layer of - reproducibility. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - Specifies for which points the tool will compute the tessellation. - By default, a Voronoi tessellation is computed for all ions in the - filtered point cloud. - - - - - - - - Specifies if the tool should report the volume of each cell. - - - - - Specifies if the tool should report the first-order neighbors of each cell. - - - - - Specifies if the tool should report the facets and vertices of each cell. - - - - - Specifies if the tool should report if the cell makes contact with - the tight axis-aligned bounding box about the point cloud. - This can be used to identify if the shape of the cell is affected - by the edge of the dataset or if cells are deeply enough embedded - into the point cloud so that the shape of their cells are not affected - by the presence of the boundary. - - - - - Maximum distance for which cells are eroded. - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml deleted file mode 100644 index 99a4a0cebd..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.nxdl.xml +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configurations of a paraprobe-transcoder tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ideally an ever persistent resource where the source code of the - program and build instructions can be found so that the program can be - configured ideally in such a manner that the result of this computational - process is recreatable deterministically. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - - - The path and name of the file (technology partner or community format) - from which to read the reconstructed ion positions. Currently, POS, - ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files - are supported. - - - - - - - - The path and name of the file (technology partner or community format - from which to read the ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. - NeXus/HDF5 files are supported. - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml deleted file mode 100644 index 7452e8a957..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.nxdl.xml +++ /dev/null @@ -1,425 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). Needs - to match maximum_number_of_atoms_per_molecular_ion. - - - - - Results of a paraprobe-ranger tool run. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on none, the - ion is considered of the default unknown type with a 0 as its - respective value in the iontypes array. - - - - The length of the isotope_vector used to describe molecular ions. - - - - - - - - - - - - - - - - - The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the elements of which a (molecular) ion - is build are considered. By contrast, charged_iontypes takes - into account also the charge state. - - - - - - - - The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. For the here computed - charged_iontypes the information for each (molecular) ion defined - in e.g. RNG or RRNG files is analyzed for which differently charge - states are possible. As an example while iontypes might only consider - if an ion is Al charged_iontypes will resolve if it is Al1+, Al2+, or - Al3+. To decide the charge state a recursive algorithm is used which - enumerates first all possible isotopic variants of a given molecular - ion build from a specific set of elements. All variants are then - analyzed for their natural abundance and filtered. The sub-set of - all significantly abundant variants is inspected if their charge - states are all the same. If only one significant variant is found - its charge state is assumed the relevant. If multiple significant - variants are found and all their charge states is the same this - charge state will be the decisive one. However, if multiple variants - are found and their charge state differs such a case highlights that - the charge state analysis is underconstrained and thus the charge - state is set to 0. Underconstrained cases are possible because - an arbitrary combination of elements into a molecular ion that is - constrained only by an additional single interval of mass-to-charge - state ratios is not necessarily sufficient. - - - - - - - - A bitmask which identifies exactly all those ions ranged irrespective - the type they ended up with. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - Paraprobe-ranger performs a combinatorial search over - all possible or a reduced set of nuclids to identify - into which ions these can be composed. - - - - The main result is the list of molecular ions, here formatted - according to the definitions of a set of isotope_vectors - as detailed in :ref:`NXion`. - - - - - - - - - The mass-to-charge-state ratio of each molecular ion - without considering relativistic or quantum effects. - - - - - - - - The mass of each molecular ion without - considering relativistic or quantum effects. - - - - - - - - The charge_state of each molecular ion. - - - - - - - - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - - - - - - - - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - - - - - - - - The number of disjoint nuclids for each molecular ion. - - - - - - - - The number of nuclids for each molecular ion. - - - - - - - - - Paraprobe-ranger loads iontypes and evaluates for each ion on which - iontype it matches. If it matches on none, the ion is considered of - the default unknown type with a 0 as its respective value in the - iontypes array. In contrast to use_existent_ranging this process - does neither needs measured ion position nor mass-to-charge-state - ratio values. - - - - The length of the isotope_vector used to describe molecular ions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml deleted file mode 100644 index ea39aec3a4..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.nxdl.xml +++ /dev/null @@ -1,383 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). Needs - to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals mapped on this ion - type. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Results of a paraprobe-transcoder tool run. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. - - - - - - - - - On a mid term perspective we would like to evolve the paraprobe-toolbox - to an implementation stage where it works exclusively with completely - provenance-tracked formats for both the configuration of the workflow step - and/or analysis with each tool and also for the output of these analyses - in the form of so-called tool-specific results files. - Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. - - Different file formats can be used to inject reconstructed datasets and - ranging definitions into the toolbox. Traditionally, these are the POS, - ePOS, and APT files with the tomographic reconstruction and other metadata - and RNG and RRNG file formats for the ranging definitions how mass-to-charge - state-ratio values map on (molecular) ion types. Such input should be - injected via specific NeXus/HDF5 files which are documented - in compliance with the NXapm application definition. - - So far the paraprobe-toolbox was used as a standalone tool. Therefore, it - was not relevant during the development to focus on interoperability. - Essentially paraprobe-transcoder was used as a parser to transcode data - in the above-mentioned file formats into a paraprobe-specific - representation. This transcoding should become deprecated. - Here we describe steps we have taken into this direction. - - With the work in the FAIRmat project and the desire to make the paraprobe- - toolbox also accessible as a cloud-computing capable service in the Nomad - Remote Tools Hub (NORTH) the topic of interoperability became more important - and eventually the NXapm application definition was proposed. - NORTH is a GUI and related service in a NOMAD OASIS instance which allows - to spawn preconfigured docker containers via JupyterHub. - Currently, NORTH includes the so-called apm container. A container with - tools specific for analyzing data from atom probe microscopy as well as - processing of point cloud and mesh data. - - The NXapm application definition and related implementation work within - NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and - RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook - solutions directly into NOMAD OASIS via the uploads section. - The process is automated and yields an NXapm-compliant NeXus/HDF5 file - inside the uploads section in return. - - With these improvements made there is no longer a need for - at least the - users of a NOMAD OASIS and NORTH instance to use the deprecated - PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should - automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 - file and in response work with this file directly. - To remain compliant with users however who do not have or do not wish - to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is - as follows: - - Calling the configuration stage of paraprobe-transcoder is always mandatory. - It is always the first step of working with the toolbox. In this process - the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ - HDF5 file from e.g. the upload section, or such a file that was obtained from - a colleague with a NOMAD OASIS instance. - In all other cases, users can pass the reconstruction and ranging definitions - using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. - - Based on which input the user delivers, the parmsetup-transcoder tool then - creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and - informs the user whether the input was NeXus (and thus if all relevant - input is already available) or whether the paraprobe-transcoder tool needs - to be executed to convert the content of the vendor files first into a - format which paraprobe can provenance track and understand. - In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is - used to communicate to all subsequently used tools from which files - the tools can expect to find the reconstruction and ranging definitions. - - All subsequent analysis steps start also with a tool-specific configuration. - This configuration step reads in (among others) the - PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration - tool identifies automatically whether to read the reconstruction and ranging data - from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant - NeXus/HDF5 file that was created upon preparing the upload or the file shared - from a colleague. This design removes the need for unnecessary copies of the data. - Currently still though users should execute the transcoder step as it will - generate a supplementary XDMF topology field with which the data in either - the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. - Paraview. For this purpose XDMF is used. - - Of course ideally the APT community would at some point converge to use - a common data exchange file format. To this end, AMETEK/Cameca's APT file format - could be a good starting point but so far it is lacking a consistent way of - how to store generalized ranging definitions and post-processing results. - POS, ePOS, Rouen's ATO, as well as other so far used representations of data - like CSV or text files have, to the best of our current knowledge, no - concept of how to marry reconstruction and (optional) ranging data into - one self-descriptive format. - - This summarizes the rationale behind the current choices of the I/O for - paraprobe. Furthermore, this summarizes also why the fundamental design - of splitting an analysis always into steps of configuration (with parmsetup), - task execution (with the respective C/C++ or Python tool of the toolbox), - and post-processing (e.g. with autoreporter) is useful because it offers - a clear description of provenance tracking. This is a necessary step to make - atom probe microscopy data at all better aligned with the aims of the - FAIR principles. - - The internal organization of the data entries in the atom_probe group - in this application definition for paraprobe-transcoder results files - mirror the definitions of the NXapm for consistency reasons. - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXatom_set.nxdl.xml b/contributed_definitions/nyaml/NXatom_set.nxdl.xml deleted file mode 100644 index 3c6e88652e..0000000000 --- a/contributed_definitions/nyaml/NXatom_set.nxdl.xml +++ /dev/null @@ -1,17 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - A base class to wrap details about a spatial configuration of atoms. - - - - Atom positions. - - - diff --git a/contributed_definitions/nyaml/NXbeam.yaml b/contributed_definitions/nyaml/NXbeam.yaml new file mode 100644 index 0000000000..e7a51cdc81 --- /dev/null +++ b/contributed_definitions/nyaml/NXbeam.yaml @@ -0,0 +1,242 @@ +category: base +doc: | + Properties of the neutron or X-ray beam at a given location. + + It will be referenced by beamline component groups within the ':'ref':'`NXinstrument` group or by the ':'ref':'`NXsample` group. + Note that variables such as the incident energy could be scalar values or arrays. + This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, + time distribution etc. at each beamline component. + Otherwise, its most likely use is in the ':'ref':'`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. + +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + + nx: | + Number of pixels of the horizontal axis (e.g. delay) of a FROG trace + + ny: | + Number of pixels of the vertical axis (e.g. frequency) of a FROG trace + +type: group +(NXobject)NXbeam: + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance from sample + incident_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + In the case of a monchromatic beam this is the scalar energy. + Several other use cases are permitted, depending on the presence of other incident_energy_X fields. + + * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + Here, incident_energy_weights and incident_energy_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_energy_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + dimensions: + rank: 1 + dim: [[1, i]] + incident_energy_spread(NX_NUMBER): + unit: NX_ENERGY + doc: | + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In + the case of shot-to-shot variation in the energy spread, this is a 2D array of + dimension nP by m (slow to fast) of the spreads of the corresponding wavelength + in incident_wavelength. + incident_energy_weights(NX_NUMBER): + unit: NX_ENERGY + doc: | + In the case of a polychromatic beam this is an array of length m of the relative + weights of the corresponding energies in incident_energy. In the case of a + polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np + by m (slow to fast) of the relative weights of the corresponding energies in + incident_energy. + final_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy on leaving beamline component + dimensions: + rank: 1 + dim: [[1, i]] + energy_transfer(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy change caused by beamline component + dimensions: + rank: 1 + dim: [[1, i]] + incident_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + In the case of a monchromatic beam this is the scalar wavelength. + Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. + + * In the case of a polychromatic beam this is an array of length m of wavelengths, + with the relative weights in incident_wavelength_weights. + * In the case of a monochromatic beam that varies shot-to-shot, + this is an array of wavelengths, one for each recorded shot. + Here, incident_wavelength_weights and incident_wavelength_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, + single-value wavelength value is available along with the original spectrum from which it was calibrated. + dimensions: + rank: 1 + dim: [[1, i]] + incident_wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Wavelength spread FWHM on entering component + dimensions: + rank: 1 + dim: [[1, i]] + incident_beam_divergence(NX_FLOAT): + unit: NX_ANGLE + doc: | + Divergence of beam entering this component + dimensions: + rank: 2 + dim: [[1, 2], [2, j]] + extent(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of the beam entering this component + dimensions: + rank: 2 + dim: [[1, 2], [2, j]] + final_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Wavelength on leaving beamline component + dimensions: + rank: 1 + dim: [[1, i]] + incident_polarization(NX_FLOAT): + unit: NX_ANY + doc: | + Incident polarization as a Stokes vector + dimensions: + rank: 1 + dim: [[1, 4]] + \@units: + type: NX_CHAR + doc: | + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. + Correct parsing can still be implemented by using this attribute. + + | Fill with':' + + * The unit unidata symbol if the unit has one (Example':' 'T' for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example':' 'farad' for capacitance). + * A string describing the units according to unidata unit operation notation, + if the unit is a complex combination of named units and does not have a name. + + Example':' for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. + Here':' SI units are 'V2/m2'. + final_polarization(NX_FLOAT): + unit: NX_ANY + doc: | + Polarization as Stokes vector on leaving beamline component + dimensions: + rank: 1 + dim: [[1, 4]] + \@units: + type: NX_CHAR + doc: | + Here':' SI units are 'V2/m2'. + final_wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Wavelength spread FWHM of beam leaving this component + dimensions: + rank: 1 + dim: [[1, i]] + final_beam_divergence(NX_FLOAT): + unit: NX_ANGLE + doc: | + Divergence FWHM of beam leaving this component + dimensions: + rank: 2 + dim: [[1, 2], [2, j]] + flux(NX_FLOAT): + unit: NX_FLUX + doc: | + flux incident on beam plane area + dimensions: + rank: 1 + dim: [[1, i]] + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy of a single pulse at the diagnostic point + average_power(NX_FLOAT): + unit: NX_POWER + doc: | + Average power at the diagnostic point + fluence(NX_FLOAT): + unit: NX_ANY + doc: | + Incident fluence at the diagnostic point + \@units: + type: NX_CHAR + doc: | + Here':' SI units are ''J/m2'', customary ''mJ/cm2''. + pulse_duration(NX_FLOAT): + unit: NX_TIME + doc: | + FWHM duration of the pulses at the diagnostic point + frog_trace(NX_FLOAT): + doc: | + FROG trace of the pulse. + dimensions: + rank: 2 + dim: [[1, nx], [2, ny]] + frog_delays(NX_FLOAT): + unit: NX_TIME + doc: | + Horizontal axis of a FROG trace, i.e. delay. + dimensions: + rank: 1 + dim: [[1, nx]] + frog_frequencies(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Vertical axis of a FROG trace, i.e. frequency. + dimensions: + rank: 1 + dim: [[1, ny]] + chirp_type(NX_CHAR): + doc: | + The type of chirp implemented + chirp_GDD(NX_FLOAT): + unit: NX_TIME + doc: | + Group delay dispersion of the pulse for linear chirp + (NXdata): + doc: | + Distribution of beam with respect to relevant variable e.g. wavelength. This is + mainly useful for simulations which need to store plottable information at each + beamline component. + \@default: + doc: | + .. 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/nyaml/NXcalibration.nxdl.xml b/contributed_definitions/nyaml/NXcalibration.nxdl.xml deleted file mode 100644 index f5bbee3412..0000000000 --- a/contributed_definitions/nyaml/NXcalibration.nxdl.xml +++ /dev/null @@ -1,90 +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/nyaml/NXcg_alpha_shape.nxdl.xml b/contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml deleted file mode 100644 index ca0b4467a4..0000000000 --- a/contributed_definitions/nyaml/NXcg_alpha_shape.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the alpha shape, for now 2 or 3. - - - - - The number of edges. - - - - - The number of faces. - - - - - The number of cells. - - - - - Computational geometry description of alpha shapes or wrappings to primitives. - - For details see: - - * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, - * https://dx.doi.org/10.1145/174462.156635 for 3D, - * https://dl.acm.org/doi/10.5555/871114 for weighted, and - * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap - - in CGAL, the Computational Geometry Algorithms Library. - As a starting point, we follow the conventions of the CGAL library. - - - - - - - - - - Specify which general type of alpha shape is computed. - Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. - Alpha_wrapping means meshes created using alpha wrapping procedures. - - - - - - - - - Specifically when computed with the CGAL, the mode specifies if singular - faces are removed (regularized) of the alpha complex. - - - - - - - - - The alpha, (radius of the alpha-sphere) parameter to be used for alpha - shapes and alpha wrappings. - - - - - The offset distance parameter to be used in addition to alpha - in the case of alpha_wrapping. - - - - - Point cloud for which the alpha shape or wrapping should be computed. - - - - - Triangle soup for which the alpha wrapping should be computed. - - - - - A meshed representation of the resulting shape. - - - - diff --git a/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml deleted file mode 100644 index 8cf1c2fb2b..0000000000 --- a/contributed_definitions/nyaml/NXcg_cylinder_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of cylinders or cones. - - - - - Computational geometry description of a set of cylinders in Euclidean space. - - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. - - - - - - - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Interior volume of each cylinder - - - - - - - - Lateral surface area - - - - - - - - Area of the upper and the lower cap of each cylinder respectively. - - - - - - - - - Cap and lateral surface area for each cylinder. - - - - - - diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 26edc57d28..0000000000 --- a/contributed_definitions/nyaml/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,112 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or - ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index 1cbbc56d88..0000000000 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,219 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml deleted file mode 100644 index da110c3645..0000000000 --- a/contributed_definitions/nyaml/NXcg_geodesic_mesh.nxdl.xml +++ /dev/null @@ -1,35 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computational geometry description of a geodesic mesh. - - People from geodesic/surveyors will likely have specific demands and - different views about what should be included in such a base class, given - that nested geodesic meshes are a key component of climate modelling tools. - For now we propose to use this base class as a container to organize metadata - and data related to geodesic meshes. - - Specifically an instance of this base class should detail the rule set how - how the geodesic (surface) mesh was instantiated as there are many - possibilities. A geodesic surface mesh is in this sense a triangulated - surface mesh with metadata. For additional details as an introduction - into the topic see e.g.: - - * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ - - Here, especially the section on subdivision schemes is relevant. - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - diff --git a/contributed_definitions/nyaml/NXcg_grid.nxdl.xml b/contributed_definitions/nyaml/NXcg_grid.nxdl.xml deleted file mode 100644 index f26e4fb98c..0000000000 --- a/contributed_definitions/nyaml/NXcg_grid.nxdl.xml +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the grid. - - - - - The cardinality or total number of cells/grid points. - - - - - Number of boundaries of the bounding box or primitive to the grid. - - - - - Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. - - Frequently convenient three-dimensional grids with cubic cells are used. - Exemplar applications are spectral-solver based crystal plasticity - and stencil methods like phase-field or cellular automata. - - - - - - - - - - - - - - - - - The symmetry of the lattice defining the shape of the unit cell. - - - - - - - - The unit cell dimensions using crystallographic notation. - - - - - - - - Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cells. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish cells for explicit indexing. - - - - - - - - Position of each cell in Euclidean space. - - - - - - - - - Coordinate of each cell with respect to the discrete grid. - - - - - - - - - A tight bounding box or sphere or bounding primitive about the grid. - - - - - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - - - - - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - - - - - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - - - - - diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml deleted file mode 100644 index 46722e18de..0000000000 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.nxdl.xml +++ /dev/null @@ -1,147 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of faces. - - - - - The number of half-edges. - - - - - Computational geeometry description of a half-edge data structure. - - Such a data structure can be used to efficiently circulate around faces - and iterate over vertices of a planar graph. - - - - - - - - In this half-edge data structure vertex identifiers start at 1. - Vertices are identified with consecutive integers up to number_of_vertices. - This field can be used to document which constant integer has to be - added to another set of vertex_identifier to assure that these other - identifiers also start at 1. - - - - - In this half-edge data structure face identifiers start at 1. - Faces are identified with consecutive integers up to number_of_faces. - This field can be used to document which constant integer has to be - added to another set of face_identifier to assure that these other - identifiers also start at 1. - - The face identifier zero is reserved for the NULL face ! - - - - - In this half-edge data structure half-edge identifiers start at 1. - Half-edges are identified with consecutive integers up to number_of_half_edges. - This field can be used to document which constant integer has to be - added to another set of half_edge_identifier to assure that these other - identifiers also start at 1. - - - - - The position of the vertices. - - - - - - - - - Identifier of the incident half-edge. - - - - - - - - Identifier of the (starting)/associated half-edge of the face. - - - - - - - - The identifier of the vertex from which this half-edge is outwards pointing. - - - - - - - - Identifier of the associated oppositely pointing half-edge. - - - - - - - - If the half-edge is a boundary half-edge the - incident face identifier is NULL, i.e. 0. - - - - - - - - Identifier of the next half-edge. - - - - - - - - Identifier of the previous half-edge. - - - - - - - - Users are referred to the literature for the background of L. Weinberg's - work about topological characterization of planar graphs: - - * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ - * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ - * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ - - and how this work can e.g. be applied in space-filling tessellations - of microstructural objects like crystals/grains. - - - diff --git a/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 43976dc71f..0000000000 --- a/contributed_definitions/nyaml/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,207 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml b/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml deleted file mode 100644 index 9164f7c68a..0000000000 --- a/contributed_definitions/nyaml/NXcg_isocontour.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the description. - - - - - Computational geometry description of isocontouring/phase-fields in Euclidean space. - - Iso-contouring algorithms such as MarchingCubes and others are frequently - used to segment d-dimensional regions into regions where intensities are - lower or higher than a threshold value, the so-called isovalue. - - Frequently in computational materials science phase-field methods are - used which generate data on discretized grids. Isocontour algorithms - are often used in such context to pinpoint the locations of microstructural - features from this implicit phase-field-variable-based description. - - One of the key intentions of this base class is to provide a starting point - for scientists from the phase-field community (condensed matter physicists, - and materials engineers) to incentivize that also phase-field simulation - data could be described with NeXus, provided base classes such as the this one - get further extend according to the liking of the phase-field community. - - - - - The discretized grid on which the iso-contour algorithm operates. - - - - - The threshold or iso-contour value. - - - diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml deleted file mode 100644 index 10604d1867..0000000000 --- a/contributed_definitions/nyaml/NXcg_marching_cubes.nxdl.xml +++ /dev/null @@ -1,50 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computational geometry description of the marching cubes algorithm. - - Documenting which specific version was used can help to understand how robust - the results are with respect to the topology of the triangulation. - - - - Reference/link to and/or details of the grid on which a specific - marching cubes algorithm implementation is operating. - - - - - Reference to the specific implementation of marching cubes used. - - See for example the following papers for details about how to identify a - DOI which specifies the implementation used: - - * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ - * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ - - The value placed here should be a DOI. If there are no specific DOI or - details write not_further_specified, or give at least a free-text - description. - - - - - Commercial or otherwise given name to the program which was used. - - - - Program 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. - - - - diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index 8b9f7bcc09..0000000000 --- a/contributed_definitions/nyaml/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,156 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - Disentangled representations of the mesh of specific parallelograms. - - - diff --git a/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml deleted file mode 100644 index 21967d7df5..0000000000 --- a/contributed_definitions/nyaml/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index ab50c22e8f..0000000000 --- a/contributed_definitions/nyaml/NXcg_polygon_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - The total number of vertices when visiting every polygon. - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index d037b06337..0000000000 --- a/contributed_definitions/nyaml/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,150 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml deleted file mode 100644 index cda26aeee0..0000000000 --- a/contributed_definitions/nyaml/NXcg_polyline_set.nxdl.xml +++ /dev/null @@ -1,153 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of polylines. - - - - - The number of vertices, supporting the polylines. - - - - - The total number of vertices traversed when visiting every polyline. - - - - - Computational geometry description of a set of polylines in Euclidean space. - - Each polyline is built from a sequence of vertices (points with identifiers). - Each polyline must have a start and an end point. - The sequence describes the positive traversal along the polyline when walking - from the start vertex to the end/last vertex. - - - - - - The total number of vertices, irrespective of their eventual uniqueness, - i.e. the total number of vertices that have to be visited when walking - along each polyline. - - - - - Array which specifies of how many vertices each polyline is built. - The number of vertices represent the total number of vertices for - each polyline, irrespectively whether vertices are shared or not. - See the docstring for polylines for further details about how - a set with different polyline members should be stored. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and polyline data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - polylines. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polylines for explicit indexing. - - - - - - - - Positions of the vertices which support the members of the polyline set. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - If true indicates that the vertices are all placed at different - positions and have different identifiers, i.e. no points overlap - or are counted twice. - - - - - Sequence of vertex identifiers which describe each polyline. - - A trivial example is a set with two polylines with three vertices each. - If the polylines meet in a junction, say the second vertex is shared - and marking the junction between the two polylines, it is possible that - there are only five unique positions suggesting five unique vertices. - - A non-trivial example is a set with several polylines, each of which with - eventually different number of vertices. The array stores the vertex - identifiers in the order how the polylines are visited: - - The first entry is the identifier of the start vertex of the first polyline, - followed by the second vertex of the first polyline, until the last vertex - of the polyline. Thereafter, the start vertex of the second polyline, and - so on and so forth. Using the (cumulated) counts in number_of_vertices, - the vertices of the n-th polyline can be accessed on the following - array index interval: - :math:`$[\sum_i = 0}^{i = N-1}, \sum_{i=0}^{i=N}]$`. - - - - - - - - The length of each polyline. - - - - - - - - If true specifies that a polyline is closed, i.e. - its end point is connected to the start point. - - - - - - - - diff --git a/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml deleted file mode 100644 index d9c4e9a275..0000000000 --- a/contributed_definitions/nyaml/NXcg_roi_set.nxdl.xml +++ /dev/null @@ -1,16 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Base class to hold geometric primitives. - - - - - - diff --git a/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index 94143d5290..0000000000 --- a/contributed_definitions/nyaml/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index c9972fda6c..0000000000 --- a/contributed_definitions/nyaml/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 547619af98..0000000000 --- a/contributed_definitions/nyaml/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml deleted file mode 100644 index 3b68642b7c..0000000000 --- a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.nxdl.xml +++ /dev/null @@ -1,22 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computational geometry description of a mesh of triangles. - - The mesh may be self-intersecting and have holes but the - triangles must not be degenerated. - - - - - A graph-based approach to describe the mesh when it is also desired - to perform topological processing or analyses on the mesh. - - - diff --git a/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml deleted file mode 100644 index 9ca1d2cf8f..0000000000 --- a/contributed_definitions/nyaml/NXcg_unit_normal_set.nxdl.xml +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of unit normals. - - - - - Computational geometry description of a set of (oriented) unit normal vectors. - - - - - - Direction of each normal - - - - - - - - - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - diff --git a/contributed_definitions/nyaml/NXchamber.nxdl.xml b/contributed_definitions/nyaml/NXchamber.nxdl.xml deleted file mode 100644 index af9dcc11d5..0000000000 --- a/contributed_definitions/nyaml/NXchamber.nxdl.xml +++ /dev/null @@ -1,19 +0,0 @@ - - - - - Component of an instrument to store or place objects and specimens. - - - - Given name/alias. - - - - - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. - - - - diff --git a/contributed_definitions/nyaml/NXclustering.nxdl.xml b/contributed_definitions/nyaml/NXclustering.nxdl.xml deleted file mode 100644 index b720d1c892..0000000000 --- a/contributed_definitions/nyaml/NXclustering.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of numeral labels per object. - - - - - Number of categorical labels per object. - - - - - Total number of clusters detected. - - - - - Metadata to the results of a clustering analysis. - - Clustering algorithms are routine tools to segment a set of objects/primitives - into groups, objects of different type. A plethora of algorithms have been - proposed for geometric primitives as objects, such as points, triangles, - or (abstract) objects. - - This base class considers metadata and results of one clustering - applied to a set in which objects are either categorized as noise - or belonging to a cluster, specifically here only one cluster. - - - - How many numeric labels does each object have. - - - - - How many categorical labels does each object have. - - - - - Reference to a set of objects investigated in a cluster analysis. - Objects must have clear integer identifier. - - - - - Reference to numeric attribute data for each object. - - - - - Reference to categorical attribute data for each object. - - - - - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - - - - - Total number of objects categorized as unassigned. - - - - - Total number of objects categorized as noise. - - - - - Total number of clusters (excluding noise and unassigned). - - - - - Number of objects associated to each cluster. The labels are implicit, - meaning the zeroth/first entry in the array belongs to the first cluster, - the second entry to the second cluster and so on and so forth. - The first cluster has the value of identifier_offset as its identifier. - The second cluster has identifier_offset + 1, and so on and so forth. - - - - - - diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml b/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml deleted file mode 100644 index 393de7efb6..0000000000 --- a/contributed_definitions/nyaml/NXcollectioncolumn.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. - - - - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. - - - - - Voltage applied to the extractor lens - - - - - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. - - - - - Distance between sample and detector entrance - - - - - Labelling of the lens setting in use. - - - - - The space projected in the angularly dispersive directions, real or reciprocal - - - - - - - - - The magnification of the electron lens assembly. - - - - - Specifies the position of the collectioncolumn 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 - 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. - - - - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - - - - - Deflectors in the collection column section - - - - - Individual lenses in the collection column section - - - diff --git a/contributed_definitions/nyaml/NXcontainer.yaml b/contributed_definitions/nyaml/NXcontainer.yaml new file mode 100644 index 0000000000..93fe2242a6 --- /dev/null +++ b/contributed_definitions/nyaml/NXcontainer.yaml @@ -0,0 +1,123 @@ +category: base +doc: | + State of a container holding the sample under investigation. + + A container is any object in the beam path which absorbs the beam and + whose contribution to the overall attenuation/scattering needs to be + determined to process the experimental data. Examples of containers + include glass capillary tubes, vanadium cans, windows in furnaces or + diamonds in a Diamond Anvil Cell. The following figures show a complex + example of a container':' + + .. figure':'':' container/ComplexExampleContainer.png + + A hypothetical capillary furnace. The beam passes from left to right + (blue dashes), passing through window 1, then window 2, before + passing through the downstream wall of the capillary. It is then + scattered by the sample with scattered beams passing through the + upstream wall of the capillary, then windows 4 and 5. As part of the + corrections for a PDF experiment it is necessary to subtract the PDF + of the empty container (i.e. each of the windows and the capillary). + To calculate the PDF of the empty container it is necessary to have + the measured scattering data and to know the nature (e.g. density, + elemental composition, etc.) of the portion of the container which + the beam passed through. + + .. figure':'':' container/ComplexContainerBeampath.png + + A complete description of the shapes of the container elements with + their orientation relative to the beam and also information on + whether they are upstream or downstream of the sample is also + therefore important. For example, although the windows 2 and 4 have + the same shape, the path taken through them by the beam is very + different and this needs to be modelled. Furthermore, it is not + inconceivable that windows might move during an experiment and thus + the changes to the beampath would need to be accounted for. + + This class encodes the position of the container with respect to the + sample and allows the calculation of the beampath through the container. + It also includes sufficient data to model beam absorption of the + container and a link to a dataset containing a measurement of the + container with nothing inside, to allow data corrections (at a specific + beam energy/measurement time) to be made. + +type: group +NXcontainer(NXobject): + name: + doc: | + Descriptive name of container. + description: + doc: | + Verbose description of container and how it fits into the wider + experimental set up. + chemical_formula: + doc: | + Chemical composition of the material the container is made from. + Specified using CIF conventions. Abbreviated version of CIF + standard':' + + * 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. + + * This is the *Hill* system used by Chemical Abstracts. + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of the material the container is made from. + dimensions: + rank: 1 + dim: [[1, n_comp]] + packing_fraction(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Fraction of the volume of the container occupied by the material + forming the container. + dimensions: + dim: [[1, n_comp]] + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative molecular mass of container. + dimensions: + rank: 1 + dim: [[1, n_comp]] + beam(NXbeam): + doc: | + Details of beam incident on container, including the position + relative to the sample (to determine whether the container is + upstream or downstream of the sample). + shape(NXshape): + doc: | + Shape of the container. In combination with orientation this + should allow the beampath through the container to be modelled to + allow the adsorption to be calculated. + orientation(NXtransformations): + doc: | + The angle the container makes to the beam and how it may change + during the experiment.In combination with shape this should allow + the beampath through the container to be modelled to allow the + adsorption of the container to be calculated. + reference_measurement(link): + target: /NXentry + doc: | + A link to a full data collection which contains the actual + measured data for this container within the experimental set up + (with no sample or inner container(s)). This data set will also + include the wavelength/energy, measurement time and intensity for + which these data are valid. diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index 87d6d5dee7..0000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,62 +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/nyaml/NXcorrector_cs.nxdl.xml b/contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml deleted file mode 100644 index 0cf6de7b48..0000000000 --- a/contributed_definitions/nyaml/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,40 +0,0 @@ - - - - - Corrector for aberrations in an electron microscope. - - Different vendors use a different naming schemes for aberration coefficients. - It is the users responsibility to map to the best matching values. - - In transmission electron microscopes the spherical aberration corrector is - a component that is controlled via instructing the microscope to achieve - set point values. The corrector is composed of multiple lenses and other - parts with vendor-specific details which are often undisclosed. - - In the case of Nion Co. microscopes the coefficients of the corrector can be - retrieved via NionSwift, which is why currently the Nion convention for the - aberration coefficients is used. - - - - Was the corrector used? - - - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - - - - diff --git a/contributed_definitions/nyaml/NXcs_computer.nxdl.xml b/contributed_definitions/nyaml/NXcs_computer.nxdl.xml deleted file mode 100644 index 9412c92a45..0000000000 --- a/contributed_definitions/nyaml/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,57 +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/nyaml/NXcs_cpu.nxdl.xml b/contributed_definitions/nyaml/NXcs_cpu.nxdl.xml deleted file mode 100644 index 1ea1ad4740..0000000000 --- a/contributed_definitions/nyaml/NXcs_cpu.nxdl.xml +++ /dev/null @@ -1,18 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a central processing unit (CPU) of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml deleted file mode 100644 index ab05cc23b4..0000000000 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.nxdl.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries (e.g. number of points or objects). - - - - - Number of bits assumed for the container datatype used. - - - - - Length of mask considering the eventual need for padding. - - - - - Computer science base class for packing and unpacking booleans. - - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. - - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. - - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. - - - - Number of objects represented by the mask. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - - - - - - - - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - - - - - - diff --git a/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml b/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml deleted file mode 100644 index 8cb1190ad2..0000000000 --- a/contributed_definitions/nyaml/NXcs_gpu.nxdl.xml +++ /dev/null @@ -1,18 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a graphic processing unit (GPU) of a computer. - - - - Given name of the GPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml b/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml deleted file mode 100644 index b811a80d44..0000000000 --- a/contributed_definitions/nyaml/NXcs_io_obj.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a storage object in an input/output system. - - - - Qualifier for the type of storage medium used. - - - - - - - - - - Total amount of data which the medium can hold. - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml b/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml deleted file mode 100644 index ef30143753..0000000000 --- a/contributed_definitions/nyaml/NXcs_io_sys.nxdl.xml +++ /dev/null @@ -1,13 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of system of a computer. - - - diff --git a/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml b/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml deleted file mode 100644 index 30d33b03f6..0000000000 --- a/contributed_definitions/nyaml/NXcs_mm_sys.nxdl.xml +++ /dev/null @@ -1,17 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a main memory system of a computer. - - - - How much physical memory does the system provide. - - - diff --git a/contributed_definitions/nyaml/NXcs_prng.nxdl.xml b/contributed_definitions/nyaml/NXcs_prng.nxdl.xml deleted file mode 100644 index 2b5d430b1a..0000000000 --- a/contributed_definitions/nyaml/NXcs_prng.nxdl.xml +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of pseudo-random number generator. - - The purpose of such metadata is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). - - - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). - - - - - - - - - - - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - - - - Version and build number, or commit hash. - - - - - - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - - - - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - - diff --git a/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml b/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml deleted file mode 100644 index 8aee1f7239..0000000000 --- a/contributed_definitions/nyaml/NXcs_profiling.nxdl.xml +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description for summary performance/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 - contributions to performance: - - * Hardware capabilities and configuration - * 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. - - 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. - - 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 - 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. - - This base class cannot and should not replace these specific solutions. - 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 - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. - - - - Path to the directory from which the tool was called. - - - - - Command line call with arguments if applicable. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - - - - - 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. - - - - - 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. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - 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 - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - - - - - Qualifier with how many nominal GPUs the app was invoked at runtime. - - - - - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - - - - - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - - diff --git a/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml b/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml deleted file mode 100644 index 53fa4e4874..0000000000 --- a/contributed_definitions/nyaml/NXcs_profiling_event.nxdl.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of processes. - - - - - Computer science description of a profiling event. - - - - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - - - - - ISO 8601 time code with local time zone offset to UTC information - 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. - 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. - - - - - Maximum amount of virtual memory allocated per process during the event. - - - - - - - - Maximum amount of resident memory allocated per process during the event. - - - - - - diff --git a/contributed_definitions/nyaml/NXcsg.yaml b/contributed_definitions/nyaml/NXcsg.yaml new file mode 100644 index 0000000000..d1580d6692 --- /dev/null +++ b/contributed_definitions/nyaml/NXcsg.yaml @@ -0,0 +1,32 @@ +category: base +doc: | + Constructive Solid Geometry base class, using ':'ref':'`NXquadric` and ':'ref':'`NXoff_geometry` + +type: group +NXcsg(NXobject): + operation: + doc: | + One of the standard construction solid geometry set operations, + or if the CSG is a pointer to the geometry provided by an + ':'ref':'`NXquadric` or an ':'ref':'`NXoff_geometry`. Takes values':' + enumeration: [UNION, INTERSECTION, DIFFERENCE, COMPLEMENT, IS_QUADRIC, IS_MESH] + a(NXcsg): + exists: ['min', '0', 'max', '1'] + doc: | + The first operand of constructive solid geometry + operation. Compulsory if 'operation' is UNION, INTERSECTION, + DIFFERENCE or COMPLEMENT. + b(NXcsg): + exists: ['min', '0', 'max', '1'] + doc: | + The second operand of constructive solid geometry + operation. Compulsory if 'operation' is UNION, INTERSECTION or + DIFFERENCE. + geometry(NX_CHAR): + exists: ['min', '0', 'max', '1'] + doc: | + Path to a field that is either an ':'ref':'`NXquadric` (if + 'operation' = IS_QUADRIC) or an ':'ref':'`NXoff_geometry` (if + 'operation' = IS_MESH) that defines the surface making up the + constructive solid geometry component. Compulsory if 'operation' + is IS_QUADRIC or IS_MESH. diff --git a/contributed_definitions/nyaml/NXcxi_ptycho.yaml b/contributed_definitions/nyaml/NXcxi_ptycho.yaml new file mode 100644 index 0000000000..9b5fbc5a56 --- /dev/null +++ b/contributed_definitions/nyaml/NXcxi_ptycho.yaml @@ -0,0 +1,211 @@ +category: application +doc: | + Application definition for a ptychography experiment, compatible with CXI from version 1.6. + + This is compatible with CXI from version 1.6 if this application definition + is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important + to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, + with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. + + An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths + with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). + +symbols: + doc: | + These symbols will be used below to coordinate the shapes of the datasets. + + npts_x: | + The number of points in the x direction + + npts_y: | + Number of points in the y direction. + + frame_size_x: | + Number of detector pixels in x + + frame_size_y: | + Number of detector pixels in y + +type: group +NXcxi_ptycho(NXobject): + (NXentry)entry_1: + title: + exists: ['min', '0', 'max', '1'] + start_time(NX_DATE_TIME): + exists: ['min', '0', 'max', '1'] + end_time(NX_DATE_TIME): + exists: ['min', '0', 'max', '1'] + definition(NX_CHAR): + exists: ['min', '1', 'max', '1'] + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXcxi_ptycho] + (NXinstrument)instrument_1: + exists: ['min', '1', 'max', '1'] + (NXsource)source_1: + exists: ['min', '1', 'max', '1'] + name(NX_CHAR): + exists: ['min', '1', 'max', '1'] + energy(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + doc: | + This is the energy of the machine, not the beamline. + probe(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + type(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + (NXbeam)beam_1: + exists: ['min', '1', 'max', '1'] + energy(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + extent(NX_FLOAT): + exists: ['min', '0', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + incident_beam_divergence(NX_FLOAT): + exists: ['min', '0', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + incident_beam_energy(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + incident_energy_spread(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + (NXdetector)detector_1: + exists: ['min', '1', 'max', '1'] + \@axes: + type: NX_CHAR + doc: | + should have value "[, data]" + \@signal: + type: NX_CHAR + doc: | + should have value "data" + (NXtransformations)transformations: + vector(NX_NUMBER): + exists: ['min', '1', 'max', '1'] + translation(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1', 'max', '1'] + doc: | + This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y + \@units: + type: NX_CHAR + exists: optional + \@axes: + exists: optional + type: NX_CHAR + doc: | + this should take the value "translation':'$slowaxisname':'$fastaxisname" + \@interpretation: + exists: optional + type: NX_CHAR + doc: | + This should be "image" + data(NX_INT): + signal: 1 + exists: ['min', '1', 'max', '1'] + dimensions: + rank: 3 for arbitrary scan, 4 for raster + dim: [[1, npts_x], [2, npts_y], [3, frame_size_x], [4, frame_size_y]] + data_1(link): + target: /NXentry/NXinstrument/NXdetector/data + doc: | + This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless + of the scan pattern. Use hdf5 virtual dataset to achieve this. + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1', 'max', '1'] + doc: | + The distance between the detector and the sample + \@units: + type: NX_CHAR + exists: optional + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + (NXmonitor): + exists: ['min', '0', 'max', '1'] + data(NX_FLOAT): + dimensions: + rank: 1 for arbitrary scan, 2 for raster + dim: [[1, npts_x], [2, npts_y]] + (NXdata): + exists: ['min', '1', 'max', '1'] + \@axes: + type: NX_CHAR + exists: optional + doc: | + This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster + \@signal: + type: NX_CHAR + exists: optional + doc: | + This should be "data" + data(link): + target: /NXentry/NXinstrument/NXdetector/data + x(link): + target: /NXentry/NXsample/NXtransformations/x + y(link): + target: /NXentry/NXsample/NXtransformations/y + x_indices(NX_CHAR): + y_indices(NX_CHAR): + (NXcollection)data_1: + exists: ['min', '1', 'max', '1'] + doc: | + To ensure CXI compatibility the data in this group must always have shape that is + (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that + hdf5 virtual dataset is used. + data(link): + target: /NXentry/NXinstrument/NXdetector/data + translation(link): + target: /NXentry/NXinstrument/NXdetector/translation + (NXsample)sample_1: + exists: ['min', '1', 'max', '1'] + name(NX_CHAR): + exists: ['min', '0', 'max', '1'] + transformations(NXtransformations): + doc: | + This must contain two fields with the x and y motors that are linked via the + dependency tree according to the real-life motor layout dependency. + For raster scans x and y will have shape (npts_x, npts_y) + For arbitrary scans x and y will be (npts_x*npts_y,) + An attribute with the units for each motor is required. + \@vector: + exists: optional + type: NX_NUMBER + (NXcollection)geometry_1: + exists: ['min', '1', 'max', '1'] + translation(link): + target: /NXentry/NXinstrument/NXdetector/translation diff --git a/contributed_definitions/nyaml/NXdeflector.nxdl.xml b/contributed_definitions/nyaml/NXdeflector.nxdl.xml deleted file mode 100644 index 8ad0e331e4..0000000000 --- a/contributed_definitions/nyaml/NXdeflector.nxdl.xml +++ /dev/null @@ -1,71 +0,0 @@ - - - - - Deflectors as they are used e.g. in an electron analyser. - - - - Qualitative type of deflector with respect to the number of pole pieces - - - - - - - - - - - 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. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. - - - - - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - - - - - 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 - 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/nyaml/NXdelocalization.nxdl.xml b/contributed_definitions/nyaml/NXdelocalization.nxdl.xml deleted file mode 100644 index 327eeca6e3..0000000000 --- a/contributed_definitions/nyaml/NXdelocalization.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of points/objects. - - - - - Number of mark data per point/object. - - - - - Number of atoms in the whitelist. - - - - - Number of isotopes in the whitelist. - - - - - Base class to describe the delocalization of point-like objects on a grid. - - Such a procedure is for instance used in image processing and e.g. atom probe - microscopy (APM) to discretize a point cloud onto a grid to enable e.g. - computing of point density, composition, or concentration values, obtain - scalar fields, and compute gradients of these fields. - - - - Reference or link to the grid on which the delocalization is applied. - - - - - Reference or link to the points which are delocalized on the grid. - - - - - The weighting model specifies how mark data are mapped to a weight per point. - For atom probe microscopy (APM) as an example, different models are used which - account differently for the multiplicity of an ion/atom: - - * default, points all get the same weight 1.; - for APM this is equivalent to ion species - * atomic_decomposition, points get as much weight as they have atoms - of a type in element_whitelist, - * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotope_whitelist. - - This description shows an example that could be reinterpreted for - similar such data processing steps in other fields of science. - - - - - - - - - - A list of elements (via proton number) to consider for the atomic_decomposition - weighting model. Elements must exist in the periodic table of elements. - - - - - - - - A list of isotopes to consider for the isotope_decomposition weighting model. - Isotopes must exist in the nuclid table. Entries in the fastest changing - dimension should be the pair of proton (first entry) and neutron number - (second entry). - - - - - - - - - Attribute data for each member of the point cloud. For APM these are the - ion species labels generated via ranging. The number of mark data per - point is 1 in the case for atom probe. - - - - - - - - - Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point. For APM the weight are positive - integer values, specifically the multiplicity of the ion, - according to the details of the weighting_model. - - - diff --git a/contributed_definitions/nyaml/NXdetector.yaml b/contributed_definitions/nyaml/NXdetector.yaml new file mode 100644 index 0000000000..6fefa6bfb3 --- /dev/null +++ b/contributed_definitions/nyaml/NXdetector.yaml @@ -0,0 +1,589 @@ +category: base +doc: | + A detector, detector bank, or multidetector. + +symbols: + doc: | + These symbols will be used below to coordinate datasets with the same + shape. + + np: | + number of scan points (only present in scanning measurements) + + i: | + number of detector pixels in the first (slowest) direction + + j: | + number of detector pixels in the second (faster) direction + + k: | + number of detector pixels in the third (if necessary, fastest) + direction + + tof: | + number of bins in the time-of-flight histogram + +type: group +(NXobject)NXdetector: + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: | + Total time of flight + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@axis: + type: NX_CHAR + enumeration: [3] + \@primary: + type: NX_CHAR + enumeration: [1] + \@long_name: + type: NX_CHAR + doc: | + Total time of flight + raw_time_of_flight(NX_INT): + unit: NX_PULSES + doc: | + In DAQ clock pulses + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@frequency: + type: NX_CHAR + doc: | + Clock frequency in Hz + detector_number(NX_INT): + doc: | + Identifier for detector (pixels) Can be multidimensional, if needed + data(NX_NUMBER): + unit: NX_ANY + doc: | + Data values from the detector. + dimensions: + rank: 4 + dim: [[1, np], [2, i], [3, j], [4, tof]] + \@long_name: + type: NX_CHAR + doc: | + Title of measurement + \@check_sum: + type: NX_CHAR + doc: | + Integral of data as check of data integrity + data_errors(NX_NUMBER): + unit: NX_ANY + doc: | + The best estimate of the uncertainty in the data value. Where possible, this + should be the standard deviation, which has the same units as the data. The form + data_error is deprecated. + dimensions: + rank: 4 + dim: [[1, np], [2, i], [3, j], [4, tof]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in x-direction. Can be multidimensional when + needed. + \@axis: + type: NX_CHAR + enumeration: [1] + \@primary: + type: NX_CHAR + enumeration: [1] + \@long_name: + type: NX_CHAR + doc: | + x-axis offset from detector center + y_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the y-direction. Can be multidimensional when + different values are required for each pixel. + \@axis: + type: NX_CHAR + enumeration: [2] + \@primary: + type: NX_CHAR + enumeration: [1] + \@long_name: + type: NX_CHAR + doc: | + y-axis offset from detector center + z_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the z-direction. Can be multidimensional when + different values are required for each pixel. + \@axis: + type: NX_CHAR + enumeration: [3] + \@primary: + type: NX_CHAR + enumeration: [1] + \@long_name: + type: NX_CHAR + doc: | + y-axis offset from detector center + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the distance to the previous component in the instrument; most often the + sample. The usage depends on the nature of the detector':' Most often it is the + distance of the detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the polar angle of the detector towards the previous component in the + instrument; most often the sample. The usage depends on the nature of the + detector. Most often it is the polar_angle of the detector assembly. But there + are irregular detectors. In this case, the polar_angle must be specified for + each detector pixel. + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the azimuthal angle angle of the detector towards the previous component + in the instrument; most often the sample. The usage depends on the nature of the + detector. Most often it is the azimuthal_angle of the detector assembly. But + there are irregular detectors. In this case, the azimuthal_angle must be + specified for each detector pixel. + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + description(NX_CHAR): + doc: | + name/manufacturer/model/etc. information + serial_number(NX_CHAR): + doc: | + Serial number for the detector + local_name(NX_CHAR): + doc: | + Local name for the detector + (NXgeometry): + doc: | + Position and orientation of detector + solid_angle(NX_FLOAT): + unit: NX_SOLID_ANGLE + doc: | + Solid angle subtended by the detector at the sample + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Detector dead time + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Detector gas pressure + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + detection_gas_path(NX_FLOAT): + unit: NX_LENGTH + doc: | + maximum drift space dimension + crate(NX_INT): + doc: | + Crate number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + type: NX_CHAR + doc: | + Equivalent local term + slot(NX_INT): + doc: | + Slot number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + type: NX_CHAR + doc: | + Equivalent local term + input(NX_INT): + doc: | + Input number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + type: NX_CHAR + doc: | + Equivalent local term + type(NX_CHAR): + doc: | + Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission + chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, ... + efficiency(NXdata): + doc: | + Spectral efficiency of detector with respect to e.g. wavelength + \@signal: + enumeration: [efficiency] + \@axes: + enumeration: [., . ., . . ., . . . ., wavelength] + \@wavelength_indices: + enumeration: [0] + efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + efficiency of the detector + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + This field can be two things':' + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + real_time(NX_NUMBER): + unit: NX_TIME + doc: | + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + dimensions: + rank: 3 + dim: [[1, np], [2, i], [3, j]] + start_time(NX_FLOAT): + unit: NX_TIME + doc: | + Start time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, np]] + \@start: + type: NX_CHAR + stop_time(NX_FLOAT): + unit: NX_TIME + doc: | + stop time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, np]] + \@start: + type: NX_CHAR + calibration_date(NX_DATE_TIME): + doc: | + date of last calibration (geometry and/or efficiency) measurements + calibration_method(NXnote): + doc: | + summary of conversion of array data to pixels (e.g. polynomial approximations) + and location of details of the calibrations + layout(NX_CHAR): + doc: | + How the detector is represented + enumeration: [point, linear, area] + count_time(NX_NUMBER): + unit: NX_TIME + doc: | + Elapsed actual counting time + dimensions: + rank: 1 + dim: [[1, np]] + data_file(NXnote): + (NXcollection): + doc: | + Use this group to provide other data related to this NXdetector group. + sequence_number(NX_INT): + doc: | + In order to properly sort the order of the images taken in (for example) a + tomography experiment, a sequence number is stored with each image. + dimensions: + rank: 1 + dim: [[1, nBrightFrames]] + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. This is a + length and can be outside of the actual detector. The length can be in physical + units or pixels as documented by the units attribute. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. This is a + length and can be outside of the actual detector. The length can be in physical + units or pixels as documented by the units attribute. + frame_start_number(NX_INT): + doc: | + This is the start number of the first frame of a scan. In PX one often scans a + couple of frames on a give sample, then does something else, then returns to the + same sample and scans some more frames. Each time with a new data file. This + number helps concatenating such measurements. + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + The diameter of a cylindrical detector + acquisition_mode(NX_CHAR): + doc: | + The acquisition mode of the detector. + enumeration: [gated, triggered, summed, event, histogrammed, decimated] + angular_calibration_applied(NX_BOOLEAN): + doc: | + True when the angular calibration has been applied in the electronics, false + otherwise. + angular_calibration(NX_FLOAT): + doc: | + Angular calibration data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_applied(NX_BOOLEAN): + doc: | + True when the flat field correction has been applied in the electronics, false + otherwise. + flatfield(NX_FLOAT): + doc: | + Flat field correction data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_errors(NX_FLOAT): + doc: | + Errors of the flat field correction data. The form flatfield_error is + deprecated. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + pixel_mask_applied(NX_BOOLEAN): + doc: | + True when the pixel mask correction has been applied in the electronics, false + otherwise. + pixel_mask(NX_INT): + doc: | + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning':' + + .. can't make a table here, a bullet list will have to do for now + + * bit 0':' gap (pixel with no sensor) + * bit 1':' dead + * bit 2':' under responding + * bit 3':' over responding + * bit 4':' noisy + * bit 5':' -undefined- + * bit 6':' pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7':' -undefined- + * bit 8':' user defined mask (e.g. around beamstop) + * bits 9-30':' -undefined- + * bit 31':' virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + countrate_correction_applied(NX_BOOLEAN): + doc: | + True when a count-rate correction has already been applied in the electronics, + false otherwise. + bit_depth_readout(NX_INT): + doc: | + How many bits the electronics reads per pixel. With CCD's and single photon + counting detectors, this must not align with traditional integer sizes. This can + be 4, 8, 12, 14, 16, ... + detector_readout_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to read the detector (typically milliseconds). This is important + to know for time resolved experiments. + trigger_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. This + is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set + delay.. This is important to know for time resolved experiments. + trigger_delay_time_set(NX_FLOAT): + unit: NX_TIME + doc: | + User-specified trigger delay. + trigger_internal_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. This + is the reaction time of the detector hardware after receiving the trigger signal + to when the detector starts to acquire the exposure. It forms the lower boundary + of the trigger_delay_time when the user does not request an additional delay. + trigger_dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time during which no new trigger signal can be accepted. Typically this is the + trigger_delay_time + exposure_time + readout_time. This is important to know for + time resolved experiments. + frame_time(NX_FLOAT): + unit: NX_TIME + doc: | + This is time for each frame. This is exposure_time + readout time. + dimensions: + rank: 1 + dim: [[1, NP]] + gain_setting(NX_CHAR): + doc: | + The gain setting of the detector. This influences background etc. + enumeration: [high, standard, fast, auto] + saturation_value(NX_INT): + doc: | + The value at which the detector goes into saturation. Especially common to CCD + detectors, the data is known to be invalid above this value. For example, given + a saturation_value and an underload_value, the valid pixels are those less than + or equal to the saturation_value and greater than or equal to the + underload_value. + underload_value(NX_INT): + doc: | + The lowest value at which pixels for this detector would be reasonably measured. + The data is known to be invalid below this value. For example, given a + saturation_value and an underload_value, the valid pixels are those less than or + equal to the saturation_value and greater than or equal to the underload_value. + number_of_cycles(NX_INT): + doc: | + CCD images are sometimes constructed by summing together multiple short + exposures in the electronics. This reduces background etc. This is the number of + short exposures used to sum images for an image. + sensor_material(NX_CHAR): + doc: | + At times, radiation is not directly sensed by the detector. Rather, the detector + might sense the output from some converter like a scintillator. This is the name + of this converter material. + sensor_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + At times, radiation is not directly sensed by the detector. Rather, the detector + might sense the output from some converter like a scintillator. This is the + thickness of this converter material. + threshold_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Single photon counter detectors can be adjusted for a certain energy range in + which they work optimally. This is the energy setting for this. + (NXdetector_module): + doc: | + For use in special cases where the data in NXdetector is represented in several + parts, each with a separate geometry. Use one or more instances of the + NXdetector_module group to declare regions of interest or some other subdivision + of a detector. + (NXoff_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the detector are + not of uniform shape. + (NXcylindrical_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the detector are + not of uniform shape and require being described by cylinders. + \@default: + doc: | + .. 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. + amplifier_type(NX_CHAR): + doc: | + Type of electron amplifier, MCP, channeltron, etc. + detector_type(NX_CHAR): + doc: | + Description of the detector type, DLD, Phosphor+CCD, CMOS. + detector_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to detector. + amplifier_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the amplifier. + amplifier_bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + The low voltage of the amplifier migh not be the ground. + sensor_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each imaging sensor chip on the detector. + sensor_count(NX_INT): + unit: NX_UNITLESS + doc: | + Number of imaging sensor chips on the detector. + sensor_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Physical size of the pixels of the imaging chip on the detector. + sensor_pixels(NX_INT): + unit: NX_UNITLESS + doc: | + Number of raw active elements in each dimension. Important for swept scans. + (NXdata): + doc: | + raw data output from the detector diff --git a/contributed_definitions/nyaml/NXdistortion.nxdl.xml b/contributed_definitions/nyaml/NXdistortion.nxdl.xml deleted file mode 100644 index 88e1202ff0..0000000000 --- a/contributed_definitions/nyaml/NXdistortion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of symmetry points used for distortion correction - - - - - Number of points of the matrix distortion field (x direction) - - - - - Number of points of the matrix distortion field (y direction) - - - - - Subclass of NXprocess to describe post-processing distortion correction. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the distortion correction been applied? - - - - - For `symmetry-guided distortion correction`_, - where a pattern of features is mapped to the regular geometric structure expected - from the symmetry. Here we record the number of elementary symmetry operations. - - .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub - - - - - For symmetry-guided distortion correction. Here we record the coordinates of the - symmetry centre point. - - - - - - - - For symmetry-guided distortion correction. Here we record the coordinates of the - relevant symmetry points. - - - - - - - - - Column deformation field for general non-rigid distortion corrections. 2D matrix - holding the column information of the mapping of each original coordinate. - - - - - - - - - Row deformation field for general non-rigid distortion corrections. 2D matrix - holding the row information of the mapping of each original coordinate. - - - - - - - - - Description of the procedures employed. - - - diff --git a/contributed_definitions/nyaml/NXebeam_column.nxdl.xml b/contributed_definitions/nyaml/NXebeam_column.nxdl.xml deleted file mode 100644 index e526c3e4bc..0000000000 --- a/contributed_definitions/nyaml/NXebeam_column.nxdl.xml +++ /dev/null @@ -1,82 +0,0 @@ - - - - - Container for components to form a controlled beam in electron microscopy. - - - - - The source which creates the electron beam. - - - - Given name/alias. - - - - - - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - - - - - Type of radiation. - - - - - - - - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - - - - - - - - - - Material of which the emitter is build, e.g. the filament material. - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - - - - - - - - - A sensor used to monitor an external or internal condition. - - - - - Individual ocharacterization results for the position, shape, - and characteristics of the electron beam. - - NXtransformations should be used to specify the location - of the position at which the beam was probed. - - - diff --git a/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml b/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml deleted file mode 100644 index 34772fcd68..0000000000 --- a/contributed_definitions/nyaml/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a - pysical quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - 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 electron analyser 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. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml new file mode 100644 index 0000000000..dc39c3b878 --- /dev/null +++ b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml @@ -0,0 +1,43 @@ +category: base +doc: | + definition for a electrostatic kicker. + +type: group +NXelectrostatic_kicker(NXobject): + description(NX_CHAR): + doc: | + extended description of the kicker. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + timing(NX_FLOAT): + unit: NX_TIME + exists: ['min', '0', 'max', '1'] + doc: | + kicker timing as defined by ``description`` attribute + \@description: + type: NX_CHAR + set_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on supply. + read_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from supply. + value: + unit: NX_CURRENT + set_voltage(NX_FLOAT): + unit: NX_VOLTAGE + exists: ['min', '0', 'max', '1'] + doc: | + volage set on supply. + read_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from supply. + value: + unit: NX_VOLTAGE diff --git a/contributed_definitions/nyaml/NXellipsometry.nxdl.xml b/contributed_definitions/nyaml/NXellipsometry.nxdl.xml deleted file mode 100644 index 093341990f..0000000000 --- a/contributed_definitions/nyaml/NXellipsometry.nxdl.xml +++ /dev/null @@ -1,839 +0,0 @@ - - - - - - Variables used throughout the document, e.g. dimensions and important - parameters - - - - Size of the energy or wavelength vector used, the length of - NXinstrument/spectrometer/wavelength array - - - - - How many variables are saved in a measurement. e.g. 2 for Psi and - Delta, 16 for Mueller matrix elements, 15 for normalized Mueller - matrix, 3 for NCS, the length of NXsample/column_names - - - - - Number of incident angles used, the length of - NXinstrument/angle_of_incidence array - - - - - Number of sample parameters scanned, if you varied any of the - parameters such as temperature, pressure, or pH, the maximal length of - the arrays specified by NXsample/environment_conditions/SENSOR/value - if it exists. - - - - - Number of time points measured, the length of NXsample/time_points - - - - - Ellipsometry, complex systems, up to variable angle spectroscopy. - - Information on ellipsometry is provided, e.g. in: - - * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, - John Wiley & Sons, 2007. - * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, - North-Holland Publishing Company, 1977. - * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, - William Andrew, 2005. - - Open access sources: - - * https://www.angstromadvanced.com/resource.asp - * https://pypolar.readthedocs.io/en/latest/ - - Review articles: - - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", - J. Phys. D: Appl. Phys. 32, R45 (1999), - https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", - Thin Solid Films 571, 334-344 (2014), - https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", - Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, - (3 October 1997), - https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", - Thin Solid Films 233, 96-111 (1993), - https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", - Adv. Opt. Techn., (2022), - https://doi.org/10.1515/aot-2022-0016 - - - - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition defines: - - * elements of the experimental instrument - * calibration information if available - * parameters used to tune the state of the sample - * sample description - - - - An application definition for ellipsometry. - - - - Version number to identify which definition of this application definition was - used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant to the - application definition - - - - - - - - - Unique identifier of the experiment, such as a (globally persistent) unique - identifier. - i) The identifier is usually defined by the facility or principle investigator. - ii) The identifier enables to link experiments to e.g. proposals. - - - - - A free-text description of the experiment. What is the aim of the experiment? - The general procedure. - - - - - Start time of the experiment. UTC offset should be specified. - - - - - - Commercial or otherwise defined given name to the program that was used to - generate the result file(s) with measured data and metadata. This program - converts the measured signals to ellipsometry data. If home written, one can - provide the actual steps in the NOTE subfield here. - - - - - Either version with build number, commit hash, or description of a (online) - repository where the source code of the program and build instructions can be - found so that the program can be configured in such a way that result files can - be created ideally in a deterministic manner. - - - - - Website of the software. - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - Official telephone number of the user. - - - - - - General properties of the ellipsometry equipment - - - - The name of the instrument - - - - The used version of the hardware if available. If not a commercial instrument - use date of completion of the hardware. - - - - - - Name of the company which build the instrument - - - - - ISO8601 date when the instrument was constructed. UTC offset should be - specified. - - - - - Commercial or otherwise defined name of the software that was used for the - measurement - - - - Version and build number or commit hash of the software source code - - - - - Website of the software. - - - - - - Specify the used light source. Multiple selection possible. - - - - - Were focussing probes (lenses) used? - - - - - Were the recorded data corrected by the window effects of the lenses? - - - - - Specify the angular spread caused by the focussing probes - - - - - What type of ellipsometry was used? See Fujiwara Table 4.2 - - - - - - - - - - - - - - - - - - - Was a calibration performed? If yes, when was it done? If the calibration time - is provided, it should be specified in calibration/calibration_time. - - - - - - - - - - - - Ellipsometers require regular calibration to adjust the hardware parameters for - proper zero values and background light compensation. - - - - If calibtration status is 'calibration time provided', specify the ISO8601 date - when calibration was last performed before this measurement. UTC offset should - be specified. - - - - - Arrays which provide the measured calibration data. Multiple sets are possible, - e.g. Psi and delta measured on a e.g. silicon calibration wafer, and the - straight-through data. We recommend to provide data that is measured under the - same settings as the measurement was performed, that is if Psi and Delta are - measured for your data, also provide Psi and Delta here and use the same - wavelenghts as for the measured data. - - - - What data were recorded for the calibration? The number of variables - (N_variables) have to be set to the number of provided data columns accordingly, - e.g. psi/delta -> N_variables = 2, Jones vector -> N_variables = 4, Mueller - martix -> N_variables = 16, etc. - - - - - - - - - - - - Angle(s) of incidence used during the calibration measurement (excluding - straight through mode) - - - - - - - - The wavelength or equivalent values (which are inter-convertible). - The importer should convert all to one unit, and make the others - accessible. Historically, energy is used in eV, but for visible - spectroscopy wavelength is more common, for IR wave numbers in - 1/cm units. - - Possibly use the same type of data as for the measurement. - - - - - - - - Calibration is performed on a reference surface (usually a silicon wafer with a - well defined oxide layer) at a number of angles of incidence and in a straight - through mode (transmission in air). - - - - - - - - - - - Free-text to describe which sample was used for calibration, e.g. silicon wafer - with 25 nm thermal oxide layer. - - - - - - Incident angle of the beam vs. the normal of the bottom reflective (substrate) - surface in the sample - - - - - - - - Sample stage, holding the sample at a specific position in X,Y,Z (Cartesian) - coordinate system and at an orientation defined by three Euler angles (alpha, - beta, gamma). The stage may be motorized or manual, special for liquids or gas - environment. - - - - Specify what type of stage was used. - - - - - - - - - - - - A free-text field to provide information about the stage. - - - - - The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with the angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). - This transformation brings us from the NEXUS coordinates to the stage coordinates. - Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) - Last, provide the rotations of the sample - - - - If there is no motorized stage, we should at least qualify where the beam hits - the sample and in what direction the sample stands in a free-text description, - e.g. 'center of sample, long edge parallel to plane of incidence'. - - - - - - - For environmental measurements, the environment (liquid, vapor, vacuum etc.) is - enclosed in a cell or cryostat, which has windows both in the direction of the - source and the detector (looking from the sample). These windows also add a - phase shift to the light altering the measured signal. This shift has to be - corrected based on measuring a known sample in the environmental cell. - - - - The material of the window - - - - - - - - - - - - - - - If you specified 'other' as window material, decsribe here what it is. - - - - - Thickness of the window - - - - - Angle of the window normal (outer) vs. the substrate normal (similar to the - angle of incidence). - - - - - Recorded data that can be used to calculate the window effect. Typically this is - the substrate (e.g. silicon with thermal oxide layer) in air without window and - in a known medium with the window. - - - - What sample was used to estimate the window effect? - - - - - Wavelength of the reference data. Use the same wavelengths at which all other - measurements are recorded - - - - - - - - Recorded data of a reference surface with and without window/medium. - - - - - - - - - - - - - Which type of detector was used, and what is known about it? A detector can be a - photomultiplier (PMT), a CCD in a camera, or an array in a spectrometer. If so, - the whole detector unit goes in here. Integration time is the count time field, - or the real time field. See their definition. - - - - What kind of detector module is used, e.g. CCD-spectrometer, CCD camera, PMT, - photodiode, etc. - - - - - - - - - - - - - If you specified 'other' as detector type, please write down what it is. - - - - - Define how many rotations of the rotating element were taken into account per - spectrum. - - - - - Define which element rotates, e.g. polarizer or analyzer. - - - - - - - - - - - Rotation rate, if the revolution does not change during the measurement. - - - - - Specify maximum and minimum values for the revolution. - - - - - - - - Minimum signal for which dynamic averaging is performed. - - - - - Value for the minimum intensity chosen. Data points below this value might be - skipped by the instrument - - - - - - The spectroscope element of the ellipsometer before the detector, but often - integrated to form one closed unit. Information on the dispersive element can be - specified in the subfield GRATING. Note that different gratings might be used - for different wavelength ranges. The dispersion of the grating for each - wavelength range can be stored in grating_dispersion. - - - - Wavelength value(s) used for the measurement. An array of 1 or more elements. - Length defines N_wavelength - - - - - - - - Diffraction grating, as could be used in a monochromator. If two or more - gratings were used, define the angular dispersion and the wavelength range - (min/max wavelength) for each grating and make sure that the wavelength ranges - do not overlap. The dispersion should be defined for the entire wavelength range - of the experiment. - - - - Dispersion of the grating in nm/mm used. - - - - - Minimum wavelength of the grating. - - - - - Maximum wavelength of the grating. - - - - - - Spectral resolution of the instrument. - - - - - Define the width of the monochromator slit in the subfield x_gap. - - - - Was the slit width fixed? - - - - - If slit width was not fixed, define the maximum slit width. - - - - - - - - Properties of the sample, its history, the sample environment and experimental - conditions (e.g. surrounding medium, temperature, pressure etc.), along with the - data (data type, wavelength array, measured data). - - - - Use Hill's system for listing elements of the periodic table which are inside or - attached to the surface of the specimen and thus relevant from a scientific - point. The purpose of this field is to allow material databases to parse the - relevant elements without having to interpret the sample history or other - fields. - - - - - Descriptive name of the sample - - - - - Ideally, a reference to the location or a unique (globally persistent) - identifier (e.g.) of e.g. another file which gives as many as possible details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history. In the case that such a detailed history of the - sample is not available, use this field as a free-text description to specify - details of the sample and its preparation. - - - - - ISO8601 date with time zone (UTC offset) specified. - - - - - Qualitative description of the layer structure for the sample. For example: - Si/native oxide/thermal oxide/polymer/peptide - - - - - An identifier to correlate data to the experimental conditions, if several were - used in this measurement; typically an index of 0 - N - - - - - Select which type of data was recorded, for example Psi and Delta (see: - https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It is possible to - have multiple selections. Data types may also be converted to each other, e.g. a - Mueller matrix contains N,C,S data as well. This selection defines how many - columns (N_variables) are stored in the data array. - - - - - - - - - - - - - Please list in this array the column names used in your actual data. That is - ['psi', 'delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for a full Mueller matrix, - etc. - - - - - - - - Resulting data from the measurement, described by data type. Minimum two columns - containing Psi and Delta, or for the normalized Mueller matrix it may be 16 (or - 15 if the element (1,1) is all 1). - - - - - - - - - - - - Specified uncertainties (errors) of the data described by data type. The - structure is the same as for the measured data. - - - - - - - - - - - - An array of relative time points if a time series was recorded. - - - - - - - - Specify external parameters that have influenced the sample. - - - - Describe what was the medium above or around the sample. The common model is - built up from the substrate to the medium on the other side. Both boundaries are - assumed infinite in the model. Here, define the name of the medium (e.g. water, - air, UHV, etc.). - - - - - Array of pairs of complex refractive indices of the medium for every measured - wavelength. Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. Specify the complex - refractive index: n + ik - - - - - - - - How many measurements were done varying the parameters? This forms an extra - dimension beyond incident angle, time points and energy/wavelength (this is the - length of the 4th dimension of the data). Defaults to 1. - - - - - Indicates which parameter was changed. Its definition must exist below. The - specified variable has to be number_of_runs long, providing the parameters for - each data set. If you vary more than one parameter simultaneously use one signal - instance for each. Record every parameter value in a linear manner, so N_p1 is - the number of measurements taken. For example, if you measure at two - temperatures and three pressures the temperature signal value looks like [T1, - T1, T1, T2, T2, T2] and the pressure signal value looks like [p1, p2, p3, p1, - p2, p3], and N_p1 = 6. - - - - - - - - - - - - - Was the sample modified using an optical source? Describe in this group the - parameters of the optical excitation used. - - - - Wavelength value(s) or the range used for excitation. In cases of continuous - laser radiation, a value or a set of values may do but for other illumination - types, such as pulsed lasers, or lamps, a range may describe the source better. - - - - - Specify the FWHM of the excitation - - - - - How long was the sample excited. - - - - - The integrated energy of light pulse. - - - - - - A sensor used to monitor an external condition. The value field contains the - measured values. If it is constant within an error for every run then use only - an array of length one. - - - - - - - What parameters are derived from the above data. - - - - Light loss due to depolarization as a value in [0-1]. - - - - - - A default view of the data, in this case Psi vs. wavelength and the angles of - incidence. If Psi does not exist, use other Mueller matrix elements, such as N, - C and S. - - - - We recommend to use wavelength as a default attribute, but it can be replaced in - the case of not full spectral ellipsometry to any suitable parameter along the - X-axis. - - - - - diff --git a/contributed_definitions/nyaml/NXem.nxdl.xml b/contributed_definitions/nyaml/NXem.nxdl.xml deleted file mode 100644 index 51d8fbae35..0000000000 --- a/contributed_definitions/nyaml/NXem.nxdl.xml +++ /dev/null @@ -1,1210 +0,0 @@ - - - - - Characterization and session with one sample in an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM), whether it be with scanning electron microscope (SEM) - or transmission electron microscope (TEM) instruments, are versatile tools for - preparing and characterizing samples and specimens. The term specimen is considered - a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating either the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an EM is an electron accelerator. Experimentalists use an EM - in sessions during which they characterize as well as prepare specimens. - This application definition describes data and metadata about processes and - characterization tasks applied to one specimen. The application definition - focuses on the usage of EM in materials research. The application definition - design makes it in principle applicable also in cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple NXentry instances. - - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process maybe even operating - the microscope. Oftentimes the scientists operate the instrument themselves - either on-site or remotely and can ask technicians for support. - In all cases, these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate application - definitions for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is used mainly to measure the - transmitted electron beam. This calls for using a different lens setup and - relative placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to illuminate - through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Compared to SEMs, TEMs have a different relative arrangement between the - lenses and the specimen which is most obvious by the different relative - arrangement of the objective lens versus the specimen. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Consequently, detectors can also be similar - if not exactly the same. - - **An embracing schema instead of specific SEM or TEM schemes**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower - the addressed user base is which develops or uses schemes for research data - management (RDM) with EM, the more understandable it is that scientists of - either community (or sub-community) ask for method-specific schemes. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemes such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the development in the past has shown that these activities led to - a zoo of schemes and especially vocabulary in use with implementations of these - into many data and file formats. There is nothing which prevents the communities - to make these schemes open and interoperable. Open here means specifically not - that all data are compliant with/or use the schema and have to end up in the - open-source domain. There can be embargo periods first of all. - - Open means that the metadata and associated schemata are documented in a manner - that as many details as possible are open in the sense that others can understand - what the (meta)data mean conceptually. Instead of trying of maintain a zoo - of eventually difficult to make interoperable formats and schema we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different - schemes with associated representations of data and metadata in EM: - Each combination of schemes or an interoperable-made handshake between two - file formats or software packages has to be maintained by software developers. - This counts especially when data should be processed interoperably - between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemes and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemes. - - Aiming for more standardization, i.e. a lower number of schemes rather than - a single standard for electron microscopy is a compromise that can serve - academia as it enables the EM community to focus their software development - efforts on those schemes, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for vendors of EM hard- and software as it improves the longevity of certain - schema; and thus can help to incentivize vendors to support the community with - implementing support for such schemes into their proprietary applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemes for EM research. - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemes differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemes can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be software from specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions and strictly speaking an application definition can only be - really general if it does not make a single entry required, in which case however - it would also not offer much value as even empty datasets would be compliant. - - **Verification of constraints and conditions**: - Tools like NeXus so far do not avoid or protect against all such possible - inconsistencies; however NeXus offers a mechanism and toolset, through which - schemes can be documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - This application definition takes a key step towards standardization of EM data. - It offers a controlled vocabulary and relation between concepts and data - relevant for research with electron microscopes. To be most efficient and - offering reusability, the application definition should be understood as a - template that one should ideally use as is. This application definition - is called NXem. NXem can be considered a base for designing more specialized - definitions (ideally prefixed with NXem) *method*. - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but make - them optional or, even better, propose changes in this NXem application definition. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as vendors also have a relevant interest in finding - a compromise between being open to their user and securing their business. - - EM experiments by design illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being vendor-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - often undocumented in detail by vendors. This serves users and makes EM - experiments easier understandable and conveniently executable for a broad - user base. On the flipside these subtilities limit the opportunities for - making application definitions too general. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemes. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what are metadata in EM. While doing - so we found that existent terminology can be encoded into a more controlled - vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Generic experimental details (time-zone-aware timestamp, identifiers, name); - conceptually these are session details. A session at a microscope may - involve the characterization of multiple specimens. For each specimen - an instance of an (NXentry) is created. Details of the instrument have to - be stored at least in an entry. Other entries should refer to these - metadata via links to reduce redundancies. - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of NXevent_data_em have an own em_lab section. - The reason is that EMs can be highly dynamic, be used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * NXmonitor; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. Alternatively, NXevent_data_em - instances can be used to store time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * NXinstrument; - conceptually this is a container to store arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * NXuser; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details who executed an event of data acquisition or processing. - * NXevent_data_em instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * NXdata; at the top-level, conceptually, this is a place for documenting - available default plottable data. A default plottable can be useful for - research data management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables not intended to serve every possible analysis and - visualization demand but be a preview. We made this choice because what - constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals and - images. Examples for possible default plottables could be arbitrarily - taken secondary, back-scattered, electron image, diffraction pattern, - EELS spectra, composition, or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Above images, spectra, and mappings should be stored as NXdata instances, - ideally formatted in such a way that they can be displayed with - visualization software that can be specific for the file format in which - the data are stored. NeXus specifies only the data model, i.e. the terms - and their relations. These descriptions can be implemented and stored in - JSON, HDF5, XML, or HSDS, file storage, or even other formats, although - HDF5 is often used. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images of electron counts detected in specific operation modes (bright - field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) - * Spectra (X-ray quanta or Auger electron counts) - * These data are in virtually all cases a result of some numerical processing. - It makes sense to name these data and processing tasks with a controlled - vocabulary, e.g. SE (secondary electron), BSE (back-scattered electron), - Kikuchi, X-ray, Auger, Cathodolum(inescence) etc. - - A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk). To this end the schema, here makes no - specific assumptions, not even that all the fields/group of a schema instance - have to be stored at all into a single file. Instead, the schema specifies the - relations between metadata, some of the constraints and conditions on how the - data should be formatted, what the data conceptually represent, and which terms - (controlled vocabulary) is practical to store to index specific quantities. - - In effect, the application definition is a graph which describes how - numerical data and (meta)data for EM research are related to one another. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_em instances to - provide additional pieces of information. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - - - - Commercial or otherwise given name to the program which was used to - create the file. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual NXprocess - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - Program 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. - - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. At the point it enters the microscope the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an NXinteraction_vol_em for - individual NXevent_data_em instances can provide a much better description - of the relevant details why one would otherwise ask to store the density - of the specimen. - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_em sections. These event instances take the role of time snapshot. - For an NXevent_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_gun group - again the details of the gun type and manufacturer but only the high-voltage - if for that event the high-voltage was different. If for all events - the high-voltage was the same it is not even necessary to include an - electron_gun section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Free text option to write further details about the detector. - - - - - - - - - - - - - - - - - - - - - - - - - - A container to structure a set of NXevent_data_em instances. - - An event is a time point/time interval during which the microscope - was configured in a specific way and the microscope was used - to take a measurement. The microscope is considered stable during this - interval. - - Each NXevent_data_em instance holds an acquisition task with the microscope. - For instance the capturing of a secondary electron, backscattered - electron, diffraction image, or spectrum. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed into consumable data like images, spectra, - etc. These on-the-fly data processing tasks are usually performed - by the control software, eventually realized with custom scripts. - - Furthermore, NXevent_dat_em instances can document specific values - and settings of the microscope during the snapshot/event. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_em instances can hold several specific - NXimage_em or NXspectrum_em instances taken and considered as - one event, i.e. a point in time when the microscope had the - settings specified either in NXinstrument or in this NXevent_data_em - instance. - - The application definition is designed without an explicit need - an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. An NXevent_data_em can be used to document a - specific state of the microscope at a time without having it placed - into the NXinstrument group. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there is no vendor-overarching standard according to which - electron microscope data are documented and stored. Therefore, it is - still a frequently the case that vendor-specific files have many fields - that cannot be safely mapped. Therefore, users are always adviced to - keep the vendor files. Working however with these vendor files inside - specific software, like materials databases, demands for parsers which - extract pieces of information from the vendor representation (numerical - data and metadata) and map them on a schema with which the database - and its associated software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented dynamically, coveringly enough in our opinion so that it is - safe to assume all vendor field names are known, logically understood, - interpretable, and thus mappable on a common schema using a controlled - common vocabulary. - - Therefore we encourage user for now to store for each image_set_em - or spectra_set_em instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain like numerical data and metadata were copied into an instance - of this schema for the purpose of working with the data in e.g. tools - offered by the materials database. - - During work on implementing file format/metadata parsers and developing - this application definition we realized that several software tools - currently do not consistently track time-zone-aware timestamps of - events associated with the data, processing, and during the microscope - session. This is in partly a consequence of vendor which store - detailed time data in different formats. We would like to encourage the - community and especially the vendors to work towards a standardization, - or at least a open documentation of the way how time-zone-aware time - data are collected and stored how and where during a microscope session - and how they end up in files and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - Reference to a specific state and setting of the microscope components. - - - - - - The detector or set of detectors that was used to collect this signal. - The name of the detector has to match one of the names of available - NXdetector instances e.g. if the instrument has an ebsd_camera - the detector for an NXimage_em_kikuchi should be the NXdetector - instance called ebsd_camera. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml b/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml deleted file mode 100644 index c7aac11023..0000000000 --- a/contributed_definitions/nyaml/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/nyaml/NXentry.yaml b/contributed_definitions/nyaml/NXentry.yaml new file mode 100644 index 0000000000..7527a9528e --- /dev/null +++ b/contributed_definitions/nyaml/NXentry.yaml @@ -0,0 +1,202 @@ +category: base +doc: | + (**required**) ':'ref':'`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. + +type: group +(NXobject)NXentry: + \@default: + doc: | + .. index':'':' plotting + + Declares which ':'ref':'`NXdata` (or ':'ref':'`NXsubentry`) group + contains the data to be shown by default. + It is needed to resolve ambiguity when more than one ':'ref':'`NXdata` group exists. + The value is the name of the default ':'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. + + .. [#] NIAC2014 discussion summary':' + https':'//www.nexusformat.org/2014_How_to_find_default_data.html + (NXdata): + doc: | + The data group + + .. note':'':' Before the NIAC2016 meeting [#]_, at least one + ':'ref':'`NXdata` group was required in each ':'ref':'`NXentry` group. + At the NIAC2016 meeting, it was decided to make ':'ref':'`NXdata` + an optional group in ':'ref':'`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an ':'ref':'`NXdata` group + in the ':'ref':'`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + ':'ref':'`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016':' + https':'//www.nexusformat.org/NIAC2016.html, + https':'//github.com/nexusformat/NIAC/issues/16 + \@IDF_Version: + doc: | + ISIS Muon IDF_Version + title(NX_CHAR): + doc: | + Extended title for entry + experiment_identifier(NX_CHAR): + doc: | + Unique identifier for the experiment, defined by the facility, possibly linked + to the proposals + experiment_description(NX_CHAR): + doc: | + Brief summary of the experiment, including key objectives. + experiment_documentation(NXnote): + doc: | + Description of the full experiment (document in pdf, latex, ...) + collection_identifier(NX_CHAR): + doc: | + User or Data Acquisition defined group of NeXus files or NXentry + collection_description(NX_CHAR): + doc: | + Brief summary of the collection, including grouping criteria. + entry_identifier(NX_CHAR): + doc: | + Unique identifier for the measurement, defined by the facility. + entry_identifier_uuid(NX_CHAR): + doc: | + UUID identifier for the measurement. + \@version: + type: NX_CHAR + doc: | + Version of UUID used + features(NX_CHAR): + doc: | + Reserved for future use by NIAC. See + https':'//github.com/nexusformat/definitions/issues/382 + definition(NX_CHAR): + doc: | + (alternate use':' see same field in ':'ref':'`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms. + This field is provided so that ':'ref':'`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use ':'ref':'`NXsubentry`, instead, as the overlay position. + \@version: + type: NX_CHAR + doc: | + NXDL version number + \@URL: + type: NX_CHAR + doc: | + URL of NXDL file + definition_local(NX_CHAR): + doc: | + Local NXDL schema extended from the entry specified in the ``definition`` field. + This contains any locally-defined, additional fields in the entry. + \@version: + type: NX_CHAR + doc: | + NXDL version number + \@URL: + type: NX_CHAR + doc: | + URL of NXDL file + start_time(NX_DATE_TIME): + doc: | + Starting time of measurement + end_time(NX_DATE_TIME): + doc: | + Ending time of measurement + duration(NX_INT): + unit: NX_TIME + doc: | + Duration of measurement + collection_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time transpired actually collecting data i.e. taking out time when collection + was suspended due to e.g. temperature out of range + run_cycle(NX_CHAR): + doc: | + Such as '2007-3'. Some user facilities organize their beam time into run cycles. + program_name(NX_CHAR): + doc: | + Name of program used to generate this file + \@version: + type: NX_CHAR + doc: | + Program version number + \@configuration: + type: NX_CHAR + doc: | + configuration of the program + revision(NX_CHAR): + doc: | + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + \@comment: + type: NX_CHAR + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flightpath before the sample position. This can be determined by a + chopper, by the moderator or the source itself. In other words':' it the distance + to the component which gives the T0 signal to the detector electronics. If + another component in the NXinstrument hierarchy provides this information, this + should be a link. + experiment_location(NX_CHAR): + doc: | + City and country where the experiment took place + experiment_start_date(NX_DATE_TIME): + doc: | + Start time of experimental run that includes the current measurement, for + example a beam time. + experiment_end_date(NX_DATE_TIME): + doc: | + End time of experimental run that includes the current measurement, for example + a beam time. + experiment_institution(NX_CHAR): + doc: | + Name of the institution hosting the facility + experiment_facility(NX_CHAR): + doc: | + Name of the experimental facility + experiment_laboratory(NX_CHAR): + doc: | + Name of the laboratory or beamline + notes(NXnote): + doc: | + Notes describing entry + thumbnail(NXnote): + doc: | + A small image that is representative of the entry. An example of this is a + 640x480 jpeg image automatically produced by a low resolution plot of the + NXdata. + \@type: + doc: | + The mime type should be an ``image/*`` + enumeration: [image/*] + (NXuser): + (NXsample): + (NXinstrument): + (NXcollection): + (NXmonitor): + (NXparameters): + (NXprocess): + (NXsubentry): diff --git a/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml b/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml deleted file mode 100644 index a4c1c280da..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,221 +0,0 @@ - - - - - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations caused or apertures used. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then choose a different value. As the aperture affects - the electron beam it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of objects, - and eventually (externally) applied stimuli and positioning of the specimen. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Theoretically, an instrument and specimen should be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - stable and of high enough quality to reuse data collection. - - In all these cases it is practical to store time-dependent data of the - instrument state not in the respective instrument component groups - of the top-level NXinstrument but in a sort of a log of event data. - This is the idea behind the NXevent_data_em snapshot containers. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - But does this warrant to document the microscope state at an even finer - and impractical in-between one collects signal time intervals? - - This is a question of how finely does one granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and illuminates a portion of the material, i.e. - the interaction volume, whose signal contributions are then counted by the - detector(s) as per pixel- or per voxel signal in the region-of-interest. - In principle this application definition allows for such doing so. - However, in most cases such a fine granularization would demand the collection - of data which are as of now hardly retrievable with commercial instruments - nor of primary interest. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. Which warrant an own - consideration in the future. A more detailed overview of such computational - steps to cope with scan distortions is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axis; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements - (i.e. images, spectra of scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective groups of the NXinstrument though - inside instances of here detailed NXevent_data_em. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Reference to a specific state and setting of the microscope components. - - - - - Which specific event/measurement type. Examples are: - - * In-lens/backscattered electron, usually has quadrants - * Secondary_electron, image, topography, fractography, overview images - * Backscattered_electron, image, Z or channeling contrast (ECCI) - * Bright_field, image, TEM - * Dark_field, image, crystal defects - * Annular dark field, image (medium- or high-angle), TEM - * Diffraction, image, TEM, or a comparable technique in the SEM - * Kikuchi, image, SEM EBSD and TEM diffraction - * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) - * Electron energy loss spectra for points, lines, surfaces, TEM - * Auger, spectrum, (low Z contrast element composition) - * Cathodoluminescence (optical spectra) - * Ronchigram, image, alignment utility specifically in TEM - * Chamber, e.g. TV camera inside the chamber, education purposes. - - - - - The detector or set of detectors that was used to collect this signal. - The name of the detector has to match the names used for available - detectors, i.e. if the instrument has an *ebsd_camera* - named detector, instances of NXimage_em_kikuchi should use - *ebsd_camera* as the detector name. - - - - - - - - - - - - - - - - - - - A group where specific settings of the instrument during the - event can be captured. This is the preferred way to keep track of - different settings of the microscope during the session. - For instance, a user may first take an overview image with different - magnification and settings and then start a spectrum analyses. - These should be stored as two NXevent_data_em instances in an - application definition. Each storing the specific settings. - - NXfabrication relevant details should not be repeated because - we assume that the session is with the same microscope. - Namely, it is hopefully not happening that someone builds out a - component of the microscope while is taking a measurement with it. - For this reason the specialized NXinstrument here contains no - NXfabrication group. - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml b/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml deleted file mode 100644 index 20776cd618..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_em_set.nxdl.xml +++ /dev/null @@ -1,11 +0,0 @@ - - - - - Container to hold NXevent_data_em instances of an electron microscope session. - - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. - - - diff --git a/contributed_definitions/nyaml/NXfabrication.nxdl.xml b/contributed_definitions/nyaml/NXfabrication.nxdl.xml deleted file mode 100644 index 2c86c961dc..0000000000 --- a/contributed_definitions/nyaml/NXfabrication.nxdl.xml +++ /dev/null @@ -1,29 +0,0 @@ - - - - - Details about a component as defined by its manufacturer. - - - - Company name of the manufacturer. - - - - - Version or model of the component named by the manufacturer. - - - - - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. - - - - - Free-text list with eventually multiple terms of - functionalities which the component offers. - - - diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml b/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml deleted file mode 100644 index 229bac7c03..0000000000 --- a/contributed_definitions/nyaml/NXgraph_edge_set.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of edges. - - - - - A set of (eventually directed) edges which connect nodes/vertices of a graph. - - - - Total number of edges, counting eventual bidirectional edges only once. - - - - - Integer which specifies the first index to be used for distinguishing - edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish edges for explicit indexing. - - - - - - - - Specifier whether each edge is non-directional, one-directional, - or bidirectional. Use the smallest available binary representation - which can store three different states: - - * 0 / state 0x00 is non-directional - * 1 / state 0x01 is one-directional - * 2 / state 0x02 is bi-directional - - - - - - - - Pairs of node/vertex identifier. Each pair represents the connection - between two nodes. - - In the case that the edge is non- or bi-directional - node identifier should be stored in ascending order is preferred. - - In the case of one-directional, for each pair the identifier of the source - node is the first entry in the pair. The identifier of the target is the - second entry in the pair, i.e. the pair encodes the information as - if one traverses the edge from the source node walking to the target node. - - - - - - - - - A human-readable qualifier which type or e.g. class instance the - edge is an instance of. - - - - - - - - A human-readable label/caption/tag for the edge. - - - - - - diff --git a/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml b/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml deleted file mode 100644 index 7d5514447e..0000000000 --- a/contributed_definitions/nyaml/NXgraph_node_set.nxdl.xml +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the graph. Eventually use one for categorical. - - - - - The cardinality of the set, i.e. the number of nodes/vertices of the - graph. - - - - - A set of nodes/vertices in space representing members of a graph. - - - - - - Integer which specifies the first index to be used for distinguishing - nodes. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish nodes for explicit indexing. - - - - - - - - A human-readable qualifier which type or e.g. class instance the - node is an instance of. As e.g. a NeXus application definition is a - graph, more specifically a hierarchical directed labelled property graph, - instances which are groups like NXgraph_node_set could have an is_a - qualifier reading NXgraph_node_set. - - - - - - - - A human-readable label/caption/tag of the graph. - - - - - - diff --git a/contributed_definitions/nyaml/NXgraph_root.nxdl.xml b/contributed_definitions/nyaml/NXgraph_root.nxdl.xml deleted file mode 100644 index 3afc941e8e..0000000000 --- a/contributed_definitions/nyaml/NXgraph_root.nxdl.xml +++ /dev/null @@ -1,14 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - An instance of a graph. - - - - diff --git a/contributed_definitions/nyaml/NXibeam_column.nxdl.xml b/contributed_definitions/nyaml/NXibeam_column.nxdl.xml deleted file mode 100644 index 8ea3088bab..0000000000 --- a/contributed_definitions/nyaml/NXibeam_column.nxdl.xml +++ /dev/null @@ -1,99 +0,0 @@ - - - - - Container for components of a focused-ion-beam (FIB) system. - - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - - - - - The source which creates the ion beam. - - - - Given name/alias for the ion gun. - - - - - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - - - - - - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - - - - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - - - - - Average/nominal brightness - - - - - Charge current - - - - - Ion acceleration voltage upon source exit and entering the vacuum flight path. - - - - - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - - - - - - - - - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - NXtransformations should be used to specify the location or position - at which details about the ion beam are probed. - - - diff --git a/contributed_definitions/nyaml/NXimage_set_em.nxdl.xml b/contributed_definitions/nyaml/NXimage_set_em.nxdl.xml deleted file mode 100644 index 97e8f292dd..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em.nxdl.xml +++ /dev/null @@ -1,86 +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 with an electron microscope. - - - - - Imaging mode in which the instrument was and with which the images - were captured. - - - - - - 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/nyaml/NXimage_set_em.yaml b/contributed_definitions/nyaml/NXimage_set_em.yaml index 9acd6e6fb2..a299907590 100644 --- a/contributed_definitions/nyaml/NXimage_set_em.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em.yaml @@ -1,69 +1,61 @@ category: base -doc: | +doc: | Container for reporting a set of images taken with an electron microscope. -symbols: - n_images: Number of images in the stack. - n_y: Number of pixel per image in the slow direction. - n_x: Number of pixel per image in the fast direction. -NXimage_set_em: - (NXprocess): - doc: | - Details how images were processed from the detector readings. - source: - doc: | - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXimage_set_em were loaded during - parsing to represent them in e.g. databases. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - program: - doc: | - Commercial or otherwise given name to the program which was used - to process detector data into the adf image(s). - \@version: - doc: | - Program 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. + +symbols: + n_images: | + Number of images in the stack. + + n_y: | + Number of pixel per image in the slow direction. + + n_x: | + Number of pixel per image in the fast direction. + +type: group +NXimage_set_em(NXobject): (NXprocess): mode: - doc: | + doc: | Imaging mode in which the instrument was and with which the images were captured. stack(NXdata): - doc: | + doc: | Image (stack). data_counts(NX_NUMBER): - doc: Image intensity values. unit: NX_UNITLESS + doc: | + Image intensity values. dimensions: rank: 3 dim: [[1, n_images], [2, n_y], [3, n_x]] axis_image_identifier(NX_UINT): - doc: Image identifier unit: NX_UNITLESS + doc: | + Image identifier dimensions: rank: 1 dim: [[1, n_images]] \@long_name: - doc: Image identifier. + doc: | + Image identifier. axis_y(NX_NUMBER): - doc: Pixel coordinate center of mass along y direction. unit: NX_LENGTH + doc: | + Pixel coordinate center of mass along y direction. dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: Coordinate along y direction. + doc: | + Coordinate along y direction. axis_x(NX_NUMBER): - doc: Pixel coordinate center of mass along x direction. unit: NX_LENGTH + doc: | + Pixel coordinate center of mass along x direction. dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: Coordinate along x direction. + doc: | + Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml deleted file mode 100644 index b776f4731b..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_adf.nxdl.xml +++ /dev/null @@ -1,130 +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 annular dark field images. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - - - Details how (HA)ADF images were processed from the detector readings. - - - - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXimage_set_em_adf were loaded during - parsing to represent them in e.g. databases. - - - - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - - - - - - Commercial or otherwise given name to the program which was used - to process detector data into the adf image(s). - - - - Program 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. - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - Annular dark field 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/nyaml/NXimage_set_em_bf.yaml b/contributed_definitions/nyaml/NXimage_set_em_bf.yaml new file mode 100644 index 0000000000..207b8f5485 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_bf.yaml @@ -0,0 +1,8 @@ +category: base +doc: | + Container for reporting a set of images taken in bright field mode. + +type: group +(NXobject)NXimage_set_em_bf: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXimage_set_em_bse.yaml b/contributed_definitions/nyaml/NXimage_set_em_bse.yaml new file mode 100644 index 0000000000..131e47f0f1 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_bse.yaml @@ -0,0 +1,8 @@ +category: base +doc: | + Container for reporting a set of back-scattered electron images. + +type: group +(NXobject)NXimage_set_em_bse: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml b/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml new file mode 100644 index 0000000000..fbbfc51dec --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml @@ -0,0 +1,8 @@ +category: base +doc: | + Container for images recorded with e.g. a TV camera in the microscope chamber. + +type: group +(NXobject)NXimage_set_em_chamber: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXimage_set_em_df.yaml b/contributed_definitions/nyaml/NXimage_set_em_df.yaml new file mode 100644 index 0000000000..b56a802faf --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_df.yaml @@ -0,0 +1,8 @@ +category: base +doc: | + Container for reporting a set of images taken in dark field mode. + +type: group +(NXobject)NXimage_set_em_df: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml b/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml new file mode 100644 index 0000000000..8c09377ea4 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml @@ -0,0 +1,8 @@ +category: base +doc: | + Container for reporting a set of diffraction images. + +type: group +(NXobject)NXimage_set_em_diffrac: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml b/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml new file mode 100644 index 0000000000..3dd7da7ee8 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml @@ -0,0 +1,8 @@ +category: base +doc: | + Container for reporting back-scattered electron channeling contrast images. + +type: group +(NXobject)NXimage_set_em_ecci: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.nxdl.xml deleted file mode 100644 index 23bd4bb351..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - - Number of scanned points. Scan point may have none, one, or more - pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per Kikuchi pattern in the slow direction. - - - - - Number of pixel per Kikuchi pattern in the fast direction. - - - - - Measured set of electron backscatter diffraction data, aka Kikuchi pattern. - Kikuchi pattern are the raw data for computational workflows in the field - of orientation (imaging) microscopy. The technique is especially used in - materials science and materials engineering. - - Based on a fuse of the `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - of the DREAM.3D community and the open H5OINA format of Oxford Instruments - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ - - EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional - orientation microscopy. So-called serial section analyses. For a detailed - overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - With serial-sectioning this involves however always a sequence of measuring, - milling. In this regard, each serial section (measuring) and milling - is an own NXevent_data_em instance and thus there such a three-dimensional - characterization should be stored as a set of two-dimensional data, - with as many NXevent_data_em instances as sections were measured. - - These measured serial sectioning images need virtually always post-processing - to arrive at the aligned and cleaned image stack before a respective digital - model of the inspected microstructure can be analyzed. The resulting volume - is often termed a so-called (representative) volume element (RVE). - Several software packages are available for performing this post-processing. - For now we do not consider metadata of these post-processing steps - as a part of this base class because the connection between the large variety - of such post-processing steps and the measured electron microscopy data - is usually very small. - - If we envision a (knowledge) graph for EBSD it consists of individual - sub-graphs which convey information about the specimen preparation, - the measurement of the specimen in the electron microscope, - the indexing of the collected Kikuchi pattern stack, - eventual post-processing of the indexed orientation image - via similarity grouping algorithms to yield (grains, texture). - Conceptually these post-processing steps are most frequently - serving the idea to reconstruct quantitatively so-called - microstructural features (grains, phases, interfaces). Materials scientists - use these features according to the multi-scale materials modeling paradigm - to infer material properties. They do so by quantifying correlations between - the spatial arrangement of the features, their individual properties, - and (macroscopic) properties of materials. - - - - Details how Kikuchi pattern were processed from the detector readings. - Scientists interested in EBSD should inspect the respective NXem_ebsd - application definition which can be used as a partner application definition - to detail substantially more details to this processing. - - - - - Collected Kikuchi pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably by the instrument - given the way how the instrument and control software was configured - for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belong to which scan point. - In an example we may assume we collected three scan points. For the first - we measure one pattern, for the second we measure three pattern, - for the last we measure no pattern. - The values of scan_point_identifier will be 0, 1, 1, 1, as we have - measured four pattern in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. Use compressed - arrays allows to store the scan_point_identifier efficiently. - - - - - - - - Signal intensity. For so-called three-dimensional or serial sectioning - EBSD it is necessary to follow a sequence of specimen surface preparation - and data collection. In this case users should collect the data for each - serial sectioning step in an own instance of NXimage_set_em_kikuchi. - All eventual post-processing of these measured data should be documented - via NXebsd, resulting microstructure representations should be stored - as NXms. - - - - - - - - - Kikuchi pattern intensity - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Kikuchi pattern identifier - - - - - - Pixel coordinate along the y direction. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the x direction. - - - - - - - Label for the x axis - - - - - diff --git a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml index 2711ff2a9a..7e0065bcf6 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml @@ -1,26 +1,21 @@ category: base -symbols: - n_sc: Number of scanned points. Scan point may have none, one, or more pattern. - n_p: Number of diffraction pattern. - n_y: Number of pixel per Kikuchi pattern in the slow direction. - n_x: Number of pixel per Kikuchi pattern in the fast direction. -doc: | +doc: | Measured set of electron backscatter diffraction data, aka Kikuchi pattern. Kikuchi pattern are the raw data for computational workflows in the field of orientation (imaging) microscopy. The technique is especially used in materials science and materials engineering. - Based on a fuse of the `M. A. Jackson et al. `_ + Based on a fuse of the `M. A. Jackson et al. `_ of the DREAM.3D community and the open H5OINA format of Oxford Instruments - `P. Pinard et al. `_ + `P. Pinard et al. `_ EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional orientation microscopy. So-called serial section analyses. For a detailed overview of these techniques see e.g. - * `M. A. Groeber et al. `_ - * `A. J. Schwartz et al. `_ - * `P. A. Rottman et al. `_ + * `M. A. Groeber et al. `_ + * `A. J. Schwartz et al. `_ + * `P. A. Rottman et al. `_ With serial-sectioning this involves however always a sequence of measuring, milling. In this regard, each serial section (measuring) and milling @@ -51,16 +46,30 @@ doc: | to infer material properties. They do so by quantifying correlations between the spatial arrangement of the features, their individual properties, and (macroscopic) properties of materials. -NXimage_set_em_kikuchi: - # a collection of pattern-related metadata + +symbols: + n_sc: | + Number of scanned points. Scan point may have none, one, or more pattern. + + n_p: | + Number of diffraction pattern. + + n_y: | + Number of pixel per Kikuchi pattern in the slow direction. + + n_x: | + Number of pixel per Kikuchi pattern in the fast direction. + +type: group +NXimage_set_em_kikuchi(NXobject): (NXprocess): - doc: | + doc: | Details how Kikuchi pattern were processed from the detector readings. Scientists interested in EBSD should inspect the respective NXem_ebsd application definition which can be used as a partner application definition to detail substantially more details to this processing. stack(NXdata): - doc: | + doc: | Collected Kikuchi pattern as an image stack. As raw and closest to the first retrievable measured data as possible, i.e. do not use this container to store already averaged, filtered or whatever post-processed @@ -68,7 +77,8 @@ NXimage_set_em_kikuchi: given the way how the instrument and control software was configured for your microscope session. scan_point_identifier(NX_UINT): - doc: | + unit: NX_UNITLESS + doc: | Array which resolves the scan point to which each pattern belongs. Scan points are evaluated in sequence starting from scan point zero until scan point n_sc - 1. Evaluating the cumulated of this array @@ -82,12 +92,12 @@ NXimage_set_em_kikuchi: In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. Use compressed arrays allows to store the scan_point_identifier efficiently. - unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_p]] data_counts(NX_NUMBER): - doc: | + unit: NX_UNITLESS + doc: | Signal intensity. For so-called three-dimensional or serial sectioning EBSD it is necessary to follow a sequence of specimen surface preparation and data collection. In this case users should collect the data for each @@ -95,45 +105,39 @@ NXimage_set_em_kikuchi: All eventual post-processing of these measured data should be documented via NXebsd, resulting microstructure representations should be stored as NXms. - unit: NX_UNITLESS dimensions: rank: 3 dim: [[1, n_p], [2, n_y], [3, n_x]] - # n_p fast 2, n_y faster 1, n_x fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast \@long_name: - doc: Kikuchi pattern intensity - # \@signal: intensity - # \@axes: [pattern_identifier, ypos, xpos] - # \@xpos_indices: 0 - # \@ypos_indices: 1 - # \@pattern_identifier_indices: 2 + doc: | + Kikuchi pattern intensity pattern_identifier(NX_UINT): - doc: | - Pattern are enumerated starting from 0 to n_p - 1. unit: NX_UNITLESS + doc: | + Pattern are enumerated starting from 0 to n_p - 1. dimensions: rank: 1 dim: [[1, n_p]] \@long_name: - doc: Kikuchi pattern identifier + doc: | + Kikuchi pattern identifier axis_y(NX_NUMBER): - doc: Pixel coordinate along the y direction. unit: NX_LENGTH + doc: | + Pixel coordinate along the y direction. dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: Label for the y axis + doc: | + Label for the y axis axis_x(NX_NUMBER): - doc: Pixel coordinate along the x direction. unit: NX_LENGTH + doc: | + Pixel coordinate along the x direction. dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: Label for the x axis - # maybe time code data when the pattern were taken? - # key is it all happened in between the time defined in NXevent_data_em - # optionally link to NXebsd instance? + doc: | + Label for the x axis diff --git a/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml b/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml new file mode 100644 index 0000000000..1d77b54180 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml @@ -0,0 +1,11 @@ +category: base +doc: | + Container for reporting a set of images related to a ronchigram. + + Ronchigrams are specifically used in transmission electron microscopy + to judge the settings for the aberration corrections and alignment. + +type: group +(NXobject)NXimage_set_em_ronchigram: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXimage_set_em_se.yaml b/contributed_definitions/nyaml/NXimage_set_em_se.yaml new file mode 100644 index 0000000000..eebd017d97 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_se.yaml @@ -0,0 +1,111 @@ +category: base +doc: | + Container for reporting a set of secondary electron images. + + Secondary electron images are one of the most important signal especially + for scanning electron microscopy in materials science and engineering, for + analyses of surface topography, getting an overview of the analysis region, + or fractography. + +symbols: + n_images: | + Number of images. + + n_y: | + Number of pixels along the slow scan direction (often y). + + n_x: | + Number of pixels along the fast scan direction (often x). + +type: group +(NXobject)NXimage_set_em_se: + (NXdata): + doc: | + Collected secondary electron images (eventually as an image stack). + intensity(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_p], [2, n_y], [3, n_x]] + \@long_name: + type: NX_CHAR + doc: | + Secondary electron image intensity + image_id(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + \@long_name: + type: NX_CHAR + doc: | + Image identifier + ypos(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + type: NX_CHAR + doc: | + Label for the y axis + xpos(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + type: NX_CHAR + doc: | + Label for the x axis + roi(NX_NUMBER): + unit: NX_LENGTH + doc: | + Physical dimensions of the region-of-interest on + the specimen surface which the image covers. + The first and second number are the coordinates for the + minimum edge, the third and fourth number are the coordinates + for the maximum edge of the rectangular ROI. + dimensions: + rank: 2 + dim: [[1, n_images], [2, 4]] + dwell_time(NX_FLOAT): + unit: NX_TIME + number_of_frames_averaged(NX_UINT): + unit: NX_UNITLESS + doc: | + How many frames were averaged to obtain the image. + dimensions: + rank: 1 + dim: [[1, n_images]] + bias_voltage(NX_FLOAT): + doc: | + Bias voltage applied to the e.g. Faraday cage in front of the + SE detector to attract or repell secondary electrons below + a specific kinetic energy. + (NXoptical_system_em): + exists: optional + doc: | + Container to store relevant settings affecting beam path, + magnification, and working_distance + scan_rotation(NXprocess): + doc: | + Scan rotation is an option offer by most control software. + tilt_correction(NXprocess): + doc: | + Tilt correction is an option offered by most control software of SEMs + to apply an on-the-fly processing of the image to correct for + the excursion of objects when characterized with SE images + on samples whose surface normal is tilted about an axis perpendicular + to the optical axis. + active(NX_BOOLEAN): + doc: | + Was the option switched active or not. + dynamic_focus(NXprocess): + doc: | + Dynamic focus is an option offered by most control software of SEMs + to keep the image also focused when probing locations on the specimens + beyond those for which the lens system was calibrated. + active(NX_BOOLEAN): + doc: | + Was the option switched active or not. diff --git a/contributed_definitions/nyaml/NXinstrument.yaml b/contributed_definitions/nyaml/NXinstrument.yaml new file mode 100644 index 0000000000..6a223092c4 --- /dev/null +++ b/contributed_definitions/nyaml/NXinstrument.yaml @@ -0,0 +1,71 @@ +category: base +doc: | + Collection of the components of the instrument or beamline. Template of + instrument descriptions comprising various beamline components. Each component + will also be a NeXus group defined by its distance from the sample. Negative + distances represent beamline components that are before the sample while + positive distances represent components that are after the sample. This device + allows the unique identification of beamline components in a way that is valid + for both reactor and pulsed instrumentation. + +type: group +(NXobject)NXinstrument: + name(NX_CHAR): + doc: | + Name of instrument + \@short_name: + type: NX_CHAR + doc: | + short name for instrument, perhaps the acronym + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the experiment (FWHM or gaussian broadening) + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the experiment (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the experiment (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the experiment (Airy disk radius) + temporal_resolution(NX_FLOAT): + unit: NX_TIME + doc: | + Temporal resolution of the experiment (FWHM) + (NXaperture): + (NXattenuator): + (NXbeam): + (NXbeam_stop): + (NXbending_magnet): + (NXcollimator): + (NXcollection): + (NXcapillary): + (NXcrystal): + (NXdetector): + (NXdetector_group): + (NXdisk_chopper): + (NXevent_data): + (NXfermi_chopper): + (NXfilter): + (NXflipper): + (NXguide): + (NXinsertion_device): + (NXmirror): + (NXmoderator): + (NXmonochromator): + (NXpolarizer): + (NXpositioner): + (NXsource): + DIFFRACTOMETER(NXtransformations): + (NXvelocity_selector): + (NXxraylens): + \@default: + doc: | + .. 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/nyaml/NXinteraction_vol_em.yaml b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml new file mode 100644 index 0000000000..9a96173b74 --- /dev/null +++ b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml @@ -0,0 +1,36 @@ +category: base +doc: | + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example':' + + * `S. Richter et al. `_ + * `J. Bünger et al. `_ + +type: group +(NXobject)NXinteraction_vol_em: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXion.nxdl.xml b/contributed_definitions/nyaml/NXion.nxdl.xml deleted file mode 100644 index 9e6e3be437..0000000000 --- a/contributed_definitions/nyaml/NXion.nxdl.xml +++ /dev/null @@ -1,110 +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. - - - - 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, 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 should be filled with zero. - - - - - - - - - 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, 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 labelled - as an ion of the here referred to ion_type. - - - - - - - diff --git a/contributed_definitions/nyaml/NXiv_temp.nxdl.xml b/contributed_definitions/nyaml/NXiv_temp.nxdl.xml deleted file mode 100644 index 568148ea74..0000000000 --- a/contributed_definitions/nyaml/NXiv_temp.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - Number of different temperature setpoints used in the experiment. - - - - - Number of different voltage setpoints used in the experiment. - - - - - Application definition for temperature-dependent IV curve measurements. - - In this application definition, times should be specified always together - with an UTC offset. - - This is the application definition describing temperature dependent IV curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. - - - - - - - - - - - Describes an environment setup for a temperature-dependent IV measurement experiment. - - The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. - - - - - - - - - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXlens_em.nxdl.xml b/contributed_definitions/nyaml/NXlens_em.nxdl.xml deleted file mode 100644 index 3ca0140a49..0000000000 --- a/contributed_definitions/nyaml/NXlens_em.nxdl.xml +++ /dev/null @@ -1,77 +0,0 @@ - - - - - Description of an electro-magnetic lens or a compound lens. - - Details of an `electro-magnetic 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. - - .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 - - - - Qualitative type of lens with respect to the number of pole pieces - - - - - - - - - - - - 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. - - - - - 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/nyaml/NXmagnetic_kicker.yaml b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml new file mode 100644 index 0000000000..29698fdde3 --- /dev/null +++ b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml @@ -0,0 +1,43 @@ +category: base +doc: | + definition for a magnetic kicker. + +type: group +NXmagnetic_kicker(NXobject): + description(NX_CHAR): + doc: | + extended description of the kicker. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + timing(NX_FLOAT): + unit: NX_TIME + exists: ['min', '0', 'max', '1'] + doc: | + kicker timing as defined by ``description`` attribute + \@description: + type: NX_CHAR + set_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on supply. + read_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from supply. + value: + unit: NX_CURRENT + set_voltage(NX_FLOAT): + unit: NX_VOLTAGE + exists: ['min', '0', 'max', '1'] + doc: | + voltage set on supply. + read_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from supply. + value: + unit: NX_VOLTAGE diff --git a/contributed_definitions/nyaml/NXmanipulator.nxdl.xml b/contributed_definitions/nyaml/NXmanipulator.nxdl.xml deleted file mode 100644 index a1dd3ee95d..0000000000 --- a/contributed_definitions/nyaml/NXmanipulator.nxdl.xml +++ /dev/null @@ -1,79 +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/nyaml/NXmatch_filter.nxdl.xml b/contributed_definitions/nyaml/NXmatch_filter.nxdl.xml deleted file mode 100644 index 9b73cb51d3..0000000000 --- a/contributed_definitions/nyaml/NXmatch_filter.nxdl.xml +++ /dev/null @@ -1,42 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - How many different match values does the filter specify. - - - - - Settings of a filter to select or remove entries based on their value. - - - - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - - - - - - - - - Array of values to filter according to method. For example if the filter - specifies [1, 5, 6] and method is whitelist, only entries with values - matching 1, 5 or 6 will be processed. All other entries will be filtered - out. - - - - - - diff --git a/contributed_definitions/nyaml/NXmpes.nxdl.xml b/contributed_definitions/nyaml/NXmpes.nxdl.xml deleted file mode 100644 index 468c203e5c..0000000000 --- a/contributed_definitions/nyaml/NXmpes.nxdl.xml +++ /dev/null @@ -1,331 +0,0 @@ - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (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. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(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. - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml b/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml deleted file mode 100644 index a2a62fa0aa..0000000000 --- a/contributed_definitions/nyaml/NXms_crystal_set.nxdl.xml +++ /dev/null @@ -1,123 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the description. - - - - - The number of objects, which can be crystals, grains, phases or phase - field regions. - - - - - Base class to describe data about observed crystals in microstructures. - - Both experiments and computer simulations support that atoms organize into regions - which are often separated and interconnected by different types of crystal defects. - Crystalline regions show a long-range periodic arrangement (compared to the - length scale of nearest neighbor distances). - Although the group of atoms forming a crystal is virtually never static, due - to diffusive in- and outflux of atoms and thermal fluctuations of the atoms - about their equilibrium positions, crystals are relevant persistent features - in microstructures. The size of crystals can span orders of magnitude from - meters to nanometers. - - There are two different and (somewhat extremal) views on crystals and how to - describe their eventually very rich variety of internal defects. Either - crystals can be coarse-grained into continuum objects or not. In the second case - they need a more advanced internal description of defects inside the grains - which convinces many that eventually a grain has to be viewed from its - individual atoms, its material points, and the hierarchy of structural motifs - local arrangements in the crystal. - - Despite these details, identifying crystals is foremost a labeling task. - Atoms are clustered into structural motifs and (noise) and these motifs - are again clustered into crystals. - - There are two main approaches how crystals are described in mesoscale - microstructure evolution simulations. Assuming for now transformations in the - solid state, precipitates, phase regions, sub-grains or grains are examples - of crystals: - - * Objects are either tracked explicitly in the sense that their shape will - be resolved through the crystal interfaces using e.g. a phase-field, - level-set, grid, or finite element mesh based models and implementations. - These simulations may keep track of explicit crystal/grain/object-related - quantities. Such models can treat the interface network implicitly while - still focusing their description on the explicit crystals. - During such simulations the interface is often analyzed on-the-fly, - because of technical demands (like in level-set implementations) or to - trigger specific situations where it is relevant to resolve the - position of the interfaces explicitly (like for placing seeds for phases, - recrystallizing grains etc, or for visualization purposes), demand a - description of interfaces between crystals. - For explicitly tracking simulations this base class can be applied as is. - * Objects are tracked implicitly in the sense that the computational domain - is discretized into an ensemble of what one can call material points. - Such models can be described at different length scale: On the one hand - where atom dynamics are (whether the assumption is substantiated or not) - homogenized/-able already or not. Each material point is assumed to have - at least one associated constitutive phase. - Such simulations usually do not/cannot resolve crystal-related quantities - without executing an on-the-fly post-processing of snapshot data from - which the spatial representation of the crystal is recovered. - An important case are large-strain formalism crystal plasticity methods. - Here the initial configuration represents most frequently material points - on a regular grid. Within the course of the simulation this grid gets - deformed implicitly. The code internally keeps no track of how the cells/ - material points of what is essentially a Voronoi tessellation, are deformed. - Only in the case when one would like to visualize the deformed configuration, - a post-processing of the simulation snapshot data is executed which - recovers the positions of the material points in the deformed configuration - in the laboratory coordinate system from which one can then extract a - representation of grains/precipitates, i.e. crystals. - It is a signature of such simulations that quantities like orientation - are defined as material point quantities. This means what constitutes the grain - needs to be extracted by cluster analyses. - In this regard, such simulation are essentially matching the representation and - case of molecular dynamics simulations, with the important difference - that these track atoms, from whose configuration - in a snapshot a description has to be computed what are most likely the - atoms that belong to the volume of the crystal or the interface/defect - network. - - - - - - Integer which specifies the first index to be used for distinguishing - objects. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish objects for explicit indexing. - - - - - - - - Depending on the value of dimensionality, the area or volume of each object. - - - - - - diff --git a/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml b/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml deleted file mode 100644 index 86e38a165b..0000000000 --- a/contributed_definitions/nyaml/NXms_snapshot.nxdl.xml +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Base class for data on the state of the microstructure at a given time/iteration. - - - - Is this time for a measurement or a simulation. - - - - - - - - - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Iteration or increment counter. - - - diff --git a/contributed_definitions/nyaml/NXms_snapshot.yaml b/contributed_definitions/nyaml/NXms_snapshot.yaml index 45dcdc8ef9..058d5a7c8d 100644 --- a/contributed_definitions/nyaml/NXms_snapshot.yaml +++ b/contributed_definitions/nyaml/NXms_snapshot.yaml @@ -1,17 +1,23 @@ category: base -doc: | +doc: | Base class for data on the state of the microstructure at a given time/iteration. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXms_snapshot: + +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + +type: group +NXms_snapshot(NXobject): comment: - doc: Is this time for a measurement or a simulation. + doc: | + Is this time for a measurement or a simulation. enumeration: [measurement, simulation] time(NX_NUMBER): - doc: | + unit: NX_TIME + doc: | Measured or simulated physical time stamp for this snapshot. Not to be confused with wall-clock timing or profiling data. - unit: NX_TIME iteration(NX_INT): - doc: Iteration or increment counter. unit: NX_UNITLESS + doc: | + Iteration or increment counter. diff --git a/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml b/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml deleted file mode 100644 index da814d5ac9..0000000000 --- a/contributed_definitions/nyaml/NXms_snapshot_set.nxdl.xml +++ /dev/null @@ -1,35 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - A collection of spatiotemporal microstructure data. - - - - Is this set describing a measurement or a simulation? - - - - - - - - - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - diff --git a/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml b/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml deleted file mode 100644 index ee48e025bf..0000000000 --- a/contributed_definitions/nyaml/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - A container for qualifying an electron optical system. - - - - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. - - - - - The factor of enlargement of the apparent size, not physical size, of an object. - - - - - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. - - - - - Citing the JEOL TEM glosssary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. - - - - - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - - - - - Specify further details how the beam current was measured or estimated. - - - diff --git a/contributed_definitions/nyaml/NXorientation_set.nxdl.xml b/contributed_definitions/nyaml/NXorientation_set.nxdl.xml deleted file mode 100644 index 913f0c62c3..0000000000 --- a/contributed_definitions/nyaml/NXorientation_set.nxdl.xml +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the reference space/coordinate system. - - - - - The cardinality of the set, i.e. the number of orientations. - - - - - Number of parameters for the chosen parameterization. - - - - - Details about individual orientations of a set of objects. - - For a more detailed insight into the discussion of parameterizing - orientations in materials science see: - - * https://doi.org/10.1016/j.matchar.2016.04.008 - * https://doi.org/10.1088/0965-0393/23/8/083501 - * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations - * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge - - - - Reference to or definition of a coordinate system with - which the definitions are interpretable. - - - - - - - - - - - A link or reference to the objects whose identifier are referred to in - identifier to resolve which row tuple is the orientation of each object - by reading orientations. - - - - - Integer which specifies which orientation (row of array orientation) matches - to which object.e first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish how a row in orientation describes a specific - object with an explicit identifier that can be queried via inspecting the - list of available objects in objects. - - The rational behind having such a more complicated pattern is that not - all objects referred when following the link in objects may still exists - or are still tracked when the orientation set was characterized. - - This design enables to also use NXorientation_set in situations where - the orientation of objects change as a function in time. - - - - - - - - Parameterized orientations. - - - - - - - diff --git a/contributed_definitions/nyaml/NXpeak.nxdl.xml b/contributed_definitions/nyaml/NXpeak.nxdl.xml deleted file mode 100644 index 4d549511cd..0000000000 --- a/contributed_definitions/nyaml/NXpeak.nxdl.xml +++ /dev/null @@ -1,66 +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/nyaml/NXpid.nxdl.xml b/contributed_definitions/nyaml/NXpid.nxdl.xml deleted file mode 100644 index f1c70fd066..0000000000 --- a/contributed_definitions/nyaml/NXpid.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - Contains the settings of a PID controller. - - - - Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. - - For example, a set of sensors could be averaged over before feeding it back into the loop. - - - - - The sensor representing the Process Value used in the feedback loop for the PID. - - In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. - - - - - The actual timeseries data fed back to the PID loop. - - - - - - - The Setpoint(s) used as an input for the PID controller. - - It can also be a link to an NXsensor.value field. - - - - - 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 contribution from the integral term is proportional to both - the magnitude of the error and the duration of the error. - The integral in a PID controller is the sum of the instantaneous - error over time and gives the accumulated offset that should have - been corrected previously. The accumulated error is then - multiplied by the integral gain (Ki) and added to the - controller output. - - - - - The derivative of the process error is calculated by determining - the slope of the error over time and multiplying this rate of - change by the derivative gain K_d. The magnitude of the - contribution of the derivative term to the overall control - action is termed the derivative gain, K_d - - - diff --git a/contributed_definitions/nyaml/NXprocess.yaml b/contributed_definitions/nyaml/NXprocess.yaml new file mode 100644 index 0000000000..2e3ab2fd39 --- /dev/null +++ b/contributed_definitions/nyaml/NXprocess.yaml @@ -0,0 +1,45 @@ +category: base +doc: | + Document an event of data processing, reconstruction, or analysis for this data. + +type: group +(NXobject)NXprocess: + program(NX_CHAR): + doc: | + Name of the program used + sequence_index(NX_POSINT): + doc: | + Sequence index of processing, for determining the order of multiple + **NXprocess** steps. Starts with 1. + version(NX_CHAR): + doc: | + Version of the program used + date(NX_DATE_TIME): + doc: | + Date and time of processing. + (NXregistration): + doc: | + Describes the operations of image registration + (NXdistortion): + doc: | + Describes the operations of image distortion correction + (NXcalibration): + doc: | + Describes the operations of calibration procedures, e.g. axis calibrations. + (NXnote): + doc: | + Notes contain information about how the data was processed or anything about the + data provenance. The contents of the note can be anything that the processing + code can understand, or simple text. The name will be numbered to allow for + ordering of steps. + \@default: + doc: | + .. 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/nyaml/NXpulser_apm.nxdl.xml b/contributed_definitions/nyaml/NXpulser_apm.nxdl.xml deleted file mode 100644 index 6c13e37a60..0000000000 --- a/contributed_definitions/nyaml/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - Direct current voltage between the specimen and the - (local electrode) in the case of local electrode atom - probe (LEAP) instrument. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - Average energy of the laser at peak of each pulse. - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - diff --git a/contributed_definitions/nyaml/NXpump.nxdl.xml b/contributed_definitions/nyaml/NXpump.nxdl.xml deleted file mode 100644 index 347fffca6d..0000000000 --- a/contributed_definitions/nyaml/NXpump.nxdl.xml +++ /dev/null @@ -1,19 +0,0 @@ - - - - - Device to reduce an atmosphere to a controlled remaining pressure level. - - - - - Principle type of the pump. - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXquadric.yaml b/contributed_definitions/nyaml/NXquadric.yaml new file mode 100644 index 0000000000..a981f3254c --- /dev/null +++ b/contributed_definitions/nyaml/NXquadric.yaml @@ -0,0 +1,27 @@ +category: base +doc: | + definition of a quadric surface. + +type: group +NXquadric(NXobject): + parameters(NX_NUMBER): + unit: NX_PER_LENGTH + doc: | + Ten real values of the matrix that defines the quadric surface + in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, + P2, P3, R. Takes a units attribute of dimension reciprocal + length. R is scalar. P has dimension reciprocal length, and the + given units. Q has dimension reciprocal length squared, and + units the square of those given. + dimensions: + dim: [[1, 10]] + surface_type: + exists: ['min', '0', 'max', '1'] + doc: | + An optional description of the form of the quadric surface':' + enumeration: [ELLIPSOID, ELLIPTIC_PARABOLOID, HYPERBOLIC_PARABOLOID, ELLIPTIC_HYPERBOLOID_OF_1_SHEET, ELLIPTIC_HYPERBOLOID_OF_2_SHEETS, ELLIPTIC_CONE, ELLIPTIC_CYLINDER, HYPERBOLIC_CYLINDER, PARABOLIC_CYLINDER, SPHEROID, SPHERE, PARABOLOID, HYPERBOLOID_1_SHEET, HYPERBOLOID_2_SHEET, CONE, CYLINDER, PLANE, IMAGINARY, UNKNOWN] + depends_on(NX_CHAR): + exists: ['min', '0', 'max', '1'] + doc: | + Path to an ':'ref':'`NXtransformations` that defining the axis on + which the orientation of the surface depends. diff --git a/contributed_definitions/nyaml/NXquadrupole_magnet.yaml b/contributed_definitions/nyaml/NXquadrupole_magnet.yaml new file mode 100644 index 0000000000..676efccfc9 --- /dev/null +++ b/contributed_definitions/nyaml/NXquadrupole_magnet.yaml @@ -0,0 +1,31 @@ +category: base +doc: | + definition for a quadrupole magnet. + +type: group +NXquadrupole_magnet(NXobject): + description(NX_CHAR): + doc: | + extended description of the magnet. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + set_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on supply. + read_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from supply. + value: + unit: NX_CURRENT + read_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from supply. + value: + unit: NX_VOLTAGE diff --git a/contributed_definitions/nyaml/NXreflectron.nxdl.xml b/contributed_definitions/nyaml/NXreflectron.nxdl.xml deleted file mode 100644 index 565f1e219d..0000000000 --- a/contributed_definitions/nyaml/NXreflectron.nxdl.xml +++ /dev/null @@ -1,31 +0,0 @@ - - - - - Device for reducing flight time differences of ions in ToF experiments. - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/nyaml/NXregion.yaml b/contributed_definitions/nyaml/NXregion.yaml new file mode 100644 index 0000000000..eda7ebba72 --- /dev/null +++ b/contributed_definitions/nyaml/NXregion.yaml @@ -0,0 +1,148 @@ +category: base +doc: | + Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, ':'ref':'`NXdetector`. + + This can be used to describe a subset of data used to create downsampled data or to derive + some data from that subset. + + Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters + (see https':'//portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** ':'math':'`= 1`, + then **stride** ':'math':'`\equiv` **step** in Python slicing. + + For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data':'':' + + detector':'NXdetector/ + data[60,256,512] + region':'NXregion/ + @region_type = "rectangular" + parent = "data" + start = [20,50] + count = [220,120] + statistics':'NXdata/ + @signal = "sum" + sum[60] + + the ``sum`` dataset contains the summed areas in each frame. + Another example, a hyperspectral image downsampled 16-fold in energy':'':' + + detector':'NXdetector/ + data[128,128,4096] + region':'NXregion/ + @region_type = "rectangular" + parent = "data" + start = [2] + count = [20] + stride = [32] + block = [16] + downsampled':'NXdata/ + @signal = "maximum" + @auxiliary_signals = "copy" + maximum[128,128,20] + copy[128,128,320] + + the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, + the ``maximum`` dataset will show maximum values in each 16-channel block + in every spectra. + +symbols: + doc: | + These symbols will denote how the shape of the parent group's data field, + + .. math':'':' (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) + + could be split into a left set of **O** outer dimensions, ':'math':'`\boldsymbol{D}`, + and a right set of **R** region dimensions, ':'math':'`\boldsymbol{d}`, + where the data field has rank **O** + **R**. Note **O** ':'math':'`>= 0`. + + O: | + Outer rank + + R: | + Region rank + +type: group +NXregion(NXobject): + \@region_type: + exists: optional + doc: | + This is ``rectangular`` to describe the region as a hyper-rectangle in + the index space of its parent group's data field. + enumeration: [rectangular] + parent: + doc: | + The name of data field in the parent group or the path of a data field relative + to the parent group (so it could be a field in a subgroup of the parent group) + parent_mask: + doc: | + The name of an optional mask field in the parent group with rank ':'math':'`\boldsymbol{R}` and + dimensions ':'math':'`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an + ':'ref':'`NXdetector`. + start(NX_NUMBER): + exists: recommended + doc: | + The starting position for region in detector data field array. + This is recommended as it also defines the region rank. + If omitted then defined as an array of zeros. + dimensions: + rank: 1 + dim: [[1, R]] + count(NX_INT): + exists: recommended + doc: | + The number of blocks or items in the hyperslab selection. + If omitted then defined as an array of dimensions that take into account + the other hyperslab selection fields to span the parent data field's shape. + dimensions: + rank: 1 + dim: [[1, R]] + stride(NX_INT): + doc: | + An optional field to define striding used to downsample data. + If omitted then defined as an array of ones. + dimensions: + rank: 1 + dim: [[1, R]] + block(NX_INT): + doc: | + An optional field to define the block size used to copy or downsample data. In the + ':'math':'`i`-th dimension, if ':'math':'`\mathbf{block}[i] < \mathbf{stride}[i]` + then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` + then the blocks are contiguous; otherwise the blocks overlap. + If omitted then defined as an array of ones. + dimensions: + rank: 1 + dim: [[1, R]] + scale(NX_NUMBER): + doc: | + An optional field to define a divisor for scaling of reduced data. For example, in a + downsampled sum, it can reduce the maximum values to fit in the domain of the result + data type. In an image that is downsampled by summing 2x2 blocks, using + ':'math':'`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as + the parent dataset. + If omitted then no scaling occurs. + dimensions: + rank: 1 + dim: [[1, R]] + downsampled(NXdata): + doc: | + An optional group containing data copied/downsampled from parent group’s data. Its dataset name + must reflect how the downsampling is done over each block. So it could be a reduction operation + such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each + block then use "copy" as the name. Where more than one downsample dataset is written + (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, + the field should have a shape of ':'math':'`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, + otherwise the expected shape is ':'math':'`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. + + The following figure shows how blocks are used in downsampling':' + + .. figure':'':' region/NXregion-example.png + ':'width':' 60% + + A selection with ':'math':'`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from + a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. + statistics(NXdata): + doc: | + An optional group containing any statistics derived from the region in parent group’s data + such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one + statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` + listing the others. All data fields should have shapes of ':'math':'`\boldsymbol{D}`. diff --git a/contributed_definitions/nyaml/NXregistration.nxdl.xml b/contributed_definitions/nyaml/NXregistration.nxdl.xml deleted file mode 100644 index ae4a48bbf5..0000000000 --- a/contributed_definitions/nyaml/NXregistration.nxdl.xml +++ /dev/null @@ -1,34 +0,0 @@ - - - - - Describes image registration procedures. - - - - Has the registration been applied? - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - To describe the operations of image registration (combinations of rigid - translations and rotations) - - - - - Description of the procedures employed. - - - diff --git a/contributed_definitions/nyaml/NXsample.yaml b/contributed_definitions/nyaml/NXsample.yaml new file mode 100644 index 0000000000..6a2cf4d1de --- /dev/null +++ b/contributed_definitions/nyaml/NXsample.yaml @@ -0,0 +1,412 @@ +category: base +doc: | + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + +symbols: + doc: | + symbolic array lengths to be coordinated between various fields + + n_comp: | + number of compositions + + n_Temp: | + number of temperatures + + n_eField: | + number of values in applied electric field + + n_mField: | + number of values in applied magnetic field + + n_pField: | + number of values in applied pressure field + + n_sField: | + number of values in applied stress field + +type: group +(NXobject)NXsample: + name(NX_CHAR): + doc: | + Descriptive name of sample + chemical_formula(NX_CHAR): + doc: | + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard':' + + * 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. + * This is the *Hill* system used by Chemical Abstracts. + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + Sample temperature. This could be a scanned variable + dimensions: + rank: anyRank + dim: [[1, n_Temp]] + electric_field(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Applied electric field + dimensions: + dim: [[1, n_eField]] + \@direction: + type: NX_CHAR + enumeration: [x, y, z] + magnetic_field(NX_FLOAT): + unit: NX_ANY + doc: | + Applied magnetic field + dimensions: + dim: [[1, n_mField]] + \@direction: + type: NX_CHAR + enumeration: [x, y, z] + stress_field(NX_FLOAT): + unit: NX_ANY + doc: | + Applied external stress field + dimensions: + dim: [[1, n_sField]] + \@direction: + type: NX_CHAR + enumeration: [x, y, z] + pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Applied pressure + dimensions: + dim: [[1, n_pField]] + changer_position(NX_INT): + unit: NX_UNITLESS + doc: | + Sample changer position + unit_cell_abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + unit_cell(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell parameters (lengths and angles) + dimensions: + rank: 2 + dim: [[1, n_comp], [2, 6]] + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention':' + + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention':' + + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + ub_matrix(NX_FLOAT): + doc: | + 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. + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + type(NX_CHAR): + enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] + situation(NX_CHAR): + doc: | + The atmosphere will be one of the components, which is where its details will be + stored; the relevant components will be indicated by the entry in the + sample_component member. + enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] + description(NX_CHAR): + doc: | + Description of the sample + preparation_date(NX_DATE_TIME): + doc: | + Date of preparation of the sample + geometry(NXgeometry): + doc: | + The position and orientation of the center of mass of the sample + (NXbeam): + doc: | + Details of beam incident on sample - used to calculate sample/beam interaction + point + (NXsample_component): + doc: | + One group per sample component This is the perferred way of recording per + component information over the n_comp arrays + component(NX_CHAR): + doc: | + Details of the component of the sample and/or can + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_component(NX_CHAR): + doc: | + Type of component + dimensions: + rank: 1 + dim: [[1, n_comp]] + enumeration: [sample, can, atmosphere, kit] + concentration(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Concentration of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + volume_fraction(NX_FLOAT): + doc: | + Volume fraction of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + scattering_length_density(NX_FLOAT): + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + unit_cell_class(NX_CHAR): + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group(NX_CHAR): + doc: | + Crystallographic space group + dimensions: + dim: [[1, n_comp]] + point_group(NX_CHAR): + doc: | + Crystallographic point group, deprecated if space_group present + dimensions: + dim: [[1, n_comp]] + path_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Path length through sample/can for simple case when it does not vary with + scattering direction + path_length_window(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of a beam entry/exit window on the can (mm). It is assumed to be the + same for entry and exit + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + sample thickness + sample_id(NX_CHAR): + doc: | + Identification number or signatures of the sample used. + sample_history(NXnote): + doc: | + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (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 + state(NX_CHAR): + doc: | + Physical state of the sample + purity(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Chemical purity of the sample + orientation(NX_CHAR): + doc: | + Surface termination of the sample (if crystalline) + layer(NX_CHAR): + doc: | + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + chemical_name(NX_CHAR): + doc: | + Full chemical name of the sample + chem_id_cas(NX_CHAR): + doc: | + CAS registry number of the sample chemical content. + gas(NX_CHAR): + doc: | + Gases might be fluxed on the surface for various reasons. Chemical designation, + or residual. + gas_pressure(NX_NUMBER): + unit: NX_PRESSURE + doc: | + In the case of a fixed pressure measurement this is the scalar pressure. In the + case of an experiment in which pressure changes, or anyway is recorded, this is + an array of length m of pressures. + surface_dopant(NX_CHAR): + doc: | + Element of evaporated surface dopant such as alkali or other + surface_dopant_coverage(NX_FLOAT): + unit: NX_LENGTH + doc: | + Nominal thickness of the evaporated dopant + bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to sample and sample holder. + growth_method(NX_CHAR): + doc: | + Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition + etc.) + vendor(NX_CHAR): + doc: | + Name of the sample vendor (company or research group) + substrate_material(NX_CHAR): + doc: | + Material of the substrate in direct contact with the sample. + substrate_state(NX_CHAR): + doc: | + Physical state of the substrate, similar options to sample_state + drain_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Current to neutralize the photoemission current. This field may also be found in + NXmanpulator if present. + bias_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Possible bias of the sample with respect to analyser ground. This field may also + be found as sample_bias in NXmanipulator if present. + notes(NXnote): + doc: | + Further notes. + transmission(NXdata): + doc: | + As a function of Wavelength + temperature(NXlog): + doc: | + temperature.value is a link to e.g. temperature_env.sensor1.value + temperature_log(NXlog): + doc: | + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + temperature_env(NXenvironment): + doc: | + Additional sample temperature environment information + magnetic_field(NXlog): + doc: | + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + magnetic_field_log(NXlog): + doc: | + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value + magnetic_field_env(NXenvironment): + doc: | + Additional sample magnetic environment information + external_DAC(NX_FLOAT): + unit: NX_ANY + doc: | + value sent to user's sample setup + external_ADC(NXlog): + doc: | + logged value (or logic state) read from user's setup + short_title(NX_CHAR): + doc: | + 20 character fixed length sample description for legends + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder diagram has been obtained + through an omega-2theta scan like from a traditional single detector powder + diffractometer + x_translation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the X-direction of the laboratory coordinate + system + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the Z-direction of the laboratory coordinate + system + (NXpositioner): + doc: | + Any positioner (motor, PZT, ...) used to locate the sample + depends_on(NX_CHAR): + doc: | + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + (NXtransformations): + doc: | + 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. + \@default: + doc: | + .. 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/nyaml/NXscanbox_em.nxdl.xml b/contributed_definitions/nyaml/NXscanbox_em.nxdl.xml deleted file mode 100644 index 8cb0b1d604..0000000000 --- a/contributed_definitions/nyaml/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,20 +0,0 @@ - - - - - Scan box and coils which deflect an electron beam in a controlled manner. - - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml b/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml deleted file mode 100644 index 07b48907ef..0000000000 --- a/contributed_definitions/nyaml/NXsensor_scan.nxdl.xml +++ /dev/null @@ -1,176 +0,0 @@ - - - - - - Variables used to set a common size for collected sensor data. - - - - The number of scan points measured in this scan. - - - - - Application definition for a generic scan using sensors. - - In this application definition, times should be specified always together - with an UTC offset. - - - - - - - - - - - - - - - Define the program that was used to generate the results file(s) - with measured data and metadata. - - - - Commercial or otherwise defined given name of the program - (or a link to the instrument software). - - - - Either version with build number, commit hash, or description of an - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - Website of the software. - - - - - - - Contact information of at least the user of the instrument or the - investigator who performed this experiment. Adding multiple users if - relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when - the experiment was performed. - - - - - Full address (street, street number, ZIP, city, country) - of the user's affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - Official telephone number of the user. - - - - - - - Describes an environment setup for the experiment. - - All the setting values of the independently scanned controllers are listed under corresponding - NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each - measurement sensor. - - For example, in a temperature-dependent IV measurement, the temperature and voltage must be - present as independently scanned controllers and the current sensor must also be present with - its readings. - - - - - Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. - - - - - For each point in the scan space, either the nominal setpoint of an independently scanned controller - or a representative average value of a measurement sensor is registered. - - The length of each sensor's data value array stored in this group should be equal to the number of scan points - probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. - This allows the scan to be made in any order as the user describes above in the experiment. We get matching - values simply using the index of the scan point. - - - - - - - - Timestamp for when the values provided in the value field were registered. - - Individual readings can be stored with their timestamps under value_log. This is to timestamp - the nominal setpoint or average reading values listed above in the value field. - - - - - - Free-text describing the data acquisition control: an internal - sweep using the built-in functionality of the controller device, - or a set/wait/read/repeat mechanism. - - - - - - ISO8601 datum when calibration was last performed - before this measurement. UTC offset should be specified. - - - - - - - A list of names of NXsensor groups used as independently scanned controllers. - - - - - A list of names of NXsensor groups used as measurement sensors. - - - - - - - - - - A scan specific representation of the measured signals as a function of the independently controlled environment settings. - Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. - - - - diff --git a/contributed_definitions/nyaml/NXseparator.yaml b/contributed_definitions/nyaml/NXseparator.yaml new file mode 100644 index 0000000000..16bee40620 --- /dev/null +++ b/contributed_definitions/nyaml/NXseparator.yaml @@ -0,0 +1,48 @@ +category: base +doc: | + definition for an electrostatic separator. + +type: group +NXseparator(NXobject): + description(NX_CHAR): + doc: | + extended description of the separator. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + set_Bfield_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on magnet supply. + read_Bfield_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from magnet supply. + value: + unit: NX_CURRENT + read_Bfield_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from magnet supply. + value: + unit: NX_VOLTAGE + set_Efield_voltage(NX_FLOAT): + unit: NX_VOLTAGE + exists: ['min', '0', 'max', '1'] + doc: | + current set on HT supply. + read_Efield_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from HT supply. + value: + unit: NX_CURRENT + read_Efield_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from HT supply. + value: + unit: NX_VOLTAGE diff --git a/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml b/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml deleted file mode 100644 index ff4dc83920..0000000000 --- a/contributed_definitions/nyaml/NXslip_system_set.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of slip systems. - - - - - Base class for describing a set of crystallographic slip systems. - - - - - - - - - - - - - - - Array of Miller indices which describe the crystallographic plane. - - - - - - - - - Array of Miller indices which describe the crystallographic direction. - - - - - - - - - For each slip system a marker whether the specified Miller indices - refer to the specific slip system or the set of crystallographic equivalent - slip systems of the respective family of slip systems. - - - - - - diff --git a/contributed_definitions/nyaml/NXsnsevent.yaml b/contributed_definitions/nyaml/NXsnsevent.yaml new file mode 100644 index 0000000000..5f4d9f8531 --- /dev/null +++ b/contributed_definitions/nyaml/NXsnsevent.yaml @@ -0,0 +1,294 @@ +category: application +doc: | + This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. + +type: group +NXsnsevent(NXobject): + (NXentry): + exists: ['min', '1'] + (NXcollection)DASlogs: + doc: | + Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). + (NXlog): + exists: ['min', '1'] + average_value(NX_FLOAT): + average_value_error(NX_FLOAT): + exists: optional + deprecated: see https':'//github.com/nexusformat/definitions/issues/821 + average_value_errors(NX_FLOAT): + description: + duration(NX_FLOAT): + maximum_value(NX_FLOAT): + minimum_value(NX_FLOAT): + time(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nvalue]] + value(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nvalue]] + (NXpositioner): + exists: ['min', '0'] + doc: | + Motor logs from cvinfo file. + average_value(NX_FLOAT): + average_value_error(NX_FLOAT): + exists: optional + deprecated: see https':'//github.com/nexusformat/definitions/issues/821 + average_value_errors(NX_FLOAT): + description: + duration(NX_FLOAT): + maximum_value(NX_FLOAT): + minimum_value(NX_FLOAT): + time(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, numvalue]] + value(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, numvalue]] + (NXnote)SNSHistoTool: + SNSbanking_file_name: + SNSmapping_file_name: + author: + command1: + doc: | + Command string for event2nxl. + date: + description: + version: + (NXdata): + exists: ['min', '1'] + data_x_y(link): + target: /NXentry/NXinstrument/NXdetector/data_x_y + x_pixel_offset(link): + target: /NXentry/NXinstrument/NXdetector/x_pixel_offset + y_pixel_offset(link): + target: /NXentry/NXinstrument/NXdetector/y_pixel_offset + (NXevent_data): + exists: ['min', '1'] + event_index(link): + target: /NXentry/NXinstrument/NXdetector/event_index + event_pixel_id(link): + target: /NXentry/NXinstrument/NXdetector/event_pixel_id + event_time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/event_time_of_flight + pulse_time(link): + target: /NXentry/NXinstrument/NXdetector/pulse_time + collection_identifier: + collection_title: + definition: + doc: | + Official NXDL schema after this file goes to applications. + enumeration: [NXsnsevent] + duration(NX_FLOAT): + unit: NX_TIME + end_time(NX_DATE_TIME): + entry_identifier: + experiment_identifier: + (NXinstrument)instrument: + (NXsource)SNS: + frequency(NX_FLOAT): + unit: NX_FREQUENCY + name: + probe: + type: + SNSdetector_calibration_id: + doc: | + Detector calibration id from DAS. + SNSgeometry_file_name: + SNStranslation_service: + (NXdetector): + exists: ['min', '1'] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + data_x_y(NX_UINT): + doc: | + expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + event_index(NX_UINT): + dimensions: + rank: 1 + dim: [[1, numpulses]] + event_pixel_id(NX_UINT): + dimensions: + rank: 1 + dim: [[1, numevents]] + event_time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, numevents]] + (NXgeometry)origin: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + pixel_id(NX_UINT): + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + pulse_time(NX_FLOAT): + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, numpulses]] + total_counts(NX_UINT): + x_pixel_offset(NX_FLOAT): + axis: 1 + primary: 1 + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, numx]] + y_pixel_offset(NX_FLOAT): + axis: 2 + primary: 1 + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, numy]] + beamline: + (NXdisk_chopper): + exists: ['min', '0'] + distance(NX_FLOAT): + unit: NX_LENGTH + (NXmoderator)moderator: + coupling_material: + distance(NX_FLOAT): + unit: NX_LENGTH + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + type: + name: + (NXaperture): + exists: ['min', '0'] + (NXgeometry)origin: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + (NXattenuator): + exists: ['min', '0'] + distance(NX_FLOAT): + unit: NX_LENGTH + (NXpolarizer): + exists: ['min', '0'] + (NXcrystal): + exists: ['min', '0'] + (NXgeometry)origin: + description: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + type: + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + (NXmonitor): + exists: ['min', '0'] + data(NX_UINT): + doc: | + expect ``signal=1 axes="time_of_flight"`` + dimensions: + rank: 1 + dim: [[1, numtimechannels]] + distance(NX_FLOAT): + unit: NX_LENGTH + mode: + time_of_flight(NX_FLOAT): + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, numtimechannels + 1]] + notes: + proton_charge(NX_FLOAT): + unit: NX_CHARGE + raw_frames(NX_INT): + run_number: + (NXsample)sample: + changer_position: + holder: + identifier: + name: + doc: | + Descriptive name of sample + nature: + start_time(NX_DATE_TIME): + title: + total_counts(NX_UINT): + unit: NX_UNITLESS + total_uncounted_counts(NX_UINT): + unit: NX_UNITLESS + (NXuser): + exists: ['min', '1'] + facility_user_id: + name: + role: diff --git a/contributed_definitions/nyaml/NXsnshisto.yaml b/contributed_definitions/nyaml/NXsnshisto.yaml new file mode 100644 index 0000000000..41396a75b7 --- /dev/null +++ b/contributed_definitions/nyaml/NXsnshisto.yaml @@ -0,0 +1,315 @@ +category: application +doc: | + This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. + +type: group +NXsnshisto(NXobject): + (NXentry): + exists: ['min', '1'] + (NXcollection)DASlogs: + doc: | + Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). + (NXlog): + exists: ['min', '1'] + average_value(NX_FLOAT): + average_value_error(NX_FLOAT): + exists: optional + deprecated: see https':'//github.com/nexusformat/definitions/issues/821 + average_value_errors(NX_FLOAT): + description: + duration(NX_FLOAT): + maximum_value(NX_FLOAT): + minimum_value(NX_FLOAT): + time(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nvalue]] + value(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nvalue]] + (NXpositioner): + exists: ['min', '0'] + doc: | + Motor logs from cvinfo file. + average_value(NX_FLOAT): + average_value_error(NX_FLOAT): + exists: optional + deprecated: see https':'//github.com/nexusformat/definitions/issues/821 + average_value_errors(NX_FLOAT): + description: + duration(NX_FLOAT): + maximum_value(NX_FLOAT): + minimum_value(NX_FLOAT): + time(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, numvalue]] + value(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, numvalue]] + (NXnote)SNSHistoTool: + SNSbanking_file_name: + SNSmapping_file_name: + author: + command1: + doc: | + Command string for event2histo_nxl. + date: + description: + version: + (NXdata): + exists: ['min', '1'] + data(link): + target: /NXentry/NXinstrument/NXdetector/data + data_x_time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/data_x_time_of_flight + data_x_y(link): + target: /NXentry/NXinstrument/NXdetector/data_x_y + data_y_time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/data_y_time_of_flight + pixel_id(link): + target: /NXentry/NXinstrument/NXdetector/pixel_id + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight + total_counts(link): + target: /NXentry/NXinstrument/NXdetector/total_counts + x_pixel_offset(link): + target: /NXentry/NXinstrument/NXdetector/x_pixel_offset + y_pixel_offset(link): + target: /NXentry/NXinstrument/NXdetector/y_pixel_offset + collection_identifier: + collection_title: + definition: + doc: | + Official NXDL schema after this file goes to applications. + enumeration: [NXsnshisto] + duration(NX_FLOAT): + unit: NX_TIME + end_time(NX_DATE_TIME): + entry_identifier: + experiment_identifier: + (NXinstrument)instrument: + (NXsource)SNS: + frequency(NX_FLOAT): + unit: NX_FREQUENCY + name: + probe: + type: + SNSdetector_calibration_id: + doc: | + Detector calibration id from DAS. + SNSgeometry_file_name: + SNStranslation_service: + (NXdetector): + exists: ['min', '1'] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + data(NX_UINT): + signal: 1 + axes: x_pixel_offset,y_pixel_offset,time_of_flight + dimensions: + rank: 3 + dim: [[1, numx], [2, numy], [3, numtof]] + data_x_time_of_flight(NX_UINT): + signal: 3 + axes: x_pixel_offset,time_of_flight + dimensions: + rank: 2 + dim: [[1, numx], [2, numtof]] + data_x_y(NX_UINT): + signal: 2 + axes: x_pixel_offset,y_pixel_offset + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + data_y_time_of_flight(NX_UINT): + signal: 4 + axes: y_pixel_offset,time_of_flight + dimensions: + rank: 2 + dim: [[1, numy], [2, numtof]] + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + (NXgeometry)origin: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + pixel_id(NX_UINT): + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + time_of_flight(NX_FLOAT): + axis: 3 + primary: 1 + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, numtof + 1]] + total_counts(NX_UINT): + x_pixel_offset(NX_FLOAT): + axis: 1 + primary: 1 + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, numx]] + y_pixel_offset(NX_FLOAT): + axis: 2 + primary: 1 + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, numy]] + beamline: + (NXdisk_chopper): + exists: ['min', '0'] + doc: | + Original specification called for NXchopper, + which is not a valid NeXus base class. + Select either NXdisk_chopper or NXfermi_chopper, as appropriate. + distance(NX_FLOAT): + unit: NX_LENGTH + (NXfermi_chopper): + exists: ['min', '0'] + doc: | + Original specification called for NXchopper, + which is not a valid NeXus base class. + Select either NXdisk_chopper or NXfermi_chopper, as appropriate. + distance(NX_FLOAT): + unit: NX_LENGTH + (NXmoderator)moderator: + coupling_material: + distance(NX_FLOAT): + unit: NX_LENGTH + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + type: + name: + (NXaperture): + exists: ['min', '0'] + (NXgeometry)origin: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + (NXattenuator): + exists: ['min', '0'] + distance(NX_FLOAT): + unit: NX_LENGTH + (NXpolarizer): + exists: ['min', '0'] + (NXcrystal): + exists: ['min', '0'] + (NXgeometry)origin: + description: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + type: + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + (NXmonitor): + exists: ['min', '0'] + data(NX_UINT): + signal: 1 + axes: time_of_flight + dimensions: + rank: 1 + dim: [[1, numtimechannels]] + distance(NX_FLOAT): + unit: NX_LENGTH + mode: + time_of_flight(NX_FLOAT): + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, numtimechannels + 1]] + notes: + proton_charge(NX_FLOAT): + unit: NX_CHARGE + raw_frames(NX_INT): + run_number: + (NXsample)sample: + changer_position: + holder: + identifier: + name: + doc: | + Descriptive name of sample + nature: + start_time(NX_DATE_TIME): + title: + total_counts(NX_UINT): + unit: NX_UNITLESS + total_uncounted_counts(NX_UINT): + unit: NX_UNITLESS + (NXuser): + exists: ['min', '1'] + facility_user_id: + name: + role: diff --git a/contributed_definitions/nyaml/NXsolenoid_magnet.yaml b/contributed_definitions/nyaml/NXsolenoid_magnet.yaml new file mode 100644 index 0000000000..33404b2ade --- /dev/null +++ b/contributed_definitions/nyaml/NXsolenoid_magnet.yaml @@ -0,0 +1,31 @@ +category: base +doc: | + definition for a solenoid magnet. + +type: group +NXsolenoid_magnet(NXobject): + description(NX_CHAR): + doc: | + extended description of the magnet. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + set_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on supply. + read_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from supply. + value: + unit: NX_CURRENT + read_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from supply. + value: + unit: NX_VOLTAGE diff --git a/contributed_definitions/nyaml/NXsolid_geometry.yaml b/contributed_definitions/nyaml/NXsolid_geometry.yaml new file mode 100644 index 0000000000..752ebdee2d --- /dev/null +++ b/contributed_definitions/nyaml/NXsolid_geometry.yaml @@ -0,0 +1,18 @@ +category: base +doc: | + the head node for constructively defined geometry + +type: group +NXsolid_geometry(NXobject): + (NXquadric): + exists: ['min', '0'] + doc: | + Instances of ':'ref':'`NXquadric` making up elements of the geometry. + (NXoff_geometry): + exists: ['min', '0'] + doc: | + Instances of ':'ref':'`NXoff_geometry` making up elements of the geometry. + (NXcsg): + exists: ['min', '0'] + doc: | + The geometries defined, made up of instances of ':'ref':'`NXquadric` and ':'ref':'`NXoff_geometry`. diff --git a/contributed_definitions/nyaml/NXsource.yaml b/contributed_definitions/nyaml/NXsource.yaml new file mode 100644 index 0000000000..e1e1cd74bb --- /dev/null +++ b/contributed_definitions/nyaml/NXsource.yaml @@ -0,0 +1,172 @@ +category: base +doc: | + The neutron or x-ray storage ring/facility. + +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + + nx: | + Number of points in a spectrum + +type: group +(NXobject)NXsource: + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Effective distance from sample Distance as seen by radiation from sample. This + number should be negative to signify that it is upstream of the sample. + name(NX_CHAR): + doc: | + Name of source + \@short_name: + type: NX_CHAR + doc: | + short name for source, perhaps the acronym + type(NX_CHAR): + doc: | + Type of radiation source (pick one from the enumerated list and spell exactly) + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray, arc lamp, halogen lamp, LED] + probe(NX_CHAR): + doc: | + Type of radiation probe (pick one from the enumerated list and spell exactly) + enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + power(NX_FLOAT): + unit: NX_POWER + doc: | + Source power + emittance_x(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in X (horizontal) direction. + emittance_y(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in Y (horizontal) direction. + sigma_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + Particle beam size in x + sigma_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + Particle beam size in y + flux(NX_FLOAT): + unit: NX_FLUX + doc: | + Source intensity/area (example':' s-1 cm-2) + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Source energy. For storage rings, this would be the particle beam energy. For + X-ray tubes, this would be the excitation voltage. + current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Accelerator, X-ray tube, or storage ring current + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Accelerator voltage + frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency of pulsed source + period(NX_FLOAT): + unit: NX_PERIOD + doc: | + Period of pulsed source + target_material(NX_CHAR): + doc: | + Pulsed source target material or other material used to generate light, e.g. He, + Ar gas for lasers, Xe or Hg/Cd vapor for arc lamps, etc. + enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C, Ar, He, Xe, Hg/Cd, H] + notes(NXnote): + doc: | + Any source/facility related messages/events that occurred during the experiment + bunch_pattern(NXdata): + doc: | + For storage rings, description of the bunch pattern. This is useful to describe + irregular bunch patterns. + title(NX_CHAR): + doc: | + name of the bunch pattern + number_of_bunches(NX_INT): + doc: | + For storage rings, the number of bunches in use. + bunch_length(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, temporal length of the bunch + bunch_distance(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, time between bunches + pulse_width(NX_FLOAT): + unit: NX_TIME + doc: | + Temporal width of source pulse + pulse_shape(NXdata): + doc: | + Source pulse shape + mode(NX_CHAR): + doc: | + Source operating mode + enumeration: + Single Bunch: + doc: | + For storage rings + Multi Bunch: + doc: | + For storage rings + top_up(NX_BOOLEAN): + doc: | + Is the synchrotron operating in top_up mode? + last_fill(NX_NUMBER): + unit: NX_CURRENT + doc: | + For storage rings, the current at the end of the most recent injection. + \@time: + type: NX_CHAR + doc: | + Date and time of the most recent injection. + photon_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + The center photon energy of the source, before it is monochromatized or + converted + center_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The center wavelength of the source, before it is monochromatized or converted + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + For pulsed sources, the energy of a single pulse + peak_power(NX_FLOAT): + unit: NX_POWER + doc: | + For pulsed sources, the pulse energy divided by the pulse duration + bunch_number_start(NX_INT): + doc: | + Some facilities tag each bunch. First bunch of the measurement + bunch_number_end(NX_INT): + doc: | + Last bunch of the measurement + geometry(NXgeometry): + doc: | + 'Engineering' location of source + distribution(NXdata): + doc: | + The wavelength or energy distribution of the source + \@default: + doc: | + .. 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/nyaml/NXspatial_filter.nxdl.xml b/contributed_definitions/nyaml/NXspatial_filter.nxdl.xml deleted file mode 100644 index c000065ed6..0000000000 --- a/contributed_definitions/nyaml/NXspatial_filter.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of ellipsoids. - - - - - Number of hexahedra. - - - - - Number of cylinders. - - - - - Spatial filter to filter entries within a region-of-interest based on their position. - - - - Qualitative statement which specifies which spatial filtering with respective - geometric primitives or bitmask is used. These settings are possible: - - * entire_dataset, no filter is applied, the entire dataset is used. - * union_of_primitives, a filter with (rotated) geometric primitives. - All ions in or on the surface of the primitives are considered - while all other ions are ignored. - * bitmasked_points, a boolean array whose bits encode with 1 - which ions should be included. Those ions whose bit is set to 0 - will be excluded. Users of python can use the bitfield operations - of the numpy package to define such bitfields. - - Conditions: - In the case that windowing_method is entire_dataset all entries are processed. - In the case that windowing_method is union_of_primitives, - it is possible to specify none or all types of primitives - (ellipsoids, cylinder, hexahedra). If no primitives are specified - the filter falls back to entire_dataset. - In the case that windowing_method is bitmask, the bitmask has to be defined; - otherwise the filter falls back to entire dataset. - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml new file mode 100644 index 0000000000..36011b808b --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml @@ -0,0 +1,8 @@ +category: base +doc: | + Container for reporting a set of auger electron energy spectra. + +type: group +(NXobject)NXspectrum_set_em_auger: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml new file mode 100644 index 0000000000..cf1a0ddf76 --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml @@ -0,0 +1,8 @@ +category: base +doc: | + Container for reporting a set of cathodoluminescence spectra. + +type: group +(NXobject)NXspectrum_set_em_cathodolum: + (NXdata): + (NXprocess): diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml deleted file mode 100644 index 4c3f7d3784..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set_em_eels.nxdl.xml +++ /dev/null @@ -1,158 +0,0 @@ - - - - - - - Number of pixel per EELS mapping in the slow direction. - - - - - Number of pixel per EELS mapping in the fast direction. - - - - - Number of electron energy loss bins. - - - - - Container for reporting a set of electron energy loss (EELS) spectra. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - - The latter pattern is the most frequently used. - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - - - Details how EELS spectra were processed from the detector readings. - - - - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXspectrum_set_em_eels were loaded during - parsing to represent them in e.g. databases. - - - - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - - - - - - Commercial or otherwise given name to the program which was used - to process detector data into the EELS spectra stack and summary. - - - - Program 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. - - - - - - - Collected EELS spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - Counts for one spectrum per each pixel. - - - - - - - - - EELS counts - - - - - - Pixel center of mass position y-coordinates. - - - - - - - Coordinate along y direction. - - - - - - Pixel center of mass position x-coordinates. - - - - - - - Coordinate along x direction. - - - - - - Pixel center of mass energy loss bins. - - - - - - - Coordinate along energy loss axis. - - - - - - - Accumulated EELS spectrum over all pixels of a rectangular - region-of-interest. This representation supports rectangular scan pattern. - - - - Counts for specific energy losses. - - - - - - - Counts electrons with an energy loss within binned range. - - - - - - Pixel center of mass energy loss bins. - - - - - - - Coordinate along energy loss axis. - - - - - diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml deleted file mode 100644 index 08a3c9d458..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set_em_xray.nxdl.xml +++ /dev/null @@ -1,271 +0,0 @@ - - - - - - - Number of pixel per X-ray mapping in the slow direction - - - - - Number of pixel per X-ray mapping in the fast direction - - - - - Number of X-ray photon energy (bins) - - - - - Number of identified elements - - - - - Number of peaks - - - - - Container for reporting a set of energy-dispersive X-ray spectra. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ - should be used. - - - - Details how X-ray spectra were processed from the detector readings. - - - - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXspectrum_set_em_xray were loaded during - parsing to represent them in e.g. databases. - - - - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - - - - - - Commercial or otherwise given name to the program which was used - to process detector data into the X-ray spectra stack and summary. - - - - Program 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. - - - - - - - Collected X-ray spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - X-ray photon counts - - - - - - - - - - Coordinate along y direction. - - - - - - - - - - Coordinate along x direction. - - - - - - - - - - Photon energy. - - - - - - - Accumulated X-ray spectrum over all pixels of a rectangular - region-of-interest. This representation supports rectangular scan pattern. - - - - - - - - X-ray photon counts - - - - - - - - - - Photon energy - - - - - - - Details about computational steps how peaks were indexed as elements. - - - - Given name of the program that was used to perform this computation. - - - - Program 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. - - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are group with the same peak. - - - - - - - List of the names of identified elements. - - - - - - - - Individual element-specific EDX/EDS/EDXS/SXES mapping - - A composition map is an image whose intensities for each pixel are the - accumulated X-ray quanta *under the curve(s)* of a set of peaks. - - - - Given name of the program that was used to perform this computation. - - - - Program 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. - - - - - - A list of strings of named instances of NXpeak from indexing - whose X-ray quanta where accumulated for each pixel. - - - - - - - - Human-readable, given name to the image. - - - - - Individual element-specific maps. Individual maps should - each be a group and be named according to element_names. - - - - - - - - - Accumulated photon counts for observed element. - - - - - - - - - - Coordinate along y direction. - - - - - - - - - - Coordinate along x direction. - - - - - - - diff --git a/contributed_definitions/nyaml/NXspin_rotator.yaml b/contributed_definitions/nyaml/NXspin_rotator.yaml new file mode 100644 index 0000000000..d803f925ba --- /dev/null +++ b/contributed_definitions/nyaml/NXspin_rotator.yaml @@ -0,0 +1,48 @@ +category: base +doc: | + definition for a spin rotator. + +type: group +NXspin_rotator(NXobject): + description(NX_CHAR): + doc: | + extended description of the spin rotator. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + set_Bfield_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on magnet supply. + read_Bfield_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from magnet supply. + value: + unit: NX_CURRENT + read_Bfield_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from magnet supply. + value: + unit: NX_VOLTAGE + set_Efield_voltage(NX_FLOAT): + unit: NX_VOLTAGE + exists: ['min', '0', 'max', '1'] + doc: | + current set on HT supply. + read_Efield_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from HT supply. + value: + unit: NX_CURRENT + read_Efield_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from HT supply. + value: + unit: NX_VOLTAGE diff --git a/contributed_definitions/nyaml/NXspindispersion.nxdl.xml b/contributed_definitions/nyaml/NXspindispersion.nxdl.xml deleted file mode 100644 index 0b281dbfc9..0000000000 --- a/contributed_definitions/nyaml/NXspindispersion.nxdl.xml +++ /dev/null @@ -1,76 +0,0 @@ - - - - - Subclass of NXelectronanalyser to describe the spin filters in photoemission - experiments. - - - - Type of spin detector, VLEED, SPLEED, Mott, etc. - - - - - Figure of merit of the spin detector - - - - - Effective Shermann function, calibrated spin selectivity factor - - - - - Energy of the spin-selective scattering - - - - - Angle of the spin-selective scattering - - - - - Name of the target - - - - - Preparation procedure of the spin target - - - - - Date of last preparation of the spin target - - - - - 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 deflector 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. - - - - - Deflectors in the spin dispersive section - - - - - Individual lenses in the spin dispersive section - - - diff --git a/contributed_definitions/nyaml/NXstage_lab.nxdl.xml b/contributed_definitions/nyaml/NXstage_lab.nxdl.xml deleted file mode 100644 index 0c076ac970..0000000000 --- a/contributed_definitions/nyaml/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,137 +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. - - - - diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml b/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml deleted file mode 100644 index ccf2f2a63b..0000000000 --- a/contributed_definitions/nyaml/NXsubsampling_filter.nxdl.xml +++ /dev/null @@ -1,26 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Settings of a filter to sample entries based on their value. - - - - Triplet of the minimum, increment, and maximum value which will - be included in the analysis. The increment controls which n-th entry to take. - - Take as an example a dataset with 100 entries (their indices start at zero) - and the filter set to 0, 1, 99. This will process each entry. - 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third - entry beginning from entry 90 up to 99. - - - - - - diff --git a/contributed_definitions/nyaml/NXtransmission.nxdl.xml b/contributed_definitions/nyaml/NXtransmission.nxdl.xml deleted file mode 100644 index f19f5f11dd..0000000000 --- a/contributed_definitions/nyaml/NXtransmission.nxdl.xml +++ /dev/null @@ -1,327 +0,0 @@ - - - - - - Variables used throughout the experiment - - - - Number of wavelength points - - - - - Number of scans - - - - - Application definition for transmission experiments - - - - This application definition - - - - An application definition for transmission. - - - - Version number to identify which definition of this application definition was - used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant to the - application definition. - - - - - - - - - Start time of the experiment. - - - - - Unique identifier of the experiment, such as a (globally persistent) - unique identifier. - - * The identifier is usually defined by the facility or principle - investigator. - * The identifier enables to link experiments to e.g. proposals. - - - - - An optional free-text description of the experiment. However, details of the - experiment should be defined in the specific fields of this application - definition rather than in this experiment description. - - - - - - Commercial or otherwise defined given name to the program that was - used to generate the result file(s) with measured data and metadata. - - - - - Version number of the program that was used to generate the result - file(s) with measured data and metadata. - - - - - Website of the software - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Street address of the user's affiliation. - - - - - Email address of the user. - - - - - Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). - - - - - Telephone number of the user. - - - - - - - Manufacturer of the instrument. - - - - - Common beam mask to shape the incident beam - - - - The height of the common beam in percentage of the beam - - - - - - If true, the incident beam is depolarized. - - - - - Polarizer value inside the beam path - - - - - Attenuator in the reference beam - - - - - - Attenuator in the sample beam - - - - - - - Wavelength value(s) used for the measurement. - An array of 1 or more elements. Length defines N_wavelenghts - - - - - - - - Overall spectral resolution of this spectrometer. - If several gratings are employed the spectral resoultion - should rather be specified for each grating inside the - NXgrating group of this spectrometer. - - - - - Diffraction grating, as could be used in a monochromator. - If two or more gratings were used, define the angular - dispersion and the wavelength range (min/max wavelength) - for each grating and make sure that the wavelength ranges - do not overlap. The dispersion should be defined for the - entire wavelength range of the experiment. - - - - Dispersion of the grating in nm/mm used. - - - - - The blaze wavelength of the grating used. - - - - - Overall spectral resolution of the instrument - when this grating is used. - - - - - Wavelength range in which this grating was used - - - - - - - - - - - Wavelength range in which this detector was used - - - - - - - - Detector type - - - - - - - - - - Response time of the detector - - - - - Detector gain - - - - - Slit setting used for measurement with this detector - - - - - - - - - - - - An array of relative scan start time points. - - - - - - - - Resulting data from the measurement. - The length of the 2nd dimension is - the number of time points. - If it has length one the time_points - may be empty. - - - - - - - - - The lamp used for illumination - - - - The type of lamp, e.g. halogen, D2 etc. - - - - - - - - - The spectrum of the lamp used - - - - - - - - Wavelength range in which the lamp was used - - - - - - - - - - Properties of the sample measured - - - - - - A default view of the data emitted intensity vs. wavelength. - From measured_data plot intensity and wavelength. - - - - We recommend to use wavelength as a default attribute, but it can be - replaced by any suitable parameter along the X-axis. - - - - - diff --git a/contributed_definitions/nyaml/NXxpcs.yaml b/contributed_definitions/nyaml/NXxpcs.yaml new file mode 100644 index 0000000000..0fff97948a --- /dev/null +++ b/contributed_definitions/nyaml/NXxpcs.yaml @@ -0,0 +1,465 @@ +category: application +doc: | + X-ray Photon Correlation Spectroscopy (XPCS) data (results). + + The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data + in order to support development of community software tools. The definition presented here only + represents a starting point and contains fields that a common software tool should support for + community acceptance. + + Additional fields may be added to XPCS results file (either formally or informally). It is expected + that this XPCS data will be part of multi-modal data set that could involve e.g., ':'ref':'`NXcanSAS` or + 1D and/or 2D data. + +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + nP: | + Number of points + +type: group +NXxpcs(NXobject): + (NXentry)entry: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxpcs] + entry_identifier: + doc: | + **Locally** unique identifier for the experiment (a.k.a. run or scan). + + * For bluesky users, this is the run's `"scan_id"`. + * For SPEC users, this is the scan number (``SCAN_N``). + entry_identifier_uuid: + exists: ['min', '0', 'max', '1'] + doc: | + (optional) UUID identifier for this entry. + + See the `UUID standard `__ (or + `wikipedia `__) + for more information. + + * For `bluesky `__ users, this is the + run's `"uid"` and is expected for that application. + * Typically, `SPEC `__ users will + not use this field without further engineering. + scan_number(NX_INT): + deprecated: Use the ``entry_identifier`` field. + doc: | + Scan number (must be an integer). + + NOTE':' Link to collection_identifier. + start_time(NX_DATE_TIME): + doc: | + Starting time of experiment, such as "2021-02-11 11':'22':'33.445566Z". + end_time(NX_DATE_TIME): + exists: ['min', '0', 'max', '1'] + doc: | + Ending time of experiment, such as "2021-02-11 11':'23':'45Z". + (NXdata)data: + doc: | + The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) + describing on-equilibrium dynamics consume more memory resources so these data are separated. + frame_sum(NX_NUMBER): + unit: NX_COUNT + exists: ['min', '0', 'max', '1'] + doc: | + Two-dimensional summation along the frames stack. + + sum of intensity v. time (in the units of "frames") + frame_average(NX_NUMBER): + unit: NX_COUNT + exists: ['min', '0', 'max', '1'] + doc: | + Two-dimensional average along the frames stack. + + average intensity v. time (in the units of "frames") + g2(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 + + .. math':'':' g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 + + Typically, ':'math':'`g_2` is a quantity calculated for a group of pixels representing a specific + region of reciprocal space. These groupings, or bins, are generically described as ':'math':'`q`. Some + open-source XPCS libraries refer to these bins as "rois", which are not to be confused with + EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ + + In short, ':'math':'`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if + the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one + of the following two formats':' + + * iterable list of linked files (or keys) for each ':'math':'`g_2` with 1 file (key) per ':'math':'`q`, where `q` is called by the nth roi_map value + * 2D array [#]_ with shape (':'math':'`g_2`, ':'math':'`q`), where `q` is represented by the nth roi_map value, not the value `q` value + + Note it is expected that "g2" and all quantities following it will be of the same length. + + Other formats are acceptable with sufficient axes description. + + See references below for related implementation information':' + + .. [#] mask':' ``NXxpcs':'/entry/instrument/masks-group`` + .. [#] NeXus 2-D data and axes':' https':'//manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata + \@storage_mode: + type: NX_CHAR + doc: | + storage_mode describes the format of the data to be loaded + + We encourage the documentation of other formats not represented here. + + * one array representing entire data set ("one_array") + * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") + enumeration: [one_array, data_exchange_keys, other] + g2_derr(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + error values for the ':'math':'`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (':'math':'`\pm` error). The data should be in the same format as ``g2``. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array, data_exchange_keys, other] + G2_unnormalized(NX_NUMBER): + unit: NX_ANY + exists: ['min', '0', 'max', '1'] + doc: | + unnormalized intensity auto-correlation function. + + Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array, data_exchange_keys, other] + delay_difference(NX_INT): + unit: NX_COUNT + exists: ['min', '0', 'max', '1'] + doc: | + delay_difference (also known as delay or lag step) + + This is quantized difference so that the "step" between two consecutive + frames is one frame (or step ``= dt = 1 frame``) + + It is the "quantized" delay time corresponding to the ``g2`` values. + + The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, + refer to ':'ref':'`NXdetector` for conversion to time units. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array, data_exchange_keys, other] + (NXdata)twotime: + exists: ['min', '0'] + doc: | + The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. + two_time_corr_func(NX_NUMBER): + unit: NX_ANY + exists: ['min', '0', 'max', '1'] + doc: | + two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) + + See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early + description applied to X-ray scattering':' + + .. math':'':' C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } + + in which time is quantized by frames. In principle, any data format is acceptable if + the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one + of the following two formats':' + + * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array + * 3D array with shape (frames, frames, q) or (q, frames, frames), where ':'math':'`q` is represented by the nth roi_map value, not the value `q` value + + + The computation of this result can be customized. These customizations can affect subsequently derived results (below). The + following attributes will be used to manage the customization. + + * Other normalization methods may be applied, but the method will not be specified in this + definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. + + * The various software libraries use different programming languages. Therefore, we need to + specify the ``time = 0`` origin location of the 2D array for each ':'math':'`q`. + + * A method to reduce data storage needs is to only record half of the 2D array by populating + array elements above or below the array diagonal. + \@storage_mode: + type: NX_CHAR + doc: | + storage_mode describes the format of the data to be loaded + + We encourage the documention of other formats represented here. + enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] + \@baseline_reference: + type: NX_INT + doc: | + baseline is the expected value of a full decorrelation + + The baseline is a constant value added to the functional form of the auto-correlation + function. This value is required. + enumeration: [0, 1] + \@time_origin_location: + type: NX_CHAR + doc: | + time_origin_location is the location of the origin + enumeration: [upper_left, lower_left] + \@populated_elements: + type: NX_CHAR + doc: | + populated_elements describe the elements of the 2D array that are populated with data + enumeration: [all, upper_half, lower_half] + g2_from_two_time_corr_func(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + frame weighted average along the diagonal direction in ``two_time_corr_func`` + + The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" + + * iterable list of linked files for each ':'math':'`g_2` with 1 file per ':'math':'`q` + * 2D array with shape (':'math':'`g_2`, ':'math':'`q`) + + Note that delay_difference is not included here because it is derived from the shape of + extracted ':'math':'`g_2` because all frames are considered, which is not necessarily the case for ':'math':'`g_2`. + + The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The + following attributes will be used to manage the customization. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] + \@baseline_reference: + type: NX_INT + enumeration: [0, 1] + \@first_point_for_fit: + type: NX_INT + doc: | + first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. + + The first_point_for_fit is True ("1") or False ("0"). This value is required. + enumeration: [0, 1] + g2_err_from_two_time_corr_func(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + error values for the ':'math':'`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (':'math':'`\pm` error). + \@storage_mode: + type: NX_CHAR + enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] + g2_from_two_time_corr_func_partials(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` + + Time slicing along the diagonal can be very sophisticated. This entry currently assumes + equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. + In principle, any data format is acceptable if the data and its axes are self describing as per NeXus + recommendations. However, the data is preferred in one of the following two formats':' + + * iterable list of linked files (or keys) for each partial ':'math':'`g_2` of each q-bin represented by the roi_map value + * 3D array with shape (':'math':'`g_2`, ':'math':'`q`, nth_partial) + + Note that delay_difference is not included here because it is derived from the shape of + extracted ':'math':'`g_2`. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array, data_exchange_keys, other] + \@baseline_reference: + type: NX_INT + enumeration: [0, 1] + g2_err_from_two_time_corr_func_partials(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + error values for the ':'math':'`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (':'math':'`\pm` error). + (NXinstrument)instrument: + doc: | + XPCS instrument Metadata. + + Objects can be entered here directly or linked from other + objects in the NeXus file (such as within ``/entry/instrument``). + (NXbeam)incident_beam: + incident_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Incident beam line energy (either keV or eV). + incident_energy_spread(NX_FLOAT): + unit: NX_ENERGY + exists: ['min', '0', 'max', '1'] + doc: | + Spread of incident beam line energy (either keV or eV). This quantity is otherwise known + as the energy resolution, which is related to the longitudinal coherence length. + incident_polarization_type: + exists: ['min', '0', 'max', '1'] + doc: | + Terse description of the incident beam polarization. + + The value can be plain text, such as ``vertical``, ``C+``, + ``circular left``. + extent(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Size (2-D) of the beam at this position. + (NXdetector): + doc: | + XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes + this data is represented in different ways (sparse arrays or photon event list), but this detail + is left to the analysis software. Therefore, we only include requirements based on full array data. + + We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This + is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ + See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and + the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI + documentation (See Fig 11 vs Fig 12). + + Additionally, not all ':'ref':'`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to + convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may + either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. + + .. [#] Coherent X-ray Imaging Data Bank':' https':'//cxidb.org/cxi.html + description: + exists: ['min', '0', 'max', '1'] + doc: | + Detector name. + distance(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Distance between sample and detector. + count_time(NX_NUMBER): + unit: NX_TIME + doc: | + Exposure time of frames, s. + frame_time(NX_NUMBER): + unit: NX_TIME + doc: | + Exposure period (time between frame starts) of frames, s + beam_center_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of beam center, x axis, in detector's coordinates. + beam_center_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of beam center, y axis, in detector's coordinates. + x_pixel_size(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Length of pixel in x direction. + y_pixel_size(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Length of pixel in y direction. + (NXnote)masks: + exists: ['min', '0', 'max', '1'] + doc: | + Data masks or mappings to regions of interest (roi) for specific ':'math':'`Q` values + + Fields in this ``masks`` group describe regions of interest + in the data by either a mask to select pixels or to associate + a *map* of rois with a (one-dimensional) *list* of values. + + "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, + which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. + + "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and + NXxpcs/entry/two_time. + + "Static" refers to finer binning used for computation not strictly used for the final + XPCS results. Implementation of _static_ binning is left for individual libraries to + document. We encourage usage of ':'ref':'`NXcanSAS` to represent standard SAXS results or + development of new NeXus definitions for GI-SAXS or other reciprocal space + intensity mapping. + dynamic_roi_map(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + roi index array or labeled array + + The values of this mask index (or map to) the ':'math':'`Q` value from the + the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations + are performed on all pixels with a value > 0. + + The ``units`` attribute should be set to ``"au"`` + indicating arbitrary units. + dynamic_q_list(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0'] + doc: | + 1-D list of ':'math':'`Q` values, one for each roi index value. + + List order is determined by the index value of the associated roi map starting at ``1``. + + The only requirement for the list is that it may be iterable. Some expected formats are':' + + * iterable list of floats (i.e., ':'math':'`Q(r)`) + * iterable list of tuples (i.e., ':'math':'`Q(r)`, ':'math':'`\varphi`), but preferable use the seperate ':'math':'`\varphi` field below + * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) + * iterable list of integers (for Nth roi_map value) or strings + + This format is chosen because results plotting packages are not common and simple I/O is required by end user. + The lists can be accessed as lists, arrays or via keys + dynamic_phi_list(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0'] + doc: | + Array of ':'math':'`\varphi` value for each pixel. + + List order is determined by the index value of the associated roi map starting at ``1``. + static_roi_map(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0'] + doc: | + roi index array. + + The values of this mask index the ':'math':'`|Q|` value from the + the ``static_q_list`` field. + + The ``units`` attribute should be set to ``"au"`` + indicating arbitrary units. + static_q_list(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0'] + doc: | + 1-D list of ':'math':'`|Q|` values, 1 for each roi. + (NXsample)sample: + exists: ['min', '0'] + temperature_set(NX_NUMBER): + unit: NX_TEMPERATURE + exists: ['min', '0'] + doc: | + Sample temperature setpoint, (C or K). + temperature(NX_NUMBER): + unit: NX_TEMPERATURE + exists: ['min', '0'] + doc: | + Sample temperature actual, (C or K). + (NXpositioner)position_x: + exists: ['min', '0'] + (NXpositioner)position_y: + exists: ['min', '0'] + (NXpositioner)position_z: + exists: ['min', '0'] + (NXnote)NOTE: + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Any other notes. + + NAME':' The NeXus convention, to use all upper case + to indicate the name (here ``NOTE``), is left to the file + writer. In our case, follow the suggested name + pattern and sequence':' note_1, note_2, note_3, ... + Start with ``note_1`` if the first one, otherwise + pick the next number in this sequence. + (NXprocess): + doc: | + Describe the computation process that produced these results. From f7b5c2bd2581f2ba11ccb29e1b55d5301368b31a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 16 Mar 2023 18:43:19 +0100 Subject: [PATCH 110/203] Update ellipsometry-structure.rst --- manual/source/ellipsometry-structure.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst index 943b7d9c97..a86b73f711 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/ellipsometry-structure.rst @@ -81,7 +81,7 @@ There is a set of base classes for describing a dispersion. :ref:`NXdispersion_function` This dispersion is described by a function and its single and repeated parameter values. It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` - (Sellmeier formula). See the formula grammer below for an ebnf grammar for this form. + (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. :ref:`NXdispersion_single_parameter` This denotes a parameter which is used outside the summed part of a dispersion function, @@ -154,4 +154,4 @@ filled with the respective single and repeated params from the stored data. %import common.WS_INLINE %ignore WS_INLINE - \ No newline at end of file + From 7e588c874fb30985629ca2301402be9a2d140776 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Thu, 16 Mar 2023 18:46:00 +0100 Subject: [PATCH 111/203] Application definition: .yaml in App_definitoin/nyaml file has been created from nxdl in App_def. --- applications/nyaml/NXarchive.yaml | 36 +- applications/nyaml/NXarpes.yaml | 22 +- applications/nyaml/NXcanSAS.yaml | 861 ++++++++++++++------------ applications/nyaml/NXdirecttof.yaml | 16 +- applications/nyaml/NXfluo.yaml | 34 +- applications/nyaml/NXindirecttof.yaml | 16 +- applications/nyaml/NXiqproc.yaml | 38 +- applications/nyaml/NXlauetof.yaml | 50 +- applications/nyaml/NXmonopd.yaml | 50 +- applications/nyaml/NXmx.yaml | 342 +++++----- applications/nyaml/NXrefscan.yaml | 38 +- applications/nyaml/NXreftof.yaml | 48 +- applications/nyaml/NXsas.yaml | 58 +- applications/nyaml/NXsastof.yaml | 55 +- applications/nyaml/NXscan.yaml | 68 +- applications/nyaml/NXspe.yaml | 10 +- applications/nyaml/NXsqom.yaml | 31 +- applications/nyaml/NXstxm.yaml | 153 ++--- applications/nyaml/NXtas.yaml | 51 +- applications/nyaml/NXtofnpd.yaml | 43 +- applications/nyaml/NXtofraw.yaml | 45 +- applications/nyaml/NXtofsingle.yaml | 48 +- applications/nyaml/NXtomo.yaml | 90 +-- applications/nyaml/NXtomophase.yaml | 68 +- applications/nyaml/NXtomoproc.yaml | 44 +- applications/nyaml/NXxas.yaml | 39 +- applications/nyaml/NXxasproc.yaml | 29 +- applications/nyaml/NXxbase.yaml | 85 +-- applications/nyaml/NXxeuler.yaml | 50 +- applications/nyaml/NXxkappa.yaml | 49 +- applications/nyaml/NXxlaue.yaml | 30 +- applications/nyaml/NXxlaueplate.yaml | 18 +- applications/nyaml/NXxnb.yaml | 48 +- applications/nyaml/NXxrot.yaml | 38 +- 34 files changed, 1530 insertions(+), 1171 deletions(-) diff --git a/applications/nyaml/NXarchive.yaml b/applications/nyaml/NXarchive.yaml index 7b56c66182..3dc5d4599e 100644 --- a/applications/nyaml/NXarchive.yaml +++ b/applications/nyaml/NXarchive.yaml @@ -1,15 +1,17 @@ -doc: | - This is a definition for data to be archived by ICAT (http://www.icatproject.org/). +category: application +doc: | + This is a definition for data to be archived by ICAT (http':'//www.icatproject.org/). .. text from the icatproject.org site - the database (with supporting software) that provides an - interface to all ISIS experimental data and will provide - a mechanism to link all aspects of ISIS research from - proposal through to publication. -category: application -NXarchive: - entry(NXentry): + the database (with supporting software) that provides an + interface to all ISIS experimental data and will provide + a mechanism to link all aspects of ISIS research from + proposal through to publication. + +type: group +NXarchive(NXobject): + (NXentry)entry: \@index: title: experiment_identifier(NX_CHAR): @@ -32,14 +34,14 @@ NXarchive: duration(NX_FLOAT): unit: NX_TIME doc: | - TODO: needs documentation + TODO':' needs documentation collection_time(NX_FLOAT): unit: NX_TIME doc: | - TODO: needs documentation + TODO':' needs documentation run_cycle(NX_CHAR): doc: | - TODO: needs documentation + TODO':' needs documentation revision(NX_CHAR): doc: | revision ID of this file, may be after recalibration, reprocessing etc. @@ -55,7 +57,7 @@ NXarchive: unit: NX_TIME doc: | when this file is to be released into PD - user(NXuser): + (NXuser)user: name(NX_CHAR): role(NX_CHAR): doc: | @@ -63,7 +65,7 @@ NXarchive: facility_user_id(NX_CHAR): doc: | ID of the user in the facility burocracy database - instrument(NXinstrument): + (NXinstrument)instrument: (NXsource): type(NX_CHAR): enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-Ray Source, Pulsed Muon Source, Rotating Anode X-Ray, Fixed Tube X-Ray] @@ -74,7 +76,7 @@ NXarchive: description(NX_CHAR): doc: | Brief description of the instrument - sample(NXsample): + (NXsample)sample: name: doc: | Descriptive name of sample @@ -90,8 +92,8 @@ NXarchive: preparation_date(NX_CHAR): unit: NX_TIME situation(NX_CHAR): - doc: | - Description of the environment the sample is in: + doc: | + Description of the environment the sample is in':' air, vacuum, oxidizing atmosphere, dehydrated, etc. temperature(NX_FLOAT): unit: NX_TEMPERATURE diff --git a/applications/nyaml/NXarpes.yaml b/applications/nyaml/NXarpes.yaml index 48a8d2ab41..7e6a20fd13 100644 --- a/applications/nyaml/NXarpes.yaml +++ b/applications/nyaml/NXarpes.yaml @@ -1,13 +1,15 @@ -doc: | +category: application +doc: | This is an application definition for angular resolved photo electron spectroscopy. It has been drawn up with hemispherical electron analysers in mind. -category: application -NXarpes: + +type: group +NXarpes(NXobject): (NXentry): \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... + doc: | + NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry. title(NX_CHAR): start_time(NX_DATE_TIME): @@ -21,10 +23,10 @@ NXarpes: name(NX_CHAR): probe: enumeration: [x-ray] - monochromator(NXmonochromator): + (NXmonochromator)monochromator: energy(NX_NUMBER): unit: NX_ENERGY - analyser(NXdetector): + (NXdetector)analyser: data(NX_NUMBER): lens_mode(NX_CHAR): doc: | @@ -48,16 +50,16 @@ NXarpes: time_per_channel(NX_NUMBER): unit: NX_TIME doc: | - todo: define more clearly + todo':' define more clearly angles(NX_NUMBER): unit: NX_ANGLE - doc: | + doc: | Angular axis of the analyser data which dimension the axis applies to is defined using the normal NXdata methods. energies(NX_NUMBER): unit: NX_ENERGY - doc: | + doc: | Energy axis of the analyser data which dimension the axis applies to is defined using the normal NXdata methods. diff --git a/applications/nyaml/NXcanSAS.yaml b/applications/nyaml/NXcanSAS.yaml index bc4baf5616..b4db70c019 100644 --- a/applications/nyaml/NXcanSAS.yaml +++ b/applications/nyaml/NXcanSAS.yaml @@ -1,38 +1,39 @@ -doc: | +category: application +doc: | Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. - .. index:: canSAS - - For more details, see: + .. index':'':' canSAS - * http://www.cansas.org/ - * http://www.cansas.org/formats/canSAS1d/1.1/doc/ - * http://cansas-org.github.io/canSAS2012/ - * https://github.com/canSAS-org/NXcanSAS_examples + For more details, see':' - The minimum requirements for *reduced* small-angle scattering data - as described by canSAS are summarized in the following figure: + * http':'//www.cansas.org/ + * http':'//www.cansas.org/formats/canSAS1d/1.1/doc/ + * http':'//cansas-org.github.io/canSAS2012/ + * https':'//github.com/canSAS-org/NXcanSAS_examples - .. _canSAS_2012_minimum: + The minimum requirements for *reduced* small-angle scattering data + as described by canSAS are summarized in the following figure':' - .. figure:: canSAS/2012-minimum.png - :width: 60% + .. _canSAS_2012_minimum':' - The minimum requirements for *reduced* small-angle scattering data. - (:download:`full image `) - See :ref:`below ` for the minimum required - information for a NeXus data file - written to the NXcanSAS specification. + .. figure':'':' canSAS/2012-minimum.png + ':'width':' 60% + + The minimum requirements for *reduced* small-angle scattering data. + (':'download':'`full image `) + See ':'ref':'`below ` for the minimum required + information for a NeXus data file + written to the NXcanSAS specification. - .. rubric:: Implementation of canSAS standard in NeXus + .. rubric':'':' Implementation of canSAS standard in NeXus This application definition is an implementation of the canSAS - standard for storing both one-dimensional and multi-dimensional + standard for storing both one-dimensional and multi-dimensional *reduced* small-angle scattering data. * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. - * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` - * External file links are not to be used for the reduced data. + * *Reduced* SAS data consists of ':'math':'`I(\vec{Q})` or ':'math':'`I(|\vec{Q}|)` + * External file links are not to be used for the reduced data. * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. * There is no need for NXcanSAS to refer to any raw data. @@ -57,177 +58,186 @@ doc: | =============== ============ ========================== (*) The name of each group is a suggestion, - not a fixed requirement and is chosen as fits each data file. + not a fixed requirement and is chosen as fits each data file. See the section on defining - :ref:`NXDL group and field names `. + ':'ref':'`NXDL group and field names `. - Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) - for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. + Refer to the NeXus Coordinate System drawing (':'ref':'`Design-CoordinateSystem`) + for choice and direction of ':'math':'`x`, ':'math':'`y`, and ':'math':'`z` axes. - .. _NXcanSAS_minimum: + .. _NXcanSAS_minimum':' - .. rubric:: The minimum required information for a NeXus data file - written to the NXcanSAS specification. + .. rubric':'':' The minimum required information for a NeXus data file + written to the NXcanSAS specification. - .. literalinclude:: canSAS/minimum-required.txt - :tab-width: 4 - :linenos: - :language: text -category: application -NXcanSAS: + .. literalinclude':'':' canSAS/minimum-required.txt + ':'tab-width':' 4 + ':'linenos':' + ':'language':' text + +type: group +NXcanSAS(NXobject): (NXentry): \@default: - doc: | - .. index:: plotting + exists: optional + doc: | + .. index':'':' plotting - Declares which :ref:`NXdata` group + Declares which ':'ref':'`NXdata` group contains the data to be shown by default. - It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. - The value is the name of the default :ref:`NXdata` group. + It is needed to resolve ambiguity when more than one ':'ref':'`NXdata` group exists. + The value is the name of the default ':'ref':'`NXdata` group. Usually, this will be the name of the first *SASdata* group. - doc: | - .. index:: NXcanSAS (applications); SASentry + doc: | + .. index':'':' NXcanSAS (applications); SASentry Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group (when data from multiple techniques are being stored) - or as a replacement for the ``NXentry`` group. + or as a replacement for the ``NXentry`` group. - Note: It is required for all numerical objects to provide - a *units* attribute that describes the engineering units. - Use the Unidata UDunits [#]_ specification + Note':' It is required for all numerical objects to provide + a *units* attribute that describes the engineering units. + Use the Unidata UDunits [#]_ specification as this is compatible with various community standards. .. [#] The UDunits specification also includes instructions for derived units. \@canSAS_class: - doc: | - Official canSAS group: **SASentry** + doc: | + Official canSAS group':' **SASentry** enumeration: [SASentry] \@version: - doc: | - Describes the version of the canSAS standard used to write this data. - This must be a text (not numerical) representation. Such as:: + doc: | + Describes the version of the canSAS standard used to write this data. + This must be a text (not numerical) representation. Such as':'':' - @version="1.1" + @version="1.1" enumeration: [1.1] definition: doc: | Official NeXus NXDL schema to which this subentry conforms. enumeration: [NXcanSAS] (NXdata): - doc: | - A *SASData* group contains a single reduced small-angle scattering data set - that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. + doc: | + A *SASData* group contains a single reduced small-angle scattering data set + that can be represented as ':'math':'`I(\vec{Q})` or ':'math':'`I(|\vec{Q}|)`. - *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) + *Q* can be either a vector (':'math':'`\vec{Q}`) or a vector magnitude (':'math':'`|\vec{Q}|`) - The name of each *SASdata* group must be unique within a SASentry group. + The name of each *SASdata* group must be unique within a SASentry group. Suggest using names such as ``sasdata01``. - NOTE: For the first *SASdata* group, be sure to write the chosen name - into the `SASentry/@default` attribute, as in:: + NOTE':' For the first *SASdata* group, be sure to write the chosen name + into the `SASentry/@default` attribute, as in':'':' - SASentry/@default="sasdata01" + SASentry/@default="sasdata01" - A *SASdata* group has several attributes: + A *SASdata* group has several attributes':' * I_axes * Q_indices * Mask_indices - To indicate the dependency relationships of other varied parameters, + To indicate the dependency relationships of other varied parameters, use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` or ``@Pressure_indices``). \@canSAS_class: doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASdata` + Official canSAS group':' ':'index':'`NXcanSAS (applications); SASdata` enumeration: [SASdata] \@signal: - doc: | + type: NX_CHAR + doc: | Name of the default data field. enumeration: I: doc: | For canSAS **SASdata**, this is always "I". \@I_axes: - doc: | - String array that defines the independent data fields used in + doc: | + String array that defines the independent data fields used in the default plot for all of the dimensions of the *signal* field (the *signal* field is the field in this group that is named by - the ``signal`` attribute of this group). - One entry is provided for every dimension of the ``I`` data object. - Such as:: + the ``signal`` attribute of this group). + One entry is provided for every dimension of the ``I`` data object. + Such as':'':' - @I_axes="Temperature", "Time", "Pressure", "Q", "Q" + @I_axes="Temperature", "Time", "Pressure", "Q", "Q" Since there are five items in the list, the intensity field of this example ``I`` must be a five-dimensional array (rank=5). \@Q_indices: - doc: | - Integer or integer array that describes which indices - (of the :math:`I` data object) are used to - reference the ``Q`` data object. The items in this array - use zero-based indexing. Such as:: + type: NX_INT + doc: | + Integer or integer array that describes which indices + (of the ':'math':'`I` data object) are used to + reference the ``Q`` data object. The items in this array + use zero-based indexing. Such as':'':' - @Q_indices=1,3,4 + @Q_indices=1,3,4 which indicates that ``Q`` requires three indices - from the :math:`I` data object: one for time and + from the ':'math':'`I` data object':' one for time and two for Q position. Thus, in this example, the - ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. + ``Q`` data is time-dependent':' ':'math':'`\vec{Q}(t)`. \@mask: - doc: | + type: NX_CHAR + doc: | Name of the data mask field. - .. see: https://github.com/nexusformat/definitions/issues/533 + .. see':' https':'//github.com/nexusformat/definitions/issues/533 The data *mask* must have the same shape as the *data* field. Positions in the mask correspond to positions in the *data* field. - The value of the mask field may be either a boolean array + The value of the mask field may be either a boolean array where ``false`` means *no mask* and ``true`` means *mask* - or a more descriptive array as as defined in :ref:`NXdetector`. + or a more descriptive array as as defined in ':'ref':'`NXdetector`. \@Mask_indices: - doc: | + exists: optional + doc: | Integer or integer array that describes which indices - (of the :math:`I` data object) are used to + (of the ':'math':'`I` data object) are used to reference the ``Mask`` data object. The items in this - array use zero-based indexing. Such as:: + array use zero-based indexing. Such as':'':' - @Mask_indices=3,4 + @Mask_indices=3,4 which indicates that Q requires two indices - from the :math:`I` data object for Q position. + from the ':'math':'`I` data object for Q position. \@timestamp: - doc: | + type: NX_DATE_TIME + exists: optional + doc: | ISO-8601 time [#iso8601]_ Q(NX_NUMBER): unit: NX_PER_LENGTH - doc: | - .. index:: NXcanSAS (applications); Q + doc: | + .. index':'':' NXcanSAS (applications); Q + + Array of ':'math':'`Q` data to accompany ':'math':'`I`. - Array of :math:`Q` data to accompany :math:`I`. + .. figure':'':' canSAS/Q-geometry.jpg + ':'width':' 60% - .. figure:: canSAS/Q-geometry.jpg - :width: 60% + The ':'math':'`\vec{Q}` geometry. + (':'download':'`full image `) - The :math:`\vec{Q}` geometry. - (:download:`full image `) + ':'math':'`Q` may be represented as either + the three-dimensional scattering vector ':'math':'`\vec{Q}` + or the magnitude of the scattering vector, ':'math':'`|\vec{Q}|`. - :math:`Q` may be represented as either - the three-dimensional scattering vector :math:`\vec{Q}` - or the magnitude of the scattering vector, :math:`|\vec{Q}|`. + .. math':'':' |\vec{Q}| = (4\pi/\lambda) sin(\theta) - .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) - - When we write :math:`Q`, we may refer to either or both of - :math:`|\vec{Q}|` - or :math:`\vec{Q}`, depending on the context. + When we write ':'math':'`Q`, we may refer to either or both of + ':'math':'`|\vec{Q}|` + or ':'math':'`\vec{Q}`, depending on the context. \@units: - doc: | + exists: optional + doc: | Engineering units to use when expressing - :math:`Q` and related terms. + ':'math':'`Q` and related terms. Data expressed in other units will generate - a warning from validation software and may not + a warning from validation software and may not be processed by some analysis software packages. enumeration: 1/m: @@ -236,124 +246,129 @@ NXcanSAS: preferred 1/angstrom: \@uncertainties: - doc: | - (optional: for numerical arrays) + exists: optional + doc: | + (optional':' for numerical arrays) - Names the dataset (in this SASdata group) that provides the - uncertainty to be used for data analysis. - The name of the dataset containing the :math:`Q` uncertainty + Names the dataset (in this SASdata group) that provides the + uncertainty to be used for data analysis. + The name of the dataset containing the ':'math':'`Q` uncertainty is flexible. The name must be unique in the *SASdata* group. .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 + see':' https':'//github.com/canSAS-org/canSAS2012/issues/7 - Such as:: + Such as':'':' - @uncertainties="Q_uncertainties" + @uncertainties="Q_uncertainties" The *uncertainties* field will have the same *shape* (dimensions) as the Q field. - These values are the estimates of uncertainty of each Q. By default, - this will be interpreted to be the estimated standard deviation. - In special cases, when a standard deviation cannot possibly be used, + These values are the estimates of uncertainty of each Q. By default, + this will be interpreted to be the estimated standard deviation. + In special cases, when a standard deviation cannot possibly be used, its value can specify another measure of distribution width. - There may also be a subdirectory (optional) with constituent + There may also be a subdirectory (optional) with constituent components. - .. note:: To report distribution in reported :math:`Q` values, - use the ``@resolutions`` attribute. It is possible for both - ``@resolutions`` and ``uncertainties`` to be reported. + .. note':'':' To report distribution in reported ':'math':'`Q` values, + use the ``@resolutions`` attribute. It is possible for both + ``@resolutions`` and ``uncertainties`` to be reported. \@resolutions: - doc: | - .. index:: NXcanSAS (applications); resolutions + type: NX_CHAR + exists: optional + doc: | + .. index':'':' NXcanSAS (applications); resolutions - (optional: for numerical arrays) + (optional':' for numerical arrays) - Names the dataset (in this SASdata group) containing the :math:`Q` resolution. - The name of the dataset containing the :math:`Q` resolution + Names the dataset (in this SASdata group) containing the ':'math':'`Q` resolution. + The name of the dataset containing the ':'math':'`Q` resolution is flexible. The name must be unique in the *SASdata* group. .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 + see':' https':'//github.com/canSAS-org/canSAS2012/issues/7 The *resolutions* field will have the same *shape* (dimensions) as the Q field. - Generally, this is the principal resolution of each :math:`Q`. - Names the data object (in this SASdata group) that provides the - :math:`Q` resolution to be used for data analysis. Such as:: + Generally, this is the principal resolution of each ':'math':'`Q`. + Names the data object (in this SASdata group) that provides the + ':'math':'`Q` resolution to be used for data analysis. Such as':'':' - @resolutions="Qdev" + @resolutions="Qdev" - To specify two-dimensional resolution for slit-smearing geometry, - such as (*dQw*, *dQl*), use a string array, such as:: + To specify two-dimensional resolution for slit-smearing geometry, + such as (*dQw*, *dQl*), use a string array, such as':'':' - @resolutions="dQw", "dQl" + @resolutions="dQw", "dQl" - There may also be a subdirectory (optional) with constituent + There may also be a subdirectory (optional) with constituent components. - This pattern will demonstrate how to introduce further as-yet + This pattern will demonstrate how to introduce further as-yet unanticipated terms related to the data. .. comment - see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 + see':' https':'//github.com/nexusformat/definitions/issues/492#issuecomment-262813907 By default, the values of the resolutions data object are assumed to be - one standard deviation of any function used to approximate the - resolution function. This equates to the width of the gaussian + one standard deviation of any function used to approximate the + resolution function. This equates to the width of the gaussian distribution if a Gaussian is chosen. See the ``@resolutions_description`` attribute. - .. note:: To report uncertainty in reported :math:`Q` values, - use the ``@uncertainties`` attribute. It is possible for both - ``@resolutions`` and ``uncertainties`` to be reported. + .. note':'':' To report uncertainty in reported ':'math':'`Q` values, + use the ``@uncertainties`` attribute. It is possible for both + ``@resolutions`` and ``uncertainties`` to be reported. \@resolutions_description: - doc: | - (optional) - Generally, this describes the :math:`Q` ``@resolutions`` data object. + type: NX_CHAR + exists: optional + doc: | + (optional) + Generally, this describes the ':'math':'`Q` ``@resolutions`` data object. By default, the value is assumed to be "Gaussian". These are - suggestions: + suggestions':' * Gaussian * Lorentzian - * Square : - note that the full width of the square would be ~2.9 times - the standard deviation specified in the vector + * Square ':' + note that the full width of the square would be ~2.9 times + the standard deviation specified in the vector * Triangular - * Sawtooth-outward : vertical edge pointing to larger Q + * Sawtooth-outward ':' vertical edge pointing to larger Q * Sawtooth-inward vertical edge pointing to smaller Q - * Bin : range of values contributing - (for example, when 2-D detector data have been reduced - to a 1-D :math:`I(|Q|)` dataset) + * Bin ':' range of values contributing + (for example, when 2-D detector data have been reduced + to a 1-D ':'math':'`I(|Q|)` dataset) For other meanings, it may be necessary to provide further details such as the function used to assess the resolution. - In such cases, use additional datasets or a :ref:`NXnote` subgroup + In such cases, use additional datasets or a ':'ref':'`NXnote` subgroup to include that detail. I(NX_NUMBER): - doc: | - .. index:: NXcanSAS (applications); I - - Array of intensity (:math:`I`) data. + doc: | + .. index':'':' NXcanSAS (applications); I + + Array of intensity (':'math':'`I`) data. - The intensity may be represented in one of these forms: + The intensity may be represented in one of these forms':' - **absolute units**: :math:`d\Sigma/d\Omega(Q)` + **absolute units**':' ':'math':'`d\Sigma/d\Omega(Q)` differential cross-section - per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) + per unit volume per unit solid angle (such as':' 1/cm/sr or 1/m/sr) - **absolute units**: :math:`d\sigma/d\Omega(Q)` + **absolute units**':' ':'math':'`d\sigma/d\Omega(Q)` differential cross-section - per unit atom per unit solid angle (such as: cm^2 or m^2) + per unit atom per unit solid angle (such as':' cm^2 or m^2) - **arbitrary units**: :math:`I(Q)` - usually a ratio of two detectors - but units are meaningless (such as: a.u. or counts) + **arbitrary units**':' ':'math':'`I(Q)` + usually a ratio of two detectors + but units are meaningless (such as':' a.u. or counts) - This presents a few problems + This presents a few problems for analysis software to sort out when reading the data. Fortunately, it is possible to analyze the *units* to determine which type of intensity is being reported and make choices at the time the file is read. But this is @@ -364,20 +379,21 @@ NXcanSAS: types of intensity indiscriminately. A second problem is that when arbitrary units are used, then the set of possible - analytical results is restricted. With such units, no meaningful volume fraction - or number density can be determined directly from :math:`I(Q)`. + analytical results is restricted. With such units, no meaningful volume fraction + or number density can be determined directly from ':'math':'`I(Q)`. - In some cases, it is possible to apply a factor to convert the arbitrary - units to an absolute scale. This should be considered as a possibility + In some cases, it is possible to apply a factor to convert the arbitrary + units to an absolute scale. This should be considered as a possibility of the analysis process. Where this documentation says *typical units*, it is possible that small-angle data may be presented in other units and still be consistent with NeXus. - See the :ref:`design-units` section. + See the ':'ref':'`design-units` section. \@units: - doc: | + exists: optional + doc: | Engineering units to use when expressing - :math:`I` and intensity-related terms. + ':'math':'`I` and intensity-related terms. Data expressed in other units (or missing a ``@units`` attribute) will be treated as ``arbitrary`` by some software packages. @@ -395,61 +411,65 @@ NXcanSAS: cm2/g: arbitrary: \@uncertainties: - doc: | - (optional: for numerical arrays) + exists: optional + doc: | + (optional':' for numerical arrays) - Names the dataset (in this SASdata group) that provides the - uncertainty of :math:`I` to be used for data analysis. - The name of the dataset containing the :math:`I` uncertainty + Names the dataset (in this SASdata group) that provides the + uncertainty of ':'math':'`I` to be used for data analysis. + The name of the dataset containing the ':'math':'`I` uncertainty is flexible. The name must be unique in the *SASdata* group. .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 + see':' https':'//github.com/canSAS-org/canSAS2012/issues/7 - Generally, this is the estimate of the uncertainty of each :math:`I`. - Typically the estimated standard deviation. + Generally, this is the estimate of the uncertainty of each ':'math':'`I`. + Typically the estimated standard deviation. - *Idev* is the canonical name from the 1D standard. + *Idev* is the canonical name from the 1D standard. The NXcanSAS standard allows for the name to be described using this attribute. - Such as:: + Such as':'':' - @uncertainties="Idev" + @uncertainties="Idev" \@scaling_factor: - doc: | - (optional) + exists: optional + doc: | + (optional) Names the field (a.k.a. dataset) that contains a factor to multiply ``I``. By default, this value is unity. Should an uncertainty be associated with the scaling factor - field, the field containing that uncertainty would be - designated via the ``uncertainties`` attribute. - Such as:: - - I : NX_NUMBER - @uncertainties="Idev" : NX_CHAR - @scaling_factor="I_scaling" : NX_CHAR - Idev : NX_NUMBER - I_scaling : NX_NUMBER - @uncertainties="I_scaling_dev" : NX_CHAR - I_scaling_dev : NX_NUMBER + field, the field containing that uncertainty would be + designated via the ``uncertainties`` attribute. + Such as':'':' + + I ':' NX_NUMBER + @uncertainties="Idev" ':' NX_CHAR + @scaling_factor="I_scaling" ':' NX_CHAR + Idev ':' NX_NUMBER + I_scaling ':' NX_NUMBER + @uncertainties="I_scaling_dev" ':' NX_CHAR + I_scaling_dev ':' NX_NUMBER The exact names for ``I_scaling`` and ``I_scaling_dev`` are not - defined by NXcanSAS. The user has the flexibility to use names + defined by NXcanSAS. The user has the flexibility to use names different than those shown in this example. Idev(NX_NUMBER): - doc: | - .. index:: NXcanSAS (applications); Idev + exists: ['min', '0'] + doc: | + .. index':'':' NXcanSAS (applications); Idev Estimated **uncertainty** (usually standard deviation) - in :math:`I`. Must have the same units as :math:`I`. + in ':'math':'`I`. Must have the same units as ':'math':'`I`. - When present, the name of this field is also - recorded in the *uncertainties* attribute of *I*, as in:: + When present, the name of this field is also + recorded in the *uncertainties* attribute of *I*, as in':'':' - I/@uncertainties="Idev" + I/@uncertainties="Idev" \@units: - doc: | + exists: optional + doc: | Engineering units to use when expressing - :math:`I` and intensity-related terms. + ':'math':'`I` and intensity-related terms. Data expressed in other units (or missing a ``@units`` attribute) will generate a warning from any validation process @@ -469,27 +489,29 @@ NXcanSAS: arbitrary: Qdev(NX_NUMBER): unit: NX_PER_LENGTH - doc: | - .. index:: NXcanSAS (applications); Qdev + exists: ['min', '0'] + doc: | + .. index':'':' NXcanSAS (applications); Qdev - Estimated :math:`Q` **resolution** (usually standard deviation). - Must have the same units as :math:`Q`. + Estimated ':'math':'`Q` **resolution** (usually standard deviation). + Must have the same units as ':'math':'`Q`. - When present, the name of this field is also - recorded in the *resolutions* attribute of *Q*, - as in:: + When present, the name of this field is also + recorded in the *resolutions* attribute of *Q*, + as in':'':' - Q/@resolutions="Qdev" + Q/@resolutions="Qdev" - or:: + or':'':' - Q/@resolutions="dQw", "dQl" + Q/@resolutions="dQw", "dQl" \@units: - doc: | + exists: optional + doc: | Engineering units to use when expressing - :math:`Q` and related terms. + ':'math':'`Q` and related terms. - Data expressed in other units may not be processed by some + Data expressed in other units may not be processed by some software packages. enumeration: 1/m: @@ -499,26 +521,28 @@ NXcanSAS: 1/angstrom: dQw(NX_NUMBER): unit: NX_PER_LENGTH - doc: | - .. index:: NXcanSAS (applications); dQw + exists: ['min', '0'] + doc: | + .. index':'':' NXcanSAS (applications); dQw - :math:`Q` **resolution** along the axis of scanning - (the high-resolution *slit width* direction). - Useful for defining resolution data from + ':'math':'`Q` **resolution** along the axis of scanning + (the high-resolution *slit width* direction). + Useful for defining resolution data from slit-smearing instruments such as Bonse-Hart geometry. - Must have the same units as :math:`Q`. + Must have the same units as ':'math':'`Q`. - When present, the name of this field is also - recorded in the *resolutions* attribute of *Q*, - as in:: + When present, the name of this field is also + recorded in the *resolutions* attribute of *Q*, + as in':'':' - Q/@resolutions="dQw", "dQl" + Q/@resolutions="dQw", "dQl" \@units: - doc: | + exists: optional + doc: | Engineering units to use when expressing - :math:`Q` and related terms. + ':'math':'`Q` and related terms. - Data expressed in other units may not be processed by some + Data expressed in other units may not be processed by some software packages. enumeration: 1/m: @@ -528,26 +552,28 @@ NXcanSAS: 1/angstrom: dQl(NX_NUMBER): unit: NX_PER_LENGTH - doc: | - .. index:: NXcanSAS (applications); dQl + exists: ['min', '0'] + doc: | + .. index':'':' NXcanSAS (applications); dQl - :math:`Q` **resolution** perpendicular to the axis of scanning - (the low-resolution *slit length* direction). - Useful for defining resolution data from + ':'math':'`Q` **resolution** perpendicular to the axis of scanning + (the low-resolution *slit length* direction). + Useful for defining resolution data from slit-smearing instruments such as Bonse-Hart geometry. - Must have the same units as :math:`Q`. + Must have the same units as ':'math':'`Q`. - When present, the name of this field is also - recorded in the *resolutions* attribute of *Q*, - as in:: + When present, the name of this field is also + recorded in the *resolutions* attribute of *Q*, + as in':'':' - Q/@resolutions="dQw", "dQl" + Q/@resolutions="dQw", "dQl" \@units: - doc: | + exists: optional + doc: | Engineering units to use when expressing - :math:`Q` and related terms. + ':'math':'`Q` and related terms. - Data expressed in other units may not be processed by some + Data expressed in other units may not be processed by some software packages. enumeration: 1/m: @@ -556,20 +582,22 @@ NXcanSAS: preferred 1/angstrom: Qmean(NX_NUMBER): + exists: ['min', '0'] unit: NX_PER_LENGTH - doc: | - Mean value of :math:`Q` for this data point. - Useful when describing data that has been - binned from higher-resolution data. + doc: | + Mean value of ':'math':'`Q` for this data point. + Useful when describing data that has been + binned from higher-resolution data. - It is expected that ``Q`` is provided + It is expected that ``Q`` is provided and that both ``Q`` and ``Qmean`` will have the same units. \@units: - doc: | + exists: optional + doc: | Engineering units to use when expressing - :math:`Q` and related terms. + ':'math':'`Q` and related terms. - Data expressed in other units may not be processed by some + Data expressed in other units may not be processed by some software packages. enumeration: 1/m: @@ -578,147 +606,155 @@ NXcanSAS: preferred 1/angstrom: ShadowFactor: + exists: ['min', '0'] unit: NX_DIMENSIONLESS - doc: | - A numerical factor applied to pixels affected by the beam stop penumbra. + doc: | + A numerical factor applied to pixels affected by the beam stop penumbra. Used in data files from NIST/NCNR instruments. - See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. + See':' J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. title: - exists: [min, 1, max, 1] - doc: | - Title of this *SASentry*. + exists: ['min', '1', 'max', '1'] + doc: | + Title of this *SASentry*. Make it so that you can recognize the data by its title. Could be the name of the sample, the name for the measured data, or something else representative. run: - exists: [min, 1, max, unbounded] - doc: | - Run identification for this *SASentry*. - For many facilities, this is an integer, such as en experiment number. + exists: ['min', '1', 'max', 'unbounded'] + nameType: any + doc: | + Run identification for this *SASentry*. + For many facilities, this is an integer, such as en experiment number. Use multiple instances of ``run`` as needed, keeping in mind that HDF5 requires unique names for all entities in a group. \@name: - doc: | - Optional string attribute to identify this particular *run*. + exists: optional + doc: | + Optional string attribute to identify this particular *run*. Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. (NXinstrument): + exists: ['min', '0'] \@canSAS_class: doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` + Official canSAS group':' ':'index':'`NXcanSAS (applications); SASinstrument` enumeration: [SASinstrument] - doc: | + doc: | Description of the small-angle scattering instrument. Consider, carefully, the relevance to the SAS data analysis process when adding subgroups in this **NXinstrument** group. Additional information can be added but will likely be ignored by standardized data anlysis processes. - The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** - group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any + The NeXus ':'ref':'`NXbeam` base class may be added as a subgroup of this **NXinstrument** + group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any point downstream from the source. (NXaperture): - doc: | - :ref:`NXaperture` is generic and limits the variation in data files. + exists: ['min', '0'] + doc: | + ':'ref':'`NXaperture` is generic and limits the variation in data files. - Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. + Possible NeXus base class alternatives are':' ':'ref':'`NXpinhole` or ':'ref':'`NXslit`. \@canSAS_class: doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASaperture` + Official canSAS group':' ':'index':'`NXcanSAS (applications); SASaperture` enumeration: [SASaperture] shape: - doc: | + doc: | describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) x_gap(NX_NUMBER): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] doc: | - opening along the :math:`x` axis + opening along the ':'math':'`x` axis y_gap(NX_NUMBER): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] doc: | - opening along the :math:`y` axis + opening along the ':'math':'`y` axis (NXcollimator): + exists: ['min', '0'] \@canSAS_class: doc: | - Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` + Official canSAS group':' ':'index':'`NXcanSAS (applications); SAScollimation` enumeration: [SAScollimation] - doc: | + doc: | Description of a collimating element (defines the divergence of the beam) in the instrument. - To document a slit, pinhole, or the beam, refer to the + To document a slit, pinhole, or the beam, refer to the documentation of the ``NXinstrument`` group above. length(NX_NUMBER): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] doc: | Amount/length of collimation inserted (as on a SANS instrument) distance(NX_NUMBER): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] doc: | Distance from this collimation element to the sample (NXdetector): + exists: ['min', '0'] \@canSAS_class: doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASdetector` + Official canSAS group':' ':'index':'`NXcanSAS (applications); SASdetector` enumeration: [SASdetector] - doc: | + doc: | Description of a detector in the instrument. name: + exists: ['max', '1'] doc: | Identifies the name of this detector SDD(NX_NUMBER): - exists: [min, 0, max, 1] unit: NX_LENGTH - doc: | + exists: ['min', '0', 'max', '1'] + doc: | Distance between sample and detector. - Note: In NXdetector, the ``distance`` field records the + Note':' In NXdetector, the ``distance`` field records the distance to the previous component ... most often the sample. - This use is the same as ``SDD`` for most SAS - instruments but not all. For example, Bonse-Hart cameras + This use is the same as ``SDD`` for most SAS + instruments but not all. For example, Bonse-Hart cameras have one or more crystals between the sample and detector. - + We define here the field ``SDD`` to document without ambiguity the distance between sample and detector. slit_length(NX_NUMBER): - exists: [min, 0, max, 1] unit: NX_PER_LENGTH - doc: | - Slit length of the instrument for this detector, - expressed in the same units as :math:`Q`. + exists: ['min', '0', 'max', '1'] + doc: | + Slit length of the instrument for this detector, + expressed in the same units as ':'math':'`Q`. x_position(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_LENGTH doc: | - Location of the detector in :math:`x` + Location of the detector in ':'math':'`x` y_position(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_LENGTH doc: | - Location of the detector in :math:`y` + Location of the detector in ':'math':'`y` roll(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_ANGLE doc: | - Rotation of the detector about the :math:`z` axis (roll) + Rotation of the detector about the ':'math':'`z` axis (roll) pitch(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_ANGLE doc: | - Rotation of the detector about the :math:`x` axis (roll) + Rotation of the detector about the ':'math':'`x` axis (roll) yaw(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_ANGLE doc: | - Rotation of the detector about the :math:`y` axis (yaw) + Rotation of the detector about the ':'math':'`y` axis (yaw) beam_center_x(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH - doc: | + exists: ['min', '0', 'max', '1'] + doc: | Position of the beam center on the detector. This is the x position where the direct beam would hit the detector plane. @@ -727,9 +763,9 @@ NXcanSAS: as documented by the units attribute. The value can be any real number (positive, zero, or negative). beam_center_y(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH - doc: | + exists: ['min', '0', 'max', '1'] + doc: | Position of the beam center on the detector. This is the y position where the direct beam would hit the detector plane. @@ -738,217 +774,226 @@ NXcanSAS: as documented by the units attribute. The value can be any real number (positive, zero, or negative). x_pixel_size(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] doc: | Size of each detector pixel. If it is scalar all pixels are the same size y_pixel_size(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] doc: | Size of each detector pixel. If it is scalar all pixels are the same size (NXsource): + exists: ['min', '0'] \@canSAS_class: doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASsource` + Official canSAS group':' ':'index':'`NXcanSAS (applications); SASsource` enumeration: [SASsource] - doc: | + doc: | Description of the radiation source. radiation: - doc: | + exists: optional + deprecated: Use either (or both) ``probe`` or ``type`` fields from ``NXsource`` (issue #765) + doc: | Name of the radiation used. Note that this is **not** the name of the facility! - This field contains a value from either the - ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, + This field contains a value from either the + ``probe`` or ``type`` fields in ':'ref':'`NXsource`. Thus, it is redundant with existing NeXus structure. enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] beam_shape: - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Text description of the shape of the beam (incident on the sample). incident_wavelength(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_WAVELENGTH doc: | - wavelength (:math:`\lambda`) of radiation incident on the sample + wavelength (':'math':'`\lambda`) of radiation incident on the sample wavelength_min(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_WAVELENGTH - doc: | - Some facilities specify wavelength using a range. + doc: | + Some facilities specify wavelength using a range. This is the lowest wavelength in such a range. wavelength_max(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_WAVELENGTH - doc: | - Some facilities specify wavelength using a range. + doc: | + Some facilities specify wavelength using a range. This is the highest wavelength in such a range. incident_wavelength_spread(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_WAVELENGTH - doc: | - Some facilities specify wavelength using a range. + doc: | + Some facilities specify wavelength using a range. This is the width (FWHM) of such a range. beam_size_x(NX_NUMBER): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] doc: | Size of the incident beam along the x axis. beam_size_y(NX_NUMBER): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] doc: | Size of the incident beam along the y axis. (NXsample): + exists: ['min', '0'] \@canSAS_class: doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASsample` + Official canSAS group':' ':'index':'`NXcanSAS (applications); SASsample` enumeration: [SASsample] - doc: | + doc: | Description of the sample. name: + exists: ['max', '1'] doc: | - **ID**: Text string that identifies this sample. + **ID**':' Text string that identifies this sample. thickness(NX_FLOAT): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_LENGTH doc: | Thickness of this sample transmission(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_DIMENSIONLESS - doc: | - Transmission (:math:`I/I_0`) of this sample. + doc: | + Transmission (':'math':'`I/I_0`) of this sample. There is no *units* attribute as this number is dimensionless. - Note: the ability to store a transmission *spectrum*, - instead of a single value, is provided elsewhere in the structure, + Note':' the ability to store a transmission *spectrum*, + instead of a single value, is provided elsewhere in the structure, in the *SAStransmission_spectrum* element. temperature(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_TEMPERATURE doc: | Temperature of this sample. details: - exists: [min, 0, max, unbounded] + exists: ['min', '0', 'max', 'unbounded'] + nameType: any doc: | Any additional sample details. x_position(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_LENGTH doc: | - Location of the sample in :math:`x` + Location of the sample in ':'math':'`x` y_position(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_LENGTH doc: | - Location of the sample in :math:`y` + Location of the sample in ':'math':'`y` roll(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_ANGLE doc: | - Rotation of the sample about the :math:`z` axis (roll) + Rotation of the sample about the ':'math':'`z` axis (roll) pitch(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_ANGLE doc: | - Rotation of the sample about the :math:`x` axis (roll) + Rotation of the sample about the ':'math':'`x` axis (roll) yaw(NX_NUMBER): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] unit: NX_ANGLE doc: | - Rotation of the sample about the :math:`y` axis (yaw) + Rotation of the sample about the ':'math':'`y` axis (yaw) (NXprocess): - exists: [min, 0, max, unbounded] + exists: ['min', '0', 'max', 'unbounded'] \@canSAS_class: doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASprocess` + Official canSAS group':' ':'index':'`NXcanSAS (applications); SASprocess` enumeration: [SASprocess] - doc: | + doc: | Description of a processing or analysis step. - Add additional fields as needed to describe value(s) of any + Add additional fields as needed to describe value(s) of any variable, parameter, or term related to the *SASprocess* step. Be sure to include *units* attributes for all numerical fields. name: - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Optional name for this data processing or analysis step date(NX_DATE_TIME): - exists: [min, 0, max, 1] - doc: | + exists: ['min', '0', 'max', '1'] + doc: | Optional date for this data processing or analysis step. [#iso8601]_ .. [#iso8601] ISO-8601 standard time representation. - NeXus dates and times are reported in ISO-8601 - (e.g., ``yyyy-mm-ddThh:mm:ss``) - or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). - - See: http://www.w3.org/TR/NOTE-datetime - or http://en.wikipedia.org/wiki/ISO_8601 for more details. + NeXus dates and times are reported in ISO-8601 + (e.g., ``yyyy-mm-ddThh':'mm':'ss``) + or modified ISO-8601 (e.g., ``yyyy-mm-dd hh':'mm':'ss``). + + See':' http':'//www.w3.org/TR/NOTE-datetime + or http':'//en.wikipedia.org/wiki/ISO_8601 for more details. description: - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Optional description for this data processing or analysis step term: - exists: [min, 0, max, unbounded] - doc: | - Specifies the value of a single variable, parameter, - or term (while defined here as a string, it could be a number) + exists: ['min', '0', 'max', 'unbounded'] + nameType: any + doc: | + Specifies the value of a single variable, parameter, + or term (while defined here as a string, it could be a number) related to the *SASprocess* step. - Note: + Note':' The name *term* is not required, it could take any name, as long as the name is unique within this group. (NXnote): - exists: [min, 0, max, unbounded] - doc: | + exists: ['min', '0', 'max', 'unbounded'] + doc: | Any additional notes or subprocessing steps will be documented here. - An **NXnote** group can be added to any NeXus group at or below the - **NXentry** group. It is shown here as a suggestion of a good place + An **NXnote** group can be added to any NeXus group at or below the + **NXentry** group. It is shown here as a suggestion of a good place to *consider* its use. (NXcollection): - exists: [min, 0, max, unbounded] - doc: | + exists: ['min', '0', 'max', 'unbounded'] + doc: | Describes anything about *SASprocess* that is not already described. Any content not defined in the canSAS standard can be placed at this point. - Note: + Note':' The name of this group is flexible, it could take any name, as long as it is unique within the **NXprocess** group. \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` + doc: | + Official canSAS group':' ':'index':'`NXcanSAS (applications); SASprocessnote` enumeration: [SASprocessnote] (NXcollection): - exists: [min, 0, max, unbounded] + exists: ['min', '0', 'max', 'unbounded'] \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASnote` + doc: | + Official canSAS group':' ':'index':'`NXcanSAS (applications); SASnote` enumeration: [SASnote] - doc: | + doc: | Free form description of anything not covered by other elements. TRANSMISSION_SPECTRUM(NXdata): - doc: | + exists: ['min', '0'] + doc: | The *SAStransmission_spectrum* element This describes certain data obtained from a variable-wavelength source such as pulsed-neutron source. - The name of each *SAStransmission_spectrum* group must be unique within a SASentry group. + The name of each *SAStransmission_spectrum* group must be unique within a SASentry group. Suggest using names such as ``sastransmission_spectrum01``. \@canSAS_class: doc: | - Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` + Official canSAS group':' ':'index':'`NXcanSAS (applications); SAStransmission_spectrum` enumeration: [SAStransmission_spectrum] \@signal: - doc: | + type: NX_CHAR + doc: | Name of the default data field. enumeration: T: @@ -960,9 +1005,9 @@ NXcanSAS: doc: | the wavelengths field (as a dimension scale) corresponding to this transmission \@name: - doc: | + doc: | Identify what type of spectrum is being described. - It is expected that this value will take either of these two values: + It is expected that this value will take either of these two values':' ====== ============================================== value meaning @@ -971,44 +1016,46 @@ NXcanSAS: can measurement with just the container ====== ============================================== \@timestamp: - doc: | + type: NX_DATE_TIME + exists: optional + doc: | ISO-8601 time [#iso8601]_ lambda(NX_NUMBER): unit: NX_WAVELENGTH - doc: | + doc: | Wavelength of the radiation. This array is of the same shape as ``T`` and ``Tdev``. T(NX_NUMBER): unit: NX_DIMENSIONLESS - doc: | - Transmission values (:math:`I/I_0`) + doc: | + Transmission values (':'math':'`I/I_0`) as a function of wavelength. This array is of the same shape as ``lambda`` and ``Tdev``. \@uncertainties: - doc: | - Names the dataset (in this SASdata group) that provides the - uncertainty of each transmission :math:`T` to be used for data analysis. - The name of the dataset containing the :math:`T` uncertainty + doc: | + Names the dataset (in this SASdata group) that provides the + uncertainty of each transmission ':'math':'`T` to be used for data analysis. + The name of the dataset containing the ':'math':'`T` uncertainty is expected to be ``Tdev``. .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 + see':' https':'//github.com/canSAS-org/canSAS2012/issues/7 - Typically: + Typically':' - @uncertainties="Tdev" + @uncertainties="Tdev" Tdev(NX_NUMBER): unit: NX_DIMENSIONLESS - doc: | - .. index:: NXcanSAS (applications); Tdev + doc: | + .. index':'':' NXcanSAS (applications); Tdev Estimated uncertainty (usually standard deviation) - in :math:`T`. Must have the same units as :math:`T`. - - This is the field is named in the *uncertainties* attribute of *T*, as in:: + in ':'math':'`T`. Must have the same units as ':'math':'`T`. - T/@uncertainties="Tdev" + This is the field is named in the *uncertainties* attribute of *T*, as in':'':' + T/@uncertainties="Tdev" + This array is of the same shape as ``lambda`` and ``T``. diff --git a/applications/nyaml/NXdirecttof.yaml b/applications/nyaml/NXdirecttof.yaml index 372ff87e9f..b460187d81 100644 --- a/applications/nyaml/NXdirecttof.yaml +++ b/applications/nyaml/NXdirecttof.yaml @@ -1,8 +1,10 @@ +category: application doc: | This is a application definition for raw data from a direct geometry TOF spectrometer -category: application + +type: group NXdirecttof(NXtofraw): - entry(NXentry): + (NXentry)entry: title: start_time(NX_DATE_TIME): definition: @@ -10,7 +12,8 @@ NXdirecttof(NXtofraw): Official NeXus NXDL schema to which this file conforms enumeration: [NXdirecttof] (NXinstrument): - fermi_chopper(NXfermi_chopper): + (NXfermi_chopper)fermi_chopper: + exists: ['min', '0'] rotation_speed(NX_FLOAT): unit: NX_FREQUENCY doc: | @@ -19,7 +22,8 @@ NXdirecttof(NXtofraw): unit: NX_ENERGY doc: | energy selected - disk_chopper(NXdisk_chopper): + (NXdisk_chopper)disk_chopper: + exists: ['min', '0'] rotation_speed(NX_FLOAT): unit: NX_FREQUENCY doc: | @@ -28,6 +32,6 @@ NXdirecttof(NXtofraw): unit: NX_ENERGY doc: | energy selected - doc: | - We definitly want the rotation_speed and energy of the chopper. Thus either + doc: | + We definitly want the rotation_speed and energy of the chopper. Thus either a fermi_chopper or a disk_chopper group is required. diff --git a/applications/nyaml/NXfluo.yaml b/applications/nyaml/NXfluo.yaml index c0aab01e47..7022988c8f 100644 --- a/applications/nyaml/NXfluo.yaml +++ b/applications/nyaml/NXfluo.yaml @@ -1,19 +1,21 @@ -doc: | +category: application +doc: | This is an application definition for raw data from an X-ray fluorescence experiment + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nE: | - Number of energies + nE: | + Number of energies -category: application -NXfluo: - entry(NXentry): +type: group +NXfluo(NXobject): + (NXentry)entry: title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms. enumeration: [NXfluo] (NXinstrument): @@ -22,10 +24,12 @@ NXfluo: name: probe: enumeration: [x-ray] - monochromator(NXmonochromator): + (NXmonochromator)monochromator: wavelength(NX_FLOAT): - fluorescence(NXdetector): + (NXdetector)fluorescence: data(NX_INT): + axes: energy + signal: 1 dimensions: rank: 1 dim: [[1, nE]] @@ -39,7 +43,7 @@ NXfluo: Descriptive name of sample (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -47,4 +51,8 @@ NXfluo: doc: | preset value for time or monitor data(NX_INT): - data(NXdata): + (NXdata)data: + energy(link): + target: /entry/instrument/fluorescence/energy + data(link): + target: /entry/instrument/fluorescence/data diff --git a/applications/nyaml/NXindirecttof.yaml b/applications/nyaml/NXindirecttof.yaml index cfd75cba61..5b64d4a641 100644 --- a/applications/nyaml/NXindirecttof.yaml +++ b/applications/nyaml/NXindirecttof.yaml @@ -1,15 +1,17 @@ +category: application doc: | This is a application definition for raw data from a direct geometry TOF spectrometer + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: | - Number of detectors + nDet: | + Number of detectors -category: application +type: group NXindirecttof(NXtofraw): - entry(NXentry): + (NXentry)entry: title: start_time(NX_DATE_TIME): definition: @@ -17,7 +19,7 @@ NXindirecttof(NXtofraw): Official NeXus NXDL schema to which this file conforms enumeration: [NXindirecttof] (NXinstrument): - analyser(NXmonochromator): + (NXmonochromator)analyser: energy(NX_FLOAT): unit: NX_ENERGY doc: | diff --git a/applications/nyaml/NXiqproc.yaml b/applications/nyaml/NXiqproc.yaml index 84cd45981c..0ac4fc5ca4 100644 --- a/applications/nyaml/NXiqproc.yaml +++ b/applications/nyaml/NXiqproc.yaml @@ -1,20 +1,22 @@ +category: application doc: | - Application definition for any :math:`I(Q)` data. + Application definition for any ':'math':'`I(Q)` data. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nVars: | - The number of values taken by the varied variable + nVars: | + The number of values taken by the varied variable - nQX: | - Number of values for the first dimension of Q + nQX: | + Number of values for the first dimension of Q - nQY: | - Number of values for the second dimension of Q + nQY: | + Number of values for the second dimension of Q -category: application -NXiqproc: +type: group +NXiqproc(NXobject): (NXentry): \@entry: title: @@ -22,7 +24,7 @@ NXiqproc: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXiqproc] - instrument(NXinstrument): + (NXinstrument)instrument: (NXsource): type: name: @@ -35,21 +37,22 @@ NXiqproc: name: doc: | Descriptive name of sample - reduction(NXprocess): + (NXprocess)reduction: program(NX_CHAR): version(NX_CHAR): - input(NXparameters): + (NXparameters)input: filenames(NX_CHAR): doc: | Raw data files used to generate this I(Q) doc: | Input parameters for the reduction program used - output(NXparameters): + (NXparameters)output: doc: | Eventual output parameters from the data reduction program used (NXdata): data(NX_INT): - doc: | + signal: 1 + doc: | This is I(Q). The client has to analyse the dimensions of I(Q). Often, multiple I(Q) for various environment conditions are measured; that would be the first @@ -59,6 +62,7 @@ NXiqproc: rank: 3 dim: [[1, nVars], [2, nQX], [3, nQY]] variable(NX_NUMBER): + axis: 1 dimensions: rank: 1 dim: [[1, nVars]] @@ -66,12 +70,14 @@ NXiqproc: doc: | The real name of the varied variable in the first dim of data, temperature, P, MF etc... qx(NX_NUMBER): + axis: 2 doc: | Values for the first dimension of Q dimensions: rank: 1 dim: [[1, nQX]] qy(NX_NUMBER): + axis: 3 doc: | Values for the second dimension of Q dimensions: diff --git a/applications/nyaml/NXlauetof.yaml b/applications/nyaml/NXlauetof.yaml index 62095cfa88..5282cb6b89 100644 --- a/applications/nyaml/NXlauetof.yaml +++ b/applications/nyaml/NXlauetof.yaml @@ -1,28 +1,30 @@ -doc: | +category: application +doc: | This is the application definition for a TOF laue diffractometer + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nXPixels: | - Number of X pixels + nXPixels: | + Number of X pixels - nYPixels: | - Number of Y pixels + nYPixels: | + Number of Y pixels - nTOF: | - Time of flight + nTOF: | + Time of flight -category: application -NXlauetof: - entry(NXentry): +type: group +NXlauetof(NXobject): + (NXentry)entry: definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXlauetof] - instrument(NXinstrument): - detector(NXdetector): - doc: | + (NXinstrument)instrument: + (NXdetector)detector: + doc: | This assumes a planar 2D detector. All angles and distances refer to the center of the detector. polar_angle(NX_FLOAT): @@ -34,10 +36,12 @@ NXlauetof: doc: | The azimuthal angle where the detector is placed. data(NX_INT): + signal: 1 dimensions: rank: 3 dim: [[1, nXPixels], [2, nYPixels], [3, nTOF]] \@signal: + type: NX_POSINT enumeration: [1] x_pixel_size(NX_FLOAT): unit: NX_LENGTH @@ -50,12 +54,12 @@ NXlauetof: dimensions: rank: 1 dim: [[1, nTOF]] - sample(NXsample): + (NXsample)sample: name: doc: | Descriptive name of sample orientation_matrix(NX_FLOAT): - doc: | + doc: | The orientation matrix according to Busing and Levy conventions. This is not strictly necessary as the UB can always be derived from the data. But @@ -65,17 +69,17 @@ NXlauetof: rank: 2 dim: [[1, 3], [2, 3]] unit_cell(NX_FLOAT): - doc: | + doc: | The unit cell, a, b, c, alpha, beta, gamma. Again, not strictly necessary, but normally written. dimensions: rank: 1 dim: [[1, 6]] - control(NXmonitor): + (NXmonitor)control: mode: doc: | Count to a preset value based on either clock time (timer) or received monitor counts - (monitor). + (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): doc: | @@ -91,4 +95,8 @@ NXlauetof: dimensions: rank: 1 dim: [[1, nTOF]] - name(NXdata): + (NXdata)name: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight diff --git a/applications/nyaml/NXmonopd.yaml b/applications/nyaml/NXmonopd.yaml index e0a6351566..894635bd2c 100644 --- a/applications/nyaml/NXmonopd.yaml +++ b/applications/nyaml/NXmonopd.yaml @@ -1,24 +1,26 @@ -doc: | - Monochromatic Neutron and X-Ray Powder diffractometer +category: application +doc: | + Monochromatic Neutron and X-Ray Powder diffractometer - Instrument - definition for a powder diffractometer at a monochromatic neutron - or X-ray beam. This is both suited for a powder diffractometer - with a single detector or a powder diffractometer with a position + Instrument + definition for a powder diffractometer at a monochromatic neutron + or X-ray beam. This is both suited for a powder diffractometer + with a single detector or a powder diffractometer with a position sensitive detector. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - i: | - i is the number of wavelengths + i: | + i is the number of wavelengths - nDet: | - Number of detectors + nDet: | + Number of detectors -category: application -NXmonopd: - entry(NXentry): +type: group +NXmonopd(NXobject): + (NXentry)entry: title: start_time(NX_DATE_TIME): definition: @@ -41,11 +43,13 @@ NXmonopd: dim: [[1, i]] (NXdetector): polar_angle(NX_FLOAT): + axis: 1 dimensions: rank: 1 dim: [[1, nDet]] data(NX_INT): - doc: | + signal: 1 + doc: | detector signal (usually counts) are already corrected for detector efficiency dimensions: @@ -57,14 +61,14 @@ NXmonopd: Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder diagram - has been obtained through an omega-2theta scan like from a + doc: | + Optional rotation angle for the case when the powder diagram + has been obtained through an omega-2theta scan like from a traditional single detector powder diffractometer (NXmonitor): mode: - doc: | - Count to a preset value based on either clock time (timer) + doc: | + Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): @@ -75,7 +79,11 @@ NXmonopd: doc: | Total integral monitor counts (NXdata): + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle doc: | Link to polar angle in /NXentry/NXinstrument/NXdetector + data(link): + target: /NXentry/NXinstrument/NXdetector/data doc: | Link to data in /NXentry/NXinstrument/NXdetector diff --git a/applications/nyaml/NXmx.yaml b/applications/nyaml/NXmx.yaml index 30e4f904f4..19adb459c3 100644 --- a/applications/nyaml/NXmx.yaml +++ b/applications/nyaml/NXmx.yaml @@ -1,58 +1,63 @@ -doc: | +category: application +doc: | functional application definition for macromolecular crystallography + symbols: - doc: | - These symbols will be used below to coordinate datasets - with the same shape. Most MX x-ray detectors will produce - two-dimensional images. Some will produce three-dimensional - images, using one of the indices to select a detector module. + doc: | + These symbols will be used below to coordinate datasets + with the same shape. Most MX x-ray detectors will produce + two-dimensional images. Some will produce three-dimensional + images, using one of the indices to select a detector module. - dataRank: | - Rank of the ``data`` field + dataRank: | + Rank of the ``data`` field - nP: | - Number of scan points + nP: | + Number of scan points - i: | - Number of detector pixels in the slowest direction + i: | + Number of detector pixels in the slowest direction - j: | - Number of detector pixels in the second slowest direction + j: | + Number of detector pixels in the second slowest direction - k: | - Number of detector pixels in the third slowest direction + k: | + Number of detector pixels in the third slowest direction - m: | - Number of channels in the incident beam spectrum, if known + m: | + Number of channels in the incident beam spectrum, if known - groupIndex: | - An array of the hierarchical levels of the parents of detector - elements or groupings of detector elements. - A top-level element or grouping has parent level -1. + groupIndex: | + An array of the hierarchical levels of the parents of detector + elements or groupings of detector elements. + A top-level element or grouping has parent level -1. -category: application -NXmx: +type: group +NXmx(NXobject): (NXentry): - doc: | + doc: | Note, it is recommended that ``file_name`` and ``file_time`` are included - as attributes at the root of a file that includes :ref:`NXmx`. See - :ref:`NXroot`. + as attributes at the root of a file that includes ':'ref':'`NXmx`. See + ':'ref':'`NXroot`. \@version: - doc: | + exists: optional + doc: | Describes the version of the NXmx definition used to write this data. - This must be a text (not numerical) representation. Such as:: + This must be a text (not numerical) representation. Such as':'':' @version="1.0" enumeration: [1.0] title(NX_CHAR): + exists: ['min', '0'] start_time(NX_DATE_TIME): - doc: | + doc: | ISO 8601 time/date of the first data point collected in UTC, using the Z suffix to avoid confusion with local time. Note that the time zone of the beamline should be provided in NXentry/NXinstrument/time_zone. end_time(NX_DATE_TIME): - doc: | + exists: ['min', '0'] + doc: | ISO 8601 time/date of the last data point collected in UTC, using the Z suffix to avoid confusion with local time. Note that the time zone of the beamline should be provided in @@ -61,7 +66,7 @@ NXmx: collection aborts or otherwise prevents accurate recording of the end_time, this field should be omitted. end_time_estimated(NX_DATE_TIME): - doc: | + doc: | ISO 8601 time/date of the last data point collected in UTC, using the Z suffix to avoid confusion with local time. Note that the time zone of the beamline should be provided in @@ -74,7 +79,7 @@ NXmx: (NXdata): data(NX_NUMBER): exists: recommended - doc: | + doc: | For a dimension-2 detector, the rank of the data array will be 3. For a dimension-3 detector, the rank of the data array will be 4. This allows for the introduction of the frame number as the @@ -87,7 +92,7 @@ NXmx: doc: | Descriptive name of sample depends_on(NX_CHAR): - doc: | + doc: | This is a requirement to describe for any scan experiment. The axis on which the sample position depends may be stored @@ -97,7 +102,8 @@ NXmx: If there is no goniometer, e.g. with a jet, depends_on should be set to "." (NXtransformations): - doc: | + exists: ['min', '0'] + doc: | This is the recommended location for sample goniometer and other related axes. @@ -113,29 +119,33 @@ NXmx: single shot exposures. temperature(NX_NUMBER): unit: NX_TEMPERATURE + exists: ['min', '0'] (NXinstrument): name(NX_CHAR): - exists: required - doc: | + exists: ['min', '1'] + doc: | Name of instrument. Consistency with the controlled vocabulary beamline naming in - https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html + https':'//mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html and - https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html + https':'//mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html is highly recommended. \@short_name: + exists: optional doc: | Short name for instrument, perhaps the acronym. time_zone(NX_DATE_TIME): exists: recommended - doc: | + doc: | ISO 8601 time_zone offset from UTC. (NXattenuator): + exists: ['min', '0'] attenuator_transmission(NX_NUMBER): unit: NX_UNITLESS + exists: ['min', '0'] (NXdetector_group): exists: recommended - doc: | + doc: | Optional logical grouping of detectors. Each detector is represented as an NXdetector @@ -153,22 +163,22 @@ NXmx: in the field group_index, and the level in the hierarchy given in the group_parent field. For example if an x-ray detector group, DET, consists of four detectors in a - rectangular array:: + rectangular array':'':' - DTL DTR - DLL DLR + DTL DTR + DLL DLR - We could have:: + We could have':'':' - group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] - group_index: [1, 2, 3, 4, 5] - group_parent: [-1, 1, 1, 1, 1] + group_names':' ["DET", "DTL", "DTR", "DLL", "DLR"] + group_index':' [1, 2, 3, 4, 5] + group_parent':' [-1, 1, 1, 1, 1] group_names(NX_CHAR): - doc: | + doc: | An array of the names of the detectors or the names of hierarchical groupings of detectors. group_index(NX_INT): - doc: | + doc: | An array of unique identifiers for detectors or groupings of detectors. @@ -179,7 +189,7 @@ NXmx: rank: 1 dim: [[1, i]] group_parent(NX_INT): - doc: | + doc: | An array of the hierarchical levels of the parents of detectors or groupings of detectors. @@ -188,28 +198,31 @@ NXmx: rank: 1 dim: [[1, groupIndex]] (NXdetector): - doc: | + doc: | Normally the detector group will have the name ``detector``. However, in the case of multiple detectors, each detector needs a uniquely named NXdetector. depends_on(NX_CHAR): - doc: | + exists: ['min', '0'] + doc: | NeXus path to the detector positioner axis that most directly supports the detector. In the case of a single-module detector, the detector axis chain may start here. (NXtransformations): - doc: | + exists: ['min', '0'] + doc: | Location for axes (transformations) to do with the detector. In the case of a single-module detector, the axes of the detector axis chain may be stored here. (NXcollection): - doc: | + exists: ['min', '0'] + doc: | Suggested container for detailed non-standard detector information like corrections applied automatically or performance settings. data(NX_NUMBER): exists: recommended - doc: | + doc: | For a dimension-2 detector, the rank of the data array will be 3. For a dimension-3 detector, the rank of the data array will be 4. This allows for the introduction of the frame number as the @@ -219,17 +232,18 @@ NXmx: dim: [[1, nP], [2, i], [3, j], [4, k]] description: exists: recommended - doc: | + doc: | name/manufacturer/model/etc. information. time_per_channel: unit: NX_TIME - doc: | + exists: ['min', '0'] + doc: | For a time-of-flight detector this is the scaling factor to convert from the numeric value reported to the flight time for a given measurement. (NXdetector_module): - exists: [min, 1, max, unbounded] - doc: | + exists: ['min', '1', 'max', 'unbounded'] + doc: | Many detectors consist of multiple smaller modules that are operated in sync and store their data in a common dataset. To allow consistent parsing of the experimental geometry, @@ -246,7 +260,7 @@ NXmx: Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. data_origin(NX_INT): - doc: | + doc: | A dimension-2 or dimension-3 field which gives the indices of the origin of the hyperslab of data for this module in the main area detector image in the parent NXdetector module. @@ -259,55 +273,63 @@ NXmx: dataset with indices (nP, i, j, k) will be an array with indices (i, j, k). - The :ref:`order ` of indices (i, j + The ':'ref':'`order ` of indices (i, j or i, j, k) is slow to fast. data_size(NX_INT): - doc: | + doc: | Two or three values for the size of the module in pixels in each direction. Dimensionality and order of indices is the same as for data_origin. data_stride(NX_INT): - doc: | + exists: ['min', '0'] + doc: | Two or three values for the stride of the module in pixels in each direction. By default the stride is [1,1] or [1,1,1], and this is the most likely case. This optional field is included for completeness. module_offset(NX_NUMBER): unit: NX_LENGTH - doc: | + exists: ['min', '0'] + doc: | Offset of the module in regards to the origin of the detector in an arbitrary direction. \@transformation_type: enumeration: [translation] \@vector: + type: NX_NUMBER \@offset: + type: NX_NUMBER \@depends_on: fast_pixel_direction(NX_NUMBER): unit: NX_LENGTH - doc: | - Values along the direction of :ref:`fastest varying ` + doc: | + Values along the direction of ':'ref':'`fastest varying ` pixel direction. The direction itself is given through the vector attribute. \@transformation_type: enumeration: [translation] \@vector: + type: NX_NUMBER \@offset: + type: NX_NUMBER \@depends_on: slow_pixel_direction(NX_NUMBER): unit: NX_LENGTH - doc: | - Values along the direction of :ref:`slowest varying ` + doc: | + Values along the direction of ':'ref':'`slowest varying ` pixel direction. The direction itself is given through the vector attribute. \@transformation_type: enumeration: [translation] \@vector: + type: NX_NUMBER \@offset: + type: NX_NUMBER \@depends_on: distance(NX_FLOAT): - exists: recommended unit: NX_LENGTH - doc: | + exists: recommended + doc: | Distance from the sample to the beam center. Normally this value is for guidance only, the proper geometry can be found following the depends_on axis chain, @@ -317,29 +339,31 @@ NXmx: calculation. distance_derived(NX_BOOLEAN): exists: recommended - doc: | + doc: | Boolean to indicate if the distance is a derived, rather than a primary observation. If distance_derived true or is not specified, the distance is assumed to be derived from detector axis specifications. dead_time(NX_FLOAT): unit: NX_TIME - doc: | + exists: ['min', '0'] + doc: | Detector dead time. count_time(NX_NUMBER): - exists: recommended unit: NX_TIME - doc: | + exists: recommended + doc: | Elapsed actual counting time. beam_center_derived(NX_BOOLEAN): - doc: | + exists: optional + doc: | Boolean to indicate if the distance is a derived, rather than a primary observation. If true or not provided, that value of beam_center_derived is assumed to be true. beam_center_x(NX_FLOAT): - exists: recommended unit: NX_LENGTH - doc: | + exists: recommended + doc: | This is the x position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as @@ -347,9 +371,9 @@ NXmx: be derived from the axis chain, but the direct specification may take precedence if it is not a derived quantity. beam_center_y(NX_FLOAT): - exists: recommended unit: NX_LENGTH - doc: | + exists: recommended + doc: | This is the y position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as @@ -357,29 +381,33 @@ NXmx: be derived from the axis chain, but the direct specification may take precedence if it is not a derived quantity. angular_calibration_applied(NX_BOOLEAN): - doc: | + exists: ['min', '0'] + doc: | True when the angular calibration has been applied in the electronics, false otherwise. angular_calibration(NX_FLOAT): + exists: ['min', '0'] doc: | Angular calibration data. dimensions: rank: dataRank dim: [[1, i], [2, j], [3, k]] flatfield_applied(NX_BOOLEAN): - doc: | + exists: ['min', '0'] + doc: | True when the flat field correction has been applied in the electronics, false otherwise. flatfield(NX_NUMBER): - doc: | + exists: ['min', '0'] + doc: | Flat field correction data. If provided, it is recommended that it be compressed. dimensions: rank: dataRank dim: [[1, i], [2, j], [3, k]] flatfield_error(NX_NUMBER): - exists: [min, 0, max, 0] - doc: | + exists: ['min', '0', 'max', '0'] + doc: | *** Deprecated form. Use plural form *** Errors of the flat field correction data. If provided, it is recommended that it be compressed. @@ -387,19 +415,21 @@ NXmx: rank: dataRank dim: [[1, i], [2, j], [3, k]] flatfield_errors(NX_NUMBER): - doc: | + exists: ['min', '0'] + doc: | Errors of the flat field correction data. If provided, it is recommended that it be compressed. dimensions: rank: dataRank dim: [[1, i], [2, j], [3, k]] pixel_mask_applied(NX_BOOLEAN): - doc: | + exists: ['min', '0'] + doc: | True when the pixel mask correction has been applied in the electronics, false otherwise. pixel_mask(NX_INT): exists: recommended - doc: | + doc: | The 32-bit pixel mask for the detector. Can be either one mask for the whole dataset (i.e. an array with indices i, j) or each frame can have its own mask (in which case it would be @@ -407,19 +437,19 @@ NXmx: Contains a bit field for each pixel to signal dead, blind, high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under-responding - * bit 3: over-responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) + They have the following meaning':' + + * bit 0':' gap (pixel with no sensor) + * bit 1':' dead + * bit 2':' under-responding + * bit 3':' over-responding + * bit 4':' noisy + * bit 5':' -undefined- + * bit 6':' pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7':' -undefined- + * bit 8':' user defined mask (e.g. around beamstop) + * bits 9-30':' -undefined- + * bit 31':' virtual pixel (corner pixel with interpolated value) Normal data analysis software would not take pixels into account when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper @@ -444,24 +474,26 @@ NXmx: rank: 2 dim: [[1, i], [2, j]] countrate_correction_applied(NX_BOOLEAN): - doc: | + exists: ['min', '0'] + doc: | Counting detectors usually are not able to measure all incoming particles, especially at higher count-rates. Count-rate correction is applied to account for these errors. True when count-rate correction has been applied, false otherwise. countrate_correction_lookup_table(NX_NUMBER): - doc: | + doc: | The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. + correction. It maps a measured count ':'math':'`c` to its corrected value + ':'math':'`countrate\_correction\_lookup\_table[c]`. - :math:`m` denotes the length of the table. + ':'math':'`m` denotes the length of the table. dimensions: rank: 1 dim: [[1, m]] virtual_pixel_interpolation_applied(NX_BOOLEAN): - doc: | + exists: ['min', '0'] + doc: | True when virtual pixel interpolation has been applied, false otherwise. When virtual pixel interpolation is applied, values of some pixels may @@ -471,27 +503,30 @@ NXmx: their logical pixels. bit_depth_readout(NX_INT): exists: recommended - doc: | + doc: | How many bits the electronics record per pixel. detector_readout_time(NX_FLOAT): unit: NX_TIME - doc: | + exists: ['min', '0'] + doc: | Time it takes to read the detector (typically milliseconds). This is important to know for time resolved experiments. frame_time(NX_FLOAT): unit: NX_TIME - doc: | + exists: ['min', '0'] + doc: | This is time for each frame. This is exposure_time + readout time. gain_setting(NX_CHAR): - doc: | + exists: ['min', '0'] + doc: | The gain setting of the detector. This influences background. This is a detector-specific value meant to document the gain setting of the detector during data collection, for detectors with multiple available gain settings. - Examples of gain settings include: + Examples of gain settings include':' * ``standard`` * ``fast`` @@ -505,7 +540,8 @@ NXmx: Developers are encouraged to use one of these terms, or to submit additional terms to add to the list. saturation_value(NX_NUMBER): - doc: | + exists: ['min', '0'] + doc: | The value at which the detector goes into saturation. Data above this value is known to be invalid. @@ -513,7 +549,8 @@ NXmx: the valid pixels are those less than or equal to the saturation_value and greater than or equal to the underload_value. underload_value(NX_NUMBER): - doc: | + exists: ['min', '0'] + doc: | The lowest value at which pixels for this detector would be reasonably be measured. @@ -521,45 +558,48 @@ NXmx: the valid pixels are those less than or equal to the saturation_value and greater than or equal to the underload_value. sensor_material(NX_CHAR): - exists: required - doc: | + exists: ['min', '1'] + doc: | At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. This is the name of this converter material. sensor_thickness(NX_FLOAT): - exists: required unit: NX_LENGTH - doc: | + exists: ['min', '1'] + doc: | At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. This is the thickness of this converter material. threshold_energy(NX_FLOAT): unit: NX_ENERGY - doc: | + exists: ['min', '0'] + doc: | Single photon counter detectors can be adjusted for a certain energy range in which they work optimally. This is the energy setting for this. If the detector supports multiple thresholds, this is an array. type: - doc: | + exists: ['min', '0'] + doc: | Description of type such as scintillator, ccd, pixel, image plate, CMOS, ... (NXbeam): - exists: required + exists: ['min', '1'] \@flux: - doc: | + exists: optional + doc: | Which field contains the measured flux. One of ``flux``, ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. Alternatively, the name being indicated could be a link to a dataset in an NXmonitor group that records per shot beam data. incident_wavelength(NX_FLOAT): - exists: required unit: NX_WAVELENGTH - doc: | + exists: ['min', '1'] + doc: | In the case of a monchromatic beam this is the scalar wavelength. @@ -586,13 +626,15 @@ NXmx: relative weights in ``incident_wavelength_weights`` as a 2D array. - Note, :ref:`variants ` are a good way + Note, ':'ref':'`variants ` are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value wavelength value is available along with the original spectrum from which it was calibrated. incident_wavelength_weight(NX_FLOAT): - doc: | + exists: ['min', '0'] + deprecated: use incident_wavelength_weights, see https':'//github.com/nexusformat/definitions/issues/837 + doc: | In the case of a polychromatic beam this is an array of length **m** of the relative weights of the corresponding wavelengths in incident_wavelength. @@ -602,7 +644,8 @@ NXmx: (slow to fast) of the relative weights of the corresponding wavelengths in incident_wavelength. incident_wavelength_weights(NX_FLOAT): - doc: | + exists: ['min', '0'] + doc: | In the case of a polychromatic beam this is an array of length **m** of the relative weights of the corresponding wavelengths in ``incident_wavelength``. @@ -613,7 +656,8 @@ NXmx: corresponding wavelengths in ``incident_wavelength``. incident_wavelength_spread(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + exists: ['min', '0'] + doc: | The wavelength spread FWHM for the corresponding wavelength(s) in incident_wavelength. @@ -622,9 +666,11 @@ NXmx: **m** (slow to fast) of the spreads of the corresponding wavelengths in incident_wavelength. incident_wavelength_spectrum(NXdata): + exists: ['min', '0'] flux(NX_FLOAT): unit: NX_FLUX - doc: | + exists: ['min', '0'] + doc: | Flux density incident on beam plane area in photons per second per unit area. @@ -632,9 +678,10 @@ NXmx: this is an array of values, one for each recorded shot. total_flux(NX_FLOAT): unit: NX_FREQUENCY - doc: | + exists: ['min', '0'] + doc: | Flux incident on beam plane in photons per second. In other words - this is the :ref:`flux ` integrated + this is the ':'ref':'`flux ` integrated over area. Useful where spatial beam profiles are not known. @@ -643,9 +690,10 @@ NXmx: this is an array of values, one for each recorded shot. flux_integrated(NX_FLOAT): unit: NX_PER_AREA - doc: | + exists: ['min', '0'] + doc: | Flux density incident on beam plane area in photons - per unit area. In other words this is the :ref:`flux ` + per unit area. In other words this is the ':'ref':'`flux ` integrated over time. Useful where temporal beam profiles of flux are not known. @@ -654,8 +702,9 @@ NXmx: this is an array of values, one for each recorded shot. total_flux_integrated(NX_FLOAT): unit: NX_DIMENSIONLESS - doc: | - Flux incident on beam plane in photons. In other words this is the :ref:`flux ` + exists: ['min', '0'] + doc: | + Flux incident on beam plane in photons. In other words this is the ':'ref':'`flux ` integrated over time and area. Useful where temporal beam profiles of flux are not known. @@ -663,9 +712,9 @@ NXmx: In the case of a beam that varies in total flux shot-to-shot, this is an array of values, one for each recorded shot. incident_beam_size(NX_FLOAT): - exists: recommended unit: NX_LENGTH - doc: | + exists: recommended + doc: | Two-element array of FWHM (if Gaussian or Airy function) or diameters (if top hat) or widths (if rectangular) of the beam in the order x, y @@ -674,13 +723,15 @@ NXmx: dim: [[1, 2]] profile(NX_CHAR): exists: recommended - doc: | + doc: | The beam profile, Gaussian, Airy function, top-hat or rectangular. The profile is given in the plane of incidence of the beam on the sample. enumeration: [Gaussian, Airy, top-hat, rectangular] incident_polarisation_stokes(NX_NUMBER): - doc: | + exists: optional + deprecated: use incident_polarization_stokes, see https':'//github.com/nexusformat/definitions/issues/708 + doc: | Polarization vector on entering beamline component using Stokes notation dimensions: @@ -688,23 +739,24 @@ NXmx: dim: [[1, nP], [2, 4]] incident_polarization_stokes(NX_NUMBER): exists: recommended - doc: | + doc: | Polarization vector on entering beamline component using Stokes notation. See - incident_polarization_stokes in :ref:`NXbeam` + incident_polarization_stokes in ':'ref':'`NXbeam` dimensions: rank: 2 dim: [[1, nP], [2, 4]] (NXsource): - doc: | + doc: | The neutron or x-ray storage ring/facility. Note, the NXsource base class has many more fields available, but at present we only require the name. name: - exists: required - doc: | + exists: ['min', '1'] + doc: | Name of source. Consistency with the naming in - https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html + https':'//mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html controlled vocabulary is highly recommended. \@short_name: + exists: optional doc: | short name for source, perhaps the acronym diff --git a/applications/nyaml/NXrefscan.yaml b/applications/nyaml/NXrefscan.yaml index 5c3bfc11b0..55bff29970 100644 --- a/applications/nyaml/NXrefscan.yaml +++ b/applications/nyaml/NXrefscan.yaml @@ -1,18 +1,20 @@ -doc: | +category: application +doc: | This is an application definition for a monochromatic scanning reflectometer. It does not have the information to calculate the resolution since it does not have any apertures. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points -category: application -NXrefscan: - entry(NXentry): +type: group +NXrefscan(NXobject): + (NXentry)entry: title: start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): @@ -20,26 +22,28 @@ NXrefscan: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXrefscan] - instrument(NXinstrument): + (NXinstrument)instrument: (NXsource): type: name: probe: enumeration: [neutron, x-ray, electron] - monochromator(NXmonochromator): + (NXmonochromator)monochromator: wavelength(NX_FLOAT): unit: NX_WAVELENGTH (NXdetector): data(NX_INT): + signal: 1 dimensions: rank: 1 dim: [[1, nP]] polar_angle(NX_FLOAT): unit: NX_ANGLE + axis: 1 dimensions: rank: 1 dim: [[1, nP]] - sample(NXsample): + (NXsample)sample: name: doc: | Descriptive name of sample @@ -48,9 +52,9 @@ NXrefscan: dimensions: rank: 1 dim: [[1, nP]] - control(NXmonitor): + (NXmonitor)control: mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -64,4 +68,10 @@ NXrefscan: dimensions: rank: 1 dim: [[1, nP]] - data(NXdata): + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle diff --git a/applications/nyaml/NXreftof.yaml b/applications/nyaml/NXreftof.yaml index 7c30a104b6..792aa1fbb9 100644 --- a/applications/nyaml/NXreftof.yaml +++ b/applications/nyaml/NXreftof.yaml @@ -1,21 +1,23 @@ +category: application doc: | This is an application definition for raw data from a TOF reflectometer. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - xSize: | - xSize description + xSize: | + xSize description - ySize: | - ySize description + ySize: | + ySize description - nTOF: | - nTOF description + nTOF: | + nTOF description -category: application -NXreftof: - entry(NXentry): +type: group +NXreftof(NXobject): + (NXentry)entry: title: start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): @@ -23,21 +25,23 @@ NXreftof: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXreftof] - instrument(NXinstrument): + (NXinstrument)instrument: name(NX_CHAR): - chopper(NXdisk_chopper): + (NXdisk_chopper)chopper: distance(NX_FLOAT): unit: NX_LENGTH doc: | Distance between chopper and sample - detector(NXdetector): + (NXdetector)detector: data(NX_INT): + signal: 1 dimensions: rank: 3 dim: [[1, xSize], [2, ySize], [3, nTOF]] time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT - doc: | + axis: 3 + doc: | Array of time values for each bin in a time-of-flight measurement dimensions: @@ -51,15 +55,15 @@ NXreftof: unit: NX_LENGTH y_pixel_size(NX_FLOAT): unit: NX_LENGTH - sample(NXsample): + (NXsample)sample: name: doc: | Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE - control(NXmonitor): + (NXmonitor)control: mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -72,9 +76,15 @@ NXreftof: Total integral monitor counts time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT + axis: 1 doc: | Time channels data(NX_INT): + signal: 1 doc: | Monitor counts in each time channel - data(NXdata): + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight diff --git a/applications/nyaml/NXsas.yaml b/applications/nyaml/NXsas.yaml index 703938291e..acee101f71 100644 --- a/applications/nyaml/NXsas.yaml +++ b/applications/nyaml/NXsas.yaml @@ -1,4 +1,5 @@ -doc: | +category: application +doc: | Raw, monochromatic 2-D SAS data with an area detector. This is an application definition for raw data (not processed or reduced data) @@ -7,26 +8,30 @@ doc: | and X-ray SAXS data. It covers all raw data from any monochromatic SAS techniques that - use an area detector: SAS, WSAS, grazing incidence, GISAS + use an area detector':' SAS, WSAS, grazing incidence, GISAS It covers all raw data from any SAS techniques that use an area detector and a monochromatic beam. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate fields with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate fields with the same shape. - nXPixel: | - Number of pixels in x direction. + nXPixel: | + Number of pixels in x direction. - nYPixel: | - Number of pixels in y direction. + nYPixel: | + Number of pixels in y direction. -category: application -NXsas: +type: group +NXsas(NXobject): (NXentry): title: + exists: ['min', '0'] start_time(NX_DATE_TIME): + exists: ['min', '0'] end_time(NX_DATE_TIME): + exists: ['min', '0'] definition: doc: | Official NeXus NXDL schema to which this file conforms. @@ -37,22 +42,25 @@ NXsas: doc: | Type of radiation source. name: + exists: ['min', '0'] doc: | Name of the radiation source. probe: - doc: | + doc: | Name of radiation probe, necessary to compute the sample contrast. enumeration: [neutron, x-ray] (NXmonochromator): wavelength(NX_FLOAT): unit: NX_WAVELENGTH doc: | - The wavelength (:math:`\lambda`) of the radiation. + The wavelength (':'math':'`\lambda`) of the radiation. wavelength_spread(NX_FLOAT): - doc: | - delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): + exists: ['min', '0'] + doc: | + delta_lambda/lambda (':'math':'`\Delta\lambda/\lambda`)':' Important for resolution calculations. (NXcollimator): + exists: ['min', '0'] (NXgeometry): (NXshape): shape(NX_CHAR): @@ -63,7 +71,7 @@ NXsas: The collimation length. (NXdetector): data(NX_NUMBER): - doc: | + doc: | This is area detector data, number of x-pixel versus number of y-pixels. @@ -90,15 +98,20 @@ NXsas: Physical size of a pixel in y-direction. polar_angle(NX_FLOAT): unit: NX_ANGLE + exists: ['min', '0'] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE + exists: ['min', '0'] rotation_angle(NX_FLOAT): unit: NX_ANGLE + exists: ['min', '0'] aequatorial_angle(NX_FLOAT): unit: NX_ANGLE + exists: ['min', '0'] beam_center_x(NX_FLOAT): unit: NX_LENGTH - doc: | + exists: ['min', '0'] + doc: | This is the x position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. @@ -108,7 +121,8 @@ NXsas: provide an initial or nominal value to advise data reduction. beam_center_y(NX_FLOAT): unit: NX_LENGTH - doc: | + exists: ['min', '0'] + doc: | This is the y position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. @@ -120,14 +134,17 @@ NXsas: doc: | Name of the instrument actually used to perform the experiment. (NXsample): + exists: ['min', '0'] name: doc: | Descriptive name of sample. aequatorial_angle(NX_FLOAT): unit: NX_ANGLE + exists: ['min', '0'] (NXmonitor): + exists: ['min', '0'] mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -140,7 +157,10 @@ NXsas: Total integral monitor counts. (NXdata): \@signal: - doc: | + exists: optional + doc: | Name the *plottable* field. The link here defines this name as ``data``. enumeration: [data] + data(link): + target: /NXentry/NXinstrument/NXdetector/data diff --git a/applications/nyaml/NXsastof.yaml b/applications/nyaml/NXsastof.yaml index 5b1ba08df2..09fd6dda0b 100644 --- a/applications/nyaml/NXsastof.yaml +++ b/applications/nyaml/NXsastof.yaml @@ -1,24 +1,26 @@ -doc: | +category: application +doc: | raw, 2-D SAS data with an area detector with a time-of-flight source It covers all raw data from any SAS techniques that use an area detector at a time-of-flight source. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nXPixel: | - nXPixel description + nXPixel: | + nXPixel description - nYPixel: | - nYPixel description + nYPixel: | + nYPixel description - nTOF: | - nTOF description + nTOF: | + nTOF description -category: application -NXsastof: +type: group +NXsastof(NXobject): (NXentry): \@entry: doc: | @@ -29,8 +31,8 @@ NXsastof: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXsastof] - instrument(NXinstrument): - source(NXsource): + (NXinstrument)instrument: + (NXsource)source: type: doc: | type of radiation source @@ -39,18 +41,19 @@ NXsastof: Name of the radiation source probe: enumeration: [neutron, x-ray] - collimator(NXcollimator): - geometry(NXgeometry): - shape(NXshape): + (NXcollimator)collimator: + (NXgeometry)geometry: + (NXshape)shape: shape(NX_CHAR): enumeration: [nxcylinder, nxbox] size(NX_FLOAT): unit: NX_LENGTH doc: | The collimation length - detector(NXdetector): + (NXdetector)detector: data(NX_NUMBER): - doc: | + signal: 1 + doc: | This is area detector data, of number of x-pixel versus number of y-pixels. Since the beam center is to be determined as a step of data reduction, it is not necessary @@ -86,24 +89,24 @@ NXsastof: unit: NX_ANGLE beam_center_x(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the x position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. beam_center_y(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the y position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. name(NX_CHAR): doc: | Name of the instrument actually used to perform the experiment - sample(NXsample): + (NXsample)sample: name: doc: | Descriptive name of sample aequatorial_angle(NX_FLOAT): unit: NX_ANGLE - control(NXmonitor): + (NXmonitor)control: mode: doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). @@ -112,6 +115,8 @@ NXsastof: doc: | preset value for time or monitor data(NX_INT): + primary: 1 + signal: 1 dimensions: rank: 1 dim: [[1, nTOF]] @@ -120,4 +125,8 @@ NXsastof: dimensions: rank: 1 dim: [[1, nTOF]] - data(NXdata): + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight diff --git a/applications/nyaml/NXscan.yaml b/applications/nyaml/NXscan.yaml index cc4a6d3a9e..978b9ee36b 100644 --- a/applications/nyaml/NXscan.yaml +++ b/applications/nyaml/NXscan.yaml @@ -1,43 +1,45 @@ -doc: | - Application definition for a generic scan instrument. +category: application +doc: | + Application definition for a generic scan instrument. - This definition is more an - example then a stringent definition as the content of a given NeXus scan file needs to - differ for different types of scans. This example definition shows a scan like done - on a rotation camera: the sample is rotated and a detector image, the rotation angle - and a monitor value is stored at each step in the scan. In the following, the symbol - ``NP`` is used to represent the number of scan points. These are the rules for - storing scan data in NeXus files which are implemented in this example: + This definition is more an + example then a stringent definition as the content of a given NeXus scan file needs to + differ for different types of scans. This example definition shows a scan like done + on a rotation camera':' the sample is rotated and a detector image, the rotation angle + and a monitor value is stored at each step in the scan. In the following, the symbol + ``NP`` is used to represent the number of scan points. These are the rules for + storing scan data in NeXus files which are implemented in this example':' - * Each value varied throughout a scan is stored as an array of - length ``NP`` at its respective location within the NeXus hierarchy. - * For area detectors, ``NP`` is the first dimension, - example for a detector of 256x256: ``data[NP,256,256]`` - * The NXdata group contains links to all variables varied in the scan and the data. - This to give an equivalent to the more familiar classical tabular representation of scans. + * Each value varied throughout a scan is stored as an array of + length ``NP`` at its respective location within the NeXus hierarchy. + * For area detectors, ``NP`` is the first dimension, + example for a detector of 256x256':' ``data[NP,256,256]`` + * The NXdata group contains links to all variables varied in the scan and the data. + This to give an equivalent to the more familiar classical tabular representation of scans. - These rules exist for a reason: HDF allows the first dimension of a data set to be - unlimited. This means the data can be appended too. Thus a NeXus file built according - to the rules given above can be used in the following way: + These rules exist for a reason':' HDF allows the first dimension of a data set to be + unlimited. This means the data can be appended too. Thus a NeXus file built according + to the rules given above can be used in the following way':' * At the start of a scan, write all the static information. - * At each scan point, append new data from varied variables - and the detector to the file. + * At each scan point, append new data from varied variables + and the detector to the file. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points - xDim: | - xDim description + xDim: | + xDim description - yDim: | - yDim description + yDim: | + yDim description -category: application -NXscan: +type: group +NXscan(NXobject): (NXentry): title: start_time(NX_DATE_TIME): @@ -49,11 +51,13 @@ NXscan: (NXinstrument): (NXdetector): data(NX_INT): + signal: 1 dimensions: rank: 3 dim: [[1, nP], [2, xDim], [3, yDim]] (NXsample): rotation_angle(NX_FLOAT): + axis: 1 dimensions: rank: 1 dim: [[1, nP]] @@ -63,3 +67,7 @@ NXscan: rank: 1 dim: [[1, nP]] (NXdata): + data(link): + target: /NXentry/NXinstrument/NXdetector/data + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle diff --git a/applications/nyaml/NXspe.yaml b/applications/nyaml/NXspe.yaml index eaab805a07..6ef8843c1f 100644 --- a/applications/nyaml/NXspe.yaml +++ b/applications/nyaml/NXspe.yaml @@ -1,7 +1,9 @@ +category: application doc: | NXSPE Inelastic Format. Application definition for NXSPE file format. -category: application -NXspe: + +type: group +NXspe(NXobject): (NXentry): program_name: definition: @@ -9,7 +11,7 @@ NXspe: Official NeXus NXDL schema to which this file conforms. \@version: enumeration: [NXspe] - NXSPE_info(NXcollection): + (NXcollection)NXSPE_info: fixed_energy(NX_FLOAT): unit: NX_ENERGY doc: | @@ -21,7 +23,7 @@ NXspe: unit: NX_ANGLE doc: | Orientation angle as expected in DCS-MSlice - data(NXdata): + (NXdata)data: azimuthal(NX_FLOAT): unit: NX_ANGLE azimuthal_width(NX_FLOAT): diff --git a/applications/nyaml/NXsqom.yaml b/applications/nyaml/NXsqom.yaml index 5089617351..ed3f8680f2 100644 --- a/applications/nyaml/NXsqom.yaml +++ b/applications/nyaml/NXsqom.yaml @@ -1,19 +1,21 @@ -doc: | - This is the application definition for S(Q,OM) processed data. +category: application +doc: | + This is the application definition for S(Q,OM) processed data. As this kind of data is in general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their intensity, table like. It is the task of a possible visualisation program to regrid this data in a sensible way. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points -category: application -NXsqom: +type: group +NXsqom(NXobject): (NXentry): \@entry: title: @@ -21,7 +23,7 @@ NXsqom: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXsqom] - instrument(NXinstrument): + (NXinstrument)instrument: (NXsource): type: name: @@ -34,26 +36,28 @@ NXsqom: name: doc: | Descriptive name of sample - reduction(NXprocess): + (NXprocess)reduction: program(NX_CHAR): version(NX_CHAR): - input(NXparameters): + (NXparameters)input: filenames(NX_CHAR): doc: | Raw data files used to generate this I(Q) doc: | Input parameters for the reduction program used - output(NXparameters): + (NXparameters)output: doc: | Eventual output parameters from the data reduction program used (NXdata): data(NX_INT): + signal: 1 doc: | This is the intensity for each point in QE dimensions: rank: 1 dim: [[1, nP]] qx(NX_NUMBER): + axis: 1 unit: NX_WAVENUMBER doc: | Positions for the first dimension of Q @@ -61,6 +65,7 @@ NXsqom: rank: 1 dim: [[1, nP]] qy(NX_NUMBER): + axis: 1 unit: NX_WAVENUMBER doc: | Positions for the the second dimension of Q @@ -68,6 +73,7 @@ NXsqom: rank: 1 dim: [[1, nP]] qz(NX_NUMBER): + axis: 1 unit: NX_WAVENUMBER doc: | Positions for the the third dimension of Q @@ -75,6 +81,7 @@ NXsqom: rank: 1 dim: [[1, nP]] en(NX_FLOAT): + axis: 1 unit: NX_ENERGY doc: | Values for the energy transfer for each point diff --git a/applications/nyaml/NXstxm.yaml b/applications/nyaml/NXstxm.yaml index 2420cbab16..a696f1b278 100644 --- a/applications/nyaml/NXstxm.yaml +++ b/applications/nyaml/NXstxm.yaml @@ -1,98 +1,100 @@ -doc: | - Application definition for a STXM instrument. +category: application +doc: | + Application definition for a STXM instrument. The interferometer position measurements, monochromator photon energy values and detector measurements are all treated as NXdetectors and stored - within the NXinstrument group as lists of values stored in + within the NXinstrument group as lists of values stored in chronological order. The NXdata group then holds another version of the data in a regular 3D array (NumE by NumY by NumX, for a total of nP points in a sample image stack type scan). The former data values should be stored with a minimum loss of precision, while the latter values can be simplified and/or approximated in order to fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' - are just sample_image scan types with reduced dimensions in the same way + are just sample_image scan types with reduced dimensions in the same way as single images have reduced E dimensions compared to image 'stacks'. + symbols: - doc: | - These symbols will be used below to coordinate the shapes of the datasets. + doc: | + These symbols will be used below to coordinate the shapes of the datasets. - nP: | - Total number of scan points + nP: | + Total number of scan points - nE: | - Number of photon energies scanned + nE: | + Number of photon energies scanned - nX: | - Number of pixels in X direction + nX: | + Number of pixels in X direction - nY: | - Number of pixels in Y direction + nY: | + Number of pixels in Y direction - detectorRank: | - Rank of data array provided by the detector for a single measurement + detectorRank: | + Rank of data array provided by the detector for a single measurement -category: application -NXstxm: +type: group +NXstxm(NXobject): (NXentry): title: start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition(NX_CHAR): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXstxm] (NXinstrument): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] (NXsource): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] type: - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] name: - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] probe: - exists: [min, 1, max, 1] - monochromator(NXmonochromator): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] + (NXmonochromator)monochromator: + exists: ['min', '1', 'max', '1'] energy(NX_FLOAT): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] dimensions: rank: 1 dim: [[1, nP]] (NXdetector): - exists: required + exists: ['min', '1'] data(NX_NUMBER): dimensions: rank: 1+detectorRank - dim: [[1, nP]] doc: | Detector data should be presented with the first dimension corresponding to the - scan point and subsequent dimensions corresponding to the output of the detector. - Detectors that provide more than one value per scan point should have - a data array of rank 1+d, where d is the dimensions of the array provided per - scan point. For example, an area detector should have an NXdetector data array - of 3 dimensions, with the first being the set of scan points and the latter - two being the x- and y- extent of the detector. - NOTE: For each dimension > 1 there must exist a dim section such as: - sample_x(NXdetector): - exists: [min, 0, max, 1] + scan point and subsequent dimensions corresponding to the output of the detector. + Detectors that provide more than one value per scan point should have + a data array of rank 1+d, where d is the dimensions of the array provided per + scan point. For example, an area detector should have an NXdetector data array + of 3 dimensions, with the first being the set of scan points and the latter + two being the x- and y- extent of the detector. + NOTE':' For each dimension > 1 there must exist a dim section such as':' + dim: [[1, nP]] + (NXdetector)sample_x: + exists: ['min', '0', 'max', '1'] doc: | Measurements of the sample position from the x-axis interferometer. data(NX_FLOAT): dimensions: rank: 1 dim: [[1, nP]] - sample_y(NXdetector): - exists: [min, 0, max, 1] + (NXdetector)sample_y: + exists: ['min', '0', 'max', '1'] doc: | Measurements of the sample position from the y-axis interferometer. data(NX_FLOAT): dimensions: rank: 1 dim: [[1, nP]] - sample_z(NXdetector): - exists: [min, 0, max, 1] + (NXdetector)sample_z: + exists: ['min', '0', 'max', '1'] doc: | Measurements of the sample position from the z-axis interferometer. data(NX_FLOAT): @@ -103,62 +105,63 @@ NXstxm: rotation_angle(NX_FLOAT): (NXdata): stxm_scan_type: - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] doc: | - Label for typical scan types as a convenience for humans. - Each label corresponds to a specific set of axes being scanned - to produce a data array of shape: - - * sample point spectrum: (photon_energy,) - * sample line spectrum: (photon_energy, sample_y/sample_x) - * sample image: (sample_y, sample_x) - * sample image stack: (photon_energy, sample_y, sample_x) - * sample focus: (zoneplate_z, sample_y/sample_x) - * osa image: (osa_y, osa_x) - * osa focus: (zoneplate_z, osa_y/osa_x) - * detector image: (detector_y, detector_x) - - The "generic scan" string is to be used when none of the - other choices are appropriate. + Label for typical scan types as a convenience for humans. + Each label corresponds to a specific set of axes being scanned + to produce a data array of shape':' + + * sample point spectrum':' (photon_energy,) + * sample line spectrum':' (photon_energy, sample_y/sample_x) + * sample image':' (sample_y, sample_x) + * sample image stack':' (photon_energy, sample_y, sample_x) + * sample focus':' (zoneplate_z, sample_y/sample_x) + * osa image':' (osa_y, osa_x) + * osa focus':' (zoneplate_z, osa_y/osa_x) + * detector image':' (detector_y, detector_x) + + The "generic scan" string is to be used when none of the + other choices are appropriate. enumeration: [sample point spectrum, sample line spectrum, sample image, sample image stack, sample focus, osa image, osa focus, detector image, generic scan] data(NX_NUMBER): + signal: 1 doc: | Detectors that provide more than one value per scan point should be summarised - to a single value per scan point for this array in order to simplify plotting. - - Note that 'Line scans' and focus type scans measure along one spatial dimension - but are not restricted to being parallel to the X or Y axes. Such scans - should therefore use a single dimension for the positions along the spatial - line. The 'sample_x' and 'sample_y' fields should then contain lists of the - x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. + to a single value per scan point for this array in order to simplify plotting. + + Note that 'Line scans' and focus type scans measure along one spatial dimension + but are not restricted to being parallel to the X or Y axes. Such scans + should therefore use a single dimension for the positions along the spatial + line. The 'sample_x' and 'sample_y' fields should then contain lists of the + x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. energy(NX_FLOAT): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] doc: | List of photon energies of the X-ray beam. If scanned through multiple values, - then an 'axis' attribute will be required to link the field to the appropriate data array dimension. + then an 'axis' attribute will be required to link the field to the appropriate data array dimension. dimensions: rank: 1 dim: [[1, nE]] sample_y(NX_FLOAT): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] doc: | List of Y positions on the sample. If scanned through multiple values, - then an 'axis' attribute will be required to link the field to the appropriate data array dimension. + then an 'axis' attribute will be required to link the field to the appropriate data array dimension. dimensions: rank: 1 dim: [[1, nY]] sample_x(NX_FLOAT): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] doc: | List of X positions on the sample. If scanned through multiple values, - then an 'axis' attribute will be required to link the field to the appropriate data array dimension. + then an 'axis' attribute will be required to link the field to the appropriate data array dimension. dimensions: rank: 1 dim: [[1, nX]] - control(NXmonitor): - exists: [min, 0, max, 1] + (NXmonitor)control: + exists: ['min', '0', 'max', '1'] data(NX_FLOAT): doc: | Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring - electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the - NXdata groups. + electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the + NXdata groups. diff --git a/applications/nyaml/NXtas.yaml b/applications/nyaml/NXtas.yaml index f9ed34031a..679a64f34a 100644 --- a/applications/nyaml/NXtas.yaml +++ b/applications/nyaml/NXtas.yaml @@ -1,18 +1,20 @@ -doc: | - This is an application definition for a triple axis spectrometer. +category: application +doc: | + This is an application definition for a triple axis spectrometer. - It is for the trademark scan of the TAS, the Q-E scan. - For your alignment scans use the rules in :ref:`NXscan`. + It is for the trademark scan of the TAS, the Q-E scan. + For your alignment scans use the rules in ':'ref':'`NXscan`. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points -category: application -NXtas: - entry(NXentry): +type: group +NXtas(NXobject): + (NXentry)entry: title(NX_CHAR): start_time(NX_DATE_TIME): definition: @@ -24,9 +26,10 @@ NXtas: name: probe: enumeration: [neutron, x-ray] - monochromator(NXcrystal): + (NXcrystal)monochromator: ei(NX_FLOAT): unit: NX_ENERGY + axis: 1 dimensions: rank: 1 dim: [[1, nP]] @@ -35,9 +38,10 @@ NXtas: dimensions: rank: 1 dim: [[1, nP]] - analyser(NXcrystal): + (NXcrystal)analyser: ef(NX_FLOAT): unit: NX_ENERGY + axis: 1 dimensions: rank: 1 dim: [[1, nP]] @@ -53,6 +57,7 @@ NXtas: dim: [[1, nP]] (NXdetector): data(NX_INT): + signal: 1 dimensions: rank: 1 dim: [[1, nP]] @@ -67,21 +72,25 @@ NXtas: Descriptive name of sample qh(NX_FLOAT): unit: NX_DIMENSIONLESS + axis: 1 dimensions: rank: 1 dim: [[1, nP]] qk(NX_FLOAT): unit: NX_DIMENSIONLESS + axis: 1 dimensions: rank: 1 dim: [[1, nP]] ql(NX_FLOAT): unit: NX_DIMENSIONLESS + axis: 1 dimensions: rank: 1 dim: [[1, nP]] en(NX_FLOAT): unit: NX_ENERGY + axis: 1 dimensions: rank: 1 dim: [[1, nP]] @@ -117,7 +126,7 @@ NXtas: dim: [[1, 9]] (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -134,3 +143,17 @@ NXtas: (NXdata): doc: | One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis + ei(link): + target: /NXentry/NXinstrument/monochromator:NXcrystal/ei + ef(link): + target: /NXentry/NXinstrument/analyser:NXcrystal/ef + en(link): + target: /NXentry/NXsample/en + qh(link): + target: /NXentry/NXsample/qh + qk(link): + target: /NXentry/NXsample/qk + ql(link): + target: /NXentry/NXsample/ql + data(link): + target: /NXentry/NXinstrument/NXdetector/data diff --git a/applications/nyaml/NXtofnpd.yaml b/applications/nyaml/NXtofnpd.yaml index c6229fd02b..cb6ea8714d 100644 --- a/applications/nyaml/NXtofnpd.yaml +++ b/applications/nyaml/NXtofnpd.yaml @@ -1,18 +1,20 @@ +category: application doc: | This is a application definition for raw data from a TOF neutron powder diffractometer + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: | - Number of detectors + nDet: | + Number of detectors - nTimeChan: | - nTimeChan description + nTimeChan: | + nTimeChan description -category: application -NXtofnpd: - entry(NXentry): +type: group +NXtofnpd(NXobject): + (NXentry)entry: title: start_time(NX_DATE_TIME): definition: @@ -21,20 +23,22 @@ NXtofnpd: enumeration: [NXtofnpd] pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the flight path before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component + by the moderator or the source itself. In other words':' it the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. - user(NXuser): + (NXuser)user: name(NX_CHAR): (NXinstrument): - detector(NXdetector): + (NXdetector)detector: data(NX_INT): + signal: 1 dimensions: rank: 2 dim: [[1, nDet], [2, nTimeChan]] detector_number(NX_INT): + axis: 2 dimensions: rank: 1 dim: [[1, nDet]] @@ -47,6 +51,7 @@ NXtofnpd: dim: [[1, nDet]] time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT + axis: 1 dimensions: rank: 1 dim: [[1, nTimeChan]] @@ -70,7 +75,7 @@ NXtofnpd: Descriptive name of sample (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -80,12 +85,20 @@ NXtofnpd: distance(NX_FLOAT): unit: NX_LENGTH data(NX_INT): + signal: 1 dimensions: rank: 1 dim: [[1, nTimeChan]] time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT + axis: 1 dimensions: rank: 1 dim: [[1, nTimeChan]] - data(NXdata): + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + detector_number(link): + target: /NXentry/NXinstrument/NXdetector/detector_number + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight diff --git a/applications/nyaml/NXtofraw.yaml b/applications/nyaml/NXtofraw.yaml index 25309dfc00..2d30efd9ca 100644 --- a/applications/nyaml/NXtofraw.yaml +++ b/applications/nyaml/NXtofraw.yaml @@ -1,18 +1,20 @@ +category: application doc: | This is an application definition for raw data from a generic TOF instrument + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: | - Number of detectors + nDet: | + Number of detectors - nTimeChan: | - nTimeChan description + nTimeChan: | + nTimeChan description -category: application -NXtofraw: - entry(NXentry): +type: group +NXtofraw(NXobject): + (NXentry)entry: title: start_time(NX_DATE_TIME): definition: @@ -23,20 +25,22 @@ NXtofraw: run_number(NX_INT): pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the flight path before the sample position. This can be determined by a chopper, - by the moderator, or the source itself. In other words: it is the distance to the component + by the moderator, or the source itself. In other words':' it is the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. - user(NXuser): + (NXuser)user: name(NX_CHAR): - instrument(NXinstrument): - detector(NXdetector): + (NXinstrument)instrument: + (NXdetector)detector: data(NX_INT): + signal: 1 dimensions: rank: 2 dim: [[1, nDet], [2, nTimeChan]] detector_number(NX_INT): + axis: 2 dimensions: rank: 1 dim: [[1, nDet]] @@ -49,6 +53,7 @@ NXtofraw: dim: [[1, nDet]] time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT + axis: 1 dimensions: rank: 1 dim: [[1, nTimeChan]] @@ -74,7 +79,7 @@ NXtofraw: enumeration: [powder, liquid, single crystal] (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -84,14 +89,22 @@ NXtofraw: distance(NX_FLOAT): unit: NX_LENGTH data(NX_INT): + signal: 1 dimensions: rank: 1 dim: [[1, nTimeChan]] time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT + axis: 1 dimensions: rank: 1 dim: [[1, nTimeChan]] integral_counts(NX_INT): unit: NX_UNITLESS - data(NXdata): + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + detector_number(link): + target: /NXentry/NXinstrument/NXdetector/detector_number + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight diff --git a/applications/nyaml/NXtofsingle.yaml b/applications/nyaml/NXtofsingle.yaml index 49e247b907..626ad4240d 100644 --- a/applications/nyaml/NXtofsingle.yaml +++ b/applications/nyaml/NXtofsingle.yaml @@ -1,24 +1,26 @@ +category: application doc: | This is a application definition for raw data from a generic TOF instrument + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - xSize: | - xSize description + xSize: | + xSize description - ySize: | - ySize description + ySize: | + ySize description - nDet: | - Number of detectors + nDet: | + Number of detectors - nTimeChan: | - nTimeChan description + nTimeChan: | + nTimeChan description -category: application -NXtofsingle: - entry(NXentry): +type: group +NXtofsingle(NXobject): + (NXentry)entry: title: start_time(NX_DATE_TIME): definition: @@ -28,16 +30,17 @@ NXtofsingle: duration(NX_FLOAT): pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the flight path before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component + by the moderator or the source itself. In other words':' it the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. - user(NXuser): + (NXuser)user: name(NX_CHAR): (NXinstrument): - detector(NXdetector): + (NXdetector)detector: data(NX_INT): + signal: 1 dimensions: rank: 3 dim: [[1, xSize], [2, ySize], [3, nTimeChan]] @@ -50,6 +53,7 @@ NXtofsingle: dim: [[1, 1]] time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT + axis: 1 dimensions: rank: 1 dim: [[1, nTimeChan]] @@ -75,7 +79,7 @@ NXtofsingle: enumeration: [powder, liquid, single crystal] (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -85,12 +89,18 @@ NXtofsingle: distance(NX_FLOAT): unit: NX_LENGTH data(NX_INT): + signal: 1 dimensions: rank: 1 dim: [[1, nTimeChan]] time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT + axis: 1 dimensions: rank: 1 dim: [[1, nTimeChan]] - data(NXdata): + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight diff --git a/applications/nyaml/NXtomo.yaml b/applications/nyaml/NXtomo.yaml index 82eb07c8b9..d74141d437 100644 --- a/applications/nyaml/NXtomo.yaml +++ b/applications/nyaml/NXtomo.yaml @@ -1,56 +1,59 @@ -doc: | - This is the application definition for x-ray or neutron tomography raw data. +category: application +doc: | + This is the application definition for x-ray or neutron tomography raw data. - In tomography - a number of dark field images are measured, some bright field images and, of course the sample. + In tomography + a number of dark field images are measured, some bright field images and, of course the sample. In order to distinguish between them images carry a image_key. + symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. + doc: | + These symbols will be used below to coordinate datasets with the same shape. - nFrames: | - Number of frames + nFrames: | + Number of frames - xSize: | - Number of pixels in X direction + xSize: | + Number of pixels in X direction - ySize: | - Number of pixels in Y direction + ySize: | + Number of pixels in Y direction -category: application -NXtomo: - entry(NXentry): +type: group +NXtomo(NXobject): + (NXentry)entry: title: - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] start_time(NX_DATE_TIME): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] end_time(NX_DATE_TIME): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXtomo] - instrument(NXinstrument): + (NXinstrument)instrument: (NXsource): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] type: - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] name: - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] probe: - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] enumeration: [neutron, x-ray, electron] - detector(NXdetector): + (NXdetector)detector: data(NX_INT): + signal: 1 dimensions: rank: 3 dim: [[1, nFrames], [2, xSize], [3, ySize]] image_key(NX_INT): - doc: | + doc: | In order to distinguish between sample projections, dark and flat images, a magic number is recorded per frame. - The key is as follows: + The key is as follows':' * projection = 0 * flat field = 1 @@ -60,27 +63,28 @@ NXtomo: rank: 1 dim: [[1, nFrames]] x_pixel_size(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] y_pixel_size(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] distance(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] doc: | Distance between detector and sample x_rotation_axis_pixel_position(NX_FLOAT): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] y_rotation_axis_pixel_position(NX_FLOAT): - exists: [min, 0, max, 1] - sample(NXsample): + exists: ['min', '0', 'max', '1'] + (NXsample)sample: name: doc: | Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + doc: | In practice this axis is always aligned along one pixel direction on the detector and usually vertical. There are experiments with horizontal rotation axes, so this would need to be indicated somehow. For now the best way for that is an open question. @@ -88,31 +92,37 @@ NXtomo: rank: 1 dim: [[1, nFrames]] x_translation(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] dimensions: rank: 1 dim: [[1, nFrames]] y_translation(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] dimensions: rank: 1 dim: [[1, nFrames]] z_translation(NX_FLOAT): - exists: [min, 0, max, 1] unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] dimensions: rank: 1 dim: [[1, nFrames]] - control(NXmonitor): - exists: [min, 0, max, 1] + (NXmonitor)control: + exists: ['min', '0', 'max', '1'] data(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Total integral monitor counts for each measured frame. Allows a to correction for fluctuations in the beam between frames. dimensions: rank: 1 dim: [[1, nFrames]] - data(NXdata): + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/detector:NXdetector/data + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + image_key(link): + target: /NXentry/NXinstrument/detector:NXdetector/image_key diff --git a/applications/nyaml/NXtomophase.yaml b/applications/nyaml/NXtomophase.yaml index 597404f74d..3faa694c38 100644 --- a/applications/nyaml/NXtomophase.yaml +++ b/applications/nyaml/NXtomophase.yaml @@ -1,34 +1,36 @@ -doc: | - This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. +category: application +doc: | + This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. - In tomography first - some dark field images are measured, some bright field images and, of course the sample. In order + In tomography first + some dark field images are measured, some bright field images and, of course the sample. In order to properly sort the order of the images taken, a sequence number is stored with each image. + symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. + doc: | + These symbols will be used below to coordinate datasets with the same shape. - nBrightFrames: | - Number of bright frames + nBrightFrames: | + Number of bright frames - nDarkFrames: | - Number of dark frames + nDarkFrames: | + Number of dark frames - nSampleFrames: | - Number of image (sample) frames + nSampleFrames: | + Number of image (sample) frames - nPhase: | - Number of phase settings + nPhase: | + Number of phase settings - xSize: | - Number of pixels in X direction + xSize: | + Number of pixels in X direction - ySize: | - Number of pixels in Y direction + ySize: | + Number of pixels in Y direction -category: application -NXtomophase: - entry(NXentry): +type: group +NXtomophase(NXobject): + (NXentry)entry: title: start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): @@ -36,14 +38,15 @@ NXtomophase: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXtomophase] - instrument(NXinstrument): + (NXinstrument)instrument: (NXsource): type: name: probe: enumeration: [neutron, x-ray, electron] - bright_field(NXdetector): + (NXdetector)bright_field: data(NX_INT): + signal: 1 dimensions: rank: 3 dim: [[1, nBrightFrames], [2, xSize], [3, ySize]] @@ -51,8 +54,9 @@ NXtomophase: dimensions: rank: 1 dim: [[1, nBrightFrames]] - dark_field(NXdetector): + (NXdetector)dark_field: data(NX_INT): + signal: 1 dimensions: rank: 3 dim: [[1, nDarkFrames], [2, xSize], [3, ySize]] @@ -60,8 +64,9 @@ NXtomophase: dimensions: rank: 1 dim: [[1, nDarkFrames]] - sample(NXdetector): + (NXdetector)sample: data(NX_INT): + signal: 1 dimensions: rank: 4 dim: [[1, nSampleFrames], [2, nPhase], [3, xSize], [4, ySize]] @@ -77,12 +82,13 @@ NXtomophase: unit: NX_LENGTH doc: | Distance between detector and sample - sample(NXsample): + (NXsample)sample: name: doc: | Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE + axis: 1 dimensions: rank: 1 dim: [[1, nSampleFrames]] @@ -101,13 +107,17 @@ NXtomophase: dimensions: rank: 1 dim: [[1, nSampleFrames]] - control(NXmonitor): + (NXmonitor)control: integral(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Total integral monitor counts for each measured frame. Allows a correction for fluctuations in the beam between frames. dimensions: rank: 1 dim: [[1, nDarkFrames + nBrightFrames + nSampleFrame]] - data(NXdata): + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/sample:NXdetector/data + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle diff --git a/applications/nyaml/NXtomoproc.yaml b/applications/nyaml/NXtomoproc.yaml index 64c1b9ec4e..2d414bef32 100644 --- a/applications/nyaml/NXtomoproc.yaml +++ b/applications/nyaml/NXtomoproc.yaml @@ -1,21 +1,23 @@ +category: application doc: | - This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. + This is an application definition for the final result of a tomography experiment':' a 3D construction of some volume of physical properties. + symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. + doc: | + These symbols will be used below to coordinate datasets with the same shape. - nX: | - Number of voxels in X direction + nX: | + Number of voxels in X direction - nY: | - Number of voxels in Y direction + nY: | + Number of voxels in Y direction - nZ: | - Number of voxels in Z direction + nZ: | + Number of voxels in Z direction -category: application -NXtomoproc: - entry(NXentry): +type: group +NXtomoproc(NXobject): + (NXentry)entry: title: definition: doc: | @@ -31,7 +33,7 @@ NXtomoproc: name: doc: | Descriptive name of sample - reconstruction(NXprocess): + (NXprocess)reconstruction: program(NX_CHAR): doc: | Name of the program used for reconstruction @@ -41,13 +43,14 @@ NXtomoproc: date(NX_DATE_TIME): doc: | Date and time of reconstruction processing. - parameters(NXparameters): + (NXparameters)parameters: raw_file(NX_CHAR): doc: | Original raw data file this data was derived from - data(NXdata): + (NXdata)data: data(NX_INT): - doc: | + signal: 1 + doc: | This is the reconstructed volume. This can be different things. Please indicate in the unit attribute what physical quantity this really is. @@ -59,7 +62,8 @@ NXtomoproc: \@scaling: x(NX_FLOAT): unit: NX_ANY - doc: | + axis: 1 + doc: | This is an array holding the values to use for the x-axis of data. The units must be appropriate for the measurement. dimensions: @@ -67,7 +71,8 @@ NXtomoproc: dim: [[1, nX]] y(NX_FLOAT): unit: NX_ANY - doc: | + axis: 2 + doc: | This is an array holding the values to use for the y-axis of data. The units must be appropriate for the measurement. dimensions: @@ -75,7 +80,8 @@ NXtomoproc: dim: [[1, nY]] z(NX_FLOAT): unit: NX_ANY - doc: | + axis: 3 + doc: | This is an array holding the values to use for the z-axis of data. The units must be appropriate for the measurement. dimensions: diff --git a/applications/nyaml/NXxas.yaml b/applications/nyaml/NXxas.yaml index 341aab3580..a25e3ef589 100644 --- a/applications/nyaml/NXxas.yaml +++ b/applications/nyaml/NXxas.yaml @@ -1,21 +1,23 @@ -doc: | - This is an application definition for raw data from an X-ray absorption spectroscopy experiment. +category: application +doc: | + This is an application definition for raw data from an X-ray absorption spectroscopy experiment. - This is essentially a scan on energy versus incoming/ + This is essentially a scan on energy versus incoming/ absorbed beam. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points -category: application -NXxas: +type: group +NXxas(NXobject): (NXentry): \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... + doc: | + NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry. title: start_time(NX_DATE_TIME): @@ -29,17 +31,18 @@ NXxas: name: probe: enumeration: [x-ray] - monochromator(NXmonochromator): + (NXmonochromator)monochromator: energy(NX_FLOAT): + axis: 1 dimensions: rank: 1 dim: [[1, nP]] - incoming_beam(NXdetector): + (NXdetector)incoming_beam: data(NX_NUMBER): dimensions: rank: 1 dim: [[1, nP]] - absorbed_beam(NXdetector): + (NXdetector)absorbed_beam: data(NX_NUMBER): doc: | This data corresponds to the sample signal. @@ -52,7 +55,7 @@ NXxas: Descriptive name of sample (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -61,11 +64,15 @@ NXxas: preset value for time or monitor data(NX_NUMBER): doc: | - This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` + This field could be a link to ``/NXentry/NXinstrument/incoming_beam':'NXdetector/data`` dimensions: rank: 1 dim: [[1, nP]] (NXdata): + energy(link): + target: /NXentry/NXinstrument/monochromator:NXmonochromator/energy + absorbed_beam(link): + target: /NXentry/NXinstrument/absorbed_beam:NXdetector/data mode: doc: | Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) diff --git a/applications/nyaml/NXxasproc.yaml b/applications/nyaml/NXxasproc.yaml index 6954367493..a0fa42db3e 100644 --- a/applications/nyaml/NXxasproc.yaml +++ b/applications/nyaml/NXxasproc.yaml @@ -1,18 +1,20 @@ -doc: | +category: application +doc: | Processed data from XAS. This is energy versus I(incoming)/I(absorbed). + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points -category: application -NXxasproc: +type: group +NXxasproc(NXobject): (NXentry): \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... + doc: | + NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry. title: definition: @@ -23,7 +25,7 @@ NXxasproc: name: doc: | Descriptive name of sample - XAS_data_reduction(NXprocess): + (NXprocess)XAS_data_reduction: program(NX_CHAR): doc: | Name of the program used for reconstruction @@ -33,18 +35,19 @@ NXxasproc: date(NX_DATE_TIME): doc: | Date and time of reconstruction processing. - parameters(NXparameters): + (NXparameters)parameters: raw_file(NX_CHAR): doc: | Original raw data file this data was derived from (NXdata): energy: + axis: 1 dimensions: rank: 1 dim: [[1, nP]] data(NX_FLOAT): - doc: | - This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. + doc: | + This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. Expect attribute ``signal=1`` dimensions: rank: 1 diff --git a/applications/nyaml/NXxbase.yaml b/applications/nyaml/NXxbase.yaml index a948d58d3d..f24e4b2622 100644 --- a/applications/nyaml/NXxbase.yaml +++ b/applications/nyaml/NXxbase.yaml @@ -1,39 +1,43 @@ -doc: | +category: application +doc: | This definition covers the common parts of all monochromatic single crystal raw data application definitions. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points - nXPixels: | - Number of X pixels + nXPixels: | + Number of X pixels - nYPixels: | - Number of Y pixels + nYPixels: | + Number of Y pixels -category: application -NXxbase: - entry(NXentry): +type: group +NXxbase(NXobject): + (NXentry)entry: title: start_time(NX_DATE_TIME): definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxbase] - instrument(NXinstrument): - source(NXsource): + (NXinstrument)instrument: + (NXsource)source: type: name: probe: enumeration: [neutron, x-ray, electron] - monochromator(NXmonochromator): + (NXmonochromator)monochromator: wavelength(NX_FLOAT): unit: NX_WAVELENGTH - detector(NXdetector): + (NXdetector)detector: + exists: ['max', 'unbounded'] data(NX_INT): - doc: | + signal: 1 + doc: | The area detector data, the first dimension is always the number of scan points, the second and third are the number of pixels in x and y. The origin is always assumed to be @@ -43,46 +47,47 @@ NXxbase: rank: 3 dim: [[1, nP], [2, nXPixels], [3, nYPixels]] \@signal: + type: NX_POSINT enumeration: [1] x_pixel_size(NX_FLOAT): unit: NX_LENGTH y_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: | - The name of the group is detector if there is only one detector, - if there are several, names have to be detector1, + doc: | + The name of the group is detector if there is only one detector, + if there are several, names have to be detector1, detector2, ...detectorn. distance(NX_FLOAT): unit: NX_LENGTH frame_start_number(NX_INT): - doc: | - This is the start number of the first frame of a scan. In PX one often scans a couple - of frames on a give sample, then does something else, then returns to the same sample + doc: | + This is the start number of the first frame of a scan. In PX one often scans a couple + of frames on a give sample, then does something else, then returns to the same sample and scans some more frames. Each time with a new data file. This number helps concatenating such measurements. - sample(NXsample): + (NXsample)sample: name(NX_CHAR): doc: | Descriptive name of sample orientation_matrix(NX_FLOAT): - doc: | - The orientation matrix according to Busing and - Levy conventions. This is not strictly necessary as - the UB can always be derived from the data. But - let us bow to common usage which includes the + doc: | + The orientation matrix according to Busing and + Levy conventions. This is not strictly necessary as + the UB can always be derived from the data. But + let us bow to common usage which includes the UB nearly always. dimensions: rank: 2 dim: [[1, 3], [2, 3]] unit_cell(NX_FLOAT): - doc: | - The unit cell, a, b, c, alpha, beta, gamma. + doc: | + The unit cell, a, b, c, alpha, beta, gamma. Again, not strictly necessary, but normally written. dimensions: rank: 1 dim: [[1, 6]] temperature(NX_FLOAT): - doc: | + doc: | The sample temperature or whatever sensor represents this value best dimensions: rank: 1 @@ -99,9 +104,9 @@ NXxbase: unit: NX_LENGTH doc: | Translation of the sample along the Z-direction of the laboratory coordinate system - control(NXmonitor): + (NXmonitor)control: mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] @@ -113,9 +118,11 @@ NXxbase: doc: | Total integral monitor counts (NXdata): - doc: | - The name of this group id data if there is only - one detector; if there are several the names will - be data1, data2, data3 and will point - to the corresponding detector groups in the + doc: | + The name of this group id data if there is only + one detector; if there are several the names will + be data1, data2, data3 and will point + to the corresponding detector groups in the instrument hierarchy. + data(link): + target: /NXentry/NXinstrument/NXdetector/data diff --git a/applications/nyaml/NXxeuler.yaml b/applications/nyaml/NXxeuler.yaml index 3ad4ff9e5d..52b03b87ba 100644 --- a/applications/nyaml/NXxeuler.yaml +++ b/applications/nyaml/NXxeuler.yaml @@ -1,37 +1,41 @@ -doc: | - raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` +category: application +doc: | + raw data from a ':'index':'`four-circle diffractometer` with an ':'index':'`eulerian cradle`, extends ':'ref':'`NXxbase` - It extends :ref:`NXxbase`, so the full definition is the content - of :ref:`NXxbase` plus the data defined here. All four angles are + It extends ':'ref':'`NXxbase`, so the full definition is the content + of ':'ref':'`NXxbase` plus the data defined here. All four angles are logged in order to support arbitrary scans in reciprocal space. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points -category: application +type: group NXxeuler(NXxbase): - entry(NXentry): + (NXentry)entry: definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxeuler] - instrument(NXinstrument): - detector(NXdetector): + (NXinstrument)instrument: + (NXdetector)detector: polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + doc: | The polar_angle (two theta) where the detector is placed at each scan point. dimensions: rank: 1 dim: [[1, nP]] - sample(NXsample): + (NXsample)sample: rotation_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + doc: | This is an array holding the sample rotation angle at each scan point dimensions: @@ -39,7 +43,8 @@ NXxeuler(NXxbase): dim: [[1, nP]] chi(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + doc: | This is an array holding the chi angle of the eulerian cradle at each scan point dimensions: @@ -47,10 +52,19 @@ NXxeuler(NXxbase): dim: [[1, nP]] phi(NX_FLOAT): unit: NX_ANGLE - doc: | + signal: 1 + doc: | This is an array holding the phi rotation of the eulerian cradle at each scan point dimensions: rank: 1 dim: [[1, nP]] - name(NXdata): + (NXdata)name: + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + chi(link): + target: /NXentry/NXsample/chi + phi(link): + target: /NXentry/NXsample/phi diff --git a/applications/nyaml/NXxkappa.yaml b/applications/nyaml/NXxkappa.yaml index 5923a43f4b..8db2b1bba7 100644 --- a/applications/nyaml/NXxkappa.yaml +++ b/applications/nyaml/NXxkappa.yaml @@ -1,27 +1,29 @@ -doc: | - raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` +category: application +doc: | + raw data from a kappa geometry (CAD4) single crystal diffractometer, extends ':'ref':'`NXxbase` - This is the application definition for raw data from a kappa geometry + This is the application definition for raw data from a kappa geometry (CAD4) single crystal - diffractometer. It extends :ref:`NXxbase`, so the full definition is - the content of :ref:`NXxbase` plus the + diffractometer. It extends ':'ref':'`NXxbase`, so the full definition is + the content of ':'ref':'`NXxbase` plus the data defined here. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points -category: application +type: group NXxkappa(NXxbase): - entry(NXentry): + (NXentry)entry: definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxkappa] - instrument(NXinstrument): - detector(NXdetector): + (NXinstrument)instrument: + (NXdetector)detector: polar_angle(NX_FLOAT): unit: NX_ANGLE doc: | @@ -29,10 +31,11 @@ NXxkappa(NXxbase): dimensions: rank: 1 dim: [[1, nP]] - sample(NXsample): + (NXsample)sample: rotation_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + doc: | This is an array holding the sample rotation angle at each scan point dimensions: @@ -40,14 +43,16 @@ NXxkappa(NXxbase): dim: [[1, nP]] kappa(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + doc: | This is an array holding the kappa angle at each scan point dimensions: rank: 1 dim: [[1, nP]] phi(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + doc: | This is an array holding the phi angle at each scan point dimensions: rank: 1 @@ -56,4 +61,12 @@ NXxkappa(NXxbase): unit: NX_ANGLE doc: | This holds the inclination angle of the kappa arm. - name(NXdata): + (NXdata)name: + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + kappa(link): + target: /NXentry/NXsample/kappa + phi(link): + target: /NXentry/NXsample/phi diff --git a/applications/nyaml/NXxlaue.yaml b/applications/nyaml/NXxlaue.yaml index c5ce9d10df..576c39452a 100644 --- a/applications/nyaml/NXxlaue.yaml +++ b/applications/nyaml/NXxlaue.yaml @@ -1,25 +1,27 @@ -doc: | - raw data from a single crystal laue camera, extends :ref:`NXxrot` +category: application +doc: | + raw data from a single crystal laue camera, extends ':'ref':'`NXxrot` - This is the application definition for raw data from a single crystal laue - camera. It extends :ref:`NXxrot`. + This is the application definition for raw data from a single crystal laue + camera. It extends ':'ref':'`NXxrot`. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nE: | - Number of energies + nE: | + Number of energies -category: application +type: group NXxlaue(NXxrot): - entry(NXentry): + (NXentry)entry: definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxlaue] - instrument(NXinstrument): - source(NXsource): - distribution(NXdata): + (NXinstrument)instrument: + (NXsource)source: + (NXdata)distribution: data: doc: | expect ``signal=1 axes="energy"`` @@ -31,5 +33,5 @@ NXxlaue(NXxrot): dimensions: rank: 1 dim: [[1, nE]] - doc: | + doc: | This is the wavelength distribution of the beam diff --git a/applications/nyaml/NXxlaueplate.yaml b/applications/nyaml/NXxlaueplate.yaml index 9994427bb2..a60b7f3eac 100644 --- a/applications/nyaml/NXxlaueplate.yaml +++ b/applications/nyaml/NXxlaueplate.yaml @@ -1,17 +1,19 @@ -doc: | - raw data from a single crystal Laue camera, extends :ref:`NXxlaue` - - This is the application definition for raw data from a single crystal Laue - camera with an image plate as a detector. It extends :ref:`NXxlaue`. category: application +doc: | + raw data from a single crystal Laue camera, extends ':'ref':'`NXxlaue` + + This is the application definition for raw data from a single crystal Laue + camera with an image plate as a detector. It extends ':'ref':'`NXxlaue`. + +type: group NXxlaueplate(NXxlaue): - entry(NXentry): + (NXentry)entry: definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxlaueplate] - instrument(NXinstrument): - detector(NXdetector): + (NXinstrument)instrument: + (NXdetector)detector: diameter(NX_FLOAT): unit: NX_LENGTH doc: | diff --git a/applications/nyaml/NXxnb.yaml b/applications/nyaml/NXxnb.yaml index 4a895b13b2..9458ce7804 100644 --- a/applications/nyaml/NXxnb.yaml +++ b/applications/nyaml/NXxnb.yaml @@ -1,51 +1,63 @@ -doc: | - raw data from a single crystal diffractometer, extends :ref:`NXxbase` +category: application +doc: | + raw data from a single crystal diffractometer, extends ':'ref':'`NXxbase` - This is the application definition for raw data from + This is the application definition for raw data from a single crystal diffractometer - measuring in normal beam mode. It extends :ref:`NXxbase`, + measuring in normal beam mode. It extends ':'ref':'`NXxbase`, so the full definition is the content of - :ref:`NXxbase` plus the data defined here. All angles are + ':'ref':'`NXxbase` plus the data defined here. All angles are logged in order to support arbitrary scans in reciprocal space. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points -category: application +type: group NXxnb(NXxbase): - entry(NXentry): + (NXentry)entry: definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxnb] - instrument(NXinstrument): - detector(NXdetector): + (NXinstrument)instrument: + (NXdetector)detector: polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + doc: | The polar_angle (gamma) of the detector for each scan point. dimensions: rank: 1 dim: [[1, nP]] tilt_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + doc: | The angle by which the detector has been tilted out of the scattering plane. dimensions: rank: 1 dim: [[1, nP]] - sample(NXsample): + (NXsample)sample: rotation_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + axis: 1 + primary: 1 + doc: | This is an array holding the sample rotation angle at each scan point dimensions: rank: 1 dim: [[1, nP]] - name(NXdata): + (NXdata)name: + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle + tilt(link): + target: /NXentry/NXinstrument/NXdetector/tilt + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle diff --git a/applications/nyaml/NXxrot.yaml b/applications/nyaml/NXxrot.yaml index 0b44ab840a..7aea09ab2e 100644 --- a/applications/nyaml/NXxrot.yaml +++ b/applications/nyaml/NXxrot.yaml @@ -1,45 +1,48 @@ -doc: | - raw data from a rotation camera, extends :ref:`NXxbase` +category: application +doc: | + raw data from a rotation camera, extends ':'ref':'`NXxbase` This is the application definition for raw data from a rotation camera. - It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` + It extends ':'ref':'`NXxbase`, so the full definition is the content of ':'ref':'`NXxbase` plus the data defined here. + symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points + nP: | + Number of points -category: application +type: group NXxrot(NXxbase): - entry(NXentry): + (NXentry)entry: definition: doc: | Official NeXus NXDL schema to which this file conforms. enumeration: [NXxrot] - instrument(NXinstrument): - detector(NXdetector): + (NXinstrument)instrument: + (NXdetector)detector: polar_angle(NX_FLOAT): unit: NX_ANGLE doc: | The polar_angle (two theta) where the detector is placed. beam_center_x(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the x position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. beam_center_y(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the y position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. - attenuator(NXattenuator): + (NXattenuator)attenuator: attenuator_transmission(NX_FLOAT): unit: NX_ANY - sample(NXsample): + (NXsample)sample: rotation_angle(NX_FLOAT): unit: NX_ANGLE + axis: 1 doc: | This is an array holding the sample rotation start angle at each scan point dimensions: @@ -47,9 +50,12 @@ NXxrot(NXxbase): dim: [[1, nP]] rotation_angle_step(NX_FLOAT): unit: NX_ANGLE + axis: 1 doc: | This is an array holding the step made for sample rotation angle at each scan point dimensions: rank: 1 dim: [[1, nP]] - name(NXdata): + (NXdata)name: + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle From 7c81ba947cf0845dfaf0ac9217a09f645f48f2bc Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Fri, 17 Mar 2023 10:45:20 +0100 Subject: [PATCH 112/203] Adding changes on appdefs and base classes which happened by Markus and on the fairmat branch after the this nxdl_consolidation branch was created by Rubel to get a consistent state which uses Rubels changes on nyaml to enable a merging of this consolidation branch with the current fairmat branch --- ...NXapm_paraprobe_results_distancer.nxdl.xml | 4 +- .../NXcg_alpha_shape.nxdl.xml | 119 -- contributed_definitions/NXdispersion.nxdl.xml | 25 +- .../NXdispersion_function.nxdl.xml | 69 +- .../NXdispersion_repeated_parameter.nxdl.xml | 25 +- .../NXdispersion_single_parameter.nxdl.xml | 25 +- .../NXdispersion_table.nxdl.xml | 25 +- .../NXdispersive_material.nxdl.xml | 159 +- .../NXellipsometry.nxdl.xml | 9 +- contributed_definitions/NXem_ebsd.nxdl.xml | 1661 ++++++++++----- .../NXem_ebsd_conventions.nxdl.xml | 109 + ...NXem_ebsd_crystal_structure_model.nxdl.xml | 2 +- .../NXimage_set_em_adf.nxdl.xml | 23 +- contributed_definitions/NXlens_em.nxdl.xml | 37 +- contributed_definitions/NXmpes.nxdl.xml | 8 + .../NXmpes_liquid.nxdl.xml | 2 +- contributed_definitions/NXprogram.nxdl.xml | 57 + .../NXapm_paraprobe_results_distancer.yaml | 4 +- .../nyaml/NXcg_alpha_shape.yaml | 83 - .../nyaml/NXdispersion.yaml | 11 + .../nyaml/NXdispersion_function.yaml | 73 + .../NXdispersion_repeated_parameter.yaml | 30 + .../nyaml/NXdispersion_single_parameter.yaml | 14 + .../nyaml/NXdispersion_table.yaml | 48 + .../nyaml/NXdispersive_material.yaml | 177 ++ .../nyaml/NXellipsometry.yaml | 11 +- contributed_definitions/nyaml/NXem_ebsd.yaml | 1878 ++++++++++++----- .../nyaml/NXem_ebsd_conventions.yaml | 55 + .../NXem_ebsd_crystal_structure_model.yaml | 2 +- .../nyaml/NXimage_set_em.yaml | 68 +- .../nyaml/NXimage_set_em_adf.yaml | 28 +- .../nyaml/NXimage_set_em_kikuchi.yaml | 80 +- contributed_definitions/nyaml/NXlens_em.yaml | 54 +- contributed_definitions/nyaml/NXmpes.yaml | 7 + .../nyaml/NXmpes_liquid.yaml | 2 +- .../nyaml/NXms_snapshot.yaml | 21 +- contributed_definitions/nyaml/NXprogram.yaml | 22 + manual/source/apm-structure.rst | 20 +- manual/source/cgms-structure.rst | 78 +- manual/source/em-structure.rst | 71 +- manual/source/north-structure.rst | 155 +- 41 files changed, 3688 insertions(+), 1663 deletions(-) delete mode 100644 contributed_definitions/NXcg_alpha_shape.nxdl.xml create mode 100644 contributed_definitions/NXprogram.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_alpha_shape.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion_function.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion_single_parameter.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion_table.yaml create mode 100644 contributed_definitions/nyaml/NXdispersive_material.yaml create mode 100644 contributed_definitions/nyaml/NXprogram.yaml diff --git a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml index 8ca1655e15..5acc178db4 100644 --- a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml @@ -285,7 +285,7 @@ The identifier of the triangle that is closest for each ion. - + @@ -294,7 +294,7 @@ A support field to visualize each ion and with this the distance informations using XDMF and e.g. Paraview. - + diff --git a/contributed_definitions/NXcg_alpha_shape.nxdl.xml b/contributed_definitions/NXcg_alpha_shape.nxdl.xml deleted file mode 100644 index 96d211dbe9..0000000000 --- a/contributed_definitions/NXcg_alpha_shape.nxdl.xml +++ /dev/null @@ -1,119 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the alpha shape, for now 2 or 3. - - - - - The number of edges. - - - - - The number of faces. - - - - - The number of cells. - - - - - Computational geometry description of alpha shapes or wrappings to primitives. - - For details see: - - * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, - * https://dx.doi.org/10.1145/174462.156635 for 3D, - * https://dl.acm.org/doi/10.5555/871114 for weighted, and - * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap - - in CGAL, the Computational Geometry Algorithms Library. - As a starting point, we follow the conventions of the CGAL library. - - - - - - - - - - Specify which general type of alpha shape is computed. - Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. - Alpha_wrapping means meshes created using alpha wrapping procedures. - - - - - - - - - Specifically when computed with the CGAL, the mode specifies if singular - faces are removed (regularized) of the alpha complex. - - - - - - - - - The alpha, (radius of the alpha-sphere) parameter to be used for alpha - shapes and alpha wrappings. - - - - - The offset distance parameter to be used in addition to alpha - in the case of alpha_wrapping. - - - - - Point cloud for which the alpha shape or wrapping should be computed. - - - - - Triangle soup for which the alpha wrapping should be computed. - - - - - A meshed representation of the resulting shape. - - - - diff --git a/contributed_definitions/NXdispersion.nxdl.xml b/contributed_definitions/NXdispersion.nxdl.xml index 8a4534f760..6f73ea5afd 100644 --- a/contributed_definitions/NXdispersion.nxdl.xml +++ b/contributed_definitions/NXdispersion.nxdl.xml @@ -1,6 +1,27 @@ - + - + + A dispersion denoting a sum of different dispersions. All NXdispersion_table and NXdispersion_function groups will be added together diff --git a/contributed_definitions/NXdispersion_function.nxdl.xml b/contributed_definitions/NXdispersion_function.nxdl.xml index 15ff513241..7cd4a1ed2b 100644 --- a/contributed_definitions/NXdispersion_function.nxdl.xml +++ b/contributed_definitions/NXdispersion_function.nxdl.xml @@ -1,6 +1,27 @@ - + - + + @@ -32,18 +53,54 @@ - + The identifier used to represent energy in the formula. It is recommended to use `E`. - + + + The minimum energy value at which this formula is valid. + + + + + The maximum energy value at which this formula is valid. + + + + + The energy unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. + + + The identifier useed to represent wavelength in the formula. It is recommended to use `lambda`. + + + The wavelength unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. + + + + + The minimum wavelength value at which this formula is valid. + + + + + The maximum wavelength value at which this formula is valid. + + Which representation does the formula evaluate to. @@ -57,12 +114,12 @@ - + - + diff --git a/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml index de7b01d73e..1f4527c848 100644 --- a/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml +++ b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml @@ -1,6 +1,27 @@ - + - + + diff --git a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml index 4ecca1b535..1a520d9613 100644 --- a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml +++ b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml @@ -1,6 +1,27 @@ - + - + + A single parameter for a dispersion function diff --git a/contributed_definitions/NXdispersion_table.nxdl.xml b/contributed_definitions/NXdispersion_table.nxdl.xml index 90de756669..fd53463982 100644 --- a/contributed_definitions/NXdispersion_table.nxdl.xml +++ b/contributed_definitions/NXdispersion_table.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols in this schema to denote the dimensions diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index 2dd9646ce4..5b41b10dca 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -1,21 +1,42 @@ - + - + + NXdispersion - + An application definition for a dispersive material. - + Version number to identify which definition of this application definition was used for this entry/data. - + URL where to find further material (documentation, examples) relevant to the application definition @@ -27,6 +48,14 @@ + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The colloquial name of the material, e.g. graphite or diamond for carbon. @@ -57,7 +86,7 @@ - + Denotes whether the dispersion is calculated or derived from an experiment @@ -66,16 +95,15 @@ - - - This fields holds a literature reference for this material. - - - - - This field holds the respective doi for the literature references. - - + + + + A text description of this reference, e.g. + `E. Example et al, The mighty example, An example journal 50 (2023), 100` + + + + The dispersion along the optical axis of the material. @@ -90,28 +118,31 @@ - - - - - + + + + + - - - - - - + + + + + + + + - - + + - - + + + @@ -125,28 +156,31 @@ - - - - - + + + + + - - - - - - + + + + + + + + - - + + - - + + + @@ -161,28 +195,31 @@ - - - - - + + + + + - - - - - - + + + + + + + + - - + + - - + + + diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 8308f14b5d..197b3f7d2e 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -643,11 +643,10 @@ - Use Hill's system for listing elements of the periodic table which are inside or - attached to the surface of the specimen and thus relevant from a scientific - point. The purpose of this field is to allow material databases to parse the - relevant elements without having to interpret the sample history or other - fields. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 213c67660e..06e4db918b 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + @@ -53,23 +53,66 @@ - Application definition for indexing Kikuchi pattern into orientation maps. + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. - For so-called three-dimensional or serial sectioning EBSD it is necessary to - follow a sequence of specimen, surface preparation, and data collection steps. - Results from individual measurements are combined into one reconstructed stack. - In this case, users should collect the data for each serial sectioning step - via an own instance of NXebsd. To report the resulting post-processing of this - set of EBSD (and/or orientation per scanned material point) users should use - an instance of the NXms application definition. This application definition - enables users to describe three-dimensional microstructures and features - identified in these microstructures. The term microstructure is used here - but is not restricted to features at the micron scale. Eventual tomography methods also use such a workflow because first diffraction - images are collected and then these are indexed and composed into a 3D - orientation mapping. The here proposed NXebsd application definition can - give some conceptual ideas how this splitting between measurement and - post-processing can be granularized also for these techniques. + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. @@ -83,7 +126,7 @@ NeXus NXDL schema to which this file conforms. - + @@ -100,10 +143,10 @@ Free-text description about the workflow. - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. @@ -126,24 +169,18 @@ when the processing of the workflow ended. - + - Commercial, parser, or otherwise given name to the program - which was used to process the workflow. + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. - - - Program 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. - - - + + + + - Optional contact information and eventually details of at least one person + Contact information and eventually details of at least one person involved in performing the workflow. This can be the principle investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -210,178 +247,6 @@ - - - An inspection of the availability of EBSD datasets with an open-source - license stored on public archive services like Zenodo revealed during - the implementation of a generic parser for EBSD data that such data are - in most cases stored in two ways: Case one was via a file in format used - by technology partners. This file contains result of an on-the-fly - executed indexing, i.e. processing of the Kikuchi pattern into scan point - positions, indexing solutions per scan point, and some quality descriptors - for the solutions as well as crystal structure and phase metadata. - Case two were raw pattern in some custom format often without a detailed - description of what the individual fields and data arrays resolve - except for some references to publications. - Therefore, we first need to collect how these files have been - generated. Ideally one would do so by creating a complete set of - information via e.g. NXem that could then be used via reading from - the information in the measurement group (see below) of this application - definition. However, in most cases this is not available. - - Therefore, this group stores key metadata about which results file - contain the EBSD mapping and which software was used (software name - and version with build number). These pieces of information support - the interpretation of specific metadata in these results file which - currently cannot or be interpreted completely or conceptually uniquely. - - Thereby this NXem_ebsd application definition solves two key documentation - tasks which are so far missing in the EBSD community. An instance - of the application definition (e.g. a NeXus/HDF5 file formatted according - to this application definition) stores the connection between the - microscope session and thus the sample and microscope settings, and - Kikuchi pattern, overview images etc. Furthermore, this application definition - connects these data to the conventions used, and the results file - which would otherwise also be ripped out of their context when using - many traditional procedures where EBSD data are indexed on-the-fly - and shared by just sharing the results file in the technology partner - specific formatting. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing. This is the usual production workflow - how scanning electron microscopes are used when collecting - EBSD data. - - - - Program version plus build number, commit hash, or other description - of an ever persistent resource where the source code of the program and - build instructions can be found or at least more information about the - program in this version can be found. If all such information is not - available, like for commercial software, here the version number - and build number should be named. Use semantic versioning if possible. - - - - - - Name of the results file. - - - - Hash of that file. - - - - - - - Connection between the measurement of the Kikuchi pattern and the - processing of these into an orientation microscopy image. - - - - Name or link to an existent instance of an EBSD raw dataset inside an - NXem which has at least one NXimage_set_em_kikuchi instance. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the field in the EBSD community is that many of the metadata - fields are not in all cases fully documented. In addition, it is common - practice in the research field of EBSD that users transcode their raw - data into other formats so that these data can be interpreted by - specific software tools including commercial software from technology - partners other than the one which delivered the system that was e.g. - used when the raw data were collected. - As many of the file formats are not designed to communicate also then - the specifically and most importantly the eventually different context - of the metadata, we have opted for the first iteration of the implementation - to discard these metadata. - - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions, should not be our authority and necessarily - demands profits from feedback from the technology partners we have - opted for this intermediate approach. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - The EBSD system, that is the electron gun, pole-piece, stage tilting, - and EBSD detector, as well as the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, - the gnomonic projection has to be calibrated. - - In most practical cases, especially in engineering, there is a substantial - larger number of sessions where such a calibrated system is used - rather than recalibrated. - - In the first case the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software is well calibrated. Consequently, users only pick - from an existent library of NXem_ebsd_crystal_structure_model - instances and use them to measure and index their data on-the-fly. - As a result an indexing is performed after/between the beam scanning - the specimen (depends on configuration). - Specifically, users load their specimen, typically create a coarse image - of the surface, set an approximate value for the calibrated working distance - then tilt, configure the microscope for collection quality data, then - configure the settings used for the calibrated EBSD system, pick one or - multiple ROIs and then measure (nowadays this is virtually always an - automated process which is in most cases unsupervised, running within the - allocated microscope session time slot, data are indexed on-the-fly, and - results file often automatically copied and/or archived in certain places. - The result of such an EBSD measurement is a set of usually proprietary - or open files from technology partners (EBSD system and microscope - manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. - - - - A link/cross reference to an existent instance of NXebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - @@ -390,6 +255,16 @@ + + + + + + + + + + @@ -418,229 +293,1070 @@ - + - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientations. Fundamentally different algorithms - can be used to index EBSD/EBSP pattern. + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. - Pattern indexing is comparing of diffraction pattern, measured - against assumed or simulated pattern. Quality descriptor are defined - based on which an indexing algorithms yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Dictionary-based indexing methods are most increasingly becoming used also. + Do not store pattern in the simulation group if they + have been measured are not simulated. - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + - Binning i.e. downsampling of the pattern. + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - + - Specific parameter relevant only for certain algorithms used + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. - - - - - - - - - - - - - - - - - - + - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. - - - - - - + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. - - - - - - + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + - Fraction of successfully indexed pattern - of the set averaged over entire set. + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. - + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + Binning i.e. downsampling of the pattern. + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + - An overview of the entire area which was scanned. - For details about what defines the image contrast inspect descriptor. + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. Descriptor representing the image contrast. - - - + + Container holding a default plot of the reconstructed volume. + + + + + + + Descriptor values displaying the ROI. + - - - + + + - Overview + Signal - + Calibrated center of mass of the pixel along the slow axis. + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + @@ -652,7 +1368,7 @@ - Calibrated center of mass of the pixel along the fast axis. + Calibrated center of mass of the pixel along the fastest axis. @@ -665,87 +1381,29 @@ - + Default inverse pole figure (IPF) plot of the data specific for each - phase interpolated on a rectangular/cuboidal domain with square - pixels/voxels and the orientations colored according - to the coloring scheme used in the respective ipf_color_modelID/program. - - Most importantly as the parser is not performing the inverse pole figure - mapping it requires that this computation is stored inside the results_file - that is referred to under commercial_on_the_fly_indexing. - This example clearly shows the key limitation that is when the computational - steps of collecting the raw data and post-processing these with some - custom scripts like MTex or commercial tools. The limitation is that - the program which consumes this file, here the parser of the research - data management system, has not necessarily sufficient information - available to check if the injected orientation data and color models - are matching the conventions which get injected from the electronic - lab notebook into an instance of this application definition, such - as a NeXus/HDF5 file that is formatted according to NXem_ebsd. - - Ideally, the parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientations - eventually. Thereafter, convention-compliant default plot(s) could - be created and served for purposes of data exploration within the RDMS. - - Given the variety of post-processing tools used for EBSD however, and - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option because - at least one developer who would pursue such task would first have to - create a library for performing such tasks for the parser. - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies different players in the field have - implemement slightly different approaches each of which misses - one consistent view of the entire workflow that is EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The default plot does so far not - yet apply relevant rotations but takes the orientation - values as. Ideally with all conventions defined it can - be possible to develop a converter which rotates the - input data but this is here not yet assumed to happen. - - The key point is that the conventions however are captured - first of all because then such conversions for improving - interoperability can be achieved. - - This default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created. - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the beam - illuminates certain positions for a certain amount time (usually equally- - spaced and same time spent at each position). - - Scan positions can be such regular flight plans mapping lines, - line stacks, rectangular regions-of-interests, but also could instruct - spiral, random, or adaptive scans instead of square or hexagon grids. - - The majority of EBSD maps is reporting results for a regular grid - (square, hexagon). What matters though in terms of damage induced by - the electron beam and signal quality is the real electron dose history, - i.e. for how long the beam exposed which location for how long. - - Specifically the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. Specifying which phase this IPF mapping visualizes. + + + Alias/name for the phase whose indexed scan points are displayed. + + Which IPF definition computation according to backend. - + Along which axis to project? Typically [0, 0, 1] is chosen. @@ -758,59 +1416,60 @@ Bitdepth used for the RGB color model. Usually 8 bit. - + The tool/implementation used for creating the IPF color map from - the orientation data. Effectively this program is the backend + the orientation data. Effectively, this program is the backend which performs the computation of the inverse pole figure mappings - to reflect what the EBSD community expects and solve also eventual - limitation of research data management system that their data - ingestion backends parsers do not have sophisticated software tools - in place to compute such community-specific default plots. - Seeing first of all that different tools may yield different color - maps may help to convince the community to work towards a common - library which transcodes between all possible relations. - In fact while working on this example I found as many different as - in backend. - - This is why it is critical to store all rotation_conventions - and reference frame details as detailed as possible because - then one can always post-process the data. + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - - - Version of the program i.e. backend used. - - - + + + + + + The RGB image which represents the IPF map. + + + + + - RGB array, with resolution per fastest changing value defined by bitdepth. + RGB array, with resolution per fastest changing value + defined by bitdepth. - - - + + + + - IPF color coded orientation mapping + IPF color-coded orientation mapping - + Calibrated center of mass of the pixel along the slow axis. + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the faster axis. + @@ -822,7 +1481,7 @@ - Calibrated center of mass of the pixel along the fast axis. + Calibrated center of mass of the pixel along the fastest axis. @@ -836,18 +1495,12 @@ - For each stereographic standard triangle (SST), (fundamental zone) of - the orientation space, it is possible to define a color model which - assigns an orientation in the fundamental zone a color. - - For details see: - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web. + Same comments as for the two-dimensional case apply. + + + + RGB array, with resolution per fastest changing value defined by bitdepth. @@ -859,7 +1512,7 @@ - Naive IPF color map + IPF color key in stereographic standard triangle (SST) diff --git a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml index cb27931193..5a46756065 100644 --- a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml @@ -100,6 +100,115 @@ + + + Details about eventually relevant named directions that may + give reasons for anisotropies. The classical example is cold-rolling + where one has to specify which directions (rolling, transverse, and normal) + align how with the direction of the base vectors of the sample_reference_frame. + + + + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + Direction of the positively pointing x-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + + + + + + + + + + + + + + Name or alias assigned to the x-axis base vector, e.g. rolling direction. + + + + + Direction of the positively pointing y-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Name or alias assigned to the y-axis base vector, e.g. transverse direction. + + + + + Direction of the positively pointing z-axis base vector of + the processing_reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Name or alias assigned to the z-axis base vector, e.g. normal direction. + + + + + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + Details about the sample/specimen reference frame. diff --git a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml index ecb402203e..1205dd6c0c 100644 --- a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml @@ -131,7 +131,7 @@ Numeric identifier for each phase. - The value 0 is reversed for the unknown phase essentially representing the + The value 0 is reserved for the unknown phase essentially representing the null-model that no phase model was sufficiently significantly confirmed. Consequently, the value 0 must not be used as a phase_identifier. diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index d7c0a63091..1301c297d8 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -98,7 +98,7 @@ Annular dark field image stack. - + Image intensity values. @@ -108,7 +108,12 @@ - + + + Image intensities + + + Image identifier @@ -117,33 +122,33 @@ - Image identifier. + Image ID. - + - Pixel coordinate center of mass along y direction. + Pixel center of mass position y-coordinates. - Coordinate along y direction. + Label for the y axis. - + - Pixel coordinate center of mass along x direction. + Pixel center of mass position x-coordinates. - Coordinate along x direction. + Label for the x axis. diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index d49659a1d6..6eb00bb69b 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -25,17 +25,16 @@ Description of an electro-magnetic lens or a compound lens. - Details of an `electro-magnetic 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. + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. - .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 + 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 + Qualitative type of lens with respect to the number of pole pieces. @@ -47,8 +46,8 @@ - Colloquial or short name for the lens. For manufacturer names and identifiers - use respective manufacturer fields. + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. @@ -56,7 +55,7 @@ Name of the manufacturer who built/constructed the lens. - + Hardware name, hash identifier, or serial number that was given by the @@ -81,6 +80,17 @@ 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 @@ -89,10 +99,11 @@ - 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. + 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/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index ef796edb60..e628d97d8b 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -299,6 +299,14 @@ case these are not available, free-text description. + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last diff --git a/contributed_definitions/NXmpes_liquid.nxdl.xml b/contributed_definitions/NXmpes_liquid.nxdl.xml index 501c7768b0..53e8c3164a 100644 --- a/contributed_definitions/NXmpes_liquid.nxdl.xml +++ b/contributed_definitions/NXmpes_liquid.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + This is the application definition for multidimensional photoelectron spectroscopy on liquids diff --git a/contributed_definitions/NXprogram.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml new file mode 100644 index 0000000000..7f769690f3 --- /dev/null +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -0,0 +1,57 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class to describe a software tool or library. + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + Commercial, parser, or otherwise given name to the program. + + + + Program version plus build number, or commit hash. + + + + + Description of an ideally ever persistent resource where the source code + of the program or this specific compiled version of the program can be + found so that the program yields repeatably exactly the same numerical + and categorical results. + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml index b06893daed..7fea68ce8c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml @@ -227,7 +227,7 @@ NXapm_paraprobe_results_distancer: The identifier of the triangle that is closest for each ion. unit: NX_UNITLESS dimensions: - rank: + rank: 1 dim: [[1, i]] xdmf_ion_identifier(NX_UINT): exists: optional @@ -236,7 +236,7 @@ NXapm_paraprobe_results_distancer: informations using XDMF and e.g. Paraview. unit: NX_UNITLESS dimensions: - rank: + rank: 1 dim: [[1, i]] # ##MK::end of the tool-specific section diff --git a/contributed_definitions/nyaml/NXcg_alpha_shape.yaml b/contributed_definitions/nyaml/NXcg_alpha_shape.yaml deleted file mode 100644 index 88a5c2929b..0000000000 --- a/contributed_definitions/nyaml/NXcg_alpha_shape.yaml +++ /dev/null @@ -1,83 +0,0 @@ -category: base -doc: | - Computational geometry description of alpha shapes or wrappings to primitives. - - For details see: - - * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, - * https://dx.doi.org/10.1145/174462.156635 for 3D, - * https://dl.acm.org/doi/10.5555/871114 for weighted, and - * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap - - in CGAL, the Computational Geometry Algorithms Library. - As a starting point, we follow the conventions of the CGAL library. -# weighted alpha shapes -# The so-called spectrum or sets of (weighted) alpha shapes includes the -# convex hull of a point set. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality of the alpha shape, for now 2 or 3. - # generalize to d > 3 - n_e: The number of edges. - n_f: The number of faces. - n_c: The number of cells. -NXcg_alpha_shape: - dimensionality(NX_UINT): - unit: NX_UNITLESS - enumeration: [2, 3] - version: - doc: | - Specify which general type of alpha shape is computed. - Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. - Alpha_wrapping means meshes created using alpha wrapping procedures. - enumeration: [basic, alpha_wrapping] # , weighted] - mode: - doc: | - Specifically when computed with the CGAL, the mode specifies if singular - faces are removed (regularized) of the alpha complex. - # CHECK THIS AGAIN CAREFULLY - enumeration: [general, regularized] - alpha(NX_NUMBER): - doc: | - The alpha, (radius of the alpha-sphere) parameter to be used for alpha - shapes and alpha wrappings. - unit: NX_LENGTH - offset(NX_NUMBER): - doc: | - The offset distance parameter to be used in addition to alpha - in the case of alpha_wrapping. - unit: NX_LENGTH - # check again carefully the CGAL documentation talks about, for 3D, the square of the radius! - s(NXcg_point_set): - doc: Point cloud for which the alpha shape or wrapping should be computed. - # this could also just be implemented as a link but how would this be possible - # unfold the NXcg_point_set and add a - # weight(NX_NUMBER): - # doc: Weights for each point - # In general, an alpha complex is a disconnected and non-pure complex, - # meaning in particular that the alpha complex may have singular faces. - # so the number of cells, faces and edges depends on how a specific alpha complex, - # i.e. an alpha-shape of S for alpha, is filtrated with respect to k < d-dimensional - # simplices. Here we assume that number_of_cells, number_of_faces, number_of_edges - # are reported assuming one filtrates these simplices according to mode. - # also using the assumption the base class reports the unique vertices - # of the specifically filtrated alpha complex. - t(NXcg_triangle_set): - doc: Triangle soup for which the alpha wrapping should be computed. - triangulation(NXcg_triangle_set): - doc: A meshed representation of the resulting shape. - # should be a mesh - # add for each triangle if desirable a notation of whether the simplex is - # exterior, regular, singular, or interior with respect to the alpha complex - # but a triangulation is more than a triangle (soup)/set because there is - # connectivity information - # customize the NXcg_triangle_set base class members such that connectivity - # information is contained - # we need to find also a better name for this, what people intutive understand - # as the interior, may not even exist for a given alpha value - # more specifically it is the set of filtrated cells acknowledging mode - # e.g. the interior cells of the regularized alpha complex - interior_cells(NXcg_tetrahedron_set): - # document the alpha status - # https://doc.cgal.org/latest/Alpha_shapes_3/classCGAL_1_1Alpha__status.html diff --git a/contributed_definitions/nyaml/NXdispersion.yaml b/contributed_definitions/nyaml/NXdispersion.yaml new file mode 100644 index 0000000000..963d7b12b3 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion.yaml @@ -0,0 +1,11 @@ +category: base +doc: | + A dispersion denoting a sum of different dispersions. + All NXdispersion_table and NXdispersion_function groups will be added together + to form a single dispersion. +NXdispersion: + model_name(NX_CHAR): + doc: | + The name of the composite model. + (NXdispersion_table): + (NXdispersion_function): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_function.yaml b/contributed_definitions/nyaml/NXdispersion_function.yaml new file mode 100644 index 0000000000..e197e3f507 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_function.yaml @@ -0,0 +1,73 @@ +category: base +doc: | + This describes a dispersion function for a material or layer +symbols: + n_repetitions: | + The number of repetitions for the repeated parameters +NXdispersion_function: + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + formula(NX_CHAR): + doc: | + This should be a python parsable function. + Here we should provide which keywords are available + and a BNF of valid grammar. + convention(NX_CHAR): + doc: | + The sign convention being used (n + or - ik) + enumeration: ["n + ik", "n - ik"] + energy_identifier(NX_CHAR): + doc: | + The identifier used to represent energy + in the formula. It is recommended to use `E`. + energy_min(NX_NUMBER): + doc: | + The minimum energy value at which this formula is valid. + unit: NX_ENERGY + energy_max(NX_NUMBER): + doc: | + The maximum energy value at which this formula is valid. + unit: NX_ENERGY + energy_unit(NX_NUMBER): + doc: | + The energy unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. + unit: NX_ENERGY + wavelength_identifier(NX_CHAR): + doc: | + The identifier useed to represent wavelength + in the formula. It is recommended to use `lambda`. + wavelength_unit(NX_NUMBER): + doc: | + The wavelength unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. + unit: NX_LENGTH + wavelength_min(NX_NUMBER): + doc: | + The minimum wavelength value at which this formula is valid. + unit: NX_LENGTH + wavelength_max(NX_NUMBER): + doc: | + The maximum wavelength value at which this formula is valid. + unit: NX_LENGTH + representation(NX_CHAR): + doc: | + Which representation does the formula evaluate to. + This may either be n for refractive index or eps for dielectric function. + The appropriate token is then to be used inside the formula. + enumeration: [n, eps] + (NXdispersion_single_parameter): + (NXdispersion_repeated_parameter): + parameter_units: + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + values(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, n_repetitions]] diff --git a/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml b/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml new file mode 100644 index 0000000000..80b6e55178 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml @@ -0,0 +1,30 @@ +category: base +doc: | + A repeated parameter for a dispersion function +symbols: + n_repetitions: | + The number of parameter repetitions +NXdispersion_repeated_parameter: + name(NX_CHAR): + doc: | + The name of the parameter + description(NX_CHAR): + doc: | + A description of what this parameter represents + parameter_units(NX_CHAR): + doc: | + A unit array associating a unit with each parameter. + The first element should be equal to values/@unit. + The values should be SI interpretable standard units + with common prefixes (e.g. mikro, nano etc.) or their + short-hand notation (e.g. nm, mm, kHz etc.). + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + values(NX_NUMBER): + doc: | + The value of the parameter + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_repetitions]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml b/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml new file mode 100644 index 0000000000..571edf0464 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml @@ -0,0 +1,14 @@ +category: base +doc: | + A single parameter for a dispersion function +NXdispersion_single_parameter: + name(NX_CHAR): + doc: | + The name of the parameter + description(NX_CHAR): + doc: | + A description of what this parameter represents + value(NX_NUMBER): + doc: | + The value of the parameter + unit: NX_ANY \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_table.yaml b/contributed_definitions/nyaml/NXdispersion_table.yaml new file mode 100644 index 0000000000..0c691a5fa6 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_table.yaml @@ -0,0 +1,48 @@ +category: base +doc: | + A dispersion table denoting energy, dielectric function tabulated values. +symbols: + doc: | + The symbols in this schema to denote the dimensions + n_points: | + The number of energy and dielectric function points +NXdispersion_table: + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + convention(NX_CHAR): + doc: | + The sign convention being used (n + or - ik) + enumeration: ['n + ik', 'n - ik'] + wavelength(NX_NUMBER): + doc: | + The wavelength array of the tabulated dataset. + This is essentially a duplicate of the energy field. + There should be one or both of them present. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_points]] + energy(NX_NUMBER): + doc: | + The energy array of the tabulated dataset. + This is essentially a duplicate of the wavelength field. + There should be one or both of them present. + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_points]] + refractive_index(NX_COMPLEX): + doc: | + The refractive index array of the tabulated dataset. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_points]] + dielectric_function(NX_COMPLEX): + doc: | + The dielectric function of the tabulated dataset. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_points]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersive_material.yaml b/contributed_definitions/nyaml/NXdispersive_material.yaml new file mode 100644 index 0000000000..16613789ce --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersive_material.yaml @@ -0,0 +1,177 @@ +category: application +doc: | + NXdispersion +NXdispersive_material: + (NXentry): + definition: + doc: "An application definition for a dispersive material." + \@version: + doc: "Version number to identify which definition of this application + definition was used for this entry/data." + \@url: + doc: "URL where to find further material (documentation, examples) + relevant to the application definition" + enumeration: [NXdispersive_material] + sample(NXsample): + chemical_formula(NX_CHAR): + atom_types(NX_CHAR): + exists: optional + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + colloquial_name(NX_CHAR): + exists: optional + doc: | + The colloquial name of the material, e.g. graphite or diamond for carbon. + material_phase(NX_CHAR): + exists: optional + doc: | + The phase of the material + enumeration: [gas, liquid, solid, other] + material_phase_comment(NX_CHAR): + exists: optional + doc: | + Additional information about the phase if the + material phase is other. + additional_phase_information(NX_CHAR): + exists: recommended + doc: | + This field may be used to denote additional phase information, + such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or + if a measurement was done on a thin film or bulk material. + dispersion_type(NX_CHAR): + exists: recommended + doc: | + Denotes whether the dispersion is calculated or derived from an experiment + enumeration: ["measured", "simulated"] + REFERENCES(NXcite): + exists: recommended + text: + doc: | + A text description of this reference, e.g. + `E. Example et al, The mighty example, An example journal 50 (2023), 100` + doi: + dispersion_x(NXdispersion): + doc: | + The dispersion along the optical axis of the material. + This should be the only dispersion available for isotropic materials. + For uniaxial materials this denotes the ordinary axis. + For biaxial materials this denotes the x axis or epsilon 11 tensor element + of the diagionalized permittivity tensor. + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + (NXdispersion_table): + exists: recommended + model_name: + convention: + wavelength(NX_NUMBER): + dielectric_function(NX_COMPLEX): + exists: recommended + refractive_index(NX_COMPLEX): + exists: recommended + (NXdispersion_function): + exists: recommended + model_name: + formula: + convention: + energy_identifier: + exists: recommended + energy_unit(NX_NUMBER): + exists: recommended + wavelength_identifier: + exists: recommended + wavelength_unit(NX_NUMBER): + exists: recommended + representation: + (NXdispersion_single_parameter): + name: + value(NX_NUMBER): + (NXdispersion_repeated_parameter): + name: + values(NX_NUMBER): + plot(NXdata): + exists: recommended + dispersion_y(NXdispersion): + doc: | + This should only be filled for biaxial materials. + It denotes the epsilon 22 direction of the diagionalized + permittivity tensor. + exists: optional + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + (NXdispersion_table): + exists: recommended + model_name: + convention: + wavelength(NX_NUMBER): + dielectric_function(NX_COMPLEX): + exists: recommended + refractive_index(NX_COMPLEX): + exists: recommended + (NXdispersion_function): + exists: recommended + model_name: + formula: + convention: + energy_identifier: + exists: recommended + energy_unit(NX_NUMBER): + exists: recommended + wavelength_identifier: + exists: recommended + wavelength_unit(NX_NUMBER): + exists: recommended + representation: + (NXdispersion_single_parameter): + name: + value(NX_NUMBER): + (NXdispersion_repeated_parameter): + name: + values(NX_NUMBER): + plot(NXdata): + exists: recommended + dispersion_z(NXdispersion): + doc: | + This should only be filled for uniaxial or biaxial materials. + For uniaxial materials this denotes the extraordinary axis. + For biaxial materials this denotes the epsilon 33 tensor element + of the diagionalized perimittivty tensor. + exists: optional + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + (NXdispersion_table): + exists: recommended + model_name: + convention: + wavelength(NX_NUMBER): + dielectric_function(NX_COMPLEX): + exists: recommended + refractive_index(NX_COMPLEX): + exists: recommended + (NXdispersion_function): + exists: recommended + model_name: + formula: + convention: + energy_identifier: + exists: recommended + energy_unit(NX_NUMBER): + exists: recommended + wavelength_identifier: + exists: recommended + wavelength_unit(NX_NUMBER): + exists: recommended + representation: + (NXdispersion_single_parameter): + name: + value(NX_NUMBER): + (NXdispersion_repeated_parameter): + name: + values(NX_NUMBER): + plot(NXdata): + exists: recommended diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index df6070b4f8..68a52830e3 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -535,12 +535,11 @@ NXellipsometry: pressure etc.), along with the data (data type, wavelength array, measured data)." atom_types: - doc: "Use Hill's system for listing elements of the periodic table - which are inside or attached to the surface of the specimen - and thus relevant from a scientific point. The purpose of this - field is to allow material databases to parse the relevant - elements without having to interpret the sample history or other - fields." + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. sample_name: doc: "Descriptive name of the sample" diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index fdbd5c3a6f..055861d53a 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -7,93 +7,144 @@ symbols: n_x: Number of pixel along fast changing dimension for a rediscretized i.e. standardized default orientation mapping. # what to do when multiple pattern are averaged into one before the beam moves further? doc: | - Application definition for indexing Kikuchi pattern into orientation maps. + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. - For so-called three-dimensional or serial sectioning EBSD it is necessary to - follow a sequence of specimen, surface preparation, and data collection steps. - Results from individual measurements are combined into one reconstructed stack. - In this case, users should collect the data for each serial sectioning step - via an own instance of NXebsd. To report the resulting post-processing of this - set of EBSD (and/or orientation per scanned material point) users should use - an instance of the NXms application definition. This application definition - enables users to describe three-dimensional microstructures and features - identified in these microstructures. The term microstructure is used here - but is not restricted to features at the micron scale. Eventual tomography methods also use such a workflow because first diffraction - images are collected and then these are indexed and composed into a 3D - orientation mapping. The here proposed NXebsd application definition can - give some conceptual ideas how this splitting between measurement and - post-processing can be granularized also for these techniques. -# also NXtkd, NXhedm, etc... ? the IUCr DMI should work on an e.g. NXhedm + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. +# The respective partner application definition NXxray_fourd +# can be used for storing data and post-processing results of X-ray diffraction +# experiments which can yield also orientation maps in one, two- or three-dimensions. +# +# These complementary techniques and associated application definitions can be used +# to inform NXms, another partner application definition to NXem_ebsd. NXms describes +# the connection between measured or simulated structural features with a focus of +# the length and time-scale coarser then the atomic scale. The term microstructure +# is used here but is not restricted to features at the micron scale. + +# the IUCr DMI should work on an e.g. NXhedm +# NXem_tkd is not needed as it can be covered by NXem_ebsd as well. # if we think of the metadata/data graph collected from the microscope session -# documented in NXem may have only few relations between nodes of an instance of -# NXebsd and NXem. Key data from NXem which many users would expect to find -# also enumerated in NXebsd could be settings of the microscope, timestamp data -# when tasks where performed at the microscope using which specimen, operated +# documented in NXem there may be only a few relations between nodes of an instance +# of NXem_ebsd and NXem. Key data from NXem which many users would expect to find +# also enumerated in NXem_ebsd could be settings of the microscope, timestamp data +# when tasks were performed at the microscope using which specimen, operated # and prepared by whom. These latter pieces of information are all available # in NXem but if we were to make fields in NXem deep inside an instance # of NXem_event_data required than we factually more and more granularize and # pull in steps of detailed numerical post-processing which arguably is not # any longer at all necessarily related to the microscope session. -# We know many cases, see Marc de Graef's group or Hakon Anes with Knut -# Marthinsen at NTNU who spent much longer with a collected dataset in post- -# processing than at the microscope so there should be the flexibilty that -# documentation of the actual microscope session and the post-processing of -# some of the data therein collected remain coupled but not too repetively and -# strictly! -# one idea could be to use a reference to another NeXus file in the NXebsd -# file instance and the NXem file instance. -# by ho to the many metadata and data from a post-processing of ebsd -# data, namely the link to the microscope session where they were collected -# measurement: # name of file with raw microscope data -# \@version: # hash of file with raw microscope data -# on the other hand there are specific metadata to store with taking EBSD -# mappings -# tilt_angle(NX_FLOAT): -# maybe better make this integrated into the NXtransformations of the stage_lab, a stage_lab event? -# beam_position(NXcg_point_set): -# (NXdetector): -# exposure_time(NX_FLOAT): -# unit: NX_TIME -# gain(NX_FLOAT): -# ##MK how does a gain translate mathematically an input signal into an intensity signal? -# insertion_distance(NX_FLOAT): -# unit: NX_LENGTH -# ##MK a coordinate system for the detector in the NXcoordinate_system_set -# drift_correction(NX_BOOLEAN): ##MK?? -# move the next two rather to detector -# acquisition_speed(NX_FLOAT): -# doc: | -# Average number of patterns taken per second averaged over entire set. -# unit: NX_FREQUENCY -# acquisition_time(NX_FLOAT): -# doc: Wall-clock time the acquisition took. -# unit: NX_TIME - -# WHERE TO PLACE THE SCAN POSITIONS ? THEY SHOULD BE IN NXem -# THIS IS REALLY ABOUT CULTURE CHANGE DO NOT EXPECT TO FIND EVERYTHING -# IN SOME AD HOC COMPOSED FILE JUST BECAUSE THIS IS EASY BUT HAVE A TOOL -# WHERE YOU CAN QUERY WHERE YOU CAN FIND THESE VALUES. -# E.G. IF AN API CALL TO YOUR RDMS FOR A GIVEN EXPERIMENT WILL GIVE YOU THE -# SCAN POSITIONS ITS LIKE QUERYING A DATABASE AND NOBODY WOULD WASTE TIME -# WITH EXPORTING/IMPORTING THESE FROM LOUSY AND IMPRECISE ASCII TABLES... - -# we do not store EBSD data by default with making any assumptions about +# We know many cases in EBSD community, see the work of e.g. Marc de Graef's group +# or of Hakon Wiik Anes and Knut Marthinsen who spent much longer with a collected +# dataset in post-processing than collecting it at the microscope. Therefore, we +# need to have the flexibility that documentation of the actual microscope session +# and the post-processing of some of the data therein collected remain coupled +# but not too repetively and with too stiff constraints on the existence of specific +# fields as otherwise there can be contradictions for which NXem_ebsd would no longer +# be applicable when one wishes to remain at the same time conformant with the data +# scheme. +# The idea used here is to use a reference to another NeXus file in the NXem_ebsd +# file instance and the NXem file instance. So far we acknowledge that exporting +# data as an NXem application definition is limited and scientists currently have +# specific file formats from commercial or open-source tools to work with. +# Therefore, we so far model the connections between the application definitions +# as NXprocesses. As soon as NXem is more supported these NXclasses should become +# NXem e.g. though. +# Details about scan positions should not be reproduced unless needed for +# interpolating between results of neighboring scan positions. +# Currently, we suggest to leave the scan positions as closely to where they are +# collected, i.e. inside NXem. +# What this exampe of linking information rather than duplicating shows is that +# somewhat a culture change is needed: Instead of packing everything in one file +# we just need to assure that we have a tool whereby we can follow and inspect a +# set of linked objects if you would like to say so, also having multiple files +# is okay. +# Finally, this application definition makes any assumptions about # gridding, this enables to handle all sort of scan schemes. -# following the argumentation of MTex, in certain cases data will not -# be fully occupied grids anyway also gridding is effectively a -# delocalization/interpolation procedure -NXebsd: +# We follow the argumentation of MTex, in certain cases data will not yield +# fully occupied grids anyway. +# NXem_ebsd could also be useful/used for storing generic simulations of EBSD pattern +# which is one example for simulations of diffractions patterns as they may be observed +# with electron microscopes. In this case, there should be simulation(NXprocess) under this +# the simulation group where one can store the minimum required set of pieces of information +# which comes with every diffraction pattern simulation. +# The main problem is in this case that the simulation group is required but then there must +# either be no measurement group and on_the_fly_indexing group, and eventually calibration ? +# or these groups should be created but remain empty. +# Using the current NeXus appdef design and rules for setting constraints demands that then the +# same appdef should be used for post-processing measured data. So there is a conflict: +# The simulation must not be required and measurement must not be optional. +# Arguably one may call for two application definitions in this case but most constraints and +# concepts would then match those of NXem_ebsd which works again standardization and +# reducing the total number of ontologies. + +NXem_ebsd: (NXentry): exists: [min, 1, max, infty] \@version: doc: | An at least as strong as SHA256 hashvalue of the file that specifies the application definition. + # NEW ISSUE: FILE or ARTIFACT? # enumeration: [sha_256_hash] definition: doc: NeXus NXDL schema to which this file conforms. - enumeration: [NXebsd] + enumeration: [NXem_ebsd] workflow_identifier: doc: | Ideally, a (globally) unique persistent identifier @@ -107,10 +158,10 @@ NXebsd: doc: | Free-text description about the workflow. - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. start_time(NX_DATE_TIME): exists: recommended doc: | @@ -129,21 +180,17 @@ NXebsd: doc: | ISO 8601 time code with local time zone offset to UTC included when the processing of the workflow ended. - program: + (NXprogram): + exists: [min, 1, max, infty] doc: | - Commercial, parser, or otherwise given name to the program - which was used to process the workflow. - \@version: - doc: | - Program 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. + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + program_name: + \@version: (NXuser): exists: [min, 0, max, infty] doc: | - Optional contact information and eventually details of at least one person + Contact information and eventually details of at least one person involved in performing the workflow. This can be the principle investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -196,158 +243,11 @@ NXebsd: Name of the social media platform where the account under social_media_name is registered. - # the reference to the sample is made by measurement - # connection to an instance of NXem in which the input data to the workflow were measured - commercial_on_the_fly_indexing(NXprocess): - doc: | - An inspection of the availability of EBSD datasets with an open-source - license stored on public archive services like Zenodo revealed during - the implementation of a generic parser for EBSD data that such data are - in most cases stored in two ways: Case one was via a file in format used - by technology partners. This file contains result of an on-the-fly - executed indexing, i.e. processing of the Kikuchi pattern into scan point - positions, indexing solutions per scan point, and some quality descriptors - for the solutions as well as crystal structure and phase metadata. - Case two were raw pattern in some custom format often without a detailed - description of what the individual fields and data arrays resolve - except for some references to publications. - Therefore, we first need to collect how these files have been - generated. Ideally one would do so by creating a complete set of - information via e.g. NXem that could then be used via reading from - the information in the measurement group (see below) of this application - definition. However, in most cases this is not available. - - Therefore, this group stores key metadata about which results file - contain the EBSD mapping and which software was used (software name - and version with build number). These pieces of information support - the interpretation of specific metadata in these results file which - currently cannot or be interpreted completely or conceptually uniquely. - - Thereby this NXem_ebsd application definition solves two key documentation - tasks which are so far missing in the EBSD community. An instance - of the application definition (e.g. a NeXus/HDF5 file formatted according - to this application definition) stores the connection between the - microscope session and thus the sample and microscope settings, and - Kikuchi pattern, overview images etc. Furthermore, this application definition - connects these data to the conventions used, and the results file - which would otherwise also be ripped out of their context when using - many traditional procedures where EBSD data are indexed on-the-fly - and shared by just sharing the results file in the technology partner - specific formatting. - program: - doc: | - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing. This is the usual production workflow - how scanning electron microscopes are used when collecting - EBSD data. - \@version: - doc: | - Program version plus build number, commit hash, or other description - of an ever persistent resource where the source code of the program and - build instructions can be found or at least more information about the - program in this version can be found. If all such information is not - available, like for commercial software, here the version number - and build number should be named. Use semantic versioning if possible. - results_file: - doc: | - Name of the results file. - \@version: - doc: | - Hash of that file. - measurement(NXprocess): - doc: | - Connection between the measurement of the Kikuchi pattern and the - processing of these into an orientation microscopy image. - origin: - doc: | - Name or link to an existent instance of an EBSD raw dataset inside an - NXem which has at least one NXimage_set_em_kikuchi instance. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the field in the EBSD community is that many of the metadata - fields are not in all cases fully documented. In addition, it is common - practice in the research field of EBSD that users transcode their raw - data into other formats so that these data can be interpreted by - specific software tools including commercial software from technology - partners other than the one which delivered the system that was e.g. - used when the raw data were collected. - As many of the file formats are not designed to communicate also then - the specifically and most importantly the eventually different context - of the metadata, we have opted for the first iteration of the implementation - to discard these metadata. - - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions, should not be our authority and necessarily - demands profits from feedback from the technology partners we have - opted for this intermediate approach. - \@version: - doc: Commit identifying this resource. - path: - doc: | - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - # connection to the calibration data based on which the EBSD indexing is considered reliable - calibration(NXprocess): - exists: recommended - doc: | - The EBSD system, that is the electron gun, pole-piece, stage tilting, - and EBSD detector, as well as the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, - the gnomonic projection has to be calibrated. - - In most practical cases, especially in engineering, there is a substantial - larger number of sessions where such a calibrated system is used - rather than recalibrated. - - In the first case the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software is well calibrated. Consequently, users only pick - from an existent library of NXem_ebsd_crystal_structure_model - instances and use them to measure and index their data on-the-fly. - As a result an indexing is performed after/between the beam scanning - the specimen (depends on configuration). - Specifically, users load their specimen, typically create a coarse image - of the surface, set an approximate value for the calibrated working distance - then tilt, configure the microscope for collection quality data, then - configure the settings used for the calibrated EBSD system, pick one or - multiple ROIs and then measure (nowadays this is virtually always an - automated process which is in most cases unsupervised, running within the - allocated microscope session time slot, data are indexed on-the-fly, and - results file often automatically copied and/or archived in certain places. - The result of such an EBSD measurement is a set of usually proprietary - or open files from technology partners (EBSD system and microscope - manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. - origin: - doc: | - A link/cross reference to an existent instance of NXebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - \@version: - doc: Commit identifying this resource. - path: - doc: | - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. # rotation and reference frame conventions + # we assume that the conventions are the same across all experiments and/or + # simulations which this application definition captures conventions(NXem_ebsd_conventions): rotation_conventions(NXprocess): three_dimensional_rotation_handedness: @@ -355,6 +255,15 @@ NXebsd: euler_angle_convention: axis_angle_convention: orientation_parameterization_sign_convention: + processing_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + xaxis_alias: + yaxis_direction: + yaxis_alias: + zaxis_direction: + zaxis_alias: + origin: sample_reference_frame(NXprocess): reference_frame_type: xaxis_direction: @@ -379,65 +288,1045 @@ NXebsd: yaxis_boundary_convention: yaxis_normalization_direction: - # base class for indexing methods with relevant vocabulary - indexing(NXprocess): + # either we have simulated data or we have a set of measured data + # in every case data are Kikuchi diffraction pattern and their metadata + simulation(NXprocess): + exists: recommended doc: | - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientations. Fundamentally different algorithms - can be used to index EBSD/EBSP pattern. + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. - Pattern indexing is comparing of diffraction pattern, measured - against assumed or simulated pattern. Quality descriptor are defined - based on which an indexing algorithms yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Dictionary-based indexing methods are most increasingly becoming used also. - method: + Do not store pattern in the simulation group if they + have been measured are not simulated. + sequence_index(NX_POSINT): # 1 + (NXprogram): + exists: [min, 0, max, infty] + program_name: + \@version: + (NXcg_geodesic_mesh): + exists: [min, 0, max, infty] + (NXimage_set_em_kikuchi): + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 3 + # dim: [[1, n_p], [2, n_y], [3, n_x]] + pattern_identifier(NX_UINT): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + axis_y(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + + experiment(NXprocess): + exists: [min, 0, max, infty] + doc: | + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + time(NX_TIME): + exists: optional # required for spatial and/or temporal for a correlation process doc: | - Principal algorithm used for indexing. - enumeration: [undefined, hough_transform, dictionary, radon_transform, other] # emsoft, astro, mtex - background_correction(NXprocess): - exists: optional - # for each process the program used + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + (NXtransformations): + exists: optional # required for a spatial correlation process doc: | - Details about the background correction applied to each Kikuchi pattern. - # auto_background_correction: - # static_or_dynamic: - # pattern_averaging(NXprocess): - # doc: | - # Details about how patterns of each scan point are average or how - # pattern from scan points and neighboring scan points are spatially - # averaged (using weighting schemes and e.g. kernels) before these - # patterns are passed to the indexing algorithm. - binning(NXprocess): # NEW ISSUE: binning replace by NXgrid - exists: optional - # for each process the program used + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + calibration(NXprocess): # the more NeXus becomes supported the more we should go for (NXem) instead + exists: recommended # it should be required even for pattern simulations + # although one could simulate spherical Kikuchi pattern without modeling the detector system doc: | - Binning i.e. downsampling of the pattern. - # mode: - # doc: Free-text description for instrument specific settings - # binning(NX_UINT): ##MK equivalent to pattern height and width? - # doc: | - # How is the camera signal binned. - # First the number of pixel along the slow direction. - # Second the number of pixel along the fast direction. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, 2]] - parameter(NXcollection): - exists: optional + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + sequence_index(NX_POSINT): # 1 + origin: + doc: | + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + \@version: + doc: Commit identifying this resource. + path: + doc: | + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + acquisition(NXprocess): + exists: recommended # the measurement should be required unless the + # data come from e.g. a Kikuchi pattern simulation! doc: | - Specific parameter relevant only for certain algorithms used - # mode: - # doc: Which method used to index pattern? - # enumeration: [optimize_bd] # what does optimize_bd mean Oxford? - (NXem_ebsd_crystal_structure_model): + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + sequence_index(NX_POSINT): # 2 + origin: + doc: | + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + \@version: + doc: | + Commit or e.g. at least SHA256 checksum identifying this resource. + path: + doc: | + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + # base class for indexing methods with relevant vocabulary + indexing(NXprocess): + exists: recommended # making it recommended makes not much sense as then we will not have + # IPF default plots in this case we need to use simulated Kikuchi pattern as a fallback + doc: | + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + sequence_index(NX_POSINT): # 3 + on_the_fly_indexing(NXprocess): + exists: optional + doc: | + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + (NXprogram): + exists: [min, 1, max, infty] + doc: | + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + program_name: + \@version: + origin: + doc: | + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + \@version: + doc: | + Hash of that file. + path: + doc: | + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + method: + doc: | + Principal algorithm used for indexing. + enumeration: [undefined, hough_transform, dictionary, radon_transform, other] # emsoft, astro, mtex + background_correction(NXprocess): + exists: optional + doc: | + Details about the background correction applied to each Kikuchi pattern. + sequence_index(NX_POSINT): + # for each process the program used + # auto_background_correction: + # static_or_dynamic: + # pattern_averaging(NXprocess): + # doc: | + # Details about how patterns of each scan point are average or how + # pattern from scan points and neighboring scan points are spatially + # averaged (using weighting schemes and e.g. kernels) before these + # patterns are passed to the indexing algorithm. + binning(NXprocess): # NEW ISSUE: binning replace by NXgrid + exists: optional + doc: | + Binning i.e. downsampling of the pattern. + sequence_index(NX_POSINT): + # for each process the program used + # mode: + # doc: Free-text description for instrument specific settings + # binning(NX_UINT): ##MK equivalent to pattern height and width? + # doc: | + # How is the camera signal binned. + # First the number of pixel along the slow direction. + # Second the number of pixel along the fast direction. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, 2]] + parameter(NXprocess): + exists: optional + doc: | + Specific parameter relevant only for certain algorithms used + sequence_index(NX_POSINT): + # mode: + # doc: Which method used to index pattern? + # enumeration: [optimize_bd] # what does optimize_bd mean Oxford? + (NXem_ebsd_crystal_structure_model): # phaseID(NXem_ebsd_crystal_structure_model) + exists: [min, 1, max, infty] + crystallographic_database_identifier: + exists: recommended + crystallographic_database: + exists: recommended + unit_cell_abc(NX_FLOAT): + unit_cell_alphabetagamma(NX_FLOAT): + space_group: + exists: recommended + phase_identifier(NX_UINT): + phase_name: + exists: recommended + atom_identifier: + exists: recommended + atom(NX_UINT): + exists: recommended + atom_positions(NX_FLOAT): + exists: recommended + atom_occupancy(NX_FLOAT): + exists: recommended + number_of_planes(NX_UINT): + exists: recommended + plane_miller(NX_NUMBER): + exists: recommended + dspacing(NX_FLOAT): + exists: recommended + relative_intensity(NX_FLOAT): + exists: recommended + # connection to data collected using kinematic or + # NEW ISSUE: dynamic diffraction theory simulations + + # individual mappings + # (scientists in EBSD consult all sorts of mappings) + # like image_quality map, orientation mapping, ipf mapping, grain mapping + # etc. in fact these could be all the possible mappings which one can + # create with the famous commercial software solutions + # the problem a RDMS cannot understand these mappings unless they + # are standardized in the sense, one has an exchange format whereby + # these mappings can be exported/transcoded from their representation + # in the commercial software, e.g. + # keep in mind, everybody uses the TSL OIM or Bruker AZTec OIM mapping + # but even these two are not directly interoperable, which is why + # they are also not interoperable in some RDMS if one does not come + # up with a way how to go about standardizing their description + # summary(NXdata): + # doc: | + status(NX_UINT): + exists: optional + doc: | + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + # data(NX_UINT): + # doc: | + # Status value of each pixel of the orientation mapping. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_sc]] + # axis_y(NX_NUMBER): + # doc: | + # Coordinate along the slow direction. + # axis_x(NX_NUMBER): + # doc: | + # Coordinate along the fast direction. + n_phases_per_scan_point(NX_UINT): + exists: recommended + doc: | + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_sc]] + phase_identifier(NX_UINT): + exists: recommended + doc: | + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] # with i = sum of n_phases_per_scan_point + phase_matching(NX_NUMBER): + exists: recommended + doc: | + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] # with i = sum of n_phases_per_scan_point + phase_matching_descriptor: + exists: recommended + doc: | + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + enumeration: [undefined, ci, mad, other] + orientation_parameterization: + exists: recommended # required when orientation exists + doc: | + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + enumeration: [euler, axis_angle, rodrigues, quaternion, homochoric] + orientation(NX_NUMBER): + exists: recommended + doc: | + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + unit: NX_ANY # because differs for different parameterizations + dimensions: + rank: 2 + dim: [[1, i], [2, n_op]] + scan_point_positions(NX_NUMBER): + exists: recommended + # we make this only required as people may not yet be so happy with + # having to walk a graph from measurement -> path -> NXevent_data_em + # -> em_lab/ebeam_deflector to retrieve the actual scan positions + # although this would be much cleaner + doc: | + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_sc], [2, 2]] # could also become a [2, 3] + # EW ISSUE: this is in fact a duplicate because if we know th + # path to the measurement we would have available all ebeam_deflector + # settings and thus could identify where the beam was scanning for each + # NXevent_data_em instance, we have even more + + # NEW ISSUE: replace by a more generic pivot table + hit_rate(NX_NUMBER): + exists: optional + doc: | + Fraction of successfully indexed pattern + of the set averaged over entire set. + unit: NX_DIMENSIONLESS + + # candidate for default plot + region_of_interest(NXprocess): # conceptually this a virtual detector + exists: [min, 1, max, 1] + doc: | + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + descriptor: + doc: | + Descriptor representing the image contrast. + # taking two examples (CTF and H5OINA choked completely of possibility to find s.th. conceptually common to plot + enumeration: ["normalized_band_contrast", "normalized_confidence_index"] + roi(NXdata): + doc: | + Container holding a default plot of the region on the sample + investigated with EBSD. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: # 0 + # \@axis_y_indices: # 1 + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data(NX_NUMBER): + doc: | + Descriptor values displaying the ROI. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_y], [2, n_x]] + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: Signal + axis_y(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the slow axis. + unit: NX_LENGTH # pixel coordinates + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis + axis_x(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the fast axis. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis + + (NXprocess): # ipf_mapID(NXprocess): + exists: [min, 0, max, infty] # should be as many as crystal structure models + doc: | + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + phase_identifier(NX_UINT): + doc: | + Specifying which phase this IPF mapping visualizes. + unit: NX_UNITLESS + phase_name: + doc: | + Alias/name for the phase whose indexed scan points are displayed. + description: + exists: optional + doc: | + Which IPF definition computation according to backend. + # AS THE FIRST STEP WE DO NOT IMPLEMENT A GENERIC ORIENTATION AND REFERENCE + # FRAME LIBRARY WHICH CAN TRANSLATE BETWEEN ALL POSSIBLE CONVENTIONS. + # INSTEAD WE TAKE THE RESULTS COMPUTED FROM THE BACKEND THAT IS + # For cpr/crc/ang the pythonEBSD backend + # For other file either MTex or kikuchipy + # For DREAM.3D this is DREAM.3D + # For pyxem following the orix library (which has some, though not yet in + # all details checked links and usage of the orix library because kikuchipy + # is somehow connected to pyxem. NEED TO TALK TO DEVELOPERS HERE! + projection_direction(NX_NUMBER): + doc: | + Along which axis to project? Typically [0, 0, 1] is chosen. + # NEW ISSUE: [0, 0, 1] is defined in which coordinate system? + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 3]] + bitdepth(NX_UINT): + doc: | + Bitdepth used for the RGB color model. Usually 8 bit. + unit: NX_UNITLESS + # can an NX_UINT have an enumeration? + (NXprogram): + exists: [min, 1, max, infty] + doc: | + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + program_name: + \@version: + # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] + + ipf_rgb_map(NXdata): + doc: | + The RGB image which represents the IPF map. + # \@signal: # rgb + # \@axes: # [zpos, ypos, xpos] # rgb + # # \@rgb_indices: 0 + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # # \@zpos_indices: 2 + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data(NX_UINT): + doc: | + RGB array, with resolution per fastest changing value + defined by bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] + # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + IPF color-coded orientation mapping + axis_y(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the slow axis. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis + # but for h5web RGB we need n_y + 1, was an issue in v6.6.1 + axis_x(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the fast axis. + dimensions: + rank: 1 + dim: [[1, n_x]] # but for h5web RGB we need n_x + 1 + \@long_name: + doc: Label for the x axis + + ipf_rgb_color_model(NXdata): + doc: | + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + # \@signal: # rgb + # \@axes: # [ypos, xpos] # rgb + # # \@rgb_indices: 0 + # \@axis_x_indices: # 0 + # \@axis_y_indices: # 1 + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data(NX_UINT): + doc: | + RGB array, with resolution per fastest changing value defined by bitdepth. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + IPF color key in stereographic standard triangle (SST) + axis_y(NX_NUMBER): + doc: | + Pixel coordinate along the slow axis. + unit: NX_ANY # pixel coordinates + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis + axis_x(NX_NUMBER): + doc: | + Pixel coordinate along the fast axis. + unit: NX_ANY # pixel coordinates + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis + + + + + + + correlation(NXprocess): + exists: optional # making it recommended makes not much sense as then we will not have + doc: | + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + sequence_index(NX_POSINT): # 4 + + (NXem_ebsd_crystal_structure_model): # phaseID(NXem_ebsd_crystal_structure_model) exists: [min, 1, max, infty] crystallographic_database_identifier: exists: recommended @@ -446,192 +1335,59 @@ NXebsd: unit_cell_abc(NX_FLOAT): unit_cell_alphabetagamma(NX_FLOAT): space_group: + exists: recommended phase_identifier(NX_UINT): phase_name: exists: recommended - atom_identifier: - atom(NX_UINT): - atom_positions(NX_FLOAT): - atom_occupancy(NX_FLOAT): - number_of_planes(NX_UINT): - plane_miller(NX_NUMBER): - dspacing(NX_FLOAT): - relative_intensity(NX_FLOAT): - # individual mappings - # (scientists in EBSD consult all sorts of mappings) - # like image_quality map, orientation mapping, ipf mapping, grain mapping - # etc. in fact these could be all the possible mappings which one can - # create with the famous commercial software solutions - # the problem a RDMS cannot understand these mappings unless they - # are standardized in the sense, one has an exchange format whereby - # these mappings can be exported/transcoded from their representation - # in the commercial software, e.g. - # keep in mind, everybody uses the TSL OIM or Bruker AZTec OIM mapping - # but even these two are not directly interoperable, which is why - # they are also not interoperable in some RDMS if one does not come - # up with a way how to go about standardizing their description - # summary(NXdata): - # doc: | - status(NX_UINT): - exists: optional - doc: | - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - # data(NX_UINT): - # doc: | - # Status value of each pixel of the orientation mapping. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_sc]] - # axis_y(NX_NUMBER): - # doc: | - # Coordinate along the slow direction. - # axis_x(NX_NUMBER): - # doc: | - # Coordinate along the fast direction. - n_phases_per_scan_point(NX_UINT): - doc: | - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_sc]] - phase_identifier(NX_UINT): - doc: | - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] # with i = sum of n_phases_per_scan_point - phase_matching(NX_NUMBER): - exists: recommended - doc: | - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] # with i = sum of n_phases_per_scan_point - phase_matching_descriptor: - doc: | - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - enumeration: [undefined, ci, mad, other] - orientation_parameterization: - doc: | - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - enumeration: [euler, axis_angle, rodrigues, quaternion, homochoric] - orientation(NX_NUMBER): - doc: | - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - unit: NX_ANY # because differs for different parameterizations - dimensions: - rank: 2 - dim: [[1, i], [2, n_op]] - scan_point_positions(NX_NUMBER): - # we make this only required as people may not yet be so happy with - # having to walk a graph from measurement -> path -> NXevent_data_em - # -> em_lab/ebeam_deflector to retrieve the actual scan positions - # although this would be much cleaner - doc: | - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_sc], [2, 2]] # could also become a [2, 3] - # EW ISSUE: this is in fact a duplicate because if we know th - # path to the measurement we would have available all ebeam_deflector - # settings and thus could identify where the beam was scanning for each - # NXevent_data_em instance, we have even more - # REPLACE BY MORE GENERIC pivot table - hit_rate(NX_NUMBER): - exists: optional - doc: | - Fraction of successfully indexed pattern - of the set averaged over entire set. - unit: NX_DIMENSIONLESS - - # candidate for default plots - region_of_interest(NXprocess): + # candidate for default plot + region_of_interest(NXprocess): # conceptually this a virtual detector exists: [min, 1, max, 1] doc: | - An overview of the entire area which was scanned. - For details about what defines the image contrast inspect descriptor. + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. descriptor: doc: | Descriptor representing the image contrast. - enumeration: [band_contrast] + # enumeration: ["normalized_band_contrast", "normalized_confidence_index"] roi(NXdata): + doc: | + Container holding a default plot of the reconstructed volume. + # \@signal: # data + # \@axes: # [axis_z, axis_y, axis_x] + # \@axis_x_indices: # 0 + # \@axis_y_indices: # 1 + # \@axis_z_indices: # 2 + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: data(NX_NUMBER): + doc: | + Descriptor values displaying the ROI. unit: NX_UNITLESS dimensions: rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] + dim: [[1, n_z], [2, n_y], [3, n_x]] # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 # in axes fast to fastest # while for _indices fastest to fast \@long_name: - doc: Overview - # \@signal: rgb - # \@axes: [ypos, xpos] # rgb - # \@rgb_indices: 0 - # \@xpos_indices: 0 - # \@ypos_indices: 1 - axis_y(NX_NUMBER): + doc: Signal + axis_z(NX_NUMBER): doc: | Calibrated center of mass of the pixel along the slow axis. unit: NX_LENGTH # pixel coordinates + dimensions: + rank: 1 + dim: [[1, n_z]] + \@long_name: + doc: Label for the z axis + axis_y(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the fast axis. + unit: NX_LENGTH # pixel coordinates dimensions: rank: 1 dim: [[1, n_y]] @@ -639,7 +1395,7 @@ NXebsd: doc: Label for the y axis axis_x(NX_NUMBER): doc: | - Calibrated center of mass of the pixel along the fast axis. + Calibrated center of mass of the pixel along the fastest axis. unit: NX_LENGTH dimensions: rank: 1 @@ -647,97 +1403,29 @@ NXebsd: \@long_name: doc: Label for the x axis - ipf_mapID(NXprocess): - exists: [min, 1, max, infty] # should be as many as crystal structure models + (NXprocess): # ipf_mapID(NXprocess): + exists: [min, 0, max, infty] # should be as many as crystal structure models doc: | Default inverse pole figure (IPF) plot of the data specific for each - phase interpolated on a rectangular/cuboidal domain with square - pixels/voxels and the orientations colored according - to the coloring scheme used in the respective ipf_color_modelID/program. - - Most importantly as the parser is not performing the inverse pole figure - mapping it requires that this computation is stored inside the results_file - that is referred to under commercial_on_the_fly_indexing. - This example clearly shows the key limitation that is when the computational - steps of collecting the raw data and post-processing these with some - custom scripts like MTex or commercial tools. The limitation is that - the program which consumes this file, here the parser of the research - data management system, has not necessarily sufficient information - available to check if the injected orientation data and color models - are matching the conventions which get injected from the electronic - lab notebook into an instance of this application definition, such - as a NeXus/HDF5 file that is formatted according to NXem_ebsd. - - Ideally, the parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientations - eventually. Thereafter, convention-compliant default plot(s) could - be created and served for purposes of data exploration within the RDMS. - - Given the variety of post-processing tools used for EBSD however, and - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option because - at least one developer who would pursue such task would first have to - create a library for performing such tasks for the parser. - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies different players in the field have - implemement slightly different approaches each of which misses - one consistent view of the entire workflow that is EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The default plot does so far not - yet apply relevant rotations but takes the orientation - values as. Ideally with all conventions defined it can - be possible to develop a converter which rotates the - input data but this is here not yet assumed to happen. - - The key point is that the conventions however are captured - first of all because then such conversions for improving - interoperability can be achieved. - - This default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created. - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the beam - illuminates certain positions for a certain amount time (usually equally- - spaced and same time spent at each position). - - Scan positions can be such regular flight plans mapping lines, - line stacks, rectangular regions-of-interests, but also could instruct - spiral, random, or adaptive scans instead of square or hexagon grids. - - The majority of EBSD maps is reporting results for a regular grid - (square, hexagon). What matters though in terms of damage induced by - the electron beam and signal quality is the real electron dose history, - i.e. for how long the beam exposed which location for how long. - - Specifically the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. phase_identifier(NX_UINT): doc: | Specifying which phase this IPF mapping visualizes. unit: NX_UNITLESS + phase_name: + doc: | + Alias/name for the phase whose indexed scan points are displayed. description: exists: optional doc: | Which IPF definition computation according to backend. - # AS THE FIRST STEP WE DO NOT IMPLEMENT A GENERIC ORIENTATION AND REFERENCE - # FRAME LIBRARY WHICH CAN TRANSLATE BETWEEN ALL POSSIBLE CONVENTIONS. - # INSTEAD WE TAKE THE RESULTS COMPUTED FROM THE BACKEND THAT IS - # For cpr/crc/ang the pythonEBSD backend - # For other file either MTex or kikuchipy - # For DREAM.3D this is DREAM.3D - # For pyxem following the orix library (which has some, though not yet in - # all details checked links and usage of the orix library because kikuchipy - # is somehow connected to pyxem. NEED TO TALK TO DEVELOPERS HERE! - projection_normal(NX_NUMBER): + projection_direction(NX_NUMBER): doc: | Along which axis to project? Typically [0, 0, 1] is chosen. - unit: NX_DIMENSIONLESS + # NEW ISSUE: [0, 0, 1] is defined in which coordinate system? + unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, 3]] @@ -745,59 +1433,70 @@ NXebsd: doc: | Bitdepth used for the RGB color model. Usually 8 bit. unit: NX_UNITLESS - # can an NX_UINT have an enumeration? - program: + (NXprogram): + exists: [min, 1, max, infty] doc: | The tool/implementation used for creating the IPF color map from - the orientation data. Effectively this program is the backend + the orientation data. Effectively, this program is the backend which performs the computation of the inverse pole figure mappings - to reflect what the EBSD community expects and solve also eventual - limitation of research data management system that their data - ingestion backends parsers do not have sophisticated software tools - in place to compute such community-specific default plots. - Seeing first of all that different tools may yield different color - maps may help to convince the community to work towards a common - library which transcodes between all possible relations. - In fact while working on this example I found as many different as - in backend. - - This is why it is critical to store all rotation_conventions - and reference frame details as detailed as possible because - then one can always post-process the data. - enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] - \@version: - doc: Version of the program i.e. backend used. + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + program_name: + \@version: + + # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] + ipf_rgb_map(NXdata): + doc: | + The RGB image which represents the IPF map. + # \@signal: # rgb + # \@axes: # [zpos, ypos, xpos] # rgb + # # \@rgb_indices: 0 + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@axis_z_indices: 2 + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: data(NX_UINT): doc: | - RGB array, with resolution per fastest changing value defined by bitdepth. + RGB array, with resolution per fastest changing value + defined by bitdepth. unit: NX_UNITLESS dimensions: rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] + dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 # in axes fast to fastest # while for _indices fastest to fast \@long_name: - doc: IPF color coded orientation mapping - # \@signal: rgb - # \@axes: [zpos, ypos, xpos] # rgb - # \@rgb_indices: 0 - # \@xpos_indices: 0 - # \@ypos_indices: 1 - # \@zpos_indices: 2 - axis_y(NX_NUMBER): + doc: | + IPF color-coded orientation mapping + axis_z(NX_NUMBER): doc: | Calibrated center of mass of the pixel along the slow axis. unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_z]] + \@long_name: + doc: Label for the z axis + # but for h5web RGB we need n_z + 1, was an issue in v6.6.1 + axis_y(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the faster axis. + unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: Label for the y axis # but for h5web RGB we need n_y + 1 + doc: Label for the y axis + # but for h5web RGB we need n_y + 1, was an issue in v6.6.1 axis_x(NX_NUMBER): doc: | - Calibrated center of mass of the pixel along the fast axis. + Calibrated center of mass of the pixel along the fastest axis. dimensions: rank: 1 dim: [[1, n_x]] # but for h5web RGB we need n_x + 1 @@ -806,17 +1505,17 @@ NXebsd: ipf_rgb_color_model(NXdata): doc: | - For each stereographic standard triangle (SST), (fundamental zone) of - the orientation space, it is possible to define a color model which - assigns an orientation in the fundamental zone a color. - - For details see: - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web. + Same comments as for the two-dimensional case apply. + # \@signal: # rgb + # \@axes: # [ypos, xpos] # rgb + # # \@rgb_indices: 0 + # \@axis_x_indices: # 0 + # \@axis_y_indices: # 1 + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: data(NX_UINT): doc: | RGB array, with resolution per fastest changing value defined by bitdepth. @@ -824,16 +1523,12 @@ NXebsd: dimensions: rank: 3 dim: [[1, n_y], [2, n_x], [3, 3]] - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast \@long_name: - doc: Naive IPF color map - # \@signal: rgb - # \@axes: [ypos, xpos] # rgb - # \@rgb_indices: 0 - # \@xpos_indices: 0 - # \@ypos_indices: 1 + doc: | + IPF color key in stereographic standard triangle (SST) axis_y(NX_NUMBER): doc: | Pixel coordinate along the slow axis. @@ -982,3 +1677,24 @@ NXebsd: # doc: | # Model used to describe some aspect of the pattern. # enumeration: [band_contrast, mean_angular_deviation] + +# tilt_angle(NX_FLOAT): +# maybe better make this integrated into the NXtransformations of the stage_lab, a stage_lab event? +# beam_position(NXcg_point_set): +# (NXdetector): +# exposure_time(NX_FLOAT): +# unit: NX_TIME +# gain(NX_FLOAT): +# ##MK how does a gain translate mathematically an input signal into an intensity signal? +# insertion_distance(NX_FLOAT): +# unit: NX_LENGTH +# ##MK a coordinate system for the detector in the NXcoordinate_system_set +# drift_correction(NX_BOOLEAN): ##MK?? +# move the next two rather to detector +# acquisition_speed(NX_FLOAT): +# doc: | +# Average number of patterns taken per second averaged over entire set. +# unit: NX_FREQUENCY +# acquisition_time(NX_FLOAT): +# doc: Wall-clock time the acquisition took. +# unit: NX_TIME diff --git a/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml b/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml index e60e27d76f..22875c331a 100644 --- a/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml @@ -50,6 +50,60 @@ NXem_ebsd_conventions: between different parameterizations/representations according to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. enumeration: [undefined, p_plus_one, p_minus_one] + processing_reference_frame(NXprocess): + doc: | + Details about eventually relevant named directions that may + give reasons for anisotropies. The classical example is cold-rolling + where one has to specify which directions (rolling, transverse, and normal) + align how with the direction of the base vectors of the sample_reference_frame. + reference_frame_type: + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] + xaxis_direction: + doc: | + Direction of the positively pointing x-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + enumeration: [undefined, north, east, south, west, in, out] + xaxis_alias: + doc: | + Name or alias assigned to the x-axis base vector, e.g. rolling direction. + yaxis_direction: + doc: | + Direction of the positively pointing y-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + yaxis_alias: + doc: | + Name or alias assigned to the y-axis base vector, e.g. transverse direction. + zaxis_direction: + doc: | + Direction of the positively pointing z-axis base vector of + the processing_reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + zaxis_alias: + doc: | + Name or alias assigned to the z-axis base vector, e.g. normal direction. + origin: + doc: | + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + sample_reference_frame(NXprocess): doc: | Details about the sample/specimen reference frame. @@ -111,6 +165,7 @@ NXem_ebsd_conventions: outer unit normals (which point either parallel or antiparallel) along respective base vector direction of the reference frame. enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + detector_reference_frame(NXprocess): doc: | Details about the detector reference frame. diff --git a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml index 33927936b7..933a82cad6 100644 --- a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml @@ -80,7 +80,7 @@ NXem_ebsd_crystal_structure_model: phase_identifier(NX_UINT): doc: | Numeric identifier for each phase. - The value 0 is reversed for the unknown phase essentially representing the + The value 0 is reserved for the unknown phase essentially representing the null-model that no phase model was sufficiently significantly confirmed. Consequently, the value 0 must not be used as a phase_identifier. unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXimage_set_em.yaml b/contributed_definitions/nyaml/NXimage_set_em.yaml index a299907590..9acd6e6fb2 100644 --- a/contributed_definitions/nyaml/NXimage_set_em.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em.yaml @@ -1,61 +1,69 @@ category: base -doc: | +doc: | Container for reporting a set of images taken with an electron microscope. - -symbols: - n_images: | - Number of images in the stack. - - n_y: | - Number of pixel per image in the slow direction. - - n_x: | - Number of pixel per image in the fast direction. - -type: group -NXimage_set_em(NXobject): +symbols: + n_images: Number of images in the stack. + n_y: Number of pixel per image in the slow direction. + n_x: Number of pixel per image in the fast direction. +NXimage_set_em: + (NXprocess): + doc: | + Details how images were processed from the detector readings. + source: + doc: | + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXimage_set_em were loaded during + parsing to represent them in e.g. databases. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + program: + doc: | + Commercial or otherwise given name to the program which was used + to process detector data into the adf image(s). + \@version: + doc: | + Program 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. (NXprocess): mode: - doc: | + doc: | Imaging mode in which the instrument was and with which the images were captured. stack(NXdata): - doc: | + doc: | Image (stack). data_counts(NX_NUMBER): + doc: Image intensity values. unit: NX_UNITLESS - doc: | - Image intensity values. dimensions: rank: 3 dim: [[1, n_images], [2, n_y], [3, n_x]] axis_image_identifier(NX_UINT): + doc: Image identifier unit: NX_UNITLESS - doc: | - Image identifier dimensions: rank: 1 dim: [[1, n_images]] \@long_name: - doc: | - Image identifier. + doc: Image identifier. axis_y(NX_NUMBER): + doc: Pixel coordinate center of mass along y direction. unit: NX_LENGTH - doc: | - Pixel coordinate center of mass along y direction. dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: | - Coordinate along y direction. + doc: Coordinate along y direction. axis_x(NX_NUMBER): + doc: Pixel coordinate center of mass along x direction. unit: NX_LENGTH - doc: | - Pixel coordinate center of mass along x direction. dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: | - Coordinate along x direction. + doc: Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml index 0bfb4088f9..de787e3cdd 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml @@ -45,35 +45,41 @@ NXimage_set_em_adf: doc: Annulus outer half angle unit: NX_ANGLE stack(NXdata): - doc: | - Annular dark field image stack. - data_counts(NX_NUMBER): + doc: Annular dark field image stack. + # \@signal: intensity + # \@axes: [image_id, ypos, xpos] + # \@xpos_indices: 2 + # \@ypos_indices: 1 + # \@image_indices: 0 + intensity(NX_NUMBER): doc: Image intensity values. unit: NX_UNITLESS dimensions: rank: 3 dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_image_identifier(NX_UINT): + \@long_name: + doc: Image intensities + image_id(NX_UINT): doc: Image identifier unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_images]] \@long_name: - doc: Image identifier. - axis_y(NX_NUMBER): - doc: Pixel coordinate center of mass along y direction. + doc: Image ID. + ypos(NX_NUMBER): + doc: Pixel center of mass position y-coordinates. unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: Coordinate along y direction. - axis_x(NX_NUMBER): - doc: Pixel coordinate center of mass along x direction. + doc: Label for the y axis. + xpos(NX_NUMBER): + doc: Pixel center of mass position x-coordinates. unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: Coordinate along x direction. + doc: Label for the x axis. diff --git a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml index 7e0065bcf6..2711ff2a9a 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml @@ -1,21 +1,26 @@ category: base -doc: | +symbols: + n_sc: Number of scanned points. Scan point may have none, one, or more pattern. + n_p: Number of diffraction pattern. + n_y: Number of pixel per Kikuchi pattern in the slow direction. + n_x: Number of pixel per Kikuchi pattern in the fast direction. +doc: | Measured set of electron backscatter diffraction data, aka Kikuchi pattern. Kikuchi pattern are the raw data for computational workflows in the field of orientation (imaging) microscopy. The technique is especially used in materials science and materials engineering. - Based on a fuse of the `M. A. Jackson et al. `_ + Based on a fuse of the `M. A. Jackson et al. `_ of the DREAM.3D community and the open H5OINA format of Oxford Instruments - `P. Pinard et al. `_ + `P. Pinard et al. `_ EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional orientation microscopy. So-called serial section analyses. For a detailed overview of these techniques see e.g. - * `M. A. Groeber et al. `_ - * `A. J. Schwartz et al. `_ - * `P. A. Rottman et al. `_ + * `M. A. Groeber et al. `_ + * `A. J. Schwartz et al. `_ + * `P. A. Rottman et al. `_ With serial-sectioning this involves however always a sequence of measuring, milling. In this regard, each serial section (measuring) and milling @@ -46,30 +51,16 @@ doc: | to infer material properties. They do so by quantifying correlations between the spatial arrangement of the features, their individual properties, and (macroscopic) properties of materials. - -symbols: - n_sc: | - Number of scanned points. Scan point may have none, one, or more pattern. - - n_p: | - Number of diffraction pattern. - - n_y: | - Number of pixel per Kikuchi pattern in the slow direction. - - n_x: | - Number of pixel per Kikuchi pattern in the fast direction. - -type: group -NXimage_set_em_kikuchi(NXobject): +NXimage_set_em_kikuchi: + # a collection of pattern-related metadata (NXprocess): - doc: | + doc: | Details how Kikuchi pattern were processed from the detector readings. Scientists interested in EBSD should inspect the respective NXem_ebsd application definition which can be used as a partner application definition to detail substantially more details to this processing. stack(NXdata): - doc: | + doc: | Collected Kikuchi pattern as an image stack. As raw and closest to the first retrievable measured data as possible, i.e. do not use this container to store already averaged, filtered or whatever post-processed @@ -77,8 +68,7 @@ NXimage_set_em_kikuchi(NXobject): given the way how the instrument and control software was configured for your microscope session. scan_point_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | + doc: | Array which resolves the scan point to which each pattern belongs. Scan points are evaluated in sequence starting from scan point zero until scan point n_sc - 1. Evaluating the cumulated of this array @@ -92,12 +82,12 @@ NXimage_set_em_kikuchi(NXobject): In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. Use compressed arrays allows to store the scan_point_identifier efficiently. + unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_p]] data_counts(NX_NUMBER): - unit: NX_UNITLESS - doc: | + doc: | Signal intensity. For so-called three-dimensional or serial sectioning EBSD it is necessary to follow a sequence of specimen surface preparation and data collection. In this case users should collect the data for each @@ -105,39 +95,45 @@ NXimage_set_em_kikuchi(NXobject): All eventual post-processing of these measured data should be documented via NXebsd, resulting microstructure representations should be stored as NXms. + unit: NX_UNITLESS dimensions: rank: 3 dim: [[1, n_p], [2, n_y], [3, n_x]] + # n_p fast 2, n_y faster 1, n_x fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast \@long_name: - doc: | - Kikuchi pattern intensity + doc: Kikuchi pattern intensity + # \@signal: intensity + # \@axes: [pattern_identifier, ypos, xpos] + # \@xpos_indices: 0 + # \@ypos_indices: 1 + # \@pattern_identifier_indices: 2 pattern_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | + doc: | Pattern are enumerated starting from 0 to n_p - 1. + unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_p]] \@long_name: - doc: | - Kikuchi pattern identifier + doc: Kikuchi pattern identifier axis_y(NX_NUMBER): + doc: Pixel coordinate along the y direction. unit: NX_LENGTH - doc: | - Pixel coordinate along the y direction. dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: | - Label for the y axis + doc: Label for the y axis axis_x(NX_NUMBER): + doc: Pixel coordinate along the x direction. unit: NX_LENGTH - doc: | - Pixel coordinate along the x direction. dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: | - Label for the x axis + doc: Label for the x axis + # maybe time code data when the pattern were taken? + # key is it all happened in between the time defined in NXevent_data_em + # optionally link to NXebsd instance? diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index 682d36d7bf..b5482e9a9a 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -1,36 +1,50 @@ category: base doc: | Description of an electro-magnetic lens or a compound lens. - - Details of an `electro-magnetic 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. - - .. _electro-magnetic lens: https://dx.doi.org/10.1007/978-3-540-38967-5 + 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 `_ NXlens_em: type: - doc: "Qualitative type of lens with respect to the number of pole pieces" - enumeration: ["single", "double", "quadrupole", "hexapole", "octupole"] + doc: Qualitative type of lens with respect to the number of pole pieces. + enumeration: [single, double, quadrupole, hexapole, octupole] name: - doc: "Colloquial or short name for the lens. For manufacturer names and identifiers use respective manufacturer fields." + doc: | + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. manufacturer_name: - doc: "Name of the manufacturer who built/constructed the lens." - (NXmanufacturer): + doc: Name of the manufacturer who built/constructed the lens. + (NXfabrication): model: - doc: "Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens." + doc: Hardware name, hash identifier, or serial number that was given by the manufacturer to identify the lens. description: - doc: "Ideally an identifier, persistent link, or free text which gives further details about the lens." + doc: Ideally an identifier, persistent link, or free text which gives further details about the lens. voltage(NX_NUMBER): - doc: "Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array." + doc: Excitation voltage of the lens. For dipoles it is a single number. For higher orders, it is an array. unit: NX_VOLTAGE current(NX_NUMBER): - doc: "Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array." + doc: Excitation current of the lens. For dipoles it is a single number. For higher orders, it is an array. unit: NX_CURRENT + value(NX_NUMBER): + doc: | + 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. + unit: NX_ANY depends_on(NX_CHAR): - doc: "Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group." + doc: Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group. (NXtransformations): - doc: - "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." + doc: | + 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/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 73802accee..6b82c6233f 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -192,6 +192,13 @@ NXmpes: Ideally, a full report of the previous operations, in any format (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." + atom_types: + exists: recommended + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. preparation_date(NX_DATE_TIME): exists: recommended doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." diff --git a/contributed_definitions/nyaml/NXmpes_liquid.yaml b/contributed_definitions/nyaml/NXmpes_liquid.yaml index 2a0224d50e..c8817c17fb 100644 --- a/contributed_definitions/nyaml/NXmpes_liquid.yaml +++ b/contributed_definitions/nyaml/NXmpes_liquid.yaml @@ -5,7 +5,7 @@ doc: This is the application definition for multidimensional photoelectron spectroscopy on liquids category: application -NXmpes: +NXmpes_liquid: (NXentry): title: start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXms_snapshot.yaml b/contributed_definitions/nyaml/NXms_snapshot.yaml index 058d5a7c8d..81a6da6ef8 100644 --- a/contributed_definitions/nyaml/NXms_snapshot.yaml +++ b/contributed_definitions/nyaml/NXms_snapshot.yaml @@ -1,23 +1,20 @@ category: base -doc: | +doc: | Base class for data on the state of the microstructure at a given time/iteration. - -symbols: - doc: | +symbols: + doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - -type: group -NXms_snapshot(NXobject): +NXms_snapshot: comment: - doc: | + doc: | Is this time for a measurement or a simulation. enumeration: [measurement, simulation] time(NX_NUMBER): - unit: NX_TIME - doc: | + doc: | Measured or simulated physical time stamp for this snapshot. Not to be confused with wall-clock timing or profiling data. + unit: NX_TIME iteration(NX_INT): - unit: NX_UNITLESS - doc: | + doc: | Iteration or increment counter. + unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXprogram.yaml b/contributed_definitions/nyaml/NXprogram.yaml new file mode 100644 index 0000000000..672d6f95bd --- /dev/null +++ b/contributed_definitions/nyaml/NXprogram.yaml @@ -0,0 +1,22 @@ +category: base +doc: | + Base class to describe a software tool or library. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXprogram: + program_name: + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + program: + doc: | + Commercial, parser, or otherwise given name to the program. + \@version: + doc: | + Program version plus build number, or commit hash. + \@url: + doc: | + Description of an ideally ever persistent resource where the source code + of the program or this specific compiled version of the program can be + found so that the program yields repeatably exactly the same numerical + and categorical results. diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 71c17933e6..1147995d7b 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -20,18 +20,18 @@ Set of data storage objects to describe the acquisition/measurement side, the re .. _ApmNewAppDef: -New Application Definitions -############################ +Application Definitions +####################### We created one new application definition whose intention is to serve both the description of atom probe tomography and field-ion microscopy measurements: :ref:`NXapm`: - A general application definition with many detailed places of leaving metadata and procedural/computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). + A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). .. _ApmNewBC: -New Base Classes -################# +Base Classes +############ We developed new base classes to structure the application definition into lab experiment and computational steps: @@ -42,10 +42,10 @@ We developed new base classes to structure the application definition into lab e A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. :ref:`NXfabrication`: - A base class to bundle manufacturer/vendor-specific details about a component or device of an instrument. + A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. :ref:`NXpeak`: A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. @@ -57,17 +57,17 @@ We developed new base classes to structure the application definition into lab e A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. :ref:`NXreflectron`: - A base class to describe a kinetic energy sensitive filtering device for ToF. + A base class to describe a kinetic-energy-sensitive filtering device for time of flight (ToF). :ref:`NXstage_lab`: A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an - atom probe microscope or especially an electron microscopy offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and in an atom probe, given that both offer fixture functionalities and additional components such as for applying stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. + atom probe microscope or especially an electron microscop3 offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and one in an atom probe instrument, given that both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. Removed base classes -###################### +#################### We have removed the NXlens_apm base class and replaced it by :ref:`NXreflectron`. We have renamed NXmanufacturer to NXfabrication. diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index adfdb8d14a..c4d99a7542 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -29,18 +29,16 @@ and computer simulations. As far as NeXus is concerned, the here proposed distinct sets of simple geometric primitives and shapes offer a complementary alternative to the already existent base classes in NeXus for constructive solid geometry -such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name a few. +such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name but a few. Second, we would like to explore with this proposal how we can harmonize terms -frequently used by materials scientists in the condensed-matter physics with the -NOMAD MetaInfo description. +frequently used by materials scientists in the field of condensed-matter physics with definitions and terms offer by the NOMAD MetaInfo description. Third, the proposal should yield a substantiated set of arguments and suggestions how descriptors for the structure and atomic architecture of materials can be -harmonize. With this we especially would like to reach out and intensify the +harmonized. With this we especially would like to reach out and intensify the cooperation between the materials-science-related consortia of the German -National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, -and NFDI4Chem +National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. .. The proposal reaches out to our colleagues in the materials engineering-based .. consortia to document that there is value in discussing about controlled vocabulary. @@ -48,7 +46,7 @@ and NFDI4Chem .. _PhysicsCGMS: Physics background -################### +################## Microstructural features or crystal defects are spatial arrangements of atoms. Given their specific atomic arrangement and composition, such features have specific constraints on the degrees of freedom how atoms can arrange. This causes @@ -80,35 +78,21 @@ temporal set of atoms, each having a nuclid type and position/trajectory. In most cases, such a coarse-graining is an ill-posed task because different mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric defect can be described and be spatio-temporally constrained through a geometrical model -with defined geometric primitives and associated coarser-scale properties of the defect. +with defined geometric primitives and associated coarser-scale properties. The key motivation to such coarse-graining is to reduce the complexity of the description. On the one hand to support visualization and scientific analyses - not only -of crystal defect arrangements - and on the other hand it is the hope that using descriptors -at a coarser level, i.e. nanometer, micrometer, and larger, still sufficiently -accurate and precise descriptors can be found without having to dynamics of each -atom to predict or understand the properties of defects and their dynamics. +of crystal defect arrangements. On the other hand it is the hope that using descriptors +at a coarser level, i.e. nanometer, micrometer, and larger, it is still possible to find sufficiently +accurate and precise descriptors which avoid that one has to account for the dynamics of each atom to predict or understand the properties of defects and their dynamics. Nevertheless, experience has shown that computational-geometry-based descriptions -when combined with hierarchical clustering/labeling methods, applied on the set of -atoms, turn out to yield useful descriptors. Examples include point, line, surface defects, +when combined with hierarchical clustering/labeling methods, applied on set of +atoms and features turn out to yield useful descriptors. Examples include point, line, surface defects, such as vacancies, solute cluster, dislocations, disconnections, interfaces to name but a few. -.. _CGMSNewAppDef: - -.. New Application Definitions -.. ############################ - -.. Work on handshaking between EPICS-controlled experiments and NeXus resulted -.. in one application definition for temperature dependent IV curve measurements. - -.. :ref:`NXiv_temp`: -.. Application definition for temperature dependent IV curve measurements. - -.. _CGMSNewBC: - -New Base Classes -################# +Base Classes +############ We propose the following base classes, starting with a set of descriptors for frequently used shapes and geometric primitives: @@ -144,7 +128,7 @@ for frequently used shapes and geometric primitives: A collection (or soup) of polyhedra. :ref:`NXcg_roi_set`: - A container to host a number of different type of primitives. + A container to host a number of different types of primitives. :ref:`NXcg_tetrahedron_set`: A collection (or soup) of tetrahedra. @@ -153,7 +137,6 @@ for frequently used shapes and geometric primitives: A collection (or soup) of hexahedra with capabilities to represent also simpler (bounding) boxes for e.g. binary trees. - These base classes make use of new base classes which describe data structures: :ref:`NXcg_face_list_data_structure`: @@ -163,22 +146,21 @@ These base classes make use of new base classes which describe data structures: :ref:`NXcg_half_edge_data_structure`: A half-edge data structure is a useful complementary descriptor for polygon/polyhedra which enables topological analyses and traversal - of the graph how polygons and polyhedra can be described. + of the graph how polygons and polyhedra can alternatively be described. :ref:`NXcg_unit_normal_set`: - As an additional structuring element especially for meshes well-documented - normal information is crucial for distance computations + As an additional structuring element especially for meshes, well-documented + normal information is crucial for distance computations. :ref:`NXcg_geodesic_mesh`: Geodesic meshes are useful for all applications when meshing the surface of a sphere. - :ref:`NXcg_alpha_shape`: + :ref:`NXcg_alpha_complex`: Alpha shapes and alpha wrappings, specifically the special case of the convex hull, are frequently used geometrical models for describing a boundary or edge to a set of geometric primitives. - Furthermore, we propose a few base classes for operations when working with discretized representations of material (area or volume) which can be useful not only for stencil-based methods: @@ -186,7 +168,7 @@ not only for stencil-based methods: :ref:`NXcg_grid`: A grid of cells. - :ref:`NXcg_isocontour`: + :ref:`NXisocontour`: A description for isocontour descriptions. :ref:`NXcg_marching_cubes`: @@ -195,7 +177,7 @@ not only for stencil-based methods: configurations is known to result in different triangle soups. :ref:`NXdelocalization`: - An approach to document procedures in which a scalar field + An approach to document procedures whereby a scalar field is smoothened in a controlled manner. Assuming that these base classes can serve as building blocks, we would like @@ -203,6 +185,9 @@ to test with the proposal also how these base classes can be applied in base classes for specific types of microstructural features and/or utility classes to hold metadata for these features: + :ref:`NXsimilarity_grouping`: + An alias for NXclustering. + :ref:`NXclustering`: A description for clustering of objects (such as atoms or features). @@ -210,8 +195,7 @@ to hold metadata for these features: A set of atoms. :ref:`NXorientation_set`: - A set of rotations to describe the relative orientation of - of members of a set of features/objects. + A set of rotations to describe the relative orientation of members of a set of features/objects. :ref:`NXslip_system_set`: Metadata to a set of slip system/slip system family for @@ -237,10 +221,16 @@ to hold metadata for these features: :ref:`NXms_snapshot_set`: The corresponding class to hold a set of :ref:`NXms_snapshot` objects. + :ref:`NXchemical_composition`: + (Chemical) composition of a sample or a set of things. + Furthermore, we found that it can be useful to have a set of base classes with -which software documents state and gives a summary for users about the performance +which software documents it state and gives a summary for users about the performance and elapsed time measured while processing data. These utility classes include: + :ref:`NXprogram`: + A named and version of a program of library/component of a larger software framework. + :ref:`NXcs_filter_boolean_mask`: A boolean mask. @@ -271,9 +261,3 @@ and elapsed time measured while processing data. These utility classes include: :ref:`NXcs_io_obj`: Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. - - -.. _CGMSNewCommonBC: -.. New Common Base Classes -.. ####################### - diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 8b266f7d2a..19ae498df1 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -16,30 +16,30 @@ B1: Electron microscopy .. _IntroductionEM: Introduction -############## +############ -Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. Realizing that we need to start somewhere, though, we focus for now on the condensed-matter physics, chemical physics of solids, and materials science applications of electron microscopy. As many of the components of the electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. +Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. Realizing that we need to start somewhere, though, we focus for now on the condensed-matter physics, chemical physics of solids, and materials science applications of electron microscopy. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. Partner consortia in the German National Research Data Infrastructure are here NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. -Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with those classical instrument control and data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software, which makes it additionally difficult to keep track of workflows and identify. Not only this it is also often challenging to identify what specific quantities in the control software mean and represent in technical detail and how these -quantities can be connected to the development of ontologies for electron microscopy experiments. +Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it additionally difficult to keep track of workflows and challenging to identify which specific quantities in the control software mean and represent in technical detail which physical quantity (and how these +quantities can be connected to the development of ontologies for electron microscopy experiments). .. _EmNewAppDef: -New Application Definitions -############################ +Application Definitions +####################### -We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet remains easy enough and useful across a variety of instruments, vendors, and instrument use cases. Therefore, we conceptualized first the basic components of an electron microscope and the usual workflow how an electron microscope is used. That is scientists place a specimen/sample into the microscope calibrate the instrument take measurements, may perform experiments or prepare their specimens with a focused ion beam, calibrate again and take other measurements. In between virtually all these steps data are being collected which come from different detectors probing different physical mechanisms of the interaction between electrons with the material of the specimen. The session ends with the scientist removing -the specimen from the instrument or parking it so that the next user can take its time at the instrument. Next, we wrote base classes to describe these steps and events. +We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet remains easy enough and useful across a variety of instruments, technology partners, and instrument use cases. Therefore, we conceptualized first the basic components of an electron microscope and the usual workflow how an electron microscope is used. That is scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments or prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. The session ends with the scientist removing +the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as session on the microscope. Next, we wrote base classes to describe these steps and events. :ref:`NXem`: A general application definition which explores the possibilities of electron microscopes. .. _EmNewBC: -New Base Classes -################# +Base Classes +############ -We developed entirely new base classes. Some of them are also used for other techniques of this proposal but mentioned here for completeness: +We developed entirely new base classes. Some of them are also used for other techniques of this proposal but mentioned here for the sake of completeness: :ref:`NXaberration`: @@ -61,13 +61,13 @@ We developed entirely new base classes. Some of them are also used for other tec A base class serving the possibility to group the components relevant for generating and shaping the electron beam in an electron microscope. :ref:`NXevent_data_em`: - A base class representing a container to hold time-stamped and microscope-state annotated data during a session at an electron microscope. + A base class representing a container to hold time-stamped and microscope-state-annotated data during a session at an electron microscope. :ref:`NXevent_data_em_set`: - A base class to group all `NXevent_data_em` instances. + A base class to group all :ref:`NXevent_data_em` instances. :ref:`NXibeam_column`: - A base class serving the possibility to group the components relevant for generating and shape an ion beam of an instrument with focused ion beam capabilities. + A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused ion beam (milling) capabilities. :ref:`NXimage_set_em_adf` :ref:`NXimage_set_em_bf` @@ -78,23 +78,24 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXimage_set_em_ecci` :ref:`NXimage_set_em_kikuchi` :ref:`NXimage_set_em_ronchigram` - :ref:`NXimage_set_em_se`: - Base classes for storing acquisition details for individual images or stacks of images collected via using e.g. different imaging modes. The suffixes specify **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction (EBSD), **ronchigram** - convergent beam diffraction pattern, and **se** secondary electron. + :ref:`NXimage_set_em_se` + :ref:`NXimage_set_em`: + Base classes for storing acquisition details for individual images or stacks of images collected via using e.g. different imaging modes. The suffixes specify **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction (EBSD), **ronchigram** - convergent beam diffraction pattern, **se** secondary electron, and **generic** images. :ref:`NXinteraction_vol_em`: A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. :ref:`NXlens_em`: - A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. The idea of this base class is to use it in an application definition. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tool which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collect for a lens as a component so that developers of application definitions can take immediate advantage of this work. + A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. :ref:`NXfabrication`: - A base class to bundle manufacturer/vendor-specific details about a component or device of an instrument. + A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. :ref:`NXoptical_system_em`: - A base class to store for now qualitative and quantitative values of frequent interest which are affected by the interplay of the components and state of an electron microscopy. + A base class to store for now qualitative and quantitative values of frequent interest which are affected by the interplay of the components and state of an electron microscope. Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. :ref:`NXpeak`: @@ -104,7 +105,7 @@ We developed entirely new base classes. Some of them are also used for other tec A base class to describe details about a pump in an instrument. :ref:`NXscanbox_em`: - A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. + A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. :ref:`NXspectrum_set_em_eels` :ref:`NXspectrum_set_em_xray` @@ -113,17 +114,37 @@ We developed entirely new base classes. Some of them are also used for other tec Base classes comparable to NXimage_set_em but for different techniques resulting in spectra. The suffixes specify **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, and **cathodolum** cathodoluminescence. :ref:`NXstage_lab`: - As it was mentioned for atom probe microscopy this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. + As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. .. _EmNewCommonBC: -New Common Base Classes -####################### +Common Base Classes +################### We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em` and :ref:`NXxraylens` have similarities. It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general -base class lenses. We see understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. +base class lenses. We understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. + +The first result of such consolidations is the NXem_ebsd partner application definition. + +Partner application definitions +############################### + +A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize these pieces of information in an own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that the pattern are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. in post-processing of these data. These numerical and algorithmic steps define computational workflows were data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints trigger the need for having an own but almost similar application definition. For this reason we use the concept of partner application definition which have fields/links where specifically relevant sources of information are connected to e.g. NXem. + +The first partner application definition is NXem_ebsd. + + :ref:`NXem_ebsd`: + Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- and four-dimensional case. + +Several new base classes are used by this application definition. + + :ref:`NXem_ebsd_conventions`: + A collection of reference frames and rotation conventions necessary to interpret the alignment and orientation data. + + :ref:`NXem_ebsd_crystal_structure_model`: + A description of a crystalline phase/structure used for a forward simulation using kinetic or dynamic diffraction theory to generate simulated diffraction pattern against which measured pattern can be indexed. .. _EmDeprecated: diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst index 77702588bf..91f79405fa 100644 --- a/manual/source/north-structure.rst +++ b/manual/source/north-structure.rst @@ -18,33 +18,33 @@ Nomad Remote Tools Hub (NORTH) Introduction ############## -NORTH (the NOMAD OASIS Remote Tools Hub) is a NOMAD OASIS service which makes -preconfigured scientific software of different communities available coupled -to the OASIS and accessible via the webbrowser. This part of the proposal documents +NORTH (the NOMAD Oasis Remote Tools Hub) is a NOMAD Oasis service which makes +preconfigured scientific software of different communities available and coupled +to Oasis and accessible via the webbrowser. This part of the proposal documents examples for specific NeXus-related work to some of the tools and containers available in NORTH. -One tool is the paraprobe-toolbox software package in the the apm tools container. + +apmtools +######## + +One tool is the paraprobe-toolbox software package in the the apmtools container. The software is developed by `M. Kühbach et al. `_. Here we show how NeXus is used to consistently define application definitions -for scientific software in the field of atom probe. - -In this community the paraprobe-toolbox is an example of an open-source parallelized +for scientific software in the field of atom probe. In this community the paraprobe-toolbox is an example of an open-source parallelized software for analyzing point cloud data, for assessing meshes in 3D continuum space, and analyzing the effects of parameterization on descriptors about the microstructure of materials which were studied with atom probe microscopy. -The need for a thorough documentation of the tools in not only the paraprobe-toolbox -was motivated by several needs: +The need for a thorough documentation of the tools in not only the paraprobe-toolbox was motivated by several needs: First, users of software would like to better understand and also be able to -study themselves which individual parameter and settings for each tool exists -and configuring these affects their analyses quantitatively. +study themselves which individual parameter and settings for each tool exist +and how configuring these affects their analyses quantitatively. -Second, scientific software like those of the paraprobe-toolbox implement a -numerical workflow where multiple data sources and previous analysis results -are processed and carried through more involved analysis with several steps. +Second, scientific software like the tools in the paraprobe-toolbox implement a +numerical/algorithmical (computational) workflow whereby data from multiple input sources (like previous analysis results) are processed and carried through more involved analysis within several steps inside the tool. The tool then creates output as files. Individual tools are developed in C/C++ and/or Python. Here, having a possibility for provenance tracking is useful as it is one component and requirement for @@ -53,15 +53,14 @@ to fullfill better the "R", i.e. reproducibility of daily FAIR research practice The paraprobe-toolbox is one example of a software which implements a workflow via a sequence of operations executed within a jupyter notebook -(or Python script respectively). Specifically, individual tools are chained -and convenience function are available to create well-defined input/configuration +(or Python script respectively). Specifically, individual tools are chained. Convenience functions are available to create well-defined input/configuration files for each tool. These config files instruct the tool upon processing. In this design, each workflow step (with a tool) is in fact a pair (or triple) of at least two sub-steps: i) the creation of a configuration file, ii) the actual analysis using the Python/or C/C++ tools, -iii) the optional of the results in the HDF5 file from each tool run with -other software in Python or Matlab for instance. +iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 files generated from each tool run using +other software. .. _WhatHasBeenAchieved: @@ -69,15 +68,15 @@ other software in Python or Matlab for instance. What has been achieved so far? ############################## -This proposal summarizes the first (of two) steps which change the interface and +This proposal summarizes both of the steps which we worked on between Q3/2022-Q1/2023 to change the interface and file interaction in all tools of the paraprobe-toolbox to accept exclusively -well-defined configuration files and yield specific output. +well-defined configuration files and yield exclusively specific output. -Data and metadata between the tools are exchanged with HDF5/NeXus files. +Data and metadata between the tools are exchanged with NeXus/HDF5 files. Specifically, we created for each tool an application definition (see below) which details all possible settings and options for the configuration as to guide users. The config(uration) files are HDF5 files, whose content matches -to the naming conventions of the respective application definition for each tool. +to the naming conventions of the respective `config` application definition for each tool. As an example NXapm_paraprobe_config_surfacer specifies how a configuration file for the paraprobe-surfacer tool should be formatted and which parameter it contains. @@ -89,17 +88,15 @@ processing chain/workflow. As an example, a user may first range their reconstruction and then compute correlation functions. The config file for the ranging tool stores the files which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the ion type labels stored. +The ranging tool generates a results file with the ion type labels stored. This results file is formatted according to the tool-specific `results` application definition. This results file and the reconstruction is imported by the spatial statistics +tool which again keeps track of all files. -This results file and the reconstruction is imported by the spatial statistics -tool which again keeps track of all files. This makes it possible to rigorously +This design makes it possible to rigorously trace which numerical results were achieved with a specific chain of input and settings using specifically-versioned tools. We understand that this additional handling of metadata and provenance tracking -may not be at first glance super relevant for scientists or appear and unnecessary -feature. There is indeed an additional layer of work for the development -and maintenance of the software. +may not be at first glance super relevant for scientists or appears to be an unnecessarily complex feature. There is indeed an additional layer of work which came with the development and maintenance of this functionality. However, we are convinced that this is the preferred way of performing software development and data analyses as it enables users to take advantage of a completely @@ -107,8 +104,10 @@ automated provenance tracking which happens silently in the background. .. _ApmParaprobeAppDef: -New Application Definitions -############################ +Application Definitions +####################### + +Firstly, we define application definitions for the input side (configuration) of each tool. :ref:`NXapm_paraprobe_config_transcoder`: Configuration of paraprobe-transcoder @@ -118,6 +117,10 @@ New Application Definitions Configuration of paraprobe-ranger Apply ranging definitions and explore possible molecular ions. + :ref:`NXapm_paraprobe_config_selector`: + Configuration of paraprobe-selector + Defining complex spatial regions-of-interest to filter reconstructed datasets. + :ref:`NXapm_paraprobe_config_surfacer`: Configuration of paraprobe-surfacer Create a model for the edge of a point cloud via convex hulls, alpha shapes. @@ -150,29 +153,73 @@ New Application Definitions Import cluster analysis results of IVAS/APSuite and perform clustering analyses in a Python ecosystem. +Secondly, we define application definitions for the output side (results) of each tool. + + :ref:`NXapm_paraprobe_config_transcoder`: + Results of paraprobe-transcoder + Store reconstructed positions, ions, and charge states. + + :ref:`NXapm_paraprobe_config_ranger`: + Results of paraprobe-ranger + Store applied ranging definitions and combinatorial analyses of all possible iontypes. + + :ref:`NXapm_paraprobe_config_selector`: + Results of paraprobe-selector + Store which points are inside or on the boundary of complex spatial regions-of-interest. + + :ref:`NXapm_paraprobe_config_surfacer`: + Results of paraprobe-surfacer + Store triangulated surface meshes of models for the edge of a dataset. + + :ref:`NXapm_paraprobe_config_distancer`: + Results of paraprobe-distancer + Store analytical distances between ions to a set of triangles. + + :ref:`NXapm_paraprobe_config_tessellator`: + Results of paraprobe-tessellator + Store volume of all Voronoi cells about each ion in the dataset. + + :ref:`NXapm_paraprobe_config_nanochem`: + Results of paraprobe-nanochem + Store all results of delocalization, isosurface, and interface detection algorithms, + store all extracted triangulated surface meshes of found microstructural features, + store composition profiles and corresponding geometric primitives (ROIs). + + :ref:`NXapm_paraprobe_config_intersector`: + Results of paraprobe-intersector + Store graph of microstructural features and relations/link identified between them. + + :ref:`NXapm_paraprobe_config_spatstat`: + Results of paraprobe-spatstat + Store spatial correlation functions. + + :ref:`NXapm_paraprobe_config_clusterer`: + Results of paraprobe-clusterer + Store results of cluster analyses. + .. _ApmParaprobeNewBC: -New Base Classes -################# +Base Classes +############ We envision that the above-mentioned definitions can be useful not only to take inspiration for other software tools in the field of atom probe but also to support a discussion towards a stronger standardization of the vocabulary used. Therefore, we are happy for your comments and suggestions on this and the related -pages via the hypothesis web annotation service. +pages via the hypothesis web annotation service or as your issues posted on GitHub. We are convinced that the majority of data analyses in atom probe use an in fact common set of operations and conditions on the input data even though this might not be immediately evident. In particular this is not -the case for some community build tools with a very specific scope where oftentimes -the algorithms hardcoded. A typically example is a reseacher who implements a -ranging tool and uses that all the examples are on a specific material. -We are convinced it is better to follow a much more generalized approach. +the case for some community built tools with a very specific scope where oftentimes +the algorithms are hardcoded for specific material systems. A typical example is a +reseacher who implements a ranging tool and uses that all the examples are on a +specific material. We are convinced it is better to follow a much more generalized approach. -In this spirit, we propose the following base classes as examples how very -flexible constraints can be implemented which restrict which ions in the dataset -should be processed or not. We see that these suggestion complement the -proposal on computational geometry base classes: +In this spirit, we propose the following base classes and the above application +definitions as examples how very flexible constraints can be implemented which +restrict which ions in the dataset should be processed or not. We see that these +suggestions complement the proposal on computational geometry base classes: :ref:`NXapm_input_reconstruction`: A description from which file the reconstructed ion positions are imported. @@ -180,8 +227,8 @@ proposal on computational geometry base classes: :ref:`NXapm_input_ranging`: A description from which file the ranging definitions are imported. The design of the ranging definitions is, thanks to :ref:`NXion` so - general that all possible nuclids be they observationally stable - or radioactive can be considered. + general that all possible nuclids can be considered, be they observationally stable, + be they radioactive or transuranium nuclids. A detailed inspection of spatial and other type of filters used in atom probe microscopy data analysis revealed that it is better to define atom probe agnostic, i.e. more @@ -204,25 +251,7 @@ general filters: or hit multiplicity. In summary, we report with this proposal our experience made in an experimental -project that is about using NeXus for standardizing a certain scientific software. +project that is about using NeXus for standardizing a set of non-trivial scientific software tools. During the implementation we learned that for handling computational geometry and microstructure-related terms many subtilities have to be considered which -makes a controlled vocabulary valuable not only to avoid reimplementing the wheel. - - -.. NextStep: - -Next Step -#################### - -This also makes us confident to take the next step which will be to change also -the results file of each tool. The following two application definition are -not yet implemented in the tools' source code but give an idea for development -purposes how such application definitions and description of created files could -look like. - - :ref:`NXapm_paraprobe_results_transcoder`: - - :ref:`NXapm_paraprobe_results_ranger`: - - +makes a controlled vocabulary valuable not only to avoid a reimplementing of the wheel. From b5d25fb3e0734a4f8c27399409820ea04491d97e Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Fri, 17 Mar 2023 13:15:49 +0100 Subject: [PATCH 113/203] Additional fixes in response to the discussion of the PR24 --- applications/NXmx.nxdl.xml | 12 ++-- .../NXcg_isocontour.nxdl.xml | 64 ------------------- .../NXelectronanalyser.nxdl.xml | 6 +- .../NXapm_paraprobe_results_nanochem.yaml | 2 +- .../nyaml/NXcg_isocontour.yaml | 30 --------- .../nyaml/NXimage_set_em_adf.yaml | 28 ++++---- .../nyaml/NXisocontour.yaml | 2 +- manual/source/apm-structure.rst | 2 +- manual/source/north-structure.rst | 20 +++--- 9 files changed, 38 insertions(+), 128 deletions(-) delete mode 100644 contributed_definitions/NXcg_isocontour.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcg_isocontour.yaml diff --git a/applications/NXmx.nxdl.xml b/applications/NXmx.nxdl.xml index 6c159203fc..a1d544ccf7 100644 --- a/applications/NXmx.nxdl.xml +++ b/applications/NXmx.nxdl.xml @@ -139,7 +139,7 @@ - + @@ -316,7 +316,7 @@ - + @@ -521,7 +521,7 @@ - + @@ -541,7 +541,7 @@ - + @@ -554,7 +554,7 @@ - + @@ -566,7 +566,7 @@ - + diff --git a/contributed_definitions/NXcg_isocontour.nxdl.xml b/contributed_definitions/NXcg_isocontour.nxdl.xml deleted file mode 100644 index c426f20dea..0000000000 --- a/contributed_definitions/NXcg_isocontour.nxdl.xml +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the description. - - - - - Computational geometry description of isocontouring/phase-fields in Euclidean space. - - Iso-contouring algorithms such as MarchingCubes and others are frequently - used to segment d-dimensional regions into regions where intensities are - lower or higher than a threshold value, the so-called isovalue. - - Frequently in computational materials science phase-field methods are - used which generate data on discretized grids. Isocontour algorithms - are often used in such context to pinpoint the locations of microstructural - features from this implicit phase-field-variable-based description. - - One of the key intentions of this base class is to provide a starting point - for scientists from the phase-field community (condensed matter physicists, - and materials engineers) to incentivize that also phase-field simulation - data could be described with NeXus, provided base classes such as the this one - get further extend according to the liking of the phase-field community. - - - - - The discretized grid on which the iso-contour algorithm operates. - - - - - The threshold or iso-contour value. - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 3b50270044..a08e610fb2 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -28,13 +28,13 @@ - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) + Number of fast axes (axes acquired symultaneously, without scanning + a physical quantity) - Number of slow axes (axes acquired scanning a pysical quantity) + Number of slow axes (axes acquired scanning a physical quantity) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml index 9233d3efec..271a9c7d68 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml @@ -591,7 +591,7 @@ NXapm_paraprobe_results_nanochem: rank: 1 dim: [[1, 3]] # ##MK:: - iso_surface(NXisosurface): + iso_surface(NXisocontour): exists: optional doc: | An iso-surface is the boundary between two regions across which diff --git a/contributed_definitions/nyaml/NXcg_isocontour.yaml b/contributed_definitions/nyaml/NXcg_isocontour.yaml deleted file mode 100644 index cfb693efb9..0000000000 --- a/contributed_definitions/nyaml/NXcg_isocontour.yaml +++ /dev/null @@ -1,30 +0,0 @@ -category: base -doc: | - Computational geometry description of isocontouring/phase-fields in Euclidean space. - - Iso-contouring algorithms such as MarchingCubes and others are frequently - used to segment d-dimensional regions into regions where intensities are - lower or higher than a threshold value, the so-called isovalue. - - Frequently in computational materials science phase-field methods are - used which generate data on discretized grids. Isocontour algorithms - are often used in such context to pinpoint the locations of microstructural - features from this implicit phase-field-variable-based description. - - One of the key intentions of this base class is to provide a starting point - for scientists from the phase-field community (condensed matter physicists, - and materials engineers) to incentivize that also phase-field simulation - data could be described with NeXus, provided base classes such as the this one - get further extend according to the liking of the phase-field community. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality of the description. -NXcg_isocontour: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - grid(NXcg_grid): - doc: | - The discretized grid on which the iso-contour algorithm operates. - isovalue(NX_NUMBER): - doc: The threshold or iso-contour value. - unit: NX_ANY diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml index de787e3cdd..371515db31 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml @@ -45,41 +45,45 @@ NXimage_set_em_adf: doc: Annulus outer half angle unit: NX_ANGLE stack(NXdata): - doc: Annular dark field image stack. + doc: | + Annular dark field image stack. # \@signal: intensity # \@axes: [image_id, ypos, xpos] # \@xpos_indices: 2 # \@ypos_indices: 1 # \@image_indices: 0 - intensity(NX_NUMBER): + data_counts(NX_NUMBER): doc: Image intensity values. unit: NX_UNITLESS dimensions: rank: 3 dim: [[1, n_images], [2, n_y], [3, n_x]] - \@long_name: - doc: Image intensities - image_id(NX_UINT): - doc: Image identifier + axis_image_identifier(NX_UINT): + doc: | + Image identifier unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_images]] \@long_name: doc: Image ID. - ypos(NX_NUMBER): - doc: Pixel center of mass position y-coordinates. + axis_y(NX_NUMBER): + doc: | + Pixel center of mass along y direction. unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_y]] \@long_name: - doc: Label for the y axis. - xpos(NX_NUMBER): - doc: Pixel center of mass position x-coordinates. + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + doc: | + Pixel center of mass along x direction. unit: NX_LENGTH dimensions: rank: 1 dim: [[1, n_x]] \@long_name: - doc: Label for the x axis. + doc: | + Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXisocontour.yaml b/contributed_definitions/nyaml/NXisocontour.yaml index cfb693efb9..9bdb30cb13 100644 --- a/contributed_definitions/nyaml/NXisocontour.yaml +++ b/contributed_definitions/nyaml/NXisocontour.yaml @@ -19,7 +19,7 @@ doc: | symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. d: The dimensionality of the description. -NXcg_isocontour: +NXisocontour: dimensionality(NX_POSINT): unit: NX_UNITLESS grid(NXcg_grid): diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 1147995d7b..037459c801 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -61,7 +61,7 @@ We developed new base classes to structure the application definition into lab e :ref:`NXstage_lab`: A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an - atom probe microscope or especially an electron microscop3 offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and one in an atom probe instrument, given that both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. + atom probe microscope or especially an electron microscope offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and one in an atom probe instrument, given that both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst index 91f79405fa..edf9527c50 100644 --- a/manual/source/north-structure.rst +++ b/manual/source/north-structure.rst @@ -155,45 +155,45 @@ Firstly, we define application definitions for the input side (configuration) of Secondly, we define application definitions for the output side (results) of each tool. - :ref:`NXapm_paraprobe_config_transcoder`: + :ref:`NXapm_paraprobe_results_transcoder`: Results of paraprobe-transcoder Store reconstructed positions, ions, and charge states. - :ref:`NXapm_paraprobe_config_ranger`: + :ref:`NXapm_paraprobe_results_ranger`: Results of paraprobe-ranger Store applied ranging definitions and combinatorial analyses of all possible iontypes. - :ref:`NXapm_paraprobe_config_selector`: + :ref:`NXapm_paraprobe_results_selector`: Results of paraprobe-selector Store which points are inside or on the boundary of complex spatial regions-of-interest. - :ref:`NXapm_paraprobe_config_surfacer`: + :ref:`NXapm_paraprobe_results_surfacer`: Results of paraprobe-surfacer Store triangulated surface meshes of models for the edge of a dataset. - :ref:`NXapm_paraprobe_config_distancer`: + :ref:`NXapm_paraprobe_results_distancer`: Results of paraprobe-distancer Store analytical distances between ions to a set of triangles. - :ref:`NXapm_paraprobe_config_tessellator`: + :ref:`NXapm_paraprobe_results_tessellator`: Results of paraprobe-tessellator Store volume of all Voronoi cells about each ion in the dataset. - :ref:`NXapm_paraprobe_config_nanochem`: + :ref:`NXapm_paraprobe_results_nanochem`: Results of paraprobe-nanochem Store all results of delocalization, isosurface, and interface detection algorithms, store all extracted triangulated surface meshes of found microstructural features, store composition profiles and corresponding geometric primitives (ROIs). - :ref:`NXapm_paraprobe_config_intersector`: + :ref:`NXapm_paraprobe_results_intersector`: Results of paraprobe-intersector Store graph of microstructural features and relations/link identified between them. - :ref:`NXapm_paraprobe_config_spatstat`: + :ref:`NXapm_paraprobe_results_spatstat`: Results of paraprobe-spatstat Store spatial correlation functions. - :ref:`NXapm_paraprobe_config_clusterer`: + :ref:`NXapm_paraprobe_results_clusterer`: Results of paraprobe-clusterer Store results of cluster analyses. From 0692a2649c2ecfeea997728958762a4807c71cfd Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Fri, 17 Mar 2023 13:17:44 +0100 Subject: [PATCH 114/203] minor fix 1 --- applications/NXmx.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/applications/NXmx.nxdl.xml b/applications/NXmx.nxdl.xml index a1d544ccf7..0c71dab11f 100644 --- a/applications/NXmx.nxdl.xml +++ b/applications/NXmx.nxdl.xml @@ -566,7 +566,7 @@ - + From bb4d36a529ad8a5d444b032a47df760c01c9955e Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Fri, 17 Mar 2023 13:26:48 +0100 Subject: [PATCH 115/203] reconverted changed yamls to nxdls --- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 2 +- .../NXimage_set_em_adf.nxdl.xml | 21 +++++++------------ contributed_definitions/NXisocontour.nxdl.xml | 2 +- 3 files changed, 10 insertions(+), 15 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index 2857ae7904..7d7b7b786e 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -720,7 +720,7 @@ - + An iso-surface is the boundary between two regions across which the magnitude of a scalar field falls below/exceeds a threshold diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index 1301c297d8..56edf87880 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -98,7 +98,7 @@ Annular dark field image stack. - + Image intensity values. @@ -108,12 +108,7 @@ - - - Image intensities - - - + Image identifier @@ -126,29 +121,29 @@ - + - Pixel center of mass position y-coordinates. + Pixel center of mass along y direction. - Label for the y axis. + Coordinate along y direction. - + - Pixel center of mass position x-coordinates. + Pixel center of mass along x direction. - Label for the x axis. + Coordinate along x direction. diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index c426f20dea..4f5a59c7ef 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. From 718ceee0e25ce741836706ba5b634a98e04e81b0 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Fri, 17 Mar 2023 17:32:23 +0100 Subject: [PATCH 116/203] Manual fixes of otherwise inconsistencies which break the documentation generation pipeline (some rank inconsistencies/errors, a missing line break after doc xml control tag not introduced by an error in nyaml2nxdl (rubel is about to fix this), as well as some merge conflict marker text, added nexus-fairmat-proposal make instruction to bypass changes in the manual build process between Sept22 and March23 by NIAC (and others) --- Makefile | 4 + ...apm_paraprobe_results_intersector.nxdl.xml | 2 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 5 +- .../NXcollectioncolumn.nxdl.xml | 5 +- contributed_definitions/NXdeflector.nxdl.xml | 3 +- .../NXdispersive_material.nxdl.xml | 74 ------------------- contributed_definitions/NXdistortion.nxdl.xml | 3 +- .../NXelectronanalyser.nxdl.xml | 3 +- contributed_definitions/NXem_ebsd.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 5 +- .../NXmanipulator.nxdl.xml | 5 +- contributed_definitions/NXmpes.nxdl.xml | 5 +- .../NXmpes_liquid.nxdl.xml | 5 +- .../NXms_dislocation_set.nxdl.xml | 3 - .../NXms_interface_set.nxdl.xml | 3 - .../NXregistration.nxdl.xml | 3 +- .../NXspindispersion.nxdl.xml | 5 +- .../NXtransmission.nxdl.xml | 3 +- .../NXapm_paraprobe_results_intersector.yaml | 2 +- .../NXapm_paraprobe_results_nanochem.yaml | 4 +- contributed_definitions/nyaml/NXem_ebsd.yaml | 2 +- .../nyaml/NXms_dislocation_set.yaml | 3 +- .../nyaml/NXms_interface_set.yaml | 2 +- 24 files changed, 46 insertions(+), 109 deletions(-) diff --git a/Makefile b/Makefile index 5a52d92072..69075caeba 100644 --- a/Makefile +++ b/Makefile @@ -83,6 +83,10 @@ all :: @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/manual/build/html/index.html`" @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus.pdf`" +nexus-fairmat-proposal :: + $(MAKE) clean + $(MAKE) prepare + $(SPHINX) -b html $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html # NeXus - Neutron and X-ray Common Data Format # diff --git a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml index 83085fa9eb..d7a9ed0a2d 100644 --- a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml @@ -294,7 +294,7 @@ The second column encodes how many clusters with as many members exist. - + diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index 7d7b7b786e..b8eb80747a 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -1086,12 +1086,12 @@ - + - + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 112ede463b..86a0453c7e 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -24,7 +24,7 @@ - The symbols used in the schema to specify e.g. dimensions of arrays + The symbols used in the schema to specify e.g. dimensions of arrays @@ -42,7 +42,8 @@ - Subclass of NXprocess to describe post-processing calibrations. + + Subclass of NXprocess to describe post-processing calibrations. diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 7afb20afee..c8bd717074 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -22,8 +22,9 @@ # For further information, see http://www.nexusformat.org --> - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + + Subclass of NXelectronanalyser to describe the electron collection + column of a photoelectron analyser. diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml index 9b185b773e..f362abb3fd 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -22,7 +22,8 @@ # For further information, see http://www.nexusformat.org --> - Deflectors as they are used e.g. in an electron analyser. + + Deflectors as they are used e.g. in an electron analyser. diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index 9d356e33a0..5b41b10dca 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -96,21 +96,13 @@ -<<<<<<< HEAD - -======= ->>>>>>> nxdl_consulting_with_rub A text description of this reference, e.g. `E. Example et al, The mighty example, An example journal 50 (2023), 100` -<<<<<<< HEAD - -======= ->>>>>>> nxdl_consulting_with_rub @@ -126,34 +118,13 @@ -<<<<<<< HEAD - - -======= ->>>>>>> nxdl_consulting_with_rub -<<<<<<< HEAD - - - - - - - - - - - - - - -======= @@ -168,7 +139,6 @@ ->>>>>>> nxdl_consulting_with_rub @@ -186,34 +156,13 @@ -<<<<<<< HEAD - - -======= ->>>>>>> nxdl_consulting_with_rub -<<<<<<< HEAD - - - - - - - - - - - - - - -======= @@ -228,7 +177,6 @@ ->>>>>>> nxdl_consulting_with_rub @@ -247,34 +195,13 @@ -<<<<<<< HEAD - - -======= ->>>>>>> nxdl_consulting_with_rub -<<<<<<< HEAD - - - - - - - - - - - - - - -======= @@ -289,7 +216,6 @@ ->>>>>>> nxdl_consulting_with_rub diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml index dc5e235e0d..b47f0aa734 100644 --- a/contributed_definitions/NXdistortion.nxdl.xml +++ b/contributed_definitions/NXdistortion.nxdl.xml @@ -42,7 +42,8 @@ - Subclass of NXprocess to describe post-processing distortion correction. + + Subclass of NXprocess to describe post-processing distortion correction. diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index a08e610fb2..0ef6f51315 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -38,7 +38,8 @@ - Subclass of NXinstrument to describe a photoelectron analyser. + + Subclass of NXinstrument to describe a photoelectron analyser. diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 06e4db918b..3f25640534 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -1441,7 +1441,7 @@ RGB array, with resolution per fastest changing value defined by bitdepth. - + diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 69efa4e8e8..d408627e24 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -22,8 +22,9 @@ # For further information, see http://www.nexusformat.org --> - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. + + Subclass of NXelectronanalyser to describe the energy dispersion + section of a photoelectron analyser. diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index 395f0c0682..ef2d40ad81 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -22,8 +22,9 @@ # For further information, see http://www.nexusformat.org --> - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. + + Extension of NXpositioner to include fields to describe the use of + manipulators in photoemission experiments. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index e628d97d8b..ff13c5e93d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -22,8 +22,9 @@ # For further information, see http://www.nexusformat.org --> - This is the most general application definition for multidimensional - photoelectron spectroscopy. + + This is the most general application definition for multidimensional + photoelectron spectroscopy. diff --git a/contributed_definitions/NXmpes_liquid.nxdl.xml b/contributed_definitions/NXmpes_liquid.nxdl.xml index 53e8c3164a..b207c7aee5 100644 --- a/contributed_definitions/NXmpes_liquid.nxdl.xml +++ b/contributed_definitions/NXmpes_liquid.nxdl.xml @@ -22,8 +22,9 @@ # For further information, see http://www.nexusformat.org --> - This is the application definition for multidimensional photoelectron - spectroscopy on liquids + + This is the application definition for multidimensional + photoelectron spectroscopy on liquids diff --git a/contributed_definitions/NXms_dislocation_set.nxdl.xml b/contributed_definitions/NXms_dislocation_set.nxdl.xml index 18dec9ace5..8e42f40d58 100644 --- a/contributed_definitions/NXms_dislocation_set.nxdl.xml +++ b/contributed_definitions/NXms_dislocation_set.nxdl.xml @@ -98,7 +98,4 @@ useful as a wrapper class in which specific details about dislocations can be stored in an arbitrarily nested manner. - - A starting point for the discussion. - diff --git a/contributed_definitions/NXms_interface_set.nxdl.xml b/contributed_definitions/NXms_interface_set.nxdl.xml index 5c02478505..bdea106fca 100644 --- a/contributed_definitions/NXms_interface_set.nxdl.xml +++ b/contributed_definitions/NXms_interface_set.nxdl.xml @@ -105,7 +105,4 @@ useful as a wrapper class in which specific details about interfaces can be stored in an arbitrarily nested manner. - - A starting point for the discussion. - diff --git a/contributed_definitions/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml index 9c37e69a55..c725562743 100644 --- a/contributed_definitions/NXregistration.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -22,7 +22,8 @@ # For further information, see http://www.nexusformat.org --> - Describes image registration procedures. + + Describes image registration procedures. diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index 4e8673932c..6539130950 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -22,8 +22,9 @@ # For further information, see http://www.nexusformat.org --> - Subclass of NXelectronanalyser to describe the spin filters in photoemission - experiments. + + Subclass of NXelectronanalyser to describe the spin filters in + photoemission experiments. diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index d7b29a8bab..8362cce7d0 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -37,7 +37,8 @@ - Application definition for transmission experiments + + Application definition for transmission experiments diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml index 36aa9b81d5..99e01e7eae 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml @@ -228,7 +228,7 @@ NXapm_paraprobe_results_intersector: exist. unit: NX_UNITLESS dimensions: - rank: 1 + rank: 2 dim: [[1, n_total], [2, 2]] # ##MK::add results from NXapm_paraprobe_results_clusterer diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml index 271a9c7d68..0f1ab53e11 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml @@ -951,12 +951,12 @@ NXapm_paraprobe_results_nanochem: xdmf_topology(NX_UINT): unit: NX_UNITLESS dimensions: - rank: 2 + rank: 1 dim: [[1, k]] xdmf_feature_identifier(NX_UINT): unit: NX_UNITLESS dimensions: - rank: 2 + rank: 1 dim: [[1, k]] objects_close_to_edge(NXms_three_d_feature_set): exists: optional diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 055861d53a..c641f99d47 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -1466,7 +1466,7 @@ NXem_ebsd: defined by bitdepth. unit: NX_UNITLESS dimensions: - rank: 3 + rank: 4 dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 # in axes fast to fastest diff --git a/contributed_definitions/nyaml/NXms_dislocation_set.yaml b/contributed_definitions/nyaml/NXms_dislocation_set.yaml index 5bf8e65536..f0fe08f36f 100644 --- a/contributed_definitions/nyaml/NXms_dislocation_set.yaml +++ b/contributed_definitions/nyaml/NXms_dislocation_set.yaml @@ -72,7 +72,8 @@ doc: | symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. NXms_dislocation_set: - doc: A starting point for the discussion. +# doc: A starting point for the discussion. + # doc: Needs to be extended based on the NXannealing appdef. # lets sketch for each of the four above-mentioned frequent use cases what # could be relevant to be nested inside such base classes diff --git a/contributed_definitions/nyaml/NXms_interface_set.yaml b/contributed_definitions/nyaml/NXms_interface_set.yaml index e44ab2accd..c2028f6e7c 100644 --- a/contributed_definitions/nyaml/NXms_interface_set.yaml +++ b/contributed_definitions/nyaml/NXms_interface_set.yaml @@ -79,7 +79,7 @@ doc: | symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. NXms_interface_set: - doc: A starting point for the discussion. +# doc: A starting point for the discussion. # needs to be extended based on the NXannealing appdef. # lets sketch for each of the four above-mentioned frequent use cases what From 11be3ca13b3d966f2bd236512d5c42af96447450 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 20 Mar 2023 14:08:29 +0100 Subject: [PATCH 117/203] Fixing formatting issues revealed by the nxdl to rst conversion and added NXms application definition --- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 14 +- contributed_definitions/NXliquid_jet.nxdl.xml | 69 -- .../NXmpes_liquid.nxdl.xml | 412 ------------ contributed_definitions/NXms.nxdl.xml | 444 +++++++++++++ .../NXms_score_results.nxdl.xml | 627 ++++++++++++++++++ .../NXapm_paraprobe_results_nanochem.yaml | 12 +- .../nyaml/NXliquid_jet.yaml | 47 -- .../nyaml/NXmpes_liquid.yaml | 267 -------- contributed_definitions/nyaml/NXms.yaml | 455 +++++++++++++ .../nyaml/NXms_score_results.yaml | 571 ++++++++++++++++ manual/source/apm-structure.rst | 14 +- manual/source/cgms-structure.rst | 44 +- manual/source/em-structure.rst | 19 +- manual/source/mpes-structure.rst | 36 +- manual/source/sed/landing-page.rst | 59 -- manual/source/transport-structure.rst | 28 +- 16 files changed, 2189 insertions(+), 929 deletions(-) delete mode 100644 contributed_definitions/NXliquid_jet.nxdl.xml delete mode 100644 contributed_definitions/NXmpes_liquid.nxdl.xml create mode 100644 contributed_definitions/NXms.nxdl.xml create mode 100644 contributed_definitions/NXms_score_results.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXliquid_jet.yaml delete mode 100644 contributed_definitions/nyaml/NXmpes_liquid.yaml create mode 100644 contributed_definitions/nyaml/NXms.yaml create mode 100644 contributed_definitions/nyaml/NXms_score_results.yaml delete mode 100644 manual/source/sed/landing-page.rst diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index b8eb80747a..37034ba761 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -891,7 +891,7 @@ Triangle normals are oriented in the direction of the gradient vector of the local delocalized scalar field. - :mathref:`$\sum_{x, y, z} {\nabla{c}_i}^2$`. + :math:`$\sum_{x, y, z} {\nabla{c}_i}^2$`. @@ -1023,7 +1023,7 @@ - + Details for features which are (closed) objects. Identifier have to exist in feature_identifier @@ -1097,7 +1097,7 @@ - + Details for all those objects close to edge, i.e. those which have at least one ion which lays closer to a modelled edge @@ -1180,7 +1180,7 @@ - + Details for all those objects far from edge, i.e. those whose ions lay all at least threshold distant from a @@ -1264,7 +1264,7 @@ - + Details for features which are so-called proxies, i.e. objects which have been reconstructed and combinatorially closed with @@ -1283,7 +1283,7 @@ - + Details for those proxies close to edge, i.e. those which have at least one ion which lays closer to a modelled edge @@ -1365,7 +1365,7 @@ - + Details for those proxies far from edge, i.e. those whose ions lay all at least threshold distant from a diff --git a/contributed_definitions/NXliquid_jet.nxdl.xml b/contributed_definitions/NXliquid_jet.nxdl.xml deleted file mode 100644 index 94e038bbba..0000000000 --- a/contributed_definitions/NXliquid_jet.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - Description of a liquid jet - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXmpes_liquid.nxdl.xml b/contributed_definitions/NXmpes_liquid.nxdl.xml deleted file mode 100644 index b207c7aee5..0000000000 --- a/contributed_definitions/NXmpes_liquid.nxdl.xml +++ /dev/null @@ -1,412 +0,0 @@ - - - - - - This is the application definition for multidimensional - photoelectron spectroscopy on liquids - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (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. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(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. - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - - - - Transformations describing the transformation chain to the - liqudjet leaf. - - - - The normal of the liquidjet leaf. - - - - The vector normal to the liquidjet leaf. - - - - - Pointer to the previous matrices in the transformation chain - to relate the normal to the rest of the instrument. - If this is '.' the vector attribute only specifies the normal vector - without specifying the position of the liquidjet leaf with respect - to the instrument. - - - - - - - Solvent material of the liquidjet. - This also accounts for multiple jets if more - than one solvent is given. - - - - - - - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml new file mode 100644 index 0000000000..1b59ad4020 --- /dev/null +++ b/contributed_definitions/NXms.nxdl.xml @@ -0,0 +1,444 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of boundaries of the bounding box or primitive to domain. + + + + + Number of parameter required for chosen orientation parameterization. + + + + + Number of texture components identified. + + + + + Application definition, spatiotemporal characterization of a microstructure. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment or computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the workflow (experiment/analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + + + + + + + + + + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe a microstructure. + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + + + + + + + + + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Using one NXtransformations + instance per base vector. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + + + + + + + A boundary to the volume element. + Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. + + + + How many distinct boundaries are distinguished. Value required equal to n_b. + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + + + + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + Collection of microstructural data observed/simulated. + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + + + + + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + + + + + + + + + + + + + + + + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Iteration or increment counter. + + + + + + + + Details about statistically or explicitly resolved + atoms in the entire domain. + + + + + Details about statistically or explicitly resolved + dislocations in the entire domain. + + + + + Details about statistically or explicitly resolved + interfaces between crystals in the entire domain. + + + + + Details about the orientation distribution function + within the entire domain. + + + + With which method was the ODF approximated? + + + + + TO BE DEFINED + + + + + TO BE DEFINED + + + + + Collection of texture components commonly referred to. + + + + Reference to or definition of a coordinate system with + which the definitions are interpretable. + + + + + + + + + + + Parameterized orientations. + + + + + + + + + Name of each texture component, e.g. Cube, Dillamore, Y. + + + + + + + + The portion of orientation space integrated over + to compute the volume fraction. + + + + + + + + The volume fraction of each texture component. + + + + + + + + + + Details about the disorientation distribution function + within the entire domain. + + + + + Details about the grain boundary character distribution + within the entire domain. + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml new file mode 100644 index 0000000000..b4eb6ac91c --- /dev/null +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -0,0 +1,627 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of boundaries of the bounding box or primitive to domain. + + + + + Number of parameter required for chosen orientation parameterization. + + + + + Number of texture components identified. + + + + + Dimensionality. + + + + + Cardinality. + + + + + Number of active cells in the (recrystallization) front. + + + + + Number of grains in the computer simulation. + + + + + Application definition for storing results of the SCORE cellular automaton. + + The SCORE cellular automaton model for primary recrystallization is an + example of typical materials engineering applications used within the field + of so-called Integral Computational Materials Engineering (ICME) whereby + one can simulate the evolution of microstructures. + + Specifically the SCORE model can be used to simulate the growth of static + recrystallization nuclei. The model is described in the literature: + + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ + * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ + * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the workflow (analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + + + + + + + + + + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe a microstructure. + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + + + + + + + + + The path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the SCORE executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Using one NXtransformations + instance per base vector. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + + + + + + + + + + + + + A tight bounding box or sphere or bounding primitive about the grid. + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + Collection of microstructural data observed/simulated. + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + + + + + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + + + + + + + + + + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Iteration or increment counter. + + + + + + Grain identifier for each cell. + + + + + + + + + + Identifier of the OpenMP thread which processed this part of the grid. + + + + + + + + + + + Details about those cells which in this time step represent + the discretized recrystallization front. + + + + So-called mobility weight which is a scaling factor to + control the mobility of the grain boundary which is assumed + to sweep currently this volume. + + + + + + + + Grid coordinates of each cell in the recrystallization front. + + + + + + + + + Grain identifier assigned to each cell in the recrystallization front. + + + + + + + + Grain identifier assigned to each nucleus which affected that cell in the recrystallization front. + + + + + + + + Relative volume transformed as a measure of infection progress. + + + + + + + + Identifier of the OpenMP thread processing each cell in the recrystallization front. + + + + + + + + Hint about the direction from which the cell was infected. + + + + + + + + + Current grain-related quantities. + + + + Bunge-Euler angle triplets for each grain. + + + + + + + + + Discrete volume of each grain accounting also for partially + transformed cells. + + + + + + + + Current value for the dislocation density as a measure of + the remaining stored energy in assumed crystal defects inside + each grain. The difference between these values scales the + driving force of grain boundary migration. + + + + + + + + Is the grain deformed. + + + + + + + + Is the grain recrystallized. + + + + + + + + + + Simulated temperature. + + + + + + Current recrystallized volume fraction. + + + + Currently evaluated actual recrystallized volume fraction. + This takes into account partially recrystallized cells. + + + + + Currently desired target recrystallized volume fraction at + which the user requested to log a snapshot. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml index 0f1ab53e11..8e4dd61520 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml @@ -749,7 +749,7 @@ NXapm_paraprobe_results_nanochem: doc: | Triangle normals are oriented in the direction of the gradient vector of the local delocalized scalar field. - :mathref:`$\sum_{x, y, z} {\nabla{c}_i}^2$`. + :math:`$\sum_{x, y, z} {\nabla{c}_i}^2$`. unit: NX_ANY dimensions: rank: 1 @@ -885,7 +885,7 @@ NXapm_paraprobe_results_nanochem: # hold multiple instances of iso_surface each with a different # number of triangles and/or features! # details about specific features - objects(NXms_three_d_feature_set): + objects(NXprocess): # (NXms_three_d_feature_set): exists: optional doc: | Details for features which are (closed) objects. @@ -958,7 +958,7 @@ NXapm_paraprobe_results_nanochem: dimensions: rank: 1 dim: [[1, k]] - objects_close_to_edge(NXms_three_d_feature_set): + objects_close_to_edge(NXprocess): # (NXms_three_d_feature_set): exists: optional doc: | Details for all those objects close to edge, i.e. those which @@ -1039,7 +1039,7 @@ NXapm_paraprobe_results_nanochem: dimensions: rank: 1 dim: [[1, i]] - objects_far_from_edge(NXms_three_d_feature_set): + objects_far_from_edge(NXprocess): # (NXms_three_d_feature_set): exists: optional doc: | Details for all those objects far from edge, i.e. those @@ -1122,7 +1122,7 @@ NXapm_paraprobe_results_nanochem: dim: [[1, i]] # linear_feature_identification(NXprocess): # these would be polylines etc - proxies(NXms_three_d_feature_set): + proxies(NXprocess): # (NXms_three_d_feature_set): exists: optional doc: | Details for features which are so-called proxies, i.e. objects @@ -1226,7 +1226,7 @@ NXapm_paraprobe_results_nanochem: dimensions: rank: 1 dim: [[1, i]] - proxies_far_from_edge(NXms_three_d_feature_set): + proxies_far_from_edge(NXprocess): # (NXms_three_d_feature_set): exists: optional doc: | Details for those proxies far from edge, i.e. those whose diff --git a/contributed_definitions/nyaml/NXliquid_jet.yaml b/contributed_definitions/nyaml/NXliquid_jet.yaml deleted file mode 100644 index e24b8b9b00..0000000000 --- a/contributed_definitions/nyaml/NXliquid_jet.yaml +++ /dev/null @@ -1,47 +0,0 @@ -category: base -doc: | - Description of a liquid jet -NXliquid_jet: - name(NX_CHAR): - chemical_formula(NX_CHAR): - preparation_data(NX_DATE_TIME): - description(NX_CHAR): - electric_field(NX_FLOAT): - unit: NX_VOLTAGE / NX_LENGTH - geometry(NXoff_geometry): - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - situation(NX_CHAR): - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - thickness(NX_FLOAT): - unit: NX_LENGTH - type(NX_CHAR): - flow_rate(NX_FLOAT): - unit: NX_VOLUME / NX_TIME - shape(NX_CHAR): - enumeration: [round, flat] - leaf_geometry(NXtransformations): - leaf_normal(NX_NUMBER): - vector(NX_NUMBER): - depends_on(NX_CHAR): - SOLVENT(NX_SAMPLE): - description: - name: - chemical_formula: - chem_id_cas(NX_CHAR): - flow_rate(NX_FLOAT): - unit: NX_VOLUME / NX_TIME - nozzle_angle(NX_FLOAT): - unit: NX_ANGLE - ph_value(NX_FLOAT): - unit: NX_UNITLESS - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - SOLUTE(NX_SAMPLE): - description: - name: - chemical_formula: - chem_id_cas(NX_CHAR): - mol_fraction(NX_FLOAT): - solvent(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXmpes_liquid.yaml b/contributed_definitions/nyaml/NXmpes_liquid.yaml deleted file mode 100644 index c8817c17fb..0000000000 --- a/contributed_definitions/nyaml/NXmpes_liquid.yaml +++ /dev/null @@ -1,267 +0,0 @@ -#Pincelli, Rettig, Arora at fhi-berlin.mpg.de, Dobener at hu-berlin.de, 06/2022 -#Draft version of a NeXus application definition for photoemission, -#It is designed to be extended by other application definitions -#with higher granularity in the data description. - -doc: This is the application definition for multidimensional photoelectron spectroscopy on liquids -category: application -NXmpes_liquid: - (NXentry): - title: - start_time(NX_DATE_TIME): - doc: "Datetime of the start of the measurement." - definition: - \@version: - enumeration: ["NXmpes_liquid"] - (NXuser): - doc: "Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users if relevant is recommended." - name: - doc: "Name of the user." - affiliation: - exists: recommended - doc: "Name of the affiliation of the user at the point in time when the - experiment was performed." - address: - exists: recommended - doc: "Full address (street, street number, ZIP, city, country) of the - user's affiliation." - email: - doc: "Email address of the user." - orcid: - exists: recommended - doc: "Author ID defined by https://orcid.org/." - (NXinstrument): - energy_resolution(NX_FLOAT): - (NXsource): - doc: "The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. - For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on." - type: - enumeration: [ - "Synchrotron X-ray Source", - "Rotating Anode X-ray", - "Fixed Tube X-ray", - "UV Laser", - "Free-Electron Laser", - "Optical Laser", - "UV Plasma Source", - "Metal Jet X-ray", - "HHG laser" - ] - name: - probe: - doc: "Type of probe. In photoemission it's always photons, so the full NIAC list is restricted." - enumeration: ["x-ray","ultraviolet", "visible light"] - (NXbeam): - distance(NX_NUMBER): - doc: "Distance of the point of evaluation of the beam from the sample surface." - incident_energy(NX_FLOAT): - incident_energy_spread(NX_NUMBER): - exists: recommended - incident_polarization(NX_NUMBER): - exists: recommended - (NXelectronanalyser): - description: - energy_resolution(NX_FLOAT): - exists: recommended - doc: "Energy resolution of the analyser with the current setting. May be linked from a NXcalibration." - fast_axes(NX_CHAR): - exists: recommended - slow_axes: - exists: recommended - (NXcollectioncolumn): - scheme: - doc: "Scheme of the electron collection column." - enumeration: [ - "Standard", - "Angular dispersive", - "Selective area", - "Deflector", - "PEEM", - "Momentum Microscope" - ] - mode: - exists: recommended - projection: - exists: recommended - field_aperture(NXaperture): - exists: optional - doc: "The size and position of the field aperture inserted in the column. - To add additional or other apertures use the APERTURE group of NXcollectioncolumn." - contrast_aperture(NXaperture): - exists: optional - doc: "The size and position of the contrast aperture inserted in the column. - To add additional or other apertures use the APERTURE group of NXcollectioncolumn." - (NXenergydispersion): - scheme: - enumeration: - [ - "tof", - "hemispherical", - "double hemispherical", - "cylindrical mirror", - "display mirror", - "retarding grid", - ] - pass_energy(NX_FLOAT): - energy_scan_mode: - entrance_slit(NXaperture): - exists: optional - doc: "Size, position and shape of the entrance slit in dispersive analyzers. - To add additional or other slits use the APERTURE group of NXenergydispersion." - exit_slit(NXaperture): - exists: optional - doc: "Size, position and shape of the exit slit in dispersive analyzers. - To add additional or other slits use the APERTURE group of NXenergydispersion." - (NXdetector): - amplifier_type: - exists: recommended - doc: "Type of electron amplifier in the first amplification step." - enumeration: ["MCP", "channeltron"] - # ToDo: Representation of count rate calibration - detector_type: - exists: recommended - doc: "Description of the detector type." - enumeration: ["DLD","Phosphor+CCD","Phosphor+CMOS","ECMOS", "Anode", "Multi-anode"] - (NXdata): # Raw signal without calibrated axes. - exists: recommended - \@signal: - enumeration: ['raw'] - raw(NX_NUMBER): # There is a block of numbers named raw. - doc: "Raw data before calibration." - (NXmanipulator): - exists: optional - doc: "Manipulator for positioning of the sample." - sample_temperature(NX_FLOAT): - exists: recommended - drain_current(NX_FLOAT): - exists: recommended - sample_bias(NX_FLOAT): - exists: recommended - (NXprocess): - doc: "Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using - one or more of the following NXcalibrations" - energy_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an energy calibration been applied?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting." - angular_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an angular calibration been applied?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated angular axis to be used for data plotting." - spatial_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an spatial calibration been applied?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated spatial axis to be used for data plotting." - momentum_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an momentum calibration been applied?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the momentum axis to be used for data plotting." - sample(NXsample): - name: - description: - chemical_formula: - exists: recommended - doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." - sample_history(NXnote): - exists: recommended - doc: "A descriptor to keep track of the treatment of the sample before entering the photoemission experiment. - Ideally, a full report of the previous operations, in any format (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." - preparation_date(NX_DATE_TIME): - exists: recommended - doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." - preparation_description(NXnote): - doc: "Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. - Ideally, a full report of the previous operations, in any format(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." - # Problem: if the temperature is logged, the data is an array of temperature/timestamp pairs. - # the timestamp NX_DATE_TIME structure of the timestamp can not be easily handled by just a field. - # there is a base class for this, NXlog. The NIAC decided to use the same name (temperature) instead of the previous temperature_log. - # how do I explain here in an appdef that temperature can be either NXnumber (single value or scanned array) or a NXlog? - # It seems quite contorted to ask to create a separate timestamp array when we have a base class that handles it more elegantly. - temperature(NX_FLOAT): - doc: "In the case of a fixed temperature measurement this is the scalar temperature of the sample. - In the case of an experiment in which the temperature is changed and recoded, this is an array of length m of temperatures. - This should be a link to - /entry/instrument/manipulator/sample_temperature." - unit: NX_TEMPERATURE - situation: - enumeration: ["vacuum", "inert atmosphere", "oxidising atmosphere", "reducing atmosphere"] - # Similar situation here, ca be a single number or a log. - gas_pressure(NX_FLOAT): - electric_field(NX_FLOAT): - unit: NX_VOLTAGE / NX_LENGTH - geometry(NXoff_geometry): - thickness(NX_FLOAT): - unit: NX_LENGTH - type(NX_CHAR): - flow_rate(NX_FLOAT): - unit: NX_VOLUME / NX_TIME - shape(NX_CHAR): - enumeration: [round, flat] - leaf_geometry(NXtransformations): - doc: | - Transformations describing the transformation chain to the - liqudjet leaf. - leaf_normal(NX_NUMBER): - doc: The normal of the liquidjet leaf. - \@vector(NX_NUMBER): - doc: The vector normal to the liquidjet leaf. - \@depends_on(NX_CHAR): - doc: | - Pointer to the previous matrices in the transformation chain - to relate the normal to the rest of the instrument. - If this is '.' the vector attribute only specifies the normal vector - without specifying the position of the liquidjet leaf with respect - to the instrument. - SOLVENT(NX_SAMPLE): - # FD 24.08.22: Should we also add transformations here to - # describe the directions of the liquidjets? - doc: | - Solvent material of the liquidjet. - This also accounts for multiple jets if more - than one solvent is given. - description: - name: - chemical_formula: - chem_id_cas(NX_CHAR): - flow_rate(NX_FLOAT): - unit: NX_VOLUME / NX_TIME - nozzle_angle(NX_FLOAT): - unit: NX_ANGLE - ph_value(NX_FLOAT): - unit: NX_UNITLESS - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - SOLUTE(NX_SAMPLE): - description: - name: - chemical_formula: - chem_id_cas(NX_CHAR): - mol_fraction(NX_FLOAT): - solvent(NX_CHAR): - (NXdata): - \@signal: - enumeration: ["data"] # There is an object named data that contains the signal - data(NX_NUMBER): # There is a block of numbers named data. - doc: "Represents a measure of one- or more-dimensional photoemission counts, where - the varied axis may be for example - energy, momentum, spatial coordinate, pump-probe delay, spin index, temperature, etc. - The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." diff --git a/contributed_definitions/nyaml/NXms.yaml b/contributed_definitions/nyaml/NXms.yaml new file mode 100644 index 0000000000..3e944460d1 --- /dev/null +++ b/contributed_definitions/nyaml/NXms.yaml @@ -0,0 +1,455 @@ +# Key difficulties: +# Several viewpoints are equally justified: Grains useful when there are crystallites with adjoining interfaces and +# none, or only some statistical populations of defects and/or some spatially-well defined defects, but if there are +# almost only defects like in a dislocation wall it might no longer be useful to define the grains as a well identifiable region whose majority volume +# shows long-range periodicity (so that defining an orientation makes) sense. Or should one better describe individual material points +# or atoms set of atoms forming a compact object with same grouping and same identifier? +# Lattice curvature, this is jargon with some truth in it but curvature has to be build from atom defects need to build the curvature +# average density, total, per character, per family, line length, curvature, jog, kink density, coarse-grainable structural motifs, atomic structure +# still all a models as thermal oscillations render that regions about a dislocation line segment oscillate change sub-nanometer arrangement frequently +# different scales relevant when coupling to specific mechanisms (e.g. phonons) +# ambiguous choices: is the grain boundary part of the grain or is it an own defect? +# i.e. can/should we store grains as childs of their grain boundary set vs the interface the childs of the grains? +# ?? right now can couple gr has gB but if gr is specialized can it still have a gB +# a member of grain boundary +# Depending on use case a continuum of descriptors: is used mapping the meaning of terms can be as simple as employing logical +# relations crystallite is a synonym for grain versus a grain is described programmatically as the resulting cluster of atoms with constraint +# Length scale of homogeneity: +# In a multi-parameter space of all possible methods and effects and different external stimuli applied, simulations in computational materials science +# make sense when they focus on often very narrowly constrained effects and boundary conditions for which the simulation is formulated and useful. +# Data structures for multi-scale materials modeling IMM/ICME are diverse because they reflect these needs and specific main choices of what these simulation +# e.g. DFT (time, length-scale, which electronic effects) +# RVE annealing phenomena at the micrometer scale (pressure, temperature, length scale, interactions considered or not) +# Some regions are well separated spatially (although it can be non-trivial to quantify the distance in a multi-dim parameter space) +# Some are overlapping (classical MD at the cutting edge with micrometer crystal plasticity microsecond and/or annealing at ns time scale) +# MD with classical vs abinitio-informed potential for studying evolution of mechanisms and phenomena at different length scale +category: application +doc: | + Application definition, spatiotemporal characterization of a microstructure. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_b: | + Number of boundaries of the bounding box or primitive to domain. + n_p: | + Number of parameter required for chosen orientation parameterization. + c: | + Number of texture components identified. +NXms: # (NXannealing) + (NXentry): + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + # enumeration: [sha_256_hash] + definition: + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXms] + workflow_identifier: + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment or computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + workflow_description: + exists: optional + doc: | + Free-text description about the workflow (experiment/analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + PROGRAM(NXprogram): + exists: [min, 1, max, infty] + program_name: + \@version: + experiment_or_simulation: + doc: | + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe a microstructure. + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + enumeration: [experiment, simulation] + USER(NXuser): + exists: [min, 0, max, infty] + doc: | + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + name: + doc: Given (first) name and surname of the user. + affiliation: + exists: recommended + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address: + exists: recommended + doc: Postal address of the affiliation. + email: + exists: recommended + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + orcid: + exists: recommended + doc: | + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + orcid_platform: + exists: recommended + doc: | + Name of the OrcID or ResearcherID where the account + under orcid is registered. + telephone_number: + exists: optional + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role: + exists: recommended + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + social_media_name: + exists: optional + doc: | + Account name that is associated with the user in social media platforms. + social_media_platform: + exists: optional + doc: | + Name of the social media platform where the account + under social_media_name is registered. + specimen(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + name: + doc: | + Descriptive name or ideally (globally) unique persistent identifier. + # sample_history: + # doc: | + # Ideally, a reference to the location of or a (globally) unique + # persistent identifier of e.g. another file which should document + # ideally as many details as possible of the material, its + # microstructure, and its thermo-chemo-mechanical processing/ + # preparation history. + # preparation_date(NX_DATE_TIME): + # doc: | + # ISO 8601 time code with local time zone offset to UTC information + # when the specimen was prepared. + (NXdata): + exists: optional + doc: | + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + (NXcoordinate_system_set): + doc: | + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Using one NXtransformations + instance per base vector. + TRANSFORMATIONS(NXtransformations): + exists: [min, 3, max, infty] + + conventions(NXem_ebsd_conventions): + rotation_conventions(NXprocess): + three_dimensional_rotation_handedness: + rotation_convention: + euler_angle_convention: + axis_angle_convention: + orientation_parameterization_sign_convention: + processing_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + xaxis_alias: + yaxis_direction: + yaxis_alias: + zaxis_direction: + zaxis_alias: + origin: + sample_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + + ROI_SET(NXcg_roi_set): + exists: [min, 1, max, infty] # usually a single domain covering the entire simulated or measured material volume + # however for solitary unit models aka volume element ensemble, replica methods we may need more than one domain + # the volume element is not called representative because for what we consider the volume element to be representative + # for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors + doc: | + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + grid(NXcg_grid): + exists: optional + polyhedron_set(NXcg_polyhedron_set): + exists: optional + point_set(NXcg_point_set): # how to model either or case? + exists: optional + boundary(NXcg_hexadedron_set): # how to model either or case? + exists: optional + doc: | + A boundary to the volume element. + Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. + # a good example for a general bounding box description for such a grids of triclinic cells + # https://docs.lammps.org/Howto_triclinic.html NXcg_hexahedron_set because can be a parallelepiped + number_of_boundaries(NX_POSINT): + doc: | + How many distinct boundaries are distinguished. Value required equal to n_b. + unit: NX_UNITLESS + boundaries: + doc: | + Name of the boundaries. E.g. left, right, front, back, bottom, top, + dimensions: + rank: 1 + dim: [[1, n_b]] + boundary_conditions(NX_UINT): + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_b]] + snapshot_set(NXms_snapshot_set): + exists: required + doc: | + Collection of microstructural data observed/simulated. + identifier_offset(NX_UINT): + doc: | + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + unit: NX_UNITLESS + + # essentially NXmonitor instances for evolution of ensemble summary statistics + evolution(NXprocess): + exists: optional + doc: | + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + temperature(NXprocess): + exists: optional + pressure(NXprocess): + exists: optional + stress(NXprocess): + exists: optional + strain(NXprocess): + exists: optional + deformation_gradient(NXprocess): + exists: optional + magnetic_field(NXprocess): + exists: optional + electric_field(NXprocess): + exists: optional + recrystallization_kinetics(NXprocess): + exists: optional + grain_size_distribution(NXprocess): + exists: optional + recrystallization_front(NXprocess): + exists: optional + + # time-resolved results for individual snapshots + # virtually all computer simulations and all experiments always probe + # snapshots + MS_SNAPSHOT(NXms_snapshot): # equivalent to time-step + time(NX_NUMBER): + doc: | + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + unit: NX_TIME + iteration(NX_UINT): + doc: | + Iteration or increment counter. + unit: NX_UNITLESS + # optional places to store the grid for instance if it changes + grid(NXcg_grid): + exists: optional + polyhedron_set(NXcg_polyhedron_set): + exists: optional + point_set(NXcg_point_set): + exists: optional + # homogenization: + # constituent: + # constitutive: + # ROI(NXcg_roi_set): #multiple rois, for each geometry, connectivity/topology, cellType... + # see that the materialpoint that is tracked conceptually in tools like DAMASK is a ROI (which is currently scale-invariant), isnt a coarse-graining of atom configurations a homogenization + # several "results" homogenized quantities at (eventually different length scales + # continuum-scale view thermodynamic(NXview) + # mechanical + # damage + # thermal + # composition + (NXms_atom_set): # positions, identifier + exists: optional + doc: | + Details about statistically or explicitly resolved + atoms in the entire domain. + # (NXms_grain_set): + # exists: optional + # doc: | + # Details about statistically or explicitly resolved + # interfaces between grains of + (NXms_dislocation_set): + exists: optional + doc: | + Details about statistically or explicitly resolved + dislocations in the entire domain. + (NXms_interface_set): + exists: optional + doc: | + Details about statistically or explicitly resolved + interfaces between crystals in the entire domain. + # (NXms_triple_line_set): + # exists: optional + # doc: | + # Details about statistically or explicitly resolved + # triple lines in the entire domain. + # (NXms_quadruple_junction_set): + # exists: optional + # doc: | + # Details about statistically or explicitly resolved + # quadruple junctions in the entire domain. + # (NXms_vacancy_set): + # exists: optional + # (NXms_solute_atom_set): + # exists: optional + # doc: | + # Details about explicitly resolved solute atoms + # in the entire domain. + + odf(NXprocess): # (NXodf): + exists: optional + doc: | + Details about the orientation distribution function + within the entire domain. + computation_method: + doc: | + With which method was the ODF approximated? + # add approximation parameter + texture_index(NX_NUMBER): + exists: optional + doc: | + TO BE DEFINED + unit: NX_ANY + texture_strength(NX_NUMBER): + exists: optional + doc: | + TO BE DEFINED + unit: NX_ANY + volume_statistics(NXorientation_set): + exists: optional + doc: | + Collection of texture components commonly referred to. + TRANSFORMATIONS(NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the definitions are interpretable. + parameterization(NX_CHAR): + enumeration: [bunge-euler (ZXZ), quaternion] + orientation(NX_NUMBER): + doc: Parameterized orientations. + unit: NX_ANY + dimensions: + rank: 2 + dim: [[1, c], [2, n_p]] + name(NX_CHAR): + doc: | + Name of each texture component, e.g. Cube, Dillamore, Y. + dimensions: + rank: 1 + dim: [[1, c]] + integration_radius(NX_NUMBER): + doc: | + The portion of orientation space integrated over + to compute the volume fraction. + unit: NX_DEGREE + dimensions: + rank: 1 + dim: [[1, c]] + volume_fraction(NX_NUMBER): + doc: | + The volume fraction of each texture component. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, c]] + + # a grain-boundary character distribution + # is again a spatial correlation statistics, GBCD can be understood like an ODF in that the entire surface Of a grain boundary (interface) network is partitioned into regions between grains in specific disorientation relationships, and boundary plane inclination so that one can again ask for the "texture" i.e. which fraction of the area network is of specific disorientation and nominal plane inclination relationship + modf(NXprocess): # (NXmodf): + exists: optional + doc: | + Details about the disorientation distribution function + within the entire domain. + gbcd(NXprocess): # (NXgbcd): + exists: optional + doc: | + Details about the grain boundary character distribution + within the entire domain. + # add descriptions for the state of each cell + # e.g. values of phase field variables if desired + + temperature(NXprocess): + exists: optional + pressure(NXprocess): + exists: optional + stress(NXprocess): + exists: optional + strain(NXprocess): + exists: optional + deformation_gradient(NXprocess): + exists: optional + magnetic_field(NXprocess): + exists: optional + electric_field(NXprocess): + exists: optional + + recrystallization_kinetics(NXprocess): + exists: optional + grain_size_distribution(NXprocess): + exists: optional + recrystallization_front(NXprocess): + exists: optional diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml new file mode 100644 index 0000000000..e250c6417f --- /dev/null +++ b/contributed_definitions/nyaml/NXms_score_results.yaml @@ -0,0 +1,571 @@ +# inspect comments behind NXms +category: application +doc: | + Application definition for storing results of the SCORE cellular automaton. + + The SCORE cellular automaton model for primary recrystallization is an + example of typical materials engineering applications used within the field + of so-called Integral Computational Materials Engineering (ICME) whereby + one can simulate the evolution of microstructures. + + Specifically the SCORE model can be used to simulate the growth of static + recrystallization nuclei. The model is described in the literature: + + * `M. Kühbach et al. `_ + * `C. Haase et al. `_ + * `M. Diehl et al. `_ + +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_b: | + Number of boundaries of the bounding box or primitive to domain. + n_p: | + Number of parameter required for chosen orientation parameterization. + n_tex: | + Number of texture components identified. + d: | + Dimensionality. + c: | + Cardinality. + n_front: | + Number of active cells in the (recrystallization) front. + n_grains: | + Number of grains in the computer simulation. +NXms_score_results: + (NXentry): + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + # enumeration: [sha_256_hash] + definition: + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXms_score_results] + analysis_identifier: + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + analysis_description: + exists: optional + doc: | + Free-text description about the workflow (analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + PROGRAM(NXprogram): + exists: [min, 1, max, infty] + program_name: + \@version: + experiment_or_simulation: + doc: | + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe a microstructure. + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + enumeration: [experiment, simulation] + # always a simulation! + config_filename: + doc: | + The path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status(NX_CHAR): + doc: | + A statement whether the SCORE executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + USER(NXuser): + exists: [min, 0, max, infty] + doc: | + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + name: + doc: Given (first) name and surname of the user. + affiliation: + exists: recommended + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address: + exists: recommended + doc: Postal address of the affiliation. + email: + exists: recommended + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + orcid: + exists: recommended + doc: | + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + orcid_platform: + exists: recommended + doc: | + Name of the OrcID or ResearcherID where the account + under orcid is registered. + telephone_number: + exists: optional + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role: + exists: recommended + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + social_media_name: + exists: optional + doc: | + Account name that is associated with the user in social media platforms. + social_media_platform: + exists: optional + doc: | + Name of the social media platform where the account + under social_media_name is registered. + specimen(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + name: + doc: | + Descriptive name or ideally (globally) unique persistent identifier. + # sample_history: + # doc: | + # Ideally, a reference to the location of or a (globally) unique + # persistent identifier of e.g. another file which should document + # ideally as many details as possible of the material, its + # microstructure, and its thermo-chemo-mechanical processing/ + # preparation history. + # preparation_date(NX_DATE_TIME): + # doc: | + # ISO 8601 time code with local time zone offset to UTC information + # when the specimen was prepared. + (NXdata): + exists: optional + doc: | + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + (NXcoordinate_system_set): + doc: | + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Using one NXtransformations + instance per base vector. + TRANSFORMATIONS(NXtransformations): + exists: [min, 3, max, infty] + + conventions(NXem_ebsd_conventions): + rotation_conventions(NXprocess): + three_dimensional_rotation_handedness: + rotation_convention: + euler_angle_convention: + axis_angle_convention: + orientation_parameterization_sign_convention: + processing_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + xaxis_alias: + yaxis_direction: + yaxis_alias: + zaxis_direction: + zaxis_alias: + origin: + sample_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + + ROI_SET(NXcg_roi_set): + exists: [min, 1, max, infty] # usually a single domain covering the entire simulated or measured material volume + # however for solitary unit models aka volume element ensemble, replica methods we may need more than one domain + # the volume element is not called representative because for what we consider the volume element to be representative + # for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors + doc: | + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + grid(NXcg_grid): + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + origin(NX_NUMBER): + symmetry: + cell_dimensions(NX_NUMBER): + extent(NX_POSINT): + identifier_offset(NX_INT): + boundary(NXcg_polyhedron_set): + doc: A tight bounding box or sphere or bounding primitive about the grid. + # a good example for a general bounding box description for such a grids of triclinic cells + # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped + number_of_boundaries(NX_POSINT): + doc: | + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + unit: NX_UNITLESS + boundaries(NX_CHAR): + exists: recommmended + doc: | + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + boundary_conditions(NX_INT): + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_b]] + + snapshot_set(NXms_snapshot_set): + exists: required + doc: | + Collection of microstructural data observed/simulated. + identifier_offset(NX_UINT): + doc: | + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + unit: NX_UNITLESS + + # essentially NXmonitor instances for evolution of ensemble summary statistics + evolution(NXprocess): + exists: optional + doc: | + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + temperature(NXprocess): + exists: optional + # pressure(NXprocess): + # exists: optional + # stress(NXprocess): + # exists: optional + # strain(NXprocess): + # exists: optional + # deformation_gradient(NXprocess): + # exists: optional + # magnetic_field(NXprocess): + # exists: optional + # electric_field(NXprocess): + # exists: optional + recrystallization_kinetics(NXprocess): + exists: optional + grain_size_distribution(NXprocess): + exists: optional + recrystallization_front(NXprocess): + exists: optional + # time-resolved results for individual snapshots + # virtually all computer simulations and all experiments always probe + # snapshots + MS_SNAPSHOT(NXms_snapshot): # equivalent to time-step + time(NX_NUMBER): + doc: | + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + unit: NX_TIME + iteration(NX_UINT): + doc: | + Iteration or increment counter. + unit: NX_UNITLESS + # optional places to store the grid for instance if it changes + grid(NXcg_grid): # cell_based quantities for Vitesh Shah + exists: recommended + grain_identifier(NX_UINT): + exists: recommended + doc: | + Grain identifier for each cell. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_x], [2, n_y], [3, n_z]] + thread_identifier(NX_UINT): + exists: optional + doc: | + Identifier of the OpenMP thread which processed this part of the grid. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_x], [2, n_y], [3, n_z]] + # check comments behind NXms + recrystallization_front(NXprocess): # front_based quantities for Vitesh Shah + exists: recommended + doc: | + Details about those cells which in this time step represent + the discretized recrystallization front. + mobility(NX_NUMBER): # P + exists: recommended + doc: | + So-called mobility weight which is a scaling factor to + control the mobility of the grain boundary which is assumed + to sweep currently this volume. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_front]] + coordinate(NX_NUMBER): + exists: recommended + doc: | + Grid coordinates of each cell in the recrystallization front. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_front], [2, 3]] + deformed_grain_identifier(NX_UINT): + exists: recommended + doc: | + Grain identifier assigned to each cell in the recrystallization front. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_front]] + recrystallized_grain_identifier(NX_UINT): + exists: recommended + doc: | + Grain identifier assigned to each nucleus which affected that cell in the recrystallization front. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_front]] + recrystallized_volume_fraction(NX_NUMBER): + exists: recommended + doc: | + Relative volume transformed as a measure of infection progress. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_front]] + thread_identifier(NX_UINT): + exists: optional + doc: | + Identifier of the OpenMP thread processing each cell in the recrystallization front. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_front]] + infection_direction(NX_UINT): + exists: optional + doc: | + Hint about the direction from which the cell was infected. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_front]] + grain_size_distribution(NXprocess): # grain_based quantities for Vitesh Shah + exists: recommended + doc: | + Current grain-related quantities. + euler(NX_NUMBER): + exists: optional + doc: | + Bunge-Euler angle triplets for each grain. + unit: NX_DEGREE + dimensions: + rank: 2 + dim: [[1, n_grains], [2, 3]] + volume(NX_NUMBER): + doc: | + Discrete volume of each grain accounting also for partially + transformed cells. + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, n_grains]] + dislocation_density(NX_NUMBER): + exists: recommended + doc: | + Current value for the dislocation density as a measure of + the remaining stored energy in assumed crystal defects inside + each grain. The difference between these values scales the + driving force of grain boundary migration. + unit: NX_ANY # 1/m^2 + dimensions: + rank: 1 + dim: [[1, n_grains]] + is_deformed(NX_BOOLEAN): + exists: recommended + doc: | + Is the grain deformed. + dimensions: + rank: 1 + dim: [[1, n_grains]] + is_recrystallized(NX_BOOLEAN): + exists: recommended + doc: | + Is the grain recrystallized. + dimensions: + rank: 1 + dim: [[1, n_grains]] + temperature(NXprocess): + value(NX_NUMBER): + doc: | + Simulated temperature. + unit: NX_TEMPERATURE + recrystallized_kinetics(NXprocess): + doc: | + Current recrystallized volume fraction. + value(NX_NUMBER): + doc: | + Currently evaluated actual recrystallized volume fraction. + This takes into account partially recrystallized cells. + unit: NX_DIMENSIONLESS + target(NX_NUMBER): + doc: | + Currently desired target recrystallized volume fraction at + which the user requested to log a snapshot. + unit: NX_DIMENSIONLESS + # pressure(NXprocess): + # exists: optional + # stress(NXprocess): + # exists: optional + # strain(NXprocess): + # exists: optional + # deformation_gradient(NXprocess): + # exists: optional + # magnetic_field(NXprocess): + # exists: optional + # electric_field(NXprocess): + # exists: optional + + performance(NXcs_profiling): + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 037459c801..bcc88b7c8d 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -5,20 +5,20 @@ B5: Atom-probe tomography ========================= .. index:: - IntroductionAPM - ApmNewAppDef - ApmNewBC + IntroductionApm + ApmAppDef + ApmBC ApmRemovedBC -.. _IntroductionAPM: +.. _IntroductionApm: Introduction ############## Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. -.. _ApmNewAppDef: +.. _ApmAppDef: Application Definitions ####################### @@ -28,7 +28,7 @@ We created one new application definition whose intention is to serve both the d :ref:`NXapm`: A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). -.. _ApmNewBC: +.. _ApmBC: Base Classes ############ @@ -66,6 +66,8 @@ We developed new base classes to structure the application definition into lab e Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. +.. _ApmRemovedBC: + Removed base classes #################### diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index c4d99a7542..6fd9230563 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -1,21 +1,21 @@ -.. _CGMSFeatures-Structure: +.. _CgmsFeatures-Structure: ========================= Geometry & microstructure ========================= .. index:: - IntroductionCGMS - PhysicsCGMS - CGMSNewAppDef - CGMSNewBC -.. CGMSNewCommonBC + IntroductionCgms + PhysicsCgms + CgmsAppDef + CgmsBC + IcmeMsModels -.. _IntroductionCGMS: +.. _IntroductionCgms: Introduction -############## +############ The computational-geometry/microstructure-modeling-based part of the proposal has the following aims: @@ -43,7 +43,7 @@ National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, .. The proposal reaches out to our colleagues in the materials engineering-based .. consortia to document that there is value in discussing about controlled vocabulary. -.. _PhysicsCGMS: +.. _PhysicsCgms: Physics background ################## @@ -91,6 +91,8 @@ when combined with hierarchical clustering/labeling methods, applied on set of atoms and features turn out to yield useful descriptors. Examples include point, line, surface defects, such as vacancies, solute cluster, dislocations, disconnections, interfaces to name but a few. +.. _CgmsBC: + Base Classes ############ @@ -261,3 +263,27 @@ and elapsed time measured while processing data. These utility classes include: :ref:`NXcs_io_obj`: Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. + +.. _IcmeMsModels: + +Application definitions for ICME models +####################################### + +To bridge to our colleagues from the NFDI-MatWerk and NFDI4Ing consortia we +have created an example how the proposed components of the nexus-fairmat-proposal +can be used to create data schemes for vanilla-type ICME microstructure models. +ICME is an abbreviation for Integrated Computational Materials Engineering, which +is a design strategy and workflow whereby physics-based modelling of microstructure +evolution at the mesoscopic scale is used to understand the relations between +the microstructure and technological relevant descriptors for the properties +of materials. + +To begin with we propose the following draft application definitions. + + :ref:`NXms`: + An application definition for arbitrary spatiotemporally resolved simulations. + + :ref:`NXms_score_results`: + A specific example how :ref:`NXms` can be specialized for documenting + results of computer simulations with the static recrystallization + cellular automata model SCORE. diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 19ae498df1..c7c508d9d2 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -5,15 +5,16 @@ B1: Electron microscopy ======================= .. index:: - IntroductionEM - EmNewAppDef - EmNewBC - EmNewCommonBC + IntroductionEm + EmAppDef + EmBC + EmCommonBC + EmPartnerClasses EmDeprecated -.. _IntroductionEM: +.. _IntroductionEm: Introduction ############ @@ -23,7 +24,7 @@ Set of data storage objects to describe components of an electron microscope and Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it additionally difficult to keep track of workflows and challenging to identify which specific quantities in the control software mean and represent in technical detail which physical quantity (and how these quantities can be connected to the development of ontologies for electron microscopy experiments). -.. _EmNewAppDef: +.. _EmAppDef: Application Definitions ####################### @@ -34,7 +35,7 @@ the specimen from the instrument or parking it so that the next user can start a :ref:`NXem`: A general application definition which explores the possibilities of electron microscopes. -.. _EmNewBC: +.. _EmBC: Base Classes ############ @@ -117,7 +118,7 @@ We developed entirely new base classes. Some of them are also used for other tec As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. -.. _EmNewCommonBC: +.. _EmCommonBC: Common Base Classes ################### @@ -128,6 +129,8 @@ base class lenses. We understand also that the proposed set of NXimage_set_em ba The first result of such consolidations is the NXem_ebsd partner application definition. +.. _EmPartnerClasses: + Partner application definitions ############################### diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index e2a0e91f01..9755e8b2c5 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -5,37 +5,37 @@ B2/B3: Photoemission & core-level spectroscopy ============================================== .. index:: - IntroductionMPES - NewAppDef - NewBC - NewCommonBC - ExtendedBC + IntroductionMpes + MpesAppDef + MpesBC + MpesCommonBC + MpesExtendedBC -.. _IntroductionMPES: +.. _IntroductionMpes: Introduction -############## +############ Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) and photoemission electron microscopy (PEEM). We also included descriptors for advanced specializations, such as spin-resolution, time resolution, near-ambient pressure conditions, dichroism etc. -.. _NewAppDef: +.. _MpesAppDef: -New Application Definitions -############################ +Application Definitions +####################### We created two new application definitions: :ref:`NXmpes`: A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. -.. _NewBC: +.. _MpesBC: -New Base Classes -################# +Base Classes +############ We developed entirely new base classes: @@ -66,10 +66,10 @@ We developed three base classes to describe data processing, which can be used a :ref:`NXregistration`: A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. -.. _NewCommonBC: +.. _MpesCommonBC: -New Common Base Classes -####################### +Common Base Classes +################### We developed two classes that are common to other techniques: @@ -79,10 +79,10 @@ We developed two classes that are common to other techniques: :ref:`NXdeflector` A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. -.. _ExtendedBC: +.. _MpesExtendedBC: Base Classes Extended in Application Definitions -################################################### +################################################ We use existent base classes in application definitions and add descriptors: diff --git a/manual/source/sed/landing-page.rst b/manual/source/sed/landing-page.rst deleted file mode 100644 index a79f1b131a..0000000000 --- a/manual/source/sed/landing-page.rst +++ /dev/null @@ -1,59 +0,0 @@ -======================================= -User Manual and Reference Documentation -======================================= - -Welcome to the user manual of the NeXus for FAIRmat project. - -https://www.nexusformat.org/ - -.. toctree:: - :maxdepth: 2 - - fairmat-cover - nexus-index - mpes-structure - ellipsometry-structure - em-structure - apm-structure - epics-structure - - ------------ - -.. rubric:: Publishing Information - -| This commit time code <>. -| This commit identifier <>. -| This manual built |today|. - - -.. seealso:: - - The extended NeXus documentation: - - :HTML: - https://manual.nexusformat.org/ - - :PDF: - https://manual.nexusformat.org/pdf/NeXusManual.pdf - - A very brief overview (title: *NeXus for the Impatient*) - is also available (separate from the manual). - - :HTML: - https://manual.nexusformat.org/impatient/ - - :PDF: - https://manual.nexusformat.org/pdf/NXImpatient.pdf - - FAIRmat website: - - ``_ - - NOMAD website: - - ``_ - - - - diff --git a/manual/source/transport-structure.rst b/manual/source/transport-structure.rst index 10abb9da85..8238b52196 100644 --- a/manual/source/transport-structure.rst +++ b/manual/source/transport-structure.rst @@ -1,40 +1,26 @@ -.. _Epics-Structure: +.. _Transport-Structure: =================== Transport Phenomena =================== .. index:: - IntroductionEpics - EpicsNewAppDef - EpicsNewBC - EpicsNewCommonBC + IntroductionTransport + TransportAppDef -.. _IntroductionEpics: +.. _IntroductionTransport: Introduction ############## -.. _EpicsNewAppDef: +.. _TransportAppDef: -New Application Definitions -############################ +Application Definitions +####################### Work on handshaking between EPICS-controlled experiments and NeXus resulted in one application definition for temperature dependent IV curve measurements. :ref:`NXiv_temp`: Application definition for temperature dependent IV curve measurements. - -.. _EpicsNewBC: - -New Base Classes -################# - - -.. _EpicsNewCommonBC: - -New Common Base Classes -####################### - From 02a61b5c66e802028a9c5197fa50dd75ad775860 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 20 Mar 2023 14:43:51 +0100 Subject: [PATCH 118/203] Fixes on NXms related dependent classes --- contributed_definitions/NXms.nxdl.xml | 4 ++-- ...atom_set.nxdl.xml => NXms_atom_set.nxdl.xml} | 2 +- .../NXms_score_results.nxdl.xml | 2 +- contributed_definitions/nyaml/NXms.yaml | 4 ++-- .../{NXatom_set.yaml => NXms_atom_set.yaml} | 2 +- .../nyaml/NXms_score_results.yaml | 2 +- manual/source/cgms-structure.rst | 15 ++++++--------- manual/source/em-structure.rst | 17 ++--------------- 8 files changed, 16 insertions(+), 32 deletions(-) rename contributed_definitions/{NXatom_set.nxdl.xml => NXms_atom_set.nxdl.xml} (91%) rename contributed_definitions/nyaml/{NXatom_set.yaml => NXms_atom_set.yaml} (96%) diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 1b59ad4020..b8be940793 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -238,7 +238,7 @@ - + A boundary to the volume element. Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. @@ -396,7 +396,7 @@ - + The portion of orientation space integrated over to compute the volume fraction. diff --git a/contributed_definitions/NXatom_set.nxdl.xml b/contributed_definitions/NXms_atom_set.nxdl.xml similarity index 91% rename from contributed_definitions/NXatom_set.nxdl.xml rename to contributed_definitions/NXms_atom_set.nxdl.xml index 83b826d33c..2367448b6d 100644 --- a/contributed_definitions/NXatom_set.nxdl.xml +++ b/contributed_definitions/NXms_atom_set.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index b4eb6ac91c..49293c0965 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -479,7 +479,7 @@ Current grain-related quantities. - + Bunge-Euler angle triplets for each grain. diff --git a/contributed_definitions/nyaml/NXms.yaml b/contributed_definitions/nyaml/NXms.yaml index 3e944460d1..fe21f2d03d 100644 --- a/contributed_definitions/nyaml/NXms.yaml +++ b/contributed_definitions/nyaml/NXms.yaml @@ -210,7 +210,7 @@ NXms: # (NXannealing) exists: optional point_set(NXcg_point_set): # how to model either or case? exists: optional - boundary(NXcg_hexadedron_set): # how to model either or case? + boundary(NXcg_hexahedron_set): # how to model either or case? exists: optional doc: | A boundary to the volume element. @@ -405,7 +405,7 @@ NXms: # (NXannealing) doc: | The portion of orientation space integrated over to compute the volume fraction. - unit: NX_DEGREE + unit: NX_ANGLE dimensions: rank: 1 dim: [[1, c]] diff --git a/contributed_definitions/nyaml/NXatom_set.yaml b/contributed_definitions/nyaml/NXms_atom_set.yaml similarity index 96% rename from contributed_definitions/nyaml/NXatom_set.yaml rename to contributed_definitions/nyaml/NXms_atom_set.yaml index 02c5385e91..61cc2be11a 100644 --- a/contributed_definitions/nyaml/NXatom_set.yaml +++ b/contributed_definitions/nyaml/NXms_atom_set.yaml @@ -3,7 +3,7 @@ doc: | A base class to wrap details about a spatial configuration of atoms. symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXatom_set: +NXms_atom_set: (NXcg_point_set): doc: Atom positions. # the application-definition specific NXcg_point_set instance diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml index e250c6417f..1bb11eead6 100644 --- a/contributed_definitions/nyaml/NXms_score_results.yaml +++ b/contributed_definitions/nyaml/NXms_score_results.yaml @@ -417,7 +417,7 @@ NXms_score_results: exists: optional doc: | Bunge-Euler angle triplets for each grain. - unit: NX_DEGREE + unit: NX_ANGLE dimensions: rank: 2 dim: [[1, n_grains], [2, 3]] diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index 6fd9230563..1ba3655827 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -193,9 +193,6 @@ to hold metadata for these features: :ref:`NXclustering`: A description for clustering of objects (such as atoms or features). - :ref:`NXatom_set`: - A set of atoms. - :ref:`NXorientation_set`: A set of rotations to describe the relative orientation of members of a set of features/objects. @@ -203,14 +200,14 @@ to hold metadata for these features: Metadata to a set of slip system/slip system family for a given crystal structure. -.. :ref:`NXms_point_defect_set`: -.. Metadata to a set of point defects. + :ref:`NXms_atom_set`: + Metadata to a set of atoms. -.. :ref:`NXms_dislocation_set`: -.. Metadata of a set of dislocation/disconnection (line) defects. + :ref:`NXms_dislocation_set`: + Metadata of a set of dislocation/disconnection (line) defects. -.. :ref:`NXms_interface_set`: -.. Metadata to a set of interfaces between crystals. + :ref:`NXms_interface_set`: + Metadata to a set of interfaces between crystals. :ref:`NXms_crystal_set`: A set of crystals, for e.g. a polycrystal, phases, diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index c7c508d9d2..b93b3b1dcf 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -70,17 +70,7 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXibeam_column`: A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused ion beam (milling) capabilities. - :ref:`NXimage_set_em_adf` - :ref:`NXimage_set_em_bf` - :ref:`NXimage_set_em_bse` - :ref:`NXimage_set_em_chamber` - :ref:`NXimage_set_em_df` - :ref:`NXimage_set_em_diffrac` - :ref:`NXimage_set_em_ecci` - :ref:`NXimage_set_em_kikuchi` - :ref:`NXimage_set_em_ronchigram` - :ref:`NXimage_set_em_se` - :ref:`NXimage_set_em`: + :ref:`NXimage_set_em_adf`, :ref:`NXimage_set_em_bf`, :ref:`NXimage_set_em_bse`, :ref:`NXimage_set_em_chamber`, :ref:`NXimage_set_em_df`, :ref:`NXimage_set_em_diffrac`, :ref:`NXimage_set_em_ecci`, :ref:`NXimage_set_em_kikuchi`, :ref:`NXimage_set_em_ronchigram`, :ref:`NXimage_set_em_se`, :ref:`NXimage_set_em`: Base classes for storing acquisition details for individual images or stacks of images collected via using e.g. different imaging modes. The suffixes specify **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction (EBSD), **ronchigram** - convergent beam diffraction pattern, **se** secondary electron, and **generic** images. :ref:`NXinteraction_vol_em`: @@ -108,10 +98,7 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXscanbox_em`: A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. - :ref:`NXspectrum_set_em_eels` - :ref:`NXspectrum_set_em_xray` - :ref:`NXspectrum_set_em_auger` - :ref:`NXspectrum_set_em_cathodolum`: + :ref:`NXspectrum_set_em_eels`, :ref:`NXspectrum_set_em_xray`, :ref:`NXspectrum_set_em_auger`, :ref:`NXspectrum_set_em_cathodolum`: Base classes comparable to NXimage_set_em but for different techniques resulting in spectra. The suffixes specify **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, and **cathodolum** cathodoluminescence. :ref:`NXstage_lab`: From 0d37d677f8fc45999a9989f0dc0820dd1c669636 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 20 Mar 2023 18:12:29 +0100 Subject: [PATCH 119/203] added minimal examples for grinding and polishing, removed sensor_scan_parsed --- ...ctro_chemo_mechanical_preparation.nxdl.xml | 168 +++++++++++++++ .../NXlab_sample_mounting.nxdl.xml | 82 ++++++++ .../NXsensor_scan_parsed.nxdl.xml | 197 ------------------ ..._electro_chemo_mechanical_preparation.yaml | 113 ++++++++++ .../nyaml/NXlab_sample_mounting.yaml | 52 +++++ .../nyaml/NXsensor_scan.yaml | 44 ++-- .../nyaml/NXsensor_scan_parsed.yaml | 134 ------------ manual/source/index.rst | 1 + manual/source/laboratory-structure.rst | 25 +++ 9 files changed, 463 insertions(+), 353 deletions(-) create mode 100644 contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml create mode 100644 contributed_definitions/NXlab_sample_mounting.nxdl.xml delete mode 100644 contributed_definitions/NXsensor_scan_parsed.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml create mode 100644 contributed_definitions/nyaml/NXlab_sample_mounting.yaml delete mode 100644 contributed_definitions/nyaml/NXsensor_scan_parsed.yaml create mode 100644 manual/source/laboratory-structure.rst diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml new file mode 100644 index 0000000000..e702f9fca0 --- /dev/null +++ b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Grinding and polishing of a sample using abrasives in a wet lab. + Manual procedures, electro-chemical, vibropolishing. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + + + + + A preparation step performed by a human or a robot/automated system. + + + + + + + Carrier/plate used on which the abrasive/(lubricant) mixture was applied. + + + + + Medium on the abrasive_medium_carrier (cloth or grinding plate) + whereby material is abrasively weared. + + + + + Lubricant + + + + + Qualitative statement how the revelation of the machine was configured. + If the rotation was controlled manually, e.g. by turning knobs + choose manual and estimate the nominal average rotation. + If the rotation was controlled via choosing from a fixed set + of options offered by the machine choose fixed and + specify the nominal rotation. + If programmed use rotation_history (e.g. for automated/robot systems). + + + + + + + + + + + Qualitative statement how the (piston) force with which the sample + was pressed into/against the abrasive medium was controlled if at all. + If the force was controlled manually e.g. by turning knobs + choose manual and estimate nominal average force. + If the force was controlled via choosing from a fixed set + of options offered by the machine choose fixed and + specify the nominal force. + If programmed use force_history (e.g. for automated/robot systems). + + + + + + + + + + + Qualitative statement for how long (assuming regular uninterrupted) + preparation at the specified conditions the preparation step was + applied. + + + + + + + + + + + Turns per unit time. + + + + + Force exerted on the sample to press it into the abrasive. + + + + + Seconds + + + + + Qualitative statement how the material removal was characterized. + + + + + + + + + + How thick a layer was removed. + + + + + + + A preparation step performed by a human or a robot/automated system + with the aim to remove residual abrasive medium from the specimen surface. + + + + + diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml new file mode 100644 index 0000000000..2f99e88903 --- /dev/null +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -0,0 +1,82 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Embedding of a sample in a medium for easing processability. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + + + + + Qualitative statement how the sample was mounted. + + + + + + + + + + Type of material. + + + + + + + + + Electrical conductivity of the embedding medium. + + + + + diff --git a/contributed_definitions/NXsensor_scan_parsed.nxdl.xml b/contributed_definitions/NXsensor_scan_parsed.nxdl.xml deleted file mode 100644 index e868b86f9d..0000000000 --- a/contributed_definitions/NXsensor_scan_parsed.nxdl.xml +++ /dev/null @@ -1,197 +0,0 @@ - - - - - - - Variables used to set a common size for collected sensor data. - - - - The number of scan points measured in this scan. - - - - - Application definition for a generic scan using sensors. - - In this application definition, times should be specified always together - with an UTC offset. - - - - - - - - - - - - - - - Define the program that was used to generate the results file(s) - with measured data and metadata. - - - - Commercial or otherwise defined given name of the program - (or a link to the instrument software). - - - - Either version with build number, commit hash, or description of an - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - Website of the software. - - - - - - - Contact information of at least the user of the instrument or the - investigator who performed this experiment. Adding multiple users if - relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when - the experiment was performed. - - - - - Full address (street, street number, ZIP, city, country) - of the user's affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - Official telephone number of the user. - - - - - - - Describes an environment setup for the experiment. - - All the setting values of the independently scanned controllers are listed under corresponding - NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each - measurement sensor. - - For example, in a temperature-dependent IV measurement, the temperature and voltage must be - present as independently scanned controllers and the current sensor must also be present with - its readings. - - - - - Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. - - - - - For each point in the scan space, either the nominal setpoint of an independently scanned controller - or a representative average value of a measurement sensor is registered. - - The length of each sensor's data value array stored in this group should be equal to the number of scan points - probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. - This allows the scan to be made in any order as the user describes above in the experiment. We get matching - values simply using the index of the scan point. - - - - - - - - Timestamp for when the values provided in the value field were registered. - - Individual readings can be stored with their timestamps under value_log. This is to timestamp - the nominal setpoint or average reading values listed above in the value field. - - - - - - Free-text describing the data acquisition control: an internal - sweep using the built-in functionality of the controller device, - or a set/wait/read/repeat mechanism. - - - - - - ISO8601 datum when calibration was last performed - before this measurement. UTC offset should be specified. - - - - - - - A list of names of NXsensor groups used as independently scanned controllers. - - - - - A list of names of NXsensor groups used as measurement sensors. - - - - - - - - - - A scan specific representation of the measured signals as a function of the independently controlled environment settings. - Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. - - - - diff --git a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml new file mode 100644 index 0000000000..2c298d4dfb --- /dev/null +++ b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml @@ -0,0 +1,113 @@ +category: application +doc: | + Grinding and polishing of a sample using abrasives in a wet lab. + Manual procedures, electro-chemical, vibropolishing. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXlab_electro_chemo_mechanical_preparation: + (NXentry): + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + \@version: + doc: Version specifier of this application definition. + definition: + doc: Official NeXus NXDL schema with which this file was written. + enumeration: [NXlab_electro_chemo_mechanical_preparation] + workflow_step_identifier(NX_UINT): + workflow_step_description: + SAMPLE(NXsample): # identifier and the usual stuff, and conditions, temperature, humidity, pH, atmosphere and its pressure + exists: [min, 1, max, 1] + USER(NXuser): + exists: [min, 1, max, infty] + # (NXlab_grinding_machine): + grinding_machine(NXfabrication): + vendor: + model: + identifier: + exists: recommended + GRINDING_STEP(NXprocess): + doc: | + A preparation step performed by a human or a robot/automated system. + # maybe a user per step as sometimes samples are prepared by more than + # one person or not each person performs all polishing steps + sequence_index(NX_POSINT): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + abrasive_medium_carrier: + doc: | + Carrier/plate used on which the abrasive/(lubricant) mixture was applied. + # enumeration: [plate] + # controlled vocabulary items + abrasive_medium: + doc: | + Medium on the abrasive_medium_carrier (cloth or grinding plate) + whereby material is abrasively weared. + # enumeration: [SiC180] + # controlled vocabulary items or instance of chemical, need for free-text? + # also need for free-text in subsequent files? + lubricant: + doc: | + Lubricant + # enumeration: [none, water, ethanol, oil] + # from a list of controlled vocabulary items, or instance of chemical + # etching/corrosive attack, tracking the environment, what can we + # learn from our colleagues within NFDI4Cat, NFDI4Chem, and NFDI-MatWerk? + rotation_control: + doc: | + Qualitative statement how the revelation of the machine was configured. + If the rotation was controlled manually, e.g. by turning knobs + choose manual and estimate the nominal average rotation. + If the rotation was controlled via choosing from a fixed set + of options offered by the machine choose fixed and + specify the nominal rotation. + If programmed use rotation_history (e.g. for automated/robot systems). + enumeration: [undefined, manual, fixed, programmed] + force_control: + doc: | + Qualitative statement how the (piston) force with which the sample + was pressed into/against the abrasive medium was controlled if at all. + If the force was controlled manually e.g. by turning knobs + choose manual and estimate nominal average force. + If the force was controlled via choosing from a fixed set + of options offered by the machine choose fixed and + specify the nominal force. + If programmed use force_history (e.g. for automated/robot systems). + enumeration: [undefined, manual, fixed, programmed] + time_control: + doc: | + Qualitative statement for how long (assuming regular uninterrupted) + preparation at the specified conditions the preparation step was + applied. + enumeration: [undefined, manual, fixed, programmed] + rotation(NX_NUMBER): + doc: | + Turns per unit time. + unit: NX_FREQUENCY + # rotation_history(NX_NUMBER): + force(NX_NUMBER): + doc: | + Force exerted on the sample to press it into the abrasive. + unit: NX_ANY + # force-history(NX_NUMBER): + time(NX_NUMBER): + doc: | + Seconds + unit: NX_TIME + removal(NX_CHAR): + doc: | + Qualitative statement how the material removal was characterized. + enumeration: [undefined, estimated, measured] + thickness_reduction(NX_NUMBER): + doc: | + How thick a layer was removed. + unit: NX_LENGTH + # time_history(NX_NUMBER): + SENSOR_SCAN(NXsensor_scan): + # electro-chemical preparation is nothing but an I(V) curve within + # a corrosive medium, eventually some wet lab steps have characteristics + # of pure grinding, mechanical polishing, or a mixture with corrosive + # attack + CLEANING_STEP(NXprocess): + doc: | + A preparation step performed by a human or a robot/automated system + with the aim to remove residual abrasive medium from the specimen surface. + sequence_index(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml new file mode 100644 index 0000000000..912f7a228b --- /dev/null +++ b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml @@ -0,0 +1,52 @@ +category: application +doc: | + Embedding of a sample in a medium for easing processability. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +NXlab_sample_mounting: + (NXentry): + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXlab_sample_mounting] + SAMPLE(NXsample): # identifier and the usual stuff, and conditions, temperature, humidity, pH, atmosphere and its pressure + exists: [min, 1, max, 1] + USER(NXuser): + exists: [min, 1, max, infty] + start_time(NX_DATE_TIME): # how to define ? + end_time(NX_DATE_TIME): # how to define (epoxy hardening is a continuous process) ? + # (NXlab_mounting_machine): + mounting_machine(NXfabrication): + vendor: + model: + identifier: + exists: recommended + mounting_method: + doc: | + Qualitative statement how the sample was mounted. + enumeration: [cold_mounting, hot_mounting] + embedding_medium: # or material from controlled vocabulary list + type: + doc: | + Type of material. + enumeration: [resin, epoxy] + electrical_conductivity(NX_FLOAT): + doc: | + Electrical conductivity of the embedding medium. + unit: NX_ANY + # temperature control of the mounting (e.g. relevant when hot_mounting Al) + # cleaning procedures + # a descriptor of the shape of the specimen + # borrow from NXlab_thermo_mechanical_processing to document the external + # stimuli (eventually) applied during mounting + # temperature, mechanical, magnetic, electro-magnetic, are externally + # applied stimuli on the sample, can we use one master schema? + # e.g. one can even store NXcg_polyhedron_set and NXcg_face_list_data_structure + # instances to keep track of the geometry of specific instrument and how + # the samples were arranged in these + # key question is which steps has the sample experienced? \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsensor_scan.yaml b/contributed_definitions/nyaml/NXsensor_scan.yaml index 32844608b9..bcc0e3adef 100644 --- a/contributed_definitions/nyaml/NXsensor_scan.yaml +++ b/contributed_definitions/nyaml/NXsensor_scan.yaml @@ -1,9 +1,9 @@ -doc: | +category: application +doc: | Application definition for a generic scan using sensors. In this application definition, times should be specified always together with an UTC offset. -category: application symbols: doc: "Variables used to set a common size for collected sensor data." N_scanpoints: "The number of scan points measured in this scan." @@ -20,56 +20,56 @@ NXsensor_scan: end_time(NX_DATE_TIME): exists: recommended (NXprocess): - doc: | + doc: | Define the program that was used to generate the results file(s) with measured data and metadata. program(NX_CHAR): - doc: | + doc: | Commercial or otherwise defined given name of the program (or a link to the instrument software). \@version: - doc: | + doc: | Either version with build number, commit hash, or description of an (online) repository where the source code of the program and build instructions can be found so that the program can be configured in such a way that result files can be created ideally in a deterministic manner. \@program_url: - doc: | + doc: | Website of the software. (NXuser): - doc: | + doc: | Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. name(NX_CHAR): - doc: | + doc: | Name of the user. affiliation(NX_CHAR): exists: recommended - doc: | + doc: | Name of the affiliation of the user at the point in time when the experiment was performed. address(NX_CHAR): exists: recommended - doc: | + doc: | Full address (street, street number, ZIP, city, country) of the user's affiliation. email(NX_CHAR): exists: recommended - doc: | + doc: | Email address of the user. orcid(NX_CHAR): exists: recommended - doc: | + doc: | Author ID defined by https://orcid.org/. telephone_number(NX_CHAR): exists: recommended - doc: | + doc: | Official telephone number of the user. (NXinstrument): (NXenvironment): - doc: | + doc: | Describes an environment setup for the experiment. All the setting values of the independently scanned controllers are listed under corresponding @@ -82,11 +82,11 @@ NXsensor_scan: (NXsensor): (NXdata): exists: recommended - doc: | + doc: | Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. value(NX_FLOAT): unit: NX_ANY - doc: | + doc: | For each point in the scan space, either the nominal setpoint of an independently scanned controller or a representative average value of a measurement sensor is registered. @@ -100,7 +100,7 @@ NXsensor_scan: value_timestamp(NX_DATE_TIME): exists: recommended - doc: | + doc: | Timestamp for when the values provided in the value field were registered. Individual readings can be stored with their timestamps under value_log. This is to timestamp @@ -108,24 +108,24 @@ NXsensor_scan: run_control(NX_CHAR): exists: recommended \@description: - doc: | + doc: | Free-text describing the data acquisition control: an internal sweep using the built-in functionality of the controller device, or a set/wait/read/repeat mechanism. calibration_time(NX_DATE_TIME): - doc: | + doc: | ISO8601 datum when calibration was last performed before this measurement. UTC offset should be specified. (NXpid): independent_controllers: - doc: | + doc: | A list of names of NXsensor groups used as independently scanned controllers. measurement_sensors: - doc: | + doc: | A list of names of NXsensor groups used as measurement sensors. (NXsample): name(NX_CHAR): (NXdata): - doc: | + doc: | A scan specific representation of the measured signals as a function of the independently controlled environment settings. Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. diff --git a/contributed_definitions/nyaml/NXsensor_scan_parsed.yaml b/contributed_definitions/nyaml/NXsensor_scan_parsed.yaml deleted file mode 100644 index c4ecf78594..0000000000 --- a/contributed_definitions/nyaml/NXsensor_scan_parsed.yaml +++ /dev/null @@ -1,134 +0,0 @@ -doc: | - Application definition for a generic scan using sensors. - - In this application definition, times should be specified always together - with an UTC offset. -symbols: - doc: | - Variables used to set a common size for collected sensor data. - - N_scanpoints: | - The number of scan points measured in this scan. - -category: application -NXsensor_scan: - (NXentry): - definition(NX_CHAR): - \@version: - enumeration: [NXsensor_scan] - experiment_identifier(NX_CHAR): - exists: recommended - experiment_description(NX_CHAR): - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - (NXprocess): - doc: | - Define the program that was used to generate the results file(s) - with measured data and metadata. - program(NX_CHAR): - doc: | - Commercial or otherwise defined given name of the program - (or a link to the instrument software). - \@version: - doc: | - Either version with build number, commit hash, or description of an - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@program_url: - doc: | - Website of the software. - (NXuser): - doc: | - Contact information of at least the user of the instrument or the - investigator who performed this experiment. Adding multiple users if - relevant is recommended. - name(NX_CHAR): - doc: | - Name of the user. - affiliation(NX_CHAR): - exists: recommended - doc: | - Name of the affiliation of the user at the point in time when - the experiment was performed. - address(NX_CHAR): - exists: recommended - doc: | - Full address (street, street number, ZIP, city, country) - of the user's affiliation. - email(NX_CHAR): - exists: recommended - doc: | - Email address of the user. - orcid(NX_CHAR): - exists: recommended - doc: | - Author ID defined by https://orcid.org/. - telephone_number(NX_CHAR): - exists: recommended - doc: | - Official telephone number of the user. - (NXinstrument): - (NXenvironment): - doc: | - Describes an environment setup for the experiment. - - All the setting values of the independently scanned controllers are listed under corresponding - NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each - measurement sensor. - - For example, in a temperature-dependent IV measurement, the temperature and voltage must be - present as independently scanned controllers and the current sensor must also be present with - its readings. - (NXsensor): - (NXdata): - exists: recommended - doc: | - Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. - value(NX_FLOAT): - unit: NX_ANY - doc: | - For each point in the scan space, either the nominal setpoint of an independently scanned controller - or a representative average value of a measurement sensor is registered. - - The length of each sensor's data value array stored in this group should be equal to the number of scan points - probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. - This allows the scan to be made in any order as the user describes above in the experiment. We get matching - values simply using the index of the scan point. - dimensions: - rank: 1 - dim: [[1, N_scanpoints]] - value_timestamp(NX_DATE_TIME): - exists: recommended - doc: | - Timestamp for when the values provided in the value field were registered. - - Individual readings can be stored with their timestamps under value_log. This is to timestamp - the nominal setpoint or average reading values listed above in the value field. - run_control(NX_CHAR): - exists: recommended - \@description: - doc: | - Free-text describing the data acquisition control: an internal - sweep using the built-in functionality of the controller device, - or a set/wait/read/repeat mechanism. - calibration_time(NX_DATE_TIME): - doc: | - ISO8601 datum when calibration was last performed - before this measurement. UTC offset should be specified. - (NXpid): - independent_controllers(NX_CHAR): - doc: | - A list of names of NXsensor groups used as independently scanned controllers. - measurement_sensors(NX_CHAR): - doc: | - A list of names of NXsensor groups used as measurement sensors. - (NXsample): - name(NX_CHAR): - (NXdata): - doc: | - A scan specific representation of the measured signals as a function of the independently controlled environment settings. - Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. diff --git a/manual/source/index.rst b/manual/source/index.rst index c9a24b313a..1fae040ddc 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -17,6 +17,7 @@ https://www.nexusformat.org/ apm-structure transport-structure cgms-structure + laboratory-structure north-structure diff --git a/manual/source/laboratory-structure.rst b/manual/source/laboratory-structure.rst new file mode 100644 index 0000000000..05523bcbfe --- /dev/null +++ b/manual/source/laboratory-structure.rst @@ -0,0 +1,25 @@ +.. _Lab-Structure: + +================== +Sample preparation +================== + +.. index:: + Draft classes + +.. _LaboratorySteps: + +Virtually all experiments require a preparation of the sample. As most techniques +are surface-sensitive or probe exclusively the surface, the use of careful preparation +techniques is the key to successful experiments. Unfortunately, the quality of +such processes is often difficult to reproduce. Nevertheless, documenting how samples +are prepared is relevant. The classes here provide minimal examples how descriptions +of the sample preparation steps can be interfaced to NeXus. +Currently, we consider these drafts to work towards harmonization with the +specific examples developed by the team of area A of FAIRmat. + + :ref:`NXlab_sample_mounting`: + An application definition to document how a sample was mounted. + + :ref:`NXlab_electro_chemo_mechanical_preparation`: + An application definition to document how a sample was prepared. From 6b4190a561cb2ac43fd2f731e8ac5bd9beada739 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 20 Mar 2023 19:37:11 +0100 Subject: [PATCH 120/203] =?UTF-8?q?added=20NXms=5Fscore=5Fconfig=20to=20br?= =?UTF-8?q?idge=20to=20our=20colleagues=20from=20NFDI-MatWerk=20(results?= =?UTF-8?q?=20of=20bilateral=20discussions=20with=20Vitesh=20Shah=20and=20?= =?UTF-8?q?Franz=20Roters=20from=20MPIE=20in=20D=C3=BCsseldorf)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../NXms_score_config.nxdl.xml | 427 ++++++++++++++++++ .../nyaml/NXms_score_config.yaml | 306 +++++++++++++ manual/source/cgms-structure.rst | 24 +- 3 files changed, 748 insertions(+), 9 deletions(-) create mode 100644 contributed_definitions/NXms_score_config.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXms_score_config.yaml diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml new file mode 100644 index 0000000000..709fe5bb1b --- /dev/null +++ b/contributed_definitions/NXms_score_config.nxdl.xml @@ -0,0 +1,427 @@ + + + + + + + + Number of Bunge-Euler angle triplets for deformed grains. + + + + + Number of Bunge-Euler angle triplets for recrystallization nuclei. + + + + + Number of solitary unit domains to export. + + + + + Application definition to control a simulation with the SCORE model. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Relevant data to instantiate a starting configuration that is typically + a microstructure in deformed conditions where stored (elastic) energy + is stored in the form of crystal defects (in SCORE) modelled as + dislocation content. + + + + Which model should be used to generate a starting microstructure. + + + + + + + + + + + Edge length of the cubic cells of each CA domain. + + + + + Extend of each CA domain in voxel along the x, y, and z direction. Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. + + + + + + + + Extend of each deformed grain along the x, y, and z direction when type is cuboidal. + + + + + + + + Average spherical diameter when type is poisson_voronoi. + + + + + Set of Bunge-Euler angles to sample orientations randomly from. + + + + + + + + + + Path and name of the EBSD dataset from which to generate the starting microstructure. + + + + SHA256 checksum of the file which contains the EBSD dataset. + + + + + + Size of the EBSD. The EBSD has to be on a regular grid of squares. + + + + + + + + + + Phenomenological model according to which it nuclei are placed + into the domain and assumed growing. + + + + According to which model will the nuclei become distributed spatially. CSR means complete spatial randomness, custom is implementation specific, GB places nuclei at grain boundaries. + + + + + + + + + + According to which model will the nuclei start to grow. + + + + + + + + Set of Bunge-Euler angles to sample orientations of nuclei randomly from. + + + + + + + + + + Mechanical properties of the material which scale the amount + of stored (elastic) energy in the system. + + + + Shear modulus at zero Kelvin. + + + + + Magnitude at the Burgers vector at zero Kelvin. + + + + + Melting temperature in degrees Celsius. + + + + + + Model for the assumed mobility of grain boundaries with different disorientation. + + + + Which type of fundamental model for the grain boundary mobility: + For the Sebald-Gottstein model the following equation is used. + For the Rollett-Holm model the following equation is used. + + + + + + + + + + + + + + + + + + + + + + + + + Simulated evolution of the dislocation density as the stored + (elastic) energy assumed stored in each grain. + + + + Which type of recovery model. + + + + + + + + + Simulated reduction of the grain boundary speed due to + the presence of dispersoids through which the total grain boundary + area of the recrystallization front can be reduced. + + + + Which type of drag model. + + + + + + + + + + + + Support point of the linearized curve of simulated time matching + a specific support point of the average dispersoid radius. + + + + + + + + Support point of the linearized curve of the average dispersoid radius. + + + + + + + + + + Simulated time temperature profile + + + + Support point of the linearized curve of simulated time matching + a specific support point of the temperature. + + + + + + + + Support point of the linearized curve of the temperature. + + + + + + + + + Criteria which enable to stop the simulation. + Whichever criterion is fulfilled first stops the simulation. + + + + Maximum recrystallized volume fraction. + + + + + Maximum simulated physical time. + + + + + Maximum number of iteration steps. + + + + + + Settings relevant for stable numerical integration. + + + + Maximum fraction equivalent to the migration of the + fastest grain boundary in the system how much a cell + may be consumed in a single iteration. + + + + + Fraction of the total number of cells in the CA which + should initially be allocated for offering cells in the + recrystallization front. + + + + + By how much more times should the already allocated memory + be is increased to offer space for storing states of cells + in the recrystallization front. + + + + + Should the cache for cells in the recrystallization front + be defragmented on-the-fly. + + + + + Heuristic recrystallized volume target values at which + the cache for cells in the recrystallization front + will be defragmented on-the-fly. + + + + + + + + List of recrystallized volume target values at which a + snapshot of the CA state should be exported for. + + + + + + + + + + Perform a statistical analyses of the results as it was + proposed by M. Kühbach (solitary unit model ensemble approach). + + + + + How many independent cellular automaton domains + should be instantiated. + + + + + Into how many time steps should the real time interval be discretized upon during post-processing the results with the solitary unit modeling approach. + + + + + List of identifier for those domain which should be rendered. + Identifier start from 0. + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXms_score_config.yaml b/contributed_definitions/nyaml/NXms_score_config.yaml new file mode 100644 index 0000000000..1e6f577890 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_score_config.yaml @@ -0,0 +1,306 @@ +category: application +doc: | + Application definition to control a simulation with the SCORE model. +symbols: + n_dg_ori: | + Number of Bunge-Euler angle triplets for deformed grains. + n_rx_ori: | + Number of Bunge-Euler angle triplets for recrystallization nuclei. + n_su: | + Number of solitary unit domains to export. +NXms_score_config: + (NXentry): + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXms_score_config] + PROGRAM(NXprogram): + program_name: + \@version: + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + initial_microstructure(NXprocess): + doc: | + Relevant data to instantiate a starting configuration that is typically + a microstructure in deformed conditions where stored (elastic) energy + is stored in the form of crystal defects (in SCORE) modelled as + dislocation content. + type: + doc: | + Which model should be used to generate a starting microstructure. + enumeration: [cuboidal, poisson_voronoi, ebsd, damask] + cell_size(NX_FLOAT): + doc: | + Edge length of the cubic cells of each CA domain. + unit: NX_LENGTH + domain_size(NX_UINT): + doc: | + Extend of each CA domain in voxel along the x, y, and z direction. Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 3]] + grain_size(NX_FLOAT): + doc: | + Extend of each deformed grain along the x, y, and z direction when type is cuboidal. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + grain_diameter(NX_FLOAT): + doc: | + Average spherical diameter when type is poisson_voronoi. + unit: NX_LENGTH + grain_euler(NX_FLOAT): + doc: | + Set of Bunge-Euler angles to sample orientations randomly from. + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, n_dg_ori], [2, 3]] + ebsd(NXprocess): + exists: optional # when type is ebsd then required + filename: + doc: | + Path and name of the EBSD dataset from which to generate the starting microstructure. + \@version: + doc: | + SHA256 checksum of the file which contains the EBSD dataset. + stepsize(NX_FLOAT): + doc: | + Size of the EBSD. The EBSD has to be on a regular grid of squares. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 2]] + nucleation_model(NXprocess): + doc: | + Phenomenological model according to which it nuclei are placed + into the domain and assumed growing. + spatial_distribution_model: + doc: | + According to which model will the nuclei become distributed spatially. CSR means complete spatial randomness, custom is implementation specific, GB places nuclei at grain boundaries. + enumeration: [csr, custom, gb] + incubation_time_model: + doc: | + According to which model will the nuclei start to grow. + enumeration: [site_saturation] + nucleus_euler(NX_FLOAT): + doc: | + Set of Bunge-Euler angles to sample orientations of nuclei randomly from. + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, n_rx_ori], [2, 3]] + material_properties(NXprocess): + doc: | + Mechanical properties of the material which scale the amount + of stored (elastic) energy in the system. + reference_shear_modulus(NX_FLOAT): + doc: | + Shear modulus at zero Kelvin. + unit: NX_PRESSURE + reference_burgers_magnitude(NX_FLOAT): + doc: | + Magnitude at the Burgers vector at zero Kelvin. + unit: NX_LENGTH + # firstOrderdG0dT + # alloyConstantThermalExpCoeff + # FirstOrderThermalExpCoeff + # SecondOrderThermalExpCoeff + melting_temperature(NX_FLOAT): + doc: | + Melting temperature in degrees Celsius. + unit: NX_TEMPERATURE + grain_boundary_mobility_model(NXprocess): + doc: | + Model for the assumed mobility of grain boundaries with different disorientation. + model: + doc: | + Which type of fundamental model for the grain boundary mobility: + For the Sebald-Gottstein model the following equation is used. + For the Rollett-Holm model the following equation is used. + enumeration: [sebald_gottstein, rollett_holm] + sebald_gottstein_parameter(NXcollection): + lagb_pre_factor(NX_FLOAT): + unit: NX_ANY + lagb_enthalpy(NX_FLOAT): + unit: NX_ANY + hagb_pre_factor(NX_FLOAT): + unit: NX_ANY + hagb_enthalpy(NX_FLOAT): + unit: NX_ANY + special_pre_factor(NX_FLOAT): + unit: NX_ANY + special_enthalpy(NX_FLOAT): + unit: NX_ANY + rollett_holm_parameter(NXcollection): + hagb_pre_factor(NX_FLOAT): + unit: NX_ANY + hagb_enthalpy(NX_FLOAT): + unit: NX_ANY + lagb_to_hagb_cut(NX_FLOAT): + unit: NX_ANY + lagb_to_hagb_transition(NX_FLOAT): + unit: NX_ANY + lagb_to_hagb_exponent(NX_FLOAT): + unit: NX_ANY + stored_energy_recovery_model(NXprocess): + doc: | + Simulated evolution of the dislocation density as the stored + (elastic) energy assumed stored in each grain. + model: + doc: | + Which type of recovery model. + enumeration: [none] + dispersoid_drag_model(NXprocess): + doc: | + Simulated reduction of the grain boundary speed due to + the presence of dispersoids through which the total grain boundary + area of the recrystallization front can be reduced. + model: + doc: | + Which type of drag model. + enumeration: [none, zener_smith] + zener_smith_parameter(NXcollection): + pre_factor(NX_FLOAT): + surface_energy_density(NX_FLOAT): + time(NX_FLOAT): + doc: | + Support point of the linearized curve of simulated time matching + a specific support point of the average dispersoid radius. + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, i]] + radius(NX_FLOAT): + doc: | + Support point of the linearized curve of the average dispersoid radius. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, i]] + time_temperature_history(NXprocess): + doc: | + Simulated time temperature profile + time(NX_FLOAT): + doc: | + Support point of the linearized curve of simulated time matching + a specific support point of the temperature. + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, j]] + temperature(NX_FLOAT): + doc: | + Support point of the linearized curve of the temperature. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, j]] + stop_criteria(NXprocess): + doc: | + Criteria which enable to stop the simulation. + Whichever criterion is fulfilled first stops the simulation. + max_x(NX_FLOAT): + doc: | + Maximum recrystallized volume fraction. + unit: NX_DIMENSIONLESS + max_time(NX_NUMBER): + doc: | + Maximum simulated physical time. + unit: NX_TIME + max_iteration(NX_UINT): + doc: | + Maximum number of iteration steps. + unit: NX_UNITLESS + numerics(NXprocess): + doc: | + Settings relevant for stable numerical integration. + max_delta_x(NX_FLOAT): + doc: | + Maximum fraction equivalent to the migration of the + fastest grain boundary in the system how much a cell + may be consumed in a single iteration. + unit: NX_DIMENSIONLESS + initial_cell_cache(NX_FLOAT): + doc: | + Fraction of the total number of cells in the CA which + should initially be allocated for offering cells in the + recrystallization front. + unit: NX_UNITLESS + realloc_cell_cache(NX_FLOAT): + doc: | + By how much more times should the already allocated memory + be is increased to offer space for storing states of cells + in the recrystallization front. + unit: NX_UNITLESS + defragment_cell_cache(NX_BOOLEAN): + doc: | + Should the cache for cells in the recrystallization front + be defragmented on-the-fly. + defragment_x(NX_FLOAT): + doc: | + Heuristic recrystallized volume target values at which + the cache for cells in the recrystallization front + will be defragmented on-the-fly. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, i]] + snapshot_x(NX_FLOAT): + doc: | + List of recrystallized volume target values at which a + snapshot of the CA state should be exported for. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, j]] + solitary_unit_model(NXprocess): + apply(NX_BOOLEAN): + doc: | + Perform a statistical analyses of the results as it was + proposed by M. Kühbach (solitary unit model ensemble approach). + number_of_domains(NX_UINT): + doc: | + How many independent cellular automaton domains + should be instantiated. + unit: NX_UNITLESS + rediscretization(NX_UINT): + doc: | + Into how many time steps should the real time interval be discretized upon during post-processing the results with the solitary unit modeling approach. + unit: NX_UNITLESS + domain_identifier(NX_UINT): + doc: | + List of identifier for those domain which should be rendered. + Identifier start from 0. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_su]] + + performance(NXcs_profiling): + current_working_directory: diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index 1ba3655827..52aafd73b8 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -32,13 +32,15 @@ already existent base classes in NeXus for constructive solid geometry such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name but a few. Second, we would like to explore with this proposal how we can harmonize terms -frequently used by materials scientists in the field of condensed-matter physics with definitions and terms offer by the NOMAD MetaInfo description. +frequently used by materials scientists in the field of condensed-matter physics +with definitions and terms offer by the NOMAD MetaInfo description. Third, the proposal should yield a substantiated set of arguments and suggestions how descriptors for the structure and atomic architecture of materials can be harmonized. With this we especially would like to reach out and intensify the cooperation between the materials-science-related consortia of the German -National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. +National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, +NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. .. The proposal reaches out to our colleagues in the materials engineering-based .. consortia to document that there is value in discussing about controlled vocabulary. @@ -83,13 +85,16 @@ with defined geometric primitives and associated coarser-scale properties. The key motivation to such coarse-graining is to reduce the complexity of the description. On the one hand to support visualization and scientific analyses - not only of crystal defect arrangements. On the other hand it is the hope that using descriptors -at a coarser level, i.e. nanometer, micrometer, and larger, it is still possible to find sufficiently -accurate and precise descriptors which avoid that one has to account for the dynamics of each atom to predict or understand the properties of defects and their dynamics. +at a coarser level, i.e. nanometer, micrometer, and larger, it is still possible +to find sufficiently accurate and precise descriptors which avoid that one has +to account for the dynamics of each atom to predict or understand the properties +of defects and their dynamics. Nevertheless, experience has shown that computational-geometry-based descriptions when combined with hierarchical clustering/labeling methods, applied on set of -atoms and features turn out to yield useful descriptors. Examples include point, line, surface defects, -such as vacancies, solute cluster, dislocations, disconnections, interfaces to name but a few. +atoms and features turn out to yield useful descriptors. Examples include point, +line, surface defects, such as vacancies, solute cluster, dislocations, +disconnections, interfaces to name but a few. .. _CgmsBC: @@ -280,7 +285,8 @@ To begin with we propose the following draft application definitions. :ref:`NXms`: An application definition for arbitrary spatiotemporally resolved simulations. + :ref:`NXms_score_config`: + A specific example how :ref:`NXapm_paraprobe_config_ranger` can be specialized for documenting the configuration of a computer simulation with the static recrystallization cellular automata model SCORE. + :ref:`NXms_score_results`: - A specific example how :ref:`NXms` can be specialized for documenting - results of computer simulations with the static recrystallization - cellular automata model SCORE. + A specific example how :ref:`NXms` can be specialized for documenting results of computer simulations with the static recrystallization cellular automata model SCORE. From 22c1e1dfe6e71340c77174d0efc1393fd5192882 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Tue, 21 Mar 2023 16:02:10 +0100 Subject: [PATCH 121/203] added make test to the make file and fixed issues with make test which broke the CI pipeline --- Example_definition/NXexample.nxdl.xml | 487 ------------------ Example_definition/NXexample.yaml | 421 --------------- Makefile | 1 + .../NXapm_paraprobe_config_clusterer.nxdl.xml | 2 +- .../NXapm_paraprobe_config_distancer.nxdl.xml | 2 +- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 2 +- .../NXapm_paraprobe_config_ranger.nxdl.xml | 2 +- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 2 +- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 2 +- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 2 +- ...Xapm_paraprobe_results_transcoder.nxdl.xml | 2 +- .../NXfabrication.nxdl.xml | 6 +- .../NXlab_sample_mounting.nxdl.xml | 26 +- .../NXmatch_filter.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 2 +- .../NXms_score_config.nxdl.xml | 4 +- .../NXms_score_results.nxdl.xml | 2 +- .../NXsubsampling_filter.nxdl.xml | 2 +- .../NXapm_paraprobe_config_clusterer.yaml | 1 - .../NXapm_paraprobe_config_distancer.yaml | 1 - .../NXapm_paraprobe_config_nanochem.yaml | 1 - .../nyaml/NXapm_paraprobe_config_ranger.yaml | 1 - .../NXapm_paraprobe_config_spatstat.yaml | 1 - .../NXapm_paraprobe_config_surfacer.yaml | 1 - .../NXapm_paraprobe_config_tessellator.yaml | 1 - .../NXapm_paraprobe_results_transcoder.yaml | 1 - .../nyaml/NXfabrication.yaml | 3 - .../nyaml/NXlab_sample_mounting.yaml | 15 +- .../nyaml/NXmatch_filter.yaml | 2 - contributed_definitions/nyaml/NXms.yaml | 1 - .../nyaml/NXms_score_config.yaml | 2 +- .../nyaml/NXms_score_results.yaml | 1 - .../nyaml/NXsubsampling_filter.yaml | 1 - 33 files changed, 39 insertions(+), 965 deletions(-) delete mode 100644 Example_definition/NXexample.nxdl.xml delete mode 100644 Example_definition/NXexample.yaml diff --git a/Example_definition/NXexample.nxdl.xml b/Example_definition/NXexample.nxdl.xml deleted file mode 100644 index c477dcd934..0000000000 --- a/Example_definition/NXexample.nxdl.xml +++ /dev/null @@ -1,487 +0,0 @@ - - - - - - - - This is doc for symbol. - - - - This is doc for symbol_1. - - - - - This is doc for symbol_2. - - - - - This is doc for root level. - - - - This is for attribute - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - - - This is for attribute - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - This is doc for field. - - - This is for attribute - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - - - - This is for attribute - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - This is doc for field. - - - This is for attribute - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - - - - - This is for attribute - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - This is doc for field. - - - This is for attribute - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - - - - This is for attribute - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - This is doc for field. - - - This is for attribute - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - This is doc for dimensions. - - - This is doc for dim_1 - - - This is doc for dim_1 - - - - - - This is doc for item_1. - - - - - This is doc for item_2. - - - - - - - - diff --git a/Example_definition/NXexample.yaml b/Example_definition/NXexample.yaml deleted file mode 100644 index c4c80bf8b9..0000000000 --- a/Example_definition/NXexample.yaml +++ /dev/null @@ -1,421 +0,0 @@ -doc: | - This is doc for root level. -symbols: - doc: | - This is doc for symbol. - - symbol_1: | - This is doc for symbol_1. - - symbol_2: | - This is doc for symbol_2. - -category: base -ignoreExtraAttributes: value_ignoreExtraAttributes -ignoreExtraFields: vlaue_ignoreExtraFields -ignoreExtraGroups: ignoreExtraGroups -restricts: restricts -type: group -(NXobject)NXgrating: - \@doc_attribute1: - recommended: ture - optional: ture - doc: | - This is for attribute - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - link1(link): - target: target_1 - napimount: napimount_1 - link2(link): - target: target_2 - napimount: napimount_2 - \@doc_attribute_2(NX_INT): - recommended: ture - optional: ture - doc: | - This is for attribute - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - field_x(NX_INT): - exists: [min, 3, max, 4] - unit: NX_LENGTH - nameType: nameType_1 - axis: 1 - signal: signal - doc: | - This is doc for field. - \@doc_attribute_2(NX_INT): - recommended: ture - optional: ture - doc: | - This is for attribute - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - link1(link): - target: target_1 - napimount: napimount_1 - link2(link): - target: target_2 - napimount: napimount_2 - group_1: - exists: [min, 1, max, 2] - \@doc_attribute1: - recommended: ture - optional: ture - doc: | - This is for attribute - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - field_1(NX_INT): - exists: [min, 3, max, 4] - unit: NX_LENGTH - nameType: nameType_1 - axis: 1 - signal: signal - doc: | - This is doc for field. - \@doc_attribute_2(NX_INT): - recommended: ture - optional: ture - doc: | - This is for attribute - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - link1(link): - target: target_1 - napimount: napimount_1 - link2(link): - target: target_2 - napimount: napimount_2 - choice_name_1(choice): - group_2: - exists: [min, 1, max, 2] - \@doc_attribute1: - recommended: ture - optional: ture - doc: | - This is for attribute - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - field2(NX_INT): - exists: [min, 3, max, 4] - unit: NX_LENGTH - nameType: nameType_1 - axis: 1 - signal: signal - doc: | - This is doc for field. - \@doc_attribute_2(NX_INT): - recommended: ture - optional: ture - doc: | - This is for attribute - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - link1(link): - target: target_1 - napimount: napimount_1 - link2(link): - target: target_2 - napimount: napimount_2 - group_3: - exists: [min, 1, max, 2] - \@doc_attribute1: - recommended: ture - optional: ture - doc: | - This is for attribute - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - fiel4(NX_INT): - exists: [min, 3, max, 4] - unit: NX_LENGTH - nameType: nameType_1 - axis: 1 - signal: signal - doc: | - This is doc for field. - \@doc_attribute_2(NX_INT): - recommended: ture - optional: ture - doc: | - This is for attribute - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - dimensions: - rank: someRank - dim: [[1, dim_value_1], [2, dim_value_2]] - dim_doc: | - ['This is doc for dim_1', 'This is doc for dim_1'] - incr: ['di_incr_1', 'di_incr_2'] - refindex: ['refindex_1', 'refindex_2'] - required: ['required_1', 'required_2'] - ref: ['dim_ref_1', 'dim_ref_2'] - doc: | - This is doc for dimensions. - enumeration: - itme_value_1: - doc: | - This is doc for item_1. - itme_value_2: - doc: | - This is doc for item_2. - link1(link): - target: target_1 - napimount: napimount_1 - link2(link): - target: target_2 - napimount: napimount_2 diff --git a/Makefile b/Makefile index 69075caeba..65d1840899 100644 --- a/Makefile +++ b/Makefile @@ -84,6 +84,7 @@ all :: @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus.pdf`" nexus-fairmat-proposal :: + $(MAKE) test $(MAKE) clean $(MAKE) prepare $(SPHINX) -b html $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml index c1bee3f943..473b5444b9 100644 --- a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -191,7 +191,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml index ffb71a285c..ffedb91510 100644 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -103,7 +103,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml index cc54d8b3c7..db73771443 100644 --- a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -128,7 +128,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml index 62550c5fdf..9f9625db36 100644 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -127,7 +127,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml index f60ce3566f..84ebc893e1 100644 --- a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -119,7 +119,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml index e498d88448..ac2b19733b 100644 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -114,7 +114,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml index d186fa3476..ced8e4ba14 100644 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -103,7 +103,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml index 877dd230bf..0a2f1c8870 100644 --- a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -177,7 +177,7 @@ - + An array of triplets of integers which can serve as a supplementary array for Paraview to display the reconstruction. The XDMF datatype diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index d687950d02..160cc82aa8 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -25,17 +25,17 @@ Details about a component as defined by its manufacturer. - + Company name of the manufacturer. - + Version or model of the component named by the manufacturer. - + Ideally, (globally) unique persistent identifier, i.e. a serial number or hash identifier of the component. diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml index 2f99e88903..a60bf2ca4d 100644 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -63,20 +63,18 @@ - - - Type of material. - - - - - - - - - Electrical conductivity of the embedding medium. - - + + Type of material. + + + + + + + + + Electrical conductivity of the embedding medium. + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index 9f1562c1b0..e3d0b200dd 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -35,7 +35,7 @@ Settings of a filter to select or remove entries based on their value. - + Meaning of the filter: Whitelist specifies which entries with said value to include. @@ -49,7 +49,7 @@ - + Array of values to filter according to method. For example if the filter specifies [1, 5, 6] and method is whitelist, only entries with values diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index b8be940793..fb81223cb7 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -272,7 +272,7 @@ - + Collection of microstructural data observed/simulated. diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml index 709fe5bb1b..c9aa3ac0a6 100644 --- a/contributed_definitions/NXms_score_config.nxdl.xml +++ b/contributed_definitions/NXms_score_config.nxdl.xml @@ -320,12 +320,12 @@ - + Criteria which enable to stop the simulation. Whichever criterion is fulfilled first stops the simulation. - + Maximum recrystallized volume fraction. diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 49293c0965..131c9e352c 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -344,7 +344,7 @@ - + Collection of microstructural data observed/simulated. diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 4939c368c1..f19fa0c856 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -30,7 +30,7 @@ Settings of a filter to sample entries based on their value. - + Triplet of the minimum, increment, and maximum value which will be included in the analysis. The increment controls which n-th entry to take. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml index 574dba0b21..f60ec06fb9 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml @@ -154,7 +154,6 @@ NXapm_paraprobe_config_clusterer: spatial_filter(NXspatial_filter): exists: optional windowing_method: - exists: required enumeration: [entire_dataset] # ##MK::nothing implemented so far (NXcg_ellipsoid_set): exists: optional diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml index e5d725e41d..120b994884 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml @@ -56,7 +56,6 @@ NXapm_paraprobe_config_distancer: spatial_filter(NXspatial_filter): exists: optional windowing_method: - exists: required (NXcg_ellipsoid_set): exists: optional dimensionality(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml index c192d7a352..758a0602ef 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml @@ -63,7 +63,6 @@ NXapm_paraprobe_config_nanochem: spatial_filter(NXspatial_filter): exists: optional windowing_method: - exists: required (NXcg_ellipsoid_set): exists: optional dimensionality(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml index 9546b302d4..b4b7e8fe21 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml @@ -75,7 +75,6 @@ NXapm_paraprobe_config_ranger: spatial_filter(NXspatial_filter): exists: optional windowing_method: - exists: required (NXcg_ellipsoid_set): exists: optional dimensionality(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml index ddc514e0e8..105ce7fcf6 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml @@ -64,7 +64,6 @@ NXapm_paraprobe_config_spatstat: spatial_filter(NXspatial_filter): exists: optional windowing_method: - exists: required (NXcg_ellipsoid_set): exists: optional dimensionality(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml index 9de4c92e84..a54a3a477d 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml @@ -62,7 +62,6 @@ NXapm_paraprobe_config_surfacer: spatial_filter(NXspatial_filter): exists: optional windowing_method: - exists: required (NXcg_ellipsoid_set): exists: optional dimensionality(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml index fb675f722a..2833a47c61 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml @@ -60,7 +60,6 @@ NXapm_paraprobe_config_tessellator: spatial_filter(NXspatial_filter): exists: optional windowing_method: - exists: required (NXcg_ellipsoid_set): exists: optional dimensionality(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml index 5b72b00819..a83752945c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml @@ -122,7 +122,6 @@ NXapm_paraprobe_results_transcoder: visualization(NXprocess): exists: recommended xdmf_topology(NX_UINT): - exists: required doc: | An array of triplets of integers which can serve as a supplementary array for Paraview to display the reconstruction. The XDMF datatype diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml index 4253d7a200..4f01979e03 100644 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -3,13 +3,10 @@ doc: | Details about a component as defined by its manufacturer. NXfabrication: vendor: - exists: required doc: Company name of the manufacturer. model: - exists: required doc: Version or model of the component named by the manufacturer. identifier: - exists: recommended doc: | Ideally, (globally) unique persistent identifier, i.e. a serial number or hash identifier of the component. diff --git a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml index 912f7a228b..79a404dab6 100644 --- a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml +++ b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml @@ -31,14 +31,13 @@ NXlab_sample_mounting: Qualitative statement how the sample was mounted. enumeration: [cold_mounting, hot_mounting] embedding_medium: # or material from controlled vocabulary list - type: - doc: | - Type of material. - enumeration: [resin, epoxy] - electrical_conductivity(NX_FLOAT): - doc: | - Electrical conductivity of the embedding medium. - unit: NX_ANY + doc: | + Type of material. + enumeration: [resin, epoxy] + electrical_conductivity(NX_FLOAT): + doc: | + Electrical conductivity of the embedding medium. + unit: NX_ANY # temperature control of the mounting (e.g. relevant when hot_mounting Al) # cleaning procedures # a descriptor of the shape of the specimen diff --git a/contributed_definitions/nyaml/NXmatch_filter.yaml b/contributed_definitions/nyaml/NXmatch_filter.yaml index b8cda3e529..06f3a0c759 100644 --- a/contributed_definitions/nyaml/NXmatch_filter.yaml +++ b/contributed_definitions/nyaml/NXmatch_filter.yaml @@ -6,7 +6,6 @@ symbols: n_values: How many different match values does the filter specify. NXmatch_filter: method: - exists: required doc: | Meaning of the filter: Whitelist specifies which entries with said value to include. @@ -16,7 +15,6 @@ NXmatch_filter: Entries with all other values will be included. enumeration: [whitelist, blacklist] match(NX_NUMBER): - exists: required doc: | Array of values to filter according to method. For example if the filter specifies [1, 5, 6] and method is whitelist, only entries with values diff --git a/contributed_definitions/nyaml/NXms.yaml b/contributed_definitions/nyaml/NXms.yaml index fe21f2d03d..c2a17fee6e 100644 --- a/contributed_definitions/nyaml/NXms.yaml +++ b/contributed_definitions/nyaml/NXms.yaml @@ -243,7 +243,6 @@ NXms: # (NXannealing) rank: 1 dim: [[1, n_b]] snapshot_set(NXms_snapshot_set): - exists: required doc: | Collection of microstructural data observed/simulated. identifier_offset(NX_UINT): diff --git a/contributed_definitions/nyaml/NXms_score_config.yaml b/contributed_definitions/nyaml/NXms_score_config.yaml index 1e6f577890..40ba43ed3e 100644 --- a/contributed_definitions/nyaml/NXms_score_config.yaml +++ b/contributed_definitions/nyaml/NXms_score_config.yaml @@ -228,7 +228,7 @@ NXms_score_config: max_x(NX_FLOAT): doc: | Maximum recrystallized volume fraction. - unit: NX_DIMENSIONLESS + unit: NX_DIMENSIONLESS max_time(NX_NUMBER): doc: | Maximum simulated physical time. diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml index 1bb11eead6..1efb4c1745 100644 --- a/contributed_definitions/nyaml/NXms_score_results.yaml +++ b/contributed_definitions/nyaml/NXms_score_results.yaml @@ -266,7 +266,6 @@ NXms_score_results: dim: [[1, n_b]] snapshot_set(NXms_snapshot_set): - exists: required doc: | Collection of microstructural data observed/simulated. identifier_offset(NX_UINT): diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/NXsubsampling_filter.yaml index 3a27ddf114..96b69dba88 100644 --- a/contributed_definitions/nyaml/NXsubsampling_filter.yaml +++ b/contributed_definitions/nyaml/NXsubsampling_filter.yaml @@ -5,7 +5,6 @@ symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. NXsubsampling_filter: linear_range_min_incr_max(NX_UINT): - exists: required doc: | Triplet of the minimum, increment, and maximum value which will be included in the analysis. The increment controls which n-th entry to take. From 9636feecb79bb32b828b1a9804269573256d7696 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 22 Mar 2023 08:19:07 +0100 Subject: [PATCH 122/203] Removes duplicate yml files for dispersive material --- .../nyaml/NXdispersion.yml | 11 -- .../nyaml/NXdispersion_function.yml | 73 -------- .../nyaml/NXdispersion_repeated_parameter.yml | 30 --- .../nyaml/NXdispersion_single_parameter.yml | 14 -- .../nyaml/NXdispersion_table.yml | 48 ----- .../nyaml/NXdispersive_material.yml | 177 ------------------ 6 files changed, 353 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXdispersion.yml delete mode 100644 contributed_definitions/nyaml/NXdispersion_function.yml delete mode 100644 contributed_definitions/nyaml/NXdispersion_repeated_parameter.yml delete mode 100644 contributed_definitions/nyaml/NXdispersion_single_parameter.yml delete mode 100644 contributed_definitions/nyaml/NXdispersion_table.yml delete mode 100644 contributed_definitions/nyaml/NXdispersive_material.yml diff --git a/contributed_definitions/nyaml/NXdispersion.yml b/contributed_definitions/nyaml/NXdispersion.yml deleted file mode 100644 index 963d7b12b3..0000000000 --- a/contributed_definitions/nyaml/NXdispersion.yml +++ /dev/null @@ -1,11 +0,0 @@ -category: base -doc: | - A dispersion denoting a sum of different dispersions. - All NXdispersion_table and NXdispersion_function groups will be added together - to form a single dispersion. -NXdispersion: - model_name(NX_CHAR): - doc: | - The name of the composite model. - (NXdispersion_table): - (NXdispersion_function): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_function.yml b/contributed_definitions/nyaml/NXdispersion_function.yml deleted file mode 100644 index e197e3f507..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_function.yml +++ /dev/null @@ -1,73 +0,0 @@ -category: base -doc: | - This describes a dispersion function for a material or layer -symbols: - n_repetitions: | - The number of repetitions for the repeated parameters -NXdispersion_function: - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - formula(NX_CHAR): - doc: | - This should be a python parsable function. - Here we should provide which keywords are available - and a BNF of valid grammar. - convention(NX_CHAR): - doc: | - The sign convention being used (n + or - ik) - enumeration: ["n + ik", "n - ik"] - energy_identifier(NX_CHAR): - doc: | - The identifier used to represent energy - in the formula. It is recommended to use `E`. - energy_min(NX_NUMBER): - doc: | - The minimum energy value at which this formula is valid. - unit: NX_ENERGY - energy_max(NX_NUMBER): - doc: | - The maximum energy value at which this formula is valid. - unit: NX_ENERGY - energy_unit(NX_NUMBER): - doc: | - The energy unit used in the formula. - The field value is a scaling factor for the units attribute. - It is recommeded to set the field value to 1 and carry all the unit - scaling information in the units attribute. - unit: NX_ENERGY - wavelength_identifier(NX_CHAR): - doc: | - The identifier useed to represent wavelength - in the formula. It is recommended to use `lambda`. - wavelength_unit(NX_NUMBER): - doc: | - The wavelength unit used in the formula. - The field value is a scaling factor for the units attribute. - It is recommeded to set the field value to 1 and carry all the unit - scaling information in the units attribute. - unit: NX_LENGTH - wavelength_min(NX_NUMBER): - doc: | - The minimum wavelength value at which this formula is valid. - unit: NX_LENGTH - wavelength_max(NX_NUMBER): - doc: | - The maximum wavelength value at which this formula is valid. - unit: NX_LENGTH - representation(NX_CHAR): - doc: | - Which representation does the formula evaluate to. - This may either be n for refractive index or eps for dielectric function. - The appropriate token is then to be used inside the formula. - enumeration: [n, eps] - (NXdispersion_single_parameter): - (NXdispersion_repeated_parameter): - parameter_units: - dimensions: - rank: 1 - dim: [[1, n_repetitions]] - values(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_repetitions]] diff --git a/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yml b/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yml deleted file mode 100644 index 80b6e55178..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yml +++ /dev/null @@ -1,30 +0,0 @@ -category: base -doc: | - A repeated parameter for a dispersion function -symbols: - n_repetitions: | - The number of parameter repetitions -NXdispersion_repeated_parameter: - name(NX_CHAR): - doc: | - The name of the parameter - description(NX_CHAR): - doc: | - A description of what this parameter represents - parameter_units(NX_CHAR): - doc: | - A unit array associating a unit with each parameter. - The first element should be equal to values/@unit. - The values should be SI interpretable standard units - with common prefixes (e.g. mikro, nano etc.) or their - short-hand notation (e.g. nm, mm, kHz etc.). - dimensions: - rank: 1 - dim: [[1, n_repetitions]] - values(NX_NUMBER): - doc: | - The value of the parameter - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_repetitions]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_single_parameter.yml b/contributed_definitions/nyaml/NXdispersion_single_parameter.yml deleted file mode 100644 index 571edf0464..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_single_parameter.yml +++ /dev/null @@ -1,14 +0,0 @@ -category: base -doc: | - A single parameter for a dispersion function -NXdispersion_single_parameter: - name(NX_CHAR): - doc: | - The name of the parameter - description(NX_CHAR): - doc: | - A description of what this parameter represents - value(NX_NUMBER): - doc: | - The value of the parameter - unit: NX_ANY \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersion_table.yml b/contributed_definitions/nyaml/NXdispersion_table.yml deleted file mode 100644 index 0c691a5fa6..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_table.yml +++ /dev/null @@ -1,48 +0,0 @@ -category: base -doc: | - A dispersion table denoting energy, dielectric function tabulated values. -symbols: - doc: | - The symbols in this schema to denote the dimensions - n_points: | - The number of energy and dielectric function points -NXdispersion_table: - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - convention(NX_CHAR): - doc: | - The sign convention being used (n + or - ik) - enumeration: ['n + ik', 'n - ik'] - wavelength(NX_NUMBER): - doc: | - The wavelength array of the tabulated dataset. - This is essentially a duplicate of the energy field. - There should be one or both of them present. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_points]] - energy(NX_NUMBER): - doc: | - The energy array of the tabulated dataset. - This is essentially a duplicate of the wavelength field. - There should be one or both of them present. - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_points]] - refractive_index(NX_COMPLEX): - doc: | - The refractive index array of the tabulated dataset. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_points]] - dielectric_function(NX_COMPLEX): - doc: | - The dielectric function of the tabulated dataset. - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_points]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdispersive_material.yml b/contributed_definitions/nyaml/NXdispersive_material.yml deleted file mode 100644 index 16613789ce..0000000000 --- a/contributed_definitions/nyaml/NXdispersive_material.yml +++ /dev/null @@ -1,177 +0,0 @@ -category: application -doc: | - NXdispersion -NXdispersive_material: - (NXentry): - definition: - doc: "An application definition for a dispersive material." - \@version: - doc: "Version number to identify which definition of this application - definition was used for this entry/data." - \@url: - doc: "URL where to find further material (documentation, examples) - relevant to the application definition" - enumeration: [NXdispersive_material] - sample(NXsample): - chemical_formula(NX_CHAR): - atom_types(NX_CHAR): - exists: optional - doc: | - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - colloquial_name(NX_CHAR): - exists: optional - doc: | - The colloquial name of the material, e.g. graphite or diamond for carbon. - material_phase(NX_CHAR): - exists: optional - doc: | - The phase of the material - enumeration: [gas, liquid, solid, other] - material_phase_comment(NX_CHAR): - exists: optional - doc: | - Additional information about the phase if the - material phase is other. - additional_phase_information(NX_CHAR): - exists: recommended - doc: | - This field may be used to denote additional phase information, - such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or - if a measurement was done on a thin film or bulk material. - dispersion_type(NX_CHAR): - exists: recommended - doc: | - Denotes whether the dispersion is calculated or derived from an experiment - enumeration: ["measured", "simulated"] - REFERENCES(NXcite): - exists: recommended - text: - doc: | - A text description of this reference, e.g. - `E. Example et al, The mighty example, An example journal 50 (2023), 100` - doi: - dispersion_x(NXdispersion): - doc: | - The dispersion along the optical axis of the material. - This should be the only dispersion available for isotropic materials. - For uniaxial materials this denotes the ordinary axis. - For biaxial materials this denotes the x axis or epsilon 11 tensor element - of the diagionalized permittivity tensor. - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - (NXdispersion_table): - exists: recommended - model_name: - convention: - wavelength(NX_NUMBER): - dielectric_function(NX_COMPLEX): - exists: recommended - refractive_index(NX_COMPLEX): - exists: recommended - (NXdispersion_function): - exists: recommended - model_name: - formula: - convention: - energy_identifier: - exists: recommended - energy_unit(NX_NUMBER): - exists: recommended - wavelength_identifier: - exists: recommended - wavelength_unit(NX_NUMBER): - exists: recommended - representation: - (NXdispersion_single_parameter): - name: - value(NX_NUMBER): - (NXdispersion_repeated_parameter): - name: - values(NX_NUMBER): - plot(NXdata): - exists: recommended - dispersion_y(NXdispersion): - doc: | - This should only be filled for biaxial materials. - It denotes the epsilon 22 direction of the diagionalized - permittivity tensor. - exists: optional - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - (NXdispersion_table): - exists: recommended - model_name: - convention: - wavelength(NX_NUMBER): - dielectric_function(NX_COMPLEX): - exists: recommended - refractive_index(NX_COMPLEX): - exists: recommended - (NXdispersion_function): - exists: recommended - model_name: - formula: - convention: - energy_identifier: - exists: recommended - energy_unit(NX_NUMBER): - exists: recommended - wavelength_identifier: - exists: recommended - wavelength_unit(NX_NUMBER): - exists: recommended - representation: - (NXdispersion_single_parameter): - name: - value(NX_NUMBER): - (NXdispersion_repeated_parameter): - name: - values(NX_NUMBER): - plot(NXdata): - exists: recommended - dispersion_z(NXdispersion): - doc: | - This should only be filled for uniaxial or biaxial materials. - For uniaxial materials this denotes the extraordinary axis. - For biaxial materials this denotes the epsilon 33 tensor element - of the diagionalized perimittivty tensor. - exists: optional - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - (NXdispersion_table): - exists: recommended - model_name: - convention: - wavelength(NX_NUMBER): - dielectric_function(NX_COMPLEX): - exists: recommended - refractive_index(NX_COMPLEX): - exists: recommended - (NXdispersion_function): - exists: recommended - model_name: - formula: - convention: - energy_identifier: - exists: recommended - energy_unit(NX_NUMBER): - exists: recommended - wavelength_identifier: - exists: recommended - wavelength_unit(NX_NUMBER): - exists: recommended - representation: - (NXdispersion_single_parameter): - name: - value(NX_NUMBER): - (NXdispersion_repeated_parameter): - name: - values(NX_NUMBER): - plot(NXdata): - exists: recommended From 3c4cbcbb90640336206b99b75e03735f2353b9c6 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 18 Apr 2023 15:12:53 +0200 Subject: [PATCH 123/203] Change time to field with unit NX_TIME (#28) --- contributed_definitions/NXem_ebsd.nxdl.xml | 22 +- contributed_definitions/nyaml/NXem_ebsd.yaml | 318 +++++++++---------- 2 files changed, 170 insertions(+), 170 deletions(-) diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 3f25640534..bad6d7823b 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -210,7 +210,7 @@ Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific + like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform @@ -228,7 +228,7 @@ - Which role does the user have in the place and at the point + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating the microscope. Student, postdoc, principle investigator, guest are common examples. @@ -359,7 +359,7 @@ and polished to create a stack of orientation data which can be reconstructed to a three-dimensional volume ROI. - + Physical time since the beginning of a timestamp that is required to be same for all experiments in the set. The purpose of this marker is @@ -369,7 +369,7 @@ in-situ experiments where a measurement was e.g. taken after 0 minutes of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - + Transformation which details where the region-of-interest described under @@ -525,7 +525,7 @@ patterns to obtain orientation per phase model and scan point. Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - Common is that pattern indexing is a computational step of comparing + Common is that pattern indexing is a computational step of comparing simulated with measured diffraction pattern. Quality descriptors are defined based on which an indexing algorithm yields a quantitative measure of how similar measured and assumed/simulated pattern are, and thus if @@ -555,7 +555,7 @@ Case two were raw pattern in some custom format, often text-based with some but in general no conclusive and interoperable representation of all relevant metadata. - Often it remains unclear what individual fields and data arrays of these + Often it remains unclear what individual fields and data arrays of these fields resolve and/or mean conceptually. For some fields, publications were referred to. However, software tools change over time and thus which specific data end in a file and which specific conceptual information is behind @@ -676,10 +676,10 @@ Which return value did the indexing algorithm yield for each scan point. Practically useful is to use an uint8 mask. - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success * 255 - Unexpected errors @@ -776,7 +776,7 @@ - Matrix of parameterized orientations identified. The slow dimension + Matrix of parameterized orientations identified. The slow dimension iterates of the individual solutions as defined by n_phases_per_scan_point. Values for phases without a solution should be correctly identified as IEEE NaN. diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index c641f99d47..44638e4335 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -8,7 +8,7 @@ symbols: # what to do when multiple pattern are averaged into one before the beam moves further? doc: | Application definition for collecting and indexing Kikuchi pattern into orientation maps. - + This NXem_ebsd application is a proposal how to represent data, metadata, and connections between these for the research field of electron microscopy. More specifically, exemplified here for electron backscatter diffraction (EBSD). @@ -16,12 +16,12 @@ doc: | so far to document provenance of data and metadata in the field of EBSD. The application definition can be an example that is relevant for related workflows in orientation microscopy. - + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted according to the NXem_ebsd application definition) stores the connection between the microscope session and the key datasets which are considered typically results of the various processing steps involved when working with EBSD data. - + Different groups in this application definition make connections to data artifacts which were collected when working with electron microscopes via the NXem partner application definition. Using a file which stores information according to the @@ -31,7 +31,7 @@ doc: | Kikuchi pattern, associated overview images, like secondary electron or backscattered electron images of the region-of-interest probed and many more pieces of information. - + Secondly, this NXem_ebsd application definition connects and stores the conventions and reference frames which were used and are the key to mathematically correctly interpret every EBSD result. Otherwise, results would be ripped out of their @@ -40,7 +40,7 @@ doc: | with some technology-partner-specific file but leaving important conventions out or relying on the assumptions that colleagues know these even though multiple definitions are possible. - + This application definition covers experiments with one-, two-dimensional, and so-called three-dimensional EBSD datasets. The third dimension is either time (in the case of quasi in-situ experiments) or space (in the case of serial- @@ -48,19 +48,19 @@ doc: | repetitively to measure the same region-of-interest at different depth increments. Material removal can be achieved with electron or ion polishing, using manual steps or using automated equipment like a robot system. - + Three-dimensional experiments require to follow a sequence of specimen, surface preparation, and data collection steps. By nature these methods are destructive in that they either require the removal of the previously measured material region or that the sample surface can degrade due to e.g. contamination or other electron-matter interaction. - + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are combined into one reconstructed stack. That is serial-sectioning is mainly a computational workflow. Users collect data for each serial sectioning step via an experiment. This assures that data for associated microscope sessions and steps of data processing stay connected and contextualized. - + Eventual tomography methods also use such a workflow because first diffraction images are collected (e.g. with X-ray) and then these imagres are indexed and computed into a 3D orientation mapping. The here proposed NXem_ebsd application @@ -70,7 +70,7 @@ doc: | # The respective partner application definition NXxray_fourd # can be used for storing data and post-processing results of X-ray diffraction # experiments which can yield also orientation maps in one, two- or three-dimensions. -# +# # These complementary techniques and associated application definitions can be used # to inform NXms, another partner application definition to NXem_ebsd. NXms describes # the connection between measured or simulated structural features with a focus of @@ -89,7 +89,7 @@ doc: | # of NXem_event_data required than we factually more and more granularize and # pull in steps of detailed numerical post-processing which arguably is not # any longer at all necessarily related to the microscope session. -# We know many cases in EBSD community, see the work of e.g. Marc de Graef's group +# We know many cases in EBSD community, see the work of e.g. Marc de Graef's group # or of Hakon Wiik Anes and Knut Marthinsen who spent much longer with a collected # dataset in post-processing than collecting it at the microscope. Therefore, we # need to have the flexibility that documentation of the actual microscope session @@ -149,7 +149,7 @@ NXem_ebsd: doc: | Ideally, a (globally) unique persistent identifier for referring to this workflow. - + The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link workflows/experiments to e.g. proposals. @@ -157,7 +157,7 @@ NXem_ebsd: exists: optional doc: | Free-text description about the workflow. - + Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of the application definition behind instead of filling in these details into the experiment_description @@ -171,7 +171,7 @@ NXem_ebsd: application definition should only be used for specifying when the workflow was executed - and the exact duration is not relevant - this start_time field should be used. - + Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and interpretation of the workflow. @@ -213,13 +213,13 @@ NXem_ebsd: exists: recommended doc: | Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific + like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform orcid_platform: exists: recommended doc: | - Name of the OrcID or ResearcherID where the account - under orcid is registered. + Name of the OrcID or ResearcherID where the account + under orcid is registered. telephone_number: exists: optional doc: | @@ -228,7 +228,7 @@ NXem_ebsd: role: exists: recommended doc: | - Which role does the user have in the place and at the point + Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating the microscope. Student, postdoc, principle investigator, guest are common examples. @@ -243,8 +243,6 @@ NXem_ebsd: Name of the social media platform where the account under social_media_name is registered. - - # rotation and reference frame conventions # we assume that the conventions are the same across all experiments and/or # simulations which this application definition captures @@ -298,14 +296,14 @@ NXem_ebsd: spherical Kikuchi images which only when projected or observed in some region-of-interest will represent a set of rectangular Kikuchi pattern with the same rectangular shape and image size. - + Therefore, these pattern should be stored. The spherical diffraction pattern can be stored as a set of triangulated geodesic meshes. The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - + Do not store pattern in the simulation group if they have been measured are not simulated. - sequence_index(NX_POSINT): # 1 + sequence_index(NX_POSINT): # 1 (NXprogram): exists: [min, 0, max, infty] program_name: @@ -345,12 +343,12 @@ NXem_ebsd: doc: | The experiment group captures relevant details about the conditions of and the tools used for collecting the Kikuchi diffraction pattern. - + The most frequently collected EBSD data are captured as rectangular ROIs composed from square or hexagonally-shaped pixels. Substantially less frequently, because such experiments are more costly and technically demanding, correlated experiments are performed. - + One important class of such correlated experiments are the so-called (quasi) in-situ experiments. Here the same or nearly the same ROI is analyzed via a cycles of thermomechanical treatment, sample preparation, @@ -358,13 +356,14 @@ NXem_ebsd: recrystallization, strain accumulation, material damage. Post-processing is required to correlate and reidentify eventual features or local ROIs across several orientation maps. - + Another important class of correlated experiments are the so-called serial-sectioning experiments. Here the same sample is repetitively measured and polished to create a stack of orientation data which can be reconstructed to a three-dimensional volume ROI. - time(NX_TIME): - exists: optional # required for spatial and/or temporal for a correlation process + time(NX_NUMBER): + unit: NX_TIME + exists: optional # required for spatial and/or temporal for a correlation process doc: | Physical time since the beginning of a timestamp that is required to be same for all experiments in the set. The purpose of this marker is @@ -374,20 +373,20 @@ NXem_ebsd: in-situ experiments where a measurement was e.g. taken after 0 minutes of annealing, 30 minutes, 6 hours, or 24 hours of annealing. (NXtransformations): - exists: optional # required for a spatial correlation process + exists: optional # required for a spatial correlation process doc: | Transformation which details where the region-of-interest described under indexing is located in absolute coordinates and rotation with respect to which coordinate system. - calibration(NXprocess): # the more NeXus becomes supported the more we should go for (NXem) instead - exists: recommended # it should be required even for pattern simulations + calibration(NXprocess): # the more NeXus becomes supported the more we should go for (NXem) instead + exists: recommended # it should be required even for pattern simulations # although one could simulate spherical Kikuchi pattern without modeling the detector system doc: | The EBSD system, including components like the electron gun, pole-piece, stage tilting, EBSD detector, and the gnomonic projection have to be calibrated to achieve reliable results. Specifically, the gnomonic projection has to be calibrated. - + In most practical cases, especially in engineering, there is a substantially larger number of sessions where such a calibrated system is used assuming that somebody has properly calibrated the system rather than that the user @@ -395,7 +394,7 @@ NXem_ebsd: Especially the projection geometry has to calibrated which is usually achieved with measuring silicon, quartz or standards, and comparing against simulated diffraction pattern. - + In the first case, the user assumes that the principle geometry of the hardware components and the settings in the control and EBSD pattern acquisition software are calibrated. Consequently, users pick from an @@ -405,7 +404,7 @@ NXem_ebsd: is represented by one NXem_ebsd_crystal_structure_model base class. For each phase an instance of this base class is to be used to store crystallographic and simulation-relevant data. - + Indexing is a data processing step performed after/during the beam scans the specimen (depends on configuration). Users load the specimen, and first collect a coarse image of the surface. Next, an approximate value for the @@ -415,19 +414,19 @@ NXem_ebsd: and aberration settings and select one or multiple ROIs to machine off. The on-the-fly indexing parameter are defined and usually the automated measurement queue started. - + Nowadays, this is usually an automated/unsupervised process. The pattern collection runs during the allocated session time slot which the user has booked ends or when the queue finishes prematurely. Kikuchi pattern surplus eventually multi-modal detector signals are collected and usually indexed on-the-fly. The Kikuchi patterns may or not be deleted directly after a solution was found (on-the-fly) so Kikuchi pattern are not always stored. - + Results files are in many labs afterwards copied automatically for archival purposes to certain storage locations. The result of such an EBSD measurement/experiment is a set of usually proprietary or open files from technology partners (microscope and EBSD detector manufacturers). - + In the second case, the system is being calibrated during the session using standards (silicon, quartz, or other common specimens). There is usually one person in each lab responsible for doing such @@ -442,7 +441,7 @@ NXem_ebsd: from the data so it remains the users personal obligation to remember these settings, write them down in the lab notebook, or these metadata get lost. All these issues are a motivation and problem which NXem_ebsd solves. - sequence_index(NX_POSINT): # 1 + sequence_index(NX_POSINT): # 1 origin: doc: | A link/cross reference to an existent instance of NXem_ebsd with ideally @@ -457,24 +456,24 @@ NXem_ebsd: when performing the calibration. acquisition(NXprocess): - exists: recommended # the measurement should be required unless the + exists: recommended # the measurement should be required unless the # data come from e.g. a Kikuchi pattern simulation! doc: | Relevant result of the session at the microscope for this experiment which enables to connect the measurement of the Kikuchi pattern and their processing into orientation microscopy maps. - sequence_index(NX_POSINT): # 2 + sequence_index(NX_POSINT): # 2 origin: doc: | Name or link to an existent instance of an EBSD raw dataset ideally as an instance of an NXem application definition which has at least one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. The path to this instance in the origin has to be specified under path. - + When NXem is not used or the aim is to rather explore first how community-specific files with EBSD data, such as ANG, CPR, or HDF5- based formats can be parsed from, inject here the name of that file. - + The em_om parser will currently not interpret the majority of the many system- and technique-specific metadata which come with the files from e.g. technology partners. This is because the current @@ -483,7 +482,7 @@ NXem_ebsd: vocabulary although many people understand terms from different implementations and how these metadata can likely be compared to one another. - + In addition, it is common practice in the research field of EBSD that users transcode their raw data into other (often text-based or HDF5) files with custom formatting to realize an information transfer @@ -512,26 +511,26 @@ NXem_ebsd: # base class for indexing methods with relevant vocabulary indexing(NXprocess): - exists: recommended # making it recommended makes not much sense as then we will not have + exists: recommended # making it recommended makes not much sense as then we will not have # IPF default plots in this case we need to use simulated Kikuchi pattern as a fallback doc: | OIM, orientation imaging microscopy. Post-processing of the Kikuchi patterns to obtain orientation per phase model and scan point. Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing + + Common is that pattern indexing is a computational step of comparing simulated with measured diffraction pattern. Quality descriptors are defined based on which an indexing algorithm yields a quantitative measure of how similar measured and assumed/simulated pattern are, and thus if no, one, or multiple so-called solutions were found. - + Assumed or simulated pattern use kinematical or dynamical electron diffraction theory. Hough transform (which is essentially a discretized Radon transform, for details see e.g A short introduction to the Radon and Hough transforms and how they relate by M. van Ginkel et al.). Recently, dictionary-based indexing methods are increasingly becoming used partly driven by the move to use artificial intelligence algorithms. - + An inspection of publicly available EBSD datasets with an open-source license which are available on Zenodo was performed prior to implementing of the associated em_om parser for NXem_ebsd. This analysis revealed that @@ -539,29 +538,29 @@ NXem_ebsd: formats from technology partners. Examples are binary formats like OSC, H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - + These files contain some result and metadata to the numerical steps and the computational workflow which was performed to index Kikuchi pattern on-the-fly. Examples of metadata include scan point positions, indexing solutions per scan point, some quality descriptors for the solutions, as well as crystal structure and phase metadata. - + Case two were raw pattern in some custom format, often text-based with some but in general no conclusive and interoperable representation of all relevant metadata. - Often it remains unclear what individual fields and data arrays of these + Often it remains unclear what individual fields and data arrays of these fields resolve and/or mean conceptually. For some fields, publications were referred to. However, software tools change over time and thus which specific data end in a file and which specific conceptual information is behind these data can change with software versions. - + Other cases were storing results of custom post-processing steps and associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry resolving methods, i.e. any sort of prototyping or alternative indexing strategies so far seem to require some flexibility for implementing rapid prototypic capabilities. The drawback of this is that such results come formatted on a case-by-case basis and are thus not interoperable. - + Therefore, we first need to collect how these files have been generated and which metadata in these files (or database entries) represent which pieces of information conceptually. Ideally, one would do so by @@ -570,11 +569,11 @@ NXem_ebsd: Eventually even interactions with the graphical user interface of commercial software during the microscope session should be stored and become a part of the application definition. - + Such a set of pieces of information could then be used via reading directly for the NXem application definition. However, in most cases such a data representation is not available yet. - sequence_index(NX_POSINT): # 3 + sequence_index(NX_POSINT): # 3 on_the_fly_indexing(NXprocess): exists: optional doc: | @@ -612,7 +611,13 @@ NXem_ebsd: method: doc: | Principal algorithm used for indexing. - enumeration: [undefined, hough_transform, dictionary, radon_transform, other] # emsoft, astro, mtex + enumeration: [ + undefined, + hough_transform, + dictionary, + radon_transform, + other, + ] # emsoft, astro, mtex background_correction(NXprocess): exists: optional doc: | @@ -627,7 +632,7 @@ NXem_ebsd: # pattern from scan points and neighboring scan points are spatially # averaged (using weighting schemes and e.g. kernels) before these # patterns are passed to the indexing algorithm. - binning(NXprocess): # NEW ISSUE: binning replace by NXgrid + binning(NXprocess): # NEW ISSUE: binning replace by NXgrid exists: optional doc: | Binning i.e. downsampling of the pattern. @@ -652,7 +657,7 @@ NXem_ebsd: # mode: # doc: Which method used to index pattern? # enumeration: [optimize_bd] # what does optimize_bd mean Oxford? - (NXem_ebsd_crystal_structure_model): # phaseID(NXem_ebsd_crystal_structure_model) + (NXem_ebsd_crystal_structure_model): # phaseID(NXem_ebsd_crystal_structure_model) exists: [min, 1, max, infty] crystallographic_database_identifier: exists: recommended @@ -704,12 +709,12 @@ NXem_ebsd: doc: | Which return value did the indexing algorithm yield for each scan point. Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors # data(NX_UINT): # doc: | # Status value of each pixel of the orientation mapping. @@ -731,11 +736,11 @@ NXem_ebsd: should be used: In the simplest case users collected one pattern for each scan point and have indexed using one phase, i.e. one instance of an NXem_ebsd_crystal_structure_model. - + In another example users may have skipped some scan points (not indexed) them at all) and/or used differing numbers of phases for different scan points. - + The cumulated of this array decodes how phase_identifier and phase_matching arrays have to be interpreted. In the simplest case (one pattern per scan point, and all scan points indexed using that same single phase model), @@ -750,11 +755,11 @@ NXem_ebsd: doc: | The array n_phases_per_scan_point details how the phase_identifier and the phase_matching arrays have to be interpreted. - + For the example with a single phase phase_identifier has trivial values either 0 (no solution) or 1 (solution matching sufficiently significant with the model for phase 1). - + When there are multiple phases, it is possible (although not frequently needed) that a pattern matches eventually (not equally well) sufficiently significant with multiple pattern. This can especially happen in cases of @@ -764,7 +769,7 @@ NXem_ebsd: or dictionary based indexing schemes because in combination with phase_matching these fields communicate the results in a model-agnostic way. - + Depending on the n_phases_per_scan_point value phase_identifier and phase_matching arrays represent a collection of concatenated tuples, which are organized in sequence: The solutions for the 0-th scan point, @@ -773,7 +778,7 @@ NXem_ebsd: unit: NX_UNITLESS dimensions: rank: 1 - dim: [[1, i]] # with i = sum of n_phases_per_scan_point + dim: [[1, i]] # with i = sum of n_phases_per_scan_point phase_matching(NX_NUMBER): exists: recommended doc: | @@ -784,7 +789,7 @@ NXem_ebsd: unit: NX_UNITLESS dimensions: rank: 1 - dim: [[1, i]] # with i = sum of n_phases_per_scan_point + dim: [[1, i]] # with i = sum of n_phases_per_scan_point phase_matching_descriptor: exists: recommended doc: | @@ -793,7 +798,7 @@ NXem_ebsd: some AI-based matching probability (other), i.e. the details are implementation-specific. enumeration: [undefined, ci, mad, other] orientation_parameterization: - exists: recommended # required when orientation exists + exists: recommended # required when orientation exists doc: | How are orientations parameterized? Inspect euler_angle_convention in case of using euler to clarify the sequence of rotations assumed. @@ -801,11 +806,11 @@ NXem_ebsd: orientation(NX_NUMBER): exists: recommended doc: | - Matrix of parameterized orientations identified. The slow dimension + Matrix of parameterized orientations identified. The slow dimension iterates of the individual solutions as defined by n_phases_per_scan_point. Values for phases without a solution should be correctly identified as IEEE NaN. - unit: NX_ANY # because differs for different parameterizations + unit: NX_ANY # because differs for different parameterizations dimensions: rank: 2 dim: [[1, i], [2, n_op]] @@ -836,7 +841,7 @@ NXem_ebsd: unit: NX_DIMENSIONLESS # candidate for default plot - region_of_interest(NXprocess): # conceptually this a virtual detector + region_of_interest(NXprocess): # conceptually this a virtual detector exists: [min, 1, max, 1] doc: | An overview of the entire area which was scanned. @@ -846,7 +851,8 @@ NXem_ebsd: doc: | Descriptor representing the image contrast. # taking two examples (CTF and H5OINA choked completely of possibility to find s.th. conceptually common to plot - enumeration: ["normalized_band_contrast", "normalized_confidence_index"] + enumeration: + ["normalized_band_contrast", "normalized_confidence_index"] roi(NXdata): doc: | Container holding a default plot of the region on the sample @@ -875,7 +881,7 @@ NXem_ebsd: axis_y(NX_NUMBER): doc: | Calibrated center of mass of the pixel along the slow axis. - unit: NX_LENGTH # pixel coordinates + unit: NX_LENGTH # pixel coordinates dimensions: rank: 1 dim: [[1, n_y]] @@ -891,23 +897,23 @@ NXem_ebsd: \@long_name: doc: Label for the x axis - (NXprocess): # ipf_mapID(NXprocess): - exists: [min, 0, max, infty] # should be as many as crystal structure models + (NXprocess): # ipf_mapID(NXprocess): + exists: [min, 0, max, infty] # should be as many as crystal structure models doc: | Default inverse pole figure (IPF) plot of the data specific for each phase. No ipf_mapID instances for non-indexed scan points as these are by definition assigned the null phase with phase_identifier 0. - + The IPF mapping is interpolated from the scan point data mapping onto a rectangular domain with square pixels and the orientations colored according to the coloring scheme used in the respective ipf_color_modelID/program. - + The main purpose of the ipf_mapID group is not to keep raw data or scan point related data but offer a default way how a research data management system can display a preview of the dataset so that users working with the RDMS can get an overview of the dataset. - + This matches the first aim of NXem_ebsd which is foremost to bring colleagues and users of EBSD together to discuss which pieces of information need to be stored together. We are convinced a step-by-step design and @@ -916,14 +922,14 @@ NXem_ebsd: interoperable description and data model for exchanging data from EBSD between different tools and research data management systems (RDMS). - + With this design the individual RDMS solutions and tools can still continue to support specific custom data analyses workflow and routes but at least there is then one common notation of understanding whereby also users not necessarily expert in all the details of the EBSD story can understand better these data and thus eventually this can motivate data reuse and repurposing. - + It is important to mention that we cannot assume, at least for now, that the parser which writes to an NXem_ebsd-compliant file is also responsible or capable at all of computing the inverse pole figure @@ -931,28 +937,28 @@ NXem_ebsd: this mapping of orientation data uses involved mathematical algorithms and functions which not every tools used in the EBSD community is capable of using or is for sure not using in exactly the same way. - + Currently, we assume it is the responsibilty of the tool used which generated the data under on_the_fly_indexing to compute these plots and deliver these to the parser. - + Specific case studies have been explored by the experiment team of Area B of the FAIRmat project to realize and implement such mapping. - + The first case study uses the H5OINA format and the pyxem/orix library. As orix is a Python library, the coloring is performed by the em_om parser. - + The second case study uses MTex and its EBSD color coding model. As MTex is a Matlab tool, an intermediate format is written from MTex first which stores these pieces of information. The parser then pulls these data from the intermediate Matlab-agnostic representation and supplements the file with missing pieces of information as it is required by NXem_ebsd. - + The third case study shows how a generic set of Kikuchi pattern can be loaded with the em_om parser. The pattern are loaded directly from a ZIP file and mapped to an simulation image section for now. - + The fourth case study uses the DREAM.3D package which provides an own set of EBSD data post-processing procedures. DREAM.3D documents the processing steps with a pipeline file which is stored inside DREAM.3D @@ -962,7 +968,7 @@ NXem_ebsd: Given that in this case the origin of the data is the DREAM.3D file again provenance is kept and more details can be followed upon when resolving origin. - + These examples offer a first set of suggestions on how to make EBSD data injectable into research data management system using schemes which themselves are agnostic to the specific RDMS and interoperable. @@ -978,12 +984,12 @@ NXem_ebsd: is that the conventions and reference frame definitions are expected in an ELN-agnostic representation to make NXem_ebsd a generally useful data scheme for EBSD. - + Ideally, the em_om parser would load convention-compliant EBSD data and use subsequently a community library to transcode/convert orientation conventions and parameterized orientation values. Thereafter, convention- compliant default plot(s) could be created that would be truely interoperable. - + However, given the variety of post-processing tools available surplus the fact that these are not usually executed along standardized post-processing workflows which perform exactly the same algorithmic steps, @@ -991,48 +997,48 @@ NXem_ebsd: developers who wish to implement this would first have to create a library for performing such tasks, mapping generally between conventions, i.e. map and rotate coordinate systems at the parser level. - + The unfortunate situation in EBSD is that due to historical reasons and competitive strategies, different players in the field have implemented (slightly) different approaches each of which misses some part of a complete workflow description which is behind EBSD analyses: Sample preparation, measurement, indexing, post-processing, paper... - + The here exemplified default plot do not so far apply relevant rotations but takes the orientation values as they come from the origin and using coloring them as they come. It is thus the scientists responsibility to enter and check if the respective dataset is rotation-conventions-wise consistent and fit for a particular task. - + Ideally, with all conventions defined it can be possible to develop a converter which rotates the input data. This application definition does not assume this and users should be aware of this limitation. - + The key point is that the conventions however are captured and this is the most important step to the development of such a generic transcoder for creating interoperable EBSD datasets. - + Currently the conventions remain in the mind or manual lab book of the respective scientists or technicians instead of getting stored and communicated with research papers that are written based on specific dataset, i.e. database entries. - + The default gridded representation of the data should not be misinterpreted as the only possible way how EBSD data and OIM maps can be created! - + Indeed, the most general case is that patterns are collected for scan points. The scan generator of an electron microscope is instructed to steer the beam in such a way across the specimen surface that the beam illuminates certain positions for a certain amount time (usually equally-spaced and spending about the same amount of time at each position). - + Therefore, scan positions can be due to such regular flight plans and represent sampling on lines, line stacks, rectangular regions-of- interests, but also could instruct spiral, random, or adaptive scans instead of tessellations with square or hexagonal pixels. - + The majority of EBSD maps is though is reporting results for a regular grid (square, hexagon). What matters though in terms of damage induced by the electron beam and signal quality is the real electron dose @@ -1041,11 +1047,11 @@ NXem_ebsd: amount of charge accumulates due to e.g. poor conducting away of this charge or an improper mounting, too high dose, etc. such details are relevant. - + Specifically, the default visualization is an inverse pole-figure (IPF) map with the usual RGB color coding. Different strategies and normalization schemes are in use to define such color coding. - + Finally, we should mention that each ipf_map represents data for scan points indexed as one phase. The alias/name of this phase should be stored in phase_name, the phase_identifier give an ID which must @@ -1060,7 +1066,7 @@ NXem_ebsd: Alias/name for the phase whose indexed scan points are displayed. description: exists: optional - doc: | + doc: | Which IPF definition computation according to backend. # AS THE FIRST STEP WE DO NOT IMPLEMENT A GENERIC ORIENTATION AND REFERENCE # FRAME LIBRARY WHICH CAN TRANSLATE BETWEEN ALL POSSIBLE CONVENTIONS. @@ -1139,7 +1145,7 @@ NXem_ebsd: Calibrated center of mass of the pixel along the fast axis. dimensions: rank: 1 - dim: [[1, n_x]] # but for h5web RGB we need n_x + 1 + dim: [[1, n_x]] # but for h5web RGB we need n_x + 1 \@long_name: doc: Label for the x axis @@ -1153,10 +1159,10 @@ NXem_ebsd: scaling relations. Differences are which base colors of the RGB color model are placed in which extremal position of the SST and where the white point is located. For further details see: - + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) * Srikanth Patala and coworkers"'" work and of others. - + Details are implementation-specific and not standardized yet. Given that the SST has a complicated geometry, it cannot yet be visualized using tools like H5Web, which is why for now the em_om @@ -1188,7 +1194,7 @@ NXem_ebsd: axis_y(NX_NUMBER): doc: | Pixel coordinate along the slow axis. - unit: NX_ANY # pixel coordinates + unit: NX_ANY # pixel coordinates dimensions: rank: 1 dim: [[1, n_y]] @@ -1197,25 +1203,20 @@ NXem_ebsd: axis_x(NX_NUMBER): doc: | Pixel coordinate along the fast axis. - unit: NX_ANY # pixel coordinates + unit: NX_ANY # pixel coordinates dimensions: rank: 1 dim: [[1, n_x]] \@long_name: doc: Label for the x axis - - - - - correlation(NXprocess): - exists: optional # making it recommended makes not much sense as then we will not have + exists: optional # making it recommended makes not much sense as then we will not have doc: | This application definition also enables to describe a workflow where several EBSD datasets are not only documented but also correlated based on time, position (spatial), or both (spatiotemporal). - + Spatial correlations between repetitively characterized regions-of-interests are typically correlated using image registration and alignment algorithms. For this typically so-called landmarks are used. These can be grains with @@ -1224,7 +1225,7 @@ NXem_ebsd: one another. Other commonly used landmarks are fiducial marks which are milled into the specimen surface using focus-ion beam milling and/or various types of indentation methods. - + As far as the same physical region-of-interest is just measured several times, the additional issue of the depth increment is not a concern. However, correct assumptions for the depth increment, amount of material removed along the milling @@ -1233,14 +1234,14 @@ NXem_ebsd: useful depth increments. Different strategies have been proposed like calibrations, wedged-shaped landmarks and computer simulation assisted assumption making. - + Despite the use of landmarks, there are many practical issues which make the processing of correlations imprecise and inaccurate. Among these are drift and shift of the specimen, instabilities of the holder, the beam, irrespective of the source of the drift, charging effects, here specifically causing local image distortions and rotations which may require special processing algorithms to reduce such imprecisions. - + Time correlations face all of the above-mentioned issues surplus the challenge that specific experimental protocols have to be used to ensure the material state is observed at specific physical time. The example of quasi in-situ characterization @@ -1250,19 +1251,19 @@ NXem_ebsd: that transient effects take place. Heating or quenching a sample might thus might not have been executed under conditions in the interaction volume as they are documented and/or assumed. - + These issue cause that correlations have an error margin as to how accurately respective datasets were not only just synced based on the geometry of the region-of-interests and the time markers but also to asssure which physical conditions the specimen experienced over the course of the measurements. - + The fourth example of the em_om reference implementation explores the use of the correlation group with a serial-sectioning datasets that was collected by the classical Inconel 100 dataset collected by M. D. Uchic and colleagues (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and characterization of polycrystalline microstructures using a fib-sem system data set. Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - + This dataset was specifically relevant in driving forward the implementation of the DREAM.3D software. DREAM.3D is an open-source software project for post-processing and reconstructing, i.e. correlating sets of orientation @@ -1270,7 +1271,7 @@ NXem_ebsd: (post-)processing of EBSD datasets. Another cutting edge tool with similar scope but a commercial solution by Bruker is QUBE which was developed by P. Konijnenberg and coworkers. - + Conceptually, software like DREAM.3D supports users with creating linear workflows of post-processing tasks. Workflows can be instructed via the graphical user interface or via so-called pipeline processing via command line @@ -1282,7 +1283,7 @@ NXem_ebsd: inside a supplementary JSON file or alongside the data in the DREAM3D file. DREAM.3D has a few hundred algorithms implemented. These are called filters in DREAM.3D terminology. - + Users configure a workflow which instructs DREAM.3D to send the data through a chain of predefined and configured filters. Given that for each analysis the filter is documented via its version tags surplus its parameter and setting @@ -1292,17 +1293,17 @@ NXem_ebsd: the initial set of input data come from commercial files like ANG. This missing link between the provenance of these input files, their associated creation as electron microscope session, is also what NXem_ebsd solves. - + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that the DREAM.3D and the em_om parser can work productively together to realize RDMS-agnostic parsing of serial-section analyses. - + The internal documentation of the DREAM.3D workflow also simplifies the provenance tracking represented by an instance of NXem_ebsd as not every intermediate results has to be stored. Therefore, the fourth example focuses on the key result obtained from DREAM.3D - the reconstructed and aligned three-dimensional orientation map. - + Usually, this result is the starting point for further post-processing and characterization of structural features. As here orientation microscopy is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should @@ -1310,7 +1311,7 @@ NXem_ebsd: Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) or open-source implementations of these techniques (such as via pyxem/orix). - + The result of orientation microscopy methods are maps of local orientation and thermodynamic phase (crystal structure) pieces of information. Virtually all post-processing of such results for structural features includes again @@ -1324,9 +1325,9 @@ NXem_ebsd: # NEW ISSUE: how to handle landmarks # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid # image registration etc. - sequence_index(NX_POSINT): # 4 + sequence_index(NX_POSINT): # 4 - (NXem_ebsd_crystal_structure_model): # phaseID(NXem_ebsd_crystal_structure_model) + (NXem_ebsd_crystal_structure_model): # phaseID(NXem_ebsd_crystal_structure_model) exists: [min, 1, max, infty] crystallographic_database_identifier: exists: recommended @@ -1341,7 +1342,7 @@ NXem_ebsd: exists: recommended # candidate for default plot - region_of_interest(NXprocess): # conceptually this a virtual detector + region_of_interest(NXprocess): # conceptually this a virtual detector exists: [min, 1, max, 1] doc: | An overview of the entire reconstructed volume. For details about @@ -1378,7 +1379,7 @@ NXem_ebsd: axis_z(NX_NUMBER): doc: | Calibrated center of mass of the pixel along the slow axis. - unit: NX_LENGTH # pixel coordinates + unit: NX_LENGTH # pixel coordinates dimensions: rank: 1 dim: [[1, n_z]] @@ -1387,7 +1388,7 @@ NXem_ebsd: axis_y(NX_NUMBER): doc: | Calibrated center of mass of the pixel along the fast axis. - unit: NX_LENGTH # pixel coordinates + unit: NX_LENGTH # pixel coordinates dimensions: rank: 1 dim: [[1, n_y]] @@ -1403,8 +1404,8 @@ NXem_ebsd: \@long_name: doc: Label for the x axis - (NXprocess): # ipf_mapID(NXprocess): - exists: [min, 0, max, infty] # should be as many as crystal structure models + (NXprocess): # ipf_mapID(NXprocess): + exists: [min, 0, max, infty] # should be as many as crystal structure models doc: | Default inverse pole figure (IPF) plot of the data specific for each phase. No ipf_mapID instances for non-indexed scan points as these are @@ -1419,7 +1420,7 @@ NXem_ebsd: Alias/name for the phase whose indexed scan points are displayed. description: exists: optional - doc: | + doc: | Which IPF definition computation according to backend. projection_direction(NX_NUMBER): doc: | @@ -1443,7 +1444,7 @@ NXem_ebsd: Consider the explanations in the docstring of the ipf_mapID group. program_name: \@version: - + # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] ipf_rgb_map(NXdata): @@ -1499,7 +1500,7 @@ NXem_ebsd: Calibrated center of mass of the pixel along the fastest axis. dimensions: rank: 1 - dim: [[1, n_x]] # but for h5web RGB we need n_x + 1 + dim: [[1, n_x]] # but for h5web RGB we need n_x + 1 \@long_name: doc: Label for the x axis @@ -1532,7 +1533,7 @@ NXem_ebsd: axis_y(NX_NUMBER): doc: | Pixel coordinate along the slow axis. - unit: NX_ANY # pixel coordinates + unit: NX_ANY # pixel coordinates dimensions: rank: 1 dim: [[1, n_y]] @@ -1541,7 +1542,7 @@ NXem_ebsd: axis_x(NX_NUMBER): doc: | Pixel coordinate along the fast axis. - unit: NX_ANY # pixel coordinates + unit: NX_ANY # pixel coordinates dimensions: rank: 1 dim: [[1, n_x]] @@ -1557,10 +1558,10 @@ NXem_ebsd: # phase_identifier or a status marker stating that no solution was found # (NXsst_color_model): ##MK # doc: | - # For each stereographic standard triangle, (fundamental zone) of + # For each stereographic standard triangle, (fundamental zone) of # the orientation space, it is possible to define a color model which # associates an orientation in the fundamental zone to a color. - # + # # For details see: # * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) # * Srikanth Patala and coworkers"'" work and of others. @@ -1576,7 +1577,7 @@ NXem_ebsd: # rgb(NX_NUMBER): # dimensions: [[1, n_points], [2, 3]] # mapping(NX_NUMBER): - # doc: | + # doc: | # The EBSD mapping with colors outlined # unit: NX_UNITLESS # dimensions: [[1, n_y], [2, n_x], [3, 3]] @@ -1663,28 +1664,27 @@ NXem_ebsd: # doc: | # TBD Oxford/HKL Channel 5 CPR files # unit: NX_DIMENSIONLESS - # how to parameterize a group with value, and descriptor type or a - # field with descriptor type as attribute? - # pattern_quality(NXprocess): - # value(NX_NUMBER): - # doc: | - # Pattern quality descriptor - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # model: - # doc: | - # Model used to describe some aspect of the pattern. - # enumeration: [band_contrast, mean_angular_deviation] - + # how to parameterize a group with value, and descriptor type or a + # field with descriptor type as attribute? + # pattern_quality(NXprocess): + # value(NX_NUMBER): + # doc: | + # Pattern quality descriptor + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # model: + # doc: | + # Model used to describe some aspect of the pattern. + # enumeration: [band_contrast, mean_angular_deviation] # tilt_angle(NX_FLOAT): # maybe better make this integrated into the NXtransformations of the stage_lab, a stage_lab event? # beam_position(NXcg_point_set): # (NXdetector): # exposure_time(NX_FLOAT): # unit: NX_TIME -# gain(NX_FLOAT): +# gain(NX_FLOAT): # ##MK how does a gain translate mathematically an input signal into an intensity signal? # insertion_distance(NX_FLOAT): # unit: NX_LENGTH From 793baee7da5ebf78f3626348f896bcb3cadc6a66 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Sat, 22 Apr 2023 21:33:00 +0200 Subject: [PATCH 124/203] Refactoring and fixing of base classes and application definitions for sprint14, pre1 for apm, em, and classes which can be useful for our colleagues in the NFDI-MatWerk consortium --- .../nyaml/NXaberration.yaml | 84 +- .../nyaml/NXaberration_model.yaml | 66 + .../nyaml/NXaberration_model_ceos.yaml | 70 + .../nyaml/NXaberration_model_nion.yaml | 38 + contributed_definitions/nyaml/NXapm.yaml | 519 ++--- .../NXapm_paraprobe_config_clusterer.yaml | 11 +- .../NXapm_paraprobe_config_distancer.yaml | 1 - .../NXapm_paraprobe_config_intersector.yaml | 25 +- .../NXapm_paraprobe_config_nanochem.yaml | 50 +- .../nyaml/NXapm_paraprobe_config_ranger.yaml | 13 +- .../NXapm_paraprobe_config_selector.yaml | 1 - .../NXapm_paraprobe_config_spatstat.yaml | 402 ++-- .../NXapm_paraprobe_config_surfacer.yaml | 5 +- .../NXapm_paraprobe_config_tessellator.yaml | 14 +- .../NXapm_paraprobe_config_transcoder.yaml | 1 - .../NXapm_paraprobe_results_clusterer.yaml | 8 +- .../NXapm_paraprobe_results_distancer.yaml | 6 +- .../NXapm_paraprobe_results_intersector.yaml | 13 +- .../NXapm_paraprobe_results_nanochem.yaml | 77 +- .../nyaml/NXapm_paraprobe_results_ranger.yaml | 37 +- .../NXapm_paraprobe_results_selector.yaml | 3 +- .../NXapm_paraprobe_results_spatstat.yaml | 19 +- .../NXapm_paraprobe_results_surfacer.yaml | 12 +- .../NXapm_paraprobe_results_tessellator.yaml | 17 +- .../NXapm_paraprobe_results_transcoder.yaml | 72 +- contributed_definitions/nyaml/NXcg_grid.yaml | 13 +- .../nyaml/NXcg_half_edge_data_structure.yaml | 2 +- .../nyaml/NXcg_polyline_set.yaml | 2 +- .../nyaml/NXchemical_composition.yaml | 2 +- .../nyaml/NXclustering.yaml | 4 +- .../nyaml/NXcorrector_cs.yaml | 43 +- .../nyaml/NXcs_profiling.yaml | 2 +- .../nyaml/NXebeam_column.yaml | 2 +- contributed_definitions/nyaml/NXem.yaml | 1763 ++++++++++++++--- .../nyaml/NXevent_data_em.yaml | 143 +- .../nyaml/NXgraph_edge_set.yaml | 4 +- .../nyaml/NXgraph_node_set.yaml | 4 +- .../nyaml/NXibeam_column.yaml | 2 +- .../nyaml/NXimage_set.yaml | 60 + contributed_definitions/nyaml/NXion.yaml | 52 +- contributed_definitions/nyaml/NXiv_temp.yaml | 2 +- ..._electro_chemo_mechanical_preparation.yaml | 4 +- contributed_definitions/nyaml/NXlens_em.yaml | 2 +- contributed_definitions/nyaml/NXms.yaml | 148 +- .../nyaml/NXms_feature_set.yaml | 233 +++ .../nyaml/NXms_score_config.yaml | 36 +- .../nyaml/NXms_score_results.yaml | 76 +- .../nyaml/NXoptical_system_em.yaml | 2 +- .../nyaml/NXorientation_set.yaml | 4 +- contributed_definitions/nyaml/NXprogram.yaml | 10 +- .../nyaml/NXpulser_apm.yaml | 33 +- .../nyaml/NXreflectron.yaml | 4 + .../nyaml/NXsimilarity_grouping.yaml | 2 +- .../nyaml/NXspectrum_set.yaml | 91 + manual/source/apm-structure.rst | 7 +- manual/source/cgms-structure.rst | 18 +- manual/source/em-structure.rst | 25 +- manual/source/index.rst | 2 + manual/source/north-structure.rst | 31 +- manual/source/stm-structure.rst | 32 + 60 files changed, 3168 insertions(+), 1256 deletions(-) create mode 100644 contributed_definitions/nyaml/NXaberration_model.yaml create mode 100644 contributed_definitions/nyaml/NXaberration_model_ceos.yaml create mode 100644 contributed_definitions/nyaml/NXaberration_model_nion.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_feature_set.yaml create mode 100644 contributed_definitions/nyaml/NXspectrum_set.yaml create mode 100644 manual/source/stm-structure.rst diff --git a/contributed_definitions/nyaml/NXaberration.yaml b/contributed_definitions/nyaml/NXaberration.yaml index f20e29c778..69f2717ef9 100644 --- a/contributed_definitions/nyaml/NXaberration.yaml +++ b/contributed_definitions/nyaml/NXaberration.yaml @@ -1,65 +1,29 @@ category: base doc: | - Models for aberrations of electro-magnetic lenses in electron microscopy. - - The notation follows `O. Krivanek et al. (1999) `_ - and `O. Krivanek et al. (2003) `_ - See also `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) - for further details, additional literature, and the unit of the coefficients. - Consult Table 7-2 of Ibid. publication on how to convert between - conventions of different groups/vendors. + Quantified aberration coefficient in an aberration_model. type: group (NXobject)NXaberration: - c_1_0(NX_FLOAT): - unit: NX_LENGTH - doc: | - Defocus - c_1_2_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Two-fold astigmatism - c_1_2_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Two-fold astigmatism - c_2_1_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Second-order axial coma - c_2_1_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Second-order axial coma - c_2_3_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threefold astigmatism - c_2_3_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threefold astigmatism - c_3_0(NX_FLOAT): - unit: NX_LENGTH - doc: | - Spherical aberration - c_3_2_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Star aberration - c_3_2_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Star aberration - c_3_4_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Fourfold astigmatism - c_3_4_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Fourfold astigmatism - c_5_0(NX_FLOAT): - unit: NX_LENGTH - doc: | - Fifth-order spherical aberration + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + doc: | + Confidence + unit: NX_LENGTH + uncertainty_model: + doc: | + How was the uncertainty quantified e.g. via the 95% confidence interval. + delta_time(NX_FLOAT): + doc: | + Time elapsed since the last measurement. + unit: NX_TIME + angle(NX_FLOAT): + doc: | + For the CEOS definitions the C aberrations are radial-symmetric and have no + angle entry, while the A, B, D, S, or R aberrations are n-fold + symmetric and have an angle entry. + For the NION definitions the coordinate system differs to the one + used in CEOS and instead two aberration coefficients a and b are used. + unit: NX_ANGLE + name: + alias: \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXaberration_model.yaml b/contributed_definitions/nyaml/NXaberration_model.yaml new file mode 100644 index 0000000000..3cbd599f2d --- /dev/null +++ b/contributed_definitions/nyaml/NXaberration_model.yaml @@ -0,0 +1,66 @@ +category: base +doc: | + Models for aberrations of electro-magnetic lenses in electron microscopy. + + See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. +type: group +(NXobject)NXaberration_model: + model: + enumeration: [ceos, nion] + (NXaberration): + + c_1_0(NX_FLOAT): + unit: NX_LENGTH + doc: | + Defocus + c_1_2_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Two-fold astigmatism + c_1_2_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Two-fold astigmatism + c_2_1_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Second-order axial coma + c_2_1_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Second-order axial coma + c_2_3_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Threefold astigmatism + c_2_3_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Threefold astigmatism + c_3_0(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spherical aberration + c_3_2_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Star aberration + c_3_2_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Star aberration + c_3_4_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Fourfold astigmatism + c_3_4_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Fourfold astigmatism + c_5_0(NX_FLOAT): + unit: NX_LENGTH + doc: | + Fifth-order spherical aberration diff --git a/contributed_definitions/nyaml/NXaberration_model_ceos.yaml b/contributed_definitions/nyaml/NXaberration_model_ceos.yaml new file mode 100644 index 0000000000..c89b0d0d7f --- /dev/null +++ b/contributed_definitions/nyaml/NXaberration_model_ceos.yaml @@ -0,0 +1,70 @@ +category: base +doc: | + CEOS definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + +type: group +(NXobject)NXaberration_model_ceos: + model: + enumeration: [ceos] + c_1(NXaberration): # Defocus + a_1(NXaberration): # Two-fold astigmatism + b_2(NXaberration): # Second-order axial coma + a_2(NXaberration): # Threefold astigmatism + c_3(NXaberration): # Spherical aberration + s_3(NXaberration): # Star aberration + a_3(NXaberration): # Fourfold astigmatism + # based on feedback from Thilo Remmele the following aberrations could be measured (enhanced mode, tilt angle > 30 mrad) but are not corrected + b_4(NXaberration): # Fourth-order axial coma + d_4(NXaberration): # Three-lobe aberration + a_4(NXaberration): # Fivefold astigmatism + c_5(NXaberration): # Fifth-order spherical aberration + s_5(NXaberration): # Fifth-order star aberration + r_5(NXaberration): # Rosette aberration + a_6(NXaberration): # Sixfold astigmatism + +# further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) +# ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes +# Aberration naming schema: C_order_multiplicity (similar to NXem, but with +# another coordinate system and in addition with a confidence entry. +# Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) +# contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space +# aberration function: +# Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] +# +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) +# +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] +# +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f + +# Thilo Remmele also mentions that there is a mapping of aberration coefficient names: +# C_2_0 -> C1 Defocus +# C_2_2 -> A1 2-fold astigmatism +# C_3_3 -> A2 3-fold astigmatism +# C_3_1 -> B2 axial coma +# C_4_0 -> C3 spherical aberration +# C_4_4 -> A3 4-fold astigmatism +# C_4_2 -> S3 star aberration +# C_5_5 -> A4 5-fold astigmatism + +# C_5_1 -> B4 axial coma +# C_5_3 -> D4 three lobe aberration +# C_6_0 -> C5 spherical aberration +# C_6_2 -> S5 star aberration +# C_6_4 -> R5 rosette aberration +# C_6_6 -> A5 6-fold astigmatism + +# In a session with HRTEM images the corrector is commonly aligned. +# The final measurement with the estimated residual aberrations +# should be saved in a corrector.html file (an example is appended +# at the end of this file. Unfortunately the datetime is not included +# in that html output, nor is the used outer tilt angle and exposure time. +# The datetime may be estimated from the file datetime and the Delta t entry, +# but caution if that datetime is not preserved on file transfers! +# More than one detector entry could occure but is not common. +# A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. +# It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. +# The corrector entry of the nexus em definition lacks the confidence information and the +# parameter settings for the estimation oft the aberrations. diff --git a/contributed_definitions/nyaml/NXaberration_model_nion.yaml b/contributed_definitions/nyaml/NXaberration_model_nion.yaml new file mode 100644 index 0000000000..832ec9f875 --- /dev/null +++ b/contributed_definitions/nyaml/NXaberration_model_nion.yaml @@ -0,0 +1,38 @@ +category: base +doc: | + NION definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + +type: group +(NXobject)NXaberration_model_nion: + model: + enumeration: [nion] + c_1_0(NXaberration): # Defocus + c_1_2_a(NXaberration): # Two-fold astigmatism + c_1_2_b(NXaberration): # Two-fold astigmatism + c_2_1_a(NXaberration): # Second-order axial coma + c_2_1_b(NXaberration): # Second-order axial coma + c_2_3_a(NXaberration): # Threefold astigmatism + c_2_3_b(NXaberration): # Threefold astigmatism + c_3_0(NXaberration): # Spherical aberration + c_3_2_a(NXaberration): # Star aberration + c_3_2_b(NXaberration): # Star aberration + c_3_4_a(NXaberration): # Fourfold astigmatism + c_3_4_b(NXaberration): # Fourfold astigmatism + c_4_1_a(NXaberration): # Fourth-order axial coma + c_4_1_b(NXaberration): # Fourth-order axial coma + c_4_3_a(NXaberration): # Three-lobe aberration + c_4_3_b(NXaberration): # Three-lobe aberration + c_4_5_a(NXaberration): # Fivefold astigmatism + c_4_5_b(NXaberration): # Fivefold astigmatism + c_5_0(NXaberration): # Fifth-order spherical aberration + c_5_2_a(NXaberration): # Fifth-order star aberration + c_5_2_b(NXaberration): # Fifth-order star aberration + c_5_4_a(NXaberration): # Rosette aberration + c_5_4_b(NXaberration): # Rosette aberration + c_5_6_a(NXaberration): # Sixfold astigmatism + c_5_6_b(NXaberration): # Sixfold astigmatism diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 65433f77a2..8717951b63 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -1,6 +1,62 @@ category: application doc: | Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve this description to cover a substantial larger number of eventually metadata that + so far are neither publicly documented nor accessible. symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. n_ions: Total number of ions collected. @@ -15,6 +71,21 @@ symbols: n_y: Number of bins in the y direction. n_z: Number of bins in the z direction. n_bins: Number of bins. + n_topology: Total number of integers in the supplementary XDMF topology array. +# some consistence is not yet achieved with IFES_APT_TC APT HDF5 v1 format +# Language precision: Keywords such as “must” “required” “should”, etc are as per RFC-2119 [RFC2119]. https://tools.ietf.org/html/rfc2119 +# https://gitlab.com/apt_software_toolbox/apt-hdf5 an implementation for an +# IFES APT TC APT HDF5 v1 verifier +# NEW ISSUE: possible offspring application definitions: +# NXapm_opt/pl would be possible, as soon as NXluminescence by Carola Emminger and Florian Dobner is ready whereby +# then there would be two subentries one for an NXapm and one for NXphotoluminesence to capture the photonic atom probe of Rouen/GPM +# and finally if there were an NXapm_afm for atomic force microscopy the IMEC AFM/APT experiments could be stored with an NXapm_afm application definition +# with NXapm and NXafm being respective subentries of the appdef but as NXapm_afm is a step-by-step approach one would have to release the constraint +# that only a single measurement can be performed. +# NXasat which could just take two subentries NXem and NXapm +# NXasat should be a fuse of NXapm and NXem within an NXentry with NXsubentry, in this way we can combine the strength of both application definitions +# to describe also the upcoming technique of atomic scale analytical tomography https://doi.org/10.1017/9781316677292 + NXapm: (NXentry): exists: [min, 1, max, infty] @@ -69,73 +140,19 @@ NXapm: doc: | ISO 8601 time code with local time zone offset to UTC included when the microscope session ended. - # NEW ISSUE: fields like duration need a clearer description as to how these quantities should be defined. Most atom probers do not care for this other than getting an approximate hour-accurate estimate of the time how long it took to evaporate the specimen. - program: - doc: | - Commercial or otherwise given name to the program which was used - to create the original results file of the atom probe experiment. - This file and program should not be confused with downstream - processing operations and file format conversion tasks. - - Atom probe microscopy experiments are except for still very much cases - controlled via commercial software. Such software is designed as an - integrated acquisition and instrument control software. - - For AMETEK/Cameca local electrode atom probe (LEAP) instruments the - least processed (rawest) numerical results and metadata are stored - in so-called RHIT and HITS files, which are proprietary and the - specifications of which are not publicly documented. - - Supplementary metadata are kept in a database which is connected - to the instrument control software and synced with the experiment - while signal is being detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also to resolve isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - Therefore, this application definition documents not only the measurement - but also the key post-processing steps which transform the proprietary - data into a tomographic reconstruction with ranging definitions. - - Future guidance by the vendors could improve this description to cover - a substantial larger number of eventually metadata that so far - are not publicly documented and accessible in an open-source manner. - \@version: - doc: | - Program 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. + # NEW ISSUE: fields like duration need a clearer description as to how these + # quantities should be defined. Most atom probers do not care for this other + # than getting an approximate hour-accurate estimate of the time how long it + # took to evaporate the specimen. + # several programs and libraries are usually coupled together for LEAP instruments, + # if it is possible to have a different root version with a different ivas/apsuite + # version that having a single program and version field is not enough but multiple + # are required LAS root version camecaroot version analysis software + + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: run_number: doc: | Neither the specimen_name nor the experiment_identifier but the identifier @@ -254,6 +271,10 @@ NXapm: specimen(NXsample): # NEW ISSUE: inject the conclusion from the discussion with Andrea # according to SAMPLE.yaml 0f8df14 2022/06/15 + # NEW ISSUE: addition of a NXfurnace in which one can define the atmosphere + # and partial pressures of the agents in that atmosphere with which the + # sample was annealed at which temperature see the work happening at PNNL + # NEW ISSUE: it would be good to have an application definition NXicp for chemical composition name: doc: | Descriptive name or ideally (globally) unique persistent identifier. @@ -345,11 +366,16 @@ NXapm: In this research field scientists distinguish usually several Euclidean coordinate systems (CS): + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. * The laboratory space; a CS specifying the room where the instrument is located in or a physical landmark on the instrument, e.g. the direction of the transfer rod where positive is the direction how the rod has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. * The specimen space; a CS affixed to either the base or the initial apex of the specimen, whose z axis points towards the detector. @@ -381,6 +407,10 @@ NXapm: the positive z-axes of either coordinate systems is oriented. Consult the work of A. J. Breen and B. Gault and team for further details. + # Spatial transformations are always active transformations; i.e. the location and direction of a vector in one coordinate system is expressed by the following transformation matrix, T Ptransformed = TPoriginal + # add a note about what is the tip space + #Conventions: right-handed, Cartesian, 3D Euclidean CS should be used Laboratory space to be set by This is the space that is set by the chassis of the instrument. The Z direction must be reasonably parallel to gravity (+ve defined to be gravity vector pointing towards lowest ground), but can be defined to be a direction that is nominally parallel to gravity during an experiment. The origin must be placed within a bounding box of the chassis. Tip space instead of specimen space, The space occupied by a tip in the neutral position when ready for analysis. Z+ should be located in the direction of the needle (apex is Z+ from needle centreline). i) If the specimen moves relative to the laboratory frame, and the electrode does not, or if no electrode is present, then the space should be defined such that when the tip is moved physically, it also moves through tip space. ii) If the electrode moves relative to the laboratory frame, then the space should be defined such that, in tip space, the electrode position does not change. + # iii) The transformation between laboratory space and Tip space must be describable by a fixed 3x3 transformation matrix. Detector space: This is a 2D space only, and contains X+ and Y+ directions. X+ and Y+ should indicate primary directions on the detector, and should be, for an equivalent straight-flight-path configuration, such that X+ and Y+ is matched to that of tip space. Laser space missing: Laser space: The coordinate frame describing the impinging wavefront on the sample. Z+ is the vector of the propagating wavefront. X+ is the orthogonal component of the tip direction within the tip-laser plane. The origin shall be placed at the best estimate for tip apex position at the start of the experiment. Reconstruction space : The space occupied by a correctly reconstructed dataset. X+ and Y+ should correspond to X+ and Y+ in the detector space. Z+ should be such that the needle centre line is normal to the detector position. The origin shall be placed at the tip apex. TRANSFORMATIONS(NXtransformations): exists: [min, 0, max, infty] # NEW ISSUE: add Breen's Ultramicroscopy paper on atom probe crystallography @@ -388,6 +418,7 @@ NXapm: (NXmonitor): exists: [min, 0, max, infty] # NEW ISSUE ADD AS MANY MONITORS AS NEEDED, also for pressure etc. + # add a default plot V = f(time/evaporation_id), essentially for each quantity atom_probe(NXinstrument): doc: | Metadata and numerical data of the atom probe and the lab in which it @@ -404,6 +435,8 @@ NXapm: Hence, there is no real probe/beam. * Second, the specimen is the lens of the microscope. + (NXcsg): + exists: optional instrument_name: doc: | Given name of the atom probe at the hosting institution. This is an @@ -432,7 +465,15 @@ NXapm: THIS DOCSTRING NEEDS CLARIFICATION. unit: NX_LENGTH # NEW ISSUE: discussion depends on the type of instrument, - # straight flight path, curved + # straight flight path, curved, there were a few comments to made + # https://fairmat-experimental.github.io/nexus-fairmat-proposal/ + # 50433d9039b3f33299bab338998acb5335cd8951/classes/ + # contributed_definitions/NXapm.html + # where further details of the flight geometry should be recorded however + # in the majority of cases these data are not offered by APSuite and + # so far nobody has asked or seriously proceeded with how to use these + # pieces of information if they were to be stored + # MK::NEW ISSUE field_of_view(NX_FLOAT): exists: recommended doc: | @@ -460,12 +501,21 @@ NXapm: exists: optional description: exists: recommended + (NXcsg): + exists: optional # NEW ISSUE: flat_test_data(NXcollection): # exists: recommended # doc: NEED FOR FURTHER DISCUSSIONS WITH APM COLLEAGUES WHAT IS RELEVANT HERE. + # NEW ISSUE: have a place to be more specific about the geometry and + # usage of additional lenses: + # for the invizo 6000 instrument it makes sense to add at least groups for the two additional lenses whereby the field of view is brought from 50-60 to at most 100 the key invention + # add: decelerating_electrode(NXlens_em) accelerating_mesh maybe needs an own base class + # I suggest that this section should be reworked with the local_electrode being required and all other components and opposite counter_electrodes being optional WO2016171675A1 details the key specifications of the components and the setup + # see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 according to A. Breen (UNSW) local_electrode(NXlens_em): doc: | - A local electrode guiding the ion flight path. + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. name: doc: | Identifier of the local_electrode in an e.g. database. @@ -481,6 +531,8 @@ NXapm: exists: optional value(NX_NUMBER): exists: recommended # ##MK::should become required + (NXcsg): + exists: optional # but the local_electrode does not really on purpose create a magnetic field, # specific for an electro-magnetic lens is the symmetry of its field # NEW ISSUE: for now keep that we have what is an NXlens_em @@ -527,7 +579,11 @@ NXapm: dimensions: rank: 1 dim: [[1, n_ions]] + (NXcsg): + exists: optional pulser(NXpulser_apm): + # NEW ISSUE: other sources of pulsers are possible + # NEW ISSUE: see in WO2016171675A1 Invizo 6000 patent from AMETEK pulse_mode: pulse_frequency(NX_FLOAT): pulse_fraction(NX_FLOAT): @@ -535,7 +591,9 @@ NXapm: exists: recommended standing_voltage(NX_FLOAT): exists: recommended - laser_gun(NXsource): + (NXcsg): + exists: optional + LASER_SOURCE(NXsource): exists: [min, 0, max, 2] # INVIZO 6000 instrument have two symmetric lasers! so for these # laser_gun and laser_beam exists: [min, 0, max, 2] @@ -583,8 +641,22 @@ NXapm: Average temperature at the specimen base, i.e. base_temperature during the measurement. unit: NX_TEMPERATURE - + temperature(NX_FLOAT): + exists: optional + doc: | + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + unit: NX_TEMPERATURE + dimensions: + rank: 1 + dim: [[1, n_ions]] + (NXcsg): + exists: optional + # evaporation control in which context is it used? # NEW ISSUE: begin add and support I/O of further details + # NEW ISSUE: with Shyam Katnagallu fix that so far the application definition does not really cover fim as there is no place to store values for a gas injection system and a (partial) pressure sensor for the imaging gas it should be clarified in the docstring of the pressure field if this measured either a chamber total of a species partial pressure + # NEW ISSUE: add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM analysis_chamber(NXchamber): name: exists: optional @@ -604,6 +676,8 @@ NXapm: doc: | Average pressure in the analysis chamber. unit: NX_PRESSURE + (NXcsg): + exists: optional buffer_chamber(NXchamber): exists: optional name: @@ -624,6 +698,8 @@ NXapm: doc: | Average pressure in the buffer chamber. unit: NX_PRESSURE + (NXcsg): + exists: optional load_lock_chamber(NXchamber): exists: optional name: @@ -644,6 +720,8 @@ NXapm: doc: | Average pressure in the load_lock_chamber. unit: NX_PRESSURE + (NXcsg): + exists: optional getter_pump(NXpump): exists: optional design: @@ -658,6 +736,8 @@ NXapm: exists: recommended capabilities: exists: optional + (NXcsg): + exists: optional roughening_pump(NXpump): exists: optional design: @@ -672,6 +752,8 @@ NXapm: exists: recommended capabilities: exists: optional + (NXcsg): + exists: optional turbomolecular_pump(NXpump): exists: optional design: @@ -686,7 +768,23 @@ NXapm: exists: recommended capabilities: exists: optional + (NXcsg): + exists: optional # NEW ISSUE: end add and support I/O of further details + + instrument_calibration(NXcollection): + exists: recommended + doc: | + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group `_ + (see `P. Felfer et al. `_ ) + # gridded-counter-electrode shadow image polyline fits are exported as + # NXcg_spline_set see also https://www.youtube.com/watch?v=99hNEkqdj78t=2348s + # NEW ISSUE: dld_signal_amplitude monitoring + # arrival_time_pairs: (recommended) NX_NUMBER (Rank: 3, Dimensions: [n_ions, n_dld_wires, 2]) {units=NX_TIME} + # eventually one may wish to store values from an NXmonitoring tracking the DLD signal amplitude (mV) = f(t) specimen_monitoring(NXcollection): exists: recommended # NEW ISSUE: should be promoted to recommended at some point in particular with closer integration of APM and EM instruments @@ -732,6 +830,14 @@ NXapm: Average detection rate over the course of the experiment. unit: NX_DIMENSIONLESS # NEW ISSUE: define e.g. radius(NX_FLOAT) and evaporation_id(NX_UINT) to store snapshots of the shape evolution of the specimen. + estimated_field_at_the_apex(NX_FLOAT): + exists: optional + doc: | + Estimated field at the apex along the evaporation sequence. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_ions]] control_software(NXcollection): doc: | @@ -764,17 +870,10 @@ NXapm: but relevant pieces of information is the purpose of this collection. # NEW ISSUE: With new development pull fields out of this collection into dedicated groups. # might consider moving this to individual groups under (NXpump) or (NXchamber) groups. - program: - doc: | - Name of the control software of the microscope - used during acquisition (e.g. IVAS/APSuite). - \@version: - doc: | - Program 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. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: buffer_chamber(NXcollection): exists: optional doc: Track time-dependent details over the course of the measurement about the buffer_chamber. @@ -793,7 +892,21 @@ NXapm: # these steps are currently not fully separatable as all processing in # most cases the processing is done in commercial software. + status: + doc: | + A statement whether the measurement was successful or failed prematurely. + enumeration: [success, failure] + + # NEW ISSUE: atomic volume, detection efficiency, electric field (assumptions), + # final specimen state, pre, post image analysis, a reference to three images + # taken as recommended by cameca, before or after, radius evolution model, field # factor, image compression + + # default statistics would be good to report as output e.g. + # total ions (single, multiple, partial) reconstructed ions (ranged, unranged) + # voltage and bowl calibration (peak) mass_calibration as an own field + ion_impact_positions(NXprocess): + # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group exists: recommended doc: | Details about where ions hit the ion_detector and data processing @@ -806,18 +919,12 @@ NXapm: For instruments built by individual research groups, like the Oxcart instrument, individual timing data from the delay-line detector are openly accessible. - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: arrival_time_pairs(NX_NUMBER): exists: recommended doc: | @@ -834,6 +941,9 @@ NXapm: Evaluated ion impact coordinates at the detector (either as computed from the arrival time data or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. unit: NX_LENGTH dimensions: rank: 2 @@ -842,6 +952,15 @@ NXapm: # detection_rate_time_profile(NX_FLOAT): # doc: Spatio-temporal profile of the detection rate since the start of the measurement. # NEW ISSUE: discuss how to handle cases when we would like to store ideally an array where one dimensions is NX_TIME and the other one is e.g. NX_PERCENT + hit_quality_filtering(NXprocess): + exists: optional + doc: | + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + sequence_index(NX_POSINT): + exists: recommended hit_multiplicity(NXprocess): # NEW ISSUE: use symbols to monitor number of pulses exists: recommended @@ -859,18 +978,12 @@ NXapm: f the same element or isotope, respectively, a molecular ion contains (which is instead encoded with the isotope_vector field of each NXion instance). - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: pulses_since_last_ion(NX_UINT): exists: recommended doc: | @@ -910,18 +1023,12 @@ NXapm: in the voltage-and-bowl correction. This post-processing is usually performed via GUI interaction in the reconstruction pipeline of IVAS/APSuite. - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: evaporation_id_included(NX_BOOLEAN): # NXcs_filter_boolean_mask doc: | Bitmask which is set to true if the ion @@ -931,24 +1038,19 @@ NXapm: dim: [[1, n_ions]] # then only a group voltage_and_bowl_correction(NXprocess): + # NEW ISSUE: add section for propagation_delay(NXprocess) ? exists: recommended doc: | Data post-processing step to correct for ion impact position flight path differences, detector biases, and nonlinearities. This step is usually performed with commercial software. - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: # NEW ISSUE: realistic is that currently scientists can pull always a calibrated time-of-flight # but not necessarily unprocessed timing data from the detector (unless individuals built the instrument). # Relevant for ranging are the calibrated data, thats why only these @@ -1004,18 +1106,12 @@ NXapm: doc: | Data post-processing step in which calibrated time-of-flight data (ToF) are interpreted into mass-to-charge-state ratios. - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: parameter(NXcollection): exists: recommended doc: | @@ -1029,6 +1125,7 @@ NXapm: rank: 1 dim: [[1, n_ions]] + # NEW ISSUE: make this rather an own subentry NXapm_reconstruction reconstruction(NXprocess): exists: recommended doc: | @@ -1039,17 +1136,12 @@ NXapm: published procedures, so-called reconstruction protocols, i.e. numerical recipes how to compute x, y, z atomic positions from the input data. - program: - doc: | - Given name of the program that was used to perform this computation. - Similar comments as voltage_and_bowl_correction apply. - \@version: - doc: | - Program 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. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: protocol_name: doc: | Qualitative statement about which reconstruction protocol was used. @@ -1093,6 +1185,28 @@ NXapm: dimensions: rank: 2 dim: [[1, n_ions], [2, 3]] + visualization(NXprocess): + exists: recommended + xdmf_topology(NX_UINT): + doc: | + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. The XDMF primitive type is here 1, the number of primitives 1 per triplet, the last integer in each triplet is the identifier of each point starting from zero. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_topology]] + # n_topology == 3*n_ions + xdmf_topology(NX_UINT): + doc: | + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 36]] naive_point_cloud_density_map(NXprocess): doc: | @@ -1100,18 +1214,10 @@ NXapm: the format conversion computes a simple 3d histogram of the ion density using one nanometer cubic bins without applying smoothening algorithms on this histogram. - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: (NXdata): doc: | A default three-dimensional histogram of the total @@ -1150,6 +1256,7 @@ NXapm: dim: [[1, n_x]] \@long_name: + # NEW ISSUE: make this rather an own subentry NXapm_ranging ranging(NXprocess): exists: recommended doc: | @@ -1162,18 +1269,12 @@ NXapm: * `D. Haley et al. `_ * `M. Kühbach et al. `_ - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: number_of_ion_types(NX_UINT): doc: | How many ion types are distinguished. @@ -1195,18 +1296,10 @@ NXapm: Usually mass-to-charge values are studied as an ensemble quantity, specifically these values are binned. This (NXprocess) stores the settings of this binning. - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: range_minmax(NX_FLOAT): doc: | Smallest and largest mass-to-charge-state ratio value. @@ -1252,18 +1345,10 @@ NXapm: doc: | Details of the background model which was used to correct the total counts per bin into counts. - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: # NEW ISSUE: add parameters of the background model in an e.g. # NXcollection as these are specific to every background model # NEW ISSUE: touching upon i.e. research activities by Andrew London et al. @@ -1275,18 +1360,10 @@ NXapm: doc: | How where peaks in the background-corrected in the histogram of mass-to-charge-state ratio values identified? - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: (NXpeak): exists: [min, 0, max, infty] label: @@ -1300,18 +1377,10 @@ NXapm: doc: | Details about how peaks, with taking into account error models, were interpreted as ion types or not. - program: - doc: | - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - \@version: - doc: | - Program 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. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: (NXion): exists: [min, 0, max, 256] isotope_vector(NX_UINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml index f60ec06fb9..6742c8f399 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml @@ -33,7 +33,6 @@ NXapm_paraprobe_config_clusterer: ISO 8601 formatted time code with local time zone offset to UTC information included when this configuration file was created. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -190,14 +189,14 @@ NXapm_paraprobe_config_clusterer: hit_multiplicity_filter(NXmatch_filter): exists: optional - # clustering_algorithm(NX_CHAR): + # clustering_algorithm: # doc: | # Name of the clustering algorithm used. # enumeration: [dbscan] # , optics, hpdbscan] # dimensions: # rank: 1 # dim: [[1, n_clust_algos]] - ion_type_filter(NX_CHAR): + ion_type_filter: doc: | How should iontypes be interpreted/considered during the cluster analysis. Different options exist how iontypes are interpreted (if considered at all) @@ -252,7 +251,7 @@ NXapm_paraprobe_config_clusterer: For details about how the DBScan algorithms is the key behind the specific modification known as the maximum-separation method in the atom probe community consider `E. Jägle et al. `_ - high_throughput_method(NX_CHAR): + high_throughput_method: doc: | Strategy how runs are performed with different parameter: @@ -293,7 +292,7 @@ NXapm_paraprobe_config_clusterer: Settings for the OPTICS clustering algorithm. * `M. Ankerest et al. `_ - high_throughput_method(NX_CHAR): + high_throughput_method: doc: | Strategy how runs are performed with different parameter: @@ -326,7 +325,7 @@ NXapm_paraprobe_config_clusterer: See also this documentation for details about the parameter. Here we use the terminology of the hdbscan documentation. - high_throughput_method(NX_CHAR): + high_throughput_method: doc: | Strategy how runs are performed with different parameter: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml index 120b994884..19229f8fcc 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml @@ -26,7 +26,6 @@ NXapm_paraprobe_config_distancer: ISO 8601 formatted time code with local time zone offset to UTC information included when this configuration file was created. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml index 2766a2dfe6..9283276f8f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml @@ -24,7 +24,6 @@ NXapm_paraprobe_config_intersector: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -46,7 +45,7 @@ NXapm_paraprobe_config_intersector: For now a support field for the tool to identify how many individual analyses the tool should execute as part of the analysis. unit: NX_UNITLESS - volume_volume_spatial_correlation(NXprocess): + VOLUME_VOLUME_SPATIAL_CORRELATION(NXprocess): exists: [min, 1, max, infty] doc: | Tracking volume_volume_spatial_correlation is the process of building logical @@ -129,8 +128,9 @@ NXapm_paraprobe_config_intersector: doc: | This identifier can be used to label the current set. The label effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in M. Kühbach - et al. 2022, this identifier takes the role of the time variable k. + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 `_, this identifier + takes the role of the time variable :math:`k`. unit: NX_ANY # number_of_objects(NX_UINT): # doc: For now a support field to tell the tool how many objects to load. @@ -153,7 +153,7 @@ NXapm_paraprobe_config_intersector: unit: NX_UNITLESS FEATURE(NXcollection): exists: [min, 1, max, 4] # restriction to two not needed, currently for objects and proxies - feature_type(NX_CHAR): + feature_type: doc: | Descriptive category explaining what these features are. enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] @@ -176,6 +176,10 @@ NXapm_paraprobe_config_intersector: doc: | Array of identifier whereby the path to the geometry data can be interferred automatically. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] next_set(NXcollection): doc: | @@ -187,8 +191,9 @@ NXapm_paraprobe_config_intersector: doc: | This identifier can be used to label the next_set. The label effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in M. Kühbach - et al. 2022, this identifier takes the role of the time variable k+1. + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 `_, this identifier + takes the role of the time variable :math:`k + 1`. unit: NX_ANY # number_of_objects(NX_UINT): # doc: For now a support field to tell the tool how many objects to load. @@ -211,7 +216,7 @@ NXapm_paraprobe_config_intersector: unit: NX_UNITLESS FEATURE(NXcollection): exists: [min, 1, max, 4] # restriction to two not needed, currently for objects and proxies - feature_type(NX_CHAR): + feature_type: doc: | Descriptive category explaining what these features are. enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] @@ -234,6 +239,10 @@ NXapm_paraprobe_config_intersector: doc: | Array of identifier whereby the path to the geometry data can be interferred automatically. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] # ##MK::tetrahedra volume intersection and tessellation, and Nef polyhedra intersection # ##MK::are considered guru features and therefore currently supported via modifying the C/C++ source code diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml index 758a0602ef..04b73691af 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml @@ -27,7 +27,6 @@ NXapm_paraprobe_config_nanochem: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -142,12 +141,12 @@ NXapm_paraprobe_config_nanochem: dataset_name: doc: Absolute HDF5 path to the dataset with distance values for each ion. - number_of_delocalizations(NX_UINT): - doc: | - For now a support field for the tool to identify how many individual - delocalization analyses for the above-mentioned dataset and supplementary - files are executed as part of the high-throughput analysis. - unit: NX_UNITLESS + # number_of_delocalizations(NX_UINT): + # doc: | + # For now a support field for the tool to identify how many individual + # delocalization analyses for the above-mentioned dataset and supplementary + # files are executed as part of the high-throughput analysis. + # unit: NX_UNITLESS delocalization(NXprocess): # NEW ISSUE delocalization is all lower case meaning you cannot have right now multiple of these # even though paraprobe-nanochem triggers a number of delocalizations for each of which triggering again isosurfaces @@ -218,14 +217,14 @@ NXapm_paraprobe_config_nanochem: # \@units: nm kernel_size(NX_UINT): doc: | - Half the width of a (2n+1)^3 cubic kernel of voxel beyond - which the Gaussian Ansatz function will be truncated. + Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel + beyond which the Gaussian Ansatz function will be truncated. Intensity beyond the kernel is refactored into the kernel via a normalization procedure. unit: NX_UNITLESS kernel_variance(NX_FLOAT): doc: | - Variance of the Gaussian Ansatz kernel sigma_x = sigma_y = 2*sigma_z. + Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`. unit: NX_LENGTH # \@units: nm normalization: @@ -288,14 +287,21 @@ NXapm_paraprobe_config_nanochem: In the results of each paraprobe-nanochem run, these proxy objects are listed separately to allow users to quantify and analyze in detail the differences when accounting for these objects or not. - Especially this is relevant in atom probe microscopy are small - in the sense that they contain few (many a few dozen) objects. - Even though such a dataset may give statistically significant - results for compositions this does not mean it necessarily yields - also statistically significant and unbiased results for three-dimensional - object analyses. Being able to quantify these effects and making - atom probers aware of these subtleties was one of the main reasons - why the paraprobe-nanochem tool was implemented. + Especially this is relevant in atom probe microscopy as objects + can contain a few dozen atoms only. + Users should be aware that results from fairing operations should + be compared to results from analyses where all objects at the edge + of the dataset have been removed. + + Also users should be careful with overestimating the statistical + significance of their dataset especially when using atom probe + to compare multiple descriptors: Even though a dataset may give + statistically significant results for compositions, this does not + necessarily mean it will yield also statistically significant + and unbiased results for three-dimensional object analyses. + Being able to quantify these effects and making atom probers + aware of these subtleties was one of the main reasons why the + paraprobe-nanochem tool was implemented. enumeration: [default, keep_edge_triangles] edge_threshold(NX_FLOAT): doc: | @@ -723,7 +729,9 @@ NXapm_paraprobe_config_nanochem: be eventually relocated. The larger the DCOM radius is relative to the target_edge_length the more likely it is that vertices will be relocated so substantially that eventually triangle self-intersections - can occur. + can occur. If the code detects these it warns and stops in a + controlled manner so that the user can repeat the analyses + with a smaller value. unit: NX_LENGTH # \@units: nm dimensions: @@ -766,8 +774,8 @@ NXapm_paraprobe_config_nanochem: Users should be aware that the latter intersection analysis is strictly speaking not a volumetric intersection analysis as such one is much more involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder piercing - or laying completely inside the polyhedron. For this the polyhedron has + in which case one would have to test robustly if the cylinder pierces + or is laying completely inside the polyhedron. For this the polyhedron has to be tessellated into convex polyhedra as otherwise tests like the Gilbert-Johnson-Keerthi algorithm would not be applicable. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml index b4b7e8fe21..10d9ffab8f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml @@ -30,7 +30,6 @@ NXapm_paraprobe_config_ranger: ISO 8601 formatted time code with local time zone offset to UTC information included when this configuration file was created. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -49,17 +48,6 @@ NXapm_paraprobe_config_ranger: (NXprocess): exists: [min, 0, max, infty] - number_of_ranging_processes(NX_UINT): - doc: | - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - unit: NX_UNITLESS - number_of_ion_search_processes(NX_UINT): - doc: | - How many molecular_ion_search processes should - the tool execute as part of the analysis. - unit: NX_UNITLESS - apply_existent_ranging(NXprocess): exists: [min, 0, max, 1] dataset(NXapm_input_reconstruction): @@ -113,6 +101,7 @@ NXapm_paraprobe_config_ranger: molecular_ion_search(NXprocess): exists: [min, 0, max, infty] assumed_composition_isotopes(NX_UINT): + exists: optional doc: | A list of pairs of number of protons and either the value 0 (per row) or the mass number for all those isotopes which are assumed present diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml index a0ac6b516f..b888a47393 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml @@ -24,7 +24,6 @@ NXapm_paraprobe_config_selector: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml index 105ce7fcf6..641b964428 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml @@ -27,7 +27,6 @@ NXapm_paraprobe_config_spatstat: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -49,215 +48,226 @@ NXapm_paraprobe_config_spatstat: How many range_with_existent_iontypes processes should the tool execute as part of the analysis. unit: NX_UNITLESS - spatial_statistics(NXprocess): - exists: [min, 0, max, 1] - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: + (NXprocess): + exists: [min, 1, max, 1] + spatial_statistics(NXprocess): + exists: [min, 0, max, 1] + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): + spatial_filter(NXspatial_filter): exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): + windowing_method: + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): + iontype_filter(NXmatch_filter): exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + ion_to_edge_distances(NXprocess): exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - ion_to_edge_distances(NXprocess): - exists: optional - doc: | - The tool enables to inject precomputed distances of each ion to a - representation of the edge of the dataset which can be used to - control and substantially reduce edge effects when computing spatial statistics. - filename: doc: | - Name of an HDF5 file which contains ion-to-edge distances. - dataset_name_distances: + The tool enables to inject precomputed distances of each ion to a + representation of the edge of the dataset which can be used to + control and substantially reduce edge effects when computing + spatial statistics. + filename: + doc: | + Name of an HDF5 file which contains ion-to-edge distances. + dataset_name_distances: + doc: | + Absolute HDF5 path to the dataset with the + ion-to-edge distance values for each ion. + The shape of the distance values has to match the length + of the ion positions array in dataset/dataset_name_reconstruction + and dataset_name_mass_to_charge respectively. + edge_distance(NX_FLOAT): + doc: | + Threshold to define how large an ion has to lay at least far away + from the edge of the dataset so that the ion can act as a source, + i.e. that an ROI is placed at the location of the ion and its + neighbors are analyzed how they contribute to the computed statistics. + + The ion_to_edge_distances threshold can be combined with a threshold + for the ion_to_feature_distances. + Specifically, if ion_to_feature_distances are loaded an ion only + acts as a source if both threshold criteria are met. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + unit: NX_LENGTH + ion_to_feature_distances(NXprocess): + exists: optional # NEW ISSUE: is this optional? + doc: | + In addition to spatial filtering, and considering how far ions lie + to the edge of the dataset, it is possible to restrict the analyses + to a sub-set of ions within a distance not farther away to a feature than + a threshold value. + filename: + doc: | + Name of an HDF5 file which contains ion-to-feature distances. + dataset_name_distances: + doc: | + Absolute HDF5 path to the dataset with the + ion-to-feature distance values for each ion. + threshold(NX_FLOAT): + doc: | + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. + + Recall that the ion_to_feature_distances threshold is combined + with the ion_to_edge_distances threshold. + unit: NX_LENGTH + # ##MK::think about an inversion ruleset for the filter, i.e. + # like discussed in Haley/Stephenson's paper where ions only far enough + # from a feature AND deeply embedded enough in the dataset are chosen. + randomize_ion_types(NX_BOOLEAN): doc: | - Absolute HDF5 path to the dataset with the - ion-to-edge distance values for each ion. - The shape of the distance values has to match the length - of the ion positions array in dataset/dataset_name_reconstruction - and dataset_name_mass_to_charge respectively. - edge_distance(NX_FLOAT): + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + random_number_generator(NXcs_prng): + exists: recommended + type: + seed(NX_NUMBER): + warmup(NX_NUMBER): + ion_query_type_source: doc: | - Threshold to define how large an ion has to lay at least far away - from the edge of the dataset so that the ion can act as a source, - i.e. that an ROI is placed at the location of the ion and its - neighbors are analyzed how they contribute to the computed statistics. + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. - The ion_to_edge_distances threshold can be combined with a threshold - for the ion_to_feature_distances. - Specifically, if ion_to_feature_distances are loaded an ion only - acts as a source if both threshold criteria are met. + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. - unit: NX_LENGTH - ion_to_feature_distances(NXprocess): - exists: optional # NEW ISSUE: is this optional? - doc: | - In addition to spatial filtering, and considering how far ions lie - to the edge of the dataset, it is possible to restrict the analyses - to a sub-set of ions within a distance not farther away to a feature than - a threshold value. - filename: - doc: | - Name of an HDF5 file which contains ion-to-feature distances. - dataset_name_distances: + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. + + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + ion_query_isotope_vector_source(NX_UINT): doc: | - Absolute HDF5 path to the dataset with the - ion-to-feature distance values for each ion. - threshold(NX_FLOAT): + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ion_source], [2, n_ivecmax]] + ion_query_type_target: doc: | - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that the ion_to_feature_distances threshold is combined - with the ion_to_edge_distances threshold. - unit: NX_LENGTH - # ##MK::think about an inversion ruleset for the filter, i.e. - # like discussed in Haley/Stephenson's paper where ions only far enough - # from a feature AND deeply embedded enough in the dataset are chosen. - randomize_labels(NX_BOOLEAN): - doc: | - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - random_number_generator(NXcs_prng): - exists: recommended - type: - seed(NX_NUMBER): - warmup(NX_NUMBER): - ion_query_type_source: - doc: | - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - ion_query_isotope_vector_source(NX_UINT): - doc: | - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_ion_source], [2, n_ivecmax]] - ion_query_type_target: - doc: | - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - # NEW ISSUE: conditionally required only when resolve_isotope - ion_query_isotope_vector_target(NX_UINT): - doc: | - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_ion_target], [2, n_ivecmax]] - statistics(NXprocess): - doc: | - Specifies which spatial statistics to compute. - knn(NXprocess): - doc: Compute k-th nearest neighbour statistics. - exists: optional - nth(NX_UINT): - doc: Order k. - unit: NX_UNITLESS - histogram_min_incr_max(NX_FLOAT): - doc: | - Minimum value, increment, and maximum value of the histogram binning. - unit: NX_LENGTH - # \@units: nm - dimensions: - rank: 1 - dim: [[1, 3]] - rdf(NXprocess): + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + # NEW ISSUE: conditionally required only when resolve_isotope + ion_query_isotope_vector_target(NX_UINT): doc: | - Compute radial distribution function. - exists: optional - histogram_min_incr_max(NX_FLOAT): + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ion_target], [2, n_ivecmax]] + statistics(NXprocess): + doc: | + Specifies which spatial statistics to compute. + knn(NXprocess): doc: | - Minimum value, increment, and maximum value of the histogram binning. - unit: NX_LENGTH - # \@units: nm - dimensions: - rank: 1 - dim: [[1, 3]] - # NEW ISSUE: ripleyk(NXcollection): - # NEW ISSUE: two_point(NXcollection): + Compute k-th nearest neighbour statistics. + exists: optional + nth(NX_UINT): + doc: | + Order k. + unit: NX_UNITLESS + histogram_min_incr_max(NX_FLOAT): + doc: | + Minimum value, increment, and maximum value of the histogram binning. + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 1 + dim: [[1, 3]] + rdf(NXprocess): + doc: | + Compute radial distribution function. + exists: optional + histogram_min_incr_max(NX_FLOAT): + doc: | + Minimum value, increment, and maximum value of the histogram binning. + unit: NX_LENGTH + # \@units: nm + dimensions: + rank: 1 + dim: [[1, 3]] + # NEW ISSUE: ripleyk(NXcollection): + # NEW ISSUE: two_point(NXcollection): performance(NXcs_profiling): current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml index a54a3a477d..e7a7323c92 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml @@ -30,7 +30,6 @@ NXapm_paraprobe_config_surfacer: ISO 8601 formatted time code with local time zone offset to UTC information included when this configuration file was created. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -173,8 +172,8 @@ NXapm_paraprobe_config_surfacer: doc: | Array of alpha values to use when alpha_value_choice is set_of_values or when alpha_value_choice is set_of_alpha_wrappings. - unit: NX_LENGTH - # \@units: nm + unit: NX_ANY + # \@units: nm^2 dimensions: rank: 1 dim: [[1, n_alpha_values]] diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml index 2833a47c61..472e33115b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml @@ -25,7 +25,6 @@ NXapm_paraprobe_config_tessellator: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -176,13 +175,12 @@ NXapm_paraprobe_config_tessellator: by the edge of the dataset or if cells are deeply enough embedded into the point cloud so that the shape of their cells are not affected by the presence of the boundary. - erosion_distance(NX_FLOAT): - doc: | - Maximum distance for which cells are eroded. - # ##MK::needs further details or is this at all a parameter? - unit: NX_LENGTH - # \@units: nm - # minValue: EPSILON + # erosion_distance(NX_FLOAT): + # doc: | + # Maximum distance for which cells are eroded. + # unit: NX_LENGTH + # # \@units: nm + # # minValue: EPSILON performance(NXcs_profiling): current_working_directory: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml index 6bf8a07ebe..f9896fb6a8 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml @@ -27,7 +27,6 @@ NXapm_paraprobe_config_transcoder: configured ideally in such a manner that the result of this computational process is recreatable deterministically. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml index 0424b8a7a4..bdbf03a502 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml @@ -62,7 +62,7 @@ NXapm_paraprobe_results_clusterer: Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status(NX_CHAR): + status: doc: | A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -190,7 +190,7 @@ NXapm_paraprobe_results_clusterer: # doc: | # How many categorical labels does each feature have. # unit: NX_UNITLESS - # features(NX_CHAR): + # features: # doc: | # Reference to a set of features investigated in a cluster analysis. # Features need to have disjoint numeric identifier. @@ -221,7 +221,7 @@ NXapm_paraprobe_results_clusterer: # dimensions: # rank: 1 # dim: [[1, n_dict]] - # reserved_identifier_value(NX_CHAR): + # reserved_identifier_value: # doc: | # The corresponding value of the reserved_identifier dictionary. # This can give a free-text description what a specific reserved @@ -264,7 +264,7 @@ NXapm_paraprobe_results_clusterer: dimensions: rank: 1 dim: [[1, c]] # ], [2, n_lbl_num]] - # categorical_label(NX_CHAR): + # categorical_label: # doc: | # Matrix of categorical attribute data for each member in the set. # dimensions: diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml index 7fea68ce8c..0e7724fcdc 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml @@ -32,7 +32,6 @@ NXapm_paraprobe_results_distancer: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -63,7 +62,7 @@ NXapm_paraprobe_results_distancer: Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status(NX_CHAR): + status: doc: | A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -156,10 +155,13 @@ NXapm_paraprobe_results_distancer: rank: 1 dim: [[1, n_ions]] window_triangles(NXcs_filter_boolean_mask): + exists: optional doc: | A bitmask which identifies which of the triangles in the set were considered. Usually these are all but sometimes users may wish to filter certain portions of the triangles out. + If window_triangles is not provided it means that + all triangles were taken. number_of_triangles(NX_UINT): doc: | Number of triangles covered by the mask. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml index 99e01e7eae..ac179c7df4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml @@ -35,7 +35,6 @@ NXapm_paraprobe_results_intersector: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -43,10 +42,16 @@ NXapm_paraprobe_results_intersector: exists: optional doc: | Possibility for leaving a free-text description about this analysis. - time_stamp(NX_DATE_TIME): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC - information included when this results file was created. + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. config_filename: doc: | The absolute path and name of the config file for this analysis. @@ -105,7 +110,7 @@ NXapm_paraprobe_results_intersector: # ##MK::begin of the tool-specific section (NXprocess): - volume_volume_spatial_correlation(NXprocess): + VOLUME_VOLUME_SPATIAL_CORRELATION(NXprocess): exists: [min, 0, max, 1] doc: | The results of an overlap/intersection analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml index 8e4dd61520..ab81db5353 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml @@ -70,7 +70,7 @@ NXapm_paraprobe_results_nanochem: Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status(NX_CHAR): + status: doc: | A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -167,7 +167,7 @@ NXapm_paraprobe_results_nanochem: iso_surface_analysis(NXprocess): exists: [min, 0, max, infty] - delocalization(NXdelocalization): + DELOCALIZATION(NXdelocalization): weighting_model: doc: | The weighting model specifies how mark data are mapped to a weight @@ -245,7 +245,7 @@ NXapm_paraprobe_results_nanochem: dimensions: rank: 1 dim: [[1, n_isotopic]] - normalization(NX_CHAR): + normalization: doc: | How results of the kernel-density estimation were computed into quantities. By default the tool computes the total number @@ -307,11 +307,13 @@ NXapm_paraprobe_results_nanochem: rank: 1 dim: [[1, d]] # (NXtransformations): - coordinate_system(NX_CHAR): + coordinate_system: exists: optional doc: | Reference to or definition of a coordinate system with which the positions and directions are interpretable. + If the coordinate system is not specified the paraprobe + coordinate system is used. # should constraints on the grid be place here or not identifier_offset(NX_INT): doc: | @@ -396,10 +398,6 @@ NXapm_paraprobe_results_nanochem: dimensions: rank: 1 dim: [[1, 36]] - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 36]] number_of_boundaries(NX_POSINT): exists: optional @@ -408,7 +406,7 @@ NXapm_paraprobe_results_nanochem: Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. unit: NX_UNITLESS - boundaries(NX_CHAR): + boundaries: exists: optional doc: | Name of the boundaries. E.g. left, right, front, back, bottom, top, @@ -571,7 +569,7 @@ NXapm_paraprobe_results_nanochem: dimensions: rank: 1 dim: [[1, 3]] - # kernel_type(NX_CHAR): + # kernel_type: # doc: | # Functional form of the kernel (Ansatz function). kernel_sigma(NX_FLOAT): @@ -749,7 +747,7 @@ NXapm_paraprobe_results_nanochem: doc: | Triangle normals are oriented in the direction of the gradient vector of the local delocalized scalar field. - :math:`$\sum_{x, y, z} {\nabla{c}_i}^2$`. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. unit: NX_ANY dimensions: rank: 1 @@ -804,7 +802,7 @@ NXapm_paraprobe_results_nanochem: unit: NX_ANGLE dimensions: rank: 2 - dim: [[1, j], [2, 3]] + dim: [[1, j], [2, 4]] center(NX_NUMBER): exists: optional doc: The center of mass of each triangle. @@ -823,8 +821,8 @@ NXapm_paraprobe_results_nanochem: by triangles. Currently, the tool distinguishes at most three types of features: - 1. So-called objects, i.e. not necessarily watertight features - convex polyhedra + 1. So-called objects, i.e. necessarily watertight features + represented polyhedra. 2. So-called proxies, i.e. features that were replaced by a proxy mesh and made watertight. 3. Remaining triangle surface meshes of arbitrary shape and @@ -835,9 +833,10 @@ NXapm_paraprobe_results_nanochem: some of them may be segments of dislocation lines or other crystal defects which are decorated (or not) with solutes. - Each type of feature needs to be registered in the feature_type - dictionary. Type identifiers (keywords are integer), values - are human-readable names like object, proxy, undefined + # Each type of feature needs to be registered in the feature_type + # dictionary. Type identifiers (keywords are integer), values + # are human-readable names like object, proxy, undefined + # NEW ISSUE: refactor using instances of NXms_feature_set triangle_cluster_identifier(NX_UINT): doc: | The identifier which the triangle_soup connectivity analysis @@ -855,7 +854,7 @@ NXapm_paraprobe_results_nanochem: dimensions: rank: 1 dim: [[1, n_feature_dict]] - feature_type_dict_value(NX_CHAR): + feature_type_dict_value: exists: optional doc: | The array of values for each keyword of the @@ -890,7 +889,7 @@ NXapm_paraprobe_results_nanochem: doc: | Details for features which are (closed) objects. Identifier have to exist in feature_identifier - `:mathcal:$identifier \in feature_identifier$`. + :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. # ##MK::constraints! feature_identifier(NX_UINT): unit: NX_UNITLESS @@ -1130,7 +1129,7 @@ NXapm_paraprobe_results_nanochem: processing their partial triangulated_surface_mesh (hole filling, refinement). Identifier have to exist in feature_identifier - `:mathcal:$identifier \in feature_identifier$`. + :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. # ##MK::constraints feature_identifier are a subset of the parent! feature_identifier(NX_UINT): unit: NX_UNITLESS @@ -1143,14 +1142,14 @@ NXapm_paraprobe_results_nanochem: rank: 1 dim: [[1, i]] # obb ? - proxies_close_to_edge(NXms_three_d_feature_set): + proxies_close_to_edge(NXprocess): # (NXms_three_d_feature_set): exists: optional doc: | Details for those proxies close to edge, i.e. those which have at least one ion which lays closer to a modelled edge of the dataset than threshold. Identifier have to exist in feature_identifier - `:mathcal:$identifier \in feature_identifier$`. + :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. # ##MK::constraints! feature_identifier(NX_UINT): unit: NX_UNITLESS @@ -1314,6 +1313,13 @@ NXapm_paraprobe_results_nanochem: The multiplicity whereby the ion position is accounted for irrespective whether the ion is considered as a decorator of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. unit: NX_UNITLESS dimensions: rank: 1 @@ -1321,24 +1327,23 @@ NXapm_paraprobe_results_nanochem: decorator_multiplicity(NX_UINT): exists: optional doc: | - The multiplicity whereby the ion position is accounted - for when the ion is considered´one which is a decorator - of the interface. + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. unit: NX_UNITLESS dimensions: rank: 1 dim: [[1, n_ions]] - initial_interface: # ##MK::(NXcg_plane_set): + initial_interface(NXprocess): # MK::(NXcg_plane_set): exists: optional doc: | - The equation of the plane that is fitting initially. - point_normal_form(NX_FLOAT): - doc: | - The four parameter ax + by + cz + d = 0 which define the plane. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 4]] + The equation of the plane that is fitted initially. + point_normal_form(NX_FLOAT): + doc: | + The four parameter :math:`ax + by + cz + d = 0` which define the plane. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 4]] MESH_CURR_PRE_DCOM_STEP(NXcg_triangle_set): exists: [min, 0, max, infty] doc: | @@ -1452,7 +1457,7 @@ NXapm_paraprobe_results_nanochem: unit: NX_ANGLE dimensions: rank: 2 - dim: [[1, c], [2, 3]] + dim: [[1, c], [2, 4]] MESH_CURR_POST_DCOM_STEP(NXcg_triangle_set): exists: [min, 0, max, infty] doc: | @@ -1565,7 +1570,7 @@ NXapm_paraprobe_results_nanochem: unit: NX_ANGLE dimensions: rank: 2 - dim: [[1, c], [2, 3]] + dim: [[1, c], [2, 4]] composition_analysis(NXprocess): exists: optional diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml index bffff42e96..9af3ce2105 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml @@ -33,7 +33,6 @@ NXapm_paraprobe_results_ranger: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -64,7 +63,7 @@ NXapm_paraprobe_results_ranger: Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status(NX_CHAR): + status: doc: | A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -141,13 +140,6 @@ NXapm_paraprobe_results_ranger: exists: recommended charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): - charged_ION(NXion): - exists: [min, 1, max, 256] - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - exists: recommended - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): iontypes(NX_UINT): doc: | The iontype ID for each ion that was best matching, stored in the @@ -161,33 +153,6 @@ NXapm_paraprobe_results_ranger: dimensions: rank: 1 dim: [[1, n_ions]] - charged_iontypes(NX_UINT): - doc: | - The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. For the here computed - charged_iontypes the information for each (molecular) ion defined - in e.g. RNG or RRNG files is analyzed for which differently charge - states are possible. As an example while iontypes might only consider - if an ion is Al charged_iontypes will resolve if it is Al1+, Al2+, or - Al3+. To decide the charge state a recursive algorithm is used which - enumerates first all possible isotopic variants of a given molecular - ion build from a specific set of elements. All variants are then - analyzed for their natural abundance and filtered. The sub-set of - all significantly abundant variants is inspected if their charge - states are all the same. If only one significant variant is found - its charge state is assumed the relevant. If multiple significant - variants are found and all their charge states is the same this - charge state will be the decisive one. However, if multiple variants - are found and their charge state differs such a case highlights that - the charge state analysis is underconstrained and thus the charge - state is set to 0. Underconstrained cases are possible because - an arbitrary combination of elements into a molecular ion that is - constrained only by an additional single interval of mass-to-charge - state ratios is not necessarily sufficient. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_ions]] window(NXcs_filter_boolean_mask): doc: | A bitmask which identifies exactly all those ions ranged irrespective diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml index 13c0ba85ff..a124718b91 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml @@ -31,7 +31,6 @@ NXapm_paraprobe_results_selector: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -56,7 +55,7 @@ NXapm_paraprobe_results_selector: doc: | At least SHA256 strong hash of the specific config_file for tracking provenance. - status(NX_CHAR): + status: doc: | A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml index 827673d547..eb8cc2c843 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml @@ -31,7 +31,6 @@ NXapm_paraprobe_results_spatstat: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -62,7 +61,7 @@ NXapm_paraprobe_results_spatstat: Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status(NX_CHAR): + status: doc: | A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -180,8 +179,14 @@ NXapm_paraprobe_results_spatstat: dimensions: rank: 1 dim: [[1, i]] - accumulated(NX_FLOAT): + cumulated(NX_FLOAT): doc: Cumulated + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + cumulated_normalized(NX_FLOAT): + doc: Cumulated and normalized by total counts unit: NX_DIMENSIONLESS dimensions: rank: 1 @@ -202,8 +207,14 @@ NXapm_paraprobe_results_spatstat: dimensions: rank: 1 dim: [[1, i]] - accumulated(NX_FLOAT): + cumulated(NX_FLOAT): doc: Cumulated + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + cumulated_normalized(NX_FLOAT): + doc: Cumulated and normalized by total counts unit: NX_DIMENSIONLESS dimensions: rank: 1 diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml index 562d7ae9b2..0e6bac09aa 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml @@ -36,7 +36,6 @@ NXapm_paraprobe_results_surfacer: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -67,7 +66,7 @@ NXapm_paraprobe_results_surfacer: Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status(NX_CHAR): + status: doc: | A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -227,10 +226,10 @@ NXapm_paraprobe_results_surfacer: which discretizes the exterior surface of the alpha complex. identifier_offset(NX_INT): doc: | - Integer which specifies the first index to be used for distin- - guishing triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined - on the interval [identifier_offset, identifier_offset+c-1]. + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. unit: NX_UNITLESS triangles(NXcg_face_list_data_structure): dimensionality(NX_POSINT): @@ -294,6 +293,7 @@ NXapm_paraprobe_results_surfacer: The accumulated volume of all interior tetrahedra. unit: NX_VOLUME tetrahedra(NXcg_face_list_data_structure): + exists: optional number_of_vertices(NX_POSINT): doc: Number of vertices. unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml index 7b0dc27fff..e1cd0f4357 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml @@ -32,7 +32,6 @@ NXapm_paraprobe_results_tessellator: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -63,7 +62,7 @@ NXapm_paraprobe_results_tessellator: Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status(NX_CHAR): + status: doc: | A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -163,7 +162,7 @@ NXapm_paraprobe_results_tessellator: A bitmask which identifies which of points have Voronoi cells that are truncated by the global axis-aligned bounding box, i.e. boundaries of the threads are ignored. - number_of_points(NX_UINT): + number_of_ions(NX_UINT): doc: | Number of points covered by the mask. The mask value for most may be 0. @@ -197,7 +196,7 @@ NXapm_paraprobe_results_tessellator: are truncated by a specific wall of the axis-aligned bounding box. The left wall has the negative x axis of the paraprobe coordinate system as the outer unit normal. - number_of_points(NX_UINT): + number_of_ions(NX_UINT): doc: | Number of points covered by the mask. The mask value for most may be 0. @@ -230,7 +229,7 @@ NXapm_paraprobe_results_tessellator: are truncated by a specific wall of the axis-aligned bounding box. The right wall has the positive x axis of the paraprobe coordinate system as the outer unit normal. - number_of_points(NX_UINT): + number_of_ions(NX_UINT): doc: | Number of points covered by the mask. The mask value for most may be 0. @@ -263,7 +262,7 @@ NXapm_paraprobe_results_tessellator: are truncated by a specific wall of the axis-aligned bounding box. The front wall has the negative y axis of the paraprobe coordinate system as the outer unit normal. - number_of_points(NX_UINT): + number_of_ions(NX_UINT): doc: | Number of points covered by the mask. The mask value for most may be 0. @@ -296,7 +295,7 @@ NXapm_paraprobe_results_tessellator: are truncated by a specific wall of the axis-aligned bounding box. The rear wall has the positive y axis of the paraprobe coordinate system as the outer unit normal. - number_of_points(NX_UINT): + number_of_ions(NX_UINT): doc: | Number of points covered by the mask. The mask value for most may be 0. @@ -330,7 +329,7 @@ NXapm_paraprobe_results_tessellator: are truncated by a specific wall of the axis-aligned bounding box. The left wall has the negative z axis of the paraprobe coordinate system as the outer unit normal. - number_of_points(NX_UINT): + number_of_ions(NX_UINT): doc: | Number of points covered by the mask. The mask value for most may be 0. @@ -364,7 +363,7 @@ NXapm_paraprobe_results_tessellator: are truncated by a specific wall of the axis-aligned bounding box. The left wall has the positive z axis of the paraprobe coordinate system as the outer unit normal. - number_of_points(NX_UINT): + number_of_ions(NX_UINT): doc: | Number of points covered by the mask. The mask value for most may be 0. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml index a83752945c..b06708b8d9 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml @@ -9,6 +9,8 @@ symbols: Needs to match maximum_number_of_atoms_per_molecular_ion. n_ranges: Number of mass-to-charge-state-ratio intervals mapped on this ion type. n_topology: Total number of integers in the supplementary XDMF topology array. + n_combinatorics: Number of ions probed in the combinatorial analysis of the charge states +# be careful n_comb can vary for every instance of (NXion) ! NXapm_paraprobe_results_transcoder: (NXentry): # by default for appdefs the value of the exists keyword is required @@ -35,7 +37,6 @@ NXapm_paraprobe_results_transcoder: ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. analysis_identifier: - exists: optional doc: | Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -66,7 +67,7 @@ NXapm_paraprobe_results_transcoder: Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status(NX_CHAR): + status: doc: | A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -332,6 +333,73 @@ NXapm_paraprobe_results_transcoder: exists: recommended charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): + charge_model(NXprocess): + doc: | + Details and results of the combinatorial analyses of this + range definition to identify the charge_state for an ion. + charge_vector(NX_UINT): + doc: | + Currently charge_state not charge! + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_combinatorics]] + isotope_matrix(NX_UINT): + doc: | + Specific isotopes building each candidate matching the range. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_combinatorics], [2, n_ivec_max]] + mass_vector(NX_FLOAT): + doc: | + Accumulated mass of the isotopes in each candidate. + Not corrected for quantum effects. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_combinatorics]] + # min_abundance(NX_FLOAT): + # doc: | + # Minimum natural abundance + # unit: NX_DIMENSIONLESS + natural_abundance_product_vector(NX_FLOAT): + doc: | + Product of natural abundance of the isotopes per candidate. + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_combinatorics]] + min_abundance_product(NX_FLOAT): + doc: | + Filter criterion on the product of the natural abundances + computed from each isotope building the (molecular) ion. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + unit: NX_DIMENSIONLESS + min_half_life(NX_FLOAT): + doc: | + Filter criterion on the minimum half life which all isotopes + building the (molecular) ion need to have to consider the + candidate. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + unit: NX_TIME + # NEW ISSUE: value can be the string infinity! + # min_half_life_vector(NX_FLOAT): + # doc: | + # Needs to be documented + # unit: NX_TIME + sacrifice_isotopic_uniqueness(NX_BOOLEAN): + doc: | + If the value is zero/false it means that non-unique solutions + are accepted. These are solutions where multiple candidates + differ in their isotopes but have the same charge. + # add further fields coming from using the charge state recovery # workflow from the ifes_apt_tc_data_modeling library # ##MK::end of the tool-specific section diff --git a/contributed_definitions/nyaml/NXcg_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml index a97fb0cda3..3a072e78c4 100644 --- a/contributed_definitions/nyaml/NXcg_grid.yaml +++ b/contributed_definitions/nyaml/NXcg_grid.yaml @@ -24,7 +24,8 @@ NXcg_grid: doc: The symmetry of the lattice defining the shape of the unit cell. enumeration: [cubic] cell_dimensions(NX_NUMBER): - doc: The unit cell dimensions using crystallographic notation. + doc: | + The unit cell dimensions using crystallographic notation. unit: NX_LENGTH dimensions: rank: 1 @@ -88,10 +89,14 @@ NXcg_grid: Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. unit: NX_UNITLESS - boundaries(NX_CHAR): + boundaries: doc: | - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. + Name of domain boundaries of the simulation box/ROI e.g. left, right, + front, back, bottom, top. + # The field must have as many entries as there are number_of_boundaries. + dimensions: + rank: 1 + dim: [[1, n_b]] boundary_conditions(NX_INT): doc: | The boundary conditions for each boundary: diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml index 04a12cc2e8..e136c2420a 100644 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml @@ -98,7 +98,7 @@ NXcg_half_edge_data_structure: dimensions: rank: 1 dim: [[1, n_he]] - weinberg_vector(NX_CHAR): + weinberg_vector: doc: | Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.yaml b/contributed_definitions/nyaml/NXcg_polyline_set.yaml index 8dcd9e426c..78d1dec642 100644 --- a/contributed_definitions/nyaml/NXcg_polyline_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polyline_set.yaml @@ -108,7 +108,7 @@ NXcg_polyline_set: so on and so forth. Using the (cumulated) counts in number_of_vertices, the vertices of the n-th polyline can be accessed on the following array index interval: - :math:`$[\sum_i = 0}^{i = N-1}, \sum_{i=0}^{i=N}]$`. + :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. unit: NX_UNITLESS dimensions: rank: 1 diff --git a/contributed_definitions/nyaml/NXchemical_composition.yaml b/contributed_definitions/nyaml/NXchemical_composition.yaml index 316db2aeae..ce334b02c6 100644 --- a/contributed_definitions/nyaml/NXchemical_composition.yaml +++ b/contributed_definitions/nyaml/NXchemical_composition.yaml @@ -6,7 +6,7 @@ symbols: n: The number of samples or things. NXchemical_composition: # molecule descriptor - # chemical_formula(NX_CHAR): + # chemical_formula: # doc: | # IUPAC chemical formula total(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXclustering.yaml b/contributed_definitions/nyaml/NXclustering.yaml index 73959a6e26..cbb0bd96c6 100644 --- a/contributed_definitions/nyaml/NXclustering.yaml +++ b/contributed_definitions/nyaml/NXclustering.yaml @@ -22,14 +22,14 @@ NXclustering: number_of_categorical_labels(NX_UINT): doc: How many categorical labels does each object have. unit: NX_UNITLESS - objects(NX_CHAR): + objects: doc: | Reference to a set of objects investigated in a cluster analysis. Objects must have clear integer identifier. numeric_label(NX_NUMBER): doc: | Reference to numeric attribute data for each object. - categorical_label(NX_CHAR): + categorical_label: doc: | Reference to categorical attribute data for each object. # list instances of base classes of an applied cluster algorithm diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 112eac1035..1f2d711ecf 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -2,17 +2,11 @@ category: base doc: | Corrector for aberrations in an electron microscope. - Different vendors use a different naming schemes for aberration coefficients. - It is the users responsibility to map to the best matching values. + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. - In transmission electron microscopes the spherical aberration corrector is - a component that is controlled via instructing the microscope to achieve - set point values. The corrector is composed of multiple lenses and other - parts with vendor-specific details which are often undisclosed. - - In the case of Nion Co. microscopes the coefficients of the corrector can be - retrieved via NionSwift, which is why currently the Nion convention for the - aberration coefficients is used. + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. NXcorrector_cs: applied(NX_BOOLEAN): doc: Was the corrector used? @@ -26,7 +20,34 @@ NXcorrector_cs: a free-text field to report further details about the corrector. # NEW ISSUE: clarify the mathematical details behind the # NEW ISSUE: following parameters of the these constants and how they are useful - (NXaberration): + ZEMLIN_TABLEAU(NXprocess): + doc: | + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + description: + doc: | + Discouraged free-text field to add further details about the alignment procedure. + tilt_angle(NX_FLOAT): + doc: | + The outer tilt angle of the beam in tableau aquisition. + unit: NX_ANGLE + exposure_time(NX_FLOAT): + doc: | + The exposure time of the single tilt images. + unit: NX_TIME + magnification(NX_NUMBER): + doc: | + The factor of enlargement of the apparent size, + not physical size, of an object. + unit: NX_DIMENSIONLESS + (NXprocess): + doc: | + Place for storing measured or estimated aberrations (for each image or final). + ceos(NXaberration_model_ceos): + nion(NXaberration_model_nion): + + # technical components of the corrector (NXlens_em): (NXtransformations): # NEW ISSUE: add the reference to the conversion table between diff --git a/contributed_definitions/nyaml/NXcs_profiling.yaml b/contributed_definitions/nyaml/NXcs_profiling.yaml index 3e6d431394..748ee5f950 100644 --- a/contributed_definitions/nyaml/NXcs_profiling.yaml +++ b/contributed_definitions/nyaml/NXcs_profiling.yaml @@ -47,7 +47,7 @@ NXcs_profiling: current_working_directory: doc: | Path to the directory from which the tool was called. - command_line_call(NX_CHAR): + command_line_call: doc: | Command line call with arguments if applicable. start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index 9411816950..b34479c5c6 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -5,7 +5,7 @@ doc: | # doc: The symbols used in the schema to specify e.g. variables. NXebeam_column: (NXfabrication): - electron_gun(NXsource): + electron_source(NXsource): doc: The source which creates the electron beam. name: doc: Given name/alias. diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index a43ca1fb0c..86e616c11a 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -1,67 +1,66 @@ category: application doc: | - Characterization and session with one sample in an electron microscope. + Characterization of a sample during a session on an electron microscope. **The idea and aim of NXem**: - Electron microscopy (EM), whether it be with scanning electron microscope (SEM) - or transmission electron microscope (TEM) instruments, are versatile tools for - preparing and characterizing samples and specimens. The term specimen is considered - a synonym for sample in this application definition. + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. A specimen is a physical portion of material that is studied/characterized during the microscope session, eventually in different places on the specimen surface, - illuminating either the surface layers or shining through thin specimens. + illuminating the surface layers or shining through thin specimens. These places are named regions of interest (ROIs). - Fundamentally, an EM is an electron accelerator. Experimentalists use an EM - in sessions during which they characterize as well as prepare specimens. - This application definition describes data and metadata about processes and - characterization tasks applied to one specimen. The application definition - focuses on the usage of EM in materials research. The application definition - design makes it in principle applicable also in cryo-EM on biomaterials. + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. - Multiple specimens have to be described with multiple NXentry instances. + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + **Electron microscopes motivate the development of an embracing data schema:** There are research groups who use an EM in a manner where it is exclusively operated by a single, instrument-responsible scientists or a team of scientists. These users may perform analyses for other users as a service task, especially in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process maybe even operating - the microscope. Oftentimes the scientists operate the instrument themselves - either on-site or remotely and can ask technicians for support. - In all cases, these people are considered users. Users might have different + cutting-edge instruments, the scientists guide the process maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different roles though. - The rational behind a common EM schema rather than making separate application - definitions for SEM or TEM are primarily the key similarities of SEM and TEM + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM instruments: Both type of instruments have electro-magnetic lenses. These may differ in design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is used mainly to measure the - transmitted electron beam. This calls for using a different lens setup and - relative placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to illuminate - through the specimen. This offers capabilities for probing of + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of additional physical mechanisms of electron-matter interaction which are unavailable in SEMs. - Compared to SEMs, TEMs have a different relative arrangement between the - lenses and the specimen which is most obvious by the different relative - arrangement of the objective lens versus the specimen. - Nevertheless, both types of electron microscopes use detector systems which measure different types of signals that originate from the same set of - radiation/specimen interactions. Consequently, detectors can also be similar - if not exactly the same. + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. - **An embracing schema instead of specific SEM or TEM schemes**: + **An embracing schema instead of specific SEM or TEM schemas**: Given these physical and technical differences, different instruments have been developed. This led to a coexistence of two broad interacting communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower - the addressed user base is which develops or uses schemes for research data - management (RDM) with EM, the more understandable it is that scientists of - either community (or sub-community) ask for method-specific schemes. + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. Researchers who have a single (main) microscope of some vendor in their lab, may argue they need an NXem_vendor_name schema or an NXem_microscope_name or @@ -70,29 +69,28 @@ doc: | (X-rays, electrons) may argue they wish to be pragmatic and store only what is immediately relevant for their particular technique and research questions. In effect, they may advocate for method-specific - schemes such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - However, the development in the past has shown that these activities led to - a zoo of schemes and especially vocabulary in use with implementations of these + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and especially vocabulary in use with implementations of these into many data and file formats. There is nothing which prevents the communities - to make these schemes open and interoperable. Open here means specifically not - that all data are compliant with/or use the schema and have to end up in the - open-source domain. There can be embargo periods first of all. + to make these schemas open and interoperable. Open here means not that all + data stored according to such schemas have to end up in the open-source domain. + There can be embargo periods first of all. Open means that the metadata and associated schemata are documented in a manner - that as many details as possible are open in the sense that others can understand + that as many details are open as possible in the sense that others can understand what the (meta)data mean conceptually. Instead of trying of maintain a zoo of eventually difficult to make interoperable formats and schema we would like to advocate that the `FAIR principles `_ should guide all decisions how data and metadata should be stored. EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different - schemes with associated representations of data and metadata in EM: - Each combination of schemes or an interoperable-made handshake between two - file formats or software packages has to be maintained by software developers. - This counts especially when data should be processed interoperably - between software packages. + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. This brings two problems: Many software tools and parsers for the handshaking between tools have to be maintained. This can result in usage of different @@ -102,53 +100,58 @@ doc: | `There are community efforts to harmonize the terminology. `_ **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemes and + A common vocabulary can serve interoperability as developers of schemas and scientists can reuse for instance these terms, thus supporting interoperability. Ideally, scientists specialize an application definition only for the few very specific additional quantities of their instruments and techniques. This is better than reimplementing the wheel for descriptions of EM instruments. This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemes. + removes the necessity for having to maintain a very large number of schemas. - Aiming for more standardization, i.e. a lower number of schemes rather than + Aiming for more standardization, i.e. a lower number of schemas rather than a single standard for electron microscopy is a compromise that can serve - academia as it enables the EM community to focus their software development - efforts on those schemes, on fixing and discussing them, and on harmonizing + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing their common vocabulary. These activities can be specifically relevant also - for vendors of EM hard- and software as it improves the longevity of certain - schema; and thus can help to incentivize vendors to support the community with - implementing support for such schemes into their proprietary applications. + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. In effect, everybody can gain from this as it will likely reduce the cases in which scientists have to fix bugs in making their own tools compliant and interoperable with tools of their colleagues and the wider community. The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemes for EM research. + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + Working towards a common vocabulary is a community activity that profits from everybody reflecting in detail whether certain terms they have used in the past are not eventually conceptually similar if not the same as what this application definition and its base classes provide. We are happy for receiving your feedback. **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemes differ + It is noteworthy to understand that (not only for NeXus), schemas differ already if at least one field is required in one version of the schema, but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemes can + attributes are removed or added, or even a docstring is changed, schemas can become inconsistent. It is noteworthy to mention that the idea of a NeXus application definition serves as a contract between a data provider and a data consumer. - Providers can be software from specific microscopes or users with specific + Providers can be the software of a specific microscopes or users with specific analysis needs. Consumers can be again specific software tools, like vendor software for controlling the instrument or a scientific software for doing artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions and strictly speaking an application definition can only be - really general if it does not make a single entry required, in which case however - it would also not offer much value as even empty datasets would be compliant. + to new versions. Strictly speaking an application definition can only be + fully general if it does not make a single entry required, in which case however + it would also not offer much value as even empty datasets would be compliant + with such a schema. **Verification of constraints and conditions**: Tools like NeXus so far do not avoid or protect against all such possible inconsistencies; however NeXus offers a mechanism and toolset, through which - schemes can be documented and defined. In effect, having an openly documented + schemas can be documented and defined. In effect, having an openly documented (at a case-specific level of technical detail) schema is a necessary but alone not a sufficient step to take EM research on a route of machine-actionable and interoperable FAIR data. @@ -159,17 +162,17 @@ doc: | requirements are formulated in the docstrings of the respective entries of the application definition. - This application definition takes a key step towards standardization of EM data. - It offers a controlled vocabulary and relation between concepts and data - relevant for research with electron microscopes. To be most efficient and - offering reusability, the application definition should be understood as a - template that one should ideally use as is. This application definition - is called NXem. NXem can be considered a base for designing more specialized - definitions (ideally prefixed with NXem) *method*. + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but make - them optional or, even better, propose changes in this NXem application definition. + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. A particular challenge with electron microscopes as physical instruments are their dynamics. To make EM data understandable, repeatable, and eventually @@ -182,10 +185,11 @@ doc: | economical constraints on how completely EM research can be documented: For most commercial systems there is a specific accessibility beyond which detailed settings like lens excitations and low-level hardware settings - may not be retrievable as vendors also have a relevant interest in finding - a compromise between being open to their user and securing their business. + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. - EM experiments by design illuminate the specimen with electrons as a + By design, EM experiments illuminate the specimen with electrons as a consequence of which the specimen changes if not may get destroyed. As such, repeatability of numerical processing and clear descriptions of procedures and system setups should be addressed first. @@ -194,14 +198,16 @@ doc: | geometry of the lens system and its excitations during the course of the experiment, it is difficult to fully abstract the technical details of the hardware into a set of names for fields and groups that make for a compromise - between clarity but being vendor-agnostic at the same time. + between clarity but being system-agnostic at the same time. Settings of apertures are an example where aperture modes are in most cases aliases behind which there is a set of very detailed settings specific to the software and control units used. These settings are difficult to retrieve, - often undocumented in detail by vendors. This serves users and makes EM - experiments easier understandable and conveniently executable for a broad - user base. On the flipside these subtilities limit the opportunities for - making application definitions too general. + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. Instead, currently it is for the docstring to specify what is conceptually eventually behind such aliases. The design rule we followed while drafting @@ -222,12 +228,12 @@ doc: | aims and interest, while remaining at the same time approachable and executable by a large number of scientists in a community. However, we are also convinced that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemes. + of oftentimes strongly overlapping and redundant schemas. NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what are metadata in EM. While doing - so we found that existent terminology can be encoded into a more controlled - vocabulary. + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. We have concluded that despite all these details of current EM research with SEM, TEM, and focused-ion beam instruments, there a clearly identifiable @@ -245,7 +251,7 @@ doc: | * Each signal, such as a spectrum or image taken at the microscope, should have an associated time-zone-aware time stamp and report of the specific settings of the microscope at that point in time when the image was taken. - This is why instances of NXevent_data_em have an own em_lab section. + This is why instances of :ref:`NXevent_data_em` have an own em_lab section. The reason is that EMs can be highly dynamic, be used to illuminate the specimen differently or show drift during signal acquisition, to name but a few effects. What constitutes a single EM experiment/measurement? @@ -253,26 +259,27 @@ doc: | taking of a secondary electron image for fracture analysis, taking a set of EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a specimen in preparation for e.g. an atom probe experiment. - * NXmonitor; + * :ref:`NXmonitor`; instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. Alternatively, NXevent_data_em - instances can be used to store time-zone-aware dates of the components, which is + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is relevant for documenting as exactly as practically possible settings when images and spectra were taken. - * NXinstrument; + * :ref:`NXinstrument`; conceptually this is a container to store arbitrary level of detail of the technical components of the microscope as a device and the lab in which the microscope is operated. - * NXuser; + * :ref:`NXuser`; conceptually, this is a set with at least one NXuser instance which details who operated or performed the measurement. Additional NXusers can be referred to in an NXevent_data_em instance to store individualized details who executed an event of data acquisition or processing. - * NXevent_data_em instances as an NXevent_data_em_set; + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; each NXevent_data_em instance is a container to group specific details about the state of the microscope when a measurement was taken and relevant data and eventual processing steps were taken (on-the-fly). - * NXdata; at the top-level, conceptually, this is a place for documenting + * :ref:`NXdata`; at the top-level, conceptually, this is a place for documenting available default plottable data. A default plottable can be useful for research data management systems to show a visual representation of some aspect of the content of the EM session. @@ -282,33 +289,37 @@ doc: | somewhat of personal taste, and community standards. In effect, default plottables are case- and method-specific. - Usually a session at a microscope is used to collect multiple signals and - images. Examples for possible default plottables could be arbitrarily - taken secondary, back-scattered, electron image, diffraction pattern, - EELS spectra, composition, or orientation mappings to name but a few. + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. **There are a few design choices to consider with sub-ordinate groups:** - * Above images, spectra, and mappings should be stored as NXdata instances, - ideally formatted in such a way that they can be displayed with - visualization software that can be specific for the file format in which - the data are stored. NeXus specifies only the data model, i.e. the terms - and their relations. These descriptions can be implemented and stored in - JSON, HDF5, XML, or HSDS, file storage, or even other formats, although - HDF5 is often used. + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables to + display image and spectra with web technology visualization software. + NeXus specifies only the data model, i.e. the terms and their relations. + These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, + file storage, or even other formats, although HDF5 is often used. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional XDMF fields which support additional plotting of + the data with visualization software like Paraview or Blender. * Consumable results of EM characterization tasks are usually a sub-set of data artifacts, as there is not an infinite amount of possible electron/ion beam-specimen interactions. * Images of electron counts detected in specific operation modes (bright - field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) + field, dark field in TEM, secondary/back-scattered, Kikuchi). * Spectra (X-ray quanta or Auger electron counts) * These data are in virtually all cases a result of some numerical processing. - It makes sense to name these data and processing tasks with a controlled - vocabulary, e.g. SE (secondary electron), BSE (back-scattered electron), - Kikuchi, X-ray, Auger, Cathodolum(inescence) etc. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk). To this end the schema, here makes no + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. To this end the schema here makes no specific assumptions, not even that all the fields/group of a schema instance have to be stored at all into a single file. Instead, the schema specifies the relations between metadata, some of the constraints and conditions on how the @@ -317,6 +328,23 @@ doc: | In effect, the application definition is a graph which describes how numerical data and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. # While an important # step this will still need in the future a mechains # So far Essentially when the docstrings are no longer needed @@ -351,8 +379,8 @@ NXem: Ideally, a (globally) unique persistent identifier for referring to this experiment. - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. experiment_description: exists: optional @@ -372,49 +400,25 @@ NXem: for specifying when the experiment was performed - and the exact duration is not relevant - this start_time field should be used. - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping and + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and interpretation of the experiment. The user should be aware that even with having both time instances specified, it may not be possible to infer how long the experiment took or for how long data were acquired. More detailed timing data over the course of the experiment have to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_em instances to + advantage of individual time stamps in NXevent_data_em instances to provide additional pieces of information. end_time(NX_DATE_TIME): exists: recommended doc: | ISO 8601 time code with local time zone offset to UTC included when the microscope session ended. - program: - doc: | - Commercial or otherwise given name to the program which was used to - create the file. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual NXprocess - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - \@version: - doc: | - Program 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. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: experiment_documentation(NXnote): exists: optional doc: | @@ -550,7 +554,7 @@ NXem: Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Usually this should be a part of the sample history, i.e. the sample is imagined handed over - for analysis. At the point it enters the microscope the session starts. + for analysis. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as @@ -564,10 +568,10 @@ NXem: Possibility to give an abbreviation or alias of the specimen name field. atom_types: doc: | - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret @@ -602,10 +606,10 @@ NXem: (Measured) density of the specimen. For multi-layered specimens this field should only be used to describe the density of the excited volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an NXinteraction_vol_em for - individual NXevent_data_em instances can provide a much better description - of the relevant details why one would otherwise ask to store the density - of the specimen. + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. unit: NX_ANY # \@units: g/cm^3 description: @@ -635,17 +639,17 @@ NXem: The em_lab section contains a description of the instrument and its components. The component descriptions in this section differ from those inside individual - NXevent_em sections. These event instances take the role of time snapshot. - For an NXevent_em instance users should store only those settings for a + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a component which are relevant to understand the current state of the component. Here, current means at the point in time, i.e. the time interval, which the event represents. - For example it is not relevant to store in each event's electron_gun group - again the details of the gun type and manufacturer but only the high-voltage - if for that event the high-voltage was different. If for all events - the high-voltage was the same it is not even necessary to include an - electron_gun section in the event. + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. Individual sections of specific type should have the following names: @@ -676,6 +680,8 @@ NXem: exists: recommended capabilities: exists: optional + (NXchamber): + exists: optional (NXebeam_column): exists: [min, 1, max, 1] (NXfabrication): @@ -686,7 +692,9 @@ NXem: exists: recommended identifier: exists: recommended - electron_gun(NXsource): + (NXchamber): + exists: optional + electron_source(NXsource): name: exists: recommended (NXfabrication): @@ -748,34 +756,516 @@ NXem: exists: recommended identifier: exists: recommended - (NXaberration): + ZEMLIN_TABLEAU(NXprocess): exists: recommended - c_1_0(NX_FLOAT): - exists: recommended - c_1_2_a(NX_FLOAT): - exists: recommended - c_1_2_b(NX_FLOAT): - exists: recommended - c_2_1_a(NX_FLOAT): - exists: recommended - c_2_1_b(NX_FLOAT): - exists: recommended - c_2_3_a(NX_FLOAT): - exists: recommended - c_2_3_b(NX_FLOAT): - exists: recommended - c_3_0(NX_FLOAT): - exists: recommended - c_3_2_a(NX_FLOAT): - exists: recommended - c_3_2_b(NX_FLOAT): - exists: recommended - c_3_4_a(NX_FLOAT): - exists: recommended - c_3_4_b(NX_FLOAT): + description: + exists: optional + tilt_angle(NX_FLOAT): exists: recommended - c_5_0(NX_FLOAT): + unit: NX_ANGLE + exposure_time(NX_FLOAT): exists: recommended + unit: NX_TIME + magnification(NX_NUMBER): + exists: optional + unit: NX_DIMENSIONLESS + (NXprocess): + exists: [min, 0, max, infty] + ceos(NXaberration_model_ceos): + exists: optional + c_1(NXaberration): # Defocus + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_1(NXaberration): # Two-fold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + b_2(NXaberration): # Second-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_2(NXaberration): # Threefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + c_3(NXaberration): # Spherical aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + s_3(NXaberration): # Star aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_3(NXaberration): # Fourfold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + # based on feedback from Thilo Remmele the following aberrations could be measured + b_4(NXaberration): # Fourth-order axial coma + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + d_4(NXaberration): # Three-lobe aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_4(NXaberration): # Fivefold astigmatism + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + c_5(NXaberration): # Fifth-order spherical aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + s_5(NXaberration): # Fifth-order star aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + r_5(NXaberration): # Rosette aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_6(NXaberration): # Sixfold astigmatism + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + nion(NXaberration_model_nion): + exists: optional + c_1_0(NXaberration): # Defocus + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_1_2_a(NXaberration): # Two-fold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_1_2_b(NXaberration): # Two-fold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_1_a(NXaberration): # Second-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_1_b(NXaberration): # Second-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_3_a(NXaberration): # Threefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_3_b(NXaberration): # Threefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_0(NXaberration): # Spherical aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_2_a(NXaberration): # Star aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_2_b(NXaberration): # Star aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_4_a(NXaberration): # Fourfold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_4_b(NXaberration): # Fourfold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_1_a(NXaberration): # Fourth-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_1_b(NXaberration): # Fourth-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_3_a(NXaberration): # Three-lobe aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_3_b(NXaberration): # Three-lobe aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_5_a(NXaberration): # Fivefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_5_b(NXaberration): # Fivefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_0(NXaberration): # Fifth-order spherical aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_2_a(NXaberration): # Fifth-order star aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_2_b(NXaberration): # Fifth-order star aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_4_a(NXaberration): # Rosette aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_4_b(NXaberration): # Rosette aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_6_a(NXaberration): # Sixfold astigmatism + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_6_b(NXaberration): # Sixfold astigmatism + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME (NXibeam_column): exists: [min, 0, max, 2] (NXfabrication): @@ -786,7 +1276,9 @@ NXem: exists: recommended identifier: exists: recommended - ion_gun(NXsource): + (NXchamber): + exists: optional + ion_source(NXsource): name: exists: recommended (NXfabrication): @@ -833,7 +1325,7 @@ NXem: exists: recommended value(NX_NUMBER): exists: recommended - ebeam_deflector(NXscanbox_em): + EBEAM_DEFLECTOR(NXscanbox_em): exists: [min, 0, max, infty] (NXfabrication): exists: recommended @@ -845,7 +1337,7 @@ NXem: exists: recommended pixel_time(NX_FLOAT): exists: recommended - ibeam_deflector(NXscanbox_em): + IBEAM_DEFLECTOR(NXscanbox_em): exists: [min, 0, max, infty] (NXfabrication): exists: recommended @@ -886,9 +1378,11 @@ NXem: Electron microscopes have typically multiple detectors. Different technologies are in use like CCD, scintillator, direct electron, CMOS, or image plate to name but a few. - type: - doc: Free text option to write further details about the detector. + local_name: (NXfabrication): + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use exists: recommended identifier: exists: recommended @@ -928,41 +1422,74 @@ NXem: # this would enable to use nxs file also for instrument inventory # system like offer through ELNs/or LIMS doc: | - A container to structure a set of NXevent_data_em instances. + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. - An event is a time point/time interval during which the microscope - was configured in a specific way and the microscope was used - to take a measurement. The microscope is considered stable during this - interval. + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. - Each NXevent_data_em instance holds an acquisition task with the microscope. - For instance the capturing of a secondary electron, backscattered - electron, diffraction image, or spectrum. + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. An NXevent_data_em instance holds specific details about how raw data from - a detector were processed into consumable data like images, spectra, - etc. These on-the-fly data processing tasks are usually performed - by the control software, eventually realized with custom scripts. + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. - Furthermore, NXevent_dat_em instances can document specific values - and settings of the microscope during the snapshot/event. + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. (NXevent_data_em): exists: [min, 1, max, infty] doc: | A container holding a specific result of the measurement and eventually metadata how that result was obtained numerically. - NXevent_em instances can hold several specific - NXimage_em or NXspectrum_em instances taken and considered as - one event, i.e. a point in time when the microscope had the - settings specified either in NXinstrument or in this NXevent_data_em - instance. + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. - The application definition is designed without an explicit need - an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. An NXevent_data_em can be used to document a - specific state of the microscope at a time without having it placed - into the NXinstrument group. + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. In other words the NXinstrument group details primarily the more static settings and components of the microscope as they are found @@ -971,19 +1498,22 @@ NXem: It is not necessary to store data in NXebeam, NXibeam instances of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of microscope session + were constant over the entire course of the microscope session and thus all relevant metadata inside the NXinstrument groups are sufficient to understand the session. - So far there is no vendor-overarching standard according to which - electron microscope data are documented and stored. Therefore, it is - still a frequently the case that vendor-specific files have many fields - that cannot be safely mapped. Therefore, users are always adviced to - keep the vendor files. Working however with these vendor files inside - specific software, like materials databases, demands for parsers which - extract pieces of information from the vendor representation (numerical - data and metadata) and map them on a schema with which the database - and its associated software tools can work with. + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. Currently, one would loose immediately track of e.g. provenance and the origin of certain data in NXevent_data_em instances unless really @@ -991,29 +1521,31 @@ NXem: schema. Currently, though, this is sadly effectively prevented in many cases as vendors indeed implemented often sophisticated provenance and commercial software state tracking tools but these are not yet - documented dynamically, coveringly enough in our opinion so that it is - safe to assume all vendor field names are known, logically understood, - interpretable, and thus mappable on a common schema using a controlled - common vocabulary. + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. - Therefore we encourage user for now to store for each image_set_em - or spectra_set_em instance to supply the so-called source of the data. + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. This can for instance be the name and hashvalue of the original file which was acquired during the microscope session and from which then - certain like numerical data and metadata were copied into an instance - of this schema for the purpose of working with the data in e.g. tools - offered by the materials database. + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. - During work on implementing file format/metadata parsers and developing - this application definition we realized that several software tools - currently do not consistently track time-zone-aware timestamps of - events associated with the data, processing, and during the microscope - session. This is in partly a consequence of vendor which store - detailed time data in different formats. We would like to encourage the - community and especially the vendors to work towards a standardization, - or at least a open documentation of the way how time-zone-aware time - data are collected and stored how and where during a microscope session - and how they end up in files and databases with which users interact. + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. This would enable to supplement instances of this schema with specific time data and assure that these time data can be used to reliably contextualize individual datasets and processing steps in materials @@ -1031,29 +1563,27 @@ NXem: exists: recommended event_identifier: exists: recommended - doc: | - Reference to a specific state and setting of the microscope components. event_type: exists: recommended - detector_identifier: - exists: recommended - doc: | - The detector or set of detectors that was used to collect this signal. - The name of the detector has to match one of the names of available - NXdetector instances e.g. if the instrument has an ebsd_camera - the detector for an NXimage_em_kikuchi should be the NXdetector - instance called ebsd_camera. # a collection of images take and group under this event # NEW ISSUE: should this only be one instance for a given event? - (NXimage_set_em): + IMAGE_SET(NXimage_set): exists: optional (NXprocess): + source: + \@version: mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: [min, 0, max, infty] + program: + \@version: stack(NXdata): + exists: recommended \@signal: \@axes: \@AXISNAME_indices: - # \@long_name: title: data_counts(NX_NUMBER): \@long_name: @@ -1075,15 +1605,90 @@ NXem: # dimensions: # rank: 1 # dim: [[1, n_x]] - (NXimage_set_em_adf): + SPECTRUM_SET(NXspectrum_set): exists: optional (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: [min, 0, max, infty] + program: + \@version: + stack(NXdata): + exists: recommended + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, n_energy]] + \@long_name: + # \@signal: counts + # \@axes: [ypos, xpos, energy] + # \@ypos_indices: 0 + # \@xpos_indices: 1 + # \@energy_indices: 2 + axis_y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + axis_x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + axis_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + summary(NXdata): + exists: recommended + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + # \@signal: counts + # \@axes: [energy] + # \@energy_indices: 0 + axis_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + adf(NXimage_set): + exists: optional + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: [min, 0, max, infty] + program: + \@version: + inner_half_angle(NX_FLOAT): + exists: recommended + doc: | + Annulus inner half angle + unit: NX_ANGLE + outer_half_angle(NX_FLOAT): exists: recommended - adf_inner_half_angle(NX_FLOAT): - exists: recommended # should be required - adf_outer_half_angle(NX_FLOAT): - exists: recommended # should be required + doc: | + Annulus outer half angle + unit: NX_ANGLE stack(NXdata): + exists: recommended \@signal: \@axes: \@AXISNAME_indices: @@ -1106,9 +1711,18 @@ NXem: # dimensions: # rank: 1 # dim: [[1, n_x]] - (NXspectrum_set_em_xray): + xray(NXspectrum_set): exists: optional - # there should also be more NXprocess instances + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: [min, 0, max, infty] + program: + \@version: stack(NXdata): \@signal: \@axes: @@ -1151,6 +1765,7 @@ NXem: # dimensions: # rank: 1 # dim: [[1, n_photon_energy]] + # NEW ISSUE: all of this should be offloaded to NXem_edx --> indexing(NXprocess): exists: optional # ##MK:: much content of the base class has not been added although @@ -1178,9 +1793,19 @@ NXem: # dimensions: # rank: 1 # dim: [[1, n_x]] - (NXspectrum_set_em_eels): + # NEW ISSUE: all of this should be offloaded to NXem_edx --> + eels(NXspectrum_set): exists: optional - # there should be more NXprocess instances + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: [min, 0, max, infty] + program: + \@version: stack(NXdata): \@signal: \@axes: @@ -1224,9 +1849,20 @@ NXem: # dim: [[1, n_energy_loss]] \@long_name: # base classes for which we have at the moment no example implemented - # consider to replace se, bse, bf, df, chamber, ronchigram, by generic NXimage_set_em - (NXimage_set_em_kikuchi): + # consider to replace se, bse, bf, df, chamber, ronchigram, by generic NXimage_set + # NEW ISSUE: all of this should be offloaded to NXem_eels --> + kikuchi(NXimage_set): exists: optional + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: [min, 0, max, infty] + program: + \@version: stack(NXdata): \@signal: \@axes: @@ -1260,33 +1896,36 @@ NXem: # dim: [[1, n_p]] # no summary because this will be handled by EBSD - - (NXimage_set_em_se): - exists: optional - (NXimage_set_em_bse): - exists: optional - (NXimage_set_em_bf): - exists: optional - (NXimage_set_em_df): - exists: optional - (NXspectrum_set_em_auger): - exists: optional - (NXspectrum_set_em_cathodolum): - exists: optional - (NXimage_set_em_ecci): - exists: optional - (NXimage_set_em_diffrac): - exists: optional - (NXimage_set_em_ronchigram): - exists: optional - (NXimage_set_em_chamber): - exists: optional + # (NXimage_set_em_se): + # exists: optional + # (NXimage_set_em_bse): + # exists: optional + # (NXimage_set_em_bf): + # exists: optional + # (NXimage_set_em_df): + # exists: optional + # (NXspectrum_set_em_auger): + # exists: optional + # (NXspectrum_set_em_cathodolum): + # exists: optional + # (NXimage_set_em_ecci): + # exists: optional + # (NXimage_set_em_diffrac): + # exists: optional + # (NXimage_set_em_ronchigram): + # exists: optional + # (NXimage_set_em_chamber): + # exists: optional # a collection of specific details about state of the microscope em_lab(NXinstrument): exists: optional + (NXchamber): + exists: optional (NXebeam_column): exists: [min, 0, max, 1] - electron_gun(NXsource): + (NXchamber): + exists: optional + electron_source(NXsource): exists: optional voltage(NX_FLOAT): (NXaperture_em): @@ -1301,39 +1940,533 @@ NXem: value(NX_NUMBER): exists: recommended aberration_correction(NXcorrector_cs): - exists: optional - applied: - (NXaberration): + exists: recommended + applied(NX_BOOLEAN): + name: + exists: optional + (NXfabrication): exists: recommended - c_1_0(NX_FLOAT): - exists: recommended - c_1_2_a(NX_FLOAT): - exists: recommended - c_1_2_b(NX_FLOAT): - exists: recommended - c_2_1_a(NX_FLOAT): - exists: recommended - c_2_1_b(NX_FLOAT): - exists: recommended - c_2_3_a(NX_FLOAT): - exists: recommended - c_2_3_b(NX_FLOAT): - exists: recommended - c_3_0(NX_FLOAT): + vendor: exists: recommended - c_3_2_a(NX_FLOAT): + model: exists: recommended - c_3_2_b(NX_FLOAT): + identifier: exists: recommended - c_3_4_a(NX_FLOAT): - exists: recommended - c_3_4_b(NX_FLOAT): + ZEMLIN_TABLEAU(NXprocess): + exists: recommended + description: + exists: optional + tilt_angle(NX_FLOAT): exists: recommended - c_5_0(NX_FLOAT): + unit: NX_ANGLE + exposure_time(NX_FLOAT): exists: recommended + unit: NX_TIME + magnification(NX_NUMBER): + exists: optional + unit: NX_DIMENSIONLESS + (NXprocess): + exists: [min, 0, max, infty] + ceos(NXaberration_model_ceos): + exists: optional + c_1(NXaberration): # Defocus + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_1(NXaberration): # Two-fold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + b_2(NXaberration): # Second-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_2(NXaberration): # Threefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + c_3(NXaberration): # Spherical aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + s_3(NXaberration): # Star aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_3(NXaberration): # Fourfold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + # based on feedback from Thilo Remmele the following aberrations could be measured + b_4(NXaberration): # Fourth-order axial coma + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + d_4(NXaberration): # Three-lobe aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_4(NXaberration): # Fivefold astigmatism + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + c_5(NXaberration): # Fifth-order spherical aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + s_5(NXaberration): # Fifth-order star aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + r_5(NXaberration): # Rosette aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_6(NXaberration): # Sixfold astigmatism + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + nion(NXaberration_model_nion): + exists: optional + c_1_0(NXaberration): # Defocus + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_1_2_a(NXaberration): # Two-fold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_1_2_b(NXaberration): # Two-fold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_1_a(NXaberration): # Second-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_1_b(NXaberration): # Second-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_3_a(NXaberration): # Threefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_3_b(NXaberration): # Threefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_0(NXaberration): # Spherical aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_2_a(NXaberration): # Star aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_2_b(NXaberration): # Star aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_4_a(NXaberration): # Fourfold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_4_b(NXaberration): # Fourfold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_1_a(NXaberration): # Fourth-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_1_b(NXaberration): # Fourth-order axial coma + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_3_a(NXaberration): # Three-lobe aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_3_b(NXaberration): # Three-lobe aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_5_a(NXaberration): # Fivefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_5_b(NXaberration): # Fivefold astigmatism + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_0(NXaberration): # Fifth-order spherical aberration + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_2_a(NXaberration): # Fifth-order star aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_2_b(NXaberration): # Fifth-order star aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_4_a(NXaberration): # Rosette aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_4_b(NXaberration): # Rosette aberration + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_6_a(NXaberration): # Sixfold astigmatism + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_6_b(NXaberration): # Sixfold astigmatism + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME (NXibeam_column): exists: [min, 0, max, 2] - ion_gun(NXsource): + (NXchamber): + exists: optional + ion_source(NXsource): exists: optional probe(NXion): exists: recommended @@ -1365,6 +2498,7 @@ NXem: exists: recommended ibeam_deflector(NXscanbox_em): exists: optional + # NEW ISSUE: how to handle situations where we wish to describe multiple deflectors? (NXoptical_system_em): exists: optional camera_length(NX_NUMBER): @@ -1397,7 +2531,6 @@ NXem: tilt_2(NX_FLOAT): exists: recommended (NXuser): - exists: optional + exists: [min, 0, max, infty] name: - (NXinteraction_vol_em): - exists: optional + diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml index d019254150..b66e01b8f3 100644 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -8,9 +8,9 @@ doc: | can be collected. Users may wish to take only a single scan or image and complete their microscope session; however - frequently users are much longer at the microscope, recalibrate and take + frequently users are working much longer at the microscope, recalibrate and take multiple data items (scans, images, spectra). Each item comes with own detector - and on-the-fly processing settings and calibrations. + and eventually on-the-fly processing settings and calibrations. For the single data item use case one may argue that the need for an additional grouping is redundant. Instead, the metadata could equally be stored inside @@ -20,7 +20,7 @@ doc: | In fact, oftentimes scientists feel that there is a need to store details about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations caused or apertures used. + or record changes to the lens excitations or apertures used and/or changed. Although current microscopes are usually equipped with stabilization systems for many of the individual components, it can still be useful to store time-dependent data in detail. @@ -29,13 +29,13 @@ doc: | storing time-dependent data, is that over the course of a session one may reconfigure the microscope. What is a reconfiguration? This could be the change of an aperture mode because a scientist may first collect an image - with some aperture and then choose a different value. As the aperture affects - the electron beam it will affect the system. + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. Let aside for a moment the technology and business models, an EM could be monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of objects, - and eventually (externally) applied stimuli and positioning of the specimen. + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. Some snapshot or integrated data from this stream are relevant for understanding signal genesis and electron/ion-beam-sample interaction (paths). In such a generic @@ -43,18 +43,23 @@ doc: | in time when specific measurements are taken (spectra collected, images taken, diffraction images indexed on-the-fly). - Theoretically, an instrument and specimen should be considered as dynamic. + Therefore, both the instrument and specimen should always be considered as dynamic. Scientists often report or feel (difficult to quantify) observations that microscopes *perform differently* across sessions, without sometimes being able to identify clear root causes. Users of the instrument may consider such conditions impractical, or *too poor* and thus either abort their session or try to bring the microscope first into a state where conditions are considered - stable and of high enough quality to reuse data collection. - - In all these cases it is practical to store time-dependent data of the - instrument state not in the respective instrument component groups - of the top-level NXinstrument but in a sort of a log of event data. - This is the idea behind the NXevent_data_em snapshot containers. + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. Ideally, NXevent_data_em are equipped with a start_time and end_time to represent a time interval (remind the idea of the instrument state stream) @@ -65,18 +70,20 @@ doc: | microscope is stable enough. Take for instance the acquisition of an image or spectra stack. It is not fully possible (technically) to avoid that even within a single image instabilities of the beam are faced and drift occurs. - But does this warrant to document the microscope state at an even finer - and impractical in-between one collects signal time intervals? + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? - This is a question of how finely does one granularize pieces of information. + This is a question of how one wishes to granularize pieces of information. A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and illuminates a portion of the material, i.e. - the interaction volume, whose signal contributions are then counted by the - detector(s) as per pixel- or per voxel signal in the region-of-interest. - In principle this application definition allows for such doing so. - However, in most cases such a fine granularization would demand the collection - of data which are as of now hardly retrievable with commercial instruments - nor of primary interest. + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. A frequently made choice, mainly for convenience, is that drift and scan distortions are considered a feature or inaccuracy of the image and/or spectrum and thus @@ -87,9 +94,11 @@ doc: | single position measurements as the smallest granularization level. Which eventually may require to add optional NXprocess instances for respectively collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. Which warrant an own - consideration in the future. A more detailed overview of such computational - steps to cope with scan distortions is available in the literature: + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: * `C. Ophus et al. `_ * `B. Berkels et al. `_ @@ -105,9 +114,9 @@ doc: | customizations of the specific fields within NXevent_data_em instances. Another alternative could be to sample finer, eventually dissimilarly along - the time axis; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements - (i.e. images, spectra of scientific relevance). + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). In this case one should better go for a customized application definition with a functional property description inside members (fields or groups) @@ -123,8 +132,8 @@ doc: | Examples include cutting-edge experiments where the electron beam gets coupled/excited by e.g. lasers. In this case, the laser unit should be registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective groups of the NXinstrument though - inside instances of here detailed NXevent_data_em. + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. NXevent_data_em: start_time(NX_DATE_TIME): doc: | @@ -140,7 +149,7 @@ NXevent_data_em: when the snapshot time interval ended. event_identifier: doc: | - Reference to a specific state and setting of the microscope components. + Reference to a specific state and setting of the microscope. event_type: doc: | Which specific event/measurement type. Examples are: @@ -160,51 +169,27 @@ NXevent_data_em: * Ronchigram, image, alignment utility specifically in TEM * Chamber, e.g. TV camera inside the chamber, education purposes. - detector_identifier: - doc: | - The detector or set of detectors that was used to collect this signal. - The name of the detector has to match the names used for available - detectors, i.e. if the instrument has an *ebsd_camera* - named detector, instances of NXimage_em_kikuchi should use - *ebsd_camera* as the detector name. + This field may also be used for storing additional information about the event. + (NXimage_set): + (NXspectrum_set): + (NXinstrument): + (NXuser): + (NXinteraction_vol_em): # a collection of images take and group under this event # NEW ISSUE: should this only be one instance for a given event? - (NXimage_set_em_se): - (NXimage_set_em_bse): - (NXimage_set_em_ecci): - (NXimage_set_em_bf): - (NXimage_set_em_df): - (NXimage_set_em_adf): - (NXimage_set_em_kikuchi): - (NXimage_set_em_diffrac): - (NXspectrum_set_em_xray): - (NXspectrum_set_em_eels): - (NXspectrum_set_em_auger): - (NXspectrum_set_em_cathodolum): - (NXimage_set_em_ronchigram): - (NXimage_set_em_chamber): - # a collection of specific details about state of the microscope - em_lab(NXinstrument): - doc: | - A group where specific settings of the instrument during the - event can be captured. This is the preferred way to keep track of - different settings of the microscope during the session. - For instance, a user may first take an overview image with different - magnification and settings and then start a spectrum analyses. - These should be stored as two NXevent_data_em instances in an - application definition. Each storing the specific settings. - - NXfabrication relevant details should not be repeated because - we assume that the session is with the same microscope. - Namely, it is hopefully not happening that someone builds out a - component of the microscope while is taking a measurement with it. - For this reason the specialized NXinstrument here contains no - NXfabrication group. - (NXebeam_column): - (NXibeam_column): - ebeam_deflector(NXscanbox_em): - ibeam_deflector(NXscanbox_em): - (NXoptical_system_em): - (NXuser): - (NXinteraction_vol_em): - (NXprocess): + # (NXimage_set_em_se): + # (NXimage_set_em_bse): + # (NXimage_set_em_ecci): + # (NXimage_set_em_bf): + # (NXimage_set_em_df): + # (NXimage_set_em_adf): + # (NXimage_set_em_kikuchi): + # (NXimage_set_em_diffrac): + # (NXspectrum_set_em_xray): + # (NXspectrum_set_em_eels): + # (NXspectrum_set_em_auger): + # (NXspectrum_set_em_cathodolum): + # (NXimage_set_em_ronchigram): + # (NXimage_set_em_chamber): + # a collection of specific details about state of the microscope + diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.yaml b/contributed_definitions/nyaml/NXgraph_edge_set.yaml index 70c3dbf90c..fb3759ee00 100644 --- a/contributed_definitions/nyaml/NXgraph_edge_set.yaml +++ b/contributed_definitions/nyaml/NXgraph_edge_set.yaml @@ -55,14 +55,14 @@ NXgraph_edge_set: dimensions: rank: 2 dim: [[1, n_edges], [2, 2]] - is_a(NX_CHAR): + is_a: doc: | A human-readable qualifier which type or e.g. class instance the edge is an instance of. dimensions: rank: 1 dim: [[1, c]] - label(NX_CHAR): + label: doc: A human-readable label/caption/tag for the edge. dimensions: rank: 1 diff --git a/contributed_definitions/nyaml/NXgraph_node_set.yaml b/contributed_definitions/nyaml/NXgraph_node_set.yaml index de0d22bd99..3bb225aef9 100644 --- a/contributed_definitions/nyaml/NXgraph_node_set.yaml +++ b/contributed_definitions/nyaml/NXgraph_node_set.yaml @@ -29,7 +29,7 @@ NXgraph_node_set: dimensions: rank: 1 dim: [[1, c]] - is_a(NX_CHAR): + is_a: doc: | A human-readable qualifier which type or e.g. class instance the node is an instance of. As e.g. a NeXus application definition is a @@ -39,7 +39,7 @@ NXgraph_node_set: dimensions: rank: 1 dim: [[1, c]] - label(NX_CHAR): + label: doc: A human-readable label/caption/tag of the graph. dimensions: rank: 1 diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml index e67d30dafc..a904e1bb5f 100644 --- a/contributed_definitions/nyaml/NXibeam_column.yaml +++ b/contributed_definitions/nyaml/NXibeam_column.yaml @@ -26,7 +26,7 @@ doc: | # doc: The symbols used in the schema to specify e.g. variables. NXibeam_column: (NXfabrication): - ion_gun(NXsource): + ion_source(NXsource): doc: The source which creates the ion beam. name: doc: Given name/alias for the ion gun. diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml new file mode 100644 index 0000000000..ef8076480e --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set.yaml @@ -0,0 +1,60 @@ +category: base +doc: | + Container for reporting a set of images taken. +symbols: + n_images: Number of images in the stack. + n_y: Number of pixel per image in the slow direction. + n_x: Number of pixel per image in the fast direction. +NXimage_set: + (NXprocess): + doc: | + Details how images were processed from the detector readings. + source: + doc: | + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + mode: + doc: | + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + detector_identifier: + doc: | + Link or name of an NXdetector instance with which the data were collected. + (NXprogram): + stack(NXdata): + doc: | + Image (stack). + data_counts(NX_NUMBER): + doc: Image intensity values. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_images], [2, n_y], [3, n_x]] + axis_image_identifier(NX_UINT): + doc: Image identifier + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_images]] + \@long_name: + doc: Image identifier. + axis_y(NX_NUMBER): + doc: Pixel coordinate center of mass along y direction. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Coordinate along y direction. + axis_x(NX_NUMBER): + doc: Pixel coordinate center of mass along x direction. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml index e3641333c7..670bff238d 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/NXion.yaml @@ -9,6 +9,14 @@ symbols: n_ranges: | Number of mass-to-charge-state-ratio range intervals for ion type. NXion: + identifier: + doc: | + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + identifier_type: + doc: | + How can the identifier be resolved? + enumeration: [inchi] ion_type(NX_UINT): doc: | Ion type (ion species) identifier. The identifier zero @@ -29,25 +37,41 @@ NXion: For the rationale behind this `M. Kühbach et al. (2021) `_ unit: NX_UNITLESS dimensions: - rank: 1 - dim: [[1, n_ivecmax]] + rank: 2 + dim: [[1, 1], [2, n_ivecmax]] nuclid_list(NX_UINT): doc: | 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, 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 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 should be filled with zero. + 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. unit: NX_UNITLESS dimensions: rank: 2 dim: [[1, 2], [2, n_ivecmax]] + color: + doc: | + Color code used for visualizing such ions. + volume(NX_FLOAT): + doc: | + 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. + unit: NX_VOLUME + charge(NX_FLOAT): + doc: | + Charge of the ion. + unit: NX_CHARGE charge_state(NX_INT): doc: | Signed charge state of the ion in multiples of electron charge. @@ -67,7 +91,7 @@ NXion: 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 `_ - unit: NX_CHARGE + unit: NX_UNITLESS name: doc: | Human-readable ion type name (e.g. Al +++) @@ -75,14 +99,16 @@ NXion: 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, the - isotope_vector should be the preferred machine-readable format to use. + 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. mass_to_charge_range(NX_FLOAT): doc: | 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 labelled - as an ion of the here referred to ion_type. + (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. unit: NX_ANY # \@units: Da dimensions: diff --git a/contributed_definitions/nyaml/NXiv_temp.yaml b/contributed_definitions/nyaml/NXiv_temp.yaml index 8c6909a549..31125a4a08 100644 --- a/contributed_definitions/nyaml/NXiv_temp.yaml +++ b/contributed_definitions/nyaml/NXiv_temp.yaml @@ -14,7 +14,7 @@ symbols: category: application NXiv_temp(NXsensor_scan): (NXentry): - definition(NX_CHAR): + definition: enumeration: [NXiv_temp] (NXinstrument): (NXenvironment): diff --git a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml index 2c298d4dfb..f2e4f4f738 100644 --- a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml +++ b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml @@ -92,7 +92,7 @@ NXlab_electro_chemo_mechanical_preparation: doc: | Seconds unit: NX_TIME - removal(NX_CHAR): + removal: doc: | Qualitative statement how the material removal was characterized. enumeration: [undefined, estimated, measured] @@ -101,7 +101,7 @@ NXlab_electro_chemo_mechanical_preparation: How thick a layer was removed. unit: NX_LENGTH # time_history(NX_NUMBER): - SENSOR_SCAN(NXsensor_scan): + # SENSOR_SCAN(NXsensor_scan): # electro-chemical preparation is nothing but an I(V) curve within # a corrosive medium, eventually some wet lab steps have characteristics # of pure grinding, mechanical polishing, or a mixture with corrosive diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index b5482e9a9a..d8e0cc4e79 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -39,7 +39,7 @@ NXlens_em: 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. unit: NX_ANY - depends_on(NX_CHAR): + depends_on: doc: Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group. (NXtransformations): doc: | diff --git a/contributed_definitions/nyaml/NXms.yaml b/contributed_definitions/nyaml/NXms.yaml index c2a17fee6e..46c1807f98 100644 --- a/contributed_definitions/nyaml/NXms.yaml +++ b/contributed_definitions/nyaml/NXms.yaml @@ -1,28 +1,31 @@ -# Key difficulties: -# Several viewpoints are equally justified: Grains useful when there are crystallites with adjoining interfaces and -# none, or only some statistical populations of defects and/or some spatially-well defined defects, but if there are -# almost only defects like in a dislocation wall it might no longer be useful to define the grains as a well identifiable region whose majority volume -# shows long-range periodicity (so that defining an orientation makes) sense. Or should one better describe individual material points -# or atoms set of atoms forming a compact object with same grouping and same identifier? -# Lattice curvature, this is jargon with some truth in it but curvature has to be build from atom defects need to build the curvature -# average density, total, per character, per family, line length, curvature, jog, kink density, coarse-grainable structural motifs, atomic structure -# still all a models as thermal oscillations render that regions about a dislocation line segment oscillate change sub-nanometer arrangement frequently -# different scales relevant when coupling to specific mechanisms (e.g. phonons) +# key points to keep in mind when thinking about a general enough description for coarse-graining systems of atoms into +# so-called microstructural features of interest for which we may store also thermodynamic properties or other feature-specific descriptors +# several viewpoints how to coarse-grain are equally justified: grains are useful when there are crystallites with adjoining interfaces and # none, or only some statistical populations of defects and/or some spatially-well defined defects inside these +# however, if grains are build almost only from defects like dislocation walls, it might no longer be useful to define the grains +# as a well identifiable region whose majority volume shows long-range atomic periodicity (so that defining an orientation makes) sense. +# one could then rather describe the set of defects. Alternatively one could describe a material volume by sampling individual so-called +# material points (e.g. in continuum-scale plasticity models) or describe the material volume really from the atoms up +# but there are many terms used in materials engineering which people may want to distinguish which stand however between the scales e.g. +# lattice curvature, this is jargon with some truth in it but curvature has to be build from atoms and defects need to build the curvature +# dislocations are another good example where different research questions demand differently granularized descriptions e.g. +# average density, total line length, per character, per family, line length, curvature, jog, kink density, +# coarse-grainable structural motifs in the dislocation core, atomic structure +# also different scales one would like to distinguish as this is relevant when defects couple/show spatiotemporal correlations +# to specific mechanisms (e.g. phonons) or when defect affect the properties of other defects # ambiguous choices: is the grain boundary part of the grain or is it an own defect? # i.e. can/should we store grains as childs of their grain boundary set vs the interface the childs of the grains? -# ?? right now can couple gr has gB but if gr is specialized can it still have a gB -# a member of grain boundary -# Depending on use case a continuum of descriptors: is used mapping the meaning of terms can be as simple as employing logical -# relations crystallite is a synonym for grain versus a grain is described programmatically as the resulting cluster of atoms with constraint -# Length scale of homogeneity: -# In a multi-parameter space of all possible methods and effects and different external stimuli applied, simulations in computational materials science -# make sense when they focus on often very narrowly constrained effects and boundary conditions for which the simulation is formulated and useful. -# Data structures for multi-scale materials modeling IMM/ICME are diverse because they reflect these needs and specific main choices of what these simulation -# e.g. DFT (time, length-scale, which electronic effects) +# Depending on the use case we need to have a flexible description which can address a continuum of descriptors: +# important is that one can logically map different features +# Length scale of homogeneity: With the reality of a multi-parameter space of all possible methods and effects and +# different external stimuli applied for real materials, simulations in computational materials science typically focus +# their analysis on a few individual, spatiotemporally constrained effects and boundary conditions for which the simulation +# is formulated, useful, interpretable, and comparable to experiment. +# Data structures for multi-scale materials modeling IMM/ICME are currently diverse because they reflect the above-mentioned needs +# and different views which researchers have on their simulations e.g. DFT (time, length-scale, which electronic effects) # RVE annealing phenomena at the micrometer scale (pressure, temperature, length scale, interactions considered or not) # Some regions are well separated spatially (although it can be non-trivial to quantify the distance in a multi-dim parameter space) -# Some are overlapping (classical MD at the cutting edge with micrometer crystal plasticity microsecond and/or annealing at ns time scale) -# MD with classical vs abinitio-informed potential for studying evolution of mechanisms and phenomena at different length scale +# Some simulations are cross-scale (classical MD at the cutting edge with micrometer crystal plasticity microsecond and/or annealing at +# ns time scale) MD with classical vs abinitio-informed potential for studying evolution of mechanisms and phenomena at different length scales category: application doc: | Application definition, spatiotemporal characterization of a microstructure. @@ -32,7 +35,7 @@ symbols: n_b: | Number of boundaries of the bounding box or primitive to domain. n_p: | - Number of parameter required for chosen orientation parameterization. + Number of parameter required for the chosen orientation parameterization. c: | Number of texture components identified. NXms: # (NXannealing) @@ -80,12 +83,18 @@ NXms: # (NXannealing) doc: | Specify if the (characterization) results/data of this instance of an application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe a microstructure. + results of a post-processing of measured data to describe + a microstructure. + The term microstructure is used to describe the spatial arrangement of crystal defects inside a sample/specimen without demanding necessarily that this structure is mainly at the micron length scale. Nanostructure and macrostructure are close synonyms. Material architecture is a narrow synonym. + + Given that microstructure simulations nowadays more and more consider + the atomic arrangement, this application definition can also be used + to describe features at the scale of atoms. enumeration: [experiment, simulation] USER(NXuser): exists: [min, 0, max, infty] @@ -166,8 +175,8 @@ NXms: # (NXannealing) doc: | Container to hold different coordinate systems conventions. A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Using one NXtransformations - instance per base vector. + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. TRANSFORMATIONS(NXtransformations): exists: [min, 3, max, infty] @@ -196,9 +205,10 @@ NXms: # (NXannealing) ROI_SET(NXcg_roi_set): exists: [min, 1, max, infty] # usually a single domain covering the entire simulated or measured material volume - # however for solitary unit models aka volume element ensemble, replica methods we may need more than one domain - # the volume element is not called representative because for what we consider the volume element to be representative - # for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors + # however for solitary unit models (i.e. ensembles of volume elements/simulation domains) and for replica methods + # we may need more than one domain + # the volume element is not called representative because for what a volume element is representative is a matter of + # interpretation (fundamentally this is an assumption) and can differ for different descriptors doc: | The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -206,11 +216,12 @@ NXms: # (NXannealing) to contain details about the boundary conditions. grid(NXcg_grid): exists: optional - polyhedron_set(NXcg_polyhedron_set): - exists: optional + # specific application definitions can use these fields to specialize point_set(NXcg_point_set): # how to model either or case? exists: optional - boundary(NXcg_hexahedron_set): # how to model either or case? + polyhedron_set(NXcg_polyhedron_set): + exists: optional + boundary(NXcg_polyhedron_set): # how to model either or case? exists: optional doc: | A boundary to the volume element. @@ -283,12 +294,6 @@ NXms: # (NXannealing) exists: optional electric_field(NXprocess): exists: optional - recrystallization_kinetics(NXprocess): - exists: optional - grain_size_distribution(NXprocess): - exists: optional - recrystallization_front(NXprocess): - exists: optional # time-resolved results for individual snapshots # virtually all computer simulations and all experiments always probe @@ -321,44 +326,35 @@ NXms: # (NXannealing) # damage # thermal # composition - (NXms_atom_set): # positions, identifier - exists: optional + MS_FEATURE_SET(NXms_feature_set): + exists: [min, 0, max, infty] doc: | - Details about statistically or explicitly resolved - atoms in the entire domain. - # (NXms_grain_set): - # exists: optional - # doc: | - # Details about statistically or explicitly resolved - # interfaces between grains of - (NXms_dislocation_set): - exists: optional - doc: | - Details about statistically or explicitly resolved - dislocations in the entire domain. - (NXms_interface_set): - exists: optional - doc: | - Details about statistically or explicitly resolved - interfaces between crystals in the entire domain. - # (NXms_triple_line_set): - # exists: optional - # doc: | - # Details about statistically or explicitly resolved - # triple lines in the entire domain. - # (NXms_quadruple_junction_set): - # exists: optional - # doc: | - # Details about statistically or explicitly resolved - # quadruple junctions in the entire domain. - # (NXms_vacancy_set): - # exists: optional - # (NXms_solute_atom_set): - # exists: optional - # doc: | - # Details about explicitly resolved solute atoms - # in the entire domain. - + Conceptually distinguished object/feature in the ROI/ + system with some relevance. Instances of NXms_feature_set can + be nested to build a hierarchy of logically-related objects. + + A typical example for MD simulations is to have one + ms_feature_set for the atoms which is the parent to another + ms_feature_set for monomers/molecules/proteins which is then the + parent to another ms_feature_set for the secondary, another feature_set + for the tertiary, and the parent for another feature_set for the + quaternary structure. + + Another typical example from materials engineering is to have + one ms_feature_set for crystals (grains/phases) which serves as + the parent to another ms_feature_set for interfaces between these + crystals which then is the parent for another ms_feature_set to + describe the triple junctions which is then the parent for the + quadruple/higher-order junctions between which connect the + triple lines. + + Another example from discrete dislocation dynamics could be to + have one ms_feature_set for the dislocations (maybe separate + sets for each dislocation type or family) which are then + parents to other ms_feature_set which describe junctions between + dislocations or features along the dislocation line network. + # respective application definitions based on NXms should add and + # specialize odf(NXprocess): # (NXodf): exists: optional doc: | @@ -386,7 +382,7 @@ NXms: # (NXannealing) doc: | Reference to or definition of a coordinate system with which the definitions are interpretable. - parameterization(NX_CHAR): + parameterization: enumeration: [bunge-euler (ZXZ), quaternion] orientation(NX_NUMBER): doc: Parameterized orientations. @@ -394,7 +390,7 @@ NXms: # (NXannealing) dimensions: rank: 2 dim: [[1, c], [2, n_p]] - name(NX_CHAR): + name: doc: | Name of each texture component, e.g. Cube, Dillamore, Y. dimensions: diff --git a/contributed_definitions/nyaml/NXms_feature_set.yaml b/contributed_definitions/nyaml/NXms_feature_set.yaml new file mode 100644 index 0000000000..402d5e090e --- /dev/null +++ b/contributed_definitions/nyaml/NXms_feature_set.yaml @@ -0,0 +1,233 @@ +# NXms_feature_set can be used e.g. as groups inside instances of NXms_snapshot +# for an MD simulation each timestep is such snapshot all snapshot for a set +# which is the parent group that has all these NXms_snapshot instances as childs +# time_stamp: # simulated, physical +category: base +doc: | + Set of topological/spatial features in materials build from other features. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: Dimensionality + c: Cardinality/number of members/features in the feature set. + n_type_dict: | + Number of types in the dictionary of human-readable types of features. + n_parent_ids: | + Total number of parent identifier. +# Thea, Joseph, Lauri, Dinga (TJLD) just for comparison for each group and field to what this would map in their model for the MDTutorial 2 +NXms_feature_set: + # TJLD: this class represents a generalization of AtomGroups + # TJLD: one such for atoms(NXms_feature_set) + # TJLD: one such for atom_groups(NXms_feature_set) + # TJLD: but not one for every molecule, i.e. all molecules and how their atoms with ids are related to atoms ids is concatenated + # TJLD: clearly there are two possibilities: either concatenate or make one NXms_feature_set for each molecule or component in the topology hierarchy + # TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations + \@depends_on: + # TJLD: not required it is currently assumed that features are always build from atoms and this relation is shown using their ids, integers on [0, n_atoms-1] + doc: | + Name (or link?) to another NXms_feature_set which defines features what are + assumed as the parents/super_features of all members in this feature set. + If depends_on is set to "." or this attribute is not defined in an instance + of this application definition, assume that this feature_set instance + represents the root feature_set of the feature tree/graph. + + # the design of this base class makes it possible to have Joseph's suggestion + # but it has the additional benefit that as it defines the set one also + # bundle the description for all features at this hierarchy level into combined + # arrays to make the eventual storage of this for instances with millions of features + # more efficient as in the current design each molecule would again be a group + # and having millions of groups comes with e.g. HDF5 with substantial overlap + # I faced this when storing grains from micro-scale continuum crystal growth simulations + # TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXms_feature_set + # TJLD: the key point we can use NXms_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... + # but with the additional benefit of a much richer geometrical description and the details about the uncertainty of these descriptions + # I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming + # their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description + dimensionality(NX_UINT): + # TJLD: not needed because they assume everything is 3d + doc: | + What is the best matching description how dimensional the feature is. + enumeration: [0, 1, 2, 3] + cardinality(NX_UINT): + # TJLD: equivalent to the number of AtomGroups class instance childs + doc: | + How many features/members are in this set? + unit: NX_UNITLESS + type_dict_keyword: + # TJLD: equivalent to the controlled vocabulary term monomer or molecule, i.e. label + # TJLD: but with the difference that in this NeXus design here different features can take different roles + # TJLD: and do not conceptually have to be atoms, alternatively one could also create an NXms_interface_set which + # TJLD: inherits from NXms_feature_set but would need to have no dimensionality + doc: | + The keywords of the dictionary of human-readable types of features. + Using terms from a community-agreed upon controlled vocabulary, e.g. + atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, + quadruple junction, triple line, disconnection, dislocation, + kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, + surface, thermal_groove_root, precipitate, dispersoid, pore, crack + is recommended. + dimensions: + rank: 1 + dim: [[1, n_type_dict]] + type_dict_value(NX_UINT): + # TJLD: equivalent to the AtomGroups index + doc: | + The integer identifier used to resolve of which type each feature is, + i.e. the values of the dictionary of human-readable types of features. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_type_dict]] + number_of_parent_identifier(NX_UINT): + doc: | + For each feature in the set specify the associated number of identifier + to parent features as are resolvable via depends_on. + This array enables to compute the array interval from which details for + specific features can be extracted as if they would be stored in an own + group. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + parent_identifier(NX_UINT): + doc: | + Concatenated array of parent identifier for each feature (in the sequence) + according to identifier and how the identifier of features in the here + described feature set are defined (implicitly from 0, to c-1 or via explicit + identifier. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_parent_ids]] + # description of the geometry of the features + # MK::how can be define that inside lines(NXprocess) we assure that there is either no geometry or only one geometry but then this geometry can be either an NXcg_polyline_set or NXcg_spline_set? + # the key problem is that at least for an implementation in HDF5 we are not allowed to have two groups named geometry even if their attributes are different because + # HDF5 implements no conceptual understanding of the relations between elements in the underlying graph which holds the data, these elements are either attributes, fields, groups, all of which + # end up as links + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + features. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: Integer used to distinguish features for explicit indexing. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, c]] + points(NXprocess): + # TJLD: this design here is different, TJLD give atom positions only (at least as of now) for the root of an object + # TJLD: while all higher-order features that are connected through their assumed topology just refer to the atoms in the root + # TJLD: via their IDs, TJLD design is ideal for systems build from atoms but would create unnecessary copies for higher-dimensional-type features + # TJLD: in fact initially I also thought it is useful to create an NXms_dislocation_set, and an NXms_atom_set but overall these are just + # specializations of NXms_feature_set. Instead I like the key approach in TJLD which is to nest instances of the same class in TJLD's case AtomGroups + # but here NXms_feature_set instances + doc: | + Assumptions and parameter to arrive at geometric primitives + to locate zero-dimensional/point-(like) features which are + discretized/represented by points. + geometry(NXcg_point_set): + uncertainty(NXprocess): + doc: | + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + lines(NXprocess): + # TJLD: not conceptualized, see comments for points and what the benefit of using NeXus would be + doc: | + Assumptions and parameters to arrive at geometric primitives + to locate one-dimensional/line-like features which are + discretized by polylines. + # MK::geometry(NXcg_spline_set) + geometry(NXcg_polyline_set): + uncertainty(NXprocess): + doc: | + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + interfaces(NXprocess): + doc: | + Assumptions and parameters to arrive at geometric primitives + to locate two-dimensional/interface features which are + discretized by triangulated surface meshes. + # MK::geometry(NXcg_nurbs_set): + geometry(NXcg_triangle_set): + uncertainty(NXprocess): + doc: | + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + volumes(NXprocess): + doc: | + Assumptions and parameters to arrive at geometric primitives + to locate three-dimensional/volumetric features which are + discretized by triangulated surface meshes of polyhedra. + # MK::geometry(NXcg_nurbs_set): + geometry(NXcg_polyhedron_set): + uncertainty(NXprocess): + doc: | + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + +# Sandor and Markus agree that how trajectories are extracted should be stored in instances of NXprocess at respective places +# Sandor suggested it can be useful to also describe how one could transform system-specific atom positions from the system-focused coordinate system to a molecule- or atom-focused local coordinate system + +# how to map results from MD simulations was already sketched by the comments from TJLD +# but ones more here stating it explicitly +# atoms(NXms_feature_set): +# # no \@depends_on: as everything is build spatiotemporally coarse-grained from the sampled atom positions and/or their trajectories +# dislocations(NXms_feature_set): +# # \@depends_on: <>/atoms +# # is trivially the same case as was described already for the DDD simulation + +# how to map from DREAM.3D to NXms_feature_set +# material_points(NXms_feature_set): # material points can be voxels of a grid (which should be specified with an instance of NXcg_grid) or real material points +# # no \@depends_on: "." required or value can be "." as material_points are considered the root +# grains(NXms_feature_set): +# \@depends_on: <>/material_points +# boundaries(NXms_feature_set): +# \@depends_on: <>/grains +# triple_lines(NXms_feature_set): +# \@depends_on: <>/boundaries +# quadruple_junctions(NXms_feature_set): +# \@depends_on: <>/triple_lines + +# how to map from e.g. DDD codes like ParaDis to NXms_feature_set +# dislocations(NXms_feature_set): +# either all types of dislocations are specified via the type_dict dictionary or by making several named instances of NXms_feature_set classes, i.e. groups +# multi_junctions(NXms_feature_set): +# \@depends_on: <>/dislocations + +# how to describe e.g. 3D cracks +# cracks(NXms_feature_set): +# # you can use volumes and interfaces to describe explicitly the 3D geometry +# # alternatively you can + +# how to map from an MTex v5.8.2 @grain2d object +# grains.poly is a cell of list of vertex indices referring to grains.V +# grains.id +# grains.phaseId to which phase does each grain belong why is it different to phase? +# grains.prop (mean and gos) +# grains.boundary +# F, list of minmax-hashed vertex indices building the facet +# grainId, list of pairs of grains incident at facet special value 0 marks grains with boundary contact +# ebsdId, list of interpolated scan points incident +# phaseId, homo/heterophase information list of pairs of phases incident at facet +# V, list of facet support vertices, the support of the polyline +# midPoint, list of facet midPoint coordinates +# direction 3d vector (V(F(i, 1),:) - V(F(i, 2), :)) and with z = 0 and then normalized, so not respecting winding order +# grains.triplePoints +# id, list of vertex id for the location of the triple point referring to grains.V or grains.boundary.V as these lists are equivalent +# grainid, triplet of adjoining grain ids +# boundaryId, triplet of adjoining boundary facets from grains.boundary.F +# nextVertexId, next vertex hit when walking from the triple point +# phaseId, is it a triple point between homophases or heterophases +# V, list of x, y coordinates for the triple points +# angles, trivial nextVertexId to triplePoint vertex angles +# grains(NXms_feature_set): +# boundaries(NXms_feature_set): +# # alternatively one NXms_feature_set for homophase boundaries diff --git a/contributed_definitions/nyaml/NXms_score_config.yaml b/contributed_definitions/nyaml/NXms_score_config.yaml index 40ba43ed3e..5b3cf22fec 100644 --- a/contributed_definitions/nyaml/NXms_score_config.yaml +++ b/contributed_definitions/nyaml/NXms_score_config.yaml @@ -43,8 +43,8 @@ NXms_score_config: doc: | Relevant data to instantiate a starting configuration that is typically a microstructure in deformed conditions where stored (elastic) energy - is stored in the form of crystal defects (in SCORE) modelled as - dislocation content. + is stored in the form of crystal defects, which in the SCORE model are + is considered as mean-field dislocation content. type: doc: | Which model should be used to generate a starting microstructure. @@ -55,7 +55,8 @@ NXms_score_config: unit: NX_LENGTH domain_size(NX_UINT): doc: | - Extend of each CA domain in voxel along the x, y, and z direction. Deformation of sheet material is assumed. + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. The x axis is assumed pointing along the rolling direction. The y axis is assumed pointing along the transverse direction. The z axis is assumed pointing along the normal direction. @@ -65,7 +66,7 @@ NXms_score_config: dim: [[1, 3]] grain_size(NX_FLOAT): doc: | - Extend of each deformed grain along the x, y, and z direction when type is cuboidal. + Extent of each deformed grain along the x, y, and z direction when type is cuboidal. unit: NX_LENGTH dimensions: rank: 1 @@ -82,7 +83,10 @@ NXms_score_config: rank: 2 dim: [[1, n_dg_ori], [2, 3]] ebsd(NXprocess): - exists: optional # when type is ebsd then required + exists: optional + doc: | + The EBSD dataset from which the initial microstructure is instantiated + if initial_microstructure/type has value ebsd. filename: doc: | Path and name of the EBSD dataset from which to generate the starting microstructure. @@ -91,7 +95,8 @@ NXms_score_config: SHA256 checksum of the file which contains the EBSD dataset. stepsize(NX_FLOAT): doc: | - Size of the EBSD. The EBSD has to be on a regular grid of squares. + Size of the EBSD. The EBSD orientation mapping has to be on a + regular grid of square-shaped pixels. unit: NX_LENGTH dimensions: rank: 1 @@ -102,12 +107,19 @@ NXms_score_config: into the domain and assumed growing. spatial_distribution_model: doc: | - According to which model will the nuclei become distributed spatially. CSR means complete spatial randomness, custom is implementation specific, GB places nuclei at grain boundaries. + According to which model will the nuclei become distributed spatially. + CSR means complete spatial randomness. + Custom is implementation specific. + GB places nuclei at grain boundaries. enumeration: [csr, custom, gb] incubation_time_model: doc: | According to which model will the nuclei start to grow. enumeration: [site_saturation] + orientation_model: + doc: | + According to which model will the nuclei get their orientation assigned. + enumeration: [sample_from_nucleus_euler] nucleus_euler(NX_FLOAT): doc: | Set of Bunge-Euler angles to sample orientations of nuclei randomly from. @@ -117,8 +129,8 @@ NXms_score_config: dim: [[1, n_rx_ori], [2, 3]] material_properties(NXprocess): doc: | - Mechanical properties of the material which scale the amount - of stored (elastic) energy in the system. + (Mechanical) properties of the material which scale the amount + of stored (elastic) energy in the ROI/system. reference_shear_modulus(NX_FLOAT): doc: | Shear modulus at zero Kelvin. @@ -144,7 +156,7 @@ NXms_score_config: For the Sebald-Gottstein model the following equation is used. For the Rollett-Holm model the following equation is used. enumeration: [sebald_gottstein, rollett_holm] - sebald_gottstein_parameter(NXcollection): + sebald_gottstein_parameters(NXcollection): lagb_pre_factor(NX_FLOAT): unit: NX_ANY lagb_enthalpy(NX_FLOAT): @@ -157,7 +169,7 @@ NXms_score_config: unit: NX_ANY special_enthalpy(NX_FLOAT): unit: NX_ANY - rollett_holm_parameter(NXcollection): + rollett_holm_parameters(NXcollection): hagb_pre_factor(NX_FLOAT): unit: NX_ANY hagb_enthalpy(NX_FLOAT): @@ -223,7 +235,7 @@ NXms_score_config: dim: [[1, j]] stop_criteria(NXprocess): doc: | - Criteria which enable to stop the simulation. + Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. max_x(NX_FLOAT): doc: | diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml index 1efb4c1745..8dc48b55c2 100644 --- a/contributed_definitions/nyaml/NXms_score_results.yaml +++ b/contributed_definitions/nyaml/NXms_score_results.yaml @@ -97,7 +97,7 @@ NXms_score_results: Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status(NX_CHAR): + status: doc: | A statement whether the SCORE executable managed to process the analysis or failed prematurely. @@ -188,8 +188,8 @@ NXms_score_results: doc: | Container to hold different coordinate systems conventions. A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Using one NXtransformations - instance per base vector. + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. TRANSFORMATIONS(NXtransformations): exists: [min, 3, max, infty] @@ -230,10 +230,10 @@ NXms_score_results: dimensionality(NX_POSINT): cardinality(NX_POSINT): origin(NX_NUMBER): - symmetry: - cell_dimensions(NX_NUMBER): - extent(NX_POSINT): - identifier_offset(NX_INT): + symmetry: + cell_dimensions(NX_NUMBER): + extent(NX_POSINT): + identifier_offset(NX_INT): boundary(NXcg_polyhedron_set): doc: A tight bounding box or sphere or bounding primitive about the grid. # a good example for a general bounding box description for such a grids of triclinic cells @@ -244,7 +244,7 @@ NXms_score_results: Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. unit: NX_UNITLESS - boundaries(NX_CHAR): + boundaries: exists: recommmended doc: | Name of the boundaries. E.g. left, right, front, back, bottom, top, @@ -292,8 +292,14 @@ NXms_score_results: can be used here. A few examples are given. Each descriptor is currently modelled as an instance of an NXprocess because it is relevant to understand how the descriptors are computed. + time(NXprocess): + exists: optional + doc: | + Evolution of the physical time. temperature(NXprocess): exists: optional + doc: | + Evolution of the simulated temperature over time. # pressure(NXprocess): # exists: optional # stress(NXprocess): @@ -306,12 +312,12 @@ NXms_score_results: # exists: optional # electric_field(NXprocess): # exists: optional - recrystallization_kinetics(NXprocess): - exists: optional - grain_size_distribution(NXprocess): - exists: optional - recrystallization_front(NXprocess): + kinetics(NXprocess): exists: optional + doc: | + Evolution of the recrystallized volume fraction over time. + # recrystallization_front(NXprocess): + # exists: optional # time-resolved results for individual snapshots # virtually all computer simulations and all experiments always probe # snapshots @@ -321,6 +327,10 @@ NXms_score_results: Measured or simulated physical time stamp for this snapshot. Not to be confused with wall-clock timing or profiling data. unit: NX_TIME + temperature(NX_NUMBER): + doc: | + Simulated temperature. + unit: NX_TEMPERATURE iteration(NX_UINT): doc: | Iteration or increment counter. @@ -350,7 +360,15 @@ NXms_score_results: doc: | Details about those cells which in this time step represent the discretized recrystallization front. - mobility(NX_NUMBER): # P + halo_region(NX_UINT): + exists: optional + doc: | + Which cells are currently in a halo region of threads. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_front]] + mobility_weight(NX_NUMBER): exists: recommended doc: | So-called mobility weight which is a scaling factor to @@ -408,7 +426,7 @@ NXms_score_results: dimensions: rank: 1 dim: [[1, n_front]] - grain_size_distribution(NXprocess): # grain_based quantities for Vitesh Shah + grain_ensemble(NXprocess): # grain_based quantities for Vitesh Shah exists: recommended doc: | Current grain-related quantities. @@ -453,11 +471,7 @@ NXms_score_results: dimensions: rank: 1 dim: [[1, n_grains]] - temperature(NXprocess): - value(NX_NUMBER): - doc: | - Simulated temperature. - unit: NX_TEMPERATURE + recrystallized_kinetics(NXprocess): doc: | Current recrystallized volume fraction. @@ -473,10 +487,24 @@ NXms_score_results: unit: NX_DIMENSIONLESS # pressure(NXprocess): # exists: optional - # stress(NXprocess): - # exists: optional - # strain(NXprocess): - # exists: optional + stress(NXprocess): + exists: optional + value(NX_NUMBER): + doc: | + Currently assumed globally applied Cauchy stress tensor on the ROI. + unit: NX_ANY + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + strain(NXprocess): + exists: optional + value(NX_NUMBER): + doc: | + Currently assumed globally applied Cauchy strain tensor on the ROI. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] # deformation_gradient(NXprocess): # exists: optional # magnetic_field(NXprocess): diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml index d01ab5fe2a..f6a7b5c47e 100644 --- a/contributed_definitions/nyaml/NXoptical_system_em.yaml +++ b/contributed_definitions/nyaml/NXoptical_system_em.yaml @@ -41,7 +41,7 @@ NXoptical_system_em: Users should specify further details like how the beam current was measured using the beam_current_description field. unit: NX_CURRENT - beam_current_description(NX_CHAR): + beam_current_description: doc: | Specify further details how the beam current was measured or estimated. # NEW ISSUE: the KIT/SCC propose: diff --git a/contributed_definitions/nyaml/NXorientation_set.yaml b/contributed_definitions/nyaml/NXorientation_set.yaml index 1a446a92b8..4a54c2b33f 100644 --- a/contributed_definitions/nyaml/NXorientation_set.yaml +++ b/contributed_definitions/nyaml/NXorientation_set.yaml @@ -28,7 +28,7 @@ NXorientation_set: doc: | Reference to or definition of a coordinate system with which the definitions are interpretable. - parameterization(NX_CHAR): + parameterization: enumeration: [bunge-euler (ZXZ), quaternion] # there are many more ways of parameterizing orientations and for each of them different conventions to be used. many scientists do not recall by hard which rule set is associated with an e.g. ZXZ Bunge-Euler angles vers ZXY so there are at least two ways how to encode these metadata: Either to have different enumerations like bunge-euler-zxz, bunge-euler-zxy, etc. or a base class NXori_bunge_euler and then internally here a rule set...? # how to take into account the reduction to two-d? just list these cases XY, XZ, ... also in the enumeration? # an instance of an NXorientation_set is useful as attribute (meta)data to a set of microstructural objects e.g. crystals, grains when the base class is stored as a sub-ordinate of the grain_set @@ -37,7 +37,7 @@ NXorientation_set: # because many computer simulations deal with ensemble where the number of objects changes over time, e.g. molecular dynamics simulation treat always the same set of atoms but post-processing # of the data may reveal these atoms are grouped/labelled as different microstructural features (grains, dislocations, vacancies) and then the names/identifiers of the objects may change over time # therefore the idea to specify if we use implicit or explicit indexing and listing of the indices because I know of colleagues where even that went havoc! - objects(NX_CHAR): + objects: doc: | A link or reference to the objects whose identifier are referred to in identifier to resolve which row tuple is the orientation of each object diff --git a/contributed_definitions/nyaml/NXprogram.yaml b/contributed_definitions/nyaml/NXprogram.yaml index 672d6f95bd..9fda651b6b 100644 --- a/contributed_definitions/nyaml/NXprogram.yaml +++ b/contributed_definitions/nyaml/NXprogram.yaml @@ -2,15 +2,13 @@ category: base doc: | Base class to describe a software tool or library. symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. NXprogram: - program_name: - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. program: doc: | - Commercial, parser, or otherwise given name to the program. + Given name of the program. Program can be a commercial one a script, + or a library or a library component. \@version: doc: | Program version plus build number, or commit hash. diff --git a/contributed_definitions/nyaml/NXpulser_apm.yaml b/contributed_definitions/nyaml/NXpulser_apm.yaml index 8c48ae158f..347fc8608e 100644 --- a/contributed_definitions/nyaml/NXpulser_apm.yaml +++ b/contributed_definitions/nyaml/NXpulser_apm.yaml @@ -11,13 +11,25 @@ NXpulser_apm: How is field evaporation physically triggered. enumeration: [laser, voltage, laser_and_voltage] pulse_frequency(NX_FLOAT): - doc: Frequency with which the high voltage or laser pulser fires. + doc: | + Frequency with which the high voltage or laser pulser fires. unit: NX_FREQUENCY + # This can change over the course of the experiment, APT HDF defines it therefore as follows: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of the high voltage or laser pulser. first entry : first pulse number where the spacing between this and all subsequent pulses are considered to be at the selected frequency. Each first entry must be strictly increasing in value. The second entry contains the frequency value" as data can be compressed in this case very efficiently we go for with an array of length 1xn_ions + dimensions: + rank: 1 + dim: [[1, n_ions]] pulse_fraction(NX_FLOAT): doc: | Fraction of the pulse_voltage that is applied in addition to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] pulsed_voltage(NX_FLOAT): doc: | In laser pulsing mode the values will be zero so the this field is recommended. @@ -26,11 +38,18 @@ NXpulser_apm: dimensions: rank: 1 dim: [[1, n_ions]] + pulse_number(NX_UINT): + doc: | + Absolute number of pulses starting from the beginning of the experiment. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] standing_voltage(NX_FLOAT): doc: | - Direct current voltage between the specimen and the - (local electrode) in the case of local electrode atom - probe (LEAP) instrument. + Direct current voltage between the specimen and the (local electrode) in + the case of local electrode atom probe (LEAP) instrument. + The standing voltage applied to the sample, relative to system ground. unit: NX_VOLTAGE dimensions: rank: 1 @@ -69,6 +88,12 @@ NXpulser_apm: doc: | Details about specific positions along the focused laser beam which illuminates the (atom probe) specimen. + incidence_vector(NXcollection): + doc: | + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set doc: | Track time-dependent settings over the course of the diff --git a/contributed_definitions/nyaml/NXreflectron.yaml b/contributed_definitions/nyaml/NXreflectron.yaml index f61cef2148..5e2a3564f6 100644 --- a/contributed_definitions/nyaml/NXreflectron.yaml +++ b/contributed_definitions/nyaml/NXreflectron.yaml @@ -1,6 +1,9 @@ category: base doc: | Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). NXreflectron: name: doc: Given name/alias. @@ -9,6 +12,7 @@ NXreflectron: doc: | Free-text field to specify further details about the reflectron. The field can be used to inform e. g. if the reflectron is flat or curved. + # IFES_APT_TC "ReflectronVoltage: Real, 1xn array (V) Must be present if ReflectronInfo is not “None” The maximum voltage applied to the reflectron, relative to system ground." (NXtransformations): doc: | Affine transformation(s) which detail where the reflectron diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml index 244aa3d64c..89e708ec77 100644 --- a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml +++ b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml @@ -30,7 +30,7 @@ NXsimilarity_grouping: number_of_categorical_labels(NX_UINT): doc: How many categorical labels does each feature have. unit: NX_UNITLESS - # features(NX_CHAR): + # features: # doc: | # Reference to a set of features investigated in a cluster analysis. # Features need to have disjoint numeric identifier. diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml new file mode 100644 index 0000000000..1b44d65938 --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set.yaml @@ -0,0 +1,91 @@ +category: base +doc: | + Container for reporting a set of spectra. +symbols: +# n_p: Number of scan points + n_y: Number of pixel in the slow direction. + n_x: Number of pixel in the fast direction. + n_energy: Number of energy bins. +NXspectrum_set: + (NXprocess): + doc: | + Details how spectra were processed from the detector readings. + source: + doc: | + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + mode: + doc: | + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + detector_identifier: + doc: | + Link or name of an NXdetector instance with which the data were collected. + (NXprogram): + # ##MK::feel free to contact us when you would like to include more complicated scan pattern than rectangular ones. + stack(NXdata): + doc: | + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, n_energy]] + \@long_name: + doc: Counts + # \@signal: counts + # \@axes: [ypos, xpos, energy] + # \@ypos_indices: 0 + # \@xpos_indices: 1 + # \@energy_indices: 2 + axis_y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Coordinate along y direction + axis_x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Coordinate along x direction + axis_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + doc: Energy + # in the majority of cases rectangular or line scans are performed + # if there is interest to support arbitrary scan pattern one should use + # scan points and contact us to generalize this base class and related + # base classes + summary(NXdata): + doc: | + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + doc: Counts + # \@signal: counts + # \@axes: [energy] + # \@energy_indices: 0 + axis_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + doc: Energy diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index bcc88b7c8d..d1d30ba644 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -68,8 +68,5 @@ a set of frequently on-the-fly processed computational data. For now we represen .. _ApmRemovedBC: -Removed base classes -#################### - -We have removed the NXlens_apm base class and replaced it by :ref:`NXreflectron`. -We have renamed NXmanufacturer to NXfabrication. +.. Removed base classes +.. #################### diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index 52aafd73b8..e2d7c90368 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -1,7 +1,7 @@ .. _CgmsFeatures-Structure: ========================= -Geometry & microstructure +Geometry & Microstructure ========================= .. index:: @@ -205,18 +205,10 @@ to hold metadata for these features: Metadata to a set of slip system/slip system family for a given crystal structure. - :ref:`NXms_atom_set`: - Metadata to a set of atoms. - - :ref:`NXms_dislocation_set`: - Metadata of a set of dislocation/disconnection (line) defects. - - :ref:`NXms_interface_set`: - Metadata to a set of interfaces between crystals. - - :ref:`NXms_crystal_set`: - A set of crystals, for e.g. a polycrystal, phases, - grains, precipitates. + :ref:`NXms_feature_set`: + Generic base class to describe any nested set of features + of a microstructure at the continuum-, micron-, nano-scale, or + to represent a topology of molecules and atoms. :ref:`NXms_snapshot`: A container to describe the state of microstructural features diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index b93b3b1dcf..5d2dd181f8 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -43,8 +43,8 @@ Base Classes We developed entirely new base classes. Some of them are also used for other techniques of this proposal but mentioned here for the sake of completeness: - :ref:`NXaberration`: - A base class to describe detailed parameters of optical models for the aberrations of the microscope. + :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: + Base classes to describe procedures and values for the calibration of aberrations based on either CEOS or Nion. :ref:`NXaperture_em`: A base class to describe an aperture. @@ -70,8 +70,8 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXibeam_column`: A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused ion beam (milling) capabilities. - :ref:`NXimage_set_em_adf`, :ref:`NXimage_set_em_bf`, :ref:`NXimage_set_em_bse`, :ref:`NXimage_set_em_chamber`, :ref:`NXimage_set_em_df`, :ref:`NXimage_set_em_diffrac`, :ref:`NXimage_set_em_ecci`, :ref:`NXimage_set_em_kikuchi`, :ref:`NXimage_set_em_ronchigram`, :ref:`NXimage_set_em_se`, :ref:`NXimage_set_em`: - Base classes for storing acquisition details for individual images or stacks of images collected via using e.g. different imaging modes. The suffixes specify **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction (EBSD), **ronchigram** - convergent beam diffraction pattern, **se** secondary electron, and **generic** images. + :ref:`NXimage_set`: + Base classes for storing acquisition details for individual images or stacks of images. Specialized versions can be defined and use controlled vocabulary terms for group name prefixes like **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction, **ronchigram** - convergent beam diffraction pattern, or **se** secondary electron. :ref:`NXinteraction_vol_em`: A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. @@ -98,8 +98,8 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXscanbox_em`: A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. - :ref:`NXspectrum_set_em_eels`, :ref:`NXspectrum_set_em_xray`, :ref:`NXspectrum_set_em_auger`, :ref:`NXspectrum_set_em_cathodolum`: - Base classes comparable to NXimage_set_em but for different techniques resulting in spectra. The suffixes specify **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, and **cathodolum** cathodoluminescence. + :ref:`NXspectrum_set`: + Base class and specializations comparable to NXimage_set but for storing spectra. Specialized base classes should use controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. :ref:`NXstage_lab`: As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. @@ -142,13 +142,8 @@ Several new base classes are used by this application definition. Deprecated ########## -With the results of the NeXus 2022.06 Code Camp the following base classes and application definitions are considered deprecated. -Their functionalities has been extended and is replaced specifically as follows: +In April/May 2023, we refactored the design of the NXimage_set and NXspectrum set base classes. Therefore, the following base classes should not longer be used: +NXimage_set_em_bf, NXimage_set_em_bse, NXimage_set_em_chamber, NXimage_set_em_df, NXimage_set_em_diffrac, NXimage_set_em_ecci, NXimage_set_em_kikuchi, NXimage_set_em_ronchigram, NXimage_set_em_se, NXimage_set_em, NXspectrum_set_em_eels, NXspectrum_set_em_xray, NXspectrum_set_em_auger, NXspectrum_set_em_cathodolum. - **NXem_nion** was an application definition specific for Nion (transmission) electron microscopes. - We consider this application definition as deprecated. Instead, users - should use the substantially more general :ref:`NXem` application definition. - - **NXfib** was a base class which described focused-ion beam capabilities of an - (electron) microscope. Considered deprecated, users should use the more specific - :ref:`NXibeam_column` base class instead. +With the NeXus 2022.06 Code Camp, we refactored the NXem application definition. Therefore, the following base classes and application definitions should no longer be used: +NXem_nion (replaced by :ref:`NXem`), NXfib (replaced by :ref:`NXibeam_column`). diff --git a/manual/source/index.rst b/manual/source/index.rst index 1fae040ddc..25f293f57f 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -16,11 +16,13 @@ https://www.nexusformat.org/ ellipsometry-structure apm-structure transport-structure + stm-structure cgms-structure laboratory-structure north-structure + ----------- .. rubric:: Publishing Information diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst index edf9527c50..6f21499139 100644 --- a/manual/source/north-structure.rst +++ b/manual/source/north-structure.rst @@ -1,8 +1,8 @@ .. _North-Structure: -============================== -Nomad Remote Tools Hub (NORTH) -============================== +====================== +Nomad Remote Tools Hub +====================== .. index:: @@ -44,7 +44,9 @@ study themselves which individual parameter and settings for each tool exist and how configuring these affects their analyses quantitatively. Second, scientific software like the tools in the paraprobe-toolbox implement a -numerical/algorithmical (computational) workflow whereby data from multiple input sources (like previous analysis results) are processed and carried through more involved analysis within several steps inside the tool. The tool then creates output as files. +numerical/algorithmical (computational) workflow whereby data from multiple input sources +(like previous analysis results) are processed and carried through more involved analysis +within several steps inside the tool. The tool then creates output as files. Individual tools are developed in C/C++ and/or Python. Here, having a possibility for provenance tracking is useful as it is one component and requirement for @@ -53,14 +55,15 @@ to fullfill better the "R", i.e. reproducibility of daily FAIR research practice The paraprobe-toolbox is one example of a software which implements a workflow via a sequence of operations executed within a jupyter notebook -(or Python script respectively). Specifically, individual tools are chained. Convenience functions are available to create well-defined input/configuration +(or Python script respectively). Specifically, individual tools are chained. +Convenience functions are available to create well-defined input/configuration files for each tool. These config files instruct the tool upon processing. In this design, each workflow step (with a tool) is in fact a pair (or triple) of at least two sub-steps: i) the creation of a configuration file, ii) the actual analysis using the Python/or C/C++ tools, -iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 files generated from each tool run using -other software. +iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 +files generated from each tool run using other software. .. _WhatHasBeenAchieved: @@ -88,15 +91,19 @@ processing chain/workflow. As an example, a user may first range their reconstruction and then compute correlation functions. The config file for the ranging tool stores the files which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the ion type labels stored. This results file is formatted according to the tool-specific `results` application definition. This results file and the reconstruction is imported by the spatial statistics -tool which again keeps track of all files. +The ranging tool generates a results file with the ion type labels stored. +This results file is formatted according to the tool-specific `results` +application definition. This results file and the reconstruction is +imported by the spatial statistics tool which again keeps track of all files. -This design makes it possible to rigorously -trace which numerical results were achieved with a specific chain of input and +This design makes it possible to rigorously trace which numerical results +were achieved with a specific chain of input and settings using specifically-versioned tools. We understand that this additional handling of metadata and provenance tracking -may not be at first glance super relevant for scientists or appears to be an unnecessarily complex feature. There is indeed an additional layer of work which came with the development and maintenance of this functionality. +may not be at first glance super relevant for scientists or appears to be an +unnecessarily complex feature. There is indeed an additional layer of work which +came with the development and maintenance of this functionality. However, we are convinced that this is the preferred way of performing software development and data analyses as it enables users to take advantage of a completely diff --git a/manual/source/stm-structure.rst b/manual/source/stm-structure.rst new file mode 100644 index 0000000000..944c262033 --- /dev/null +++ b/manual/source/stm-structure.rst @@ -0,0 +1,32 @@ +.. _Stm-Structure: + +============================= +Scanning Tunneling Microscopy +============================= + + +.. index:: + IntroductionStm + StmAppDef + StmNewBC + + +.. _IntroductionStm: + +Introduction +############## +TBD + + +.. _StmAppDef: + +Application Definitions +####################### +TBD + + +.. _StmNewBC: + +Base Classes +############ +TBD From db59846726f08f3fe32bd39536a433d7557180ea Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 24 Apr 2023 09:57:26 +0200 Subject: [PATCH 125/203] Updates XMLs (regenerated with pynxtools, master, 176451e, only inside contributed_definitions directory) --- contributed_definitions/NXaberration.nxdl.xml | 102 +- .../NXaberration_model.nxdl.xml | 105 ++ .../NXaberration_model_ceos.nxdl.xml | 91 ++ .../NXaberration_model_nion.nxdl.xml | 63 + contributed_definitions/NXaperture.nxdl.xml | 29 +- .../NXaperture_em.nxdl.xml | 1 + contributed_definitions/NXapm.nxdl.xml | 667 ++++---- .../NXapm_input_ranging.nxdl.xml | 1 + .../NXapm_input_reconstruction.nxdl.xml | 1 + .../NXapm_paraprobe_config_clusterer.nxdl.xml | 57 +- .../NXapm_paraprobe_config_distancer.nxdl.xml | 12 +- ...Xapm_paraprobe_config_intersector.nxdl.xml | 41 +- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 117 +- .../NXapm_paraprobe_config_ranger.nxdl.xml | 38 +- .../NXapm_paraprobe_config_selector.nxdl.xml | 5 +- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 445 +++--- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 12 +- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 54 +- ...NXapm_paraprobe_config_transcoder.nxdl.xml | 7 +- ...NXapm_paraprobe_results_clusterer.nxdl.xml | 74 +- ...NXapm_paraprobe_results_distancer.nxdl.xml | 19 +- ...apm_paraprobe_results_intersector.nxdl.xml | 26 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 161 +- .../NXapm_paraprobe_results_ranger.nxdl.xml | 51 +- .../NXapm_paraprobe_results_selector.nxdl.xml | 14 +- .../NXapm_paraprobe_results_spatstat.nxdl.xml | 34 +- .../NXapm_paraprobe_results_surfacer.nxdl.xml | 27 +- ...apm_paraprobe_results_tessellator.nxdl.xml | 42 +- ...Xapm_paraprobe_results_transcoder.nxdl.xml | 169 +- contributed_definitions/NXbeam.nxdl.xml | 63 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_alpha_complex.nxdl.xml | 31 + .../NXcg_cylinder_set.nxdl.xml | 12 + .../NXcg_ellipsoid_set.nxdl.xml | 3 + .../NXcg_face_list_data_structure.nxdl.xml | 3 + .../NXcg_geodesic_mesh.nxdl.xml | 1 + contributed_definitions/NXcg_grid.nxdl.xml | 15 +- .../NXcg_half_edge_data_structure.nxdl.xml | 8 +- .../NXcg_hexahedron_set.nxdl.xml | 11 + .../NXcg_marching_cubes.nxdl.xml | 3 + .../NXcg_parallelogram_set.nxdl.xml | 6 + .../NXcg_polygon_set.nxdl.xml | 69 + .../NXcg_polyhedron_set.nxdl.xml | 23 + .../NXcg_polyline_set.nxdl.xml | 11 +- contributed_definitions/NXcg_roi_set.nxdl.xml | 3 + .../NXcg_sphere_set.nxdl.xml | 2 + .../NXcg_tetrahedron_set.nxdl.xml | 22 + .../NXcg_triangle_set.nxdl.xml | 4 + .../NXcg_triangulated_surface_mesh.nxdl.xml | 13 + .../NXcg_unit_normal_set.nxdl.xml | 3 + .../NXchemical_composition.nxdl.xml | 4 + contributed_definitions/NXclustering.nxdl.xml | 7 +- .../NXcollectioncolumn.nxdl.xml | 4 +- contributed_definitions/NXcontainer.nxdl.xml | 289 ++-- .../NXcoordinate_system_set.nxdl.xml | 54 + .../NXcorrector_cs.nxdl.xml | 55 +- .../NXcs_computer.nxdl.xml | 2 + contributed_definitions/NXcs_io_obj.nxdl.xml | 2 + contributed_definitions/NXcs_mm_sys.nxdl.xml | 1 + contributed_definitions/NXcs_prng.nxdl.xml | 3 + .../NXcs_profiling.nxdl.xml | 10 +- contributed_definitions/NXcsg.nxdl.xml | 105 +- contributed_definitions/NXcxi_ptycho.nxdl.xml | 383 +++-- contributed_definitions/NXdeflector.nxdl.xml | 2 +- .../NXdelocalization.nxdl.xml | 16 + contributed_definitions/NXdetector.nxdl.xml | 63 +- contributed_definitions/NXdistortion.nxdl.xml | 2 +- .../NXebeam_column.nxdl.xml | 8 +- .../NXelectronanalyser.nxdl.xml | 8 +- .../NXelectrostatic_kicker.nxdl.xml | 120 +- .../NXellipsometry.nxdl.xml | 14 + contributed_definitions/NXem.nxdl.xml | 1408 +++++++++++++---- contributed_definitions/NXem_ebsd.nxdl.xml | 377 +++++ .../NXem_ebsd_conventions.nxdl.xml | 13 + ...NXem_ebsd_crystal_structure_model.nxdl.xml | 14 + .../NXenergydispersion.nxdl.xml | 4 +- contributed_definitions/NXentry.nxdl.xml | 83 +- .../NXevent_data_em.nxdl.xml | 148 +- .../NXfabrication.nxdl.xml | 1 + .../NXgraph_edge_set.nxdl.xml | 4 +- .../NXgraph_node_set.nxdl.xml | 7 +- contributed_definitions/NXgraph_root.nxdl.xml | 1 + .../NXibeam_column.nxdl.xml | 28 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ .../NXimage_set_em_adf.nxdl.xml | 5 + .../NXimage_set_em_bf.nxdl.xml | 25 +- .../NXimage_set_em_bse.nxdl.xml | 25 +- .../NXimage_set_em_chamber.nxdl.xml | 25 +- .../NXimage_set_em_df.nxdl.xml | 25 +- .../NXimage_set_em_diffrac.nxdl.xml | 25 +- .../NXimage_set_em_ecci.nxdl.xml | 25 +- .../NXimage_set_em_kikuchi.nxdl.xml | 12 + .../NXimage_set_em_ronchigram.nxdl.xml | 25 +- .../NXimage_set_em_se.nxdl.xml | 31 +- contributed_definitions/NXinstrument.nxdl.xml | 31 +- .../NXinteraction_vol_em.nxdl.xml | 55 +- contributed_definitions/NXion.nxdl.xml | 64 +- contributed_definitions/NXiv_temp.nxdl.xml | 2 +- ...ctro_chemo_mechanical_preparation.nxdl.xml | 24 +- .../NXlab_sample_mounting.nxdl.xml | 17 +- contributed_definitions/NXlens_em.nxdl.xml | 2 +- .../NXmagnetic_kicker.nxdl.xml | 117 +- .../NXmanipulator.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 15 +- contributed_definitions/NXms.nxdl.xml | 137 +- .../NXms_feature_set.nxdl.xml | 300 ++++ .../NXms_score_config.nxdl.xml | 43 +- .../NXms_score_results.nxdl.xml | 135 +- .../NXms_snapshot_set.nxdl.xml | 6 + .../NXoptical_system_em.nxdl.xml | 9 +- .../NXorientation_set.nxdl.xml | 22 +- contributed_definitions/NXprocess.nxdl.xml | 35 +- contributed_definitions/NXprogram.nxdl.xml | 9 +- contributed_definitions/NXpulser_apm.nxdl.xml | 34 +- contributed_definitions/NXpump.nxdl.xml | 3 + contributed_definitions/NXquadric.nxdl.xml | 115 +- .../NXquadrupole_magnet.nxdl.xml | 100 +- contributed_definitions/NXreflectron.nxdl.xml | 4 + contributed_definitions/NXregion.nxdl.xml | 344 ++-- .../NXregistration.nxdl.xml | 2 +- contributed_definitions/NXsample.nxdl.xml | 61 +- contributed_definitions/NXscanbox_em.nxdl.xml | 6 + contributed_definitions/NXseparator.nxdl.xml | 124 +- .../NXsimilarity_grouping.nxdl.xml | 8 + .../NXslip_system_set.nxdl.xml | 8 + contributed_definitions/NXsnsevent.nxdl.xml | 621 ++++---- contributed_definitions/NXsnshisto.nxdl.xml | 647 ++++---- .../NXsolenoid_magnet.nxdl.xml | 100 +- .../NXsolid_geometry.nxdl.xml | 53 +- contributed_definitions/NXsource.nxdl.xml | 37 +- .../NXspatial_filter.nxdl.xml | 3 + .../NXspectrum_set.nxdl.xml | 162 ++ .../NXspectrum_set_em_auger.nxdl.xml | 25 +- .../NXspectrum_set_em_cathodolum.nxdl.xml | 25 +- .../NXspectrum_set_em_eels.nxdl.xml | 9 + .../NXspectrum_set_em_xray.nxdl.xml | 19 + .../NXspin_rotator.nxdl.xml | 124 +- .../NXspindispersion.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 15 + .../NXtransmission.nxdl.xml | 10 +- contributed_definitions/NXxpcs.nxdl.xml | 1100 +++++++------ 141 files changed, 7589 insertions(+), 3567 deletions(-) create mode 100644 contributed_definitions/NXaberration_model.nxdl.xml create mode 100644 contributed_definitions/NXaberration_model_ceos.nxdl.xml create mode 100644 contributed_definitions/NXaberration_model_nion.nxdl.xml create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXms_feature_set.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml index 0b3a8a5632..a26f988e43 100644 --- a/contributed_definitions/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -1,79 +1,55 @@ - + - + + - Models for aberrations of electro-magnetic lenses in electron microscopy. - - The notation follows `O. Krivanek et al. (1999) <https://doi.org/10.1016/S0304-3991(99)00013-3>`_ - and `O. Krivanek et al. (2003) <https://doi.org/10.1016/S0304-3991(03)00090-1>`_ - See also `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) - for further details, additional literature, and the unit of the coefficients. - Consult Table 7-2 of Ibid. publication on how to convert between - conventions of different groups/vendors. + Quantified aberration coefficient in an aberration_model. - + + - Defocus + Confidence - + - Two-fold astigmatism + How was the uncertainty quantified e.g. via the 95% confidence interval. - + - Two-fold astigmatism + Time elapsed since the last measurement. - + - Second-order axial coma - - - - - Second-order axial coma - - - - - Threefold astigmatism - - - - - Threefold astigmatism - - - - - Spherical aberration - - - - - Star aberration - - - - - Star aberration - - - - - Fourfold astigmatism - - - - - Fourfold astigmatism - - - - - Fifth-order spherical aberration + For the CEOS definitions the C aberrations are radial-symmetric and have no + angle entry, while the A, B, D, S, or R aberrations are n-fold + symmetric and have an angle entry. + For the NION definitions the coordinate system differs to the one + used in CEOS and instead two aberration coefficients a and b are used. + + diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml new file mode 100644 index 0000000000..64c1c012e4 --- /dev/null +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -0,0 +1,105 @@ + + + + + + Models for aberrations of electro-magnetic lenses in electron microscopy. + + See `S. J. Pennycock and P. D. Nellist <https':'//doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + + + + + + + + + + + Defocus + + + + + Two-fold astigmatism + + + + + Two-fold astigmatism + + + + + Second-order axial coma + + + + + Second-order axial coma + + + + + Threefold astigmatism + + + + + Threefold astigmatism + + + + + Spherical aberration + + + + + Star aberration + + + + + Star aberration + + + + + Fourfold astigmatism + + + + + Fourfold astigmatism + + + + + Fifth-order spherical aberration + + + diff --git a/contributed_definitions/NXaberration_model_ceos.nxdl.xml b/contributed_definitions/NXaberration_model_ceos.nxdl.xml new file mode 100644 index 0000000000..20bf7e2a06 --- /dev/null +++ b/contributed_definitions/NXaberration_model_ceos.nxdl.xml @@ -0,0 +1,91 @@ + + + + + + CEOS definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist <https':'//doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXaberration_model_nion.nxdl.xml b/contributed_definitions/NXaberration_model_nion.nxdl.xml new file mode 100644 index 0000000000..bd1dc9a7d9 --- /dev/null +++ b/contributed_definitions/NXaberration_model_nion.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + NION definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist <https':'//doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXaperture.nxdl.xml b/contributed_definitions/NXaperture.nxdl.xml index 3e4b8dd42c..4aaf3e0b27 100644 --- a/contributed_definitions/NXaperture.nxdl.xml +++ b/contributed_definitions/NXaperture.nxdl.xml @@ -1,16 +1,37 @@ - + - + + A beamline aperture - Declares which child group contains a path leading to a :ref:`NXdata` group. + 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 1c3d7a3a0e..2f8ac254d6 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -22,6 +22,7 @@ # For further information, see http://www.nexusformat.org --> + Details of an individual aperture for beams in electron microscopy. diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index ae4a598dc3..86a6a4e3e6 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -21,6 +21,19 @@ # # For further information, see http://www.nexusformat.org --> + @@ -72,9 +85,70 @@ Number of bins. + + + Total number of integers in the supplementary XDMF topology array. + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve this description to cover a substantial larger number of eventually metadata that + so far are neither publicly documented nor accessible. @@ -83,6 +157,7 @@ that specifies the application definition. + NeXus NXDL schema to which this file conforms. @@ -131,82 +206,27 @@ collected to compute this event chain during the experiment. + ISO 8601 time code with local time zone offset to UTC included when the microscope session ended. - - - Commercial or otherwise given name to the program which was used - to create the original results file of the atom probe experiment. - This file and program should not be confused with downstream - processing operations and file format conversion tasks. - - Atom probe microscopy experiments are except for still very much cases - controlled via commercial software. Such software is designed as an - integrated acquisition and instrument control software. - - For AMETEK/Cameca local electrode atom probe (LEAP) instruments the - least processed (rawest) numerical results and metadata are stored - in so-called RHIT and HITS files, which are proprietary and the - specifications of which are not publicly documented. - - Supplementary metadata are kept in a database which is connected - to the instrument control software and synced with the experiment - while signal is being detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also to resolve isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - Therefore, this application definition documents not only the measurement - but also the key post-processing steps which transform the proprietary - data into a tomographic reconstruction with ranging definitions. - - Future guidance by the vendors could improve this description to cover - a substantial larger number of eventually metadata that so far - are not publicly documented and accessible in an open-source manner. - - - - Program 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. - - - + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier @@ -274,6 +294,9 @@ + Contact information and eventually details of at least one person @@ -344,6 +367,12 @@ + Descriptive name or ideally (globally) unique persistent identifier. @@ -425,6 +454,9 @@ + Hard link to a location in the hierarchy of the NeXus file @@ -443,11 +475,16 @@ In this research field scientists distinguish usually several Euclidean coordinate systems (CS): + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. * The laboratory space; a CS specifying the room where the instrument is located in or a physical landmark on the instrument, e.g. the direction of the transfer rod where positive is the direction how the rod has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. * The specimen space; a CS affixed to either the base or the initial apex of the specimen, whose z axis points towards the detector. @@ -480,9 +517,17 @@ Consult the work of A. J. Breen and B. Gault and team for further details. + + + Metadata and numerical data of the atom probe and the lab in which it @@ -499,6 +544,7 @@ Hence, there is no real probe/beam. * Second, the specimen is the lens of the microscope. + Given name of the atom probe at the hosting institution. This is an @@ -526,6 +572,16 @@ THIS DOCSTRING NEEDS CLARIFICATION. + The nominal diameter of the specimen ROI which is measured in the @@ -535,6 +591,7 @@ + Is a reflectron installed and was it used? @@ -548,10 +605,21 @@ + + - A local electrode guiding the ion flight path. + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. @@ -566,7 +634,14 @@ + + Detector for taking raw time-of-flight and @@ -582,11 +657,13 @@ the detector type via free-text. + Given name/alias. + Given brand or model name by the manufacturer. @@ -615,14 +692,20 @@ + + - + + + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the excitation @@ -653,13 +736,29 @@ + Average temperature at the specimen base, i.e. base_temperature during the measurement. + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + @@ -674,6 +773,7 @@ Average pressure in the analysis chamber. + @@ -689,6 +789,7 @@ Average pressure in the buffer chamber. + @@ -704,6 +805,7 @@ Average pressure in the load_lock_chamber. + @@ -712,6 +814,7 @@ + @@ -721,6 +824,7 @@ + @@ -730,9 +834,26 @@ + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + A place where details about the initial shape of the specimen can be stored. Ideally, here also data about the shape evolution @@ -756,6 +877,7 @@ Nothing can be said about the outcome of this research yet but here is where such spatio-temporally data could be stored. + Ideally measured or best elaborated guess of the @@ -776,6 +898,15 @@ Average detection rate over the course of the experiment. + + + + Estimated field at the apex along the evaporation sequence. + + + + + @@ -807,21 +938,13 @@ groups to begin with. Holding heterogeneous, not yet standardized but relevant pieces of information is the purpose of this collection. - - - Name of the control software of the microscope - used during acquisition (e.g. IVAS/APSuite). - - - - Program 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. - - - + + + + + + Track time-dependent details over the course of the measurement about the @@ -841,6 +964,29 @@ + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + Details about where ions hit the ion_detector and data processing @@ -854,22 +1000,14 @@ like the Oxcart instrument, individual timing data from the delay-line detector are openly accessible. - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + + + Raw readings from the analog-to-digital-converter @@ -886,6 +1024,9 @@ Evaluated ion impact coordinates at the detector (either as computed from the arrival time data or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. @@ -893,6 +1034,20 @@ + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + Data post-processing step which is, like the impact position analyses, @@ -909,22 +1064,12 @@ ion contains (which is instead encoded with the isotope_vector field of each NXion instance). - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + + Number of pulses since the last detected ion pulse. @@ -934,6 +1079,9 @@ + Number of pulses since the start of the atom probe @@ -944,6 +1092,8 @@ + Hit multiplicity. @@ -961,22 +1111,12 @@ This post-processing is usually performed via GUI interaction in the reconstruction pipeline of IVAS/APSuite. - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + + Bitmask which is set to true if the ion @@ -987,6 +1127,7 @@ + Data post-processing step to correct for ion impact @@ -994,22 +1135,16 @@ and nonlinearities. This step is usually performed with commercial software. - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + + + Raw time-of-flight data as read out from the acquisition software @@ -1020,6 +1155,8 @@ + Calibrated time-of-flight. @@ -1053,27 +1190,20 @@ + Data post-processing step in which calibrated time-of-flight data (ToF) are interpreted into mass-to-charge-state ratios. - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + + Store vendor-specific calibration models here (if available). @@ -1083,11 +1213,13 @@ Mass-to-charge-state ratio values. + + Data post-processing step to create a tomographic reconstruction @@ -1098,21 +1230,12 @@ i.e. numerical recipes how to compute x, y, z atomic positions from the input data. - - - Given name of the program that was used to perform this computation. - Similar comments as voltage_and_bowl_correction apply. - - - - Program 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. - - - + + + + + + Qualitative statement about which reconstruction protocol was used. @@ -1126,6 +1249,10 @@ + Different reconstruction protocols exist. Although these approaches are qualitatively similar, each protocol uses different parameters @@ -1134,6 +1261,19 @@ in a collection. + Different strategies for crystallographic calibration of the @@ -1153,6 +1293,30 @@ + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. The XDMF primitive type is here 1, the number of primitives 1 per triplet, the last integer in each triplet is the identifier of each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + To get a first overview of the reconstructed dataset, @@ -1160,22 +1324,11 @@ of the ion density using one nanometer cubic bins without applying smoothening algorithms on this histogram. - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + A default three-dimensional histogram of the total @@ -1185,6 +1338,7 @@ + @@ -1226,6 +1380,7 @@ + Data post-processing step in which elemental, isotopic, @@ -1237,22 +1392,12 @@ * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + + How many ion types are distinguished. @@ -1275,26 +1420,17 @@ specifically these values are binned. This (NXprocess) stores the settings of this binning. - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + Smallest and largest mass-to-charge-state ratio value. + @@ -1304,6 +1440,8 @@ Binning width of the mass-to-charge-state ratio values. + A default histogram aka mass spectrum of @@ -1312,6 +1450,7 @@ + @@ -1338,44 +1477,27 @@ Details of the background model which was used to correct the total counts per bin into counts. - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + + How where peaks in the background-corrected in the histogram of mass-to-charge-state ratio values identified? - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + @@ -1390,22 +1512,11 @@ Details about how peaks, with taking into account error models, were interpreted as ion types or not. - - - Given name of the program that was used to perform this computation. - Apart from the classical approach to use AMETEK software for this - processing step, a number of open-source alternative tools exists. - - - - Program 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. - - - + + + + + diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml index 2f44bec9a8..99aba9553a 100644 --- a/contributed_definitions/NXapm_input_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_input_ranging.nxdl.xml @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + Metadata to ranging definitions made for a dataset in atom probe microscopy. diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml index c6d9401be5..db9c18895a 100644 --- a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml index 473b5444b9..ffebc158a5 100644 --- a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -26,6 +26,8 @@ The symbols used in the schema to specify e.g. dimensions of arrays. + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. @@ -46,6 +48,8 @@ Configuration of a paraprobe-clusterer tool run in atom probe microscopy. + Version specifier of this application definition. @@ -80,7 +84,7 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -139,6 +143,29 @@ + Specifies if the tool should try to recover for each position the closest @@ -149,6 +176,13 @@ + This process performs a cluster analysis on a reconstructed dataset @@ -228,7 +262,14 @@ - + + How should iontypes be interpreted/considered during the cluster analysis. Different options exist how iontypes are interpreted (if considered at all) @@ -258,6 +299,7 @@ at a position that the cluster has two members. This multiplicity affects the size of the feature and chemical composition. + @@ -289,7 +331,7 @@ specific modification known as the maximum-separation method in the atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ - + Strategy how runs are performed with different parameter: @@ -329,13 +371,16 @@ + Settings for the OPTICS clustering algorithm. * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ - + Strategy how runs are performed with different parameter: @@ -377,7 +422,7 @@ See also this documentation for details about the parameter. Here we use the terminology of the hdbscan documentation. - + Strategy how runs are performed with different parameter: @@ -427,4 +472,6 @@ + diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml index ffedb91510..dfa6181a6c 100644 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -65,7 +65,7 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -145,6 +145,7 @@ giving an exact solution. + Paraprobe-distancer enables the computation of the Euclidean shortest distance for each member of a set of points against a set of triangles. @@ -234,12 +235,21 @@ + Maximum distance for which distances are computed when method is skin. + + diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml index 5dcd3fa915..00e5b4c730 100644 --- a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml @@ -31,6 +31,8 @@ Configuration of a paraprobe-intersector tool run in atom probe microscopy. + Version specifier of this application definition. @@ -59,7 +61,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -89,7 +91,7 @@ analyses the tool should execute as part of the analysis. - + Tracking volume_volume_spatial_correlation is the process of building logical relations between volumetric features based on meshes, their proximity and @@ -161,6 +163,7 @@ both objects are still considered within proximity. + Specifies if the tool stores the so-called forward relations between @@ -186,10 +189,14 @@ This identifier can be used to label the current set. The label effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in M. Kühbach - et al. 2022, this identifier takes the role of the time variable k. + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier + takes the role of the time variable :math:`k`. + The total number of distinguished feature sets FEATURE. @@ -208,7 +215,7 @@ - + Descriptive category explaining what these features are. @@ -225,6 +232,7 @@ surface meshes of the members of the set as instances of NXcg_polyhedron_set. + Version identifier of the file such as a secure hash which documents @@ -239,11 +247,14 @@ Currently groupname_geometry_prefix/object<ID>/polyhedron. - + Array of identifier whereby the path to the geometry data can be interferred automatically. + + + @@ -258,10 +269,14 @@ This identifier can be used to label the next_set. The label effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in M. Kühbach - et al. 2022, this identifier takes the role of the time variable k+1. + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier + takes the role of the time variable :math:`k + 1`. + The total number of distinguished feature sets FEATURE. @@ -280,7 +295,7 @@ - + Descriptive category explaining what these features are. @@ -297,6 +312,7 @@ surface meshes of the members of the set as instances of NXcg_polyhedron_set. + Version identifier of the file such as a secure hash which documents @@ -311,15 +327,20 @@ Currently groupname_geometry_prefix/object<ID>/polyhedron. - + Array of identifier whereby the path to the geometry data can be interferred automatically. + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml index db73771443..5a2c720e31 100644 --- a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -84,7 +84,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -171,6 +171,7 @@ the edge of the dataset. This model can be used to detect and control various sources of bias in the analyses. + Name of the HDF5 file which contains vertex coordinates and facet @@ -203,6 +204,7 @@ The tool enables to inject precomputed distance information for each point/ion which can be used for further post-processing and analysis. + Name of an HDF5 file which contains the ion distances. @@ -221,13 +223,21 @@ - - - For now a support field for the tool to identify how many individual - delocalization analyses for the above-mentioned dataset and supplementary - files are executed as part of the high-throughput analysis. - - + + Discretization of the ion point cloud on a three-dimensional grid. @@ -247,11 +257,13 @@ settings which were used for computing this already existent delocalization are specified in the same manner as they were. + + Matrix of isotope vectors representing iontypes. @@ -293,19 +305,21 @@ an edge length of values in gridresolutions. + - Half the width of a (2n+1)^3 cubic kernel of voxel beyond - which the Gaussian Ansatz function will be truncated. + Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel + beyond which the Gaussian Ansatz function will be truncated. Intensity beyond the kernel is refactored into the kernel via a normalization procedure. - Variance of the Gaussian Ansatz kernel sigma_x = sigma_y = 2*sigma_z. + Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`. + How should the results of the kernel-density estimation be computed @@ -326,6 +340,12 @@ Specifies if the tool should report the delocalization 3D field values. + + Optional computation of iso-surfaces after each computed delocalization @@ -368,14 +388,21 @@ In the results of each paraprobe-nanochem run, these proxy objects are listed separately to allow users to quantify and analyze in detail the differences when accounting for these objects or not. - Especially this is relevant in atom probe microscopy are small - in the sense that they contain few (many a few dozen) objects. - Even though such a dataset may give statistically significant - results for compositions this does not mean it necessarily yields - also statistically significant and unbiased results for three-dimensional - object analyses. Being able to quantify these effects and making - atom probers aware of these subtleties was one of the main reasons - why the paraprobe-nanochem tool was implemented. + Especially this is relevant in atom probe microscopy as objects + can contain a few dozen atoms only. + Users should be aware that results from fairing operations should + be compared to results from analyses where all objects at the edge + of the dataset have been removed. + + Also users should be careful with overestimating the statistical + significance of their dataset especially when using atom probe + to compare multiple descriptors: Even though a dataset may give + statistically significant results for compositions, this does not + necessarily mean it will yield also statistically significant + and unbiased results for three-dimensional object analyses. + Being able to quantify these effects and making atom probers + aware of these subtleties was one of the main reasons why the + paraprobe-nanochem tool was implemented. @@ -403,6 +430,7 @@ In short, a distance-based approach is rigorous and more flexible. + Array of iso-contour values. For each value the tool computes @@ -416,6 +444,7 @@ * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + Specifies if the tool should report the triangle soup which represents @@ -480,6 +509,7 @@ (aspect ratios). + Specifies if the tool should report for each closed polyhedron @@ -520,6 +550,9 @@ by the fact that the dataset is finite. + Specifies if the tool should analyze a doppelganger/proxy mesh for @@ -593,6 +626,11 @@ + Analyses of interfacial excess. @@ -671,6 +709,8 @@ + The interface model is the result of a previous (set of) processing @@ -815,6 +855,7 @@ X, Y, Z coordinates of disjoint control point read from an HDF5 file named according to control_point_file. + @@ -859,6 +900,7 @@ which specify how the initial triangles of the mesh should be iteratively refined by edge splitting and related mesh refinement operations. + @@ -871,8 +913,11 @@ be eventually relocated. The larger the DCOM radius is relative to the target_edge_length the more likely it is that vertices will be relocated so substantially that eventually triangle self-intersections - can occur. + can occur. If the code detects these it warns and stops in a + controlled manner so that the user can repeat the analyses + with a smaller value. + @@ -914,8 +959,8 @@ Users should be aware that the latter intersection analysis is strictly speaking not a volumetric intersection analysis as such one is much more involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder piercing - or laying completely inside the polyhedron. For this the polyhedron has + in which case one would have to test robustly if the cylinder pierces + or is laying completely inside the polyhedron. For this the polyhedron has to be tessellated into convex polyhedra as otherwise tests like the Gilbert-Johnson-Keerthi algorithm would not be applicable. @@ -936,6 +981,16 @@ Furthermore, the tool can be instructed to compute for each (or a selected sub-set of facet) a set of differently oriented profiles. + The feature mesh enables the injection of previously computed triangle @@ -975,6 +1030,11 @@ normals of the facets. + @@ -985,6 +1045,7 @@ The tool enables to inject precomputed distance information for each point which can be used for further post-processing and analysis. + Name of an HDF5 file which contains ion distances. @@ -1012,6 +1073,7 @@ + In which directions should the tool probe for each ROI. @@ -1020,12 +1082,18 @@ + For each ROI, how high (projected on the cylinder axis) should the cylindrical ROI be. + For each ROI, how wide (radius) should the cylindrical ROI be. @@ -1033,6 +1101,11 @@ + diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml index 9f9625db36..4b3d3d633a 100644 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -42,6 +42,8 @@ Configuration of a paraprobe-ranger tool run in atom probe microscopy. + Version specifier of this application definition. @@ -76,7 +78,7 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -100,18 +102,6 @@ - - - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - - - - - How many molecular_ion_search processes should - the tool execute as part of the analysis. - - @@ -162,7 +152,7 @@ - + A list of pairs of number of protons and either the value 0 (per row) or the mass number for all those isotopes which are assumed present @@ -178,6 +168,15 @@ + A list of pairs of number of protons and mass number for all isotopes @@ -259,6 +258,17 @@ specimen can differ by orders of magnitude. + Report the charge state of the ions. diff --git a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml index bb3799a57a..6e8583ece5 100644 --- a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml @@ -31,6 +31,8 @@ Configuration of a paraprobe-selector tool run in atom probe microscopy. + Version specifier of this application definition. @@ -59,7 +61,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -110,6 +112,7 @@ + diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml index 84ebc893e1..3db0b7f1fb 100644 --- a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -46,6 +46,8 @@ Configuration of a paraprobe-spatstat tool run in atom probe microscopy. + Version specifier of this application definition. @@ -74,7 +76,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -104,250 +106,267 @@ the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + - - - - - - - + + + + + - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - + + + + + + The tool enables to inject precomputed distances of each ion to a + representation of the edge of the dataset which can be used to + control and substantially reduce edge effects when computing + spatial statistics. + + + + Name of an HDF5 file which contains ion-to-edge distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-edge distance values for each ion. + The shape of the distance values has to match the length + of the ion positions array in dataset/dataset_name_reconstruction + and dataset_name_mass_to_charge respectively. + + + + + Threshold to define how large an ion has to lay at least far away + from the edge of the dataset so that the ion can act as a source, + i.e. that an ROI is placed at the location of the ion and its + neighbors are analyzed how they contribute to the computed statistics. + + The ion_to_edge_distances threshold can be combined with a threshold + for the ion_to_feature_distances. + Specifically, if ion_to_feature_distances are loaded an ion only + acts as a source if both threshold criteria are met. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + + - - - - - - - The tool enables to inject precomputed distances of each ion to a - representation of the edge of the dataset which can be used to - control and substantially reduce edge effects when computing spatial statistics. - - + - Name of an HDF5 file which contains ion-to-edge distances. + In addition to spatial filtering, and considering how far ions lie + to the edge of the dataset, it is possible to restrict the analyses + to a sub-set of ions within a distance not farther away to a feature than + a threshold value. - - + + + Name of an HDF5 file which contains ion-to-feature distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-feature distance values for each ion. + + + + + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. + + Recall that the ion_to_feature_distances threshold is combined + with the ion_to_edge_distances threshold. + + + + + - Absolute HDF5 path to the dataset with the - ion-to-edge distance values for each ion. - The shape of the distance values has to match the length - of the ion positions array in dataset/dataset_name_reconstruction - and dataset_name_mass_to_charge respectively. + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. - + + + + + + - Threshold to define how large an ion has to lay at least far away - from the edge of the dataset so that the ion can act as a source, - i.e. that an ROI is placed at the location of the ion and its - neighbors are analyzed how they contribute to the computed statistics. + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. + + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. - The ion_to_edge_distances threshold can be combined with a threshold - for the ion_to_feature_distances. - Specifically, if ion_to_feature_distances are loaded an ion only - acts as a source if both threshold criteria are met. + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. + + + + + + + - - - - In addition to spatial filtering, and considering how far ions lie - to the edge of the dataset, it is possible to restrict the analyses - to a sub-set of ions within a distance not farther away to a feature than - a threshold value. - - + - Name of an HDF5 file which contains ion-to-feature distances. + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + - + - Absolute HDF5 path to the dataset with the - ion-to-feature distance values for each ion. + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + + + + + + + - + + - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that the ion_to_feature_distances threshold is combined - with the ion_to_edge_distances threshold. + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + + + + - - - - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - - - - - - - - - - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - - - - - - - - - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - - - - - - - - - Specifies which spatial statistics to compute. - - + - Compute k-th nearest neighbour statistics. + Specifies which spatial statistics to compute. - + - Order k. + Compute k-th nearest neighbour statistics. - - + + + Order k. + + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + - Minimum value, increment, and maximum value of the histogram binning. + Compute radial distribution function. - - - - - - - - Compute radial distribution function. - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml index ac2b19733b..8ec33204e2 100644 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -41,6 +41,8 @@ Configuration of a paraprobe-surfacer tool run in atom probe microscopy. + Version specifier of this application definition. @@ -75,7 +77,7 @@ information included when this configuration file was created. - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -144,6 +146,7 @@ + @@ -192,6 +195,7 @@ + When using the kuehbach preprocessing, this is the width of the kernel for identifying which ions are in voxels close to the @@ -226,6 +230,7 @@ though such as watertightness and proximity constraints on the resulting wrapping. + @@ -235,11 +240,12 @@ - + Array of alpha values to use when alpha_value_choice is set_of_values or when alpha_value_choice is set_of_alpha_wrappings. + @@ -250,6 +256,7 @@ set_of_alpha_wrappings. The array of alpha_values and offset_values define a sequence of (alpha and offset value). + @@ -274,6 +281,7 @@ + diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml index ced8e4ba14..3f846cac1c 100644 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -31,6 +32,8 @@ Configuration of a paraprobe-tessellator tool run in atom probe microscopy. + Version specifier of this application definition. @@ -59,7 +62,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -133,6 +136,10 @@ + @@ -168,10 +175,44 @@ By default, a Voronoi tessellation is computed for all ions in the filtered point cloud. + + Specifies if the tool should report the volume of each cell. @@ -197,13 +238,14 @@ by the presence of the boundary. - - - Maximum distance for which cells are eroded. - - + diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml index d7f66157d7..e230219d3b 100644 --- a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -31,6 +31,8 @@ Configurations of a paraprobe-transcoder tool run in atom probe microscopy. + Version specifier of this application definition. @@ -59,7 +61,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -84,6 +86,9 @@ + diff --git a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml index a6214b3e6b..d2398a8d90 100644 --- a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml @@ -40,12 +40,15 @@ Results of a paraprobe-clusterer tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -54,6 +57,7 @@ + Given name of the program/software/tool with which this NeXus @@ -112,7 +116,7 @@ current working directory. - + A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -153,6 +157,8 @@ paraprobe defined, which specifies the coordinate system. In which all positions are defined. + The individual coordinate systems which should be used. @@ -169,6 +175,7 @@ + @@ -235,6 +242,18 @@ dataset. + Which identifier is the first to be used to label a cluster. @@ -247,6 +266,31 @@ Numerical identifier have to be strictly increasing. + The evaporation sequence identifier to figure out which ions @@ -256,6 +300,7 @@ + The raw labels from the DBScan clustering backend process. @@ -273,6 +318,7 @@ + Matrix of numerical label for each member in the set. @@ -283,6 +329,12 @@ + The array of weight which specifies how surely/likely the @@ -321,16 +373,31 @@ In addition to the detailed storage which members was grouped to which feature/group summary statistics are stored under this group. + Total number of members in the set which are categorized as noise. + Total number of members in the set which are categorized as a core point. + Total number of clusters (excluding noise and unassigned). @@ -356,6 +423,8 @@ + + @@ -405,18 +474,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml index 5acc178db4..20035c0486 100644 --- a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml @@ -40,12 +40,15 @@ Results of a paraprobe-distancer tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -54,6 +57,7 @@ + Given name of the program/software/tool with which this NeXus @@ -69,7 +73,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -112,7 +116,7 @@ current working directory. - + A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -165,6 +169,7 @@ + @@ -182,6 +187,7 @@ The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -206,11 +212,13 @@ - + A bitmask which identifies which of the triangles in the set were considered. Usually these are all but sometimes users may wish to filter certain portions of the triangles out. + If window_triangles is not provided it means that + all triangles were taken. @@ -265,6 +273,7 @@ The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -300,6 +309,7 @@ + @@ -349,18 +359,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml index d7a9ed0a2d..7daf7e57b0 100644 --- a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml @@ -61,11 +61,14 @@ Results of a paraprobe-intersector tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -74,6 +77,7 @@ + Given name of the program/software/tool with which this NeXus @@ -89,7 +93,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -100,10 +104,18 @@ Possibility for leaving a free-text description about this analysis. - + ISO 8601 formatted time code with local time zone offset to UTC - information included when this results file was created. + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. @@ -160,8 +172,9 @@ + - + The results of an overlap/intersection analysis. @@ -302,6 +315,8 @@ + + @@ -351,18 +366,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index 37034ba761..11f52ab6da 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -51,6 +51,8 @@ The cardinality/total number of cells/grid points in the delocalization grid. + The total number of XDMF values to represent all faces of triangles via XDMF. @@ -70,12 +72,15 @@ Results of a paraprobe-nanochem tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -84,6 +89,7 @@ + Given name of the program/software/tool with which this NeXus @@ -142,7 +148,7 @@ current working directory. - + A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -183,6 +189,8 @@ paraprobe defined, which specifies the coordinate system. In which all positions are defined. + The individual coordinate systems which should be used. @@ -199,6 +207,7 @@ + @@ -236,7 +245,7 @@ - + The weighting model specifies how mark data are mapped to a weight @@ -257,6 +266,8 @@ + A list of elements (via proton number) to consider for the @@ -331,7 +342,7 @@ - + How results of the kernel-density estimation were computed into quantities. By default the tool computes the total number @@ -413,12 +424,16 @@ - + + Reference to or definition of a coordinate system with which the positions and directions are interpretable. + If the coordinate system is not specified the paraprobe + coordinate system is used. + Integer which specifies the first index to be used for @@ -521,7 +536,7 @@ - + Name of the boundaries. E.g. left, right, front, back, bottom, top, The field must have as many entries as there are number_of_boundaries. @@ -546,12 +561,15 @@ + The result of the delocalization based on which subsequent iso-surfaces will be computed. In commercial software so far there is not a possibility to export such grid. + @@ -573,6 +591,7 @@ + Cell center of mass positions along y. @@ -623,8 +642,11 @@ The three-dimensional gradient nabla operator applied to scalar_field_magnitude. + + @@ -645,6 +667,7 @@ + Cell center of mass positions along y. @@ -697,10 +720,14 @@ The shape of the kernel is that of a cuboid of extent 2*kernel_extent[i] + 1 in each dimension i. + + Sigma of the kernel in each dimension in the paraprobe @@ -720,6 +747,7 @@ + An iso-surface is the boundary between two regions across which @@ -864,6 +892,8 @@ + @@ -891,12 +921,22 @@ Triangle normals are oriented in the direction of the gradient vector of the local delocalized scalar field. - :math:`$\sum_{x, y, z} {\nabla{c}_i}^2$`. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. + Triangle normals are oriented in the direction of the @@ -938,7 +978,7 @@ - + @@ -961,8 +1001,8 @@ by triangles. Currently, the tool distinguishes at most three types of features: - 1. So-called objects, i.e. not necessarily watertight features - convex polyhedra + 1. So-called objects, i.e. necessarily watertight features + represented polyhedra. 2. So-called proxies, i.e. features that were replaced by a proxy mesh and made watertight. 3. Remaining triangle surface meshes of arbitrary shape and @@ -972,11 +1012,11 @@ Some of them may be precipitates, some of them may be poles, some of them may be segments of dislocation lines or other crystal defects which are decorated (or not) with solutes. - - Each type of feature needs to be registered in the feature_type - dictionary. Type identifiers (keywords are integer), values - are human-readable names like object, proxy, undefined + The identifier which the triangle_soup connectivity analysis @@ -995,7 +1035,7 @@ - + The array of values for each keyword of the feature_type dictionary. @@ -1023,12 +1063,18 @@ + Details for features which are (closed) objects. Identifier have to exist in feature_identifier - `:mathcal:$identifier \in feature_identifier$`. + :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. + @@ -1053,6 +1099,7 @@ + Oriented bounding box aspect ratio. YX versus ZY. @@ -1074,17 +1121,21 @@ + A simple approach to describe the entire set of hexahedra when the main intention is to store the shape of the hexahedra for visualization. + + @@ -1140,6 +1191,10 @@ + @@ -1152,6 +1207,7 @@ + @@ -1223,6 +1279,10 @@ + @@ -1235,6 +1295,7 @@ + @@ -1264,6 +1325,8 @@ + Details for features which are so-called proxies, i.e. objects @@ -1271,8 +1334,9 @@ processing their partial triangulated_surface_mesh (hole filling, refinement). Identifier have to exist in feature_identifier - `:mathcal:$identifier \in feature_identifier$`. + :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. + @@ -1283,14 +1347,16 @@ + Details for those proxies close to edge, i.e. those which have at least one ion which lays closer to a modelled edge of the dataset than threshold. Identifier have to exist in feature_identifier - `:mathcal:$identifier \in feature_identifier$`. + :math:`\textnormal{identifier} \in \textnormal{feature_identifier}`. + @@ -1311,6 +1377,8 @@ + Count or weight which, when divided by total @@ -1325,6 +1393,10 @@ + @@ -1337,6 +1409,7 @@ + @@ -1391,6 +1464,8 @@ + Count or weight which, when divided by total @@ -1405,6 +1480,10 @@ + @@ -1417,6 +1496,7 @@ + @@ -1457,6 +1537,13 @@ The multiplicity whereby the ion position is accounted for irrespective whether the ion is considered as a decorator of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. @@ -1464,27 +1551,26 @@ - The multiplicity whereby the ion position is accounted - for when the ion is considered´one which is a decorator - of the interface. + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. - + - The equation of the plane that is fitting initially. + The equation of the plane that is fitted initially. - - - - The four parameter ax + by + cz + d = 0 which define the plane. - - - - - + + + The four parameter :math:`ax + by + cz + d = 0` which define the plane. + + + + + + The triangle surface mesh representing the interface model. @@ -1523,6 +1609,7 @@ + @@ -1599,7 +1686,7 @@ - + @@ -1640,6 +1727,7 @@ + @@ -1716,7 +1804,7 @@ - + @@ -1757,6 +1845,7 @@ + The number of atoms in each ROI. @@ -1798,6 +1887,9 @@ + @@ -1847,18 +1939,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml index a7a22f42ef..e0b9b736d6 100644 --- a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml @@ -41,12 +41,15 @@ Results of a paraprobe-ranger tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -55,6 +58,7 @@ + Given name of the program/software/tool with which this NeXus @@ -70,7 +74,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -113,7 +117,7 @@ current working directory. - + A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -166,6 +170,7 @@ + @@ -174,6 +179,7 @@ ion is considered of the default unknown type with a 0 as its respective value in the iontypes array. + The length of the isotope_vector used to describe molecular ions. @@ -185,12 +191,6 @@ - - - - - - The iontype ID for each ion that was best matching, stored in the @@ -205,34 +205,6 @@ - - - The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. For the here computed - charged_iontypes the information for each (molecular) ion defined - in e.g. RNG or RRNG files is analyzed for which differently charge - states are possible. As an example while iontypes might only consider - if an ion is Al charged_iontypes will resolve if it is Al1+, Al2+, or - Al3+. To decide the charge state a recursive algorithm is used which - enumerates first all possible isotopic variants of a given molecular - ion build from a specific set of elements. All variants are then - analyzed for their natural abundance and filtered. The sub-set of - all significantly abundant variants is inspected if their charge - states are all the same. If only one significant variant is found - its charge state is assumed the relevant. If multiple significant - variants are found and all their charge states is the same this - charge state will be the decisive one. However, if multiple variants - are found and their charge state differs such a case highlights that - the charge state analysis is underconstrained and thus the charge - state is set to 0. Underconstrained cases are possible because - an arbitrary combination of elements into a molecular ion that is - constrained only by an additional single interval of mass-to-charge - state ratios is not necessarily sufficient. - - - - - A bitmask which identifies exactly all those ions ranged irrespective @@ -244,6 +216,7 @@ The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -300,6 +273,7 @@ The mass of each molecular ion without considering relativistic or quantum effects. + @@ -358,6 +332,7 @@ does neither needs measured ion position nor mass-to-charge-state ratio values. + The length of the isotope_vector used to describe molecular ions. @@ -371,6 +346,7 @@ + @@ -420,18 +396,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml index 70c38c656d..7211093546 100644 --- a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml @@ -35,12 +35,15 @@ Results of a paraprobe-selector tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -49,6 +52,7 @@ + Given name of the program/software/tool with which this NeXus @@ -64,7 +68,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -100,7 +104,7 @@ - + A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -153,6 +157,7 @@ + @@ -165,6 +170,7 @@ The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -190,6 +196,7 @@ + @@ -238,18 +245,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml index 31e55ad32c..643e18a695 100644 --- a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml @@ -35,12 +35,15 @@ Results of a paraprobe-spatstat tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -49,6 +52,7 @@ + Given name of the program/software/tool with which this NeXus @@ -64,7 +68,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -107,7 +111,7 @@ current working directory. - + A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -160,6 +164,7 @@ + @@ -172,6 +177,7 @@ The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -227,7 +233,7 @@ - + Cumulated @@ -235,6 +241,14 @@ + + + Cumulated and normalized by total counts + + + + + @@ -253,7 +267,7 @@ - + Cumulated @@ -261,8 +275,17 @@ + + + Cumulated and normalized by total counts + + + + + + @@ -312,18 +335,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml index 9a07bf5138..421670cdae 100644 --- a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml @@ -55,12 +55,15 @@ Results of a paraprobe-surfacer tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -69,6 +72,7 @@ + Given name of the program/software/tool with which this NeXus @@ -84,7 +88,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -127,7 +131,7 @@ current working directory. - + A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -180,6 +184,7 @@ + @@ -230,6 +235,8 @@ This polyhedron is not necessarily convex. For some algorithms there is no guarantee that the resulting mesh yields a watertight mesh. + @@ -240,12 +247,14 @@ have been filtered out to reduce the computational costs of the alpha complex analysis. + Number of ions covered by the mask. The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -300,10 +309,10 @@ - Integer which specifies the first index to be used for distin- - guishing triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined - on the interval [identifier_offset, identifier_offset+c-1]. + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. @@ -375,7 +384,7 @@ The accumulated volume of all interior tetrahedra. - + Number of vertices. @@ -415,6 +424,7 @@ + @@ -464,18 +474,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml index 952fead4b8..3fcb3d2be2 100644 --- a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml @@ -40,12 +40,15 @@ Results of a paraprobe-tessellator tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -54,6 +57,7 @@ + Given name of the program/software/tool with which this NeXus @@ -69,7 +73,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -112,7 +116,7 @@ current working directory. - + A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -165,6 +169,7 @@ + @@ -185,6 +190,7 @@ The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -215,12 +221,13 @@ are truncated by the global axis-aligned bounding box, i.e. boundaries of the threads are ignored. - + Number of points covered by the mask. The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -245,6 +252,7 @@ + A bitmask which identifies which of points have Voronoi cells that @@ -252,12 +260,13 @@ The left wall has the negative x axis of the paraprobe coordinate system as the outer unit normal. - + Number of points covered by the mask. The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -289,12 +298,13 @@ The right wall has the positive x axis of the paraprobe coordinate system as the outer unit normal. - + Number of points covered by the mask. The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -326,12 +336,13 @@ The front wall has the negative y axis of the paraprobe coordinate system as the outer unit normal. - + Number of points covered by the mask. The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -363,12 +374,13 @@ The rear wall has the positive y axis of the paraprobe coordinate system as the outer unit normal. - + Number of points covered by the mask. The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -400,12 +412,13 @@ The left wall has the negative z axis of the paraprobe coordinate system as the outer unit normal. - + Number of points covered by the mask. The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -437,12 +450,13 @@ The left wall has the positive z axis of the paraprobe coordinate system as the outer unit normal. - + Number of points covered by the mask. The mask value for most may be 0. + Number of bits assumed matching on a default datatype. @@ -508,6 +522,12 @@ + Integer which specifies the first index to be used for distinguishing @@ -578,6 +598,7 @@ + @@ -627,18 +648,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml index 0a2f1c8870..93e2363ba0 100644 --- a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -47,16 +48,24 @@ Total number of integers in the supplementary XDMF topology array. + + + Number of ions probed in the combinatorial analysis of the charge states + + Results of a paraprobe-transcoder tool run. + Version specifier of this application definition. + Official NeXus NXDL schema with which this file was written. @@ -65,6 +74,7 @@ + Given name of the program/software/tool with which this NeXus @@ -80,7 +90,7 @@ - + Ideally, a (globally persistent) unique identifier for referring to this analysis. @@ -123,7 +133,7 @@ current working directory. - + A statement whether the paraprobe-tool executable managed to process the analysis or failed prematurely. @@ -176,6 +186,7 @@ + @@ -189,6 +200,68 @@ + On a mid term perspective we would like to evolve the paraprobe-toolbox @@ -291,17 +364,26 @@ in this application definition for paraprobe-transcoder results files mirror the definitions of the NXapm for consistency reasons. + Mass-to-charge-state ratio values. + + Three-dimensional reconstructed positions of the ions. @@ -324,10 +406,90 @@ + + + Details and results of the combinatorial analyses of this + range definition to identify the charge_state for an ion. + + + + Currently charge_state not charge! + + + + + + + + Specific isotopes building each candidate matching the range. + + + + + + + + + Accumulated mass of the isotopes in each candidate. + Not corrected for quantum effects. + + + + + + + + + Product of natural abundance of the isotopes per candidate. + + + + + + + + Filter criterion on the product of the natural abundances + computed from each isotope building the (molecular) ion. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + + + + + Filter criterion on the minimum half life which all isotopes + building the (molecular) ion need to have to consider the + candidate. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + + + + + + If the value is zero/false it means that non-unique solutions + are accepted. These are solutions where multiple candidates + differ in their isotopes but have the same charge. + + + + @@ -377,18 +539,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXbeam.nxdl.xml b/contributed_definitions/NXbeam.nxdl.xml index ffbe10b857..f6ab5e6561 100644 --- a/contributed_definitions/NXbeam.nxdl.xml +++ b/contributed_definitions/NXbeam.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays @@ -17,13 +38,13 @@ - Properties of the neutron or X-ray beam at a given location. - - It will be referenced by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. - Note that variables such as the incident energy could be scalar values or arrays. - This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, - time distribution etc. at each beamline component. - Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + Properties of the neutron or X-ray beam at a given location. + + It will be referenced by beamline component groups within the ':'ref':'`NXinstrument` group or by the ':'ref':'`NXsample` group. + Note that variables such as the incident energy could be scalar values or arrays. + This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, + time distribution etc. at each beamline component. + Otherwise, its most likely use is in the ':'ref':'`NXsample` group in which it defines the results of the neutron scattering by the sample, e.g., energy transfer, polarizations. @@ -37,9 +58,9 @@ Several other use cases are permitted, depending on the presence of other incident_energy_X fields. * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, + * In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_energy_weights as a 2D array. * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. @@ -153,15 +174,15 @@ Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. Correct parsing can still be implemented by using this attribute. - | Fill with: + | Fill with':' - * The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: 'farad' for capacitance). + * The unit unidata symbol if the unit has one (Example':' 'T' for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example':' 'farad' for capacitance). * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. - Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. - Here: SI units are 'V2/m2'. + Example':' for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. + Here':' SI units are 'V2/m2'. @@ -174,7 +195,7 @@ - Here: SI units are 'V2/m2'. + Here':' SI units are 'V2/m2'. @@ -219,7 +240,7 @@ - Here: SI units are ''J/m2'', customary ''mJ/cm2''. + Here':' SI units are ''J/m2'', customary ''mJ/cm2''. @@ -272,14 +293,14 @@ - .. index:: plotting + .. index':'':' plotting Declares which child group contains a path leading - to a :ref:`NXdata` group. + 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 86a0453c7e..7a1b51318b 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -24,7 +24,7 @@ - The symbols used in the schema to specify e.g. dimensions of arrays + The symbols used in the schema to specify e.g. dimensions of arrays @@ -43,7 +43,7 @@ - Subclass of NXprocess to describe post-processing calibrations. + Subclass of NXprocess to describe post-processing calibrations. diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml index a7e2d7828c..ae2e431e9e 100644 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -22,6 +22,9 @@ # For further information, see http://www.nexusformat.org --> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -31,6 +34,7 @@ The dimensionality of the alpha shape, for now 2 or 3. + The number of edges. @@ -84,6 +88,7 @@ Specifically when computed with the CGAL, the mode specifies if singular faces are removed (regularized) of the alpha complex. + @@ -101,11 +106,24 @@ in the case of alpha_wrapping. + Point cloud for which the alpha shape or wrapping should be computed. + Triangle soup for which the alpha wrapping should be computed. @@ -116,5 +134,18 @@ A meshed representation of the resulting shape. + + diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index e71adff6fd..310689f198 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -21,6 +21,8 @@ # # For further information, see http://www.nexusformat.org --> + @@ -86,6 +88,10 @@ + @@ -117,6 +123,7 @@ which the positions and directions are interpretable. + Interior volume of each cylinder @@ -150,4 +157,9 @@ + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index bcc121fe9c..25c80dca79 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -102,6 +103,7 @@ which the positions and directions are interpretable. + Are the ellipsoids closed or hollow? @@ -120,6 +122,7 @@ + Direction unit vector which points along the largest half-axes. diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 270582a939..a62ee03374 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -85,6 +86,7 @@ Dimensionality. + Array which specifies of how many vertices each face is built. @@ -211,6 +213,7 @@ + If true indicates that the vertices are all placed at different positions diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index 2ad1e03bb8..3817172989 100644 --- a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -53,4 +53,5 @@ + diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index e3929b098b..2586709ef9 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -97,6 +97,8 @@ which the positions and directions are interpretable. + Integer which specifies the first index to be used for distinguishing @@ -136,11 +138,14 @@ + A tight bounding box or sphere or bounding primitive about the grid. + How many distinct boundaries are distinguished? @@ -148,11 +153,15 @@ six sides can be distinguished, each making an own boundary. - + - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. + Name of domain boundaries of the simulation box/ROI e.g. left, right, + front, back, bottom, top. + + + + diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index ea731f4f38..0451f3cf86 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -22,6 +22,7 @@ # For further information, see http://www.nexusformat.org --> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -86,6 +87,7 @@ identifiers also start at 1. + The position of the vertices. @@ -152,7 +154,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: @@ -165,4 +167,8 @@ of microstructural objects like crystals/grains. + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index f9ff489f56..081d7f72c6 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -21,6 +21,11 @@ # # For further information, see http://www.nexusformat.org --> + @@ -88,6 +93,7 @@ + A qualitative description of each hexahedron/cuboid/cube/box. @@ -203,22 +209,27 @@ + + + A simple approach to describe the entire set of hexahedra when the main intention is to store the shape of the hexahedra for visualization. + Disentangled representations of the mesh of specific hexahedra. + Disentangled representation of the planar graph that each hexahedron represents. Such a description simplifies topological processing diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index 25a58d5b53..270d67537d 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -68,4 +68,7 @@ + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index 2486ad7ad8..7454bb625e 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -79,6 +79,7 @@ + A qualitative description of each parallelogram/rectangle/square/box. @@ -159,19 +160,24 @@ + + + A simple approach to describe the entire set of parallelograms when the main intention is to store the shape of the parallelograms for visualization. + Disentangled representations of the mesh of specific parallelograms. + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index efa99c5d1c..2aa9ec3709 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -22,6 +22,9 @@ # For further information, see http://www.nexusformat.org --> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -36,12 +39,14 @@ The cardinality of the set, i.e. the number of polygons. + The total number of vertices when visiting every polygon. + Computational geometry description of a set of polygons in Euclidean space. @@ -95,14 +100,18 @@ + A simple approach to describe the entire set of polygons when the main intention is to store the shape of the polygons for visualization. + + @@ -153,4 +162,64 @@ Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 5525812aa7..3faa043d93 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -21,6 +21,15 @@ # # For further information, see http://www.nexusformat.org --> + @@ -61,6 +70,7 @@ + Interior volume @@ -126,6 +136,7 @@ which the qualifiers and mesh data are interpretable. + Integer which specifies the first index to be used for distinguishing @@ -150,22 +161,34 @@ + + A simple approach to describe the entire set of polyhedra when the main intention is to store the shape of the polyhedra for visualization. + Disentangled representations of the mesh of specific polyhedron. + Disentangled representation of the planar graph that each polyhedron represents. Such a description simplifies topological processing or analyses of mesh primitive operations and neighborhood queries. + diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index fc85478336..bda0b73eaf 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -36,6 +36,8 @@ The cardinality of the set, i.e. the number of polylines. + The number of vertices, supporting the polylines. @@ -57,6 +59,8 @@ + The total number of vertices, irrespective of their eventual uniqueness, @@ -103,6 +107,10 @@ + Positions of the vertices which support the members of the polyline set. @@ -146,12 +154,13 @@ so on and so forth. Using the (cumulated) counts in number_of_vertices, the vertices of the n-th polyline can be accessed on the following array index interval: - :math:`$[\sum_i = 0}^{i = N-1}, \sum_{i=0}^{i=N}]$`. + :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. + The length of each polyline. diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml index 96b299aa8d..aafda71ad4 100644 --- a/contributed_definitions/NXcg_roi_set.nxdl.xml +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -34,4 +35,6 @@ + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 80f53d17e4..bbc8459363 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -98,6 +99,7 @@ which the positions and directions are interpretable. + Are the spheres closed or hollow? diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 4cae3e4229..2f7185551e 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -21,6 +21,11 @@ # # For further information, see http://www.nexusformat.org --> + @@ -57,6 +62,7 @@ + Interior volume @@ -107,6 +113,18 @@ which the qualifiers and mesh data are interpretable. + Integer which specifies the first index to be used for distinguishing @@ -131,7 +149,9 @@ + + A simple approach to describe the entire set of tetrahedra when the main intention is to store the shape of the tetrahedra for visualization. @@ -139,11 +159,13 @@ + Disentangled representations of the mesh of specific tetrahedra. + Disentangled representation of the planar graph that each tetrahedron represents. Such a description simplifies topological processing diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 8bf4467570..78e16c7512 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -76,14 +76,18 @@ + A simple approach to describe the entire set of triangles when the main intention is to store the shape of the triangles for visualization. + + diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index 06210e334b..a83c63553f 100644 --- a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -33,6 +33,19 @@ The mesh may be self-intersecting and have holes but the triangles must not be degenerated. + diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index cf2213b4ac..a6f606a7cb 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -21,6 +21,9 @@ # # For further information, see http://www.nexusformat.org --> + diff --git a/contributed_definitions/NXchemical_composition.nxdl.xml b/contributed_definitions/NXchemical_composition.nxdl.xml index 4b6309c258..6f1c2e6c80 100644 --- a/contributed_definitions/NXchemical_composition.nxdl.xml +++ b/contributed_definitions/NXchemical_composition.nxdl.xml @@ -35,6 +35,10 @@ (Chemical) composition of a sample or a set of things. + Total based on which composition information is normalized. diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml index 1192a9289f..68ee6cca76 100644 --- a/contributed_definitions/NXclustering.nxdl.xml +++ b/contributed_definitions/NXclustering.nxdl.xml @@ -64,7 +64,7 @@ How many categorical labels does each object have. - + Reference to a set of objects investigated in a cluster analysis. Objects must have clear integer identifier. @@ -75,11 +75,13 @@ Reference to numeric attribute data for each object. - + Reference to categorical attribute data for each object. + Which identifier is the first to be used to label a cluster. @@ -118,4 +120,5 @@ + diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index c8bd717074..7a96016053 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -23,8 +23,8 @@ --> - Subclass of NXelectronanalyser to describe the electron collection - column of a photoelectron analyser. + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. diff --git a/contributed_definitions/NXcontainer.nxdl.xml b/contributed_definitions/NXcontainer.nxdl.xml index c32854f305..ec050b4628 100644 --- a/contributed_definitions/NXcontainer.nxdl.xml +++ b/contributed_definitions/NXcontainer.nxdl.xml @@ -1,14 +1,14 @@ - + - - - - State of a container holding the sample under investigation. - - A container is any object in the beam path which absorbs the beam and - whose contribution to the overall attenuation/scattering needs to be - determined to process the experimental data. Examples of containers - include glass capillary tubes, vanadium cans, windows in furnaces or - diamonds in a Diamond Anvil Cell. The following figures show a complex - example of a container: - - .. figure:: container/ComplexExampleContainer.png - - A hypothetical capillary furnace. The beam passes from left to right - (blue dashes), passing through window 1, then window 2, before - passing through the downstream wall of the capillary. It is then - scattered by the sample with scattered beams passing through the - upstream wall of the capillary, then windows 4 and 5. As part of the - corrections for a PDF experiment it is necessary to subtract the PDF - of the empty container (i.e. each of the windows and the capillary). - To calculate the PDF of the empty container it is necessary to have - the measured scattering data and to know the nature (e.g. density, - elemental composition, etc.) of the portion of the container which - the beam passed through. - - .. figure:: container/ComplexContainerBeampath.png - - A complete description of the shapes of the container elements with - their orientation relative to the beam and also information on - whether they are upstream or downstream of the sample is also - therefore important. For example, although the windows 2 and 4 have - the same shape, the path taken through them by the beam is very - different and this needs to be modelled. Furthermore, it is not - inconceivable that windows might move during an experiment and thus - the changes to the beampath would need to be accounted for. - - This class encodes the position of the container with respect to the - sample and allows the calculation of the beampath through the container. - It also includes sufficient data to model beam absorption of the - container and a link to a dataset containing a measurement of the - container with nothing inside, to allow data corrections (at a specific - beam energy/measurement time) to be made. - - - - Descriptive name of container. - - - - - Verbose description of container and how it fits into the wider - experimental set up. - - - - - Chemical composition of the material the container is made from. - Specified using CIF conventions. Abbreviated version of CIF - standard: - - * 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. - - * This is the *Hill* system used by Chemical Abstracts. - - - - - Density of the material the container is made from. - - - - - - - - Fraction of the volume of the container occupied by the material - forming the container. - - - - - - - Relative molecular mass of container. - - - - - - - Details of beam incident on container, including the position - relative to the sample (to determine whether the container is - upstream or downstream of the sample). - - - - - Shape of the container. In combination with orientation this - should allow the beampath through the container to be modelled to - allow the adsorption to be calculated. - - - - - The angle the container makes to the beam and how it may change - during the experiment.In combination with shape this should allow - the beampath through the container to be modelled to allow the - adsorption of the container to be calculated. - - - - - A link to a full data collection which contains the actual - measured data for this container within the experimental set up - (with no sample or inner container(s)). This data set will also - include the wavelength/energy, measurement time and intensity for - which these data are valid. - - + + + State of a container holding the sample under investigation. + + A container is any object in the beam path which absorbs the beam and + whose contribution to the overall attenuation/scattering needs to be + determined to process the experimental data. Examples of containers + include glass capillary tubes, vanadium cans, windows in furnaces or + diamonds in a Diamond Anvil Cell. The following figures show a complex + example of a container':' + + .. figure':'':' container/ComplexExampleContainer.png + + A hypothetical capillary furnace. The beam passes from left to right + (blue dashes), passing through window 1, then window 2, before + passing through the downstream wall of the capillary. It is then + scattered by the sample with scattered beams passing through the + upstream wall of the capillary, then windows 4 and 5. As part of the + corrections for a PDF experiment it is necessary to subtract the PDF + of the empty container (i.e. each of the windows and the capillary). + To calculate the PDF of the empty container it is necessary to have + the measured scattering data and to know the nature (e.g. density, + elemental composition, etc.) of the portion of the container which + the beam passed through. + + .. figure':'':' container/ComplexContainerBeampath.png + + A complete description of the shapes of the container elements with + their orientation relative to the beam and also information on + whether they are upstream or downstream of the sample is also + therefore important. For example, although the windows 2 and 4 have + the same shape, the path taken through them by the beam is very + different and this needs to be modelled. Furthermore, it is not + inconceivable that windows might move during an experiment and thus + the changes to the beampath would need to be accounted for. + + This class encodes the position of the container with respect to the + sample and allows the calculation of the beampath through the container. + It also includes sufficient data to model beam absorption of the + container and a link to a dataset containing a measurement of the + container with nothing inside, to allow data corrections (at a specific + beam energy/measurement time) to be made. + + + + Descriptive name of container. + + + + + Verbose description of container and how it fits into the wider + experimental set up. + + + + + Chemical composition of the material the container is made from. + Specified using CIF conventions. Abbreviated version of CIF + standard':' + + * 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. + + * This is the *Hill* system used by Chemical Abstracts. + + + + + Density of the material the container is made from. + + + + + + + + Fraction of the volume of the container occupied by the material + forming the container. + + + + + + + + Relative molecular mass of container. + + + + + + + + Details of beam incident on container, including the position + relative to the sample (to determine whether the container is + upstream or downstream of the sample). + + + + + Shape of the container. In combination with orientation this + should allow the beampath through the container to be modelled to + allow the adsorption to be calculated. + + + + + The angle the container makes to the beam and how it may change + during the experiment.In combination with shape this should allow + the beampath through the container to be modelled to allow the + adsorption of the container to be calculated. + + + + + A link to a full data collection which contains the actual + measured data for this container within the experimental set up + (with no sample or inner container(s)). This data set will also + include the wavelength/energy, measurement time and intensity for + which these data are valid. + + - diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index 17fc4368f6..ed06270f23 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -57,6 +57,10 @@ 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: @@ -80,4 +84,54 @@ according to the descriptions in NXtransformations. + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 31e9f4a54e..b7e5be8c41 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -25,17 +25,11 @@ Corrector for aberrations in an electron microscope. - Different vendors use a different naming schemes for aberration coefficients. - It is the users responsibility to map to the best matching values. + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. - In transmission electron microscopes the spherical aberration corrector is - a component that is controlled via instructing the microscope to achieve - set point values. The corrector is composed of multiple lenses and other - parts with vendor-specific details which are often undisclosed. - - In the case of Nion Co. microscopes the coefficients of the corrector can be - retrieved via NionSwift, which is why currently the Nion convention for the - aberration coefficients is used. + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. @@ -55,7 +49,46 @@ a free-text field to report further details about the corrector. - + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index be45aa4453..5d794aaf06 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -49,12 +49,14 @@ + 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). diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index aa1b2bd32f..7995308a7d 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -40,11 +40,13 @@ + Total amount of data which the medium can hold. + Given name to the I/O unit. diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index fc25da0a1a..eb2e574771 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -35,4 +35,5 @@ How much physical memory does the system provide. + diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml index 99bbcec883..d540b09cf8 100644 --- a/contributed_definitions/NXcs_prng.nxdl.xml +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -71,6 +71,7 @@ sequence of numbers it generates. + Number of initial draws from the PRNG which are discarded in an effort @@ -79,4 +80,6 @@ users should set the value to zero. + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml index 3d8d5eec34..3cf1cb9741 100644 --- a/contributed_definitions/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -69,12 +69,13 @@ references to e.g. more detailed performance data to which they wish to link the metadata in this base class. + Path to the directory from which the tool was called. - + Command line call with arguments if applicable. @@ -125,6 +126,11 @@ Qualifier with how many nominal GPUs the app was invoked at runtime. + A collection with one or more computing nodes each with own resources. @@ -138,4 +144,6 @@ memory was consumed during these operations. + diff --git a/contributed_definitions/NXcsg.nxdl.xml b/contributed_definitions/NXcsg.nxdl.xml index b095387486..b7183349cc 100644 --- a/contributed_definitions/NXcsg.nxdl.xml +++ b/contributed_definitions/NXcsg.nxdl.xml @@ -1,14 +1,14 @@ - + - - - Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` - + - One of the standard construction solid geometry set operations, - or if the CSG is a pointer to the geometry provided by an - :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: + Constructive Solid Geometry base class, using ':'ref':'`NXquadric` and ':'ref':'`NXoff_geometry` - - - - - - - - - - - - The first operand of constructive solid geometry - operation. Compulsory if 'operation' is UNION, INTERSECTION, - DIFFERENCE or COMPLEMENT. - - - - - The second operand of constructive solid geometry - operation. Compulsory if 'operation' is UNION, INTERSECTION or - DIFFERENCE. - - - - - Path to a field that is either an :ref:`NXquadric` (if - 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if - 'operation' = IS_MESH) that defines the surface making up the - constructive solid geometry component. Compulsory if 'operation' - is IS_QUADRIC or IS_MESH. - - + + + One of the standard construction solid geometry set operations, + or if the CSG is a pointer to the geometry provided by an + ':'ref':'`NXquadric` or an ':'ref':'`NXoff_geometry`. Takes values':' + + + + + + + + + + + + + The first operand of constructive solid geometry + operation. Compulsory if 'operation' is UNION, INTERSECTION, + DIFFERENCE or COMPLEMENT. + + + + + The second operand of constructive solid geometry + operation. Compulsory if 'operation' is UNION, INTERSECTION or + DIFFERENCE. + + + + + Path to a field that is either an ':'ref':'`NXquadric` (if + 'operation' = IS_QUADRIC) or an ':'ref':'`NXoff_geometry` (if + 'operation' = IS_MESH) that defines the surface making up the + constructive solid geometry component. Compulsory if 'operation' + is IS_QUADRIC or IS_MESH. + + diff --git a/contributed_definitions/NXcxi_ptycho.nxdl.xml b/contributed_definitions/NXcxi_ptycho.nxdl.xml index e0f9c0efcc..4760a2c66b 100644 --- a/contributed_definitions/NXcxi_ptycho.nxdl.xml +++ b/contributed_definitions/NXcxi_ptycho.nxdl.xml @@ -1,232 +1,217 @@ - - - + - These symbols will be used below to coordinate the shapes of the datasets. + These symbols will be used below to coordinate the shapes of the + datasets. - - - The number of points in the x direction + + The number of points in the x direction - - - Number of points in the y direction. + + Number of points in the y direction. - - Number of detector pixels in x + + Number of detector pixels in x - - - Number of detector pixels in y + + Number of detector pixels in y - - Application definition for a ptychography experiment, compatible with CXI from version 1.6. - - This is compatible with CXI from version 1.6 if this application definition - is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important - to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, - with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. - - An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths - with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). + Application definition for a ptychography experiment, compatible with CXI from version 1.6. + + This is compatible with CXI from version 1.6 if this application definition + is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important + to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, + with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. + + An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths + with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). - - - - - - - Official NeXus NXDL schema to which this file conforms + + + + + + Official NeXus NXDL schema to which this file conforms - - - - + + + - - - - - - This is the energy of the machine, not the beamline. - - - - - - - - - - - - - - - - - - - - - - - - - - should have value "[, data]" - - - - - should have value "data" - - - - - - - - This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y - - - - - this should take the value "translation:$slowaxisname:$fastaxisname" - - - - - This should be "image" - - - - - - - - - - - - - - This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless - of the scan pattern. Use hdf5 virtual dataset to achieve this. - - - - - + + + + + + This is the energy of the machine, not the beamline. + + + + + + + + + + + + + + + + + + + + + + + + + + should have value "[, data]" + + + + + should have value "data" + + + + + + + + This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y + + + + + this should take the value "translation':'$slowaxisname':'$fastaxisname" + + + + + This should be "image" + + + + + + + + + + + + + + This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless + of the scan pattern. Use hdf5 virtual dataset to achieve this. + + + + + - + - - - The distance between the detector and the sample + + + The distance between the detector and the sample - + - + - + - - - - - - - - - - + + + + + + + + + + + + + + + This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster + + + + + This should be "data" + + + + + + + + + + + To ensure CXI compatibility the data in this group must always have shape that is + (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that + hdf5 virtual dataset is used. + + + + + + + + + This must contain two fields with the x and y motors that are linked via the + dependency tree according to the real-life motor layout dependency. + For raster scans x and y will have shape (npts_x, npts_y) + For arbitrary scans x and y will be (npts_x*npts_y,) + An attribute with the units for each motor is required. + + + + + - - - - This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster - - - - - This should be "data" - - - - - - - - - - - To ensure CXI compatibility the data in this group must always have shape that is - (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that - hdf5 virtual dataset is used. - - - - - - - - - - This must contain two fields with the x and y motors that are linked via the - dependency tree according to the real-life motor layout dependency. - For raster scans x and y will have shape (npts_x, npts_y) - For arbitrary scans x and y will be (npts_x*npts_y,) - An attribute with the units for each motor is required. - - - - - - - + - - diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml index f362abb3fd..33d751cded 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -23,7 +23,7 @@ --> - Deflectors as they are used e.g. in an electron analyser. + Deflectors as they are used e.g. in an electron analyser. diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 7487e80c86..8dceaaec0f 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -65,6 +65,17 @@ Reference or link to the points which are delocalized on the grid. + The weighting model specifies how mark data are mapped to a weight per point. @@ -87,6 +98,11 @@ + A list of elements (via proton number) to consider for the atomic_decomposition diff --git a/contributed_definitions/NXdetector.nxdl.xml b/contributed_definitions/NXdetector.nxdl.xml index d5df7c8c66..0130540c84 100644 --- a/contributed_definitions/NXdetector.nxdl.xml +++ b/contributed_definitions/NXdetector.nxdl.xml @@ -1,6 +1,27 @@ - + - + + These symbols will be used below to coordinate datasets with the same @@ -177,7 +198,7 @@ This is the distance to the previous component in the instrument; most often the - sample. The usage depends on the nature of the detector: Most often it is the + sample. The usage depends on the nature of the detector':' Most often it is the distance of the detector assembly. But there are irregular detectors. In this case the distance must be specified for each detector pixel. @@ -369,7 +390,7 @@ - This field can be two things: + This field can be two things':' #. For a pixel detector it provides the nominal wavelength for which the detector has been calibrated. @@ -381,6 +402,8 @@ In this use case, the efficiency and wavelength arrays must have the same dimensionality. + + @@ -562,21 +585,21 @@ Contains a bit field for each pixel to signal dead, blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: + They have the following meaning':' .. can't make a table here, a bullet list will have to do for now - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) + * bit 0':' gap (pixel with no sensor) + * bit 1':' dead + * bit 2':' under responding + * bit 3':' over responding + * bit 4':' noisy + * bit 5':' -undefined- + * bit 6':' pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7':' -undefined- + * bit 8':' user defined mask (e.g. around beamstop) + * bits 9-30':' -undefined- + * bit 31':' virtual pixel (corner pixel with interpolated value) Normal data analysis software would not take pixels into account @@ -737,14 +760,14 @@ - .. index:: plotting + .. index':'':' plotting - Declares which child group contains a path leading - to a :ref:`NXdata` group. + 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml index b47f0aa734..7431919c68 100644 --- a/contributed_definitions/NXdistortion.nxdl.xml +++ b/contributed_definitions/NXdistortion.nxdl.xml @@ -43,7 +43,7 @@ - Subclass of NXprocess to describe post-processing distortion correction. + Subclass of NXprocess to describe post-processing distortion correction. diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index ff72728eaa..a21a0fb47f 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -21,12 +21,14 @@ # # For further information, see http://www.nexusformat.org --> + Container for components to form a controlled beam in electron microscopy. - + The source which creates the electron beam. @@ -69,12 +71,15 @@ Material of which the emitter is build, e.g. the filament material. + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. + Affine transformation which detail the arrangement in the @@ -85,6 +90,7 @@ + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 0ef6f51315..968347b380 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -28,18 +28,18 @@ - Number of fast axes (axes acquired symultaneously, without scanning - a physical quantity) + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) - Number of slow axes (axes acquired scanning a physical quantity) + Number of slow axes (axes acquired scanning a pysical quantity) - Subclass of NXinstrument to describe a photoelectron analyser. + Subclass of NXinstrument to describe a photoelectron analyser. diff --git a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml index 552eb562a6..3426e227c3 100644 --- a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml +++ b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml @@ -1,60 +1,66 @@ - - - -definition for a electrostatic kicker. - -extended description of the kicker. - - -define position of beamline element relative to production target - - -kicker timing as defined by ``description`` attribute - - - -current set on supply. - - -current read from supply. - - - -volage set on supply. - - -voltage read from supply. - - + + + definition for a electrostatic kicker. + + + + extended description of the kicker. + + + + + define position of beamline element relative to production target + + + + + kicker timing as defined by ``description`` attribute + + + + + + current set on supply. + + + + + current read from supply. + + + + + + volage set on supply. + + + + + voltage read from supply. + + + diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 197b3f7d2e..03378baf79 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -21,6 +21,12 @@ # # For further information, see http://www.nexusformat.org --> + + @@ -257,6 +263,14 @@ Specify the used light source. Multiple selection possible. + + Were focussing probes (lenses) used? diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 23c77743f6..5ba5c62d1d 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -21,70 +21,84 @@ # # For further information, see http://www.nexusformat.org --> + - Characterization and session with one sample in an electron microscope. + Characterization of a sample during a session on an electron microscope. **The idea and aim of NXem**: - Electron microscopy (EM), whether it be with scanning electron microscope (SEM) - or transmission electron microscope (TEM) instruments, are versatile tools for - preparing and characterizing samples and specimens. The term specimen is considered - a synonym for sample in this application definition. + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. A specimen is a physical portion of material that is studied/characterized during the microscope session, eventually in different places on the specimen surface, - illuminating either the surface layers or shining through thin specimens. + illuminating the surface layers or shining through thin specimens. These places are named regions of interest (ROIs). - Fundamentally, an EM is an electron accelerator. Experimentalists use an EM - in sessions during which they characterize as well as prepare specimens. - This application definition describes data and metadata about processes and - characterization tasks applied to one specimen. The application definition - focuses on the usage of EM in materials research. The application definition - design makes it in principle applicable also in cryo-EM on biomaterials. + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. - Multiple specimens have to be described with multiple NXentry instances. + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + **Electron microscopes motivate the development of an embracing data schema:** There are research groups who use an EM in a manner where it is exclusively operated by a single, instrument-responsible scientists or a team of scientists. These users may perform analyses for other users as a service task, especially in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process maybe even operating - the microscope. Oftentimes the scientists operate the instrument themselves - either on-site or remotely and can ask technicians for support. - In all cases, these people are considered users. Users might have different + cutting-edge instruments, the scientists guide the process maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different roles though. - The rational behind a common EM schema rather than making separate application - definitions for SEM or TEM are primarily the key similarities of SEM and TEM + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM instruments: Both type of instruments have electro-magnetic lenses. These may differ in design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is used mainly to measure the - transmitted electron beam. This calls for using a different lens setup and - relative placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to illuminate - through the specimen. This offers capabilities for probing of + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of additional physical mechanisms of electron-matter interaction which are unavailable in SEMs. - Compared to SEMs, TEMs have a different relative arrangement between the - lenses and the specimen which is most obvious by the different relative - arrangement of the objective lens versus the specimen. - Nevertheless, both types of electron microscopes use detector systems which measure different types of signals that originate from the same set of - radiation/specimen interactions. Consequently, detectors can also be similar - if not exactly the same. + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. - **An embracing schema instead of specific SEM or TEM schemes**: + **An embracing schema instead of specific SEM or TEM schemas**: Given these physical and technical differences, different instruments have been developed. This led to a coexistence of two broad interacting communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower - the addressed user base is which develops or uses schemes for research data - management (RDM) with EM, the more understandable it is that scientists of - either community (or sub-community) ask for method-specific schemes. + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. Researchers who have a single (main) microscope of some vendor in their lab, may argue they need an NXem_vendor_name schema or an NXem_microscope_name or @@ -93,29 +107,28 @@ (X-rays, electrons) may argue they wish to be pragmatic and store only what is immediately relevant for their particular technique and research questions. In effect, they may advocate for method-specific - schemes such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - However, the development in the past has shown that these activities led to - a zoo of schemes and especially vocabulary in use with implementations of these + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and especially vocabulary in use with implementations of these into many data and file formats. There is nothing which prevents the communities - to make these schemes open and interoperable. Open here means specifically not - that all data are compliant with/or use the schema and have to end up in the - open-source domain. There can be embargo periods first of all. + to make these schemas open and interoperable. Open here means not that all + data stored according to such schemas have to end up in the open-source domain. + There can be embargo periods first of all. Open means that the metadata and associated schemata are documented in a manner - that as many details as possible are open in the sense that others can understand + that as many details are open as possible in the sense that others can understand what the (meta)data mean conceptually. Instead of trying of maintain a zoo of eventually difficult to make interoperable formats and schema we would like to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ should guide all decisions how data and metadata should be stored. EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different - schemes with associated representations of data and metadata in EM: - Each combination of schemes or an interoperable-made handshake between two - file formats or software packages has to be maintained by software developers. - This counts especially when data should be processed interoperably - between software packages. + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. This brings two problems: Many software tools and parsers for the handshaking between tools have to be maintained. This can result in usage of different @@ -125,53 +138,58 @@ `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemes and + A common vocabulary can serve interoperability as developers of schemas and scientists can reuse for instance these terms, thus supporting interoperability. Ideally, scientists specialize an application definition only for the few very specific additional quantities of their instruments and techniques. This is better than reimplementing the wheel for descriptions of EM instruments. This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemes. + removes the necessity for having to maintain a very large number of schemas. - Aiming for more standardization, i.e. a lower number of schemes rather than + Aiming for more standardization, i.e. a lower number of schemas rather than a single standard for electron microscopy is a compromise that can serve - academia as it enables the EM community to focus their software development - efforts on those schemes, on fixing and discussing them, and on harmonizing + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing their common vocabulary. These activities can be specifically relevant also - for vendors of EM hard- and software as it improves the longevity of certain - schema; and thus can help to incentivize vendors to support the community with - implementing support for such schemes into their proprietary applications. + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. In effect, everybody can gain from this as it will likely reduce the cases in which scientists have to fix bugs in making their own tools compliant and interoperable with tools of their colleagues and the wider community. The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemes for EM research. + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + Working towards a common vocabulary is a community activity that profits from everybody reflecting in detail whether certain terms they have used in the past are not eventually conceptually similar if not the same as what this application definition and its base classes provide. We are happy for receiving your feedback. **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemes differ + It is noteworthy to understand that (not only for NeXus), schemas differ already if at least one field is required in one version of the schema, but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemes can + attributes are removed or added, or even a docstring is changed, schemas can become inconsistent. It is noteworthy to mention that the idea of a NeXus application definition serves as a contract between a data provider and a data consumer. - Providers can be software from specific microscopes or users with specific + Providers can be the software of a specific microscopes or users with specific analysis needs. Consumers can be again specific software tools, like vendor software for controlling the instrument or a scientific software for doing artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions and strictly speaking an application definition can only be - really general if it does not make a single entry required, in which case however - it would also not offer much value as even empty datasets would be compliant. + to new versions. Strictly speaking an application definition can only be + fully general if it does not make a single entry required, in which case however + it would also not offer much value as even empty datasets would be compliant + with such a schema. **Verification of constraints and conditions**: Tools like NeXus so far do not avoid or protect against all such possible inconsistencies; however NeXus offers a mechanism and toolset, through which - schemes can be documented and defined. In effect, having an openly documented + schemas can be documented and defined. In effect, having an openly documented (at a case-specific level of technical detail) schema is a necessary but alone not a sufficient step to take EM research on a route of machine-actionable and interoperable FAIR data. @@ -182,17 +200,17 @@ requirements are formulated in the docstrings of the respective entries of the application definition. - This application definition takes a key step towards standardization of EM data. - It offers a controlled vocabulary and relation between concepts and data - relevant for research with electron microscopes. To be most efficient and - offering reusability, the application definition should be understood as a - template that one should ideally use as is. This application definition - is called NXem. NXem can be considered a base for designing more specialized - definitions (ideally prefixed with NXem) *method*. + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but make - them optional or, even better, propose changes in this NXem application definition. + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. A particular challenge with electron microscopes as physical instruments are their dynamics. To make EM data understandable, repeatable, and eventually @@ -205,10 +223,11 @@ economical constraints on how completely EM research can be documented: For most commercial systems there is a specific accessibility beyond which detailed settings like lens excitations and low-level hardware settings - may not be retrievable as vendors also have a relevant interest in finding - a compromise between being open to their user and securing their business. + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. - EM experiments by design illuminate the specimen with electrons as a + By design, EM experiments illuminate the specimen with electrons as a consequence of which the specimen changes if not may get destroyed. As such, repeatability of numerical processing and clear descriptions of procedures and system setups should be addressed first. @@ -217,14 +236,16 @@ geometry of the lens system and its excitations during the course of the experiment, it is difficult to fully abstract the technical details of the hardware into a set of names for fields and groups that make for a compromise - between clarity but being vendor-agnostic at the same time. + between clarity but being system-agnostic at the same time. Settings of apertures are an example where aperture modes are in most cases aliases behind which there is a set of very detailed settings specific to the software and control units used. These settings are difficult to retrieve, - often undocumented in detail by vendors. This serves users and makes EM - experiments easier understandable and conveniently executable for a broad - user base. On the flipside these subtilities limit the opportunities for - making application definitions too general. + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. Instead, currently it is for the docstring to specify what is conceptually eventually behind such aliases. The design rule we followed while drafting @@ -245,12 +266,12 @@ aims and interest, while remaining at the same time approachable and executable by a large number of scientists in a community. However, we are also convinced that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemes. + of oftentimes strongly overlapping and redundant schemas. NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what are metadata in EM. While doing - so we found that existent terminology can be encoded into a more controlled - vocabulary. + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. We have concluded that despite all these details of current EM research with SEM, TEM, and focused-ion beam instruments, there a clearly identifiable @@ -268,7 +289,7 @@ * Each signal, such as a spectrum or image taken at the microscope, should have an associated time-zone-aware time stamp and report of the specific settings of the microscope at that point in time when the image was taken. - This is why instances of NXevent_data_em have an own em_lab section. + This is why instances of :ref:`NXevent_data_em` have an own em_lab section. The reason is that EMs can be highly dynamic, be used to illuminate the specimen differently or show drift during signal acquisition, to name but a few effects. What constitutes a single EM experiment/measurement? @@ -276,26 +297,27 @@ taking of a secondary electron image for fracture analysis, taking a set of EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a specimen in preparation for e.g. an atom probe experiment. - * NXmonitor; + * :ref:`NXmonitor`; instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. Alternatively, NXevent_data_em - instances can be used to store time-zone-aware dates of the components, which is + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is relevant for documenting as exactly as practically possible settings when images and spectra were taken. - * NXinstrument; + * :ref:`NXinstrument`; conceptually this is a container to store arbitrary level of detail of the technical components of the microscope as a device and the lab in which the microscope is operated. - * NXuser; + * :ref:`NXuser`; conceptually, this is a set with at least one NXuser instance which details who operated or performed the measurement. Additional NXusers can be referred to in an NXevent_data_em instance to store individualized details who executed an event of data acquisition or processing. - * NXevent_data_em instances as an NXevent_data_em_set; + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; each NXevent_data_em instance is a container to group specific details about the state of the microscope when a measurement was taken and relevant data and eventual processing steps were taken (on-the-fly). - * NXdata; at the top-level, conceptually, this is a place for documenting + * :ref:`NXdata`; at the top-level, conceptually, this is a place for documenting available default plottable data. A default plottable can be useful for research data management systems to show a visual representation of some aspect of the content of the EM session. @@ -305,33 +327,37 @@ somewhat of personal taste, and community standards. In effect, default plottables are case- and method-specific. - Usually a session at a microscope is used to collect multiple signals and - images. Examples for possible default plottables could be arbitrarily - taken secondary, back-scattered, electron image, diffraction pattern, - EELS spectra, composition, or orientation mappings to name but a few. + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. **There are a few design choices to consider with sub-ordinate groups:** - * Above images, spectra, and mappings should be stored as NXdata instances, - ideally formatted in such a way that they can be displayed with - visualization software that can be specific for the file format in which - the data are stored. NeXus specifies only the data model, i.e. the terms - and their relations. These descriptions can be implemented and stored in - JSON, HDF5, XML, or HSDS, file storage, or even other formats, although - HDF5 is often used. + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables to + display image and spectra with web technology visualization software. + NeXus specifies only the data model, i.e. the terms and their relations. + These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, + file storage, or even other formats, although HDF5 is often used. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional XDMF fields which support additional plotting of + the data with visualization software like Paraview or Blender. * Consumable results of EM characterization tasks are usually a sub-set of data artifacts, as there is not an infinite amount of possible electron/ion beam-specimen interactions. * Images of electron counts detected in specific operation modes (bright - field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) + field, dark field in TEM, secondary/back-scattered, Kikuchi). * Spectra (X-ray quanta or Auger electron counts) * These data are in virtually all cases a result of some numerical processing. - It makes sense to name these data and processing tasks with a controlled - vocabulary, e.g. SE (secondary electron), BSE (back-scattered electron), - Kikuchi, X-ray, Auger, Cathodolum(inescence) etc. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk). To this end the schema, here makes no + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. To this end the schema here makes no specific assumptions, not even that all the fields/group of a schema instance have to be stored at all into a single file. Instead, the schema specifies the relations between metadata, some of the constraints and conditions on how the @@ -340,14 +366,34 @@ In effect, the application definition is a graph which describes how numerical data and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + An at least as strong as SHA256 hashvalue of the file that specifies the application definition. + NeXus NXDL schema to which this file conforms. @@ -361,8 +407,8 @@ Ideally, a (globally) unique persistent identifier for referring to this experiment. - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals. @@ -384,15 +430,15 @@ for specifying when the experiment was performed - and the exact duration is not relevant - this start_time field should be used. - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping and + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and interpretation of the experiment. The user should be aware that even with having both time instances specified, it may not be possible to infer how long the experiment took or for how long data were acquired. More detailed timing data over the course of the experiment have to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_em instances to + advantage of individual time stamps in NXevent_data_em instances to provide additional pieces of information. @@ -402,38 +448,11 @@ the microscope session ended. - - - Commercial or otherwise given name to the program which was used to - create the file. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual NXprocess - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - - - - Program 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. - - - + + + + + Binary container for a file or a compressed collection of files which @@ -521,6 +540,12 @@ + A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. @@ -535,6 +560,10 @@ + Ideally (globally) unique persistent identifier. The name distinguishes @@ -585,7 +614,7 @@ Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Usually this should be a part of the sample history, i.e. the sample is imagined handed over - for analysis. At the point it enters the microscope the session starts. + for analysis. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as @@ -602,16 +631,17 @@ - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history. + (Measured) sample thickness. The information is recorded to qualify @@ -623,17 +653,30 @@ surface normal of the specimen is parallel to the optical axis. + (Measured) density of the specimen. For multi-layered specimens this field should only be used to describe the density of the excited volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an NXinteraction_vol_em for - individual NXevent_data_em instances can provide a much better description - of the relevant details why one would otherwise ask to store the density - of the specimen. + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + Discouraged free-text field in case properly designed records @@ -650,24 +693,28 @@ + + + Metadata and numerical data of the microscope and the lab in which it stands. The em_lab section contains a description of the instrument and its components. The component descriptions in this section differ from those inside individual - NXevent_em sections. These event instances take the role of time snapshot. - For an NXevent_em instance users should store only those settings for a + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a component which are relevant to understand the current state of the component. Here, current means at the point in time, i.e. the time interval, which the event represents. - For example it is not relevant to store in each event's electron_gun group - again the details of the gun type and manufacturer but only the high-voltage - if for that event the high-voltage was different. If for all events - the high-voltage was the same it is not even necessary to include an - electron_gun section in the event. + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. Individual sections of specific type should have the following names: @@ -698,13 +745,15 @@ + - + + @@ -735,6 +784,7 @@ If the lens is described at least one of the fields voltage, current, or value should be defined. + @@ -752,20 +802,263 @@ - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -775,7 +1068,8 @@ - + + @@ -812,7 +1106,7 @@ - + @@ -820,7 +1114,7 @@ - + @@ -831,11 +1125,18 @@ + + + Description of the type of the detector. @@ -844,16 +1145,16 @@ Different technologies are in use like CCD, scintillator, direct electron, CMOS, or image plate to name but a few. - - - Free text option to write further details about the detector. - - + + + @@ -864,6 +1165,7 @@ + @@ -871,42 +1173,80 @@ + - A container to structure a set of NXevent_data_em instances. + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. - An event is a time point/time interval during which the microscope - was configured in a specific way and the microscope was used - to take a measurement. The microscope is considered stable during this - interval. + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. - Each NXevent_data_em instance holds an acquisition task with the microscope. - For instance the capturing of a secondary electron, backscattered - electron, diffraction image, or spectrum. + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. An NXevent_data_em instance holds specific details about how raw data from - a detector were processed into consumable data like images, spectra, - etc. These on-the-fly data processing tasks are usually performed - by the control software, eventually realized with custom scripts. + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. - Furthermore, NXevent_dat_em instances can document specific values - and settings of the microscope during the snapshot/event. + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. A container holding a specific result of the measurement and eventually metadata how that result was obtained numerically. - NXevent_em instances can hold several specific - NXimage_em or NXspectrum_em instances taken and considered as - one event, i.e. a point in time when the microscope had the - settings specified either in NXinstrument or in this NXevent_data_em - instance. + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. - The application definition is designed without an explicit need - an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. An NXevent_data_em can be used to document a - specific state of the microscope at a time without having it placed - into the NXinstrument group. + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. In other words the NXinstrument group details primarily the more static settings and components of the microscope as they are found @@ -915,19 +1255,22 @@ It is not necessary to store data in NXebeam, NXibeam instances of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of microscope session + were constant over the entire course of the microscope session and thus all relevant metadata inside the NXinstrument groups are sufficient to understand the session. - So far there is no vendor-overarching standard according to which - electron microscope data are documented and stored. Therefore, it is - still a frequently the case that vendor-specific files have many fields - that cannot be safely mapped. Therefore, users are always adviced to - keep the vendor files. Working however with these vendor files inside - specific software, like materials databases, demands for parsers which - extract pieces of information from the vendor representation (numerical - data and metadata) and map them on a schema with which the database - and its associated software tools can work with. + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. Currently, one would loose immediately track of e.g. provenance and the origin of certain data in NXevent_data_em instances unless really @@ -935,29 +1278,31 @@ schema. Currently, though, this is sadly effectively prevented in many cases as vendors indeed implemented often sophisticated provenance and commercial software state tracking tools but these are not yet - documented dynamically, coveringly enough in our opinion so that it is - safe to assume all vendor field names are known, logically understood, - interpretable, and thus mappable on a common schema using a controlled - common vocabulary. + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. - Therefore we encourage user for now to store for each image_set_em - or spectra_set_em instance to supply the so-called source of the data. + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. This can for instance be the name and hashvalue of the original file which was acquired during the microscope session and from which then - certain like numerical data and metadata were copied into an instance - of this schema for the purpose of working with the data in e.g. tools - offered by the materials database. + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. - During work on implementing file format/metadata parsers and developing - this application definition we realized that several software tools - currently do not consistently track time-zone-aware timestamps of - events associated with the data, processing, and during the microscope - session. This is in partly a consequence of vendor which store - detailed time data in different formats. We would like to encourage the - community and especially the vendors to work towards a standardization, - or at least a open documentation of the way how time-zone-aware time - data are collected and stored how and where during a microscope session - and how they end up in files and databases with which users interact. + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. This would enable to supplement instances of this schema with specific time data and assure that these time data can be used to reliably contextualize individual datasets and processing steps in materials @@ -972,26 +1317,24 @@ - - - Reference to a specific state and setting of the microscope components. - - + - - - The detector or set of detectors that was used to collect this signal. - The name of the detector has to match one of the names of available - NXdetector instances e.g. if the instrument has an ebsd_camera - the detector for an NXimage_em_kikuchi should be the NXdetector - instance called ebsd_camera. - - - + + - + + + + + + + + + + - + @@ -999,26 +1342,121 @@ + + + - - - - + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + @@ -1026,58 +1464,109 @@ + + - + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -1085,72 +1574,154 @@ - + + + + + + + + + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + - - - - - - - - - - + + + - + + @@ -1161,27 +1732,277 @@ - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + + @@ -1203,6 +2024,7 @@ + @@ -1213,6 +2035,7 @@ + @@ -1221,10 +2044,9 @@ - + - diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index bad6d7823b..02094abac1 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -21,6 +21,70 @@ # # For further information, see http://www.nexusformat.org --> + + @@ -52,6 +116,7 @@ + Application definition for collecting and indexing Kikuchi pattern into orientation maps. @@ -121,6 +186,8 @@ that specifies the application definition. + NeXus NXDL schema to which this file conforms. @@ -247,6 +314,9 @@ + @@ -293,6 +363,8 @@ + Details about simulations for Kikuchi pattern using kinematic or dynamic @@ -320,22 +392,35 @@ + + + + + The experiment group captures relevant details about the conditions of @@ -378,6 +463,7 @@ + The EBSD system, including components like the electron gun, pole-piece, stage tilting, EBSD detector, and the gnomonic projection have to be @@ -461,6 +547,7 @@ + Relevant result of the session at the microscope for this experiment which enables to connect the measurement of the Kikuchi pattern and @@ -519,7 +606,9 @@ + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi patterns to obtain orientation per phase model and scan point. @@ -642,18 +731,42 @@ + Binning i.e. downsampling of the pattern. + Specific parameter relevant only for certain algorithms used + @@ -671,6 +784,26 @@ + + + Which return value did the indexing algorithm yield for each scan point. @@ -686,6 +819,12 @@ + How many phases i.e. crystal structure models were used to index each @@ -787,6 +926,10 @@ + Matrix of calibrated centre positions of each scan point in the sample surface reference system. @@ -796,12 +939,18 @@ + + Fraction of successfully indexed pattern of the set averaged over entire set. + An overview of the entire area which was scanned. @@ -812,6 +961,7 @@ Descriptor representing the image contrast. + @@ -822,9 +972,14 @@ Container holding a default plot of the region on the sample investigated with EBSD. + + @@ -834,6 +989,9 @@ + Signal @@ -1043,6 +1201,16 @@ Which IPF definition computation according to backend. + + Along which axis to project? Typically [0, 0, 1] is chosen. @@ -1056,6 +1224,7 @@ Bitdepth used for the RGB color model. Usually 8 bit. + The tool/implementation used for creating the IPF color map from @@ -1068,13 +1237,21 @@ + The RGB image which represents the IPF map. + + @@ -1086,6 +1263,9 @@ + IPF color-coded orientation mapping @@ -1105,6 +1285,7 @@ + Calibrated center of mass of the pixel along the fast axis. @@ -1139,9 +1320,15 @@ parsers takes a rasterized image which is rendered by the backend tool. + + @@ -1152,6 +1339,9 @@ + IPF color key in stereographic standard triangle (SST) @@ -1297,6 +1487,11 @@ again be a link or reference to an instance of NXem_ebsd to complete the chain of provenance. + @@ -1307,6 +1502,7 @@ + An overview of the entire reconstructed volume. For details about @@ -1317,13 +1513,20 @@ Descriptor representing the image contrast. + Container holding a default plot of the reconstructed volume. + + @@ -1334,6 +1537,9 @@ + Signal @@ -1403,6 +1609,7 @@ Which IPF definition computation according to backend. + Along which axis to project? Typically [0, 0, 1] is chosen. @@ -1428,13 +1635,21 @@ + The RGB image which represents the IPF map. + + @@ -1447,6 +1662,9 @@ + IPF color-coded orientation mapping @@ -1466,6 +1684,7 @@ + Calibrated center of mass of the pixel along the faster axis. @@ -1479,6 +1698,7 @@ + Calibrated center of mass of the pixel along the fastest axis. @@ -1497,9 +1717,15 @@ Same comments as for the two-dimensional case apply. + + @@ -1510,6 +1736,9 @@ + IPF color key in stereographic standard triangle (SST) @@ -1546,4 +1775,152 @@ + + diff --git a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml index 5a46756065..c471943e94 100644 --- a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml @@ -22,6 +22,7 @@ # For further information, see http://www.nexusformat.org --> + Conventions for rotations and coordinate systems to interpret EBSD data. @@ -31,6 +32,8 @@ and the use of file formats which do not store this information is the key unsolved problem. + Mathematical conventions and materials-science-specific conventions @@ -594,4 +597,14 @@ + diff --git a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml index 1205dd6c0c..8df153844e 100644 --- a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml @@ -50,6 +50,9 @@ used algorithm. More and more dictionary based alternatives are used. Either way both algorithm need a crystal structure model. + Identifier of an entry from crystallographic_database which was used @@ -62,6 +65,7 @@ crystallographic_database_identifier e.g. COD or others. + Crystallography unit cell parameters a, b, and c. @@ -70,6 +74,7 @@ + Crystallography unit cell parameters alpha, beta, and gamma. @@ -88,6 +93,7 @@ Crystallographic space group + True if space group is considered a centrosymmetric one. @@ -109,11 +115,13 @@ Laue group + Point group using International Notation. + Crystal system @@ -169,6 +177,8 @@ + Relative occupancy of the atom position. @@ -182,6 +192,7 @@ How many reflectors are distinguished. Value has to be n_hkl. + Miller indices :math:`(hkl)`. @@ -207,4 +218,7 @@ + diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index d408627e24..a6d5f22d40 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -23,8 +23,8 @@ --> - Subclass of NXelectronanalyser to describe the energy dispersion - section of a photoelectron analyser. + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. diff --git a/contributed_definitions/NXentry.nxdl.xml b/contributed_definitions/NXentry.nxdl.xml index b062a10d3d..3d585c1fc6 100644 --- a/contributed_definitions/NXentry.nxdl.xml +++ b/contributed_definitions/NXentry.nxdl.xml @@ -1,58 +1,79 @@ - + - + + - (**required**) :ref:`NXentry` describes the measurement. + (**required**) ':'ref':'`NXentry` describes the measurement. The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. + information that comprise a single measurement. It is mandatory that there is at least one group of this type in the NeXus file. - .. index:: plotting + .. index':'':' plotting - Declares which :ref:`NXdata` (or :ref:`NXsubentry`) group + Declares which ':'ref':'`NXdata` (or ':'ref':'`NXsubentry`) group contains the data to be shown by default. - It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. - The value is the name of the default :ref:`NXdata` group. + It is needed to resolve ambiguity when more than one ':'ref':'`NXdata` group exists. + The value is the name of the default ':'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. - .. [#] NIAC2014 discussion summary: - https://www.nexusformat.org/2014_How_to_find_default_data.html + .. [#] NIAC2014 discussion summary':' + https':'//www.nexusformat.org/2014_How_to_find_default_data.html The data group - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that + .. note':'':' Before the NIAC2016 meeting [#]_, at least one + ':'ref':'`NXdata` group was required in each ':'ref':'`NXentry` group. + At the NIAC2016 meeting, it was decided to make ':'ref':'`NXdata` + an optional group in ':'ref':'`NXentry` groups for data files that do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when defining the default plot is not practical or possible from the available data. - For example, neutron event data may not have anything that + For example, neutron event data may not have anything that makes a useful plot without extensive processing. Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group + require an ':'ref':'`NXdata` group + in the ':'ref':'`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + ':'ref':'`NXdata` group is optional, otherwise, it is required. - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 + .. [#] NIAC2016':' + https':'//www.nexusformat.org/NIAC2016.html, + https':'//github.com/nexusformat/NIAC/issues/16 @@ -109,19 +130,19 @@ Reserved for future use by NIAC. See - https://github.com/nexusformat/definitions/issues/382 + https':'//github.com/nexusformat/definitions/issues/382 - (alternate use: see same field in :ref:`NXsubentry` for preferred) + (alternate use':' see same field in ':'ref':'`NXsubentry` for preferred) Official NeXus NXDL schema to which this entry conforms. - This field is provided so that :ref:`NXentry` can be the overlay position + This field is provided so that ':'ref':'`NXentry` can be the overlay position in a NeXus data file for an application definition and its - set of groups, fields, and attributes. + set of groups, fields, and attributes. - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + *It is advised* to use ':'ref':'`NXsubentry`, instead, as the overlay position. @@ -201,7 +222,7 @@ This is the flightpath before the sample position. This can be determined by a - chopper, by the moderator or the source itself. In other words: it the distance + chopper, by the moderator or the source itself. In other words':' it the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 6f3c087f93..35e42c292d 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -31,9 +31,9 @@ can be collected. Users may wish to take only a single scan or image and complete their microscope session; however - frequently users are much longer at the microscope, recalibrate and take + frequently users are working much longer at the microscope, recalibrate and take multiple data items (scans, images, spectra). Each item comes with own detector - and on-the-fly processing settings and calibrations. + and eventually on-the-fly processing settings and calibrations. For the single data item use case one may argue that the need for an additional grouping is redundant. Instead, the metadata could equally be stored inside @@ -43,7 +43,7 @@ In fact, oftentimes scientists feel that there is a need to store details about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations caused or apertures used. + or record changes to the lens excitations or apertures used and/or changed. Although current microscopes are usually equipped with stabilization systems for many of the individual components, it can still be useful to store time-dependent data in detail. @@ -52,13 +52,13 @@ storing time-dependent data, is that over the course of a session one may reconfigure the microscope. What is a reconfiguration? This could be the change of an aperture mode because a scientist may first collect an image - with some aperture and then choose a different value. As the aperture affects - the electron beam it will affect the system. + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. Let aside for a moment the technology and business models, an EM could be monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of objects, - and eventually (externally) applied stimuli and positioning of the specimen. + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. Some snapshot or integrated data from this stream are relevant for understanding signal genesis and electron/ion-beam-sample interaction (paths). In such a generic @@ -66,18 +66,23 @@ in time when specific measurements are taken (spectra collected, images taken, diffraction images indexed on-the-fly). - Theoretically, an instrument and specimen should be considered as dynamic. + Therefore, both the instrument and specimen should always be considered as dynamic. Scientists often report or feel (difficult to quantify) observations that microscopes *perform differently* across sessions, without sometimes being able to identify clear root causes. Users of the instrument may consider such conditions impractical, or *too poor* and thus either abort their session or try to bring the microscope first into a state where conditions are considered - stable and of high enough quality to reuse data collection. - - In all these cases it is practical to store time-dependent data of the - instrument state not in the respective instrument component groups - of the top-level NXinstrument but in a sort of a log of event data. - This is the idea behind the NXevent_data_em snapshot containers. + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. Ideally, NXevent_data_em are equipped with a start_time and end_time to represent a time interval (remind the idea of the instrument state stream) @@ -88,18 +93,20 @@ microscope is stable enough. Take for instance the acquisition of an image or spectra stack. It is not fully possible (technically) to avoid that even within a single image instabilities of the beam are faced and drift occurs. - But does this warrant to document the microscope state at an even finer - and impractical in-between one collects signal time intervals? + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? - This is a question of how finely does one granularize pieces of information. + This is a question of how one wishes to granularize pieces of information. A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and illuminates a portion of the material, i.e. - the interaction volume, whose signal contributions are then counted by the - detector(s) as per pixel- or per voxel signal in the region-of-interest. - In principle this application definition allows for such doing so. - However, in most cases such a fine granularization would demand the collection - of data which are as of now hardly retrievable with commercial instruments - nor of primary interest. + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. A frequently made choice, mainly for convenience, is that drift and scan distortions are considered a feature or inaccuracy of the image and/or spectrum and thus @@ -110,9 +117,11 @@ single position measurements as the smallest granularization level. Which eventually may require to add optional NXprocess instances for respectively collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. Which warrant an own - consideration in the future. A more detailed overview of such computational - steps to cope with scan distortions is available in the literature: + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ @@ -128,9 +137,9 @@ customizations of the specific fields within NXevent_data_em instances. Another alternative could be to sample finer, eventually dissimilarly along - the time axis; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements - (i.e. images, spectra of scientific relevance). + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). In this case one should better go for a customized application definition with a functional property description inside members (fields or groups) @@ -146,8 +155,8 @@ Examples include cutting-edge experiments where the electron beam gets coupled/excited by e.g. lasers. In this case, the laser unit should be registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective groups of the NXinstrument though - inside instances of here detailed NXevent_data_em. + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. @@ -167,7 +176,7 @@ - Reference to a specific state and setting of the microscope components. + Reference to a specific state and setting of the microscope. @@ -187,56 +196,31 @@ * Auger, spectrum, (low Z contrast element composition) * Cathodoluminescence (optical spectra) * Ronchigram, image, alignment utility specifically in TEM - * Chamber, e.g. TV camera inside the chamber, education purposes. - - - - - The detector or set of detectors that was used to collect this signal. - The name of the detector has to match the names used for available - detectors, i.e. if the instrument has an *ebsd_camera* - named detector, instances of NXimage_em_kikuchi should use - *ebsd_camera* as the detector name. - - - - - - - - - - - - - - - - - - - A group where specific settings of the instrument during the - event can be captured. This is the preferred way to keep track of - different settings of the microscope during the session. - For instance, a user may first take an overview image with different - magnification and settings and then start a spectrum analyses. - These should be stored as two NXevent_data_em instances in an - application definition. Each storing the specific settings. + * Chamber, e.g. TV camera inside the chamber, education purposes. - NXfabrication relevant details should not be repeated because - we assume that the session is with the same microscope. - Namely, it is hopefully not happening that someone builds out a - component of the microscope while is taking a measurement with it. - For this reason the specialized NXinstrument here contains no - NXfabrication group. + This field may also be used for storing additional information about the event. - - - - - - - + + + + + - + diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index 160cc82aa8..dd4c68f59a 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -47,4 +47,5 @@ functionalities which the component offers. + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 376c4ea37d..f9fd3d38dc 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -93,7 +93,7 @@ - + A human-readable qualifier which type or e.g. class instance the edge is an instance of. @@ -102,7 +102,7 @@ - + A human-readable label/caption/tag for the edge. diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index f6fc7561fd..94ccadcae1 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -22,6 +22,7 @@ # For further information, see http://www.nexusformat.org --> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -63,7 +64,7 @@ - + A human-readable qualifier which type or e.g. class instance the node is an instance of. As e.g. a NeXus application definition is a @@ -75,7 +76,7 @@ - + A human-readable label/caption/tag of the graph. @@ -83,4 +84,6 @@ + diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index 1ed723f89a..890838bcc8 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -32,4 +32,5 @@ + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml index 7d3d2e03dd..0b25782f92 100644 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -21,6 +21,8 @@ # # For further information, see http://www.nexusformat.org --> + Container for components of a focused-ion-beam (FIB) system. @@ -43,10 +45,10 @@ * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ - * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - + The source which creates the ion beam. @@ -82,11 +84,14 @@ or xenon, O2+. + Average/nominal brightness + Charge current @@ -105,8 +110,11 @@ + + @@ -117,4 +125,20 @@ at which details about the ion beam are probed. + diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml new file mode 100644 index 0000000000..9426823645 --- /dev/null +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -0,0 +1,128 @@ + + + + + + + + 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/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index 56edf87880..2782a391e8 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -98,6 +98,11 @@ Annular dark field image stack. + Image intensity values. diff --git a/contributed_definitions/NXimage_set_em_bf.nxdl.xml b/contributed_definitions/NXimage_set_em_bf.nxdl.xml index 066b2b3e46..ee5c35dbf4 100644 --- a/contributed_definitions/NXimage_set_em_bf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_bf.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for reporting a set of images taken in bright field mode. diff --git a/contributed_definitions/NXimage_set_em_bse.nxdl.xml b/contributed_definitions/NXimage_set_em_bse.nxdl.xml index 6c99db5649..b90cebf37e 100644 --- a/contributed_definitions/NXimage_set_em_bse.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_bse.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for reporting a set of back-scattered electron images. diff --git a/contributed_definitions/NXimage_set_em_chamber.nxdl.xml b/contributed_definitions/NXimage_set_em_chamber.nxdl.xml index 09973347dc..958664d27c 100644 --- a/contributed_definitions/NXimage_set_em_chamber.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_chamber.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for images recorded with e.g. a TV camera in the microscope chamber. diff --git a/contributed_definitions/NXimage_set_em_df.nxdl.xml b/contributed_definitions/NXimage_set_em_df.nxdl.xml index f9c37cab96..288a3b63c1 100644 --- a/contributed_definitions/NXimage_set_em_df.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_df.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for reporting a set of images taken in dark field mode. diff --git a/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml b/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml index 7065a8a981..f47e0a3b0b 100644 --- a/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for reporting a set of diffraction images. diff --git a/contributed_definitions/NXimage_set_em_ecci.nxdl.xml b/contributed_definitions/NXimage_set_em_ecci.nxdl.xml index 820ec8869f..949d708472 100644 --- a/contributed_definitions/NXimage_set_em_ecci.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_ecci.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for reporting back-scattered electron channeling contrast images. diff --git a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml index 8d052150de..ee89aa5162 100644 --- a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml @@ -92,6 +92,7 @@ the spatial arrangement of the features, their individual properties, and (macroscopic) properties of materials. + Details how Kikuchi pattern were processed from the detector readings. @@ -144,12 +145,20 @@ + Kikuchi pattern intensity + Pattern are enumerated starting from 0 to n_p - 1. @@ -190,4 +199,7 @@ + diff --git a/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml b/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml index 8ab388cf25..d83a9f3647 100644 --- a/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for reporting a set of images related to a ronchigram. diff --git a/contributed_definitions/NXimage_set_em_se.nxdl.xml b/contributed_definitions/NXimage_set_em_se.nxdl.xml index a5ab12200b..a86f9398dc 100644 --- a/contributed_definitions/NXimage_set_em_se.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_se.nxdl.xml @@ -1,6 +1,27 @@ - + - + + @@ -75,9 +96,9 @@ - Physical dimensions of the region-of-interest on + Physical dimensions of the region-of-interest on the specimen surface which the image covers. - The first and second number are the coordinates for the + The first and second number are the coordinates for the minimum edge, the third and fourth number are the coordinates for the maximum edge of the rectangular ROI. @@ -102,7 +123,7 @@ a specific kinetic energy. - + Container to store relevant settings affecting beam path, magnification, and working_distance diff --git a/contributed_definitions/NXinstrument.nxdl.xml b/contributed_definitions/NXinstrument.nxdl.xml index bec81c7a30..dedadac67c 100644 --- a/contributed_definitions/NXinstrument.nxdl.xml +++ b/contributed_definitions/NXinstrument.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Collection of the components of the instrument or beamline. Template of instrument descriptions comprising various beamline components. Each component @@ -74,9 +95,9 @@ - .. index:: plotting - Declares which child group contains a path leading to a :ref:`NXdata` group. - It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + .. index':'':' plotting + Declares which child group contains a path leading to a ':'ref':'`NXdata` group. + It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml index a6beeb6482..f16afbc2c2 100644 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Base class for storing details about a modelled shape of interaction volume. @@ -13,24 +34,24 @@ Explicit or implicit descriptions are possible. - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy Further details on how the interaction volume can be quantified - is available in the literature for example: + is available in the literature for example':' - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + * `S. Richter et al. <https':'//doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https':'//doi.org/10.1017/S1431927622000083>`_ diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index c8c157827b..fa8bba72ca 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -40,6 +40,20 @@ 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 @@ -60,8 +74,9 @@ 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>`_ - - + + + @@ -69,21 +84,41 @@ 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, 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 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 should be filled with zero. + 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. @@ -111,17 +146,20 @@ 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, the - isotope_vector should be the preferred machine-readable format to use. + 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 labelled - as an ion of the here referred to ion_type. + (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/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 876db0de5e..fee057bb33 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -46,7 +46,7 @@ Then, the next desired temperature is set and an IV measurement is performed. - + diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml index e702f9fca0..a3777873d0 100644 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml @@ -32,6 +32,7 @@ Manual procedures, electro-chemical, vibropolishing. + Version specifier of this application definition. @@ -49,6 +50,7 @@ + @@ -58,6 +60,8 @@ A preparation step performed by a human or a robot/automated system. + @@ -66,17 +70,26 @@ Carrier/plate used on which the abrasive/(lubricant) mixture was applied. + Medium on the abrasive_medium_carrier (cloth or grinding plate) whereby material is abrasively weared. + Lubricant + Qualitative statement how the revelation of the machine was configured. @@ -130,17 +143,19 @@ Turns per unit time. + Force exerted on the sample to press it into the abrasive. + Seconds - + Qualitative statement how the material removal was characterized. @@ -155,8 +170,13 @@ How thick a layer was removed. - + A preparation step performed by a human or a robot/automated system diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml index a60bf2ca4d..5ed5c175a1 100644 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -31,6 +31,7 @@ Embedding of a sample in a medium for easing processability. + Version specifier of this application definition. @@ -48,6 +49,7 @@ + @@ -64,7 +66,7 @@ - Type of material. + Type of material. @@ -73,8 +75,19 @@ - Electrical conductivity of the embedding medium. + Electrical conductivity of the embedding medium. + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 6eb00bb69b..fa46ddab30 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -91,7 +91,7 @@ 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. diff --git a/contributed_definitions/NXmagnetic_kicker.nxdl.xml b/contributed_definitions/NXmagnetic_kicker.nxdl.xml index 78543de83f..6776755866 100644 --- a/contributed_definitions/NXmagnetic_kicker.nxdl.xml +++ b/contributed_definitions/NXmagnetic_kicker.nxdl.xml @@ -1,57 +1,66 @@ - - - - definition for a magnetic kicker. - - extended description of the kicker. - - - define position of beamline element relative to production target - - - kicker timing as defined by ``description`` attribute - - - - current set on supply. - - - current read from supply. - - - - voltage set on supply. - - - voltage read from supply. - - + + + definition for a magnetic kicker. + + + + extended description of the kicker. + + + + + define position of beamline element relative to production target + + + + + kicker timing as defined by ``description`` attribute + + + + + + current set on supply. + + + + + current read from supply. + + + + + + voltage set on supply. + + + + + voltage read from supply. + + + diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index ef2d40ad81..26b5071c4a 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -23,8 +23,8 @@ --> - Extension of NXpositioner to include fields to describe the use of - manipulators in photoemission experiments. + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index ff13c5e93d..72e222bb07 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -22,9 +22,13 @@ # For further information, see http://www.nexusformat.org --> + - This is the most general application definition for multidimensional - photoelectron spectroscopy. + This is the most general application definition for multidimensional + photoelectron spectroscopy. @@ -192,6 +196,7 @@ + Description of the detector type. @@ -323,6 +328,11 @@ other metadata file. In the case these are not available, free-text description. + In the case of a fixed temperature measurement this is the scalar temperature of @@ -339,6 +349,7 @@ + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index fb81223cb7..274838adeb 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -21,6 +21,34 @@ # # For further information, see http://www.nexusformat.org --> + @@ -33,7 +61,7 @@ - Number of parameter required for chosen orientation parameterization. + Number of parameter required for the chosen orientation parameterization. @@ -52,6 +80,7 @@ that specifies the application definition. + NeXus NXDL schema to which this file conforms. @@ -101,12 +130,18 @@ Specify if the (characterization) results/data of this instance of an application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe a microstructure. + results of a post-processing of measured data to describe + a microstructure. + The term microstructure is used to describe the spatial arrangement of crystal defects inside a sample/specimen without demanding necessarily that this structure is mainly at the micron length scale. Nanostructure and macrostructure are close synonyms. Material architecture is a narrow synonym. + + Given that microstructure simulations nowadays more and more consider + the atomic arrangement, this application definition can also be used + to describe features at the scale of atoms. @@ -181,12 +216,25 @@ + Descriptive name or ideally (globally) unique persistent identifier. + Hard link to a location in the hierarchy of the NeXus file @@ -197,8 +245,8 @@ Container to hold different coordinate systems conventions. A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Using one NXtransformations - instance per base vector. + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. @@ -229,6 +277,10 @@ + The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -236,13 +288,16 @@ to contain details about the boundary conditions. - + - + + A boundary to the volume element. Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. + How many distinct boundaries are distinguished. Value required equal to n_b. @@ -290,6 +345,7 @@ notation) respectively. + Summary quantities which are the result of some post-processing of @@ -306,10 +362,10 @@ - - - + @@ -322,27 +378,51 @@ Iteration or increment counter. + - - - Details about statistically or explicitly resolved - atoms in the entire domain. - - - - - Details about statistically or explicitly resolved - dislocations in the entire domain. - - - + + - Details about statistically or explicitly resolved - interfaces between crystals in the entire domain. + Conceptually distinguished object/feature in the ROI/ + system with some relevance. Instances of NXms_feature_set can + be nested to build a hierarchy of logically-related objects. + + A typical example for MD simulations is to have one + ms_feature_set for the atoms which is the parent to another + ms_feature_set for monomers/molecules/proteins which is then the + parent to another ms_feature_set for the secondary, another feature_set + for the tertiary, and the parent for another feature_set for the + quaternary structure. + + Another typical example from materials engineering is to have + one ms_feature_set for crystals (grains/phases) which serves as + the parent to another ms_feature_set for interfaces between these + crystals which then is the parent for another ms_feature_set to + describe the triple junctions which is then the parent for the + quadruple/higher-order junctions between which connect the + triple lines. + + Another example from discrete dislocation dynamics could be to + have one ms_feature_set for the dislocations (maybe separate + sets for each dislocation type or family) which are then + parents to other ms_feature_set which describe junctions between + dislocations or features along the dislocation line network. + Details about the orientation distribution function @@ -353,6 +433,7 @@ With which method was the ODF approximated? + TO BE DEFINED @@ -373,7 +454,7 @@ which the definitions are interpretable. - + @@ -388,7 +469,7 @@ - + Name of each texture component, e.g. Cube, Dillamore, Y. @@ -415,6 +496,8 @@ + Details about the disorientation distribution function @@ -427,6 +510,8 @@ within the entire domain. + diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml new file mode 100644 index 0000000000..07173292f1 --- /dev/null +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -0,0 +1,300 @@ + + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Dimensionality + + + + + Cardinality/number of members/features in the feature set. + + + + + Number of types in the dictionary of human-readable types of features. + + + + + Total number of parent identifier. + + + + + Set of topological/spatial features in materials build from other features. + + + + + + Name (or link?) to another NXms_feature_set which defines features what are + assumed as the parents/super_features of all members in this feature set. + If depends_on is set to "." or this attribute is not defined in an instance + of this application definition, assume that this feature_set instance + represents the root feature_set of the feature tree/graph. + + + + + + + What is the best matching description how dimensional the feature is. + + + + + + + + + + + + How many features/members are in this set? + + + + + + The keywords of the dictionary of human-readable types of features. + Using terms from a community-agreed upon controlled vocabulary, e.g. + atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, + quadruple junction, triple line, disconnection, dislocation, + kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, + surface, thermal_groove_root, precipitate, dispersoid, pore, crack + is recommended. + + + + + + + + + The integer identifier used to resolve of which type each feature is, + i.e. the values of the dictionary of human-readable types of features. + + + + + + + + For each feature in the set specify the associated number of identifier + to parent features as are resolvable via depends_on. + This array enables to compute the array interval from which details for + specific features can be extracted as if they would be stored in an own + group. + + + + + + + + Concatenated array of parent identifier for each feature (in the sequence) + according to identifier and how the identifier of features in the here + described feature set are defined (implicitly from 0, to c-1 or via explicit + identifier. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + features. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish features for explicit indexing. + + + + + + + + + Assumptions and parameter to arrive at geometric primitives + to locate zero-dimensional/point-(like) features which are + discretized/represented by points. + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + + Assumptions and parameters to arrive at geometric primitives + to locate one-dimensional/line-like features which are + discretized by polylines. + + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + Assumptions and parameters to arrive at geometric primitives + to locate two-dimensional/interface features which are + discretized by triangulated surface meshes. + + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + Assumptions and parameters to arrive at geometric primitives + to locate three-dimensional/volumetric features which are + discretized by triangulated surface meshes of polyhedra. + + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + + + + + diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml index c9aa3ac0a6..fafa5217d3 100644 --- a/contributed_definitions/NXms_score_config.nxdl.xml +++ b/contributed_definitions/NXms_score_config.nxdl.xml @@ -89,8 +89,8 @@ Relevant data to instantiate a starting configuration that is typically a microstructure in deformed conditions where stored (elastic) energy - is stored in the form of crystal defects (in SCORE) modelled as - dislocation content. + is stored in the form of crystal defects, which in the SCORE model are + is considered as mean-field dislocation content. @@ -110,7 +110,8 @@ - Extend of each CA domain in voxel along the x, y, and z direction. Deformation of sheet material is assumed. + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. The x axis is assumed pointing along the rolling direction. The y axis is assumed pointing along the transverse direction. The z axis is assumed pointing along the normal direction. @@ -121,7 +122,7 @@ - Extend of each deformed grain along the x, y, and z direction when type is cuboidal. + Extent of each deformed grain along the x, y, and z direction when type is cuboidal. @@ -142,6 +143,10 @@ + + The EBSD dataset from which the initial microstructure is instantiated + if initial_microstructure/type has value ebsd. + Path and name of the EBSD dataset from which to generate the starting microstructure. @@ -154,7 +159,8 @@ - Size of the EBSD. The EBSD has to be on a regular grid of squares. + Size of the EBSD. The EBSD orientation mapping has to be on a + regular grid of square-shaped pixels. @@ -169,7 +175,10 @@ - According to which model will the nuclei become distributed spatially. CSR means complete spatial randomness, custom is implementation specific, GB places nuclei at grain boundaries. + According to which model will the nuclei become distributed spatially. + CSR means complete spatial randomness. + Custom is implementation specific. + GB places nuclei at grain boundaries. @@ -185,6 +194,14 @@ + + + According to which model will the nuclei get their orientation assigned. + + + + + Set of Bunge-Euler angles to sample orientations of nuclei randomly from. @@ -197,8 +214,8 @@ - Mechanical properties of the material which scale the amount - of stored (elastic) energy in the system. + (Mechanical) properties of the material which scale the amount + of stored (elastic) energy in the ROI/system. @@ -210,6 +227,10 @@ Magnitude at the Burgers vector at zero Kelvin. + Melting temperature in degrees Celsius. @@ -231,7 +252,7 @@ - + @@ -239,7 +260,7 @@ - + @@ -322,7 +343,7 @@ - Criteria which enable to stop the simulation. + Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 131c9e352c..d68f6f50c4 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -75,7 +76,7 @@ * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ - * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ @@ -84,6 +85,7 @@ that specifies the application definition. + NeXus NXDL schema to which this file conforms. @@ -145,6 +147,7 @@ + The path and name of the config file for this analysis. @@ -163,7 +166,7 @@ current working directory. - + A statement whether the SCORE executable managed to process the analysis or failed prematurely. @@ -248,12 +251,25 @@ + Descriptive name or ideally (globally) unique persistent identifier. + Hard link to a location in the hierarchy of the NeXus file @@ -264,8 +280,8 @@ Container to hold different coordinate systems conventions. A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Using one NXtransformations - instance per base vector. + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. @@ -296,6 +312,9 @@ + The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -306,15 +325,17 @@ + + + + - - - - A tight bounding box or sphere or bounding primitive about the grid. + How many distinct boundaries are distinguished? @@ -322,7 +343,7 @@ six sides can be distinguished, each making an own boundary. - + Name of the boundaries. E.g. left, right, front, back, bottom, top, The field must have as many entries as there are number_of_boundaries. @@ -362,6 +383,7 @@ notation) respectively. + Summary quantities which are the result of some post-processing of @@ -371,11 +393,39 @@ modelled as an instance of an NXprocess because it is relevant to understand how the descriptors are computed. - - - - + + + Evolution of the physical time. + + + + + Evolution of the simulated temperature over time. + + + + + + Evolution of the recrystallized volume fraction over time. + + + @@ -383,11 +433,17 @@ Not to be confused with wall-clock timing or profiling data. + + + Simulated temperature. + + Iteration or increment counter. + @@ -410,12 +466,21 @@ + Details about those cells which in this time step represent the discretized recrystallization front. - + + + Which cells are currently in a halo region of threads. + + + + + + So-called mobility weight which is a scaling factor to control the mobility of the grain boundary which is assumed @@ -475,7 +540,7 @@ - + Current grain-related quantities. @@ -525,13 +590,6 @@ - - - - Simulated temperature. - - - Current recrystallized volume fraction. @@ -549,9 +607,39 @@ + + + + + Currently assumed globally applied Cauchy stress tensor on the ROI. + + + + + + + + + + + Currently assumed globally applied Cauchy strain tensor on the ROI. + + + + + + + + @@ -601,18 +689,21 @@ + Specify if it was different from the number_of_processes in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml index 1f68d4dc86..040607189c 100644 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -52,5 +52,11 @@ or from 0 (referred to as C-, Python-style index notation) respectively. + + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 4ddb466d73..b36ebee14d 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -25,6 +25,9 @@ A container for qualifying an electron optical system. + Citing the JEOL TEM glossary this is *an effective distance from a specimen @@ -68,9 +71,13 @@ using the beam_current_description field. - + Specify further details how the beam current was measured or estimated. + diff --git a/contributed_definitions/NXorientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml index 026aab2fba..9183f4afbf 100644 --- a/contributed_definitions/NXorientation_set.nxdl.xml +++ b/contributed_definitions/NXorientation_set.nxdl.xml @@ -22,6 +22,9 @@ # For further information, see http://www.nexusformat.org --> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,19 +56,30 @@ * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge + Reference to or definition of a coordinate system with which the definitions are interpretable. - + - + + A link or reference to the objects whose identifier are referred to in identifier to resolve which row tuple is the orientation of each object @@ -112,4 +126,8 @@ + + diff --git a/contributed_definitions/NXprocess.nxdl.xml b/contributed_definitions/NXprocess.nxdl.xml index 5b12ff4776..33b0458a8d 100644 --- a/contributed_definitions/NXprocess.nxdl.xml +++ b/contributed_definitions/NXprocess.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Document an event of data processing, reconstruction, or analysis for this data. @@ -50,14 +71,14 @@ - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. + .. 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 + 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/contributed_definitions/NXprogram.nxdl.xml index 7f769690f3..ca42571e62 100644 --- a/contributed_definitions/NXprogram.nxdl.xml +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -30,15 +30,10 @@ Base class to describe a software tool or library. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - Commercial, parser, or otherwise given name to the program. + Given name of the program. Program can be a commercial one a script, + or a library or a library component. diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index cfeb2c915f..feadaffa46 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -50,12 +50,23 @@ Frequency with which the high voltage or laser pulser fires. + + + + Fraction of the pulse_voltage that is applied in addition to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + @@ -66,11 +77,19 @@ + + + Absolute number of pulses starting from the beginning of the experiment. + + + + + - Direct current voltage between the specimen and the - (local electrode) in the case of local electrode atom - probe (LEAP) instrument. + Direct current voltage between the specimen and the (local electrode) in + the case of local electrode atom probe (LEAP) instrument. + The standing voltage applied to the sample, relative to system ground. @@ -99,6 +118,7 @@ Nominal power of the laser source while illuminating the specimen. + Average energy of the laser at peak of each pulse. @@ -121,6 +141,14 @@ Details about specific positions along the focused laser beam which illuminates the (atom probe) specimen. + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + Track time-dependent settings over the course of the diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index b536259d6b..902a820d85 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -37,4 +37,7 @@ + diff --git a/contributed_definitions/NXquadric.nxdl.xml b/contributed_definitions/NXquadric.nxdl.xml index 8f061f3af0..e656577810 100644 --- a/contributed_definitions/NXquadric.nxdl.xml +++ b/contributed_definitions/NXquadric.nxdl.xml @@ -1,14 +1,14 @@ - + - - definition of a quadric surface. - + - Ten real values of the matrix that defines the quadric surface - in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, - P2, P3, R. Takes a units attribute of dimension reciprocal - length. R is scalar. P has dimension reciprocal length, and the - given units. Q has dimension reciprocal length squared, and - units the square of those given. + definition of a quadric surface. - - - - - - - An optional description of the form of the quadric surface: - - - - - - - - - - - - - - - - - - - - - - - - - - Path to an :ref:`NXtransformations` that defining the axis on - which the orientation of the surface depends. - - + + + Ten real values of the matrix that defines the quadric surface + in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, + P2, P3, R. Takes a units attribute of dimension reciprocal + length. R is scalar. P has dimension reciprocal length, and the + given units. Q has dimension reciprocal length squared, and + units the square of those given. + + + + + + + + An optional description of the form of the quadric surface':' + + + + + + + + + + + + + + + + + + + + + + + + + + Path to an ':'ref':'`NXtransformations` that defining the axis on + which the orientation of the surface depends. + + diff --git a/contributed_definitions/NXquadrupole_magnet.nxdl.xml b/contributed_definitions/NXquadrupole_magnet.nxdl.xml index 14b97b75eb..2e6306501f 100644 --- a/contributed_definitions/NXquadrupole_magnet.nxdl.xml +++ b/contributed_definitions/NXquadrupole_magnet.nxdl.xml @@ -1,51 +1,55 @@ - - - - definition for a quadrupole magnet. - -extended description of the magnet. - - -define position of beamline element relative to production target - - -current set on supply. - - -current read from supply. - - - -voltage read from supply. - - + + + definition for a quadrupole magnet. + + + + extended description of the magnet. + + + + + define position of beamline element relative to production target + + + + + current set on supply. + + + + + current read from supply. + + + + + + voltage read from supply. + + + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml index 5b53b8a794..5d0262be25 100644 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -24,6 +24,9 @@ Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). @@ -37,6 +40,7 @@ The field can be used to inform e. g. if the reflectron is flat or curved. + Affine transformation(s) which detail where the reflectron diff --git a/contributed_definitions/NXregion.nxdl.xml b/contributed_definitions/NXregion.nxdl.xml index bffff2da59..0d41d0c091 100644 --- a/contributed_definitions/NXregion.nxdl.xml +++ b/contributed_definitions/NXregion.nxdl.xml @@ -1,14 +1,14 @@ - + - - - - These symbols will denote how the shape of the parent group's data field, - - .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) - - could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, - and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, - where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. - - Outer rank - Region rank - - - Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. - - This can be used to describe a subset of data used to create downsampled data or to derive - some data from that subset. - - Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters - (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, - then **stride** :math:`\equiv` **step** in Python slicing. - - For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: - - detector:NXdetector/ - data[60,256,512] - region:NXregion/ - @region_type = "rectangular" - parent = "data" - start = [20,50] - count = [220,120] - statistics:NXdata/ - @signal = "sum" - sum[60] - - the ``sum`` dataset contains the summed areas in each frame. - Another example, a hyperspectral image downsampled 16-fold in energy:: - - detector:NXdetector/ - data[128,128,4096] - region:NXregion/ - @region_type = "rectangular" - parent = "data" - start = [2] - count = [20] - stride = [32] - block = [16] - downsampled:NXdata/ - @signal = "maximum" - @auxiliary_signals = "copy" - maximum[128,128,20] - copy[128,128,320] - - the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, - the ``maximum`` dataset will show maximum values in each 16-channel block - in every spectra. - - - - This is ``rectangular`` to describe the region as a hyper-rectangle in - the index space of its parent group's data field. - - - - - - - - The name of data field in the parent group or the path of a data field relative - to the parent group (so it could be a field in a subgroup of the parent group) - - - - - The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and - dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an - :ref:`NXdetector`. - - - - - The starting position for region in detector data field array. - This is recommended as it also defines the region rank. - If omitted then defined as an array of zeros. - - - - - - - - The number of blocks or items in the hyperslab selection. - If omitted then defined as an array of dimensions that take into account - the other hyperslab selection fields to span the parent data field's shape. - - - - - - - - An optional field to define striding used to downsample data. - If omitted then defined as an array of ones. - - - - - - - - An optional field to define the block size used to copy or downsample data. In the - :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` - then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` - then the blocks are contiguous; otherwise the blocks overlap. - If omitted then defined as an array of ones. - - - - - - - - An optional field to define a divisor for scaling of reduced data. For example, in a - downsampled sum, it can reduce the maximum values to fit in the domain of the result - data type. In an image that is downsampled by summing 2x2 blocks, using - :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as - the parent dataset. - If omitted then no scaling occurs. - - - - - - - - An optional group containing data copied/downsampled from parent group’s data. Its dataset name - must reflect how the downsampling is done over each block. So it could be a reduction operation - such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each - block then use "copy" as the name. Where more than one downsample dataset is written - (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, - the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, - otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. - - The following figure shows how blocks are used in downsampling: - - .. figure:: region/NXregion-example.png - :width: 60% - - A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from - a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. - - - - - - An optional group containing any statistics derived from the region in parent group’s data - such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one - statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` - listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. - - + + + + These symbols will denote how the shape of the parent group's data + field, .. math':'':' (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., + d_{\mathbf{R}-1}) could be split into a left set of **O** outer + dimensions, ':'math':'`\boldsymbol{D}`, and a right set of **R** + region dimensions, ':'math':'`\boldsymbol{d}`, where the data field + has rank **O** + **R**. Note **O** ':'math':'`>= 0`. + + + + Outer rank + + + + + Region rank + + + + + Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, ':'ref':'`NXdetector`. + + This can be used to describe a subset of data used to create downsampled data or to derive + some data from that subset. + + Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters + (see https':'//portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** ':'math':'`= 1`, + then **stride** ':'math':'`\equiv` **step** in Python slicing. + + For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data':'':' + + detector':'NXdetector/ + data[60,256,512] + region':'NXregion/ + @region_type = "rectangular" + parent = "data" + start = [20,50] + count = [220,120] + statistics':'NXdata/ + @signal = "sum" + sum[60] + + the ``sum`` dataset contains the summed areas in each frame. + Another example, a hyperspectral image downsampled 16-fold in energy':'':' + + detector':'NXdetector/ + data[128,128,4096] + region':'NXregion/ + @region_type = "rectangular" + parent = "data" + start = [2] + count = [20] + stride = [32] + block = [16] + downsampled':'NXdata/ + @signal = "maximum" + @auxiliary_signals = "copy" + maximum[128,128,20] + copy[128,128,320] + + the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, + the ``maximum`` dataset will show maximum values in each 16-channel block + in every spectra. + + + + This is ``rectangular`` to describe the region as a hyper-rectangle in + the index space of its parent group's data field. + + + + + + + + The name of data field in the parent group or the path of a data field relative + to the parent group (so it could be a field in a subgroup of the parent group) + + + + + The name of an optional mask field in the parent group with rank ':'math':'`\boldsymbol{R}` and + dimensions ':'math':'`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an + ':'ref':'`NXdetector`. + + + + + The starting position for region in detector data field array. + This is recommended as it also defines the region rank. + If omitted then defined as an array of zeros. + + + + + + + + The number of blocks or items in the hyperslab selection. + If omitted then defined as an array of dimensions that take into account + the other hyperslab selection fields to span the parent data field's shape. + + + + + + + + An optional field to define striding used to downsample data. + If omitted then defined as an array of ones. + + + + + + + + An optional field to define the block size used to copy or downsample data. In the + ':'math':'`i`-th dimension, if ':'math':'`\mathbf{block}[i] < \mathbf{stride}[i]` + then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` + then the blocks are contiguous; otherwise the blocks overlap. + If omitted then defined as an array of ones. + + + + + + + + An optional field to define a divisor for scaling of reduced data. For example, in a + downsampled sum, it can reduce the maximum values to fit in the domain of the result + data type. In an image that is downsampled by summing 2x2 blocks, using + ':'math':'`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as + the parent dataset. + If omitted then no scaling occurs. + + + + + + + + An optional group containing data copied/downsampled from parent group’s data. Its dataset name + must reflect how the downsampling is done over each block. So it could be a reduction operation + such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each + block then use "copy" as the name. Where more than one downsample dataset is written + (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, + the field should have a shape of ':'math':'`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, + otherwise the expected shape is ':'math':'`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. + + The following figure shows how blocks are used in downsampling':' + + .. figure':'':' region/NXregion-example.png + ':'width':' 60% + + A selection with ':'math':'`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from + a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. + + + + + An optional group containing any statistics derived from the region in parent group’s data + such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one + statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` + listing the others. All data fields should have shapes of ':'math':'`\boldsymbol{D}`. + + diff --git a/contributed_definitions/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml index c725562743..155ca9c2a2 100644 --- a/contributed_definitions/NXregistration.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -23,7 +23,7 @@ --> - Describes image registration procedures. + Describes image registration procedures. diff --git a/contributed_definitions/NXsample.nxdl.xml b/contributed_definitions/NXsample.nxdl.xml index 5dac64b788..82030fac94 100644 --- a/contributed_definitions/NXsample.nxdl.xml +++ b/contributed_definitions/NXsample.nxdl.xml @@ -1,6 +1,27 @@ - + - + + symbolic array lengths to be coordinated between various fields @@ -51,21 +72,21 @@ The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: + Abbreviated version of CIF standard':' * 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 + * 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 + * 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: + * 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. + - 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. * This is the *Hill* system used by Chemical Abstracts. @@ -170,7 +191,7 @@ - This will follow the Busing-Levy convention: + This will follow the Busing-Levy convention':' W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 @@ -180,7 +201,7 @@ - Orientation matrix of single crystal sample using Busing-Levy convention: + Orientation matrix of single crystal sample using Busing-Levy convention':' W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 @@ -192,12 +213,12 @@ - UB matrix of single crystal sample using Busing-Levy convention: + 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 + This is the multiplication of the orientation_matrix, + given above, with the ':'math':'`B` matrix which can be derived from the lattice constants. @@ -585,14 +606,14 @@ - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. + .. 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 4bb59f8bf1..82449a42b0 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -31,11 +31,17 @@ + + + diff --git a/contributed_definitions/NXseparator.nxdl.xml b/contributed_definitions/NXseparator.nxdl.xml index be3e7ce26f..cb028d2c43 100644 --- a/contributed_definitions/NXseparator.nxdl.xml +++ b/contributed_definitions/NXseparator.nxdl.xml @@ -1,58 +1,72 @@ - - - - definition for an electrostatic separator. - - extended description of the separator. - - - define position of beamline element relative to production target - - - current set on magnet supply. - - - current read from magnet supply. - - - - voltage read from magnet supply. - - - - current set on HT supply. - - - current read from HT supply. - - - - voltage read from HT supply. - - + + + definition for an electrostatic separator. + + + + extended description of the separator. + + + + + define position of beamline element relative to production target + + + + + current set on magnet supply. + + + + + current read from magnet supply. + + + + + + voltage read from magnet supply. + + + + + + current set on HT supply. + + + + + current read from HT supply. + + + + + + voltage read from HT supply. + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 1813e2d194..fba612d346 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -78,6 +78,10 @@ How many categorical labels does each feature have. + Which identifier is the first to be used to label a cluster. @@ -108,6 +112,8 @@ Matrix of categorical attribute data for each member in the set. + @@ -118,6 +124,7 @@ In addition to the detailed storage which members was grouped to which feature/group summary statistics are stored under this group. + Total number of members in the set which are categorized as unassigned. @@ -134,6 +141,7 @@ + Total number of clusters (excluding noise and unassigned). diff --git a/contributed_definitions/NXslip_system_set.nxdl.xml b/contributed_definitions/NXslip_system_set.nxdl.xml index 12f064ce2c..3b134d6b91 100644 --- a/contributed_definitions/NXslip_system_set.nxdl.xml +++ b/contributed_definitions/NXslip_system_set.nxdl.xml @@ -35,7 +35,11 @@ Base class for describing a set of crystallographic slip systems. + + @@ -46,6 +50,9 @@ + Array of Miller indices which describe the crystallographic plane. @@ -55,6 +62,7 @@ + Array of Miller indices which describe the crystallographic direction. diff --git a/contributed_definitions/NXsnsevent.nxdl.xml b/contributed_definitions/NXsnsevent.nxdl.xml index 934ada4985..b9079cc50a 100644 --- a/contributed_definitions/NXsnsevent.nxdl.xml +++ b/contributed_definitions/NXsnsevent.nxdl.xml @@ -1,328 +1,339 @@ - + - - This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. - - - - Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). - - - - - - - - - - - - - - - - - - - - - - - Motor logs from cvinfo file. - - - - - - - - - - - - - - - - - - - - - - - - - - - Command string for event2nxl. - - - - - - - - - - - - - - - - - - - - - - - - Official NXDL schema after this file goes to applications. - - - - - - - - - - - - - - - + + + This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. + + + + + Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). + + + + + + + + + + + + + + + + + + + + + + + Motor logs from cvinfo file. + + + + + + + + + + + + + + + + + + + + + + + + + + + Command string for event2nxl. + + + + + - - - Detector calibration id from DAS. - + + + + + + + + + + + + + + + + Official NXDL schema after this file goes to applications. + + + + - - - - - - - - - - - - - expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + - Six out of nine rotation parameters. + Detector calibration id from DAS. - - - - + + + + + + + + + + + + + expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Six out of nine rotation parameters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - + + + - - - - - - + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Six out of nine rotation parameters. - - - - - + + + + + + + Six out of nine rotation parameters. + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - + + - - - - - - + + + + + + + + Six out of nine rotation parameters. + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - + + - Six out of nine rotation parameters. + expect ``signal=1 axes="time_of_flight"`` - + - - - - - - - - - - + + + + - + - - - - - + + + + + + + + + + + + + Descriptive name of sample + + + + + + + + + + + + - - - - expect ``signal=1 axes="time_of_flight"`` - - - - - - - - - - - - - - - - - - - - - - Descriptive name of sample - - - - - - - - - - - - diff --git a/contributed_definitions/NXsnshisto.nxdl.xml b/contributed_definitions/NXsnshisto.nxdl.xml index 2e94b7c71e..d23908f5f4 100644 --- a/contributed_definitions/NXsnshisto.nxdl.xml +++ b/contributed_definitions/NXsnshisto.nxdl.xml @@ -1,341 +1,350 @@ - + - - This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. - - - - Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). - - - - - - - - - - - - - - - - - - - - - - - Motor logs from cvinfo file. - - - - - - - - - - - - - - - - - - - - - - - - - - - Command string for event2histo_nxl. - - - - - - - - - - - - - - - - - - - - - - - Official NXDL schema after this file goes to applications. - - - - - - - - - - - - - - - + + + This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. + + + + + Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). + + + + + + + + + + + + + + + + + + + + + + + Motor logs from cvinfo file. + + + + + + + + + + + + + + + + + + + - - - Detector calibration id from DAS. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + - Six out of nine rotation parameters. + Command string for event2histo_nxl. - - - - + + + + + + + + + + + + + + + + + + + + + Official NXDL schema after this file goes to applications. + + + + + + + + + + + + + + + - - - - - - - - + + + Detector calibration id from DAS. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Six out of nine rotation parameters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - + + + + Original specification called for NXchopper, + which is not a valid NeXus base class. + Select either NXdisk_chopper or NXfermi_chopper, as appropriate. + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Original specification called for NXchopper, - which is not a valid NeXus base class. - Select either NXdisk_chopper or NXfermi_chopper, as appropriate. - - - - - - Original specification called for NXchopper, - which is not a valid NeXus base class. - Select either NXdisk_chopper or NXfermi_chopper, as appropriate. - - - - - - - - - - - - - - + - Six out of nine rotation parameters. + Original specification called for NXchopper, + which is not a valid NeXus base class. + Select either NXdisk_chopper or NXfermi_chopper, as appropriate. - - - - + - - - - - - - - + + + + + - - - - - - + + + + + + + Six out of nine rotation parameters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Six out of nine rotation parameters. + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - Six out of nine rotation parameters. - + + - + - - - - - - - - - - + + + + - + - - - - - + + + + + + + + + + + + + Descriptive name of sample + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - Descriptive name of sample - - - - - - - - - - - - diff --git a/contributed_definitions/NXsolenoid_magnet.nxdl.xml b/contributed_definitions/NXsolenoid_magnet.nxdl.xml index 457d5225b2..4fa4ca8992 100644 --- a/contributed_definitions/NXsolenoid_magnet.nxdl.xml +++ b/contributed_definitions/NXsolenoid_magnet.nxdl.xml @@ -1,51 +1,55 @@ - - - -definition for a solenoid magnet. - -extended description of the magnet. - - -define position of beamline element relative to production target - - -current set on supply. - - -current read from supply. - - - -voltage read from supply. - - + + + definition for a solenoid magnet. + + + + extended description of the magnet. + + + + + define position of beamline element relative to production target + + + + + current set on supply. + + + + + current read from supply. + + + + + + voltage read from supply. + + + diff --git a/contributed_definitions/NXsolid_geometry.nxdl.xml b/contributed_definitions/NXsolid_geometry.nxdl.xml index f5bcaa742d..060b3d2f2f 100644 --- a/contributed_definitions/NXsolid_geometry.nxdl.xml +++ b/contributed_definitions/NXsolid_geometry.nxdl.xml @@ -1,14 +1,14 @@ - + - - - the head node for constructively defined geometry - - + - Instances of :ref:`NXquadric` making up elements of the geometry. + the head node for constructively defined geometry - - - - Instances of :ref:`NXoff_geometry` making up elements of the geometry. - - - - - The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. - - + + + Instances of ':'ref':'`NXquadric` making up elements of the geometry. + + + + + Instances of ':'ref':'`NXoff_geometry` making up elements of the geometry. + + + + + The geometries defined, made up of instances of ':'ref':'`NXquadric` and ':'ref':'`NXoff_geometry`. + + diff --git a/contributed_definitions/NXsource.nxdl.xml b/contributed_definitions/NXsource.nxdl.xml index ae24b92e00..7d9d802740 100644 --- a/contributed_definitions/NXsource.nxdl.xml +++ b/contributed_definitions/NXsource.nxdl.xml @@ -1,6 +1,27 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays @@ -95,7 +116,7 @@ - Source intensity/area (example: s-1 cm-2) + Source intensity/area (example':' s-1 cm-2) @@ -260,14 +281,14 @@ - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. + .. 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 + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 28d2e2c518..599fc8f04f 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -21,6 +21,9 @@ # # For further information, see http://www.nexusformat.org --> + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 0000000000..0ee718b967 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_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 NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml b/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml index e41ce1a860..97ce9f69cd 100644 --- a/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for reporting a set of auger electron energy spectra. diff --git a/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml b/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml index 20ce7bf72d..1e400215f5 100644 --- a/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml @@ -1,6 +1,27 @@ - + - + + Container for reporting a set of cathodoluminescence spectra. diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml index dd6df8264d..f27a45e546 100644 --- a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -23,6 +23,7 @@ --> + Number of pixel per EELS mapping in the slow direction. @@ -104,6 +105,11 @@ + Pixel center of mass position y-coordinates. @@ -162,6 +168,9 @@ + Pixel center of mass energy loss bins. diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml index af0e8dccd4..34a40d60db 100644 --- a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -22,7 +22,10 @@ # For further information, see http://www.nexusformat.org --> + + Number of pixel per X-ray mapping in the slow direction @@ -97,6 +100,8 @@ + Collected X-ray spectra for all pixels of a rectangular region-of-interest. @@ -114,6 +119,11 @@ + @@ -160,6 +170,9 @@ + @@ -171,6 +184,7 @@ + Details about computational steps how peaks were indexed as elements. @@ -250,6 +264,7 @@ Human-readable, given name to the image. + Individual element-specific maps. Individual maps should @@ -266,6 +281,10 @@ + diff --git a/contributed_definitions/NXspin_rotator.nxdl.xml b/contributed_definitions/NXspin_rotator.nxdl.xml index a86744af3f..0a25bee8ac 100644 --- a/contributed_definitions/NXspin_rotator.nxdl.xml +++ b/contributed_definitions/NXspin_rotator.nxdl.xml @@ -1,58 +1,72 @@ - - - - definition for a spin rotator. - - extended description of the spin rotator. - - - define position of beamline element relative to production target - - - current set on magnet supply. - - - current read from magnet supply. - - - - voltage read from magnet supply. - - - - current set on HT supply. - - - current read from HT supply. - - - - voltage read from HT supply. - - + + + definition for a spin rotator. + + + + extended description of the spin rotator. + + + + + define position of beamline element relative to production target + + + + + current set on magnet supply. + + + + + current read from magnet supply. + + + + + + voltage read from magnet supply. + + + + + + current set on HT supply. + + + + + current read from HT supply. + + + + + + voltage read from HT supply. + + + diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index 6539130950..689d40a7cf 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -23,8 +23,8 @@ --> - Subclass of NXelectronanalyser to describe the spin filters in - photoemission experiments. + Subclass of NXelectronanalyser to describe the spin filters in photoemission + experiments. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 308a23cc6d..f1eed76c4c 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -147,6 +147,7 @@ Voltage applied to the stage to decelerate electrons. + The rotation, tilt and position of stage components can be specified @@ -155,4 +156,18 @@ + diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 8362cce7d0..f35ff39e74 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -21,6 +21,8 @@ # # For further information, see http://www.nexusformat.org --> + @@ -38,7 +40,7 @@ - Application definition for transmission experiments + Application definition for transmission experiments @@ -86,6 +88,10 @@ definition rather than in this experiment description. + @@ -327,6 +333,8 @@ + Properties of the sample measured diff --git a/contributed_definitions/NXxpcs.nxdl.xml b/contributed_definitions/NXxpcs.nxdl.xml index 9839fbb2a9..e7327eeba6 100644 --- a/contributed_definitions/NXxpcs.nxdl.xml +++ b/contributed_definitions/NXxpcs.nxdl.xml @@ -1,14 +1,14 @@ - + - - - - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - - Number of points - - - - X-ray Photon Correlation Spectroscopy (XPCS) data (results). - - The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data - in order to support development of community software tools. The definition presented here only - represents a starting point and contains fields that a common software tool should support for - community acceptance. - - Additional fields may be added to XPCS results file (either formally or informally). It is expected - that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or - 1D and/or 2D data. - - - - Official NeXus NXDL schema to which this file conforms - - - - - - - - **Locally** unique identifier for the experiment (a.k.a. run or scan). - - * For bluesky users, this is the run's `"scan_id"`. - * For SPEC users, this is the scan number (``SCAN_N``). - - - - - (optional) UUID identifier for this entry. - - See the `UUID standard <https://www.rfc-editor.org/rfc/rfc4122.html>`__ (or - `wikipedia <https://en.wikipedia.org/wiki/Universally_unique_identifier>`__) - for more information. - - * For `bluesky <https://blueskyproject.io/>`__ users, this is the - run's `"uid"` and is expected for that application. - * Typically, `SPEC <https://certif.com/content/spec/>`__ users will - not use this field without further engineering. - - - - - - Scan number (must be an integer). - - NOTE: Link to collection_identifier. - - - - - Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". - - - - - Ending time of experiment, such as "2021-02-11 11:23:45Z". - - - - - - The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) - describing on-equilibrium dynamics consume more memory resources so these data are separated. - - - - Two-dimensional summation along the frames stack. - - sum of intensity v. time (in the units of "frames") - - - - - Two-dimensional average along the frames stack. - - average intensity v. time (in the units of "frames") - - - - - normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 - - .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 - - Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific - region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some - open-source XPCS libraries refer to these bins as "rois", which are not to be confused with - EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ - - In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if - the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats: - - * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value - * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value - - Note it is expected that "g2" and all quantities following it will be of the same length. - - Other formats are acceptable with sufficient axes description. - - See references below for related implementation information: - - .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` - .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata - - - - storage_mode describes the format of the data to be loaded - - We encourage the documentation of other formats not represented here. - - * one array representing entire data set ("one_array") - * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") - - - - - - - - - - - error values for the :math:`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (:math:`\pm` error). The data should be in the same format as ``g2``. - - - - - - - - - - - - unnormalized intensity auto-correlation function. - - Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. - - - - - - - - - - - + + - delay_difference (also known as delay or lag step) - - This is quantized difference so that the "step" between two consecutive - frames is one frame (or step ``= dt = 1 frame``) - - It is the "quantized" delay time corresponding to the ``g2`` values. - - The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, - refer to :ref:`NXdetector` for conversion to time units. + The symbol(s) listed here will be used below to coordinate datasets + with the same shape. - - - - - - - - - - - + + + Number of points + + + - The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. + X-ray Photon Correlation Spectroscopy (XPCS) data (results). + + The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data + in order to support development of community software tools. The definition presented here only + represents a starting point and contains fields that a common software tool should support for + community acceptance. + + Additional fields may be added to XPCS results file (either formally or informally). It is expected + that this XPCS data will be part of multi-modal data set that could involve e.g., ':'ref':'`NXcanSAS` or + 1D and/or 2D data. - - - two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) - - See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early - description applied to X-ray scattering: - - .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } - - in which time is quantized by frames. In principle, any data format is acceptable if - the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats: - - * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array - * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value - - - The computation of this result can be customized. These customizations can affect subsequently derived results (below). The - following attributes will be used to manage the customization. - - * Other normalization methods may be applied, but the method will not be specified in this - definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. - - * The various software libraries use different programming languages. Therefore, we need to - specify the ``time = 0`` origin location of the 2D array for each :math:`q`. - - * A method to reduce data storage needs is to only record half of the 2D array by populating - array elements above or below the array diagonal. - - - - - - storage_mode describes the format of the data to be loaded - - We encourage the documention of other formats represented here. - - - - - - - - - - - baseline is the expected value of a full decorrelation - - The baseline is a constant value added to the functional form of the auto-correlation - function. This value is required. - - - - - - - - - time_origin_location is the location of the origin - - - - - - - - - populated_elements describe the elements of the 2D array that are populated with data - - - - - - - - - - - frame weighted average along the diagonal direction in ``two_time_corr_func`` - - The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" - - * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` - * 2D array with shape (:math:`g_2`, :math:`q`) - - Note that delay_difference is not included here because it is derived from the shape of - extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. - - The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The - following attributes will be used to manage the customization. - - - - - - - - - - - - - - - - - - - first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. - - The first_point_for_fit is True ("1") or False ("0"). This value is required. - - - - - - - - - - error values for the :math:`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (:math:`\pm` error). - - - - - - - - - - - - - subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` - - Time slicing along the diagonal can be very sophisticated. This entry currently assumes - equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. - In principle, any data format is acceptable if the data and its axes are self describing as per NeXus - recommendations. However, the data is preferred in one of the following two formats: - - * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value - * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) - - Note that delay_difference is not included here because it is derived from the shape of - extracted :math:`g_2`. - - - - - - - - - - - - - - - - - - - error values for the :math:`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (:math:`\pm` error). - - - - - - - XPCS instrument Metadata. - - Objects can be entered here directly or linked from other - objects in the NeXus file (such as within ``/entry/instrument``). - - - - Incident beam line energy (either keV or eV). - - - - Spread of incident beam line energy (either keV or eV). This quantity is otherwise known - as the energy resolution, which is related to the longitudinal coherence length. - - - - - Terse description of the incident beam polarization. - - The value can be plain text, such as ``vertical``, ``C+``, - ``circular left``. - - - - Size (2-D) of the beam at this position. - - - - - - - XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes - this data is represented in different ways (sparse arrays or photon event list), but this detail - is left to the analysis software. Therefore, we only include requirements based on full array data. - - We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This - is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ - See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and - the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI - documentation (See Fig 11 vs Fig 12). - - Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to - convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may - either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. - - .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html - - - Detector name. - - - Distance between sample and detector. - - - Exposure time of frames, s. - - - - Exposure period (time between frame starts) of frames, s - + + + + Official NeXus NXDL schema to which this file conforms + + + + - - - Position of beam center, x axis, in detector's coordinates. - + + + **Locally** unique identifier for the experiment (a.k.a. run or scan). + + * For bluesky users, this is the run's `"scan_id"`. + * For SPEC users, this is the scan number (``SCAN_N``). + - - - Position of beam center, y axis, in detector's coordinates. - + + + (optional) UUID identifier for this entry. + + See the `UUID standard <https':'//www.rfc-editor.org/rfc/rfc4122.html>`__ (or + `wikipedia <https':'//en.wikipedia.org/wiki/Universally_unique_identifier>`__) + for more information. + + * For `bluesky <https':'//blueskyproject.io/>`__ users, this is the + run's `"uid"` and is expected for that application. + * Typically, `SPEC <https':'//certif.com/content/spec/>`__ users will + not use this field without further engineering. + - - - - Length of pixel in x direction. - + + + Scan number (must be an integer). + + NOTE':' Link to collection_identifier. + - - - Length of pixel in y direction. - + + + Starting time of experiment, such as "2021-02-11 11':'22':'33.445566Z". + - - - - - Data masks or mappings to regions of interest (roi) for specific :math:`Q` values - - Fields in this ``masks`` group describe regions of interest - in the data by either a mask to select pixels or to associate - a *map* of rois with a (one-dimensional) *list* of values. - - "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, - which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. - - "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and - NXxpcs/entry/two_time. - - "Static" refers to finer binning used for computation not strictly used for the final - XPCS results. Implementation of _static_ binning is left for individual libraries to - document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or - development of new NeXus definitions for GI-SAXS or other reciprocal space - intensity mapping. - - + - roi index array or labeled array - - The values of this mask index (or map to) the :math:`Q` value from the - the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations - are performed on all pixels with a value > 0. - - The ``units`` attribute should be set to ``"au"`` - indicating arbitrary units. + Ending time of experiment, such as "2021-02-11 11':'23':'45Z". - - + + - 1-D list of :math:`Q` values, one for each roi index value. - - List order is determined by the index value of the associated roi map starting at ``1``. - - The only requirement for the list is that it may be iterable. Some expected formats are: - - * iterable list of floats (i.e., :math:`Q(r)`) - * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below - * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) - * iterable list of integers (for Nth roi_map value) or strings - - This format is chosen because results plotting packages are not common and simple I/O is required by end user. - The lists can be accessed as lists, arrays or via keys + The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) + describing on-equilibrium dynamics consume more memory resources so these data are separated. - - + + + Two-dimensional summation along the frames stack. + + sum of intensity v. time (in the units of "frames") + + + + + Two-dimensional average along the frames stack. + + average intensity v. time (in the units of "frames") + + + + + normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 + + .. math':'':' g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 + + Typically, ':'math':'`g_2` is a quantity calculated for a group of pixels representing a specific + region of reciprocal space. These groupings, or bins, are generically described as ':'math':'`q`. Some + open-source XPCS libraries refer to these bins as "rois", which are not to be confused with + EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ + + In short, ':'math':'`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if + the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one + of the following two formats':' + + * iterable list of linked files (or keys) for each ':'math':'`g_2` with 1 file (key) per ':'math':'`q`, where `q` is called by the nth roi_map value + * 2D array [#]_ with shape (':'math':'`g_2`, ':'math':'`q`), where `q` is represented by the nth roi_map value, not the value `q` value + + Note it is expected that "g2" and all quantities following it will be of the same length. + + Other formats are acceptable with sufficient axes description. + + See references below for related implementation information':' + + .. [#] mask':' ``NXxpcs':'/entry/instrument/masks-group`` + .. [#] NeXus 2-D data and axes':' https':'//manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata + + + + storage_mode describes the format of the data to be loaded + + We encourage the documentation of other formats not represented here. + + * one array representing entire data set ("one_array") + * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") + + + + + + + + + + + error values for the ':'math':'`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (':'math':'`\pm` error). The data should be in the same format as ``g2``. + + + + + + + + + + + + unnormalized intensity auto-correlation function. + + Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. + + + + + + + + + + + + delay_difference (also known as delay or lag step) + + This is quantized difference so that the "step" between two consecutive + frames is one frame (or step ``= dt = 1 frame``) + + It is the "quantized" delay time corresponding to the ``g2`` values. + + The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, + refer to ':'ref':'`NXdetector` for conversion to time units. + + + + + + + + + + + - Array of :math:`\varphi` value for each pixel. - - List order is determined by the index value of the associated roi map starting at ``1``. + The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. - - + + + two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) + + See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early + description applied to X-ray scattering':' + + .. math':'':' C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } + + in which time is quantized by frames. In principle, any data format is acceptable if + the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one + of the following two formats':' + + * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array + * 3D array with shape (frames, frames, q) or (q, frames, frames), where ':'math':'`q` is represented by the nth roi_map value, not the value `q` value + + + The computation of this result can be customized. These customizations can affect subsequently derived results (below). The + following attributes will be used to manage the customization. + + * Other normalization methods may be applied, but the method will not be specified in this + definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. + + * The various software libraries use different programming languages. Therefore, we need to + specify the ``time = 0`` origin location of the 2D array for each ':'math':'`q`. + + * A method to reduce data storage needs is to only record half of the 2D array by populating + array elements above or below the array diagonal. + + + + storage_mode describes the format of the data to be loaded + + We encourage the documention of other formats represented here. + + + + + + + + + + + baseline is the expected value of a full decorrelation + + The baseline is a constant value added to the functional form of the auto-correlation + function. This value is required. + + + + + + + + + time_origin_location is the location of the origin + + + + + + + + + populated_elements describe the elements of the 2D array that are populated with data + + + + + + + + + + + frame weighted average along the diagonal direction in ``two_time_corr_func`` + + The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" + + * iterable list of linked files for each ':'math':'`g_2` with 1 file per ':'math':'`q` + * 2D array with shape (':'math':'`g_2`, ':'math':'`q`) + + Note that delay_difference is not included here because it is derived from the shape of + extracted ':'math':'`g_2` because all frames are considered, which is not necessarily the case for ':'math':'`g_2`. + + The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The + following attributes will be used to manage the customization. + + + + + + + + + + + + + + + + + + first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. + + The first_point_for_fit is True ("1") or False ("0"). This value is required. + + + + + + + + + + error values for the ':'math':'`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (':'math':'`\pm` error). + + + + + + + + + + + + + subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` + + Time slicing along the diagonal can be very sophisticated. This entry currently assumes + equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. + In principle, any data format is acceptable if the data and its axes are self describing as per NeXus + recommendations. However, the data is preferred in one of the following two formats':' + + * iterable list of linked files (or keys) for each partial ':'math':'`g_2` of each q-bin represented by the roi_map value + * 3D array with shape (':'math':'`g_2`, ':'math':'`q`, nth_partial) + + Note that delay_difference is not included here because it is derived from the shape of + extracted ':'math':'`g_2`. + + + + + + + + + + + + + + + + + + error values for the ':'math':'`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (':'math':'`\pm` error). + + + + - roi index array. - - The values of this mask index the :math:`|Q|` value from the - the ``static_q_list`` field. - - The ``units`` attribute should be set to ``"au"`` - indicating arbitrary units. + XPCS instrument Metadata. + + Objects can be entered here directly or linked from other + objects in the NeXus file (such as within ``/entry/instrument``). - - + + + + Incident beam line energy (either keV or eV). + + + + + Spread of incident beam line energy (either keV or eV). This quantity is otherwise known + as the energy resolution, which is related to the longitudinal coherence length. + + + + + Terse description of the incident beam polarization. + + The value can be plain text, such as ``vertical``, ``C+``, + ``circular left``. + + + + + Size (2-D) of the beam at this position. + + + + + + XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes + this data is represented in different ways (sparse arrays or photon event list), but this detail + is left to the analysis software. Therefore, we only include requirements based on full array data. + + We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This + is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ + See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and + the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI + documentation (See Fig 11 vs Fig 12). + + Additionally, not all ':'ref':'`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to + convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may + either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. + + .. [#] Coherent X-ray Imaging Data Bank':' https':'//cxidb.org/cxi.html + + + + Detector name. + + + + + Distance between sample and detector. + + + + + Exposure time of frames, s. + + + + + Exposure period (time between frame starts) of frames, s + + + + + Position of beam center, x axis, in detector's coordinates. + + + + + Position of beam center, y axis, in detector's coordinates. + + + + + Length of pixel in x direction. + + + + + Length of pixel in y direction. + + + + + + Data masks or mappings to regions of interest (roi) for specific ':'math':'`Q` values + + Fields in this ``masks`` group describe regions of interest + in the data by either a mask to select pixels or to associate + a *map* of rois with a (one-dimensional) *list* of values. + + "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, + which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. + + "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and + NXxpcs/entry/two_time. + + "Static" refers to finer binning used for computation not strictly used for the final + XPCS results. Implementation of _static_ binning is left for individual libraries to + document. We encourage usage of ':'ref':'`NXcanSAS` to represent standard SAXS results or + development of new NeXus definitions for GI-SAXS or other reciprocal space + intensity mapping. + + + + roi index array or labeled array + + The values of this mask index (or map to) the ':'math':'`Q` value from the + the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations + are performed on all pixels with a value > 0. + + The ``units`` attribute should be set to ``"au"`` + indicating arbitrary units. + + + + + 1-D list of ':'math':'`Q` values, one for each roi index value. + + List order is determined by the index value of the associated roi map starting at ``1``. + + The only requirement for the list is that it may be iterable. Some expected formats are':' + + * iterable list of floats (i.e., ':'math':'`Q(r)`) + * iterable list of tuples (i.e., ':'math':'`Q(r)`, ':'math':'`\varphi`), but preferable use the seperate ':'math':'`\varphi` field below + * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) + * iterable list of integers (for Nth roi_map value) or strings + + This format is chosen because results plotting packages are not common and simple I/O is required by end user. + The lists can be accessed as lists, arrays or via keys + + + + + Array of ':'math':'`\varphi` value for each pixel. + + List order is determined by the index value of the associated roi map starting at ``1``. + + + + + roi index array. + + The values of this mask index the ':'math':'`|Q|` value from the + the ``static_q_list`` field. + + The ``units`` attribute should be set to ``"au"`` + indicating arbitrary units. + + + + + 1-D list of ':'math':'`|Q|` values, 1 for each roi. + + + + + + + + Sample temperature setpoint, (C or K). + + + + + Sample temperature actual, (C or K). + + + + + + + - 1-D list of :math:`|Q|` values, 1 for each roi. + Any other notes. + + NAME':' The NeXus convention, to use all upper case + to indicate the name (here ``NOTE``), is left to the file + writer. In our case, follow the suggested name + pattern and sequence':' note_1, note_2, note_3, ... + Start with ``note_1`` if the first one, otherwise + pick the next number in this sequence. - - + - - - - - - Sample temperature setpoint, (C or K). - - - + - Sample temperature actual, (C or K). + Describe the computation process that produced these results. - - - - - - - - - Any other notes. - - NAME: The NeXus convention, to use all upper case - to indicate the name (here ``NOTE``), is left to the file - writer. In our case, follow the suggested name - pattern and sequence: note_1, note_2, note_3, ... - Start with ``note_1`` if the first one, otherwise - pick the next number in this sequence. - - - - - - Describe the computation process that produced these results. - - From 23c7650b5ce79957ca37b5f7ce891220f4006551 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Mon, 24 Apr 2023 16:04:01 +0200 Subject: [PATCH 126/203] restore nxdl files whith no change in nyaml --- contributed_definitions/NXaperture.nxdl.xml | 29 +- .../NXaperture_em.nxdl.xml | 1 - .../NXapm_input_ranging.nxdl.xml | 1 - .../NXapm_input_reconstruction.nxdl.xml | 1 - contributed_definitions/NXbeam.nxdl.xml | 63 +- .../NXcalibration.nxdl.xml | 4 +- .../NXcg_alpha_complex.nxdl.xml | 31 - .../NXcg_cylinder_set.nxdl.xml | 12 - .../NXcg_ellipsoid_set.nxdl.xml | 3 - .../NXcg_face_list_data_structure.nxdl.xml | 3 - .../NXcg_geodesic_mesh.nxdl.xml | 1 - .../NXcg_hexahedron_set.nxdl.xml | 11 - .../NXcg_marching_cubes.nxdl.xml | 3 - .../NXcg_parallelogram_set.nxdl.xml | 6 - .../NXcg_polygon_set.nxdl.xml | 69 -- .../NXcg_polyhedron_set.nxdl.xml | 23 - contributed_definitions/NXcg_roi_set.nxdl.xml | 3 - .../NXcg_sphere_set.nxdl.xml | 2 - .../NXcg_tetrahedron_set.nxdl.xml | 22 - .../NXcg_triangle_set.nxdl.xml | 4 - .../NXcg_triangulated_surface_mesh.nxdl.xml | 13 - .../NXcg_unit_normal_set.nxdl.xml | 3 - .../NXcollectioncolumn.nxdl.xml | 4 +- contributed_definitions/NXcontainer.nxdl.xml | 289 ++--- .../NXcoordinate_system_set.nxdl.xml | 54 - .../NXcs_computer.nxdl.xml | 2 - contributed_definitions/NXcs_io_obj.nxdl.xml | 2 - contributed_definitions/NXcs_mm_sys.nxdl.xml | 1 - contributed_definitions/NXcs_prng.nxdl.xml | 3 - contributed_definitions/NXcsg.nxdl.xml | 105 +- contributed_definitions/NXcxi_ptycho.nxdl.xml | 383 +++--- contributed_definitions/NXdeflector.nxdl.xml | 2 +- .../NXdelocalization.nxdl.xml | 16 - contributed_definitions/NXdetector.nxdl.xml | 63 +- contributed_definitions/NXdistortion.nxdl.xml | 2 +- .../NXelectronanalyser.nxdl.xml | 8 +- .../NXelectrostatic_kicker.nxdl.xml | 120 +- .../NXellipsometry.nxdl.xml | 14 - .../NXem_ebsd_conventions.nxdl.xml | 13 - ...NXem_ebsd_crystal_structure_model.nxdl.xml | 14 - .../NXenergydispersion.nxdl.xml | 4 +- contributed_definitions/NXentry.nxdl.xml | 83 +- .../NXfabrication.nxdl.xml | 1 - contributed_definitions/NXgraph_root.nxdl.xml | 1 - .../NXimage_set_em_adf.nxdl.xml | 5 - .../NXimage_set_em_bf.nxdl.xml | 25 +- .../NXimage_set_em_bse.nxdl.xml | 25 +- .../NXimage_set_em_chamber.nxdl.xml | 25 +- .../NXimage_set_em_df.nxdl.xml | 25 +- .../NXimage_set_em_diffrac.nxdl.xml | 25 +- .../NXimage_set_em_ecci.nxdl.xml | 25 +- .../NXimage_set_em_kikuchi.nxdl.xml | 12 - .../NXimage_set_em_ronchigram.nxdl.xml | 25 +- .../NXimage_set_em_se.nxdl.xml | 31 +- contributed_definitions/NXinstrument.nxdl.xml | 31 +- .../NXinteraction_vol_em.nxdl.xml | 55 +- .../NXlab_sample_mounting.nxdl.xml | 17 +- .../NXmagnetic_kicker.nxdl.xml | 117 +- .../NXmanipulator.nxdl.xml | 4 +- contributed_definitions/NXmpes.nxdl.xml | 15 +- .../NXms_snapshot_set.nxdl.xml | 6 - contributed_definitions/NXprocess.nxdl.xml | 35 +- contributed_definitions/NXpump.nxdl.xml | 3 - contributed_definitions/NXquadric.nxdl.xml | 115 +- .../NXquadrupole_magnet.nxdl.xml | 100 +- contributed_definitions/NXregion.nxdl.xml | 344 +++--- .../NXregistration.nxdl.xml | 2 +- contributed_definitions/NXsample.nxdl.xml | 61 +- contributed_definitions/NXscanbox_em.nxdl.xml | 6 - contributed_definitions/NXseparator.nxdl.xml | 124 +- .../NXslip_system_set.nxdl.xml | 8 - contributed_definitions/NXsnsevent.nxdl.xml | 621 +++++----- contributed_definitions/NXsnshisto.nxdl.xml | 647 +++++----- .../NXsolenoid_magnet.nxdl.xml | 100 +- .../NXsolid_geometry.nxdl.xml | 53 +- contributed_definitions/NXsource.nxdl.xml | 37 +- .../NXspatial_filter.nxdl.xml | 3 - .../NXspectrum_set_em_auger.nxdl.xml | 25 +- .../NXspectrum_set_em_cathodolum.nxdl.xml | 25 +- .../NXspectrum_set_em_eels.nxdl.xml | 9 - .../NXspectrum_set_em_xray.nxdl.xml | 19 - .../NXspin_rotator.nxdl.xml | 124 +- .../NXspindispersion.nxdl.xml | 4 +- contributed_definitions/NXstage_lab.nxdl.xml | 15 - .../NXtransmission.nxdl.xml | 10 +- contributed_definitions/NXxpcs.nxdl.xml | 1100 +++++++++-------- 86 files changed, 2360 insertions(+), 3190 deletions(-) diff --git a/contributed_definitions/NXaperture.nxdl.xml b/contributed_definitions/NXaperture.nxdl.xml index 4aaf3e0b27..3e4b8dd42c 100644 --- a/contributed_definitions/NXaperture.nxdl.xml +++ b/contributed_definitions/NXaperture.nxdl.xml @@ -1,37 +1,16 @@ - + - - + A beamline aperture - Declares which child group contains a path leading to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 2f8ac254d6..1c3d7a3a0e 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -22,7 +22,6 @@ # For further information, see http://www.nexusformat.org --> - Details of an individual aperture for beams in electron microscopy. diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml index 99aba9553a..2f44bec9a8 100644 --- a/contributed_definitions/NXapm_input_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_input_ranging.nxdl.xml @@ -21,7 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - Metadata to ranging definitions made for a dataset in atom probe microscopy. diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml index db9c18895a..c6d9401be5 100644 --- a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml @@ -21,7 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. diff --git a/contributed_definitions/NXbeam.nxdl.xml b/contributed_definitions/NXbeam.nxdl.xml index f6ab5e6561..ffbe10b857 100644 --- a/contributed_definitions/NXbeam.nxdl.xml +++ b/contributed_definitions/NXbeam.nxdl.xml @@ -1,27 +1,6 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -38,13 +17,13 @@ - Properties of the neutron or X-ray beam at a given location. - - It will be referenced by beamline component groups within the ':'ref':'`NXinstrument` group or by the ':'ref':'`NXsample` group. - Note that variables such as the incident energy could be scalar values or arrays. - This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, - time distribution etc. at each beamline component. - Otherwise, its most likely use is in the ':'ref':'`NXsample` group in which it defines the results of the neutron + Properties of the neutron or X-ray beam at a given location. + + It will be referenced by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. + Note that variables such as the incident energy could be scalar values or arrays. + This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, + time distribution etc. at each beamline component. + Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron scattering by the sample, e.g., energy transfer, polarizations. @@ -58,9 +37,9 @@ Several other use cases are permitted, depending on the presence of other incident_energy_X fields. * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, + * In the case of a polychromatic beam that varies shot-to-shot, this is an array of length m with the relative weights in incident_energy_weights as a 2D array. * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. @@ -174,15 +153,15 @@ Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. Correct parsing can still be implemented by using this attribute. - | Fill with':' + | Fill with: - * The unit unidata symbol if the unit has one (Example':' 'T' for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example':' 'farad' for capacitance). + * The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: 'farad' for capacitance). * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. - Example':' for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. - Here':' SI units are 'V2/m2'. + Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. + Here: SI units are 'V2/m2'. @@ -195,7 +174,7 @@ - Here':' SI units are 'V2/m2'. + Here: SI units are 'V2/m2'. @@ -240,7 +219,7 @@ - Here':' SI units are ''J/m2'', customary ''mJ/cm2''. + Here: SI units are ''J/m2'', customary ''mJ/cm2''. @@ -293,14 +272,14 @@ - .. index':'':' plotting + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 7a1b51318b..86a0453c7e 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -24,7 +24,7 @@ - The symbols used in the schema to specify e.g. dimensions of arrays + The symbols used in the schema to specify e.g. dimensions of arrays @@ -43,7 +43,7 @@ - Subclass of NXprocess to describe post-processing calibrations. + Subclass of NXprocess to describe post-processing calibrations. diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml index ae2e431e9e..a7e2d7828c 100644 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -22,9 +22,6 @@ # For further information, see http://www.nexusformat.org --> - The symbols used in the schema to specify e.g. dimensions of arrays. @@ -34,7 +31,6 @@ convex hull of a point set.--> The dimensionality of the alpha shape, for now 2 or 3. - The number of edges. @@ -88,7 +84,6 @@ convex hull of a point set.--> Specifically when computed with the CGAL, the mode specifies if singular faces are removed (regularized) of the alpha complex. - @@ -106,24 +101,11 @@ convex hull of a point set.--> in the case of alpha_wrapping. - Point cloud for which the alpha shape or wrapping should be computed. - Triangle soup for which the alpha wrapping should be computed. @@ -134,18 +116,5 @@ of the specifically filtrated alpha complex.--> A meshed representation of the resulting shape. - - diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index 310689f198..e71adff6fd 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -21,8 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -88,10 +86,6 @@ cylinder could be constructed, but NXcylinder is easier to understand--> - @@ -123,7 +117,6 @@ one should really better use NXquadric...--> which the positions and directions are interpretable. - Interior volume of each cylinder @@ -157,9 +150,4 @@ one should really better use NXquadric...--> - diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 25c80dca79..bcc121fe9c 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -21,7 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -103,7 +102,6 @@ which the positions and directions are interpretable. - Are the ellipsoids closed or hollow? @@ -122,7 +120,6 @@ - Direction unit vector which points along the largest half-axes. diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index a62ee03374..270582a939 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -21,7 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -86,7 +85,6 @@ Dimensionality. - Array which specifies of how many vertices each face is built. @@ -213,7 +211,6 @@ - If true indicates that the vertices are all placed at different positions diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index 3817172989..2ad1e03bb8 100644 --- a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -53,5 +53,4 @@ - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index 081d7f72c6..f9ff489f56 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -21,11 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -93,7 +88,6 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - A qualitative description of each hexahedron/cuboid/cube/box. @@ -209,27 +203,22 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - - - A simple approach to describe the entire set of hexahedra when the main intention is to store the shape of the hexahedra for visualization. - Disentangled representations of the mesh of specific hexahedra. - Disentangled representation of the planar graph that each hexahedron represents. Such a description simplifies topological processing diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index 270d67537d..25a58d5b53 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -68,7 +68,4 @@ - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index 7454bb625e..2486ad7ad8 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -79,7 +79,6 @@ - A qualitative description of each parallelogram/rectangle/square/box. @@ -160,24 +159,19 @@ - - - A simple approach to describe the entire set of parallelograms when the main intention is to store the shape of the parallelograms for visualization. - Disentangled representations of the mesh of specific parallelograms. - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2aa9ec3709..efa99c5d1c 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -22,9 +22,6 @@ # For further information, see http://www.nexusformat.org --> - The symbols used in the schema to specify e.g. dimensions of arrays. @@ -39,14 +36,12 @@ descriptors.--> The cardinality of the set, i.e. the number of polygons. - The total number of vertices when visiting every polygon. - Computational geometry description of a set of polygons in Euclidean space. @@ -100,18 +95,14 @@ descriptors.--> - A simple approach to describe the entire set of polygons when the main intention is to store the shape of the polygons for visualization. - - @@ -162,64 +153,4 @@ properties of the polygon primitives--> Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 3faa043d93..5525812aa7 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -21,15 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -70,7 +61,6 @@ for clean graph-based descriptions of polyhedra.--> - Interior volume @@ -136,7 +126,6 @@ for clean graph-based descriptions of polyhedra.--> which the qualifiers and mesh data are interpretable. - Integer which specifies the first index to be used for distinguishing @@ -161,34 +150,22 @@ for clean graph-based descriptions of polyhedra.--> - - A simple approach to describe the entire set of polyhedra when the main intention is to store the shape of the polyhedra for visualization. - Disentangled representations of the mesh of specific polyhedron. - Disentangled representation of the planar graph that each polyhedron represents. Such a description simplifies topological processing or analyses of mesh primitive operations and neighborhood queries. - diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml index aafda71ad4..96b299aa8d 100644 --- a/contributed_definitions/NXcg_roi_set.nxdl.xml +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -21,7 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -35,6 +34,4 @@ - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index bbc8459363..80f53d17e4 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -21,7 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -99,7 +98,6 @@ which the positions and directions are interpretable. - Are the spheres closed or hollow? diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 2f7185551e..4cae3e4229 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -21,11 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -62,7 +57,6 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Interior volume @@ -113,18 +107,6 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> which the qualifiers and mesh data are interpretable. - Integer which specifies the first index to be used for distinguishing @@ -149,9 +131,7 @@ interior_angle(NX_NUMBER): - - A simple approach to describe the entire set of tetrahedra when the main intention is to store the shape of the tetrahedra for visualization. @@ -159,13 +139,11 @@ interior_angle(NX_NUMBER): - Disentangled representations of the mesh of specific tetrahedra. - Disentangled representation of the planar graph that each tetrahedron represents. Such a description simplifies topological processing diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 78e16c7512..8bf4467570 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -76,18 +76,14 @@ - A simple approach to describe the entire set of triangles when the main intention is to store the shape of the triangles for visualization. - - diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index a83c63553f..06210e334b 100644 --- a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -33,19 +33,6 @@ The mesh may be self-intersecting and have holes but the triangles must not be degenerated. - diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index a6f606a7cb..cf2213b4ac 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -21,9 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 7a96016053..c8bd717074 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -23,8 +23,8 @@ --> - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Subclass of NXelectronanalyser to describe the electron collection + column of a photoelectron analyser. diff --git a/contributed_definitions/NXcontainer.nxdl.xml b/contributed_definitions/NXcontainer.nxdl.xml index ec050b4628..c32854f305 100644 --- a/contributed_definitions/NXcontainer.nxdl.xml +++ b/contributed_definitions/NXcontainer.nxdl.xml @@ -1,14 +1,14 @@ - + - - - State of a container holding the sample under investigation. - - A container is any object in the beam path which absorbs the beam and - whose contribution to the overall attenuation/scattering needs to be - determined to process the experimental data. Examples of containers - include glass capillary tubes, vanadium cans, windows in furnaces or - diamonds in a Diamond Anvil Cell. The following figures show a complex - example of a container':' - - .. figure':'':' container/ComplexExampleContainer.png - - A hypothetical capillary furnace. The beam passes from left to right - (blue dashes), passing through window 1, then window 2, before - passing through the downstream wall of the capillary. It is then - scattered by the sample with scattered beams passing through the - upstream wall of the capillary, then windows 4 and 5. As part of the - corrections for a PDF experiment it is necessary to subtract the PDF - of the empty container (i.e. each of the windows and the capillary). - To calculate the PDF of the empty container it is necessary to have - the measured scattering data and to know the nature (e.g. density, - elemental composition, etc.) of the portion of the container which - the beam passed through. - - .. figure':'':' container/ComplexContainerBeampath.png - - A complete description of the shapes of the container elements with - their orientation relative to the beam and also information on - whether they are upstream or downstream of the sample is also - therefore important. For example, although the windows 2 and 4 have - the same shape, the path taken through them by the beam is very - different and this needs to be modelled. Furthermore, it is not - inconceivable that windows might move during an experiment and thus - the changes to the beampath would need to be accounted for. - - This class encodes the position of the container with respect to the - sample and allows the calculation of the beampath through the container. - It also includes sufficient data to model beam absorption of the - container and a link to a dataset containing a measurement of the - container with nothing inside, to allow data corrections (at a specific - beam energy/measurement time) to be made. - - - - Descriptive name of container. - - - - - Verbose description of container and how it fits into the wider - experimental set up. - - - - - Chemical composition of the material the container is made from. - Specified using CIF conventions. Abbreviated version of CIF - standard':' - - * 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. - - * This is the *Hill* system used by Chemical Abstracts. - - - - - Density of the material the container is made from. - - - - - - - - Fraction of the volume of the container occupied by the material - forming the container. - - - - - - - - Relative molecular mass of container. - - - - - - - - Details of beam incident on container, including the position - relative to the sample (to determine whether the container is - upstream or downstream of the sample). - - - - - Shape of the container. In combination with orientation this - should allow the beampath through the container to be modelled to - allow the adsorption to be calculated. - - - - - The angle the container makes to the beam and how it may change - during the experiment.In combination with shape this should allow - the beampath through the container to be modelled to allow the - adsorption of the container to be calculated. - - - - - A link to a full data collection which contains the actual - measured data for this container within the experimental set up - (with no sample or inner container(s)). This data set will also - include the wavelength/energy, measurement time and intensity for - which these data are valid. - - + + + + State of a container holding the sample under investigation. + + A container is any object in the beam path which absorbs the beam and + whose contribution to the overall attenuation/scattering needs to be + determined to process the experimental data. Examples of containers + include glass capillary tubes, vanadium cans, windows in furnaces or + diamonds in a Diamond Anvil Cell. The following figures show a complex + example of a container: + + .. figure:: container/ComplexExampleContainer.png + + A hypothetical capillary furnace. The beam passes from left to right + (blue dashes), passing through window 1, then window 2, before + passing through the downstream wall of the capillary. It is then + scattered by the sample with scattered beams passing through the + upstream wall of the capillary, then windows 4 and 5. As part of the + corrections for a PDF experiment it is necessary to subtract the PDF + of the empty container (i.e. each of the windows and the capillary). + To calculate the PDF of the empty container it is necessary to have + the measured scattering data and to know the nature (e.g. density, + elemental composition, etc.) of the portion of the container which + the beam passed through. + + .. figure:: container/ComplexContainerBeampath.png + + A complete description of the shapes of the container elements with + their orientation relative to the beam and also information on + whether they are upstream or downstream of the sample is also + therefore important. For example, although the windows 2 and 4 have + the same shape, the path taken through them by the beam is very + different and this needs to be modelled. Furthermore, it is not + inconceivable that windows might move during an experiment and thus + the changes to the beampath would need to be accounted for. + + This class encodes the position of the container with respect to the + sample and allows the calculation of the beampath through the container. + It also includes sufficient data to model beam absorption of the + container and a link to a dataset containing a measurement of the + container with nothing inside, to allow data corrections (at a specific + beam energy/measurement time) to be made. + + + + Descriptive name of container. + + + + + Verbose description of container and how it fits into the wider + experimental set up. + + + + + Chemical composition of the material the container is made from. + Specified using CIF conventions. Abbreviated version of CIF + standard: + + * 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. + + * This is the *Hill* system used by Chemical Abstracts. + + + + + Density of the material the container is made from. + + + + + + + + Fraction of the volume of the container occupied by the material + forming the container. + + + + + + + Relative molecular mass of container. + + + + + + + Details of beam incident on container, including the position + relative to the sample (to determine whether the container is + upstream or downstream of the sample). + + + + + Shape of the container. In combination with orientation this + should allow the beampath through the container to be modelled to + allow the adsorption to be calculated. + + + + + The angle the container makes to the beam and how it may change + during the experiment.In combination with shape this should allow + the beampath through the container to be modelled to allow the + adsorption of the container to be calculated. + + + + + A link to a full data collection which contains the actual + measured data for this container within the experimental set up + (with no sample or inner container(s)). This data set will also + include the wavelength/energy, measurement time and intensity for + which these data are valid. + + + diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index ed06270f23..17fc4368f6 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -57,10 +57,6 @@ 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: @@ -84,54 +80,4 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d according to the descriptions in NXtransformations. - - - - diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index 5d794aaf06..be45aa4453 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -49,14 +49,12 @@ - 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). diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index 7995308a7d..aa1b2bd32f 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -40,13 +40,11 @@ - Total amount of data which the medium can hold. - Given name to the I/O unit. diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index eb2e574771..fc25da0a1a 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -35,5 +35,4 @@ How much physical memory does the system provide. - diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml index d540b09cf8..99bbcec883 100644 --- a/contributed_definitions/NXcs_prng.nxdl.xml +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -71,7 +71,6 @@ sequence of numbers it generates. - Number of initial draws from the PRNG which are discarded in an effort @@ -80,6 +79,4 @@ users should set the value to zero. - diff --git a/contributed_definitions/NXcsg.nxdl.xml b/contributed_definitions/NXcsg.nxdl.xml index b7183349cc..b095387486 100644 --- a/contributed_definitions/NXcsg.nxdl.xml +++ b/contributed_definitions/NXcsg.nxdl.xml @@ -1,14 +1,14 @@ - + - + + + Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` + - Constructive Solid Geometry base class, using ':'ref':'`NXquadric` and ':'ref':'`NXoff_geometry` + One of the standard construction solid geometry set operations, + or if the CSG is a pointer to the geometry provided by an + :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: - - - One of the standard construction solid geometry set operations, - or if the CSG is a pointer to the geometry provided by an - ':'ref':'`NXquadric` or an ':'ref':'`NXoff_geometry`. Takes values':' - - - - - - - - - - - - - The first operand of constructive solid geometry - operation. Compulsory if 'operation' is UNION, INTERSECTION, - DIFFERENCE or COMPLEMENT. - - - - - The second operand of constructive solid geometry - operation. Compulsory if 'operation' is UNION, INTERSECTION or - DIFFERENCE. - - - - - Path to a field that is either an ':'ref':'`NXquadric` (if - 'operation' = IS_QUADRIC) or an ':'ref':'`NXoff_geometry` (if - 'operation' = IS_MESH) that defines the surface making up the - constructive solid geometry component. Compulsory if 'operation' - is IS_QUADRIC or IS_MESH. - - + + + + + + + + + + + + The first operand of constructive solid geometry + operation. Compulsory if 'operation' is UNION, INTERSECTION, + DIFFERENCE or COMPLEMENT. + + + + + The second operand of constructive solid geometry + operation. Compulsory if 'operation' is UNION, INTERSECTION or + DIFFERENCE. + + + + + Path to a field that is either an :ref:`NXquadric` (if + 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if + 'operation' = IS_MESH) that defines the surface making up the + constructive solid geometry component. Compulsory if 'operation' + is IS_QUADRIC or IS_MESH. + + diff --git a/contributed_definitions/NXcxi_ptycho.nxdl.xml b/contributed_definitions/NXcxi_ptycho.nxdl.xml index 4760a2c66b..e0f9c0efcc 100644 --- a/contributed_definitions/NXcxi_ptycho.nxdl.xml +++ b/contributed_definitions/NXcxi_ptycho.nxdl.xml @@ -1,217 +1,232 @@ - - - + - These symbols will be used below to coordinate the shapes of the - datasets. + These symbols will be used below to coordinate the shapes of the datasets. + - - The number of points in the x direction + + The number of points in the x direction + - - Number of points in the y direction. + + Number of points in the y direction. - - Number of detector pixels in x + + Number of detector pixels in x + - - Number of detector pixels in y + + Number of detector pixels in y + - Application definition for a ptychography experiment, compatible with CXI from version 1.6. - - This is compatible with CXI from version 1.6 if this application definition - is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important - to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, - with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. - - An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths - with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). + Application definition for a ptychography experiment, compatible with CXI from version 1.6. + + This is compatible with CXI from version 1.6 if this application definition + is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important + to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, + with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. + + An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths + with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). + - - - - - - Official NeXus NXDL schema to which this file conforms + + + + + + Official NeXus NXDL schema to which this file conforms - - - + + + + - - - - - - This is the energy of the machine, not the beamline. - - - - - - - - - - - - - - - - - - - - - - - - - - should have value "[, data]" - - - - - should have value "data" - - - - - - - - This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y - - - - - this should take the value "translation':'$slowaxisname':'$fastaxisname" - - - - - This should be "image" - - - - - - - - - - - - - - This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless - of the scan pattern. Use hdf5 virtual dataset to achieve this. - - - - - + + + + + + This is the energy of the machine, not the beamline. + + + + + + + + + + + + + + + + + + + + + + + + + + should have value "[, data]" + + + + + should have value "data" + + + + + + + + This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y + + + + + this should take the value "translation:$slowaxisname:$fastaxisname" + + + + + This should be "image" + + + + + + + + + + + + + + This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless + of the scan pattern. Use hdf5 virtual dataset to achieve this. + + + + + - + - - - The distance between the detector and the sample + + + The distance between the detector and the sample - + - + - + - - - - - - - - - - - - - - - This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster - - - - - This should be "data" - - - - - - - - - - - To ensure CXI compatibility the data in this group must always have shape that is - (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that - hdf5 virtual dataset is used. - - - - - - - - - This must contain two fields with the x and y motors that are linked via the - dependency tree according to the real-life motor layout dependency. - For raster scans x and y will have shape (npts_x, npts_y) - For arbitrary scans x and y will be (npts_x*npts_y,) - An attribute with the units for each motor is required. - - - - - + + + + + + + + + + - + + + + This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster + + + + + This should be "data" + + + + + + + + + + + To ensure CXI compatibility the data in this group must always have shape that is + (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that + hdf5 virtual dataset is used. + + + + + + + + + + This must contain two fields with the x and y motors that are linked via the + dependency tree according to the real-life motor layout dependency. + For raster scans x and y will have shape (npts_x, npts_y) + For arbitrary scans x and y will be (npts_x*npts_y,) + An attribute with the units for each motor is required. + + + + + + + + + diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml index 33d751cded..f362abb3fd 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -23,7 +23,7 @@ --> - Deflectors as they are used e.g. in an electron analyser. + Deflectors as they are used e.g. in an electron analyser. diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 8dceaaec0f..7487e80c86 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -65,17 +65,6 @@ Reference or link to the points which are delocalized on the grid. - The weighting model specifies how mark data are mapped to a weight per point. @@ -98,11 +87,6 @@ and the interpretation model that to consider carbon atoms or carbon ions--> - A list of elements (via proton number) to consider for the atomic_decomposition diff --git a/contributed_definitions/NXdetector.nxdl.xml b/contributed_definitions/NXdetector.nxdl.xml index 0130540c84..d5df7c8c66 100644 --- a/contributed_definitions/NXdetector.nxdl.xml +++ b/contributed_definitions/NXdetector.nxdl.xml @@ -1,27 +1,6 @@ - + - - + These symbols will be used below to coordinate datasets with the same @@ -198,7 +177,7 @@ This is the distance to the previous component in the instrument; most often the - sample. The usage depends on the nature of the detector':' Most often it is the + sample. The usage depends on the nature of the detector: Most often it is the distance of the detector assembly. But there are irregular detectors. In this case the distance must be specified for each detector pixel. @@ -390,7 +369,7 @@ - This field can be two things':' + This field can be two things: #. For a pixel detector it provides the nominal wavelength for which the detector has been calibrated. @@ -402,8 +381,6 @@ In this use case, the efficiency and wavelength arrays must have the same dimensionality. - - @@ -585,21 +562,21 @@ Contains a bit field for each pixel to signal dead, blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning':' + They have the following meaning: .. can't make a table here, a bullet list will have to do for now - * bit 0':' gap (pixel with no sensor) - * bit 1':' dead - * bit 2':' under responding - * bit 3':' over responding - * bit 4':' noisy - * bit 5':' -undefined- - * bit 6':' pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7':' -undefined- - * bit 8':' user defined mask (e.g. around beamstop) - * bits 9-30':' -undefined- - * bit 31':' virtual pixel (corner pixel with interpolated value) + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) Normal data analysis software would not take pixels into account @@ -760,14 +737,14 @@ - .. index':'':' plotting + .. index:: plotting - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml index 7431919c68..b47f0aa734 100644 --- a/contributed_definitions/NXdistortion.nxdl.xml +++ b/contributed_definitions/NXdistortion.nxdl.xml @@ -43,7 +43,7 @@ - Subclass of NXprocess to describe post-processing distortion correction. + Subclass of NXprocess to describe post-processing distortion correction. diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 968347b380..0ef6f51315 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -28,18 +28,18 @@ - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) + Number of fast axes (axes acquired symultaneously, without scanning + a physical quantity) - Number of slow axes (axes acquired scanning a pysical quantity) + Number of slow axes (axes acquired scanning a physical quantity) - Subclass of NXinstrument to describe a photoelectron analyser. + Subclass of NXinstrument to describe a photoelectron analyser. diff --git a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml index 3426e227c3..552eb562a6 100644 --- a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml +++ b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml @@ -1,66 +1,60 @@ - - - - - definition for a electrostatic kicker. - - - - extended description of the kicker. - - - - - define position of beamline element relative to production target - - - - - kicker timing as defined by ``description`` attribute - - - - - - current set on supply. - - - - - current read from supply. - - - - - - volage set on supply. - - - - - voltage read from supply. - - - + +definition for a electrostatic kicker. + +extended description of the kicker. + + +define position of beamline element relative to production target + + +kicker timing as defined by ``description`` attribute + + + +current set on supply. + + +current read from supply. + + + +volage set on supply. + + +voltage read from supply. + + diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 03378baf79..197b3f7d2e 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -21,12 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - - @@ -263,14 +257,6 @@ A draft version of a NeXus application definition for ellipsometry.--> Specify the used light source. Multiple selection possible. - - Were focussing probes (lenses) used? diff --git a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml index c471943e94..5a46756065 100644 --- a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml @@ -22,7 +22,6 @@ # For further information, see http://www.nexusformat.org --> - Conventions for rotations and coordinate systems to interpret EBSD data. @@ -32,8 +31,6 @@ and the use of file formats which do not store this information is the key unsolved problem. - Mathematical conventions and materials-science-specific conventions @@ -597,14 +594,4 @@ assumed reference frame and rotation conventions--> - diff --git a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml index 8df153844e..1205dd6c0c 100644 --- a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml @@ -50,9 +50,6 @@ used algorithm. More and more dictionary based alternatives are used. Either way both algorithm need a crystal structure model. - Identifier of an entry from crystallographic_database which was used @@ -65,7 +62,6 @@ positions--> crystallographic_database_identifier e.g. COD or others. - Crystallography unit cell parameters a, b, and c. @@ -74,7 +70,6 @@ positions--> - Crystallography unit cell parameters alpha, beta, and gamma. @@ -93,7 +88,6 @@ positions--> Crystallographic space group - True if space group is considered a centrosymmetric one. @@ -115,13 +109,11 @@ positions--> Laue group - Point group using International Notation. - Crystal system @@ -177,8 +169,6 @@ positions--> - Relative occupancy of the atom position. @@ -192,7 +182,6 @@ to describe the simulated Kikuchi pattern generated from such a model--> How many reflectors are distinguished. Value has to be n_hkl. - Miller indices :math:`(hkl)`. @@ -218,7 +207,4 @@ to describe the simulated Kikuchi pattern generated from such a model--> - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index a6d5f22d40..d408627e24 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -23,8 +23,8 @@ --> - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. + Subclass of NXelectronanalyser to describe the energy dispersion + section of a photoelectron analyser. diff --git a/contributed_definitions/NXentry.nxdl.xml b/contributed_definitions/NXentry.nxdl.xml index 3d585c1fc6..b062a10d3d 100644 --- a/contributed_definitions/NXentry.nxdl.xml +++ b/contributed_definitions/NXentry.nxdl.xml @@ -1,79 +1,58 @@ - + - - + - (**required**) ':'ref':'`NXentry` describes the measurement. + (**required**) :ref:`NXentry` describes the measurement. The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. + information that comprise a single measurement. It is mandatory that there is at least one group of this type in the NeXus file. - .. index':'':' plotting + .. index:: plotting - Declares which ':'ref':'`NXdata` (or ':'ref':'`NXsubentry`) group + Declares which :ref:`NXdata` (or :ref:`NXsubentry`) group contains the data to be shown by default. - It is needed to resolve ambiguity when more than one ':'ref':'`NXdata` group exists. - The value is the name of the default ':'ref':'`NXdata` group. + It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. + The value is the name of the default :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. - .. [#] NIAC2014 discussion summary':' - https':'//www.nexusformat.org/2014_How_to_find_default_data.html + .. [#] NIAC2014 discussion summary: + https://www.nexusformat.org/2014_How_to_find_default_data.html The data group - .. note':'':' Before the NIAC2016 meeting [#]_, at least one - ':'ref':'`NXdata` group was required in each ':'ref':'`NXentry` group. - At the NIAC2016 meeting, it was decided to make ':'ref':'`NXdata` - an optional group in ':'ref':'`NXentry` groups for data files that + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when defining the default plot is not practical or possible from the available data. - For example, neutron event data may not have anything that + For example, neutron event data may not have anything that makes a useful plot without extensive processing. Certain application definitions override this decision and - require an ':'ref':'`NXdata` group - in the ':'ref':'`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - ':'ref':'`NXdata` group + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group is optional, otherwise, it is required. - .. [#] NIAC2016':' - https':'//www.nexusformat.org/NIAC2016.html, - https':'//github.com/nexusformat/NIAC/issues/16 + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 @@ -130,19 +109,19 @@ Reserved for future use by NIAC. See - https':'//github.com/nexusformat/definitions/issues/382 + https://github.com/nexusformat/definitions/issues/382 - (alternate use':' see same field in ':'ref':'`NXsubentry` for preferred) + (alternate use: see same field in :ref:`NXsubentry` for preferred) Official NeXus NXDL schema to which this entry conforms. - This field is provided so that ':'ref':'`NXentry` can be the overlay position + This field is provided so that :ref:`NXentry` can be the overlay position in a NeXus data file for an application definition and its - set of groups, fields, and attributes. + set of groups, fields, and attributes. - *It is advised* to use ':'ref':'`NXsubentry`, instead, as the overlay position. + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. @@ -222,7 +201,7 @@ This is the flightpath before the sample position. This can be determined by a - chopper, by the moderator or the source itself. In other words':' it the distance + chopper, by the moderator or the source itself. In other words: it the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index dd4c68f59a..160cc82aa8 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -47,5 +47,4 @@ functionalities which the component offers. - diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index 890838bcc8..1ed723f89a 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -32,5 +32,4 @@ - diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index 2782a391e8..56edf87880 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -98,11 +98,6 @@ Annular dark field image stack. - Image intensity values. diff --git a/contributed_definitions/NXimage_set_em_bf.nxdl.xml b/contributed_definitions/NXimage_set_em_bf.nxdl.xml index ee5c35dbf4..066b2b3e46 100644 --- a/contributed_definitions/NXimage_set_em_bf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_bf.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Container for reporting a set of images taken in bright field mode. diff --git a/contributed_definitions/NXimage_set_em_bse.nxdl.xml b/contributed_definitions/NXimage_set_em_bse.nxdl.xml index b90cebf37e..6c99db5649 100644 --- a/contributed_definitions/NXimage_set_em_bse.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_bse.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Container for reporting a set of back-scattered electron images. diff --git a/contributed_definitions/NXimage_set_em_chamber.nxdl.xml b/contributed_definitions/NXimage_set_em_chamber.nxdl.xml index 958664d27c..09973347dc 100644 --- a/contributed_definitions/NXimage_set_em_chamber.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_chamber.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Container for images recorded with e.g. a TV camera in the microscope chamber. diff --git a/contributed_definitions/NXimage_set_em_df.nxdl.xml b/contributed_definitions/NXimage_set_em_df.nxdl.xml index 288a3b63c1..f9c37cab96 100644 --- a/contributed_definitions/NXimage_set_em_df.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_df.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Container for reporting a set of images taken in dark field mode. diff --git a/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml b/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml index f47e0a3b0b..7065a8a981 100644 --- a/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Container for reporting a set of diffraction images. diff --git a/contributed_definitions/NXimage_set_em_ecci.nxdl.xml b/contributed_definitions/NXimage_set_em_ecci.nxdl.xml index 949d708472..820ec8869f 100644 --- a/contributed_definitions/NXimage_set_em_ecci.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_ecci.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Container for reporting back-scattered electron channeling contrast images. diff --git a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml index ee89aa5162..8d052150de 100644 --- a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml @@ -92,7 +92,6 @@ the spatial arrangement of the features, their individual properties, and (macroscopic) properties of materials. - Details how Kikuchi pattern were processed from the detector readings. @@ -145,20 +144,12 @@ - Kikuchi pattern intensity - Pattern are enumerated starting from 0 to n_p - 1. @@ -199,7 +190,4 @@ while for _indices fastest to fast--> - diff --git a/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml b/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml index d83a9f3647..8ab388cf25 100644 --- a/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Container for reporting a set of images related to a ronchigram. diff --git a/contributed_definitions/NXimage_set_em_se.nxdl.xml b/contributed_definitions/NXimage_set_em_se.nxdl.xml index a86f9398dc..a5ab12200b 100644 --- a/contributed_definitions/NXimage_set_em_se.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_se.nxdl.xml @@ -1,27 +1,6 @@ - + - - + @@ -96,9 +75,9 @@ - Physical dimensions of the region-of-interest on + Physical dimensions of the region-of-interest on the specimen surface which the image covers. - The first and second number are the coordinates for the + The first and second number are the coordinates for the minimum edge, the third and fourth number are the coordinates for the maximum edge of the rectangular ROI. @@ -123,7 +102,7 @@ a specific kinetic energy. - + Container to store relevant settings affecting beam path, magnification, and working_distance diff --git a/contributed_definitions/NXinstrument.nxdl.xml b/contributed_definitions/NXinstrument.nxdl.xml index dedadac67c..bec81c7a30 100644 --- a/contributed_definitions/NXinstrument.nxdl.xml +++ b/contributed_definitions/NXinstrument.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Collection of the components of the instrument or beamline. Template of instrument descriptions comprising various beamline components. Each component @@ -95,9 +74,9 @@ - .. index':'':' plotting - Declares which child group contains a path leading to a ':'ref':'`NXdata` group. - It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + .. index:: plotting + Declares which child group contains a path leading to a :ref:`NXdata` group. + It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml index f16afbc2c2..a6beeb6482 100644 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Base class for storing details about a modelled shape of interaction volume. @@ -34,24 +13,24 @@ Explicit or implicit descriptions are possible. - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy Further details on how the interaction volume can be quantified - is available in the literature for example':' + is available in the literature for example: - * `S. Richter et al. <https':'//doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https':'//doi.org/10.1017/S1431927622000083>`_ + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml index 5ed5c175a1..a60bf2ca4d 100644 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -31,7 +31,6 @@ Embedding of a sample in a medium for easing processability. - Version specifier of this application definition. @@ -49,7 +48,6 @@ - @@ -66,7 +64,7 @@ - Type of material. + Type of material. @@ -75,19 +73,8 @@ - Electrical conductivity of the embedding medium. + Electrical conductivity of the embedding medium. - diff --git a/contributed_definitions/NXmagnetic_kicker.nxdl.xml b/contributed_definitions/NXmagnetic_kicker.nxdl.xml index 6776755866..78543de83f 100644 --- a/contributed_definitions/NXmagnetic_kicker.nxdl.xml +++ b/contributed_definitions/NXmagnetic_kicker.nxdl.xml @@ -1,66 +1,57 @@ - - - - - definition for a magnetic kicker. - - - - extended description of the kicker. - - - - - define position of beamline element relative to production target - - - - - kicker timing as defined by ``description`` attribute - - - - - - current set on supply. - - - - - current read from supply. - - - - - - voltage set on supply. - - - - - voltage read from supply. - - - + + definition for a magnetic kicker. + + extended description of the kicker. + + + define position of beamline element relative to production target + + + kicker timing as defined by ``description`` attribute + + + + current set on supply. + + + current read from supply. + + + + voltage set on supply. + + + voltage read from supply. + + diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index 26b5071c4a..ef2d40ad81 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -23,8 +23,8 @@ --> - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. + Extension of NXpositioner to include fields to describe the use of + manipulators in photoemission experiments. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 72e222bb07..ff13c5e93d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -22,13 +22,9 @@ # For further information, see http://www.nexusformat.org --> - - This is the most general application definition for multidimensional - photoelectron spectroscopy. + This is the most general application definition for multidimensional + photoelectron spectroscopy. @@ -196,7 +192,6 @@ with higher granularity in the data description.--> - Description of the detector type. @@ -328,11 +323,6 @@ with higher granularity in the data description.--> other metadata file. In the case these are not available, free-text description. - In the case of a fixed temperature measurement this is the scalar temperature of @@ -349,7 +339,6 @@ It seems quite contorted to ask to create a separate timestamp array when we hav - diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml index 040607189c..1f68d4dc86 100644 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -52,11 +52,5 @@ or from 0 (referred to as C-, Python-style index notation) respectively. - - diff --git a/contributed_definitions/NXprocess.nxdl.xml b/contributed_definitions/NXprocess.nxdl.xml index 33b0458a8d..5b12ff4776 100644 --- a/contributed_definitions/NXprocess.nxdl.xml +++ b/contributed_definitions/NXprocess.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Document an event of data processing, reconstruction, or analysis for this data. @@ -71,14 +50,14 @@ - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + .. 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index 902a820d85..b536259d6b 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -37,7 +37,4 @@ - diff --git a/contributed_definitions/NXquadric.nxdl.xml b/contributed_definitions/NXquadric.nxdl.xml index e656577810..8f061f3af0 100644 --- a/contributed_definitions/NXquadric.nxdl.xml +++ b/contributed_definitions/NXquadric.nxdl.xml @@ -1,14 +1,14 @@ - + - + + definition of a quadric surface. + - definition of a quadric surface. + Ten real values of the matrix that defines the quadric surface + in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, + P2, P3, R. Takes a units attribute of dimension reciprocal + length. R is scalar. P has dimension reciprocal length, and the + given units. Q has dimension reciprocal length squared, and + units the square of those given. - - - Ten real values of the matrix that defines the quadric surface - in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, - P2, P3, R. Takes a units attribute of dimension reciprocal - length. R is scalar. P has dimension reciprocal length, and the - given units. Q has dimension reciprocal length squared, and - units the square of those given. - - - - - - - - An optional description of the form of the quadric surface':' - - - - - - - - - - - - - - - - - - - - - - - - - - Path to an ':'ref':'`NXtransformations` that defining the axis on - which the orientation of the surface depends. - - + + + + + + + An optional description of the form of the quadric surface: + + + + + + + + + + + + + + + + + + + + + + + + + + Path to an :ref:`NXtransformations` that defining the axis on + which the orientation of the surface depends. + + diff --git a/contributed_definitions/NXquadrupole_magnet.nxdl.xml b/contributed_definitions/NXquadrupole_magnet.nxdl.xml index 2e6306501f..14b97b75eb 100644 --- a/contributed_definitions/NXquadrupole_magnet.nxdl.xml +++ b/contributed_definitions/NXquadrupole_magnet.nxdl.xml @@ -1,55 +1,51 @@ - - - - - definition for a quadrupole magnet. - - - - extended description of the magnet. - - - - - define position of beamline element relative to production target - - - - - current set on supply. - - - - - current read from supply. - - - - - - voltage read from supply. - - - + + definition for a quadrupole magnet. + +extended description of the magnet. + + +define position of beamline element relative to production target + + +current set on supply. + + +current read from supply. + + + +voltage read from supply. + + diff --git a/contributed_definitions/NXregion.nxdl.xml b/contributed_definitions/NXregion.nxdl.xml index 0d41d0c091..bffff2da59 100644 --- a/contributed_definitions/NXregion.nxdl.xml +++ b/contributed_definitions/NXregion.nxdl.xml @@ -1,14 +1,14 @@ - + - - - - These symbols will denote how the shape of the parent group's data - field, .. math':'':' (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., - d_{\mathbf{R}-1}) could be split into a left set of **O** outer - dimensions, ':'math':'`\boldsymbol{D}`, and a right set of **R** - region dimensions, ':'math':'`\boldsymbol{d}`, where the data field - has rank **O** + **R**. Note **O** ':'math':'`>= 0`. - - - - Outer rank - - - - - Region rank - - - - - Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, ':'ref':'`NXdetector`. - - This can be used to describe a subset of data used to create downsampled data or to derive - some data from that subset. - - Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters - (see https':'//portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** ':'math':'`= 1`, - then **stride** ':'math':'`\equiv` **step** in Python slicing. - - For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data':'':' - - detector':'NXdetector/ - data[60,256,512] - region':'NXregion/ - @region_type = "rectangular" - parent = "data" - start = [20,50] - count = [220,120] - statistics':'NXdata/ - @signal = "sum" - sum[60] - - the ``sum`` dataset contains the summed areas in each frame. - Another example, a hyperspectral image downsampled 16-fold in energy':'':' - - detector':'NXdetector/ - data[128,128,4096] - region':'NXregion/ - @region_type = "rectangular" - parent = "data" - start = [2] - count = [20] - stride = [32] - block = [16] - downsampled':'NXdata/ - @signal = "maximum" - @auxiliary_signals = "copy" - maximum[128,128,20] - copy[128,128,320] - - the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, - the ``maximum`` dataset will show maximum values in each 16-channel block - in every spectra. - - - - This is ``rectangular`` to describe the region as a hyper-rectangle in - the index space of its parent group's data field. - - - - - - - - The name of data field in the parent group or the path of a data field relative - to the parent group (so it could be a field in a subgroup of the parent group) - - - - - The name of an optional mask field in the parent group with rank ':'math':'`\boldsymbol{R}` and - dimensions ':'math':'`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an - ':'ref':'`NXdetector`. - - - - - The starting position for region in detector data field array. - This is recommended as it also defines the region rank. - If omitted then defined as an array of zeros. - - - - - - - - The number of blocks or items in the hyperslab selection. - If omitted then defined as an array of dimensions that take into account - the other hyperslab selection fields to span the parent data field's shape. - - - - - - - - An optional field to define striding used to downsample data. - If omitted then defined as an array of ones. - - - - - - - - An optional field to define the block size used to copy or downsample data. In the - ':'math':'`i`-th dimension, if ':'math':'`\mathbf{block}[i] < \mathbf{stride}[i]` - then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` - then the blocks are contiguous; otherwise the blocks overlap. - If omitted then defined as an array of ones. - - - - - - - - An optional field to define a divisor for scaling of reduced data. For example, in a - downsampled sum, it can reduce the maximum values to fit in the domain of the result - data type. In an image that is downsampled by summing 2x2 blocks, using - ':'math':'`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as - the parent dataset. - If omitted then no scaling occurs. - - - - - - - - An optional group containing data copied/downsampled from parent group’s data. Its dataset name - must reflect how the downsampling is done over each block. So it could be a reduction operation - such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each - block then use "copy" as the name. Where more than one downsample dataset is written - (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, - the field should have a shape of ':'math':'`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, - otherwise the expected shape is ':'math':'`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. - - The following figure shows how blocks are used in downsampling':' - - .. figure':'':' region/NXregion-example.png - ':'width':' 60% - - A selection with ':'math':'`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from - a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. - - - - - An optional group containing any statistics derived from the region in parent group’s data - such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one - statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` - listing the others. All data fields should have shapes of ':'math':'`\boldsymbol{D}`. - - + + + + These symbols will denote how the shape of the parent group's data field, + + .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) + + could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, + and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, + where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. + + Outer rank + Region rank + + + Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. + + This can be used to describe a subset of data used to create downsampled data or to derive + some data from that subset. + + Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters + (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, + then **stride** :math:`\equiv` **step** in Python slicing. + + For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: + + detector:NXdetector/ + data[60,256,512] + region:NXregion/ + @region_type = "rectangular" + parent = "data" + start = [20,50] + count = [220,120] + statistics:NXdata/ + @signal = "sum" + sum[60] + + the ``sum`` dataset contains the summed areas in each frame. + Another example, a hyperspectral image downsampled 16-fold in energy:: + + detector:NXdetector/ + data[128,128,4096] + region:NXregion/ + @region_type = "rectangular" + parent = "data" + start = [2] + count = [20] + stride = [32] + block = [16] + downsampled:NXdata/ + @signal = "maximum" + @auxiliary_signals = "copy" + maximum[128,128,20] + copy[128,128,320] + + the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, + the ``maximum`` dataset will show maximum values in each 16-channel block + in every spectra. + + + + This is ``rectangular`` to describe the region as a hyper-rectangle in + the index space of its parent group's data field. + + + + + + + + The name of data field in the parent group or the path of a data field relative + to the parent group (so it could be a field in a subgroup of the parent group) + + + + + The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and + dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an + :ref:`NXdetector`. + + + + + The starting position for region in detector data field array. + This is recommended as it also defines the region rank. + If omitted then defined as an array of zeros. + + + + + + + + The number of blocks or items in the hyperslab selection. + If omitted then defined as an array of dimensions that take into account + the other hyperslab selection fields to span the parent data field's shape. + + + + + + + + An optional field to define striding used to downsample data. + If omitted then defined as an array of ones. + + + + + + + + An optional field to define the block size used to copy or downsample data. In the + :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` + then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` + then the blocks are contiguous; otherwise the blocks overlap. + If omitted then defined as an array of ones. + + + + + + + + An optional field to define a divisor for scaling of reduced data. For example, in a + downsampled sum, it can reduce the maximum values to fit in the domain of the result + data type. In an image that is downsampled by summing 2x2 blocks, using + :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as + the parent dataset. + If omitted then no scaling occurs. + + + + + + + + An optional group containing data copied/downsampled from parent group’s data. Its dataset name + must reflect how the downsampling is done over each block. So it could be a reduction operation + such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each + block then use "copy" as the name. Where more than one downsample dataset is written + (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, + the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, + otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. + + The following figure shows how blocks are used in downsampling: + + .. figure:: region/NXregion-example.png + :width: 60% + + A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from + a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. + + + + + + An optional group containing any statistics derived from the region in parent group’s data + such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one + statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` + listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. + + diff --git a/contributed_definitions/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml index 155ca9c2a2..c725562743 100644 --- a/contributed_definitions/NXregistration.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -23,7 +23,7 @@ --> - Describes image registration procedures. + Describes image registration procedures. diff --git a/contributed_definitions/NXsample.nxdl.xml b/contributed_definitions/NXsample.nxdl.xml index 82030fac94..5dac64b788 100644 --- a/contributed_definitions/NXsample.nxdl.xml +++ b/contributed_definitions/NXsample.nxdl.xml @@ -1,27 +1,6 @@ - + - - + symbolic array lengths to be coordinated between various fields @@ -72,21 +51,21 @@ The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard':' + Abbreviated version of CIF standard: * 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 + * 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 + * 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':' + * 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. + - 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. * This is the *Hill* system used by Chemical Abstracts. @@ -191,7 +170,7 @@ - This will follow the Busing-Levy convention':' + This will follow the Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 @@ -201,7 +180,7 @@ - Orientation matrix of single crystal sample using Busing-Levy convention':' + Orientation matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 @@ -213,12 +192,12 @@ - UB matrix of single crystal sample using Busing-Levy convention':' + 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 + This is the multiplication of the orientation_matrix, + given above, with the :math:`B` matrix which can be derived from the lattice constants. @@ -606,14 +585,14 @@ - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + .. 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 82449a42b0..4bb59f8bf1 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -31,17 +31,11 @@ - - - diff --git a/contributed_definitions/NXseparator.nxdl.xml b/contributed_definitions/NXseparator.nxdl.xml index cb028d2c43..be3e7ce26f 100644 --- a/contributed_definitions/NXseparator.nxdl.xml +++ b/contributed_definitions/NXseparator.nxdl.xml @@ -1,72 +1,58 @@ - - - - - definition for an electrostatic separator. - - - - extended description of the separator. - - - - - define position of beamline element relative to production target - - - - - current set on magnet supply. - - - - - current read from magnet supply. - - - - - - voltage read from magnet supply. - - - - - - current set on HT supply. - - - - - current read from HT supply. - - - - - - voltage read from HT supply. - - - + + definition for an electrostatic separator. + + extended description of the separator. + + + define position of beamline element relative to production target + + + current set on magnet supply. + + + current read from magnet supply. + + + + voltage read from magnet supply. + + + + current set on HT supply. + + + current read from HT supply. + + + + voltage read from HT supply. + + diff --git a/contributed_definitions/NXslip_system_set.nxdl.xml b/contributed_definitions/NXslip_system_set.nxdl.xml index 3b134d6b91..12f064ce2c 100644 --- a/contributed_definitions/NXslip_system_set.nxdl.xml +++ b/contributed_definitions/NXslip_system_set.nxdl.xml @@ -35,11 +35,7 @@ Base class for describing a set of crystallographic slip systems. - - @@ -50,9 +46,6 @@ identifier(NX_UINT):--> - Array of Miller indices which describe the crystallographic plane. @@ -62,7 +55,6 @@ identifier(NX_UINT):--> - Array of Miller indices which describe the crystallographic direction. diff --git a/contributed_definitions/NXsnsevent.nxdl.xml b/contributed_definitions/NXsnsevent.nxdl.xml index b9079cc50a..934ada4985 100644 --- a/contributed_definitions/NXsnsevent.nxdl.xml +++ b/contributed_definitions/NXsnsevent.nxdl.xml @@ -1,339 +1,328 @@ - + - - - This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. - - - - - Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). - - - - - - - - - - - - - - - - - - - - - - - Motor logs from cvinfo file. - - - - - - - - - - - - - - - - - - - - - - - - - - - Command string for event2nxl. - - - - - - - - - - - - - - - - + + This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. + + + + Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). + + + + + + + + + + + + + + + + + + + + + + + Motor logs from cvinfo file. + + + + + + + + + + + + + + + + + + + + + + + + + + + Command string for event2nxl. + + + + + + + + + + + + + + + + + + + + + + + + Official NXDL schema after this file goes to applications. + + + + + + + + + + + + + + + - - - - - Official NXDL schema after this file goes to applications. - - - - + + + Detector calibration id from DAS. + - - - - - - - - - - - - + + + + + + + + + + + + + expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - Detector calibration id from DAS. + Six out of nine rotation parameters. - - - - - - - - - - - - - expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Six out of nine rotation parameters. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + - - - + + + + + + + + - - - - - + + + + + + - - - - - - - Six out of nine rotation parameters. - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Six out of nine rotation parameters. + + + + + - - + + + + + + + + - - - - - - - - Six out of nine rotation parameters. - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + - - + + + + + + + - expect ``signal=1 axes="time_of_flight"`` + Six out of nine rotation parameters. - + - - - - + + + + + + + + + + - + - - - - - - - - - - - - - Descriptive name of sample - - - - - - - - - - - - + + + + + + + + + expect ``signal=1 axes="time_of_flight"`` + + + + + + + + + + + + + + + + + + + + + + Descriptive name of sample + + + + + + + + + + + + diff --git a/contributed_definitions/NXsnshisto.nxdl.xml b/contributed_definitions/NXsnshisto.nxdl.xml index d23908f5f4..2e94b7c71e 100644 --- a/contributed_definitions/NXsnshisto.nxdl.xml +++ b/contributed_definitions/NXsnshisto.nxdl.xml @@ -1,350 +1,341 @@ - + - - - This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. - - - - - Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). - - - - - - - - - - - - - - - - - - - - - - - Motor logs from cvinfo file. - - - - - - - - - - - - - - - - - - - - - - - - - - - Command string for event2histo_nxl. - - - - - - - - - - - - - - - - + + This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. + + + + Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). + + + + + + + + + + + + + + + + + + + + + + + Motor logs from cvinfo file. + + + + + + + + + + + + + + + + + + + + + + + + + + + Command string for event2histo_nxl. + + + + + + + + + + + + + + + + + + + + + + + Official NXDL schema after this file goes to applications. + + + + + + + + + + + + + + + - - - - - Official NXDL schema after this file goes to applications. - - - - + + + Detector calibration id from DAS. + - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - Detector calibration id from DAS. + Six out of nine rotation parameters. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Six out of nine rotation parameters. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + - - - - Original specification called for NXchopper, - which is not a valid NeXus base class. - Select either NXdisk_chopper or NXfermi_chopper, as appropriate. - - + + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Original specification called for NXchopper, + which is not a valid NeXus base class. + Select either NXdisk_chopper or NXfermi_chopper, as appropriate. + + + + + + Original specification called for NXchopper, + which is not a valid NeXus base class. + Select either NXdisk_chopper or NXfermi_chopper, as appropriate. + + + + + + + + + + + + + + - Original specification called for NXchopper, - which is not a valid NeXus base class. - Select either NXdisk_chopper or NXfermi_chopper, as appropriate. + Six out of nine rotation parameters. - - - - - - - - - - - - - - - Six out of nine rotation parameters. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Six out of nine rotation parameters. - - - - - - - - - - - - - - - - - - - - - + + + + - - - + + + + - + - - - - + + + + - + - + + + + + + + + + - - - - - - - - - + + + + + + + - Descriptive name of sample + Six out of nine rotation parameters. - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Descriptive name of sample + + + + + + + + + + + + diff --git a/contributed_definitions/NXsolenoid_magnet.nxdl.xml b/contributed_definitions/NXsolenoid_magnet.nxdl.xml index 4fa4ca8992..457d5225b2 100644 --- a/contributed_definitions/NXsolenoid_magnet.nxdl.xml +++ b/contributed_definitions/NXsolenoid_magnet.nxdl.xml @@ -1,55 +1,51 @@ - - - - - definition for a solenoid magnet. - - - - extended description of the magnet. - - - - - define position of beamline element relative to production target - - - - - current set on supply. - - - - - current read from supply. - - - - - - voltage read from supply. - - - + +definition for a solenoid magnet. + +extended description of the magnet. + + +define position of beamline element relative to production target + + +current set on supply. + + +current read from supply. + + + +voltage read from supply. + + diff --git a/contributed_definitions/NXsolid_geometry.nxdl.xml b/contributed_definitions/NXsolid_geometry.nxdl.xml index 060b3d2f2f..f5bcaa742d 100644 --- a/contributed_definitions/NXsolid_geometry.nxdl.xml +++ b/contributed_definitions/NXsolid_geometry.nxdl.xml @@ -1,14 +1,14 @@ - + - + + + the head node for constructively defined geometry + + - the head node for constructively defined geometry + Instances of :ref:`NXquadric` making up elements of the geometry. - - - Instances of ':'ref':'`NXquadric` making up elements of the geometry. - - - - - Instances of ':'ref':'`NXoff_geometry` making up elements of the geometry. - - - - - The geometries defined, made up of instances of ':'ref':'`NXquadric` and ':'ref':'`NXoff_geometry`. - - + + + + Instances of :ref:`NXoff_geometry` making up elements of the geometry. + + + + + The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. + + diff --git a/contributed_definitions/NXsource.nxdl.xml b/contributed_definitions/NXsource.nxdl.xml index 7d9d802740..ae24b92e00 100644 --- a/contributed_definitions/NXsource.nxdl.xml +++ b/contributed_definitions/NXsource.nxdl.xml @@ -1,27 +1,6 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -116,7 +95,7 @@ - Source intensity/area (example':' s-1 cm-2) + Source intensity/area (example: s-1 cm-2) @@ -281,14 +260,14 @@ - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + .. 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 599fc8f04f..28d2e2c518 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -21,9 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - diff --git a/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml b/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml index 97ce9f69cd..e41ce1a860 100644 --- a/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Container for reporting a set of auger electron energy spectra. diff --git a/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml b/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml index 1e400215f5..20ce7bf72d 100644 --- a/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml @@ -1,27 +1,6 @@ - + - - + Container for reporting a set of cathodoluminescence spectra. diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml index f27a45e546..dd6df8264d 100644 --- a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -23,7 +23,6 @@ --> - Number of pixel per EELS mapping in the slow direction. @@ -105,11 +104,6 @@ - Pixel center of mass position y-coordinates. @@ -168,9 +162,6 @@ - Pixel center of mass energy loss bins. diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml index 34a40d60db..af0e8dccd4 100644 --- a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -22,10 +22,7 @@ # For further information, see http://www.nexusformat.org --> - - Number of pixel per X-ray mapping in the slow direction @@ -100,8 +97,6 @@ NEW ISSUE: make the binning flexible per scan point--> - Collected X-ray spectra for all pixels of a rectangular region-of-interest. @@ -119,11 +114,6 @@ NEW ISSUE: make the binning flexible per scan point--> - @@ -170,9 +160,6 @@ NEW ISSUE: make the binning flexible per scan point--> - @@ -184,7 +171,6 @@ NEW ISSUE: make the binning flexible per scan point--> - Details about computational steps how peaks were indexed as elements. @@ -264,7 +250,6 @@ NEW ISSUE: make the binning flexible per scan point--> Human-readable, given name to the image. - Individual element-specific maps. Individual maps should @@ -281,10 +266,6 @@ NEW ISSUE: make the binning flexible per scan point--> - diff --git a/contributed_definitions/NXspin_rotator.nxdl.xml b/contributed_definitions/NXspin_rotator.nxdl.xml index 0a25bee8ac..a86744af3f 100644 --- a/contributed_definitions/NXspin_rotator.nxdl.xml +++ b/contributed_definitions/NXspin_rotator.nxdl.xml @@ -1,72 +1,58 @@ - - - - - definition for a spin rotator. - - - - extended description of the spin rotator. - - - - - define position of beamline element relative to production target - - - - - current set on magnet supply. - - - - - current read from magnet supply. - - - - - - voltage read from magnet supply. - - - - - - current set on HT supply. - - - - - current read from HT supply. - - - - - - voltage read from HT supply. - - - + + definition for a spin rotator. + + extended description of the spin rotator. + + + define position of beamline element relative to production target + + + current set on magnet supply. + + + current read from magnet supply. + + + + voltage read from magnet supply. + + + + current set on HT supply. + + + current read from HT supply. + + + + voltage read from HT supply. + + diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index 689d40a7cf..6539130950 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -23,8 +23,8 @@ --> - Subclass of NXelectronanalyser to describe the spin filters in photoemission - experiments. + Subclass of NXelectronanalyser to describe the spin filters in + photoemission experiments. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index f1eed76c4c..308a23cc6d 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -147,7 +147,6 @@ Voltage applied to the stage to decelerate electrons. - The rotation, tilt and position of stage components can be specified @@ -156,18 +155,4 @@ - diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index f35ff39e74..8362cce7d0 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -21,8 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -40,7 +38,7 @@ Draft NeXus application definition for transmission experiments--> - Application definition for transmission experiments + Application definition for transmission experiments @@ -88,10 +86,6 @@ Draft NeXus application definition for transmission experiments--> definition rather than in this experiment description. - @@ -333,8 +327,6 @@ of instrument.--> - Properties of the sample measured diff --git a/contributed_definitions/NXxpcs.nxdl.xml b/contributed_definitions/NXxpcs.nxdl.xml index e7327eeba6..9839fbb2a9 100644 --- a/contributed_definitions/NXxpcs.nxdl.xml +++ b/contributed_definitions/NXxpcs.nxdl.xml @@ -1,14 +1,14 @@ - + - - + + + + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + + + Number of points + + + + X-ray Photon Correlation Spectroscopy (XPCS) data (results). + + The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data + in order to support development of community software tools. The definition presented here only + represents a starting point and contains fields that a common software tool should support for + community acceptance. + + Additional fields may be added to XPCS results file (either formally or informally). It is expected + that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or + 1D and/or 2D data. + + + + Official NeXus NXDL schema to which this file conforms + + + + + + + + **Locally** unique identifier for the experiment (a.k.a. run or scan). + + * For bluesky users, this is the run's `"scan_id"`. + * For SPEC users, this is the scan number (``SCAN_N``). + + + + + (optional) UUID identifier for this entry. + + See the `UUID standard <https://www.rfc-editor.org/rfc/rfc4122.html>`__ (or + `wikipedia <https://en.wikipedia.org/wiki/Universally_unique_identifier>`__) + for more information. + + * For `bluesky <https://blueskyproject.io/>`__ users, this is the + run's `"uid"` and is expected for that application. + * Typically, `SPEC <https://certif.com/content/spec/>`__ users will + not use this field without further engineering. + + + + + + Scan number (must be an integer). + + NOTE: Link to collection_identifier. + + + + + Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". + + + + + Ending time of experiment, such as "2021-02-11 11:23:45Z". + + + + + + The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) + describing on-equilibrium dynamics consume more memory resources so these data are separated. + + - The symbol(s) listed here will be used below to coordinate datasets - with the same shape. + Two-dimensional summation along the frames stack. + + sum of intensity v. time (in the units of "frames") - - - Number of points - - - + + + + Two-dimensional average along the frames stack. + + average intensity v. time (in the units of "frames") + + + + + normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 + + .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 + + Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific + region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some + open-source XPCS libraries refer to these bins as "rois", which are not to be confused with + EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ + + In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if + the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one + of the following two formats: + + * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value + * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value + + Note it is expected that "g2" and all quantities following it will be of the same length. + + Other formats are acceptable with sufficient axes description. + + See references below for related implementation information: + + .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` + .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata + + + + storage_mode describes the format of the data to be loaded + + We encourage the documentation of other formats not represented here. + + * one array representing entire data set ("one_array") + * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") + + + + + + + + + + + error values for the :math:`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (:math:`\pm` error). The data should be in the same format as ``g2``. + + + + + + + + + + + + unnormalized intensity auto-correlation function. + + Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. + + + + + + + + + + + + + delay_difference (also known as delay or lag step) + + This is quantized difference so that the "step" between two consecutive + frames is one frame (or step ``= dt = 1 frame``) + + It is the "quantized" delay time corresponding to the ``g2`` values. + + The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, + refer to :ref:`NXdetector` for conversion to time units. + + + + + + + + + + + + - X-ray Photon Correlation Spectroscopy (XPCS) data (results). - - The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data - in order to support development of community software tools. The definition presented here only - represents a starting point and contains fields that a common software tool should support for - community acceptance. - - Additional fields may be added to XPCS results file (either formally or informally). It is expected - that this XPCS data will be part of multi-modal data set that could involve e.g., ':'ref':'`NXcanSAS` or - 1D and/or 2D data. + The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. - - - - Official NeXus NXDL schema to which this file conforms - - - - + + + two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) + + See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early + description applied to X-ray scattering: + + .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } + + in which time is quantized by frames. In principle, any data format is acceptable if + the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one + of the following two formats: + + * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array + * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value + + + The computation of this result can be customized. These customizations can affect subsequently derived results (below). The + following attributes will be used to manage the customization. + + * Other normalization methods may be applied, but the method will not be specified in this + definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. + + * The various software libraries use different programming languages. Therefore, we need to + specify the ``time = 0`` origin location of the 2D array for each :math:`q`. + + * A method to reduce data storage needs is to only record half of the 2D array by populating + array elements above or below the array diagonal. + + + + + + storage_mode describes the format of the data to be loaded + + We encourage the documention of other formats represented here. + + + + + + + + + + + baseline is the expected value of a full decorrelation + + The baseline is a constant value added to the functional form of the auto-correlation + function. This value is required. + + + + + + + + + time_origin_location is the location of the origin + + + + + + + + + populated_elements describe the elements of the 2D array that are populated with data + + + + + + + + + + + frame weighted average along the diagonal direction in ``two_time_corr_func`` + + The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" + + * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` + * 2D array with shape (:math:`g_2`, :math:`q`) + + Note that delay_difference is not included here because it is derived from the shape of + extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. + + The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The + following attributes will be used to manage the customization. + + + + + + + + + + + + + + + + + + + first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. + + The first_point_for_fit is True ("1") or False ("0"). This value is required. + + + + + + + + + + error values for the :math:`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (:math:`\pm` error). + + + + + + + + + + + + + subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` + + Time slicing along the diagonal can be very sophisticated. This entry currently assumes + equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. + In principle, any data format is acceptable if the data and its axes are self describing as per NeXus + recommendations. However, the data is preferred in one of the following two formats: + + * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value + * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) + + Note that delay_difference is not included here because it is derived from the shape of + extracted :math:`g_2`. + + + + + + + + + + + + + + + + + + + error values for the :math:`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (:math:`\pm` error). + + + + + + + XPCS instrument Metadata. + + Objects can be entered here directly or linked from other + objects in the NeXus file (such as within ``/entry/instrument``). + + + + Incident beam line energy (either keV or eV). - - - **Locally** unique identifier for the experiment (a.k.a. run or scan). - - * For bluesky users, this is the run's `"scan_id"`. - * For SPEC users, this is the scan number (``SCAN_N``). - + + + Spread of incident beam line energy (either keV or eV). This quantity is otherwise known + as the energy resolution, which is related to the longitudinal coherence length. + - - - (optional) UUID identifier for this entry. - - See the `UUID standard <https':'//www.rfc-editor.org/rfc/rfc4122.html>`__ (or - `wikipedia <https':'//en.wikipedia.org/wiki/Universally_unique_identifier>`__) - for more information. - - * For `bluesky <https':'//blueskyproject.io/>`__ users, this is the - run's `"uid"` and is expected for that application. - * Typically, `SPEC <https':'//certif.com/content/spec/>`__ users will - not use this field without further engineering. - + + + Terse description of the incident beam polarization. + + The value can be plain text, such as ``vertical``, ``C+``, + ``circular left``. + - - - Scan number (must be an integer). - - NOTE':' Link to collection_identifier. - + + Size (2-D) of the beam at this position. + - - - Starting time of experiment, such as "2021-02-11 11':'22':'33.445566Z". - + + + + + XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes + this data is represented in different ways (sparse arrays or photon event list), but this detail + is left to the analysis software. Therefore, we only include requirements based on full array data. + + We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This + is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ + See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and + the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI + documentation (See Fig 11 vs Fig 12). + + Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to + convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may + either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. + + .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html + + + Detector name. - + + Distance between sample and detector. + + + Exposure time of frames, s. + + + + Exposure period (time between frame starts) of frames, s + + + + + Position of beam center, x axis, in detector's coordinates. + + + + + Position of beam center, y axis, in detector's coordinates. + + + + + + Length of pixel in x direction. + + + + + Length of pixel in y direction. + + + + + + + Data masks or mappings to regions of interest (roi) for specific :math:`Q` values + + Fields in this ``masks`` group describe regions of interest + in the data by either a mask to select pixels or to associate + a *map* of rois with a (one-dimensional) *list* of values. + + "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, + which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. + + "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and + NXxpcs/entry/two_time. + + "Static" refers to finer binning used for computation not strictly used for the final + XPCS results. Implementation of _static_ binning is left for individual libraries to + document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or + development of new NeXus definitions for GI-SAXS or other reciprocal space + intensity mapping. + + - Ending time of experiment, such as "2021-02-11 11':'23':'45Z". + roi index array or labeled array + + The values of this mask index (or map to) the :math:`Q` value from the + the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations + are performed on all pixels with a value > 0. + + The ``units`` attribute should be set to ``"au"`` + indicating arbitrary units. - - + + - The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) - describing on-equilibrium dynamics consume more memory resources so these data are separated. + 1-D list of :math:`Q` values, one for each roi index value. + + List order is determined by the index value of the associated roi map starting at ``1``. + + The only requirement for the list is that it may be iterable. Some expected formats are: + + * iterable list of floats (i.e., :math:`Q(r)`) + * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below + * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) + * iterable list of integers (for Nth roi_map value) or strings + + This format is chosen because results plotting packages are not common and simple I/O is required by end user. + The lists can be accessed as lists, arrays or via keys - - - Two-dimensional summation along the frames stack. - - sum of intensity v. time (in the units of "frames") - - - - - Two-dimensional average along the frames stack. - - average intensity v. time (in the units of "frames") - - - - - normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 - - .. math':'':' g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 - - Typically, ':'math':'`g_2` is a quantity calculated for a group of pixels representing a specific - region of reciprocal space. These groupings, or bins, are generically described as ':'math':'`q`. Some - open-source XPCS libraries refer to these bins as "rois", which are not to be confused with - EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ - - In short, ':'math':'`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if - the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats':' - - * iterable list of linked files (or keys) for each ':'math':'`g_2` with 1 file (key) per ':'math':'`q`, where `q` is called by the nth roi_map value - * 2D array [#]_ with shape (':'math':'`g_2`, ':'math':'`q`), where `q` is represented by the nth roi_map value, not the value `q` value - - Note it is expected that "g2" and all quantities following it will be of the same length. - - Other formats are acceptable with sufficient axes description. - - See references below for related implementation information':' - - .. [#] mask':' ``NXxpcs':'/entry/instrument/masks-group`` - .. [#] NeXus 2-D data and axes':' https':'//manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata - - - - storage_mode describes the format of the data to be loaded - - We encourage the documentation of other formats not represented here. - - * one array representing entire data set ("one_array") - * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") - - - - - - - - - - - error values for the ':'math':'`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (':'math':'`\pm` error). The data should be in the same format as ``g2``. - - - - - - - - - - - - unnormalized intensity auto-correlation function. - - Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. - - - - - - - - - - - - delay_difference (also known as delay or lag step) - - This is quantized difference so that the "step" between two consecutive - frames is one frame (or step ``= dt = 1 frame``) - - It is the "quantized" delay time corresponding to the ``g2`` values. - - The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, - refer to ':'ref':'`NXdetector` for conversion to time units. - - - - - - - - - - - + + - The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. + Array of :math:`\varphi` value for each pixel. + + List order is determined by the index value of the associated roi map starting at ``1``. - - - two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) - - See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early - description applied to X-ray scattering':' - - .. math':'':' C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } - - in which time is quantized by frames. In principle, any data format is acceptable if - the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats':' - - * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array - * 3D array with shape (frames, frames, q) or (q, frames, frames), where ':'math':'`q` is represented by the nth roi_map value, not the value `q` value - - - The computation of this result can be customized. These customizations can affect subsequently derived results (below). The - following attributes will be used to manage the customization. - - * Other normalization methods may be applied, but the method will not be specified in this - definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. - - * The various software libraries use different programming languages. Therefore, we need to - specify the ``time = 0`` origin location of the 2D array for each ':'math':'`q`. - - * A method to reduce data storage needs is to only record half of the 2D array by populating - array elements above or below the array diagonal. - - - - storage_mode describes the format of the data to be loaded - - We encourage the documention of other formats represented here. - - - - - - - - - - - baseline is the expected value of a full decorrelation - - The baseline is a constant value added to the functional form of the auto-correlation - function. This value is required. - - - - - - - - - time_origin_location is the location of the origin - - - - - - - - - populated_elements describe the elements of the 2D array that are populated with data - - - - - - - - - - - frame weighted average along the diagonal direction in ``two_time_corr_func`` - - The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" - - * iterable list of linked files for each ':'math':'`g_2` with 1 file per ':'math':'`q` - * 2D array with shape (':'math':'`g_2`, ':'math':'`q`) - - Note that delay_difference is not included here because it is derived from the shape of - extracted ':'math':'`g_2` because all frames are considered, which is not necessarily the case for ':'math':'`g_2`. - - The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The - following attributes will be used to manage the customization. - - - - - - - - - - - - - - - - - - first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. - - The first_point_for_fit is True ("1") or False ("0"). This value is required. - - - - - - - - - - error values for the ':'math':'`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (':'math':'`\pm` error). - - - - - - - - - - - - - subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` - - Time slicing along the diagonal can be very sophisticated. This entry currently assumes - equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. - In principle, any data format is acceptable if the data and its axes are self describing as per NeXus - recommendations. However, the data is preferred in one of the following two formats':' - - * iterable list of linked files (or keys) for each partial ':'math':'`g_2` of each q-bin represented by the roi_map value - * 3D array with shape (':'math':'`g_2`, ':'math':'`q`, nth_partial) - - Note that delay_difference is not included here because it is derived from the shape of - extracted ':'math':'`g_2`. - - - - - - - - - - - - - - - - - - error values for the ':'math':'`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (':'math':'`\pm` error). - - - - + + - XPCS instrument Metadata. - - Objects can be entered here directly or linked from other - objects in the NeXus file (such as within ``/entry/instrument``). + roi index array. + + The values of this mask index the :math:`|Q|` value from the + the ``static_q_list`` field. + + The ``units`` attribute should be set to ``"au"`` + indicating arbitrary units. - - - - Incident beam line energy (either keV or eV). - - - - - Spread of incident beam line energy (either keV or eV). This quantity is otherwise known - as the energy resolution, which is related to the longitudinal coherence length. - - - - - Terse description of the incident beam polarization. - - The value can be plain text, such as ``vertical``, ``C+``, - ``circular left``. - - - - - Size (2-D) of the beam at this position. - - - - - - XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes - this data is represented in different ways (sparse arrays or photon event list), but this detail - is left to the analysis software. Therefore, we only include requirements based on full array data. - - We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This - is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ - See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and - the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI - documentation (See Fig 11 vs Fig 12). - - Additionally, not all ':'ref':'`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to - convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may - either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. - - .. [#] Coherent X-ray Imaging Data Bank':' https':'//cxidb.org/cxi.html - - - - Detector name. - - - - - Distance between sample and detector. - - - - - Exposure time of frames, s. - - - - - Exposure period (time between frame starts) of frames, s - - - - - Position of beam center, x axis, in detector's coordinates. - - - - - Position of beam center, y axis, in detector's coordinates. - - - - - Length of pixel in x direction. - - - - - Length of pixel in y direction. - - - - - - Data masks or mappings to regions of interest (roi) for specific ':'math':'`Q` values - - Fields in this ``masks`` group describe regions of interest - in the data by either a mask to select pixels or to associate - a *map* of rois with a (one-dimensional) *list* of values. - - "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, - which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. - - "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and - NXxpcs/entry/two_time. - - "Static" refers to finer binning used for computation not strictly used for the final - XPCS results. Implementation of _static_ binning is left for individual libraries to - document. We encourage usage of ':'ref':'`NXcanSAS` to represent standard SAXS results or - development of new NeXus definitions for GI-SAXS or other reciprocal space - intensity mapping. - - - - roi index array or labeled array - - The values of this mask index (or map to) the ':'math':'`Q` value from the - the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations - are performed on all pixels with a value > 0. - - The ``units`` attribute should be set to ``"au"`` - indicating arbitrary units. - - - - - 1-D list of ':'math':'`Q` values, one for each roi index value. - - List order is determined by the index value of the associated roi map starting at ``1``. - - The only requirement for the list is that it may be iterable. Some expected formats are':' - - * iterable list of floats (i.e., ':'math':'`Q(r)`) - * iterable list of tuples (i.e., ':'math':'`Q(r)`, ':'math':'`\varphi`), but preferable use the seperate ':'math':'`\varphi` field below - * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) - * iterable list of integers (for Nth roi_map value) or strings - - This format is chosen because results plotting packages are not common and simple I/O is required by end user. - The lists can be accessed as lists, arrays or via keys - - - - - Array of ':'math':'`\varphi` value for each pixel. - - List order is determined by the index value of the associated roi map starting at ``1``. - - - - - roi index array. - - The values of this mask index the ':'math':'`|Q|` value from the - the ``static_q_list`` field. - - The ``units`` attribute should be set to ``"au"`` - indicating arbitrary units. - - - - - 1-D list of ':'math':'`|Q|` values, 1 for each roi. - - - - - - - - Sample temperature setpoint, (C or K). - - - - - Sample temperature actual, (C or K). - - - - - - - + + - Any other notes. - - NAME':' The NeXus convention, to use all upper case - to indicate the name (here ``NOTE``), is left to the file - writer. In our case, follow the suggested name - pattern and sequence':' note_1, note_2, note_3, ... - Start with ``note_1`` if the first one, otherwise - pick the next number in this sequence. + 1-D list of :math:`|Q|` values, 1 for each roi. - + + - + + + + + + Sample temperature setpoint, (C or K). + + + - Describe the computation process that produced these results. + Sample temperature actual, (C or K). + + + + + + + + + Any other notes. + + NAME: The NeXus convention, to use all upper case + to indicate the name (here ``NOTE``), is left to the file + writer. In our case, follow the suggested name + pattern and sequence: note_1, note_2, note_3, ... + Start with ``note_1`` if the first one, otherwise + pick the next number in this sequence. + + + + + + Describe the computation process that produced these results. + + From 91b31ab2081ff78691acbfc2c7e48f789a635442 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 09:42:16 +0200 Subject: [PATCH 127/203] regenerated nyaml for NIAC registered unchaged nxdl files --- .../nyaml/NXcontainer.yaml | 205 ++++- contributed_definitions/nyaml/NXcsg.yaml | 107 ++- .../nyaml/NXcxi_ptycho.yaml | 283 +++++- .../nyaml/NXelectrostatic_kicker.yaml | 80 +- .../nyaml/NXimage_set_em_bf.yaml | 15 +- .../nyaml/NXimage_set_em_bse.yaml | 15 +- .../nyaml/NXimage_set_em_chamber.yaml | 15 +- .../nyaml/NXimage_set_em_df.yaml | 15 +- .../nyaml/NXimage_set_em_diffrac.yaml | 15 +- .../nyaml/NXimage_set_em_ecci.yaml | 15 +- .../nyaml/NXimage_set_em_ronchigram.yaml | 18 +- .../nyaml/NXimage_set_em_se.yaml | 187 +++- .../nyaml/NXinteraction_vol_em.yaml | 49 +- .../nyaml/NXmagnetic_kicker.yaml | 77 +- contributed_definitions/nyaml/NXquadric.yaml | 104 ++- .../nyaml/NXquadrupole_magnet.yaml | 67 +- contributed_definitions/nyaml/NXregion.yaml | 284 +++++- .../nyaml/NXseparator.yaml | 80 +- contributed_definitions/nyaml/NXsnsevent.yaml | 376 +++++++- contributed_definitions/nyaml/NXsnshisto.yaml | 385 +++++++- .../nyaml/NXsolenoid_magnet.yaml | 67 +- .../nyaml/NXsolid_geometry.yaml | 74 +- .../nyaml/NXspectrum_set_em_auger.yaml | 15 +- .../nyaml/NXspectrum_set_em_cathodolum.yaml | 15 +- .../nyaml/NXspin_rotator.yaml | 80 +- contributed_definitions/nyaml/NXxpcs.yaml | 834 +++++++++++++++--- 26 files changed, 3127 insertions(+), 350 deletions(-) diff --git a/contributed_definitions/nyaml/NXcontainer.yaml b/contributed_definitions/nyaml/NXcontainer.yaml index 93fe2242a6..2bfbdf7f58 100644 --- a/contributed_definitions/nyaml/NXcontainer.yaml +++ b/contributed_definitions/nyaml/NXcontainer.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | State of a container holding the sample under investigation. A container is any object in the beam path which absorbs the beam and @@ -7,9 +7,9 @@ doc: | determined to process the experimental data. Examples of containers include glass capillary tubes, vanadium cans, windows in furnaces or diamonds in a Diamond Anvil Cell. The following figures show a complex - example of a container':' + example of a container: - .. figure':'':' container/ComplexExampleContainer.png + .. figure:: container/ComplexExampleContainer.png A hypothetical capillary furnace. The beam passes from left to right (blue dashes), passing through window 1, then window 2, before @@ -23,7 +23,7 @@ doc: | elemental composition, etc.) of the portion of the container which the beam passed through. - .. figure':'':' container/ComplexContainerBeampath.png + .. figure:: container/ComplexContainerBeampath.png A complete description of the shapes of the container elements with their orientation relative to the beam and also information on @@ -40,21 +40,20 @@ doc: | container and a link to a dataset containing a measurement of the container with nothing inside, to allow data corrections (at a specific beam energy/measurement time) to be made. - type: group NXcontainer(NXobject): name: - doc: | + doc: | Descriptive name of container. description: - doc: | + doc: | Verbose description of container and how it fits into the wider experimental set up. chemical_formula: - doc: | + doc: | Chemical composition of the material the container is made from. Specified using CIF conventions. Abbreviated version of CIF - standard':' + standard: * Only recognized element symbols may be used. * Each element symbol is followed by a 'count' number. A count of @@ -68,7 +67,7 @@ NXcontainer(NXobject): * 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':' + * If carbon is present, the order should be: - C, then H, then the other elements in alphabetical order of their symbol. @@ -78,46 +77,218 @@ NXcontainer(NXobject): * This is the *Hill* system used by Chemical Abstracts. density(NX_FLOAT): unit: NX_MASS_DENSITY - doc: | + doc: | Density of the material the container is made from. dimensions: rank: 1 dim: [[1, n_comp]] packing_fraction(NX_FLOAT): unit: NX_UNITLESS - doc: | + doc: | Fraction of the volume of the container occupied by the material forming the container. dimensions: dim: [[1, n_comp]] relative_molecular_mass(NX_FLOAT): unit: NX_MASS - doc: | + doc: | Relative molecular mass of container. dimensions: rank: 1 dim: [[1, n_comp]] beam(NXbeam): - doc: | + doc: | Details of beam incident on container, including the position relative to the sample (to determine whether the container is upstream or downstream of the sample). shape(NXshape): - doc: | + doc: | Shape of the container. In combination with orientation this should allow the beampath through the container to be modelled to allow the adsorption to be calculated. orientation(NXtransformations): - doc: | + doc: | The angle the container makes to the beam and how it may change during the experiment.In combination with shape this should allow the beampath through the container to be modelled to allow the adsorption of the container to be calculated. reference_measurement(link): target: /NXentry - doc: | + doc: | A link to a full data collection which contains the actual measured data for this container within the experimental set up (with no sample or inner container(s)). This data set will also include the wavelength/energy, measurement time and intensity for which these data are valid. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fbb634b42fbf75d55158a96329119a770f9ff716d2e3ec127b28b192c5fe872a +# +# +# +# +# +# +# State of a container holding the sample under investigation. +# +# A container is any object in the beam path which absorbs the beam and +# whose contribution to the overall attenuation/scattering needs to be +# determined to process the experimental data. Examples of containers +# include glass capillary tubes, vanadium cans, windows in furnaces or +# diamonds in a Diamond Anvil Cell. The following figures show a complex +# example of a container: +# +# .. figure:: container/ComplexExampleContainer.png +# +# A hypothetical capillary furnace. The beam passes from left to right +# (blue dashes), passing through window 1, then window 2, before +# passing through the downstream wall of the capillary. It is then +# scattered by the sample with scattered beams passing through the +# upstream wall of the capillary, then windows 4 and 5. As part of the +# corrections for a PDF experiment it is necessary to subtract the PDF +# of the empty container (i.e. each of the windows and the capillary). +# To calculate the PDF of the empty container it is necessary to have +# the measured scattering data and to know the nature (e.g. density, +# elemental composition, etc.) of the portion of the container which +# the beam passed through. +# +# .. figure:: container/ComplexContainerBeampath.png +# +# A complete description of the shapes of the container elements with +# their orientation relative to the beam and also information on +# whether they are upstream or downstream of the sample is also +# therefore important. For example, although the windows 2 and 4 have +# the same shape, the path taken through them by the beam is very +# different and this needs to be modelled. Furthermore, it is not +# inconceivable that windows might move during an experiment and thus +# the changes to the beampath would need to be accounted for. +# +# This class encodes the position of the container with respect to the +# sample and allows the calculation of the beampath through the container. +# It also includes sufficient data to model beam absorption of the +# container and a link to a dataset containing a measurement of the +# container with nothing inside, to allow data corrections (at a specific +# beam energy/measurement time) to be made. +# +# +# +# Descriptive name of container. +# +# +# +# +# Verbose description of container and how it fits into the wider +# experimental set up. +# +# +# +# +# Chemical composition of the material the container is made from. +# Specified using CIF conventions. Abbreviated version of CIF +# standard: +# +# * 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. +# +# * This is the *Hill* system used by Chemical Abstracts. +# +# +# +# +# Density of the material the container is made from. +# +# +# +# +# +# +# +# Fraction of the volume of the container occupied by the material +# forming the container. +# +# +# +# +# +# +# Relative molecular mass of container. +# +# +# +# +# +# +# Details of beam incident on container, including the position +# relative to the sample (to determine whether the container is +# upstream or downstream of the sample). +# +# +# +# +# Shape of the container. In combination with orientation this +# should allow the beampath through the container to be modelled to +# allow the adsorption to be calculated. +# +# +# +# +# The angle the container makes to the beam and how it may change +# during the experiment.In combination with shape this should allow +# the beampath through the container to be modelled to allow the +# adsorption of the container to be calculated. +# +# +# +# +# A link to a full data collection which contains the actual +# measured data for this container within the experimental set up +# (with no sample or inner container(s)). This data set will also +# include the wavelength/energy, measurement time and intensity for +# which these data are valid. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcsg.yaml b/contributed_definitions/nyaml/NXcsg.yaml index d1580d6692..e7f408c7a2 100644 --- a/contributed_definitions/nyaml/NXcsg.yaml +++ b/contributed_definitions/nyaml/NXcsg.yaml @@ -1,32 +1,119 @@ category: base -doc: | - Constructive Solid Geometry base class, using ':'ref':'`NXquadric` and ':'ref':'`NXoff_geometry` - +doc: | + Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` type: group NXcsg(NXobject): operation: - doc: | + doc: | One of the standard construction solid geometry set operations, or if the CSG is a pointer to the geometry provided by an - ':'ref':'`NXquadric` or an ':'ref':'`NXoff_geometry`. Takes values':' + :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: enumeration: [UNION, INTERSECTION, DIFFERENCE, COMPLEMENT, IS_QUADRIC, IS_MESH] a(NXcsg): exists: ['min', '0', 'max', '1'] - doc: | + doc: | The first operand of constructive solid geometry operation. Compulsory if 'operation' is UNION, INTERSECTION, DIFFERENCE or COMPLEMENT. b(NXcsg): exists: ['min', '0', 'max', '1'] - doc: | + doc: | The second operand of constructive solid geometry operation. Compulsory if 'operation' is UNION, INTERSECTION or DIFFERENCE. geometry(NX_CHAR): exists: ['min', '0', 'max', '1'] - doc: | - Path to a field that is either an ':'ref':'`NXquadric` (if - 'operation' = IS_QUADRIC) or an ':'ref':'`NXoff_geometry` (if + doc: | + Path to a field that is either an :ref:`NXquadric` (if + 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if 'operation' = IS_MESH) that defines the surface making up the constructive solid geometry component. Compulsory if 'operation' is IS_QUADRIC or IS_MESH. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 26b9cbb33ac382f8758dc8bda210c12a550d888e5d33c1a0e662e9671d2788db +# +# +# +# +# +# Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` +# +# +# One of the standard construction solid geometry set operations, +# or if the CSG is a pointer to the geometry provided by an +# :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: +# +# +# +# +# +# +# +# +# +# +# +# +# The first operand of constructive solid geometry +# operation. Compulsory if 'operation' is UNION, INTERSECTION, +# DIFFERENCE or COMPLEMENT. +# +# +# +# +# The second operand of constructive solid geometry +# operation. Compulsory if 'operation' is UNION, INTERSECTION or +# DIFFERENCE. +# +# +# +# +# Path to a field that is either an :ref:`NXquadric` (if +# 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if +# 'operation' = IS_MESH) that defines the surface making up the +# constructive solid geometry component. Compulsory if 'operation' +# is IS_QUADRIC or IS_MESH. +# +# +# diff --git a/contributed_definitions/nyaml/NXcxi_ptycho.yaml b/contributed_definitions/nyaml/NXcxi_ptycho.yaml index 9b5fbc5a56..1b68b54452 100644 --- a/contributed_definitions/nyaml/NXcxi_ptycho.yaml +++ b/contributed_definitions/nyaml/NXcxi_ptycho.yaml @@ -1,5 +1,5 @@ category: application -doc: | +doc: | Application definition for a ptychography experiment, compatible with CXI from version 1.6. This is compatible with CXI from version 1.6 if this application definition @@ -9,23 +9,17 @@ doc: | An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). - -symbols: - doc: | +symbols: + doc: | These symbols will be used below to coordinate the shapes of the datasets. - - npts_x: | + npts_x: | The number of points in the x direction - - npts_y: | + npts_y: | Number of points in the y direction. - - frame_size_x: | + frame_size_x: | Number of detector pixels in x - - frame_size_y: | + frame_size_y: | Number of detector pixels in y - type: group NXcxi_ptycho(NXobject): (NXentry)entry_1: @@ -37,7 +31,7 @@ NXcxi_ptycho(NXobject): exists: ['min', '0', 'max', '1'] definition(NX_CHAR): exists: ['min', '1', 'max', '1'] - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXcxi_ptycho] (NXinstrument)instrument_1: @@ -48,7 +42,7 @@ NXcxi_ptycho(NXobject): exists: ['min', '1', 'max', '1'] energy(NX_FLOAT): exists: ['min', '1', 'max', '1'] - doc: | + doc: | This is the energy of the machine, not the beamline. probe(NX_FLOAT): exists: ['min', '1', 'max', '1'] @@ -85,11 +79,11 @@ NXcxi_ptycho(NXobject): exists: ['min', '1', 'max', '1'] \@axes: type: NX_CHAR - doc: | + doc: | should have value "[, data]" \@signal: type: NX_CHAR - doc: | + doc: | should have value "data" (NXtransformations)transformations: vector(NX_NUMBER): @@ -97,7 +91,7 @@ NXcxi_ptycho(NXobject): translation(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1', 'max', '1'] - doc: | + doc: | This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y \@units: type: NX_CHAR @@ -105,12 +99,12 @@ NXcxi_ptycho(NXobject): \@axes: exists: optional type: NX_CHAR - doc: | - this should take the value "translation':'$slowaxisname':'$fastaxisname" + doc: | + this should take the value "translation:$slowaxisname:$fastaxisname" \@interpretation: exists: optional type: NX_CHAR - doc: | + doc: | This should be "image" data(NX_INT): signal: 1 @@ -120,7 +114,7 @@ NXcxi_ptycho(NXobject): dim: [[1, npts_x], [2, npts_y], [3, frame_size_x], [4, frame_size_y]] data_1(link): target: /NXentry/NXinstrument/NXdetector/data - doc: | + doc: | This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless of the scan pattern. Use hdf5 virtual dataset to achieve this. x_pixel_size(NX_FLOAT): @@ -138,7 +132,7 @@ NXcxi_ptycho(NXobject): distance(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1', 'max', '1'] - doc: | + doc: | The distance between the detector and the sample \@units: type: NX_CHAR @@ -166,12 +160,12 @@ NXcxi_ptycho(NXobject): \@axes: type: NX_CHAR exists: optional - doc: | + doc: | This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster \@signal: type: NX_CHAR exists: optional - doc: | + doc: | This should be "data" data(link): target: /NXentry/NXinstrument/NXdetector/data @@ -183,7 +177,7 @@ NXcxi_ptycho(NXobject): y_indices(NX_CHAR): (NXcollection)data_1: exists: ['min', '1', 'max', '1'] - doc: | + doc: | To ensure CXI compatibility the data in this group must always have shape that is (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that hdf5 virtual dataset is used. @@ -196,7 +190,7 @@ NXcxi_ptycho(NXobject): name(NX_CHAR): exists: ['min', '0', 'max', '1'] transformations(NXtransformations): - doc: | + doc: | This must contain two fields with the x and y motors that are linked via the dependency tree according to the real-life motor layout dependency. For raster scans x and y will have shape (npts_x, npts_y) @@ -209,3 +203,238 @@ NXcxi_ptycho(NXobject): exists: ['min', '1', 'max', '1'] translation(link): target: /NXentry/NXinstrument/NXdetector/translation + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cc83e17501fdd8eab38f6229fd41422c15a196db1698921004af9d9736c9cb83 +# +# +# +# +# +# +# These symbols will be used below to coordinate the shapes of the datasets. +# +# +# +# +# The number of points in the x direction +# +# +# +# +# +# Number of points in the y direction. +# +# +# +# +# Number of detector pixels in x +# +# +# +# +# +# Number of detector pixels in y +# +# +# +# +# +# Application definition for a ptychography experiment, compatible with CXI from version 1.6. +# +# This is compatible with CXI from version 1.6 if this application definition +# is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important +# to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, +# with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. +# +# An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths +# with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). +# +# +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# This is the energy of the machine, not the beamline. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# should have value "[, data]" +# +# +# +# +# should have value "data" +# +# +# +# +# +# +# +# This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y +# +# +# +# +# this should take the value "translation:$slowaxisname:$fastaxisname" +# +# +# +# +# This should be "image" +# +# +# +# +# +# +# +# +# +# +# +# +# +# This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless +# of the scan pattern. Use hdf5 virtual dataset to achieve this. +# +# +# +# +# +# +# +# +# +# +# The distance between the detector and the sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster +# +# +# +# +# This should be "data" +# +# +# +# +# +# +# +# +# +# +# To ensure CXI compatibility the data in this group must always have shape that is +# (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that +# hdf5 virtual dataset is used. +# +# +# +# +# +# +# +# +# +# This must contain two fields with the x and y motors that are linked via the +# dependency tree according to the real-life motor layout dependency. +# For raster scans x and y will have shape (npts_x, npts_y) +# For arbitrary scans x and y will be (npts_x*npts_y,) +# An attribute with the units for each motor is required. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml index dc39c3b878..821e7c9324 100644 --- a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml +++ b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml @@ -1,43 +1,105 @@ category: base -doc: | +doc: | definition for a electrostatic kicker. - type: group NXelectrostatic_kicker(NXobject): description(NX_CHAR): - doc: | + doc: | extended description of the kicker. beamline_distance(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | define position of beamline element relative to production target timing(NX_FLOAT): unit: NX_TIME exists: ['min', '0', 'max', '1'] - doc: | + doc: | kicker timing as defined by ``description`` attribute \@description: type: NX_CHAR set_current(NX_FLOAT): unit: NX_CURRENT exists: ['min', '0', 'max', '1'] - doc: | + doc: | current set on supply. read_current(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | current read from supply. value: unit: NX_CURRENT set_voltage(NX_FLOAT): unit: NX_VOLTAGE exists: ['min', '0', 'max', '1'] - doc: | + doc: | volage set on supply. read_voltage(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | voltage read from supply. value: unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8bc323e93c7d175eab0c362d716d4ca617041ffaf2f420a386d92ab7cb75d595 +# +# +# +# +# definition for a electrostatic kicker. +# +# extended description of the kicker. +# +# +# define position of beamline element relative to production target +# +# +# kicker timing as defined by ``description`` attribute +# +# +# +# current set on supply. +# +# +# current read from supply. +# +# +# +# volage set on supply. +# +# +# voltage read from supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_bf.yaml b/contributed_definitions/nyaml/NXimage_set_em_bf.yaml index 207b8f5485..18f462d3f5 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_bf.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_bf.yaml @@ -1,8 +1,19 @@ category: base -doc: | +doc: | Container for reporting a set of images taken in bright field mode. - type: group (NXobject)NXimage_set_em_bf: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 97b1cbbb65471ab425b7b56afe4fb7656087e13682a01527eb0f8c479b4afde0 +# +# +# +# +# Container for reporting a set of images taken in bright field mode. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_bse.yaml b/contributed_definitions/nyaml/NXimage_set_em_bse.yaml index 131e47f0f1..80b5de171f 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_bse.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_bse.yaml @@ -1,8 +1,19 @@ category: base -doc: | +doc: | Container for reporting a set of back-scattered electron images. - type: group (NXobject)NXimage_set_em_bse: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# dd6e820f87f0f28d05c4b326a9c7c10182844dca68f531c96c53f23f9e032404 +# +# +# +# +# Container for reporting a set of back-scattered electron images. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml b/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml index fbbfc51dec..34c00c6c72 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml @@ -1,8 +1,19 @@ category: base -doc: | +doc: | Container for images recorded with e.g. a TV camera in the microscope chamber. - type: group (NXobject)NXimage_set_em_chamber: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d7cf1580a93b0e7d3e0707fd6c0755ea4cc2088b1fa90bb7103e7944cb2cb023 +# +# +# +# +# Container for images recorded with e.g. a TV camera in the microscope chamber. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_df.yaml b/contributed_definitions/nyaml/NXimage_set_em_df.yaml index b56a802faf..c92af257c5 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_df.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_df.yaml @@ -1,8 +1,19 @@ category: base -doc: | +doc: | Container for reporting a set of images taken in dark field mode. - type: group (NXobject)NXimage_set_em_df: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ae023c1522bd25c3f09b11c773b64dffc20163523750045d878d5aefd181d0d6 +# +# +# +# +# Container for reporting a set of images taken in dark field mode. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml b/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml index 8c09377ea4..d34c9bb5fe 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml @@ -1,8 +1,19 @@ category: base -doc: | +doc: | Container for reporting a set of diffraction images. - type: group (NXobject)NXimage_set_em_diffrac: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8ed8592c148009db926f1d317b7a02c479604c26664cf5da49619911b4c171d6 +# +# +# +# +# Container for reporting a set of diffraction images. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml b/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml index 3dd7da7ee8..917171d918 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml @@ -1,8 +1,19 @@ category: base -doc: | +doc: | Container for reporting back-scattered electron channeling contrast images. - type: group (NXobject)NXimage_set_em_ecci: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8bab1f8cdf185ad16552fff19483fc7336a544e55ae323b2c3d1b7106c60848f +# +# +# +# +# Container for reporting back-scattered electron channeling contrast images. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml b/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml index 1d77b54180..06fa6aa369 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml @@ -1,11 +1,25 @@ category: base -doc: | +doc: | Container for reporting a set of images related to a ronchigram. Ronchigrams are specifically used in transmission electron microscopy to judge the settings for the aberration corrections and alignment. - type: group (NXobject)NXimage_set_em_ronchigram: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f11728363f198092b5506064b30ea5e65cea08e628d4b8c7d1f5e2241bd57dcb +# +# +# +# +# Container for reporting a set of images related to a ronchigram. +# +# Ronchigrams are specifically used in transmission electron microscopy +# to judge the settings for the aberration corrections and alignment. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_se.yaml b/contributed_definitions/nyaml/NXimage_set_em_se.yaml index eebd017d97..03cd5e92a7 100644 --- a/contributed_definitions/nyaml/NXimage_set_em_se.yaml +++ b/contributed_definitions/nyaml/NXimage_set_em_se.yaml @@ -1,26 +1,22 @@ category: base -doc: | +doc: | Container for reporting a set of secondary electron images. Secondary electron images are one of the most important signal especially for scanning electron microscopy in materials science and engineering, for analyses of surface topography, getting an overview of the analysis region, or fractography. - -symbols: - n_images: | +symbols: + n_images: | Number of images. - - n_y: | + n_y: | Number of pixels along the slow scan direction (often y). - - n_x: | + n_x: | Number of pixels along the fast scan direction (often x). - type: group (NXobject)NXimage_set_em_se: (NXdata): - doc: | + doc: | Collected secondary electron images (eventually as an image stack). intensity(NX_NUMBER): unit: NX_UNITLESS @@ -29,7 +25,7 @@ type: group dim: [[1, n_p], [2, n_y], [3, n_x]] \@long_name: type: NX_CHAR - doc: | + doc: | Secondary electron image intensity image_id(NX_NUMBER): unit: NX_UNITLESS @@ -38,7 +34,7 @@ type: group dim: [[1, n_p]] \@long_name: type: NX_CHAR - doc: | + doc: | Image identifier ypos(NX_NUMBER): unit: NX_LENGTH @@ -47,7 +43,7 @@ type: group dim: [[1, n_y]] \@long_name: type: NX_CHAR - doc: | + doc: | Label for the y axis xpos(NX_NUMBER): unit: NX_LENGTH @@ -56,11 +52,11 @@ type: group dim: [[1, n_x]] \@long_name: type: NX_CHAR - doc: | + doc: | Label for the x axis roi(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | Physical dimensions of the region-of-interest on the specimen surface which the image covers. The first and second number are the coordinates for the @@ -73,39 +69,184 @@ type: group unit: NX_TIME number_of_frames_averaged(NX_UINT): unit: NX_UNITLESS - doc: | + doc: | How many frames were averaged to obtain the image. dimensions: rank: 1 dim: [[1, n_images]] bias_voltage(NX_FLOAT): - doc: | + doc: | Bias voltage applied to the e.g. Faraday cage in front of the SE detector to attract or repell secondary electrons below a specific kinetic energy. (NXoptical_system_em): exists: optional - doc: | + doc: | Container to store relevant settings affecting beam path, magnification, and working_distance scan_rotation(NXprocess): - doc: | + doc: | Scan rotation is an option offer by most control software. tilt_correction(NXprocess): - doc: | + doc: | Tilt correction is an option offered by most control software of SEMs to apply an on-the-fly processing of the image to correct for the excursion of objects when characterized with SE images on samples whose surface normal is tilted about an axis perpendicular to the optical axis. active(NX_BOOLEAN): - doc: | + doc: | Was the option switched active or not. dynamic_focus(NXprocess): - doc: | + doc: | Dynamic focus is an option offered by most control software of SEMs to keep the image also focused when probing locations on the specimens beyond those for which the lens system was calibrated. active(NX_BOOLEAN): - doc: | + doc: | Was the option switched active or not. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e840afac66f17f804831854d8f4a942ec96a646e3eed57dcd48e6c66ab5d552c +# +# +# +# +# +# +# Number of images. +# +# +# +# +# Number of pixels along the slow scan direction (often y). +# +# +# +# +# Number of pixels along the fast scan direction (often x). +# +# +# +# +# Container for reporting a set of secondary electron images. +# +# Secondary electron images are one of the most important signal especially +# for scanning electron microscopy in materials science and engineering, for +# analyses of surface topography, getting an overview of the analysis region, +# or fractography. +# +# +# +# Collected secondary electron images (eventually as an image stack). +# +# +# +# +# +# +# +# +# +# Secondary electron image intensity +# +# +# +# +# +# +# +# +# +# Image identifier +# +# +# +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# +# Physical dimensions of the region-of-interest on +# the specimen surface which the image covers. +# The first and second number are the coordinates for the +# minimum edge, the third and fourth number are the coordinates +# for the maximum edge of the rectangular ROI. +# +# +# +# +# +# +# +# +# +# How many frames were averaged to obtain the image. +# +# +# +# +# +# +# +# Bias voltage applied to the e.g. Faraday cage in front of the +# SE detector to attract or repell secondary electrons below +# a specific kinetic energy. +# +# +# +# +# Container to store relevant settings affecting beam path, +# magnification, and working_distance +# +# +# +# +# Scan rotation is an option offer by most control software. +# +# +# +# +# Tilt correction is an option offered by most control software of SEMs +# to apply an on-the-fly processing of the image to correct for +# the excursion of objects when characterized with SE images +# on samples whose surface normal is tilted about an axis perpendicular +# to the optical axis. +# +# +# +# Was the option switched active or not. +# +# +# +# +# +# Dynamic focus is an option offered by most control software of SEMs +# to keep the image also focused when probing locations on the specimens +# beyond those for which the lens system was calibrated. +# +# +# +# Was the option switched active or not. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml index 9a96173b74..916ca1dacc 100644 --- a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml +++ b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | Base class for storing details about a modelled shape of interaction volume. The interaction volume is mainly relevant in scanning electron microscopy @@ -25,12 +25,51 @@ doc: | be relevant e.g. for X-ray spectroscopy Further details on how the interaction volume can be quantified - is available in the literature for example':' + is available in the literature for example: - * `S. Richter et al. `_ - * `J. Bünger et al. `_ - + * `S. Richter et al. `_ + * `J. Bünger et al. `_ type: group (NXobject)NXinteraction_vol_em: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 29b6daff56a280c88764ab6e66b9b4e67228cd110dbb825726104e01550aeeb7 +# +# +# +# +# Base class for storing details about a modelled shape of interaction volume. +# +# The interaction volume is mainly relevant in scanning electron microscopy +# when the sample is thick enough so that the beam is unable to illuminate +# through the specimen. +# Computer models like Monte Carlo or molecular dynamics / electron beam +# interaction simulations can be used to qualify and/or quantify the shape of +# the interaction volume. +# +# Explicit or implicit descriptions are possible. +# +# * An implicit description is via a set of electron/specimen interactions +# represented ideally as trajectory data from the computer simulation. +# * An explicit description is via an iso-contour surface using either +# a simulation grid or a triangulated surface mesh of the approximated +# iso-contour surface evaluated at specific threshold values. +# Iso-contours could be computed from electron or particle fluxes through +# an imaginary control surface (the iso-surface). +# Threshold values can be defined by particles passing through a unit control +# volume (electrons) or energy-levels (e.g. the case of X-rays). +# Details depend on the model. +# * Another explicit description is via theoretical models which may +# be relevant e.g. for X-ray spectroscopy +# +# Further details on how the interaction volume can be quantified +# is available in the literature for example: +# +# * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ +# * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml index 29698fdde3..317325e62a 100644 --- a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml +++ b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml @@ -1,43 +1,102 @@ category: base -doc: | +doc: | definition for a magnetic kicker. - type: group NXmagnetic_kicker(NXobject): description(NX_CHAR): - doc: | + doc: | extended description of the kicker. beamline_distance(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | define position of beamline element relative to production target timing(NX_FLOAT): unit: NX_TIME exists: ['min', '0', 'max', '1'] - doc: | + doc: | kicker timing as defined by ``description`` attribute \@description: type: NX_CHAR set_current(NX_FLOAT): unit: NX_CURRENT exists: ['min', '0', 'max', '1'] - doc: | + doc: | current set on supply. read_current(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | current read from supply. value: unit: NX_CURRENT set_voltage(NX_FLOAT): unit: NX_VOLTAGE exists: ['min', '0', 'max', '1'] - doc: | + doc: | voltage set on supply. read_voltage(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | voltage read from supply. value: unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 34b7476f76592e9226269d3b02886646193836d024fce656135de8c230c8119c +# +# +# +# +# definition for a magnetic kicker. +# +# extended description of the kicker. +# +# +# define position of beamline element relative to production target +# +# +# kicker timing as defined by ``description`` attribute +# +# +# +# current set on supply. +# +# +# current read from supply. +# +# +# +# voltage set on supply. +# +# +# voltage read from supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXquadric.yaml b/contributed_definitions/nyaml/NXquadric.yaml index a981f3254c..f220b55003 100644 --- a/contributed_definitions/nyaml/NXquadric.yaml +++ b/contributed_definitions/nyaml/NXquadric.yaml @@ -1,12 +1,11 @@ category: base -doc: | +doc: | definition of a quadric surface. - type: group NXquadric(NXobject): parameters(NX_NUMBER): unit: NX_PER_LENGTH - doc: | + doc: | Ten real values of the matrix that defines the quadric surface in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, P2, P3, R. Takes a units attribute of dimension reciprocal @@ -17,11 +16,102 @@ NXquadric(NXobject): dim: [[1, 10]] surface_type: exists: ['min', '0', 'max', '1'] - doc: | - An optional description of the form of the quadric surface':' + doc: | + An optional description of the form of the quadric surface: enumeration: [ELLIPSOID, ELLIPTIC_PARABOLOID, HYPERBOLIC_PARABOLOID, ELLIPTIC_HYPERBOLOID_OF_1_SHEET, ELLIPTIC_HYPERBOLOID_OF_2_SHEETS, ELLIPTIC_CONE, ELLIPTIC_CYLINDER, HYPERBOLIC_CYLINDER, PARABOLIC_CYLINDER, SPHEROID, SPHERE, PARABOLOID, HYPERBOLOID_1_SHEET, HYPERBOLOID_2_SHEET, CONE, CYLINDER, PLANE, IMAGINARY, UNKNOWN] depends_on(NX_CHAR): exists: ['min', '0', 'max', '1'] - doc: | - Path to an ':'ref':'`NXtransformations` that defining the axis on + doc: | + Path to an :ref:`NXtransformations` that defining the axis on which the orientation of the surface depends. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 267b94fd8c62dec6dbb2c835d40cda184ec544f98b054c545c067c0206a6680f +# +# +# +# +# definition of a quadric surface. +# +# +# Ten real values of the matrix that defines the quadric surface +# in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, +# P2, P3, R. Takes a units attribute of dimension reciprocal +# length. R is scalar. P has dimension reciprocal length, and the +# given units. Q has dimension reciprocal length squared, and +# units the square of those given. +# +# +# +# +# +# +# +# An optional description of the form of the quadric surface: +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Path to an :ref:`NXtransformations` that defining the axis on +# which the orientation of the surface depends. +# +# +# diff --git a/contributed_definitions/nyaml/NXquadrupole_magnet.yaml b/contributed_definitions/nyaml/NXquadrupole_magnet.yaml index 676efccfc9..62bec22844 100644 --- a/contributed_definitions/nyaml/NXquadrupole_magnet.yaml +++ b/contributed_definitions/nyaml/NXquadrupole_magnet.yaml @@ -1,31 +1,84 @@ category: base -doc: | +doc: | definition for a quadrupole magnet. - type: group NXquadrupole_magnet(NXobject): description(NX_CHAR): - doc: | + doc: | extended description of the magnet. beamline_distance(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | define position of beamline element relative to production target set_current(NX_FLOAT): unit: NX_CURRENT exists: ['min', '0', 'max', '1'] - doc: | + doc: | current set on supply. read_current(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | current read from supply. value: unit: NX_CURRENT read_voltage(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | voltage read from supply. value: unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 87dac0535ae7038f0b632b817a8a67683a20a6257cea6283e449a7b8bd0f3587 +# +# +# +# +# definition for a quadrupole magnet. +# +# extended description of the magnet. +# +# +# define position of beamline element relative to production target +# +# +# current set on supply. +# +# +# current read from supply. +# +# +# +# voltage read from supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXregion.yaml b/contributed_definitions/nyaml/NXregion.yaml index eda7ebba72..b074a5f157 100644 --- a/contributed_definitions/nyaml/NXregion.yaml +++ b/contributed_definitions/nyaml/NXregion.yaml @@ -1,40 +1,40 @@ category: base -doc: | - Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, ':'ref':'`NXdetector`. +doc: | + Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. This can be used to describe a subset of data used to create downsampled data or to derive some data from that subset. Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters - (see https':'//portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** ':'math':'`= 1`, - then **stride** ':'math':'`\equiv` **step** in Python slicing. + (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, + then **stride** :math:`\equiv` **step** in Python slicing. - For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data':'':' + For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: - detector':'NXdetector/ + detector:NXdetector/ data[60,256,512] - region':'NXregion/ + region:NXregion/ @region_type = "rectangular" parent = "data" start = [20,50] count = [220,120] - statistics':'NXdata/ + statistics:NXdata/ @signal = "sum" sum[60] the ``sum`` dataset contains the summed areas in each frame. - Another example, a hyperspectral image downsampled 16-fold in energy':'':' + Another example, a hyperspectral image downsampled 16-fold in energy:: - detector':'NXdetector/ + detector:NXdetector/ data[128,128,4096] - region':'NXregion/ + region:NXregion/ @region_type = "rectangular" parent = "data" start = [2] count = [20] stride = [32] block = [16] - downsampled':'NXdata/ + downsampled:NXdata/ @signal = "maximum" @auxiliary_signals = "copy" maximum[128,128,20] @@ -43,43 +43,39 @@ doc: | the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, the ``maximum`` dataset will show maximum values in each 16-channel block in every spectra. - -symbols: - doc: | +symbols: + doc: | These symbols will denote how the shape of the parent group's data field, - .. math':'':' (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) + .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) - could be split into a left set of **O** outer dimensions, ':'math':'`\boldsymbol{D}`, - and a right set of **R** region dimensions, ':'math':'`\boldsymbol{d}`, - where the data field has rank **O** + **R**. Note **O** ':'math':'`>= 0`. - - O: | + could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, + and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, + where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. + O: | Outer rank - - R: | + R: | Region rank - type: group NXregion(NXobject): \@region_type: exists: optional - doc: | + doc: | This is ``rectangular`` to describe the region as a hyper-rectangle in the index space of its parent group's data field. enumeration: [rectangular] parent: - doc: | + doc: | The name of data field in the parent group or the path of a data field relative to the parent group (so it could be a field in a subgroup of the parent group) parent_mask: - doc: | - The name of an optional mask field in the parent group with rank ':'math':'`\boldsymbol{R}` and - dimensions ':'math':'`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an - ':'ref':'`NXdetector`. + doc: | + The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and + dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an + :ref:`NXdetector`. start(NX_NUMBER): exists: recommended - doc: | + doc: | The starting position for region in detector data field array. This is recommended as it also defines the region rank. If omitted then defined as an array of zeros. @@ -88,7 +84,7 @@ NXregion(NXobject): dim: [[1, R]] count(NX_INT): exists: recommended - doc: | + doc: | The number of blocks or items in the hyperslab selection. If omitted then defined as an array of dimensions that take into account the other hyperslab selection fields to span the parent data field's shape. @@ -96,16 +92,16 @@ NXregion(NXobject): rank: 1 dim: [[1, R]] stride(NX_INT): - doc: | + doc: | An optional field to define striding used to downsample data. If omitted then defined as an array of ones. dimensions: rank: 1 dim: [[1, R]] block(NX_INT): - doc: | + doc: | An optional field to define the block size used to copy or downsample data. In the - ':'math':'`i`-th dimension, if ':'math':'`\mathbf{block}[i] < \mathbf{stride}[i]` + :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` then the blocks are contiguous; otherwise the blocks overlap. If omitted then defined as an array of ones. @@ -113,36 +109,232 @@ NXregion(NXobject): rank: 1 dim: [[1, R]] scale(NX_NUMBER): - doc: | + doc: | An optional field to define a divisor for scaling of reduced data. For example, in a downsampled sum, it can reduce the maximum values to fit in the domain of the result data type. In an image that is downsampled by summing 2x2 blocks, using - ':'math':'`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as + :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as the parent dataset. If omitted then no scaling occurs. dimensions: rank: 1 dim: [[1, R]] downsampled(NXdata): - doc: | + doc: | An optional group containing data copied/downsampled from parent group’s data. Its dataset name must reflect how the downsampling is done over each block. So it could be a reduction operation such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each block then use "copy" as the name. Where more than one downsample dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, - the field should have a shape of ':'math':'`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, - otherwise the expected shape is ':'math':'`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. + the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, + otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. - The following figure shows how blocks are used in downsampling':' + The following figure shows how blocks are used in downsampling: - .. figure':'':' region/NXregion-example.png - ':'width':' 60% + .. figure:: region/NXregion-example.png + :width: 60% - A selection with ':'math':'`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from + A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. statistics(NXdata): - doc: | + doc: | An optional group containing any statistics derived from the region in parent group’s data such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` - listing the others. All data fields should have shapes of ':'math':'`\boldsymbol{D}`. + listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8426e78db8c7bfc828d27cea0e29c7cc255b78f1ca7e809672cb6b0174497dd0 +# +# +# +# +# +# +# These symbols will denote how the shape of the parent group's data field, +# +# .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) +# +# could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, +# and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, +# where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. +# +# Outer rank +# Region rank +# +# +# Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. +# +# This can be used to describe a subset of data used to create downsampled data or to derive +# some data from that subset. +# +# Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters +# (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, +# then **stride** :math:`\equiv` **step** in Python slicing. +# +# For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: +# +# detector:NXdetector/ +# data[60,256,512] +# region:NXregion/ +# @region_type = "rectangular" +# parent = "data" +# start = [20,50] +# count = [220,120] +# statistics:NXdata/ +# @signal = "sum" +# sum[60] +# +# the ``sum`` dataset contains the summed areas in each frame. +# Another example, a hyperspectral image downsampled 16-fold in energy:: +# +# detector:NXdetector/ +# data[128,128,4096] +# region:NXregion/ +# @region_type = "rectangular" +# parent = "data" +# start = [2] +# count = [20] +# stride = [32] +# block = [16] +# downsampled:NXdata/ +# @signal = "maximum" +# @auxiliary_signals = "copy" +# maximum[128,128,20] +# copy[128,128,320] +# +# the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, +# the ``maximum`` dataset will show maximum values in each 16-channel block +# in every spectra. +# +# +# +# This is ``rectangular`` to describe the region as a hyper-rectangle in +# the index space of its parent group's data field. +# +# +# +# +# +# +# +# The name of data field in the parent group or the path of a data field relative +# to the parent group (so it could be a field in a subgroup of the parent group) +# +# +# +# +# The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and +# dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an +# :ref:`NXdetector`. +# +# +# +# +# The starting position for region in detector data field array. +# This is recommended as it also defines the region rank. +# If omitted then defined as an array of zeros. +# +# +# +# +# +# +# +# The number of blocks or items in the hyperslab selection. +# If omitted then defined as an array of dimensions that take into account +# the other hyperslab selection fields to span the parent data field's shape. +# +# +# +# +# +# +# +# An optional field to define striding used to downsample data. +# If omitted then defined as an array of ones. +# +# +# +# +# +# +# +# An optional field to define the block size used to copy or downsample data. In the +# :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` +# then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` +# then the blocks are contiguous; otherwise the blocks overlap. +# If omitted then defined as an array of ones. +# +# +# +# +# +# +# +# An optional field to define a divisor for scaling of reduced data. For example, in a +# downsampled sum, it can reduce the maximum values to fit in the domain of the result +# data type. In an image that is downsampled by summing 2x2 blocks, using +# :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as +# the parent dataset. +# If omitted then no scaling occurs. +# +# +# +# +# +# +# +# An optional group containing data copied/downsampled from parent group’s data. Its dataset name +# must reflect how the downsampling is done over each block. So it could be a reduction operation +# such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each +# block then use "copy" as the name. Where more than one downsample dataset is written +# (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, +# the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, +# otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. +# +# The following figure shows how blocks are used in downsampling: +# +# .. figure:: region/NXregion-example.png +# :width: 60% +# +# A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from +# a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. +# +# +# +# +# +# An optional group containing any statistics derived from the region in parent group’s data +# such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one +# statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` +# listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. +# +# +# diff --git a/contributed_definitions/nyaml/NXseparator.yaml b/contributed_definitions/nyaml/NXseparator.yaml index 16bee40620..f3d94ab6ac 100644 --- a/contributed_definitions/nyaml/NXseparator.yaml +++ b/contributed_definitions/nyaml/NXseparator.yaml @@ -1,48 +1,108 @@ category: base -doc: | +doc: | definition for an electrostatic separator. - type: group NXseparator(NXobject): description(NX_CHAR): - doc: | + doc: | extended description of the separator. beamline_distance(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | define position of beamline element relative to production target set_Bfield_current(NX_FLOAT): unit: NX_CURRENT exists: ['min', '0', 'max', '1'] - doc: | + doc: | current set on magnet supply. read_Bfield_current(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | current read from magnet supply. value: unit: NX_CURRENT read_Bfield_voltage(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | voltage read from magnet supply. value: unit: NX_VOLTAGE set_Efield_voltage(NX_FLOAT): unit: NX_VOLTAGE exists: ['min', '0', 'max', '1'] - doc: | + doc: | current set on HT supply. read_Efield_current(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | current read from HT supply. value: unit: NX_CURRENT read_Efield_voltage(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | voltage read from HT supply. value: unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0221be104fb3192c4a5b942ad422bee251f3519e222030df39dbc3acf85b4fc4 +# +# +# +# +# definition for an electrostatic separator. +# +# extended description of the separator. +# +# +# define position of beamline element relative to production target +# +# +# current set on magnet supply. +# +# +# current read from magnet supply. +# +# +# +# voltage read from magnet supply. +# +# +# +# current set on HT supply. +# +# +# current read from HT supply. +# +# +# +# voltage read from HT supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXsnsevent.yaml b/contributed_definitions/nyaml/NXsnsevent.yaml index 5f4d9f8531..dae92ff25b 100644 --- a/contributed_definitions/nyaml/NXsnsevent.yaml +++ b/contributed_definitions/nyaml/NXsnsevent.yaml @@ -1,20 +1,20 @@ category: application -doc: | +doc: | This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. - type: group NXsnsevent(NXobject): (NXentry): exists: ['min', '1'] (NXcollection)DASlogs: - doc: | + doc: | Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). (NXlog): exists: ['min', '1'] average_value(NX_FLOAT): average_value_error(NX_FLOAT): exists: optional - deprecated: see https':'//github.com/nexusformat/definitions/issues/821 + deprecated: + see https://github.com/nexusformat/definitions/issues/821 average_value_errors(NX_FLOAT): description: duration(NX_FLOAT): @@ -30,12 +30,13 @@ NXsnsevent(NXobject): dim: [[1, nvalue]] (NXpositioner): exists: ['min', '0'] - doc: | + doc: | Motor logs from cvinfo file. average_value(NX_FLOAT): average_value_error(NX_FLOAT): exists: optional - deprecated: see https':'//github.com/nexusformat/definitions/issues/821 + deprecated: + see https://github.com/nexusformat/definitions/issues/821 average_value_errors(NX_FLOAT): description: duration(NX_FLOAT): @@ -54,13 +55,15 @@ NXsnsevent(NXobject): SNSmapping_file_name: author: command1: - doc: | + doc: | Command string for event2nxl. date: description: version: (NXdata): exists: ['min', '1'] + + # for all NXdata/banks data_x_y(link): target: /NXentry/NXinstrument/NXdetector/data_x_y x_pixel_offset(link): @@ -69,6 +72,8 @@ NXsnsevent(NXobject): target: /NXentry/NXinstrument/NXdetector/y_pixel_offset (NXevent_data): exists: ['min', '1'] + + # for all NXdata/banks event_index(link): target: /NXentry/NXinstrument/NXdetector/event_index event_pixel_id(link): @@ -80,7 +85,7 @@ NXsnsevent(NXobject): collection_identifier: collection_title: definition: - doc: | + doc: | Official NXDL schema after this file goes to applications. enumeration: [NXsnsevent] duration(NX_FLOAT): @@ -96,20 +101,26 @@ NXsnsevent(NXobject): probe: type: SNSdetector_calibration_id: - doc: | + doc: | Detector calibration id from DAS. SNSgeometry_file_name: + + # SNSnxtranslate SNStranslation_service: (NXdetector): exists: ['min', '1'] + + # for all NXdetector/banks azimuthal_angle(NX_FLOAT): unit: NX_ANGLE dimensions: rank: 2 dim: [[1, numx], [2, numy]] data_x_y(NX_UINT): - doc: | + doc: | expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" + + # axes are set in data files dimensions: rank: 2 dim: [[1, numx], [2, numy]] @@ -134,7 +145,7 @@ NXsnsevent(NXobject): (NXgeometry)origin: (NXorientation)orientation: value(NX_FLOAT): - doc: | + doc: | Six out of nine rotation parameters. dimensions: rank: 1 @@ -200,7 +211,7 @@ NXsnsevent(NXobject): (NXgeometry)origin: (NXorientation)orientation: value(NX_FLOAT): - doc: | + doc: | Six out of nine rotation parameters. dimensions: rank: 1 @@ -225,15 +236,19 @@ NXsnsevent(NXobject): exists: ['min', '0'] distance(NX_FLOAT): unit: NX_LENGTH + + # motor links from DASlogs when exist (NXpolarizer): exists: ['min', '0'] + + # motor links from DASlogs when exist (NXcrystal): exists: ['min', '0'] (NXgeometry)origin: description: (NXorientation)orientation: value(NX_FLOAT): - doc: | + doc: | Six out of nine rotation parameters. dimensions: rank: 1 @@ -255,7 +270,7 @@ NXsnsevent(NXobject): (NXmonitor): exists: ['min', '0'] data(NX_UINT): - doc: | + doc: | expect ``signal=1 axes="time_of_flight"`` dimensions: rank: 1 @@ -278,7 +293,7 @@ NXsnsevent(NXobject): holder: identifier: name: - doc: | + doc: | Descriptive name of sample nature: start_time(NX_DATE_TIME): @@ -292,3 +307,334 @@ NXsnsevent(NXobject): facility_user_id: name: role: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5c4b685e1799791496ef54d585f15144de4b9a3fd442811acae7f43aadc3dd34 +# +# +# +# +# This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. +# +# +# +# Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Motor logs from cvinfo file. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Command string for event2nxl. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Official NXDL schema after this file goes to applications. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Detector calibration id from DAS. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# expect ``signal=1 axes="time_of_flight"`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsnshisto.yaml b/contributed_definitions/nyaml/NXsnshisto.yaml index 41396a75b7..adbb825170 100644 --- a/contributed_definitions/nyaml/NXsnshisto.yaml +++ b/contributed_definitions/nyaml/NXsnshisto.yaml @@ -1,20 +1,20 @@ category: application -doc: | +doc: | This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. - type: group NXsnshisto(NXobject): (NXentry): exists: ['min', '1'] (NXcollection)DASlogs: - doc: | + doc: | Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). (NXlog): exists: ['min', '1'] average_value(NX_FLOAT): average_value_error(NX_FLOAT): exists: optional - deprecated: see https':'//github.com/nexusformat/definitions/issues/821 + deprecated: + see https://github.com/nexusformat/definitions/issues/821 average_value_errors(NX_FLOAT): description: duration(NX_FLOAT): @@ -30,12 +30,13 @@ NXsnshisto(NXobject): dim: [[1, nvalue]] (NXpositioner): exists: ['min', '0'] - doc: | + doc: | Motor logs from cvinfo file. average_value(NX_FLOAT): average_value_error(NX_FLOAT): exists: optional - deprecated: see https':'//github.com/nexusformat/definitions/issues/821 + deprecated: + see https://github.com/nexusformat/definitions/issues/821 average_value_errors(NX_FLOAT): description: duration(NX_FLOAT): @@ -54,13 +55,15 @@ NXsnshisto(NXobject): SNSmapping_file_name: author: command1: - doc: | + doc: | Command string for event2histo_nxl. date: description: version: (NXdata): exists: ['min', '1'] + + # for all NXdata/banks data(link): target: /NXentry/NXinstrument/NXdetector/data data_x_time_of_flight(link): @@ -82,7 +85,7 @@ NXsnshisto(NXobject): collection_identifier: collection_title: definition: - doc: | + doc: | Official NXDL schema after this file goes to applications. enumeration: [NXsnshisto] duration(NX_FLOAT): @@ -98,12 +101,16 @@ NXsnshisto(NXobject): probe: type: SNSdetector_calibration_id: - doc: | + doc: | Detector calibration id from DAS. SNSgeometry_file_name: + + # SNSnxtranslate SNStranslation_service: (NXdetector): exists: ['min', '1'] + + # for all NXdetector/banks azimuthal_angle(NX_FLOAT): unit: NX_ANGLE dimensions: @@ -141,7 +148,7 @@ NXsnshisto(NXobject): (NXgeometry)origin: (NXorientation)orientation: value(NX_FLOAT): - doc: | + doc: | Six out of nine rotation parameters. dimensions: rank: 1 @@ -194,7 +201,7 @@ NXsnshisto(NXobject): beamline: (NXdisk_chopper): exists: ['min', '0'] - doc: | + doc: | Original specification called for NXchopper, which is not a valid NeXus base class. Select either NXdisk_chopper or NXfermi_chopper, as appropriate. @@ -202,7 +209,7 @@ NXsnshisto(NXobject): unit: NX_LENGTH (NXfermi_chopper): exists: ['min', '0'] - doc: | + doc: | Original specification called for NXchopper, which is not a valid NeXus base class. Select either NXdisk_chopper or NXfermi_chopper, as appropriate. @@ -221,7 +228,7 @@ NXsnshisto(NXobject): (NXgeometry)origin: (NXorientation)orientation: value(NX_FLOAT): - doc: | + doc: | Six out of nine rotation parameters. dimensions: rank: 1 @@ -246,15 +253,19 @@ NXsnshisto(NXobject): exists: ['min', '0'] distance(NX_FLOAT): unit: NX_LENGTH + + # motor links from DASlogs when exist (NXpolarizer): exists: ['min', '0'] + + # motor links from DASlogs when exist (NXcrystal): exists: ['min', '0'] (NXgeometry)origin: description: (NXorientation)orientation: value(NX_FLOAT): - doc: | + doc: | Six out of nine rotation parameters. dimensions: rank: 1 @@ -299,7 +310,7 @@ NXsnshisto(NXobject): holder: identifier: name: - doc: | + doc: | Descriptive name of sample nature: start_time(NX_DATE_TIME): @@ -313,3 +324,347 @@ NXsnshisto(NXobject): facility_user_id: name: role: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 416fcb00afa79775d07f92148b37bcc4250c622609ced0374cc7490a7349ee25 +# +# +# +# +# This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. +# +# +# +# Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Motor logs from cvinfo file. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Command string for event2histo_nxl. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Official NXDL schema after this file goes to applications. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Detector calibration id from DAS. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Original specification called for NXchopper, +# which is not a valid NeXus base class. +# Select either NXdisk_chopper or NXfermi_chopper, as appropriate. +# +# +# +# +# +# Original specification called for NXchopper, +# which is not a valid NeXus base class. +# Select either NXdisk_chopper or NXfermi_chopper, as appropriate. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsolenoid_magnet.yaml b/contributed_definitions/nyaml/NXsolenoid_magnet.yaml index 33404b2ade..ae5f355fa5 100644 --- a/contributed_definitions/nyaml/NXsolenoid_magnet.yaml +++ b/contributed_definitions/nyaml/NXsolenoid_magnet.yaml @@ -1,31 +1,84 @@ category: base -doc: | +doc: | definition for a solenoid magnet. - type: group NXsolenoid_magnet(NXobject): description(NX_CHAR): - doc: | + doc: | extended description of the magnet. beamline_distance(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | define position of beamline element relative to production target set_current(NX_FLOAT): unit: NX_CURRENT exists: ['min', '0', 'max', '1'] - doc: | + doc: | current set on supply. read_current(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | current read from supply. value: unit: NX_CURRENT read_voltage(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | voltage read from supply. value: unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1364b1b892354a667957c67d8d4d7b6ebb5f1a1bd7fc2dc5876622ed45239995 +# +# +# +# +# definition for a solenoid magnet. +# +# extended description of the magnet. +# +# +# define position of beamline element relative to production target +# +# +# current set on supply. +# +# +# current read from supply. +# +# +# +# voltage read from supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXsolid_geometry.yaml b/contributed_definitions/nyaml/NXsolid_geometry.yaml index 752ebdee2d..3d752e4626 100644 --- a/contributed_definitions/nyaml/NXsolid_geometry.yaml +++ b/contributed_definitions/nyaml/NXsolid_geometry.yaml @@ -1,18 +1,76 @@ category: base -doc: | +doc: | the head node for constructively defined geometry - type: group NXsolid_geometry(NXobject): (NXquadric): exists: ['min', '0'] - doc: | - Instances of ':'ref':'`NXquadric` making up elements of the geometry. + doc: | + Instances of :ref:`NXquadric` making up elements of the geometry. (NXoff_geometry): exists: ['min', '0'] - doc: | - Instances of ':'ref':'`NXoff_geometry` making up elements of the geometry. + doc: | + Instances of :ref:`NXoff_geometry` making up elements of the geometry. (NXcsg): exists: ['min', '0'] - doc: | - The geometries defined, made up of instances of ':'ref':'`NXquadric` and ':'ref':'`NXoff_geometry`. + doc: | + The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 71a1b3ca39b88fdae9499a10284ddc6fd89423b5d2e3e1d544bacfa3793bb5c0 +# +# +# +# +# +# the head node for constructively defined geometry +# +# +# +# Instances of :ref:`NXquadric` making up elements of the geometry. +# +# +# +# +# Instances of :ref:`NXoff_geometry` making up elements of the geometry. +# +# +# +# +# The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. +# +# +# diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml index 36011b808b..198e3b928d 100644 --- a/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml @@ -1,8 +1,19 @@ category: base -doc: | +doc: | Container for reporting a set of auger electron energy spectra. - type: group (NXobject)NXspectrum_set_em_auger: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# eaf9e6b72cc5c4cc91bcb6198acbc2cf74dcc00d16469feb27aeb92b41d35924 +# +# +# +# +# Container for reporting a set of auger electron energy spectra. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml index cf1a0ddf76..635cac8f74 100644 --- a/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml @@ -1,8 +1,19 @@ category: base -doc: | +doc: | Container for reporting a set of cathodoluminescence spectra. - type: group (NXobject)NXspectrum_set_em_cathodolum: (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 90fc581369c8fbf7c59f4066e6dc149890981b03400042962d78acd505535563 +# +# +# +# +# Container for reporting a set of cathodoluminescence spectra. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXspin_rotator.yaml b/contributed_definitions/nyaml/NXspin_rotator.yaml index d803f925ba..8cdf66348c 100644 --- a/contributed_definitions/nyaml/NXspin_rotator.yaml +++ b/contributed_definitions/nyaml/NXspin_rotator.yaml @@ -1,48 +1,108 @@ category: base -doc: | +doc: | definition for a spin rotator. - type: group NXspin_rotator(NXobject): description(NX_CHAR): - doc: | + doc: | extended description of the spin rotator. beamline_distance(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | define position of beamline element relative to production target set_Bfield_current(NX_FLOAT): unit: NX_CURRENT exists: ['min', '0', 'max', '1'] - doc: | + doc: | current set on magnet supply. read_Bfield_current(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | current read from magnet supply. value: unit: NX_CURRENT read_Bfield_voltage(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | voltage read from magnet supply. value: unit: NX_VOLTAGE set_Efield_voltage(NX_FLOAT): unit: NX_VOLTAGE exists: ['min', '0', 'max', '1'] - doc: | + doc: | current set on HT supply. read_Efield_current(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | current read from HT supply. value: unit: NX_CURRENT read_Efield_voltage(NXlog): exists: ['min', '0', 'max', '1'] - doc: | + doc: | voltage read from HT supply. value: unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 260f697bca7fcdb6e806e85e0cb1459de350eab0f1eb633c5b15ac31d38c1572 +# +# +# +# +# definition for a spin rotator. +# +# extended description of the spin rotator. +# +# +# define position of beamline element relative to production target +# +# +# current set on magnet supply. +# +# +# current read from magnet supply. +# +# +# +# voltage read from magnet supply. +# +# +# +# current set on HT supply. +# +# +# current read from HT supply. +# +# +# +# voltage read from HT supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXxpcs.yaml b/contributed_definitions/nyaml/NXxpcs.yaml index 0fff97948a..20dd211c91 100644 --- a/contributed_definitions/nyaml/NXxpcs.yaml +++ b/contributed_definitions/nyaml/NXxpcs.yaml @@ -1,5 +1,5 @@ category: application -doc: | +doc: | X-ray Photon Correlation Spectroscopy (XPCS) data (results). The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data @@ -8,104 +8,104 @@ doc: | community acceptance. Additional fields may be added to XPCS results file (either formally or informally). It is expected - that this XPCS data will be part of multi-modal data set that could involve e.g., ':'ref':'`NXcanSAS` or + that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or 1D and/or 2D data. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXxpcs(NXobject): (NXentry)entry: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxpcs] entry_identifier: - doc: | + doc: | **Locally** unique identifier for the experiment (a.k.a. run or scan). * For bluesky users, this is the run's `"scan_id"`. * For SPEC users, this is the scan number (``SCAN_N``). entry_identifier_uuid: exists: ['min', '0', 'max', '1'] - doc: | + doc: | (optional) UUID identifier for this entry. - See the `UUID standard `__ (or - `wikipedia `__) + See the `UUID standard `__ (or + `wikipedia `__) for more information. - * For `bluesky `__ users, this is the + * For `bluesky `__ users, this is the run's `"uid"` and is expected for that application. - * Typically, `SPEC `__ users will + * Typically, `SPEC `__ users will not use this field without further engineering. scan_number(NX_INT): deprecated: Use the ``entry_identifier`` field. - doc: | + + # Use of "deprecated" is to advise the XPCS authors of this change. + # The `scan_number` field will be removed by 2022-12-31. + doc: | Scan number (must be an integer). - NOTE':' Link to collection_identifier. + NOTE: Link to collection_identifier. start_time(NX_DATE_TIME): - doc: | - Starting time of experiment, such as "2021-02-11 11':'22':'33.445566Z". + doc: | + Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". end_time(NX_DATE_TIME): exists: ['min', '0', 'max', '1'] - doc: | - Ending time of experiment, such as "2021-02-11 11':'23':'45Z". + doc: | + Ending time of experiment, such as "2021-02-11 11:23:45Z". (NXdata)data: - doc: | + doc: | The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) describing on-equilibrium dynamics consume more memory resources so these data are separated. frame_sum(NX_NUMBER): unit: NX_COUNT exists: ['min', '0', 'max', '1'] - doc: | + doc: | Two-dimensional summation along the frames stack. sum of intensity v. time (in the units of "frames") frame_average(NX_NUMBER): unit: NX_COUNT exists: ['min', '0', 'max', '1'] - doc: | + doc: | Two-dimensional average along the frames stack. average intensity v. time (in the units of "frames") g2(NX_NUMBER): unit: NX_DIMENSIONLESS exists: ['min', '0', 'max', '1'] - doc: | + doc: | normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 - .. math':'':' g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 + .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 - Typically, ':'math':'`g_2` is a quantity calculated for a group of pixels representing a specific - region of reciprocal space. These groupings, or bins, are generically described as ':'math':'`q`. Some + Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific + region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some open-source XPCS libraries refer to these bins as "rois", which are not to be confused with EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ - In short, ':'math':'`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if + In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats':' + of the following two formats: - * iterable list of linked files (or keys) for each ':'math':'`g_2` with 1 file (key) per ':'math':'`q`, where `q` is called by the nth roi_map value - * 2D array [#]_ with shape (':'math':'`g_2`, ':'math':'`q`), where `q` is represented by the nth roi_map value, not the value `q` value + * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value + * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value Note it is expected that "g2" and all quantities following it will be of the same length. Other formats are acceptable with sufficient axes description. - See references below for related implementation information':' + See references below for related implementation information: - .. [#] mask':' ``NXxpcs':'/entry/instrument/masks-group`` - .. [#] NeXus 2-D data and axes':' https':'//manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata + .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` + .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata \@storage_mode: type: NX_CHAR - doc: | + doc: | storage_mode describes the format of the data to be loaded We encourage the documentation of other formats not represented here. @@ -116,18 +116,18 @@ NXxpcs(NXobject): g2_derr(NX_NUMBER): unit: NX_DIMENSIONLESS exists: ['min', '0', 'max', '1'] - doc: | - error values for the ':'math':'`g_2` values. + doc: | + error values for the :math:`g_2` values. The derivation of the error is left up to the implemented code. Symmetric error will be - expected (':'math':'`\pm` error). The data should be in the same format as ``g2``. + expected (:math:`\pm` error). The data should be in the same format as ``g2``. \@storage_mode: type: NX_CHAR enumeration: [one_array, data_exchange_keys, other] G2_unnormalized(NX_NUMBER): unit: NX_ANY exists: ['min', '0', 'max', '1'] - doc: | + doc: | unnormalized intensity auto-correlation function. Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. @@ -137,7 +137,7 @@ NXxpcs(NXobject): delay_difference(NX_INT): unit: NX_COUNT exists: ['min', '0', 'max', '1'] - doc: | + doc: | delay_difference (also known as delay or lag step) This is quantized difference so that the "step" between two consecutive @@ -146,31 +146,31 @@ NXxpcs(NXobject): It is the "quantized" delay time corresponding to the ``g2`` values. The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, - refer to ':'ref':'`NXdetector` for conversion to time units. + refer to :ref:`NXdetector` for conversion to time units. \@storage_mode: type: NX_CHAR enumeration: [one_array, data_exchange_keys, other] (NXdata)twotime: exists: ['min', '0'] - doc: | + doc: | The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. two_time_corr_func(NX_NUMBER): unit: NX_ANY exists: ['min', '0', 'max', '1'] - doc: | + doc: | two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early - description applied to X-ray scattering':' + description applied to X-ray scattering: - .. math':'':' C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } + .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } in which time is quantized by frames. In principle, any data format is acceptable if the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats':' + of the following two formats: * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array - * 3D array with shape (frames, frames, q) or (q, frames, frames), where ':'math':'`q` is represented by the nth roi_map value, not the value `q` value + * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value The computation of this result can be customized. These customizations can affect subsequently derived results (below). The @@ -180,20 +180,20 @@ NXxpcs(NXobject): definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. * The various software libraries use different programming languages. Therefore, we need to - specify the ``time = 0`` origin location of the 2D array for each ':'math':'`q`. + specify the ``time = 0`` origin location of the 2D array for each :math:`q`. * A method to reduce data storage needs is to only record half of the 2D array by populating array elements above or below the array diagonal. \@storage_mode: type: NX_CHAR - doc: | + doc: | storage_mode describes the format of the data to be loaded We encourage the documention of other formats represented here. enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] \@baseline_reference: type: NX_INT - doc: | + doc: | baseline is the expected value of a full decorrelation The baseline is a constant value added to the functional form of the auto-correlation @@ -201,27 +201,27 @@ NXxpcs(NXobject): enumeration: [0, 1] \@time_origin_location: type: NX_CHAR - doc: | + doc: | time_origin_location is the location of the origin enumeration: [upper_left, lower_left] \@populated_elements: type: NX_CHAR - doc: | + doc: | populated_elements describe the elements of the 2D array that are populated with data enumeration: [all, upper_half, lower_half] g2_from_two_time_corr_func(NX_NUMBER): unit: NX_DIMENSIONLESS exists: ['min', '0', 'max', '1'] - doc: | + doc: | frame weighted average along the diagonal direction in ``two_time_corr_func`` The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" - * iterable list of linked files for each ':'math':'`g_2` with 1 file per ':'math':'`q` - * 2D array with shape (':'math':'`g_2`, ':'math':'`q`) + * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` + * 2D array with shape (:math:`g_2`, :math:`q`) Note that delay_difference is not included here because it is derived from the shape of - extracted ':'math':'`g_2` because all frames are considered, which is not necessarily the case for ':'math':'`g_2`. + extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The following attributes will be used to manage the customization. @@ -233,7 +233,7 @@ NXxpcs(NXobject): enumeration: [0, 1] \@first_point_for_fit: type: NX_INT - doc: | + doc: | first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. The first_point_for_fit is True ("1") or False ("0"). This value is required. @@ -241,30 +241,30 @@ NXxpcs(NXobject): g2_err_from_two_time_corr_func(NX_NUMBER): unit: NX_DIMENSIONLESS exists: ['min', '0', 'max', '1'] - doc: | - error values for the ':'math':'`g_2` values. + doc: | + error values for the :math:`g_2` values. The derivation of the error is left up to the implemented code. Symmetric error will be - expected (':'math':'`\pm` error). + expected (:math:`\pm` error). \@storage_mode: type: NX_CHAR enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] g2_from_two_time_corr_func_partials(NX_NUMBER): unit: NX_DIMENSIONLESS exists: ['min', '0', 'max', '1'] - doc: | + doc: | subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` Time slicing along the diagonal can be very sophisticated. This entry currently assumes equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. In principle, any data format is acceptable if the data and its axes are self describing as per NeXus - recommendations. However, the data is preferred in one of the following two formats':' + recommendations. However, the data is preferred in one of the following two formats: - * iterable list of linked files (or keys) for each partial ':'math':'`g_2` of each q-bin represented by the roi_map value - * 3D array with shape (':'math':'`g_2`, ':'math':'`q`, nth_partial) + * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value + * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) Note that delay_difference is not included here because it is derived from the shape of - extracted ':'math':'`g_2`. + extracted :math:`g_2`. \@storage_mode: type: NX_CHAR enumeration: [one_array, data_exchange_keys, other] @@ -274,13 +274,13 @@ NXxpcs(NXobject): g2_err_from_two_time_corr_func_partials(NX_NUMBER): unit: NX_DIMENSIONLESS exists: ['min', '0', 'max', '1'] - doc: | - error values for the ':'math':'`g_2` values. + doc: | + error values for the :math:`g_2` values. The derivation of the error is left up to the implemented code. Symmetric error will be - expected (':'math':'`\pm` error). + expected (:math:`\pm` error). (NXinstrument)instrument: - doc: | + doc: | XPCS instrument Metadata. Objects can be entered here directly or linked from other @@ -288,17 +288,17 @@ NXxpcs(NXobject): (NXbeam)incident_beam: incident_energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | Incident beam line energy (either keV or eV). incident_energy_spread(NX_FLOAT): unit: NX_ENERGY exists: ['min', '0', 'max', '1'] - doc: | + doc: | Spread of incident beam line energy (either keV or eV). This quantity is otherwise known as the energy resolution, which is related to the longitudinal coherence length. incident_polarization_type: exists: ['min', '0', 'max', '1'] - doc: | + doc: | Terse description of the incident beam polarization. The value can be plain text, such as ``vertical``, ``C+``, @@ -306,10 +306,14 @@ NXxpcs(NXobject): extent(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Size (2-D) of the beam at this position. + + # FIXME: (h, v) or (v, h)? State this in the docs FOR EPICS AD, likeky v, h. But seems CSX is (h,v) if looking + # from the source's perspective at the face of the detector - see fig 11 and fig 12 of cxidb documentation. this + # is also relevant for the next section, which is just describing the 2D array V, H is python/bluesky (NXdetector): - doc: | + doc: | XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes this data is represented in different ways (sparse arrays or photon event list), but this detail is left to the analysis software. Therefore, we only include requirements based on full array data. @@ -320,50 +324,52 @@ NXxpcs(NXobject): the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI documentation (See Fig 11 vs Fig 12). - Additionally, not all ':'ref':'`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to + Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. - .. [#] Coherent X-ray Imaging Data Bank':' https':'//cxidb.org/cxi.html + .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html description: exists: ['min', '0', 'max', '1'] - doc: | + doc: | Detector name. distance(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Distance between sample and detector. count_time(NX_NUMBER): unit: NX_TIME - doc: | + doc: | Exposure time of frames, s. frame_time(NX_NUMBER): unit: NX_TIME - doc: | + doc: | Exposure period (time between frame starts) of frames, s beam_center_x(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | Position of beam center, x axis, in detector's coordinates. beam_center_y(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | Position of beam center, y axis, in detector's coordinates. x_pixel_size(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + + # made this optional in case of single photon xy-time lists + doc: | Length of pixel in x direction. y_pixel_size(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Length of pixel in y direction. (NXnote)masks: exists: ['min', '0', 'max', '1'] - doc: | - Data masks or mappings to regions of interest (roi) for specific ':'math':'`Q` values + doc: | + Data masks or mappings to regions of interest (roi) for specific :math:`Q` values Fields in this ``masks`` group describe regions of interest in the data by either a mask to select pixels or to associate @@ -377,15 +383,15 @@ NXxpcs(NXobject): "Static" refers to finer binning used for computation not strictly used for the final XPCS results. Implementation of _static_ binning is left for individual libraries to - document. We encourage usage of ':'ref':'`NXcanSAS` to represent standard SAXS results or + document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or development of new NeXus definitions for GI-SAXS or other reciprocal space intensity mapping. dynamic_roi_map(NX_NUMBER): unit: NX_DIMENSIONLESS - doc: | + doc: | roi index array or labeled array - The values of this mask index (or map to) the ':'math':'`Q` value from the + The values of this mask index (or map to) the :math:`Q` value from the the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations are performed on all pixels with a value > 0. @@ -394,15 +400,15 @@ NXxpcs(NXobject): dynamic_q_list(NX_NUMBER): unit: NX_PER_LENGTH exists: ['min', '0'] - doc: | - 1-D list of ':'math':'`Q` values, one for each roi index value. + doc: | + 1-D list of :math:`Q` values, one for each roi index value. List order is determined by the index value of the associated roi map starting at ``1``. - The only requirement for the list is that it may be iterable. Some expected formats are':' + The only requirement for the list is that it may be iterable. Some expected formats are: - * iterable list of floats (i.e., ':'math':'`Q(r)`) - * iterable list of tuples (i.e., ':'math':'`Q(r)`, ':'math':'`\varphi`), but preferable use the seperate ':'math':'`\varphi` field below + * iterable list of floats (i.e., :math:`Q(r)`) + * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) * iterable list of integers (for Nth roi_map value) or strings @@ -411,17 +417,17 @@ NXxpcs(NXobject): dynamic_phi_list(NX_NUMBER): unit: NX_PER_LENGTH exists: ['min', '0'] - doc: | - Array of ':'math':'`\varphi` value for each pixel. + doc: | + Array of :math:`\varphi` value for each pixel. List order is determined by the index value of the associated roi map starting at ``1``. static_roi_map(NX_NUMBER): unit: NX_DIMENSIONLESS exists: ['min', '0'] - doc: | + doc: | roi index array. - The values of this mask index the ':'math':'`|Q|` value from the + The values of this mask index the :math:`|Q|` value from the the ``static_q_list`` field. The ``units`` attribute should be set to ``"au"`` @@ -429,19 +435,26 @@ NXxpcs(NXobject): static_q_list(NX_NUMBER): unit: NX_PER_LENGTH exists: ['min', '0'] - doc: | - 1-D list of ':'math':'`|Q|` values, 1 for each roi. + doc: | + 1-D list of :math:`|Q|` values, 1 for each roi. (NXsample)sample: exists: ['min', '0'] + + # Describes the minimum requirements regarding equilibrium sample conditions. NXsample + # permits other quantities (e.g., applied fields, crystallographic information, name, etc) that + # may optionally be include for equilibrium conditions (which is not exclusively equilibrium + # dynamics from XPCS analysis). + # For non-equilibrium sample conditions (i.e., changing sample or process conditions + # during the XPCS measurement) will require either a new entry or an additional atttribute. temperature_set(NX_NUMBER): unit: NX_TEMPERATURE exists: ['min', '0'] - doc: | + doc: | Sample temperature setpoint, (C or K). temperature(NX_NUMBER): unit: NX_TEMPERATURE exists: ['min', '0'] - doc: | + doc: | Sample temperature actual, (C or K). (NXpositioner)position_x: exists: ['min', '0'] @@ -451,15 +464,622 @@ NXxpcs(NXobject): exists: ['min', '0'] (NXnote)NOTE: exists: ['min', '0', 'max', 'unbounded'] - doc: | + doc: | Any other notes. - NAME':' The NeXus convention, to use all upper case + NAME: The NeXus convention, to use all upper case to indicate the name (here ``NOTE``), is left to the file writer. In our case, follow the suggested name - pattern and sequence':' note_1, note_2, note_3, ... + pattern and sequence: note_1, note_2, note_3, ... Start with ``note_1`` if the first one, otherwise pick the next number in this sequence. (NXprocess): - doc: | + doc: | Describe the computation process that produced these results. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 24b656b7be7f0c85955748deed904585a8136c312327d128d6a4a377760052c8 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# X-ray Photon Correlation Spectroscopy (XPCS) data (results). +# +# The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data +# in order to support development of community software tools. The definition presented here only +# represents a starting point and contains fields that a common software tool should support for +# community acceptance. +# +# Additional fields may be added to XPCS results file (either formally or informally). It is expected +# that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or +# 1D and/or 2D data. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# **Locally** unique identifier for the experiment (a.k.a. run or scan). +# +# * For bluesky users, this is the run's `"scan_id"`. +# * For SPEC users, this is the scan number (``SCAN_N``). +# +# +# +# +# (optional) UUID identifier for this entry. +# +# See the `UUID standard <https://www.rfc-editor.org/rfc/rfc4122.html>`__ (or +# `wikipedia <https://en.wikipedia.org/wiki/Universally_unique_identifier>`__) +# for more information. +# +# * For `bluesky <https://blueskyproject.io/>`__ users, this is the +# run's `"uid"` and is expected for that application. +# * Typically, `SPEC <https://certif.com/content/spec/>`__ users will +# not use this field without further engineering. +# +# +# +# +# +# Scan number (must be an integer). +# +# NOTE: Link to collection_identifier. +# +# +# +# +# Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". +# +# +# +# +# Ending time of experiment, such as "2021-02-11 11:23:45Z". +# +# +# +# +# +# The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) +# describing on-equilibrium dynamics consume more memory resources so these data are separated. +# +# +# +# Two-dimensional summation along the frames stack. +# +# sum of intensity v. time (in the units of "frames") +# +# +# +# +# Two-dimensional average along the frames stack. +# +# average intensity v. time (in the units of "frames") +# +# +# +# +# normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 +# +# .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 +# +# Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific +# region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some +# open-source XPCS libraries refer to these bins as "rois", which are not to be confused with +# EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ +# +# In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if +# the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one +# of the following two formats: +# +# * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value +# * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value +# +# Note it is expected that "g2" and all quantities following it will be of the same length. +# +# Other formats are acceptable with sufficient axes description. +# +# See references below for related implementation information: +# +# .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` +# .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata +# +# +# +# storage_mode describes the format of the data to be loaded +# +# We encourage the documentation of other formats not represented here. +# +# * one array representing entire data set ("one_array") +# * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") +# +# +# +# +# +# +# +# +# +# +# error values for the :math:`g_2` values. +# +# The derivation of the error is left up to the implemented code. Symmetric error will be +# expected (:math:`\pm` error). The data should be in the same format as ``g2``. +# +# +# +# +# +# +# +# +# +# +# +# unnormalized intensity auto-correlation function. +# +# Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. +# +# +# +# +# +# +# +# +# +# +# +# +# delay_difference (also known as delay or lag step) +# +# This is quantized difference so that the "step" between two consecutive +# frames is one frame (or step ``= dt = 1 frame``) +# +# It is the "quantized" delay time corresponding to the ``g2`` values. +# +# The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, +# refer to :ref:`NXdetector` for conversion to time units. +# +# +# +# +# +# +# +# +# +# +# +# +# +# The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. +# +# +# +# two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) +# +# See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early +# description applied to X-ray scattering: +# +# .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } +# +# in which time is quantized by frames. In principle, any data format is acceptable if +# the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one +# of the following two formats: +# +# * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array +# * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value +# +# +# The computation of this result can be customized. These customizations can affect subsequently derived results (below). The +# following attributes will be used to manage the customization. +# +# * Other normalization methods may be applied, but the method will not be specified in this +# definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. +# +# * The various software libraries use different programming languages. Therefore, we need to +# specify the ``time = 0`` origin location of the 2D array for each :math:`q`. +# +# * A method to reduce data storage needs is to only record half of the 2D array by populating +# array elements above or below the array diagonal. +# +# +# +# +# +# storage_mode describes the format of the data to be loaded +# +# We encourage the documention of other formats represented here. +# +# +# +# +# +# +# +# +# +# +# baseline is the expected value of a full decorrelation +# +# The baseline is a constant value added to the functional form of the auto-correlation +# function. This value is required. +# +# +# +# +# +# +# +# +# time_origin_location is the location of the origin +# +# +# +# +# +# +# +# +# populated_elements describe the elements of the 2D array that are populated with data +# +# +# +# +# +# +# +# +# +# +# frame weighted average along the diagonal direction in ``two_time_corr_func`` +# +# The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" +# +# * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` +# * 2D array with shape (:math:`g_2`, :math:`q`) +# +# Note that delay_difference is not included here because it is derived from the shape of +# extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. +# +# The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The +# following attributes will be used to manage the customization. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. +# +# The first_point_for_fit is True ("1") or False ("0"). This value is required. +# +# +# +# +# +# +# +# +# +# error values for the :math:`g_2` values. +# +# The derivation of the error is left up to the implemented code. Symmetric error will be +# expected (:math:`\pm` error). +# +# +# +# +# +# +# +# +# +# +# +# +# subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` +# +# Time slicing along the diagonal can be very sophisticated. This entry currently assumes +# equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. +# In principle, any data format is acceptable if the data and its axes are self describing as per NeXus +# recommendations. However, the data is preferred in one of the following two formats: +# +# * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value +# * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) +# +# Note that delay_difference is not included here because it is derived from the shape of +# extracted :math:`g_2`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# error values for the :math:`g_2` values. +# +# The derivation of the error is left up to the implemented code. Symmetric error will be +# expected (:math:`\pm` error). +# +# +# +# +# +# +# XPCS instrument Metadata. +# +# Objects can be entered here directly or linked from other +# objects in the NeXus file (such as within ``/entry/instrument``). +# +# +# +# Incident beam line energy (either keV or eV). +# +# +# +# Spread of incident beam line energy (either keV or eV). This quantity is otherwise known +# as the energy resolution, which is related to the longitudinal coherence length. +# +# +# +# +# Terse description of the incident beam polarization. +# +# The value can be plain text, such as ``vertical``, ``C+``, +# ``circular left``. +# +# +# +# Size (2-D) of the beam at this position. +# +# +# +# +# +# +# XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes +# this data is represented in different ways (sparse arrays or photon event list), but this detail +# is left to the analysis software. Therefore, we only include requirements based on full array data. +# +# We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This +# is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ +# See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and +# the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI +# documentation (See Fig 11 vs Fig 12). +# +# Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to +# convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may +# either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. +# +# .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html +# +# +# Detector name. +# +# +# Distance between sample and detector. +# +# +# Exposure time of frames, s. +# +# +# +# Exposure period (time between frame starts) of frames, s +# +# +# +# +# Position of beam center, x axis, in detector's coordinates. +# +# +# +# +# Position of beam center, y axis, in detector's coordinates. +# +# +# +# +# +# Length of pixel in x direction. +# +# +# +# +# Length of pixel in y direction. +# +# +# +# +# +# +# Data masks or mappings to regions of interest (roi) for specific :math:`Q` values +# +# Fields in this ``masks`` group describe regions of interest +# in the data by either a mask to select pixels or to associate +# a *map* of rois with a (one-dimensional) *list* of values. +# +# "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, +# which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. +# +# "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and +# NXxpcs/entry/two_time. +# +# "Static" refers to finer binning used for computation not strictly used for the final +# XPCS results. Implementation of _static_ binning is left for individual libraries to +# document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or +# development of new NeXus definitions for GI-SAXS or other reciprocal space +# intensity mapping. +# +# +# +# roi index array or labeled array +# +# The values of this mask index (or map to) the :math:`Q` value from the +# the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations +# are performed on all pixels with a value > 0. +# +# The ``units`` attribute should be set to ``"au"`` +# indicating arbitrary units. +# +# +# +# +# 1-D list of :math:`Q` values, one for each roi index value. +# +# List order is determined by the index value of the associated roi map starting at ``1``. +# +# The only requirement for the list is that it may be iterable. Some expected formats are: +# +# * iterable list of floats (i.e., :math:`Q(r)`) +# * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below +# * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) +# * iterable list of integers (for Nth roi_map value) or strings +# +# This format is chosen because results plotting packages are not common and simple I/O is required by end user. +# The lists can be accessed as lists, arrays or via keys +# +# +# +# +# Array of :math:`\varphi` value for each pixel. +# +# List order is determined by the index value of the associated roi map starting at ``1``. +# +# +# +# +# roi index array. +# +# The values of this mask index the :math:`|Q|` value from the +# the ``static_q_list`` field. +# +# The ``units`` attribute should be set to ``"au"`` +# indicating arbitrary units. +# +# +# +# +# 1-D list of :math:`|Q|` values, 1 for each roi. +# +# +# +# +# +# +# +# +# +# Sample temperature setpoint, (C or K). +# +# +# +# +# Sample temperature actual, (C or K). +# +# +# +# +# +# +# +# +# +# Any other notes. +# +# NAME: The NeXus convention, to use all upper case +# to indicate the name (here ``NOTE``), is left to the file +# writer. In our case, follow the suggested name +# pattern and sequence: note_1, note_2, note_3, ... +# Start with ``note_1`` if the first one, otherwise +# pick the next number in this sequence. +# +# +# +# +# +# +# Describe the computation process that produced these results. +# +# +# From 3ad2528546cb4168deb9319d36dc20122d57db43 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 09:53:33 +0200 Subject: [PATCH 128/203] regenerated nyaml for NIAC registered unchaged Application nxdl files --- applications/nyaml/NXarchive.yaml | 226 ++- applications/nyaml/NXarpes.yaml | 168 ++- applications/nyaml/NXcanSAS.yaml | 1957 +++++++++++++++++++++---- applications/nyaml/NXdirecttof.yaml | 81 +- applications/nyaml/NXfluo.yaml | 129 +- applications/nyaml/NXindirecttof.yaml | 90 +- applications/nyaml/NXiqproc.yaml | 160 +- applications/nyaml/NXlauetof.yaml | 184 ++- applications/nyaml/NXmonopd.yaml | 172 ++- applications/nyaml/NXmx.yaml | 1246 ++++++++++++++-- applications/nyaml/NXrefscan.yaml | 144 +- applications/nyaml/NXreftof.yaml | 164 ++- applications/nyaml/NXsas.yaml | 265 +++- applications/nyaml/NXsastof.yaml | 232 ++- applications/nyaml/NXscan.yaml | 142 +- applications/nyaml/NXspe.yaml | 89 +- applications/nyaml/NXsqom.yaml | 157 +- applications/nyaml/NXstxm.yaml | 271 +++- applications/nyaml/NXtas.yaml | 219 ++- applications/nyaml/NXtofnpd.yaml | 165 ++- applications/nyaml/NXtofraw.yaml | 181 ++- applications/nyaml/NXtofsingle.yaml | 182 ++- applications/nyaml/NXtomo.yaml | 187 ++- applications/nyaml/NXtomophase.yaml | 211 ++- applications/nyaml/NXtomoproc.yaml | 172 ++- applications/nyaml/NXxas.yaml | 165 ++- applications/nyaml/NXxasproc.yaml | 123 +- applications/nyaml/NXxbase.yaml | 232 ++- applications/nyaml/NXxeuler.yaml | 133 +- applications/nyaml/NXxkappa.yaml | 134 +- applications/nyaml/NXxlaue.yaml | 96 +- applications/nyaml/NXxlaueplate.yaml | 65 +- applications/nyaml/NXxnb.yaml | 125 +- applications/nyaml/NXxrot.yaml | 124 +- 34 files changed, 7393 insertions(+), 998 deletions(-) diff --git a/applications/nyaml/NXarchive.yaml b/applications/nyaml/NXarchive.yaml index 3dc5d4599e..44246f4a25 100644 --- a/applications/nyaml/NXarchive.yaml +++ b/applications/nyaml/NXarchive.yaml @@ -1,6 +1,6 @@ category: application -doc: | - This is a definition for data to be archived by ICAT (http':'//www.icatproject.org/). +doc: | + This is a definition for data to be archived by ICAT (http://www.icatproject.org/). .. text from the icatproject.org site @@ -8,92 +8,93 @@ doc: | interface to all ISIS experimental data and will provide a mechanism to link all aspects of ISIS research from proposal through to publication. - type: group NXarchive(NXobject): (NXentry)entry: \@index: title: experiment_identifier(NX_CHAR): - doc: | + doc: | unique identifier for the experiment experiment_description(NX_CHAR): - doc: | + doc: | Brief description of the experiment and its objectives collection_identifier(NX_CHAR): - doc: | + doc: | ID of user or DAQ define group of data files collection_description(NX_CHAR): - doc: | + doc: | Brief summary of the collection, including grouping criteria entry_identifier(NX_CHAR): - doc: | + doc: | unique identifier for this measurement as provided by the facility start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): duration(NX_FLOAT): unit: NX_TIME - doc: | - TODO':' needs documentation + doc: | + TODO: needs documentation collection_time(NX_FLOAT): unit: NX_TIME - doc: | - TODO':' needs documentation + doc: | + TODO: needs documentation run_cycle(NX_CHAR): - doc: | - TODO':' needs documentation + doc: | + TODO: needs documentation revision(NX_CHAR): - doc: | + doc: | revision ID of this file, may be after recalibration, reprocessing etc. definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXarchive] program(NX_CHAR): - doc: | + doc: | The program and version used for generating this file \@version: release_date(NX_CHAR): unit: NX_TIME - doc: | + doc: | when this file is to be released into PD (NXuser)user: name(NX_CHAR): role(NX_CHAR): - doc: | + doc: | role of the user facility_user_id(NX_CHAR): - doc: | + doc: | ID of the user in the facility burocracy database (NXinstrument)instrument: (NXsource): type(NX_CHAR): + + # TODO: suggest changing from enumeration to suggested list enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-Ray Source, Pulsed Muon Source, Rotating Anode X-Ray, Fixed Tube X-Ray] name: probe: enumeration: [neutron, x-ray, electron] name(NX_CHAR): description(NX_CHAR): - doc: | + doc: | Brief description of the instrument (NXsample)sample: name: - doc: | + doc: | Descriptive name of sample sample_id(NX_CHAR): - doc: | + doc: | Unique database id of the sample description(NX_CHAR): type(NX_CHAR): enumeration: [sample, sample+can, calibration sample, normalisation sample, simulated data, none, sample_environment] chemical_formula(NX_CHAR): - doc: | + doc: | Chemical formula formatted according to CIF conventions preparation_date(NX_CHAR): unit: NX_TIME situation(NX_CHAR): - doc: | - Description of the environment the sample is in':' + doc: | + Description of the environment the sample is in: air, vacuum, oxidizing atmosphere, dehydrated, etc. temperature(NX_FLOAT): unit: NX_TEMPERATURE @@ -105,3 +106,176 @@ NXarchive(NXobject): unit: NX_UNITLESS pressure(NX_FLOAT): unit: NX_PRESSURE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e5a85aff26bd71392bbe9cc8482e9067d971b4f1af39884f60db7dc0adfe811c +# +# +# +# +# +# This is a definition for data to be archived by ICAT (http://www.icatproject.org/). +# +# .. text from the icatproject.org site +# +# the database (with supporting software) that provides an +# interface to all ISIS experimental data and will provide +# a mechanism to link all aspects of ISIS research from +# proposal through to publication. +# +# +# +# +# +# unique identifier for the experiment +# +# +# Brief description of the experiment and its objectives +# +# +# ID of user or DAQ define group of data files +# +# +# Brief summary of the collection, including grouping criteria +# +# +# unique identifier for this measurement as provided by the facility +# +# +# +# +# TODO: needs documentation +# +# +# TODO: needs documentation +# +# +# TODO: needs documentation +# +# +# revision ID of this file, may be after recalibration, reprocessing etc. +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# The program and version used for generating this file +# +# +# when this file is to be released into PD +# +# +# +# role of the user +# +# ID of the user in the facility burocracy database +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Brief description of the instrument +# +# +# +# +# Descriptive name of sample +# +# +# Unique database id of the sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Chemical formula formatted according to CIF conventions +# +# +# +# +# Description of the environment the sample is in: +# air, vacuum, oxidizing atmosphere, dehydrated, etc. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXarpes.yaml b/applications/nyaml/NXarpes.yaml index 7e6a20fd13..746d91696f 100644 --- a/applications/nyaml/NXarpes.yaml +++ b/applications/nyaml/NXarpes.yaml @@ -1,20 +1,19 @@ category: application -doc: | +doc: | This is an application definition for angular resolved photo electron spectroscopy. It has been drawn up with hemispherical electron analysers in mind. - type: group NXarpes(NXobject): (NXentry): \@entry: - doc: | + doc: | NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry. title(NX_CHAR): start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms. enumeration: [NXarpes] (NXinstrument): @@ -29,7 +28,7 @@ NXarpes(NXobject): (NXdetector)analyser: data(NX_NUMBER): lens_mode(NX_CHAR): - doc: | + doc: | setting for the electron analyser lens acquisition_mode: enumeration: [swept, fixed] @@ -37,54 +36,191 @@ NXarpes(NXobject): enumeration: [curved, straight] entrance_slit_setting(NX_NUMBER): unit: NX_ANY - doc: | + doc: | dial setting of the entrance slit entrance_slit_size(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | size of the entrance slit pass_energy(NX_NUMBER): unit: NX_ENERGY - doc: | + doc: | energy of the electrons on the mean path of the analyser time_per_channel(NX_NUMBER): unit: NX_TIME - doc: | - todo':' define more clearly + doc: | + todo: define more clearly angles(NX_NUMBER): unit: NX_ANGLE - doc: | + doc: | Angular axis of the analyser data which dimension the axis applies to is defined using the normal NXdata methods. energies(NX_NUMBER): unit: NX_ENERGY - doc: | + doc: | Energy axis of the analyser data which dimension the axis applies to is defined using the normal NXdata methods. sensor_size(NX_INT): - doc: | + doc: | number of raw active elements in each dimension dimensions: rank: 1 dim: [[1, 2]] region_origin(NX_INT): - doc: | + doc: | origin of rectangular region selected for readout dimensions: rank: 1 dim: [[1, 2]] region_size(NX_INT): - doc: | + doc: | size of rectangular region selected for readout dimensions: rank: 1 dim: [[1, 2]] (NXsample): name(NX_CHAR): - doc: | + doc: | Descriptive name of sample temperature(NX_NUMBER): unit: NX_TEMPERATURE (NXdata): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 31232b8eac61f1e491926e74795efc8930591197ca40ea19d78788a866e7c6bf +# +# +# +# +# +# This is an application definition for angular resolved photo electron spectroscopy. +# +# It has been drawn up with hemispherical electron analysers in mind. +# +# +# +# +# NeXus convention is to use "entry1", "entry2", ... +# for analysis software to locate each entry. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# setting for the electron analyser lens +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# dial setting of the entrance slit +# +# +# size of the entrance slit +# +# +# energy of the electrons on the mean path of the analyser +# +# +# todo: define more clearly +# +# +# +# Angular axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# +# Energy axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# number of raw active elements in each dimension +# +# +# +# +# +# origin of rectangular region selected for readout +# +# +# +# +# +# size of rectangular region selected for readout +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# diff --git a/applications/nyaml/NXcanSAS.yaml b/applications/nyaml/NXcanSAS.yaml index b4db70c019..27192a0ea4 100644 --- a/applications/nyaml/NXcanSAS.yaml +++ b/applications/nyaml/NXcanSAS.yaml @@ -1,38 +1,38 @@ category: application -doc: | +doc: | Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. - .. index':'':' canSAS + .. index:: canSAS - For more details, see':' + For more details, see: - * http':'//www.cansas.org/ - * http':'//www.cansas.org/formats/canSAS1d/1.1/doc/ - * http':'//cansas-org.github.io/canSAS2012/ - * https':'//github.com/canSAS-org/NXcanSAS_examples + * http://www.cansas.org/ + * http://www.cansas.org/formats/canSAS1d/1.1/doc/ + * http://cansas-org.github.io/canSAS2012/ + * https://github.com/canSAS-org/NXcanSAS_examples The minimum requirements for *reduced* small-angle scattering data - as described by canSAS are summarized in the following figure':' + as described by canSAS are summarized in the following figure: - .. _canSAS_2012_minimum':' + .. _canSAS_2012_minimum: - .. figure':'':' canSAS/2012-minimum.png - ':'width':' 60% + .. figure:: canSAS/2012-minimum.png + :width: 60% The minimum requirements for *reduced* small-angle scattering data. - (':'download':'`full image `) - See ':'ref':'`below ` for the minimum required + (:download:`full image `) + See :ref:`below ` for the minimum required information for a NeXus data file written to the NXcanSAS specification. - .. rubric':'':' Implementation of canSAS standard in NeXus + .. rubric:: Implementation of canSAS standard in NeXus This application definition is an implementation of the canSAS standard for storing both one-dimensional and multi-dimensional *reduced* small-angle scattering data. * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. - * *Reduced* SAS data consists of ':'math':'`I(\vec{Q})` or ':'math':'`I(|\vec{Q}|)` + * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` * External file links are not to be used for the reduced data. * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. * There is no need for NXcanSAS to refer to any raw data. @@ -60,78 +60,87 @@ doc: | (*) The name of each group is a suggestion, not a fixed requirement and is chosen as fits each data file. See the section on defining - ':'ref':'`NXDL group and field names `. + :ref:`NXDL group and field names `. - Refer to the NeXus Coordinate System drawing (':'ref':'`Design-CoordinateSystem`) - for choice and direction of ':'math':'`x`, ':'math':'`y`, and ':'math':'`z` axes. + Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) + for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. - .. _NXcanSAS_minimum':' + .. _NXcanSAS_minimum: - .. rubric':'':' The minimum required information for a NeXus data file + .. rubric:: The minimum required information for a NeXus data file written to the NXcanSAS specification. - .. literalinclude':'':' canSAS/minimum-required.txt - ':'tab-width':' 4 - ':'linenos':' - ':'language':' text + .. literalinclude:: canSAS/minimum-required.txt + :tab-width: 4 + :linenos: + :language: text +# NOTE: +# This NXDL refers to several image files (.jpg, .png) in its documentation. +# All such related resources are stored in the related subdirectory: ./canSAS/ +# In general, for an NXDL file: NXsomenxdl.nxdl.xml +# all related resources should be stored in subdirectory: ./somenxdl/ type: group NXcanSAS(NXobject): (NXentry): \@default: exists: optional - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting - Declares which ':'ref':'`NXdata` group + Declares which :ref:`NXdata` group contains the data to be shown by default. - It is needed to resolve ambiguity when more than one ':'ref':'`NXdata` group exists. - The value is the name of the default ':'ref':'`NXdata` group. + It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. + The value is the name of the default :ref:`NXdata` group. Usually, this will be the name of the first *SASdata* group. - doc: | - .. index':'':' NXcanSAS (applications); SASentry + doc: | + .. index:: NXcanSAS (applications); SASentry Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group (when data from multiple techniques are being stored) or as a replacement for the ``NXentry`` group. - Note':' It is required for all numerical objects to provide + Note: It is required for all numerical objects to provide a *units* attribute that describes the engineering units. Use the Unidata UDunits [#]_ specification as this is compatible with various community standards. .. [#] The UDunits specification also includes instructions for derived units. \@canSAS_class: - doc: | - Official canSAS group':' **SASentry** + doc: | + Official canSAS group: **SASentry** enumeration: [SASentry] \@version: - doc: | + doc: | Describes the version of the canSAS standard used to write this data. - This must be a text (not numerical) representation. Such as':'':' + This must be a text (not numerical) representation. Such as:: @version="1.1" enumeration: [1.1] definition: - doc: | + doc: | Official NeXus NXDL schema to which this subentry conforms. enumeration: [NXcanSAS] + + # ============================ + # SASdata + # ============================ (NXdata): - doc: | + doc: | A *SASData* group contains a single reduced small-angle scattering data set - that can be represented as ':'math':'`I(\vec{Q})` or ':'math':'`I(|\vec{Q}|)`. + that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. - *Q* can be either a vector (':'math':'`\vec{Q}`) or a vector magnitude (':'math':'`|\vec{Q}|`) + *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) The name of each *SASdata* group must be unique within a SASentry group. Suggest using names such as ``sasdata01``. - NOTE':' For the first *SASdata* group, be sure to write the chosen name - into the `SASentry/@default` attribute, as in':'':' + NOTE: For the first *SASdata* group, be sure to write the chosen name + into the `SASentry/@default` attribute, as in:: SASentry/@default="sasdata01" - A *SASdata* group has several attributes':' + A *SASdata* group has several attributes: * I_axes * Q_indices @@ -141,25 +150,27 @@ NXcanSAS(NXobject): use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` or ``@Pressure_indices``). \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SASdata` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASdata` enumeration: [SASdata] + + # attributes, see: http://www.cansas.org/formats/canSAS2012/1.0/doc/framework.html#terms \@signal: type: NX_CHAR - doc: | + doc: | Name of the default data field. enumeration: I: - doc: | + doc: | For canSAS **SASdata**, this is always "I". \@I_axes: - doc: | + doc: | String array that defines the independent data fields used in the default plot for all of the dimensions of the *signal* field (the *signal* field is the field in this group that is named by the ``signal`` attribute of this group). One entry is provided for every dimension of the ``I`` data object. - Such as':'':' + Such as:: @I_axes="Temperature", "Time", "Pressure", "Q", "Q" @@ -167,74 +178,76 @@ NXcanSAS(NXobject): ``I`` must be a five-dimensional array (rank=5). \@Q_indices: type: NX_INT - doc: | + doc: | Integer or integer array that describes which indices - (of the ':'math':'`I` data object) are used to + (of the :math:`I` data object) are used to reference the ``Q`` data object. The items in this array - use zero-based indexing. Such as':'':' + use zero-based indexing. Such as:: @Q_indices=1,3,4 which indicates that ``Q`` requires three indices - from the ':'math':'`I` data object':' one for time and + from the :math:`I` data object: one for time and two for Q position. Thus, in this example, the - ``Q`` data is time-dependent':' ':'math':'`\vec{Q}(t)`. + ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. \@mask: type: NX_CHAR - doc: | + doc: | Name of the data mask field. - .. see':' https':'//github.com/nexusformat/definitions/issues/533 + .. see: https://github.com/nexusformat/definitions/issues/533 The data *mask* must have the same shape as the *data* field. Positions in the mask correspond to positions in the *data* field. The value of the mask field may be either a boolean array where ``false`` means *no mask* and ``true`` means *mask* - or a more descriptive array as as defined in ':'ref':'`NXdetector`. + or a more descriptive array as as defined in :ref:`NXdetector`. \@Mask_indices: exists: optional - doc: | + doc: | Integer or integer array that describes which indices - (of the ':'math':'`I` data object) are used to + (of the :math:`I` data object) are used to reference the ``Mask`` data object. The items in this - array use zero-based indexing. Such as':'':' + array use zero-based indexing. Such as:: @Mask_indices=3,4 which indicates that Q requires two indices - from the ':'math':'`I` data object for Q position. + from the :math:`I` data object for Q position. \@timestamp: type: NX_DATE_TIME exists: optional - doc: | + doc: | ISO-8601 time [#iso8601]_ Q(NX_NUMBER): unit: NX_PER_LENGTH - doc: | - .. index':'':' NXcanSAS (applications); Q + + # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of + doc: | + .. index:: NXcanSAS (applications); Q - Array of ':'math':'`Q` data to accompany ':'math':'`I`. + Array of :math:`Q` data to accompany :math:`I`. - .. figure':'':' canSAS/Q-geometry.jpg - ':'width':' 60% + .. figure:: canSAS/Q-geometry.jpg + :width: 60% - The ':'math':'`\vec{Q}` geometry. - (':'download':'`full image `) + The :math:`\vec{Q}` geometry. + (:download:`full image `) - ':'math':'`Q` may be represented as either - the three-dimensional scattering vector ':'math':'`\vec{Q}` - or the magnitude of the scattering vector, ':'math':'`|\vec{Q}|`. + :math:`Q` may be represented as either + the three-dimensional scattering vector :math:`\vec{Q}` + or the magnitude of the scattering vector, :math:`|\vec{Q}|`. - .. math':'':' |\vec{Q}| = (4\pi/\lambda) sin(\theta) + .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) - When we write ':'math':'`Q`, we may refer to either or both of - ':'math':'`|\vec{Q}|` - or ':'math':'`\vec{Q}`, depending on the context. + When we write :math:`Q`, we may refer to either or both of + :math:`|\vec{Q}|` + or :math:`\vec{Q}`, depending on the context. \@units: exists: optional - doc: | + doc: | Engineering units to use when expressing - ':'math':'`Q` and related terms. + :math:`Q` and related terms. Data expressed in other units will generate a warning from validation software and may not @@ -242,23 +255,23 @@ NXcanSAS(NXobject): enumeration: 1/m: 1/nm: - doc: | + doc: | preferred 1/angstrom: \@uncertainties: exists: optional - doc: | - (optional':' for numerical arrays) + doc: | + (optional: for numerical arrays) Names the dataset (in this SASdata group) that provides the uncertainty to be used for data analysis. - The name of the dataset containing the ':'math':'`Q` uncertainty + The name of the dataset containing the :math:`Q` uncertainty is flexible. The name must be unique in the *SASdata* group. .. comment - see':' https':'//github.com/canSAS-org/canSAS2012/issues/7 + see: https://github.com/canSAS-org/canSAS2012/issues/7 - Such as':'':' + Such as:: @uncertainties="Q_uncertainties" @@ -273,35 +286,35 @@ NXcanSAS(NXobject): There may also be a subdirectory (optional) with constituent components. - .. note':'':' To report distribution in reported ':'math':'`Q` values, + .. note:: To report distribution in reported :math:`Q` values, use the ``@resolutions`` attribute. It is possible for both ``@resolutions`` and ``uncertainties`` to be reported. \@resolutions: type: NX_CHAR exists: optional - doc: | - .. index':'':' NXcanSAS (applications); resolutions + doc: | + .. index:: NXcanSAS (applications); resolutions - (optional':' for numerical arrays) + (optional: for numerical arrays) - Names the dataset (in this SASdata group) containing the ':'math':'`Q` resolution. - The name of the dataset containing the ':'math':'`Q` resolution + Names the dataset (in this SASdata group) containing the :math:`Q` resolution. + The name of the dataset containing the :math:`Q` resolution is flexible. The name must be unique in the *SASdata* group. .. comment - see':' https':'//github.com/canSAS-org/canSAS2012/issues/7 + see: https://github.com/canSAS-org/canSAS2012/issues/7 The *resolutions* field will have the same *shape* (dimensions) as the Q field. - Generally, this is the principal resolution of each ':'math':'`Q`. + Generally, this is the principal resolution of each :math:`Q`. Names the data object (in this SASdata group) that provides the - ':'math':'`Q` resolution to be used for data analysis. Such as':'':' + :math:`Q` resolution to be used for data analysis. Such as:: @resolutions="Qdev" To specify two-dimensional resolution for slit-smearing geometry, - such as (*dQw*, *dQl*), use a string array, such as':'':' + such as (*dQw*, *dQl*), use a string array, such as:: @resolutions="dQw", "dQl" @@ -312,7 +325,7 @@ NXcanSAS(NXobject): unanticipated terms related to the data. .. comment - see':' https':'//github.com/nexusformat/definitions/issues/492#issuecomment-262813907 + see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 By default, the values of the resolutions data object are assumed to be one standard deviation of any function used to approximate the @@ -320,53 +333,55 @@ NXcanSAS(NXobject): distribution if a Gaussian is chosen. See the ``@resolutions_description`` attribute. - .. note':'':' To report uncertainty in reported ':'math':'`Q` values, + .. note:: To report uncertainty in reported :math:`Q` values, use the ``@uncertainties`` attribute. It is possible for both ``@resolutions`` and ``uncertainties`` to be reported. \@resolutions_description: type: NX_CHAR exists: optional - doc: | + doc: | (optional) - Generally, this describes the ':'math':'`Q` ``@resolutions`` data object. + Generally, this describes the :math:`Q` ``@resolutions`` data object. By default, the value is assumed to be "Gaussian". These are - suggestions':' + suggestions: * Gaussian * Lorentzian - * Square ':' + * Square : note that the full width of the square would be ~2.9 times the standard deviation specified in the vector * Triangular - * Sawtooth-outward ':' vertical edge pointing to larger Q + * Sawtooth-outward : vertical edge pointing to larger Q * Sawtooth-inward vertical edge pointing to smaller Q - * Bin ':' range of values contributing + * Bin : range of values contributing (for example, when 2-D detector data have been reduced - to a 1-D ':'math':'`I(|Q|)` dataset) + to a 1-D :math:`I(|Q|)` dataset) For other meanings, it may be necessary to provide further details such as the function used to assess the resolution. - In such cases, use additional datasets or a ':'ref':'`NXnote` subgroup + In such cases, use additional datasets or a :ref:`NXnote` subgroup to include that detail. I(NX_NUMBER): - doc: | - .. index':'':' NXcanSAS (applications); I + + # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of-intensity + doc: | + .. index:: NXcanSAS (applications); I - Array of intensity (':'math':'`I`) data. + Array of intensity (:math:`I`) data. - The intensity may be represented in one of these forms':' + The intensity may be represented in one of these forms: - **absolute units**':' ':'math':'`d\Sigma/d\Omega(Q)` + **absolute units**: :math:`d\Sigma/d\Omega(Q)` differential cross-section - per unit volume per unit solid angle (such as':' 1/cm/sr or 1/m/sr) + per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) - **absolute units**':' ':'math':'`d\sigma/d\Omega(Q)` + **absolute units**: :math:`d\sigma/d\Omega(Q)` differential cross-section - per unit atom per unit solid angle (such as':' cm^2 or m^2) + per unit atom per unit solid angle (such as: cm^2 or m^2) - **arbitrary units**':' ':'math':'`I(Q)` + **arbitrary units**: :math:`I(Q)` usually a ratio of two detectors - but units are meaningless (such as':' a.u. or counts) + but units are meaningless (such as: a.u. or counts) This presents a few problems for analysis software to sort out when reading the data. @@ -380,7 +395,7 @@ NXcanSAS(NXobject): A second problem is that when arbitrary units are used, then the set of possible analytical results is restricted. With such units, no meaningful volume fraction - or number density can be determined directly from ':'math':'`I(Q)`. + or number density can be determined directly from :math:`I(Q)`. In some cases, it is possible to apply a factor to convert the arbitrary units to an absolute scale. This should be considered as a possibility @@ -388,12 +403,12 @@ NXcanSAS(NXobject): Where this documentation says *typical units*, it is possible that small-angle data may be presented in other units and still be consistent with NeXus. - See the ':'ref':'`design-units` section. + See the :ref:`design-units` section. \@units: exists: optional - doc: | + doc: | Engineering units to use when expressing - ':'math':'`I` and intensity-related terms. + :math:`I` and intensity-related terms. Data expressed in other units (or missing a ``@units`` attribute) will be treated as ``arbitrary`` by some software packages. @@ -402,74 +417,74 @@ NXcanSAS(NXobject): changed to ``unknown`` for handling with that library. enumeration: 1/m: - doc: | + doc: | includes m2/m3 and 1/m/sr 1/cm: - doc: | + doc: | includes cm2/cm3 and 1/cm/sr m2/g: cm2/g: arbitrary: \@uncertainties: exists: optional - doc: | - (optional':' for numerical arrays) + doc: | + (optional: for numerical arrays) Names the dataset (in this SASdata group) that provides the - uncertainty of ':'math':'`I` to be used for data analysis. - The name of the dataset containing the ':'math':'`I` uncertainty + uncertainty of :math:`I` to be used for data analysis. + The name of the dataset containing the :math:`I` uncertainty is flexible. The name must be unique in the *SASdata* group. .. comment - see':' https':'//github.com/canSAS-org/canSAS2012/issues/7 + see: https://github.com/canSAS-org/canSAS2012/issues/7 - Generally, this is the estimate of the uncertainty of each ':'math':'`I`. + Generally, this is the estimate of the uncertainty of each :math:`I`. Typically the estimated standard deviation. *Idev* is the canonical name from the 1D standard. The NXcanSAS standard allows for the name to be described using this attribute. - Such as':'':' + Such as:: @uncertainties="Idev" \@scaling_factor: exists: optional - doc: | + doc: | (optional) Names the field (a.k.a. dataset) that contains a factor to multiply ``I``. By default, this value is unity. Should an uncertainty be associated with the scaling factor field, the field containing that uncertainty would be designated via the ``uncertainties`` attribute. - Such as':'':' + Such as:: - I ':' NX_NUMBER - @uncertainties="Idev" ':' NX_CHAR - @scaling_factor="I_scaling" ':' NX_CHAR - Idev ':' NX_NUMBER - I_scaling ':' NX_NUMBER - @uncertainties="I_scaling_dev" ':' NX_CHAR - I_scaling_dev ':' NX_NUMBER + I : NX_NUMBER + @uncertainties="Idev" : NX_CHAR + @scaling_factor="I_scaling" : NX_CHAR + Idev : NX_NUMBER + I_scaling : NX_NUMBER + @uncertainties="I_scaling_dev" : NX_CHAR + I_scaling_dev : NX_NUMBER The exact names for ``I_scaling`` and ``I_scaling_dev`` are not defined by NXcanSAS. The user has the flexibility to use names different than those shown in this example. Idev(NX_NUMBER): exists: ['min', '0'] - doc: | - .. index':'':' NXcanSAS (applications); Idev + doc: | + .. index:: NXcanSAS (applications); Idev Estimated **uncertainty** (usually standard deviation) - in ':'math':'`I`. Must have the same units as ':'math':'`I`. + in :math:`I`. Must have the same units as :math:`I`. When present, the name of this field is also - recorded in the *uncertainties* attribute of *I*, as in':'':' + recorded in the *uncertainties* attribute of *I*, as in:: I/@uncertainties="Idev" \@units: exists: optional - doc: | + doc: | Engineering units to use when expressing - ':'math':'`I` and intensity-related terms. + :math:`I` and intensity-related terms. Data expressed in other units (or missing a ``@units`` attribute) will generate a warning from any validation process @@ -479,10 +494,10 @@ NXcanSAS(NXobject): changed to ``unknown`` for handling with that library. enumeration: 1/m: - doc: | + doc: | includes m2/m3 and 1/m/sr 1/cm: - doc: | + doc: | includes cm2/cm3 and 1/cm/sr m2/g: cm2/g: @@ -490,102 +505,102 @@ NXcanSAS(NXobject): Qdev(NX_NUMBER): unit: NX_PER_LENGTH exists: ['min', '0'] - doc: | - .. index':'':' NXcanSAS (applications); Qdev + doc: | + .. index:: NXcanSAS (applications); Qdev - Estimated ':'math':'`Q` **resolution** (usually standard deviation). - Must have the same units as ':'math':'`Q`. + Estimated :math:`Q` **resolution** (usually standard deviation). + Must have the same units as :math:`Q`. When present, the name of this field is also recorded in the *resolutions* attribute of *Q*, - as in':'':' + as in:: Q/@resolutions="Qdev" - or':'':' + or:: Q/@resolutions="dQw", "dQl" \@units: exists: optional - doc: | + doc: | Engineering units to use when expressing - ':'math':'`Q` and related terms. + :math:`Q` and related terms. Data expressed in other units may not be processed by some software packages. enumeration: 1/m: 1/nm: - doc: | + doc: | preferred 1/angstrom: dQw(NX_NUMBER): unit: NX_PER_LENGTH exists: ['min', '0'] - doc: | - .. index':'':' NXcanSAS (applications); dQw + doc: | + .. index:: NXcanSAS (applications); dQw - ':'math':'`Q` **resolution** along the axis of scanning + :math:`Q` **resolution** along the axis of scanning (the high-resolution *slit width* direction). Useful for defining resolution data from slit-smearing instruments such as Bonse-Hart geometry. - Must have the same units as ':'math':'`Q`. + Must have the same units as :math:`Q`. When present, the name of this field is also recorded in the *resolutions* attribute of *Q*, - as in':'':' + as in:: Q/@resolutions="dQw", "dQl" \@units: exists: optional - doc: | + doc: | Engineering units to use when expressing - ':'math':'`Q` and related terms. + :math:`Q` and related terms. Data expressed in other units may not be processed by some software packages. enumeration: 1/m: 1/nm: - doc: | + doc: | preferred 1/angstrom: dQl(NX_NUMBER): unit: NX_PER_LENGTH exists: ['min', '0'] - doc: | - .. index':'':' NXcanSAS (applications); dQl + doc: | + .. index:: NXcanSAS (applications); dQl - ':'math':'`Q` **resolution** perpendicular to the axis of scanning + :math:`Q` **resolution** perpendicular to the axis of scanning (the low-resolution *slit length* direction). Useful for defining resolution data from slit-smearing instruments such as Bonse-Hart geometry. - Must have the same units as ':'math':'`Q`. + Must have the same units as :math:`Q`. When present, the name of this field is also recorded in the *resolutions* attribute of *Q*, - as in':'':' + as in:: Q/@resolutions="dQw", "dQl" \@units: exists: optional - doc: | + doc: | Engineering units to use when expressing - ':'math':'`Q` and related terms. + :math:`Q` and related terms. Data expressed in other units may not be processed by some software packages. enumeration: 1/m: 1/nm: - doc: | + doc: | preferred 1/angstrom: Qmean(NX_NUMBER): exists: ['min', '0'] unit: NX_PER_LENGTH - doc: | - Mean value of ':'math':'`Q` for this data point. + doc: | + Mean value of :math:`Q` for this data point. Useful when describing data that has been binned from higher-resolution data. @@ -593,29 +608,31 @@ NXcanSAS(NXobject): and that both ``Q`` and ``Qmean`` will have the same units. \@units: exists: optional - doc: | + doc: | Engineering units to use when expressing - ':'math':'`Q` and related terms. + :math:`Q` and related terms. Data expressed in other units may not be processed by some software packages. enumeration: 1/m: 1/nm: - doc: | + doc: | preferred 1/angstrom: ShadowFactor: exists: ['min', '0'] unit: NX_DIMENSIONLESS - doc: | + doc: | A numerical factor applied to pixels affected by the beam stop penumbra. Used in data files from NIST/NCNR instruments. - See':' J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. + See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. + + # optional items title: exists: ['min', '1', 'max', '1'] - doc: | + doc: | Title of this *SASentry*. Make it so that you can recognize the data by its title. Could be the name of the sample, @@ -623,7 +640,7 @@ NXcanSAS(NXobject): run: exists: ['min', '1', 'max', 'unbounded'] nameType: any - doc: | + doc: | Run identification for this *SASentry*. For many facilities, this is an integer, such as en experiment number. Use multiple instances of ``run`` as needed, keeping @@ -631,55 +648,63 @@ NXcanSAS(NXobject): in a group. \@name: exists: optional - doc: | + doc: | Optional string attribute to identify this particular *run*. Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. (NXinstrument): exists: ['min', '0'] \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SASinstrument` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` enumeration: [SASinstrument] - doc: | + doc: | Description of the small-angle scattering instrument. Consider, carefully, the relevance to the SAS data analysis process when adding subgroups in this **NXinstrument** group. Additional information can be added but will likely be ignored by standardized data anlysis processes. - The NeXus ':'ref':'`NXbeam` base class may be added as a subgroup of this **NXinstrument** + The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any point downstream from the source. + + # =========== + # SASaperture + # =========== (NXaperture): exists: ['min', '0'] - doc: | - ':'ref':'`NXaperture` is generic and limits the variation in data files. + doc: | + :ref:`NXaperture` is generic and limits the variation in data files. - Possible NeXus base class alternatives are':' ':'ref':'`NXpinhole` or ':'ref':'`NXslit`. + Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SASaperture` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASaperture` enumeration: [SASaperture] shape: - doc: | + doc: | describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) x_gap(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | - opening along the ':'math':'`x` axis + doc: | + opening along the :math:`x` axis y_gap(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | - opening along the ':'math':'`y` axis + doc: | + opening along the :math:`y` axis + + # ============== + # SAScollimation + # ============== (NXcollimator): exists: ['min', '0'] \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SAScollimation` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` enumeration: [SAScollimation] - doc: | + doc: | Description of a collimating element (defines the divergence of the beam) in the instrument. To document a slit, pinhole, or the beam, refer to the @@ -687,32 +712,38 @@ NXcanSAS(NXobject): length(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Amount/length of collimation inserted (as on a SANS instrument) distance(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Distance from this collimation element to the sample + + # SAScollimation + + # ============================ + # SASdetector + # ============================ (NXdetector): exists: ['min', '0'] \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SASdetector` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASdetector` enumeration: [SASdetector] - doc: | + doc: | Description of a detector in the instrument. name: exists: ['max', '1'] - doc: | + doc: | Identifies the name of this detector SDD(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Distance between sample and detector. - Note':' In NXdetector, the ``distance`` field records the + Note: In NXdetector, the ``distance`` field records the distance to the previous component ... most often the sample. This use is the same as ``SDD`` for most SAS instruments but not all. For example, Bonse-Hart cameras @@ -723,38 +754,38 @@ NXcanSAS(NXobject): slit_length(NX_NUMBER): unit: NX_PER_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Slit length of the instrument for this detector, - expressed in the same units as ':'math':'`Q`. + expressed in the same units as :math:`Q`. x_position(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_LENGTH - doc: | - Location of the detector in ':'math':'`x` + doc: | + Location of the detector in :math:`x` y_position(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_LENGTH - doc: | - Location of the detector in ':'math':'`y` + doc: | + Location of the detector in :math:`y` roll(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_ANGLE - doc: | - Rotation of the detector about the ':'math':'`z` axis (roll) + doc: | + Rotation of the detector about the :math:`z` axis (roll) pitch(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_ANGLE - doc: | - Rotation of the detector about the ':'math':'`x` axis (roll) + doc: | + Rotation of the detector about the :math:`x` axis (roll) yaw(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_ANGLE - doc: | - Rotation of the detector about the ':'math':'`y` axis (yaw) + doc: | + Rotation of the detector about the :math:`y` axis (yaw) beam_center_x(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Position of the beam center on the detector. This is the x position where the direct beam would hit the detector plane. @@ -765,7 +796,7 @@ NXcanSAS(NXobject): beam_center_y(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Position of the beam center on the detector. This is the y position where the direct beam would hit the detector plane. @@ -776,138 +807,160 @@ NXcanSAS(NXobject): x_pixel_size(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Size of each detector pixel. If it is scalar all pixels are the same size y_pixel_size(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Size of each detector pixel. If it is scalar all pixels are the same size + + # SASdetector + + # ============================ + # SASsource + # ============================ (NXsource): exists: ['min', '0'] \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SASsource` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASsource` enumeration: [SASsource] - doc: | + doc: | Description of the radiation source. radiation: exists: optional deprecated: Use either (or both) ``probe`` or ``type`` fields from ``NXsource`` (issue #765) - doc: | + doc: | Name of the radiation used. Note that this is **not** the name of the facility! This field contains a value from either the - ``probe`` or ``type`` fields in ':'ref':'`NXsource`. Thus, + ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, it is redundant with existing NeXus structure. + + # enumeration values from NXsource/type and NXsource/probe enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] beam_shape: exists: ['min', '0', 'max', '1'] - doc: | + doc: | Text description of the shape of the beam (incident on the sample). incident_wavelength(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_WAVELENGTH - doc: | - wavelength (':'math':'`\lambda`) of radiation incident on the sample + doc: | + wavelength (:math:`\lambda`) of radiation incident on the sample wavelength_min(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_WAVELENGTH - doc: | + doc: | Some facilities specify wavelength using a range. This is the lowest wavelength in such a range. wavelength_max(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_WAVELENGTH - doc: | + doc: | Some facilities specify wavelength using a range. This is the highest wavelength in such a range. incident_wavelength_spread(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_WAVELENGTH - doc: | + doc: | Some facilities specify wavelength using a range. This is the width (FWHM) of such a range. beam_size_x(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Size of the incident beam along the x axis. beam_size_y(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Size of the incident beam along the y axis. + + # SASsource + + # SASinstrument + + # ============== + # SASsample + # ============== (NXsample): exists: ['min', '0'] \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SASsample` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASsample` enumeration: [SASsample] - doc: | + doc: | Description of the sample. name: exists: ['max', '1'] - doc: | - **ID**':' Text string that identifies this sample. + doc: | + **ID**: Text string that identifies this sample. thickness(NX_FLOAT): exists: ['min', '0', 'max', '1'] unit: NX_LENGTH - doc: | + doc: | Thickness of this sample transmission(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_DIMENSIONLESS - doc: | - Transmission (':'math':'`I/I_0`) of this sample. + doc: | + Transmission (:math:`I/I_0`) of this sample. There is no *units* attribute as this number is dimensionless. - Note':' the ability to store a transmission *spectrum*, + Note: the ability to store a transmission *spectrum*, instead of a single value, is provided elsewhere in the structure, in the *SAStransmission_spectrum* element. temperature(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_TEMPERATURE - doc: | + doc: | Temperature of this sample. details: exists: ['min', '0', 'max', 'unbounded'] nameType: any - doc: | + doc: | Any additional sample details. x_position(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_LENGTH - doc: | - Location of the sample in ':'math':'`x` + doc: | + Location of the sample in :math:`x` y_position(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_LENGTH - doc: | - Location of the sample in ':'math':'`y` + doc: | + Location of the sample in :math:`y` roll(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_ANGLE - doc: | - Rotation of the sample about the ':'math':'`z` axis (roll) + doc: | + Rotation of the sample about the :math:`z` axis (roll) pitch(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_ANGLE - doc: | - Rotation of the sample about the ':'math':'`x` axis (roll) + doc: | + Rotation of the sample about the :math:`x` axis (roll) yaw(NX_NUMBER): exists: ['min', '0', 'max', '1'] unit: NX_ANGLE - doc: | - Rotation of the sample about the ':'math':'`y` axis (yaw) + doc: | + Rotation of the sample about the :math:`y` axis (yaw) + + # NXsample + + # ============== + # SASprocess + # ============== (NXprocess): exists: ['min', '0', 'max', 'unbounded'] \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SASprocess` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASprocess` enumeration: [SASprocess] - doc: | + doc: | Description of a processing or analysis step. Add additional fields as needed to describe value(s) of any @@ -915,40 +968,44 @@ NXcanSAS(NXobject): Be sure to include *units* attributes for all numerical fields. name: exists: ['min', '0', 'max', '1'] - doc: | + doc: | Optional name for this data processing or analysis step date(NX_DATE_TIME): exists: ['min', '0', 'max', '1'] - doc: | + doc: | Optional date for this data processing or analysis step. [#iso8601]_ .. [#iso8601] ISO-8601 standard time representation. NeXus dates and times are reported in ISO-8601 - (e.g., ``yyyy-mm-ddThh':'mm':'ss``) - or modified ISO-8601 (e.g., ``yyyy-mm-dd hh':'mm':'ss``). + (e.g., ``yyyy-mm-ddThh:mm:ss``) + or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). - See':' http':'//www.w3.org/TR/NOTE-datetime - or http':'//en.wikipedia.org/wiki/ISO_8601 for more details. + See: http://www.w3.org/TR/NOTE-datetime + or http://en.wikipedia.org/wiki/ISO_8601 for more details. description: exists: ['min', '0', 'max', '1'] - doc: | + doc: | Optional description for this data processing or analysis step term: exists: ['min', '0', 'max', 'unbounded'] nameType: any - doc: | + doc: | Specifies the value of a single variable, parameter, or term (while defined here as a string, it could be a number) related to the *SASprocess* step. - Note':' + Note: The name *term* is not required, it could take any name, as long as the name is unique within this group. + + # suggested at NIAC2014 + # Isn't this ALWAYS a possibility in any NeXus base class? + # Not needed to define this but it is a good suggestion for usage. (NXnote): exists: ['min', '0', 'max', 'unbounded'] - doc: | + doc: | Any additional notes or subprocessing steps will be documented here. An **NXnote** group can be added to any NeXus group at or below the @@ -956,58 +1013,68 @@ NXcanSAS(NXobject): to *consider* its use. (NXcollection): exists: ['min', '0', 'max', 'unbounded'] - doc: | + doc: | Describes anything about *SASprocess* that is not already described. Any content not defined in the canSAS standard can be placed at this point. - Note':' + Note: The name of this group is flexible, it could take any name, as long as it is unique within the **NXprocess** group. \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SASprocessnote` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` enumeration: [SASprocessnote] + + # SASprocessnote + + # SASprocess + + # ============== + # SASnote + # ============== (NXcollection): exists: ['min', '0', 'max', 'unbounded'] \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SASnote` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASnote` enumeration: [SASnote] - doc: | + doc: | Free form description of anything not covered by other elements. + + # ============================ + # SAStransmission_spectrum + # ============================ TRANSMISSION_SPECTRUM(NXdata): exists: ['min', '0'] - doc: | + doc: | The *SAStransmission_spectrum* element This describes certain data obtained from a variable-wavelength source such as pulsed-neutron source. - - The name of each *SAStransmission_spectrum* group must be unique within a SASentry group. - Suggest using names such as ``sastransmission_spectrum01``. + # requested to be in the 1D format by ISIS \@canSAS_class: - doc: | - Official canSAS group':' ':'index':'`NXcanSAS (applications); SAStransmission_spectrum` + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` enumeration: [SAStransmission_spectrum] \@signal: type: NX_CHAR - doc: | + doc: | Name of the default data field. enumeration: T: - doc: | + doc: | For **SAStransmission_spectrum**, this is always "T". \@T_axes: enumeration: T: - doc: | + doc: | the wavelengths field (as a dimension scale) corresponding to this transmission \@name: - doc: | + doc: | Identify what type of spectrum is being described. - It is expected that this value will take either of these two values':' + It is expected that this value will take either of these two values: ====== ============================================== value meaning @@ -1018,44 +1085,1338 @@ NXcanSAS(NXobject): \@timestamp: type: NX_DATE_TIME exists: optional - doc: | + doc: | ISO-8601 time [#iso8601]_ lambda(NX_NUMBER): unit: NX_WAVELENGTH - doc: | + doc: | Wavelength of the radiation. This array is of the same shape as ``T`` and ``Tdev``. T(NX_NUMBER): unit: NX_DIMENSIONLESS - doc: | - Transmission values (':'math':'`I/I_0`) + doc: | + Transmission values (:math:`I/I_0`) as a function of wavelength. This array is of the same shape as ``lambda`` and ``Tdev``. \@uncertainties: - doc: | + doc: | Names the dataset (in this SASdata group) that provides the - uncertainty of each transmission ':'math':'`T` to be used for data analysis. - The name of the dataset containing the ':'math':'`T` uncertainty + uncertainty of each transmission :math:`T` to be used for data analysis. + The name of the dataset containing the :math:`T` uncertainty is expected to be ``Tdev``. .. comment - see':' https':'//github.com/canSAS-org/canSAS2012/issues/7 + see: https://github.com/canSAS-org/canSAS2012/issues/7 - Typically':' + Typically: @uncertainties="Tdev" Tdev(NX_NUMBER): unit: NX_DIMENSIONLESS - doc: | - .. index':'':' NXcanSAS (applications); Tdev + doc: | + .. index:: NXcanSAS (applications); Tdev Estimated uncertainty (usually standard deviation) - in ':'math':'`T`. Must have the same units as ':'math':'`T`. + in :math:`T`. Must have the same units as :math:`T`. - This is the field is named in the *uncertainties* attribute of *T*, as in':'':' + This is the field is named in the *uncertainties* attribute of *T*, as in:: T/@uncertainties="Tdev" This array is of the same shape as ``lambda`` and ``T``. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0138726f10e2c6809b373544080966e4d3f5a78d2311b780dcabd6ceeea535fa +# +# +# +# +# +# +# +# +# Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. +# +# .. index:: canSAS +# +# For more details, see: +# +# * http://www.cansas.org/ +# * http://www.cansas.org/formats/canSAS1d/1.1/doc/ +# * http://cansas-org.github.io/canSAS2012/ +# * https://github.com/canSAS-org/NXcanSAS_examples +# +# The minimum requirements for *reduced* small-angle scattering data +# as described by canSAS are summarized in the following figure: +# +# .. _canSAS_2012_minimum: +# +# .. figure:: canSAS/2012-minimum.png +# :width: 60% +# +# The minimum requirements for *reduced* small-angle scattering data. +# (:download:`full image <canSAS/2012-minimum.png>`) +# See :ref:`below <NXcanSAS_minimum>` for the minimum required +# information for a NeXus data file +# written to the NXcanSAS specification. +# +# .. rubric:: Implementation of canSAS standard in NeXus +# +# This application definition is an implementation of the canSAS +# standard for storing both one-dimensional and multi-dimensional +# *reduced* small-angle scattering data. +# +# * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. +# * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` +# * External file links are not to be used for the reduced data. +# * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. +# * There is no need for NXcanSAS to refer to any raw data. +# +# The canSAS data format has a structure similar to NeXus, not identical. +# To allow canSAS data to be expressed in NeXus, yet identifiable +# by the canSAS standard, an additional group attribute ``canSAS_class`` +# was introduced. Here is the mapping of some common groups. +# +# =============== ============ ========================== +# group (*) NX_class canSAS_class +# =============== ============ ========================== +# sasentry NXentry SASentry +# sasdata NXdata SASdata +# sasdetector NXdetector SASdetector +# sasinstrument NXinstrument SASinstrument +# sasnote NXnote SASnote +# sasprocess NXprocess SASprocess +# sasprocessnote NXcollection SASprocessnote +# sastransmission NXdata SAStransmission_spectrum +# sassample NXsample SASsample +# sassource NXsource SASsource +# =============== ============ ========================== +# +# (*) The name of each group is a suggestion, +# not a fixed requirement and is chosen as fits each data file. +# See the section on defining +# :ref:`NXDL group and field names <RegExpName>`. +# +# Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) +# for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. +# +# .. _NXcanSAS_minimum: +# +# .. rubric:: The minimum required information for a NeXus data file +# written to the NXcanSAS specification. +# +# .. literalinclude:: canSAS/minimum-required.txt +# :tab-width: 4 +# :linenos: +# :language: text +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which :ref:`NXdata` group +# contains the data to be shown by default. +# It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. +# The value is the name of the default :ref:`NXdata` group. +# Usually, this will be the name of the first *SASdata* group. +# +# +# +# .. index:: NXcanSAS (applications); SASentry +# +# Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group +# (when data from multiple techniques are being stored) +# or as a replacement for the ``NXentry`` group. +# +# Note: It is required for all numerical objects to provide +# a *units* attribute that describes the engineering units. +# Use the Unidata UDunits [#]_ specification +# as this is compatible with various community standards. +# +# .. [#] The UDunits specification also includes instructions for derived units. +# +# +# +# Official canSAS group: **SASentry** +# +# +# +# +# +# +# +# Describes the version of the canSAS standard used to write this data. +# This must be a text (not numerical) representation. Such as:: +# +# @version="1.1" +# +# +# +# +# +# +# +# +# Official NeXus NXDL schema to which this subentry conforms. +# +# +# +# +# +# +# +# +# +# A *SASData* group contains a single reduced small-angle scattering data set +# that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. +# +# *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) +# +# The name of each *SASdata* group must be unique within a SASentry group. +# Suggest using names such as ``sasdata01``. +# +# NOTE: For the first *SASdata* group, be sure to write the chosen name +# into the `SASentry/@default` attribute, as in:: +# +# SASentry/@default="sasdata01" +# +# A *SASdata* group has several attributes: +# +# * I_axes +# * Q_indices +# * Mask_indices +# +# To indicate the dependency relationships of other varied parameters, +# use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` +# or ``@Pressure_indices``). +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASdata` +# +# +# +# +# +# +# +# Name of the default data field. +# +# +# For canSAS **SASdata**, this is always "I". +# +# +# +# +# String array that defines the independent data fields used in +# the default plot for all of the dimensions of the *signal* field +# (the *signal* field is the field in this group that is named by +# the ``signal`` attribute of this group). +# One entry is provided for every dimension of the ``I`` data object. +# Such as:: +# +# @I_axes="Temperature", "Time", "Pressure", "Q", "Q" +# +# Since there are five items in the list, the intensity field of this example +# ``I`` must be a five-dimensional array (rank=5). +# +# +# +# +# +# Integer or integer array that describes which indices +# (of the :math:`I` data object) are used to +# reference the ``Q`` data object. The items in this array +# use zero-based indexing. Such as:: +# +# @Q_indices=1,3,4 +# +# which indicates that ``Q`` requires three indices +# from the :math:`I` data object: one for time and +# two for Q position. Thus, in this example, the +# ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. +# +# +# +# +# Name of the data mask field. +# +# .. see: https://github.com/nexusformat/definitions/issues/533 +# +# The data *mask* must have the same shape as the *data* field. +# Positions in the mask correspond to positions in the *data* field. +# The value of the mask field may be either a boolean array +# where ``false`` means *no mask* and ``true`` means *mask* +# or a more descriptive array as as defined in :ref:`NXdetector`. +# +# +# +# +# Integer or integer array that describes which indices +# (of the :math:`I` data object) are used to +# reference the ``Mask`` data object. The items in this +# array use zero-based indexing. Such as:: +# +# @Mask_indices=3,4 +# +# which indicates that Q requires two indices +# from the :math:`I` data object for Q position. +# +# +# +# +# ISO-8601 time [#iso8601]_ +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); Q +# +# Array of :math:`Q` data to accompany :math:`I`. +# +# .. figure:: canSAS/Q-geometry.jpg +# :width: 60% +# +# The :math:`\vec{Q}` geometry. +# (:download:`full image <canSAS/Q-geometry.jpg>`) +# +# :math:`Q` may be represented as either +# the three-dimensional scattering vector :math:`\vec{Q}` +# or the magnitude of the scattering vector, :math:`|\vec{Q}|`. +# +# .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) +# +# When we write :math:`Q`, we may refer to either or both of +# :math:`|\vec{Q}|` +# or :math:`\vec{Q}`, depending on the context. +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units will generate +# a warning from validation software and may not +# be processed by some analysis software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# (optional: for numerical arrays) +# +# Names the dataset (in this SASdata group) that provides the +# uncertainty to be used for data analysis. +# The name of the dataset containing the :math:`Q` uncertainty +# is flexible. The name must be unique in the *SASdata* group. +# +# .. comment +# see: https://github.com/canSAS-org/canSAS2012/issues/7 +# +# Such as:: +# +# @uncertainties="Q_uncertainties" +# +# The *uncertainties* field will have the same *shape* (dimensions) +# as the Q field. +# +# These values are the estimates of uncertainty of each Q. By default, +# this will be interpreted to be the estimated standard deviation. +# In special cases, when a standard deviation cannot possibly be used, +# its value can specify another measure of distribution width. +# +# There may also be a subdirectory (optional) with constituent +# components. +# +# .. note:: To report distribution in reported :math:`Q` values, +# use the ``@resolutions`` attribute. It is possible for both +# ``@resolutions`` and ``uncertainties`` to be reported. +# +# +# +# +# +# .. index:: NXcanSAS (applications); resolutions +# +# (optional: for numerical arrays) +# +# Names the dataset (in this SASdata group) containing the :math:`Q` resolution. +# The name of the dataset containing the :math:`Q` resolution +# is flexible. The name must be unique in the *SASdata* group. +# +# .. comment +# see: https://github.com/canSAS-org/canSAS2012/issues/7 +# +# The *resolutions* field will have the same *shape* (dimensions) +# as the Q field. +# +# Generally, this is the principal resolution of each :math:`Q`. +# Names the data object (in this SASdata group) that provides the +# :math:`Q` resolution to be used for data analysis. Such as:: +# +# @resolutions="Qdev" +# +# To specify two-dimensional resolution for slit-smearing geometry, +# such as (*dQw*, *dQl*), use a string array, such as:: +# +# @resolutions="dQw", "dQl" +# +# There may also be a subdirectory (optional) with constituent +# components. +# +# This pattern will demonstrate how to introduce further as-yet +# unanticipated terms related to the data. +# +# .. comment +# see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 +# +# By default, the values of the resolutions data object are assumed to be +# one standard deviation of any function used to approximate the +# resolution function. This equates to the width of the gaussian +# distribution if a Gaussian is chosen. See the ``@resolutions_description`` +# attribute. +# +# .. note:: To report uncertainty in reported :math:`Q` values, +# use the ``@uncertainties`` attribute. It is possible for both +# ``@resolutions`` and ``uncertainties`` to be reported. +# +# +# +# +# +# (optional) +# Generally, this describes the :math:`Q` ``@resolutions`` data object. +# By default, the value is assumed to be "Gaussian". These are +# suggestions: +# +# * Gaussian +# * Lorentzian +# * Square : +# note that the full width of the square would be ~2.9 times +# the standard deviation specified in the vector +# * Triangular +# * Sawtooth-outward : vertical edge pointing to larger Q +# * Sawtooth-inward vertical edge pointing to smaller Q +# * Bin : range of values contributing +# (for example, when 2-D detector data have been reduced +# to a 1-D :math:`I(|Q|)` dataset) +# +# For other meanings, it may be necessary to provide further details +# such as the function used to assess the resolution. +# In such cases, use additional datasets or a :ref:`NXnote` subgroup +# to include that detail. +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); I +# +# Array of intensity (:math:`I`) data. +# +# The intensity may be represented in one of these forms: +# +# **absolute units**: :math:`d\Sigma/d\Omega(Q)` +# differential cross-section +# per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) +# +# **absolute units**: :math:`d\sigma/d\Omega(Q)` +# differential cross-section +# per unit atom per unit solid angle (such as: cm^2 or m^2) +# +# **arbitrary units**: :math:`I(Q)` +# usually a ratio of two detectors +# but units are meaningless (such as: a.u. or counts) +# +# This presents a few problems +# for analysis software to sort out when reading the data. +# Fortunately, it is possible to analyze the *units* to determine which type of +# intensity is being reported and make choices at the time the file is read. But this is +# an area for consideration and possible improvement. +# +# One problem arises with software that automatically converts data into some canonical +# units used by that software. The software should not convert units between these different +# types of intensity indiscriminately. +# +# A second problem is that when arbitrary units are used, then the set of possible +# analytical results is restricted. With such units, no meaningful volume fraction +# or number density can be determined directly from :math:`I(Q)`. +# +# In some cases, it is possible to apply a factor to convert the arbitrary +# units to an absolute scale. This should be considered as a possibility +# of the analysis process. +# +# Where this documentation says *typical units*, it is possible that small-angle +# data may be presented in other units and still be consistent with NeXus. +# See the :ref:`design-units` section. +# +# +# +# Engineering units to use when expressing +# :math:`I` and intensity-related terms. +# +# Data expressed in other units (or missing a ``@units`` attribute) +# will be treated as ``arbitrary`` by some software packages. +# +# For software using the UDUNITS-2 library, ``arbitrary`` will be +# changed to ``unknown`` for handling with that library. +# +# +# +# includes m2/m3 and 1/m/sr +# +# +# includes cm2/cm3 and 1/cm/sr +# +# +# +# +# +# +# +# +# (optional: for numerical arrays) +# +# Names the dataset (in this SASdata group) that provides the +# uncertainty of :math:`I` to be used for data analysis. +# The name of the dataset containing the :math:`I` uncertainty +# is flexible. The name must be unique in the *SASdata* group. +# +# .. comment +# see: https://github.com/canSAS-org/canSAS2012/issues/7 +# +# Generally, this is the estimate of the uncertainty of each :math:`I`. +# Typically the estimated standard deviation. +# +# *Idev* is the canonical name from the 1D standard. +# The NXcanSAS standard allows for the name to be described using this attribute. +# Such as:: +# +# @uncertainties="Idev" +# +# +# +# +# +# (optional) +# Names the field (a.k.a. dataset) that contains a factor +# to multiply ``I``. By default, this value is unity. +# Should an uncertainty be associated with the scaling factor +# field, the field containing that uncertainty would be +# designated via the ``uncertainties`` attribute. +# Such as:: +# +# I : NX_NUMBER +# @uncertainties="Idev" : NX_CHAR +# @scaling_factor="I_scaling" : NX_CHAR +# Idev : NX_NUMBER +# I_scaling : NX_NUMBER +# @uncertainties="I_scaling_dev" : NX_CHAR +# I_scaling_dev : NX_NUMBER +# +# The exact names for ``I_scaling`` and ``I_scaling_dev`` are not +# defined by NXcanSAS. The user has the flexibility to use names +# different than those shown in this example. +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); Idev +# +# Estimated **uncertainty** (usually standard deviation) +# in :math:`I`. Must have the same units as :math:`I`. +# +# When present, the name of this field is also +# recorded in the *uncertainties* attribute of *I*, as in:: +# +# I/@uncertainties="Idev" +# +# +# +# +# Engineering units to use when expressing +# :math:`I` and intensity-related terms. +# +# Data expressed in other units (or missing a ``@units`` attribute) +# will generate a warning from any validation process +# and will be treated as ``arbitrary`` by some analysis software packages. +# +# For software using the UDUNITS-2 library, ``arbitrary`` will be +# changed to ``unknown`` for handling with that library. +# +# +# +# includes m2/m3 and 1/m/sr +# +# +# includes cm2/cm3 and 1/cm/sr +# +# +# +# +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); Qdev +# +# Estimated :math:`Q` **resolution** (usually standard deviation). +# Must have the same units as :math:`Q`. +# +# When present, the name of this field is also +# recorded in the *resolutions* attribute of *Q*, +# as in:: +# +# Q/@resolutions="Qdev" +# +# or:: +# +# Q/@resolutions="dQw", "dQl" +# +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units may not be processed by some +# software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); dQw +# +# :math:`Q` **resolution** along the axis of scanning +# (the high-resolution *slit width* direction). +# Useful for defining resolution data from +# slit-smearing instruments such as Bonse-Hart geometry. +# Must have the same units as :math:`Q`. +# +# When present, the name of this field is also +# recorded in the *resolutions* attribute of *Q*, +# as in:: +# +# Q/@resolutions="dQw", "dQl" +# +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units may not be processed by some +# software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); dQl +# +# :math:`Q` **resolution** perpendicular to the axis of scanning +# (the low-resolution *slit length* direction). +# Useful for defining resolution data from +# slit-smearing instruments such as Bonse-Hart geometry. +# Must have the same units as :math:`Q`. +# +# When present, the name of this field is also +# recorded in the *resolutions* attribute of *Q*, +# as in:: +# +# Q/@resolutions="dQw", "dQl" +# +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units may not be processed by some +# software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# +# +# Mean value of :math:`Q` for this data point. +# Useful when describing data that has been +# binned from higher-resolution data. +# +# It is expected that ``Q`` is provided +# and that both ``Q`` and ``Qmean`` will have the same units. +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units may not be processed by some +# software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# +# A numerical factor applied to pixels affected by the beam stop penumbra. +# Used in data files from NIST/NCNR instruments. +# +# See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. +# +# +# +# +# +# +# +# +# Title of this *SASentry*. +# Make it so that you can recognize the data by its title. +# Could be the name of the sample, +# the name for the measured data, or something else representative. +# +# +# +# +# Run identification for this *SASentry*. +# For many facilities, this is an integer, such as en experiment number. +# Use multiple instances of ``run`` as needed, keeping +# in mind that HDF5 requires unique names for all entities +# in a group. +# +# +# +# Optional string attribute to identify this particular *run*. +# Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` +# +# +# +# +# +# Description of the small-angle scattering instrument. +# +# Consider, carefully, the relevance to the SAS data analysis process +# when adding subgroups in this **NXinstrument** group. Additional information +# can be added but will likely be ignored by standardized data anlysis processes. +# +# The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** +# group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any +# point downstream from the source. +# +# +# +# +# +# +# :ref:`NXaperture` is generic and limits the variation in data files. +# +# Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASaperture` +# +# +# +# +# +# +# +# describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) +# +# +# +# opening along the :math:`x` axis +# +# +# opening along the :math:`y` axis +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` +# +# +# +# +# +# Description of a collimating element (defines the divergence of the beam) in the instrument. +# +# To document a slit, pinhole, or the beam, refer to the +# documentation of the ``NXinstrument`` group above. +# +# +# +# Amount/length of collimation inserted (as on a SANS instrument) +# +# +# +# Distance from this collimation element to the sample +# +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASdetector` +# +# +# +# +# +# Description of a detector in the instrument. +# +# +# +# Identifies the name of this detector +# +# +# +# Distance between sample and detector. +# +# Note: In NXdetector, the ``distance`` field records the +# distance to the previous component ... most often the sample. +# This use is the same as ``SDD`` for most SAS +# instruments but not all. For example, Bonse-Hart cameras +# have one or more crystals between the sample and detector. +# +# We define here the field ``SDD`` to document without +# ambiguity the distance between sample and detector. +# +# +# +# +# Slit length of the instrument for this detector, +# expressed in the same units as :math:`Q`. +# +# +# +# +# Location of the detector in :math:`x` +# +# +# Location of the detector in :math:`y` +# +# +# Rotation of the detector about the :math:`z` axis (roll) +# +# +# Rotation of the detector about the :math:`x` axis (roll) +# +# +# Rotation of the detector about the :math:`y` axis (yaw) +# +# +# +# +# Position of the beam center on the detector. +# +# This is the x position where the direct beam would hit the detector plane. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. The value can be any +# real number (positive, zero, or negative). +# +# +# +# +# +# Position of the beam center on the detector. +# +# This is the y position where the direct beam would hit the detector plane. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. The value can be any +# real number (positive, zero, or negative). +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASsource` +# +# +# +# +# +# Description of the radiation source. +# +# +# +# +# Name of the radiation used. +# Note that this is **not** the name of the facility! +# +# This field contains a value from either the +# ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, +# it is redundant with existing NeXus structure. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Text description of the shape of the beam (incident on the sample). +# +# +# wavelength (:math:`\lambda`) of radiation incident on the sample +# +# +# +# Some facilities specify wavelength using a range. +# This is the lowest wavelength in such a range. +# +# +# +# +# Some facilities specify wavelength using a range. +# This is the highest wavelength in such a range. +# +# +# +# +# Some facilities specify wavelength using a range. +# This is the width (FWHM) of such a range. +# +# +# +# Size of the incident beam along the x axis. +# +# +# Size of the incident beam along the y axis. +# +# +# +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASsample` +# +# +# +# +# +# Description of the sample. +# +# +# +# **ID**: Text string that identifies this sample. +# +# +# Thickness of this sample +# +# +# +# Transmission (:math:`I/I_0`) of this sample. +# There is no *units* attribute as this number is dimensionless. +# +# Note: the ability to store a transmission *spectrum*, +# instead of a single value, is provided elsewhere in the structure, +# in the *SAStransmission_spectrum* element. +# +# +# +# Temperature of this sample. +# +# +# Any additional sample details. +# +# +# +# Location of the sample in :math:`x` +# +# +# Location of the sample in :math:`y` +# +# +# Rotation of the sample about the :math:`z` axis (roll) +# +# +# Rotation of the sample about the :math:`x` axis (roll) +# +# +# Rotation of the sample about the :math:`y` axis (yaw) +# +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASprocess` +# +# +# +# +# +# Description of a processing or analysis step. +# +# Add additional fields as needed to describe value(s) of any +# variable, parameter, or term related to the *SASprocess* step. +# Be sure to include *units* attributes for all numerical fields. +# +# +# +# Optional name for this data processing or analysis step +# +# +# +# Optional date for this data processing or analysis step. [#iso8601]_ +# +# +# .. [#iso8601] ISO-8601 standard time representation. +# +# NeXus dates and times are reported in ISO-8601 +# (e.g., ``yyyy-mm-ddThh:mm:ss``) +# or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). +# +# See: http://www.w3.org/TR/NOTE-datetime +# or http://en.wikipedia.org/wiki/ISO_8601 for more details. +# +# +# +# Optional description for this data processing or analysis step +# +# +# +# Specifies the value of a single variable, parameter, +# or term (while defined here as a string, it could be a number) +# related to the *SASprocess* step. +# +# Note: +# The name *term* is not required, it could take any name, +# as long as the name is unique within this group. +# +# +# +# +# +# +# Any additional notes or subprocessing steps will be documented here. +# +# An **NXnote** group can be added to any NeXus group at or below the +# **NXentry** group. It is shown here as a suggestion of a good place +# to *consider* its use. +# +# +# +# +# +# Describes anything about *SASprocess* that is not already described. +# +# Any content not defined in the canSAS standard can be placed at this point. +# +# Note: +# The name of this group is flexible, it could take any name, +# as long as it is unique within the **NXprocess** group. +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASnote` +# +# +# +# +# +# +# Free form description of anything not covered by other elements. +# +# +# +# +# +# +# +# The *SAStransmission_spectrum* element +# +# This describes certain data obtained from a variable-wavelength source +# such as pulsed-neutron source. +# +# +# The name of each *SAStransmission_spectrum* group must be unique within a SASentry group. +# Suggest using names such as ``sastransmission_spectrum01``. +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` +# +# +# +# +# +# +# Name of the default data field. +# +# +# For **SAStransmission_spectrum**, this is always "T". +# +# +# +# +# +# the wavelengths field (as a dimension scale) corresponding to this transmission +# +# +# +# +# +# Identify what type of spectrum is being described. +# It is expected that this value will take either of these two values: +# +# ====== ============================================== +# value meaning +# ====== ============================================== +# sample measurement with the sample and container +# can measurement with just the container +# ====== ============================================== +# +# +# +# +# ISO-8601 time [#iso8601]_ +# +# +# +# +# +# Wavelength of the radiation. +# +# This array is of the same shape as ``T`` and ``Tdev``. +# +# +# +# +# Transmission values (:math:`I/I_0`) +# as a function of wavelength. +# +# This array is of the same shape as ``lambda`` and ``Tdev``. +# +# +# +# Names the dataset (in this SASdata group) that provides the +# uncertainty of each transmission :math:`T` to be used for data analysis. +# The name of the dataset containing the :math:`T` uncertainty +# is expected to be ``Tdev``. +# +# .. comment +# see: https://github.com/canSAS-org/canSAS2012/issues/7 +# +# Typically: +# +# @uncertainties="Tdev" +# +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); Tdev +# +# Estimated uncertainty (usually standard deviation) +# in :math:`T`. Must have the same units as :math:`T`. +# +# This is the field is named in the *uncertainties* attribute of *T*, as in:: +# +# T/@uncertainties="Tdev" +# +# This array is of the same shape as ``lambda`` and ``T``. +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXdirecttof.yaml b/applications/nyaml/NXdirecttof.yaml index b460187d81..8ced0bc49d 100644 --- a/applications/nyaml/NXdirecttof.yaml +++ b/applications/nyaml/NXdirecttof.yaml @@ -1,14 +1,13 @@ category: application -doc: | +doc: | This is a application definition for raw data from a direct geometry TOF spectrometer - type: group NXdirecttof(NXtofraw): (NXentry)entry: title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXdirecttof] (NXinstrument): @@ -16,22 +15,88 @@ NXdirecttof(NXtofraw): exists: ['min', '0'] rotation_speed(NX_FLOAT): unit: NX_FREQUENCY - doc: | + doc: | chopper rotation speed energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | energy selected (NXdisk_chopper)disk_chopper: exists: ['min', '0'] rotation_speed(NX_FLOAT): unit: NX_FREQUENCY - doc: | + doc: | chopper rotation speed energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | energy selected - doc: | + doc: | We definitly want the rotation_speed and energy of the chopper. Thus either a fermi_chopper or a disk_chopper group is required. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1d47a6d74aba3fd326b8022400cf62c8d44aa409690508a10b91dce0f188c23c +# +# +# +# +# This is a application definition for raw data from a direct geometry TOF spectrometer +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# chopper rotation speed +# +# +# energy selected +# +# +# +# +# chopper rotation speed +# +# +# energy selected +# +# +# +# We definitly want the rotation_speed and energy of the chopper. Thus either +# a fermi_chopper or a disk_chopper group is required. +# +# +# +# diff --git a/applications/nyaml/NXfluo.yaml b/applications/nyaml/NXfluo.yaml index 7022988c8f..34390473a8 100644 --- a/applications/nyaml/NXfluo.yaml +++ b/applications/nyaml/NXfluo.yaml @@ -1,21 +1,18 @@ category: application -doc: | +doc: | This is an application definition for raw data from an X-ray fluorescence experiment - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nE: | + nE: | Number of energies - type: group NXfluo(NXobject): (NXentry)entry: title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms. enumeration: [NXfluo] (NXinstrument): @@ -39,16 +36,16 @@ NXfluo(NXobject): dim: [[1, nE]] (NXsample): name: - doc: | + doc: | Descriptive name of sample (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor data(NX_INT): (NXdata)data: @@ -56,3 +53,113 @@ NXfluo(NXobject): target: /entry/instrument/fluorescence/energy data(link): target: /entry/instrument/fluorescence/data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a29da208a1ae223c660dcd483b2d1f475272c28538ec79fc7f342883ca2cd321 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of energies +# +# +# +# This is an application definition for raw data from an X-ray fluorescence experiment +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXindirecttof.yaml b/applications/nyaml/NXindirecttof.yaml index 5b64d4a641..ea4502b226 100644 --- a/applications/nyaml/NXindirecttof.yaml +++ b/applications/nyaml/NXindirecttof.yaml @@ -1,43 +1,111 @@ category: application -doc: | +doc: | This is a application definition for raw data from a direct geometry TOF spectrometer - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nDet: | + nDet: | Number of detectors - type: group NXindirecttof(NXtofraw): (NXentry)entry: title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXindirecttof] (NXinstrument): (NXmonochromator)analyser: energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | analyzed energy dimensions: rank: 1 dim: [[1, nDet]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | polar angle towards sample dimensions: rank: 1 dim: [[1, nDet]] distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | distance from sample dimensions: rank: 1 dim: [[1, nDet]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a8938d31a14f39d6935cd347cc25df7c67207c21c5bd8aab84182f83d2681d6e +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of detectors +# +# +# This is a application definition for raw data from a direct geometry TOF spectrometer +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# analyzed energy +# +# +# +# +# polar angle towards sample +# +# +# +# +# distance from sample +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXiqproc.yaml b/applications/nyaml/NXiqproc.yaml index 0ac4fc5ca4..de29062cf5 100644 --- a/applications/nyaml/NXiqproc.yaml +++ b/applications/nyaml/NXiqproc.yaml @@ -1,27 +1,24 @@ category: application -doc: | - Application definition for any ':'math':'`I(Q)` data. - -symbols: - doc: | +doc: | + Application definition for any :math:`I(Q)` data. +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nVars: | + nVars: | The number of values taken by the varied variable - - nQX: | + nQX: | Number of values for the first dimension of Q - - nQY: | + nQY: | Number of values for the second dimension of Q - type: group NXiqproc(NXobject): (NXentry): \@entry: + + # TODO documentation string needed here title: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXiqproc] (NXinstrument)instrument: @@ -31,28 +28,28 @@ NXiqproc(NXobject): probe: enumeration: [neutron, x-ray, electron] name(NX_CHAR): - doc: | + doc: | Name of the instrument from which this data was reduced. (NXsample): name: - doc: | + doc: | Descriptive name of sample (NXprocess)reduction: program(NX_CHAR): version(NX_CHAR): (NXparameters)input: filenames(NX_CHAR): - doc: | + doc: | Raw data files used to generate this I(Q) - doc: | + doc: | Input parameters for the reduction program used (NXparameters)output: - doc: | + doc: | Eventual output parameters from the data reduction program used (NXdata): data(NX_INT): signal: 1 - doc: | + doc: | This is I(Q). The client has to analyse the dimensions of I(Q). Often, multiple I(Q) for various environment conditions are measured; that would be the first @@ -67,19 +64,138 @@ NXiqproc(NXobject): rank: 1 dim: [[1, nVars]] \@varied_variable: - doc: | + doc: | The real name of the varied variable in the first dim of data, temperature, P, MF etc... qx(NX_NUMBER): axis: 2 - doc: | + doc: | Values for the first dimension of Q dimensions: rank: 1 dim: [[1, nQX]] qy(NX_NUMBER): axis: 3 - doc: | + doc: | Values for the second dimension of Q dimensions: rank: 1 dim: [[1, nQY]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 20d4c942462350f47af152e37e83f320e5814be2b399fc9a4897794d1ce4916e +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# The number of values taken by the varied variable +# +# +# Number of values for the first dimension of Q +# +# +# Number of values for the second dimension of Q +# +# +# Application definition for any :math:`I(Q)` data. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name of the instrument from which this data was reduced. +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# Raw data files used to generate this I(Q) +# Input parameters for the reduction program used +# +# Eventual output parameters from the data reduction program used +# +# +# +# This is I(Q). The client has to analyse the dimensions +# of I(Q). Often, multiple I(Q) for various environment +# conditions are measured; that would be the first +# dimension. Q can be multidimensional, this accounts for +# the further dimensions in the data +# +# +# +# +# +# +# +# +# +# +# +# +# The real name of the varied variable in the first dim of data, temperature, P, MF etc... +# +# Values for the first dimension of Q +# +# +# +# Values for the second dimension of Q +# +# +# +# +# diff --git a/applications/nyaml/NXlauetof.yaml b/applications/nyaml/NXlauetof.yaml index 5282cb6b89..60691e613e 100644 --- a/applications/nyaml/NXlauetof.yaml +++ b/applications/nyaml/NXlauetof.yaml @@ -1,39 +1,34 @@ category: application -doc: | +doc: | This is the application definition for a TOF laue diffractometer - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nXPixels: | + nXPixels: | Number of X pixels - - nYPixels: | + nYPixels: | Number of Y pixels - - nTOF: | + nTOF: | Time of flight - type: group NXlauetof(NXobject): (NXentry)entry: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXlauetof] (NXinstrument)instrument: (NXdetector)detector: - doc: | + doc: | This assumes a planar 2D detector. All angles and distances refer to the center of the detector. polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | The polar_angle (two theta) where the detector is placed. azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | The azimuthal angle where the detector is placed. data(NX_INT): signal: 1 @@ -56,10 +51,10 @@ NXlauetof(NXobject): dim: [[1, nTOF]] (NXsample)sample: name: - doc: | + doc: | Descriptive name of sample orientation_matrix(NX_FLOAT): - doc: | + doc: | The orientation matrix according to Busing and Levy conventions. This is not strictly necessary as the UB can always be derived from the data. But @@ -69,7 +64,7 @@ NXlauetof(NXobject): rank: 2 dim: [[1, 3], [2, 3]] unit_cell(NX_FLOAT): - doc: | + doc: | The unit cell, a, b, c, alpha, beta, gamma. Again, not strictly necessary, but normally written. dimensions: @@ -77,15 +72,15 @@ NXlauetof(NXobject): dim: [[1, 6]] (NXmonitor)control: mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor data(NX_INT): - doc: | + doc: | use these attributes ``primary=1 signal=1`` dimensions: rank: 1 @@ -100,3 +95,150 @@ NXlauetof(NXobject): target: /NXentry/NXinstrument/NXdetector/data time_of_flight(link): target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9e664cc6cefa2508344073c6ddcac30bdfaa76a7950aaba871bf13b9f6f72be4 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of X pixels +# +# +# Number of Y pixels +# +# +# Time of flight +# +# +# +# This is the application definition for a TOF laue diffractometer +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# This assumes a planar 2D detector. All angles and distances refer to the center of the +# detector. +# +# +# The polar_angle (two theta) where the detector is placed. +# +# +# The azimuthal angle where the detector is placed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# The orientation matrix according to Busing and +# Levy conventions. This is not strictly necessary as +# the UB can always be derived from the data. But +# let us bow to common usage which includes thie +# UB nearly always. +# +# +# +# +# +# +# +# +# The unit cell, a, b, c, alpha, beta, gamma. +# Again, not strictly necessary, but normally written. +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) or received monitor counts +# (monitor). +# +# +# +# +# +# +# preset value for time or monitor +# +# +# use these attributes ``primary=1 signal=1`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXmonopd.yaml b/applications/nyaml/NXmonopd.yaml index 894635bd2c..f6381a17ce 100644 --- a/applications/nyaml/NXmonopd.yaml +++ b/applications/nyaml/NXmonopd.yaml @@ -1,5 +1,5 @@ category: application -doc: | +doc: | Monochromatic Neutron and X-Ray Powder diffractometer Instrument @@ -7,24 +7,20 @@ doc: | or X-ray beam. This is both suited for a powder diffractometer with a single detector or a powder diffractometer with a position sensitive detector. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - i: | + i: | i is the number of wavelengths - - nDet: | + nDet: | Number of detectors - type: group NXmonopd(NXobject): (NXentry)entry: title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXmonopd] (NXinstrument): @@ -36,7 +32,7 @@ NXmonopd(NXobject): (NXcrystal): wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | Optimum diffracted wavelength dimensions: rank: 1 @@ -49,7 +45,7 @@ NXmonopd(NXobject): dim: [[1, nDet]] data(NX_INT): signal: 1 - doc: | + doc: | detector signal (usually counts) are already corrected for detector efficiency dimensions: @@ -57,33 +53,171 @@ NXmonopd(NXobject): dim: [[1, nDet]] (NXsample): name: - doc: | + doc: | Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Optional rotation angle for the case when the powder diagram has been obtained through an omega-2theta scan like from a traditional single detector powder diffractometer (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor integral(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Total integral monitor counts (NXdata): polar_angle(link): target: /NXentry/NXinstrument/NXdetector/polar_angle - doc: | + doc: | Link to polar angle in /NXentry/NXinstrument/NXdetector data(link): target: /NXentry/NXinstrument/NXdetector/data - doc: | + doc: | Link to data in /NXentry/NXinstrument/NXdetector + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a85a64b0de4e045e8b6275a9ef6309437ba7aaad04f28e31d62f46d4744763c1 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# i is the number of wavelengths +# +# +# Number of detectors +# +# +# +# Monochromatic Neutron and X-Ray Powder diffractometer +# +# Instrument +# definition for a powder diffractometer at a monochromatic neutron +# or X-ray beam. This is both suited for a powder diffractometer +# with a single detector or a powder diffractometer with a position +# sensitive detector. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Optimum diffracted wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# detector signal (usually counts) are already +# corrected for detector efficiency +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# Optional rotation angle for the case when the powder diagram +# has been obtained through an omega-2theta scan like from a +# traditional single detector powder diffractometer +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Total integral monitor counts +# +# +# +# +# Link to polar angle in /NXentry/NXinstrument/NXdetector +# +# +# Link to data in /NXentry/NXinstrument/NXdetector +# +# +# +# diff --git a/applications/nyaml/NXmx.yaml b/applications/nyaml/NXmx.yaml index 19adb459c3..4f3b28e858 100644 --- a/applications/nyaml/NXmx.yaml +++ b/applications/nyaml/NXmx.yaml @@ -1,63 +1,54 @@ category: application -doc: | +doc: | functional application definition for macromolecular crystallography - -symbols: - doc: | +symbols: + doc: | These symbols will be used below to coordinate datasets with the same shape. Most MX x-ray detectors will produce two-dimensional images. Some will produce three-dimensional images, using one of the indices to select a detector module. - - dataRank: | + dataRank: | Rank of the ``data`` field - - nP: | + nP: | Number of scan points - - i: | + i: | Number of detector pixels in the slowest direction - - j: | + j: | Number of detector pixels in the second slowest direction - - k: | + k: | Number of detector pixels in the third slowest direction - - m: | + m: | Number of channels in the incident beam spectrum, if known - - groupIndex: | + groupIndex: | An array of the hierarchical levels of the parents of detector elements or groupings of detector elements. A top-level element or grouping has parent level -1. - type: group NXmx(NXobject): (NXentry): - doc: | + doc: | Note, it is recommended that ``file_name`` and ``file_time`` are included - as attributes at the root of a file that includes ':'ref':'`NXmx`. See - ':'ref':'`NXroot`. + as attributes at the root of a file that includes :ref:`NXmx`. See + :ref:`NXroot`. \@version: exists: optional - doc: | + doc: | Describes the version of the NXmx definition used to write this data. - This must be a text (not numerical) representation. Such as':'':' + This must be a text (not numerical) representation. Such as:: @version="1.0" enumeration: [1.0] title(NX_CHAR): exists: ['min', '0'] start_time(NX_DATE_TIME): - doc: | + doc: | ISO 8601 time/date of the first data point collected in UTC, using the Z suffix to avoid confusion with local time. Note that the time zone of the beamline should be provided in NXentry/NXinstrument/time_zone. end_time(NX_DATE_TIME): exists: ['min', '0'] - doc: | + doc: | ISO 8601 time/date of the last data point collected in UTC, using the Z suffix to avoid confusion with local time. Note that the time zone of the beamline should be provided in @@ -66,20 +57,20 @@ NXmx(NXobject): collection aborts or otherwise prevents accurate recording of the end_time, this field should be omitted. end_time_estimated(NX_DATE_TIME): - doc: | + doc: | ISO 8601 time/date of the last data point collected in UTC, using the Z suffix to avoid confusion with local time. Note that the time zone of the beamline should be provided in NXentry/NXinstrument/time_zone. This field may be filled with a value estimated before an observed value is available. definition: - doc: | + doc: | NeXus NXDL schema to which this file conforms enumeration: [NXmx] (NXdata): data(NX_NUMBER): exists: recommended - doc: | + doc: | For a dimension-2 detector, the rank of the data array will be 3. For a dimension-3 detector, the rank of the data array will be 4. This allows for the introduction of the frame number as the @@ -87,12 +78,16 @@ NXmx(NXobject): dimensions: rank: dataRank dim: [[1, nP], [2, i], [3, j], [4, k]] + dim_parameters: + required: ['false'] (NXsample): name(NX_CHAR): - doc: | + doc: | Descriptive name of sample depends_on(NX_CHAR): - doc: | + + # better type for paths the need to resolve + doc: | This is a requirement to describe for any scan experiment. The axis on which the sample position depends may be stored @@ -103,7 +98,7 @@ NXmx(NXobject): should be set to "." (NXtransformations): exists: ['min', '0'] - doc: | + doc: | This is the recommended location for sample goniometer and other related axes. @@ -123,20 +118,22 @@ NXmx(NXobject): (NXinstrument): name(NX_CHAR): exists: ['min', '1'] - doc: | + + # CAUTION: keep URLs all on one line + doc: | Name of instrument. Consistency with the controlled vocabulary beamline naming in - https':'//mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html + https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html and - https':'//mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html + https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html is highly recommended. \@short_name: exists: optional - doc: | + doc: | Short name for instrument, perhaps the acronym. time_zone(NX_DATE_TIME): exists: recommended - doc: | + doc: | ISO 8601 time_zone offset from UTC. (NXattenuator): exists: ['min', '0'] @@ -145,7 +142,7 @@ NXmx(NXobject): exists: ['min', '0'] (NXdetector_group): exists: recommended - doc: | + doc: | Optional logical grouping of detectors. Each detector is represented as an NXdetector @@ -163,22 +160,22 @@ NXmx(NXobject): in the field group_index, and the level in the hierarchy given in the group_parent field. For example if an x-ray detector group, DET, consists of four detectors in a - rectangular array':'':' + rectangular array:: DTL DTR DLL DLR - We could have':'':' + We could have:: - group_names':' ["DET", "DTL", "DTR", "DLL", "DLR"] - group_index':' [1, 2, 3, 4, 5] - group_parent':' [-1, 1, 1, 1, 1] + group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] + group_index: [1, 2, 3, 4, 5] + group_parent: [-1, 1, 1, 1, 1] group_names(NX_CHAR): - doc: | + doc: | An array of the names of the detectors or the names of hierarchical groupings of detectors. group_index(NX_INT): - doc: | + doc: | An array of unique identifiers for detectors or groupings of detectors. @@ -189,7 +186,7 @@ NXmx(NXobject): rank: 1 dim: [[1, i]] group_parent(NX_INT): - doc: | + doc: | An array of the hierarchical levels of the parents of detectors or groupings of detectors. @@ -198,31 +195,31 @@ NXmx(NXobject): rank: 1 dim: [[1, groupIndex]] (NXdetector): - doc: | + doc: | Normally the detector group will have the name ``detector``. However, in the case of multiple detectors, each detector needs a uniquely named NXdetector. depends_on(NX_CHAR): exists: ['min', '0'] - doc: | + doc: | NeXus path to the detector positioner axis that most directly supports the detector. In the case of a single-module detector, the detector axis chain may start here. (NXtransformations): exists: ['min', '0'] - doc: | + doc: | Location for axes (transformations) to do with the detector. In the case of a single-module detector, the axes of the detector axis chain may be stored here. (NXcollection): exists: ['min', '0'] - doc: | + doc: | Suggested container for detailed non-standard detector information like corrections applied automatically or performance settings. data(NX_NUMBER): exists: recommended - doc: | + doc: | For a dimension-2 detector, the rank of the data array will be 3. For a dimension-3 detector, the rank of the data array will be 4. This allows for the introduction of the frame number as the @@ -230,20 +227,22 @@ NXmx(NXobject): dimensions: rank: dataRank dim: [[1, nP], [2, i], [3, j], [4, k]] + dim_parameters: + required: ['false'] description: exists: recommended - doc: | + doc: | name/manufacturer/model/etc. information. time_per_channel: unit: NX_TIME exists: ['min', '0'] - doc: | + doc: | For a time-of-flight detector this is the scaling factor to convert from the numeric value reported to the flight time for a given measurement. (NXdetector_module): exists: ['min', '1', 'max', 'unbounded'] - doc: | + doc: | Many detectors consist of multiple smaller modules that are operated in sync and store their data in a common dataset. To allow consistent parsing of the experimental geometry, @@ -260,7 +259,7 @@ NXmx(NXobject): Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. data_origin(NX_INT): - doc: | + doc: | A dimension-2 or dimension-3 field which gives the indices of the origin of the hyperslab of data for this module in the main area detector image in the parent NXdetector module. @@ -273,16 +272,16 @@ NXmx(NXobject): dataset with indices (nP, i, j, k) will be an array with indices (i, j, k). - The ':'ref':'`order ` of indices (i, j + The :ref:`order ` of indices (i, j or i, j, k) is slow to fast. data_size(NX_INT): - doc: | + doc: | Two or three values for the size of the module in pixels in each direction. Dimensionality and order of indices is the same as for data_origin. data_stride(NX_INT): exists: ['min', '0'] - doc: | + doc: | Two or three values for the stride of the module in pixels in each direction. By default the stride is [1,1] or [1,1,1], and this is the most likely case. This optional field is @@ -290,7 +289,7 @@ NXmx(NXobject): module_offset(NX_NUMBER): unit: NX_LENGTH exists: ['min', '0'] - doc: | + doc: | Offset of the module in regards to the origin of the detector in an arbitrary direction. \@transformation_type: @@ -302,8 +301,8 @@ NXmx(NXobject): \@depends_on: fast_pixel_direction(NX_NUMBER): unit: NX_LENGTH - doc: | - Values along the direction of ':'ref':'`fastest varying ` + doc: | + Values along the direction of :ref:`fastest varying ` pixel direction. The direction itself is given through the vector attribute. \@transformation_type: @@ -315,8 +314,8 @@ NXmx(NXobject): \@depends_on: slow_pixel_direction(NX_NUMBER): unit: NX_LENGTH - doc: | - Values along the direction of ':'ref':'`slowest varying ` + doc: | + Values along the direction of :ref:`slowest varying ` pixel direction. The direction itself is given through the vector attribute. \@transformation_type: @@ -329,7 +328,7 @@ NXmx(NXobject): distance(NX_FLOAT): unit: NX_LENGTH exists: recommended - doc: | + doc: | Distance from the sample to the beam center. Normally this value is for guidance only, the proper geometry can be found following the depends_on axis chain, @@ -339,7 +338,7 @@ NXmx(NXobject): calculation. distance_derived(NX_BOOLEAN): exists: recommended - doc: | + doc: | Boolean to indicate if the distance is a derived, rather than a primary observation. If distance_derived true or is not specified, the distance is assumed to be derived from detector axis @@ -347,23 +346,23 @@ NXmx(NXobject): dead_time(NX_FLOAT): unit: NX_TIME exists: ['min', '0'] - doc: | + doc: | Detector dead time. count_time(NX_NUMBER): unit: NX_TIME exists: recommended - doc: | + doc: | Elapsed actual counting time. beam_center_derived(NX_BOOLEAN): exists: optional - doc: | + doc: | Boolean to indicate if the distance is a derived, rather than a primary observation. If true or not provided, that value of beam_center_derived is assumed to be true. beam_center_x(NX_FLOAT): unit: NX_LENGTH exists: recommended - doc: | + doc: | This is the x position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as @@ -373,7 +372,7 @@ NXmx(NXobject): beam_center_y(NX_FLOAT): unit: NX_LENGTH exists: recommended - doc: | + doc: | This is the y position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as @@ -382,54 +381,62 @@ NXmx(NXobject): may take precedence if it is not a derived quantity. angular_calibration_applied(NX_BOOLEAN): exists: ['min', '0'] - doc: | + doc: | True when the angular calibration has been applied in the electronics, false otherwise. angular_calibration(NX_FLOAT): exists: ['min', '0'] - doc: | + doc: | Angular calibration data. dimensions: rank: dataRank dim: [[1, i], [2, j], [3, k]] + dim_parameters: + required: ['false'] flatfield_applied(NX_BOOLEAN): exists: ['min', '0'] - doc: | + doc: | True when the flat field correction has been applied in the electronics, false otherwise. flatfield(NX_NUMBER): exists: ['min', '0'] - doc: | + doc: | Flat field correction data. If provided, it is recommended that it be compressed. dimensions: rank: dataRank dim: [[1, i], [2, j], [3, k]] + dim_parameters: + required: ['false'] flatfield_error(NX_NUMBER): exists: ['min', '0', 'max', '0'] - doc: | + doc: | *** Deprecated form. Use plural form *** Errors of the flat field correction data. If provided, it is recommended that it be compressed. dimensions: rank: dataRank dim: [[1, i], [2, j], [3, k]] + dim_parameters: + required: ['false'] flatfield_errors(NX_NUMBER): exists: ['min', '0'] - doc: | + doc: | Errors of the flat field correction data. If provided, it is recommended that it be compressed. dimensions: rank: dataRank dim: [[1, i], [2, j], [3, k]] + dim_parameters: + required: ['false'] pixel_mask_applied(NX_BOOLEAN): exists: ['min', '0'] - doc: | + doc: | True when the pixel mask correction has been applied in the electronics, false otherwise. pixel_mask(NX_INT): exists: recommended - doc: | + doc: | The 32-bit pixel mask for the detector. Can be either one mask for the whole dataset (i.e. an array with indices i, j) or each frame can have its own mask (in which case it would be @@ -437,19 +444,19 @@ NXmx(NXobject): Contains a bit field for each pixel to signal dead, blind, high or otherwise unwanted or undesirable pixels. - They have the following meaning':' - - * bit 0':' gap (pixel with no sensor) - * bit 1':' dead - * bit 2':' under-responding - * bit 3':' over-responding - * bit 4':' noisy - * bit 5':' -undefined- - * bit 6':' pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7':' -undefined- - * bit 8':' user defined mask (e.g. around beamstop) - * bits 9-30':' -undefined- - * bit 31':' virtual pixel (corner pixel with interpolated value) + They have the following meaning: + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under-responding + * bit 3: over-responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) Normal data analysis software would not take pixels into account when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper @@ -475,25 +482,25 @@ NXmx(NXobject): dim: [[1, i], [2, j]] countrate_correction_applied(NX_BOOLEAN): exists: ['min', '0'] - doc: | + doc: | Counting detectors usually are not able to measure all incoming particles, especially at higher count-rates. Count-rate correction is applied to account for these errors. True when count-rate correction has been applied, false otherwise. countrate_correction_lookup_table(NX_NUMBER): - doc: | + doc: | The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count ':'math':'`c` to its corrected value - ':'math':'`countrate\_correction\_lookup\_table[c]`. + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. - ':'math':'`m` denotes the length of the table. + :math:`m` denotes the length of the table. dimensions: rank: 1 dim: [[1, m]] virtual_pixel_interpolation_applied(NX_BOOLEAN): exists: ['min', '0'] - doc: | + doc: | True when virtual pixel interpolation has been applied, false otherwise. When virtual pixel interpolation is applied, values of some pixels may @@ -503,30 +510,30 @@ NXmx(NXobject): their logical pixels. bit_depth_readout(NX_INT): exists: recommended - doc: | + doc: | How many bits the electronics record per pixel. detector_readout_time(NX_FLOAT): unit: NX_TIME exists: ['min', '0'] - doc: | + doc: | Time it takes to read the detector (typically milliseconds). This is important to know for time resolved experiments. frame_time(NX_FLOAT): unit: NX_TIME exists: ['min', '0'] - doc: | + doc: | This is time for each frame. This is exposure_time + readout time. gain_setting(NX_CHAR): exists: ['min', '0'] - doc: | + doc: | The gain setting of the detector. This influences background. This is a detector-specific value meant to document the gain setting of the detector during data collection, for detectors with multiple available gain settings. - Examples of gain settings include':' + Examples of gain settings include: * ``standard`` * ``fast`` @@ -541,7 +548,7 @@ NXmx(NXobject): additional terms to add to the list. saturation_value(NX_NUMBER): exists: ['min', '0'] - doc: | + doc: | The value at which the detector goes into saturation. Data above this value is known to be invalid. @@ -550,7 +557,7 @@ NXmx(NXobject): saturation_value and greater than or equal to the underload_value. underload_value(NX_NUMBER): exists: ['min', '0'] - doc: | + doc: | The lowest value at which pixels for this detector would be reasonably be measured. @@ -559,7 +566,7 @@ NXmx(NXobject): saturation_value and greater than or equal to the underload_value. sensor_material(NX_CHAR): exists: ['min', '1'] - doc: | + doc: | At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. @@ -567,7 +574,7 @@ NXmx(NXobject): sensor_thickness(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1'] - doc: | + doc: | At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. This is the thickness of this @@ -575,14 +582,14 @@ NXmx(NXobject): threshold_energy(NX_FLOAT): unit: NX_ENERGY exists: ['min', '0'] - doc: | + doc: | Single photon counter detectors can be adjusted for a certain energy range in which they work optimally. This is the energy setting for this. If the detector supports multiple thresholds, this is an array. type: exists: ['min', '0'] - doc: | + doc: | Description of type such as scintillator, ccd, pixel, image plate, CMOS, ... @@ -590,7 +597,7 @@ NXmx(NXobject): exists: ['min', '1'] \@flux: exists: optional - doc: | + doc: | Which field contains the measured flux. One of ``flux``, ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. @@ -599,7 +606,7 @@ NXmx(NXobject): incident_wavelength(NX_FLOAT): unit: NX_WAVELENGTH exists: ['min', '1'] - doc: | + doc: | In the case of a monchromatic beam this is the scalar wavelength. @@ -626,15 +633,16 @@ NXmx(NXobject): relative weights in ``incident_wavelength_weights`` as a 2D array. - Note, ':'ref':'`variants ` are a good way + Note, :ref:`variants ` are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value wavelength value is available along with the original spectrum from which it was calibrated. incident_wavelength_weight(NX_FLOAT): exists: ['min', '0'] - deprecated: use incident_wavelength_weights, see https':'//github.com/nexusformat/definitions/issues/837 - doc: | + deprecated: + use incident_wavelength_weights, see https://github.com/nexusformat/definitions/issues/837 + doc: | In the case of a polychromatic beam this is an array of length **m** of the relative weights of the corresponding wavelengths in incident_wavelength. @@ -645,7 +653,7 @@ NXmx(NXobject): corresponding wavelengths in incident_wavelength. incident_wavelength_weights(NX_FLOAT): exists: ['min', '0'] - doc: | + doc: | In the case of a polychromatic beam this is an array of length **m** of the relative weights of the corresponding wavelengths in ``incident_wavelength``. @@ -657,7 +665,7 @@ NXmx(NXobject): incident_wavelength_spread(NX_FLOAT): unit: NX_WAVELENGTH exists: ['min', '0'] - doc: | + doc: | The wavelength spread FWHM for the corresponding wavelength(s) in incident_wavelength. @@ -670,7 +678,7 @@ NXmx(NXobject): flux(NX_FLOAT): unit: NX_FLUX exists: ['min', '0'] - doc: | + doc: | Flux density incident on beam plane area in photons per second per unit area. @@ -679,9 +687,9 @@ NXmx(NXobject): total_flux(NX_FLOAT): unit: NX_FREQUENCY exists: ['min', '0'] - doc: | + doc: | Flux incident on beam plane in photons per second. In other words - this is the ':'ref':'`flux ` integrated + this is the :ref:`flux ` integrated over area. Useful where spatial beam profiles are not known. @@ -691,9 +699,9 @@ NXmx(NXobject): flux_integrated(NX_FLOAT): unit: NX_PER_AREA exists: ['min', '0'] - doc: | + doc: | Flux density incident on beam plane area in photons - per unit area. In other words this is the ':'ref':'`flux ` + per unit area. In other words this is the :ref:`flux ` integrated over time. Useful where temporal beam profiles of flux are not known. @@ -703,8 +711,8 @@ NXmx(NXobject): total_flux_integrated(NX_FLOAT): unit: NX_DIMENSIONLESS exists: ['min', '0'] - doc: | - Flux incident on beam plane in photons. In other words this is the ':'ref':'`flux ` + doc: | + Flux incident on beam plane in photons. In other words this is the :ref:`flux ` integrated over time and area. Useful where temporal beam profiles of flux are not known. @@ -714,7 +722,7 @@ NXmx(NXobject): incident_beam_size(NX_FLOAT): unit: NX_LENGTH exists: recommended - doc: | + doc: | Two-element array of FWHM (if Gaussian or Airy function) or diameters (if top hat) or widths (if rectangular) of the beam in the order x, y @@ -723,15 +731,16 @@ NXmx(NXobject): dim: [[1, 2]] profile(NX_CHAR): exists: recommended - doc: | + doc: | The beam profile, Gaussian, Airy function, top-hat or rectangular. The profile is given in the plane of incidence of the beam on the sample. enumeration: [Gaussian, Airy, top-hat, rectangular] incident_polarisation_stokes(NX_NUMBER): exists: optional - deprecated: use incident_polarization_stokes, see https':'//github.com/nexusformat/definitions/issues/708 - doc: | + deprecated: + use incident_polarization_stokes, see https://github.com/nexusformat/definitions/issues/708 + doc: | Polarization vector on entering beamline component using Stokes notation dimensions: @@ -739,24 +748,997 @@ NXmx(NXobject): dim: [[1, nP], [2, 4]] incident_polarization_stokes(NX_NUMBER): exists: recommended - doc: | + doc: | Polarization vector on entering beamline component using Stokes notation. See - incident_polarization_stokes in ':'ref':'`NXbeam` + incident_polarization_stokes in :ref:`NXbeam` dimensions: rank: 2 dim: [[1, nP], [2, 4]] (NXsource): - doc: | + doc: | The neutron or x-ray storage ring/facility. Note, the NXsource base class has many more fields available, but at present we only require the name. name: exists: ['min', '1'] - doc: | + doc: | Name of source. Consistency with the naming in - https':'//mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html + https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html controlled vocabulary is highly recommended. \@short_name: exists: optional - doc: | + doc: | short name for source, perhaps the acronym + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# eedfcb0d8464a8b20e31394f68e8c6b271c72a38a05d429832c8a60420d8793f +# +# +# +# +# +# +# +# These symbols will be used below to coordinate datasets +# with the same shape. Most MX x-ray detectors will produce +# two-dimensional images. Some will produce three-dimensional +# images, using one of the indices to select a detector module. +# +# +# Rank of the ``data`` field +# +# +# Number of scan points +# +# +# Number of detector pixels in the slowest direction +# +# +# Number of detector pixels in the second slowest direction +# +# +# Number of detector pixels in the third slowest direction +# +# +# Number of channels in the incident beam spectrum, if known +# +# +# +# An array of the hierarchical levels of the parents of detector +# elements or groupings of detector elements. +# A top-level element or grouping has parent level -1. +# +# +# +# +# +# functional application definition for macromolecular crystallography +# +# +# +# +# +# Note, it is recommended that ``file_name`` and ``file_time`` are included +# as attributes at the root of a file that includes :ref:`NXmx`. See +# :ref:`NXroot`. +# +# +# +# +# Describes the version of the NXmx definition used to write this data. +# This must be a text (not numerical) representation. Such as:: +# +# @version="1.0" +# +# +# +# +# +# +# +# +# +# +# ISO 8601 time/date of the first data point collected in UTC, +# using the Z suffix to avoid confusion with local time. +# Note that the time zone of the beamline should be provided in +# NXentry/NXinstrument/time_zone. +# +# +# +# +# +# ISO 8601 time/date of the last data point collected in UTC, +# using the Z suffix to avoid confusion with local time. +# Note that the time zone of the beamline should be provided in +# NXentry/NXinstrument/time_zone. This field should only be +# filled when the value is accurately observed. If the data +# collection aborts or otherwise prevents accurate recording of +# the end_time, this field should be omitted. +# +# +# +# +# +# ISO 8601 time/date of the last data point collected in UTC, +# using the Z suffix to avoid confusion with local time. +# Note that the time zone of the beamline should be provided in +# NXentry/NXinstrument/time_zone. This field may be filled +# with a value estimated before an observed value is available. +# +# +# +# +# NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# For a dimension-2 detector, the rank of the data array will be 3. +# For a dimension-3 detector, the rank of the data array will be 4. +# This allows for the introduction of the frame number as the +# first index. +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# This is a requirement to describe for any scan experiment. +# +# The axis on which the sample position depends may be stored +# anywhere, but is normally stored in the NXtransformations +# group within the NXsample group. +# +# If there is no goniometer, e.g. with a jet, depends_on +# should be set to "." +# +# +# +# +# +# This is the recommended location for sample goniometer +# and other related axes. +# +# This is a requirement to describe for any scan experiment. +# The reason it is optional is mainly to accommodate XFEL +# single shot exposures. +# +# Use of the depends_on field and the NXtransformations group is +# strongly recommended. As noted above this should be an absolute +# requirement to have for any scan experiment. +# +# The reason it is optional is mainly to accommodate XFEL +# single shot exposures. +# +# +# +# +# +# +# +# +# +# +# +# +# Name of instrument. Consistency with the controlled +# vocabulary beamline naming in +# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html +# and +# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html +# is highly recommended. +# +# +# Short name for instrument, perhaps the acronym. +# +# +# +# +# +# ISO 8601 time_zone offset from UTC. +# +# +# +# +# +# +# +# +# +# Optional logical grouping of detectors. +# +# Each detector is represented as an NXdetector +# with its own detector data array. Each detector data array +# may be further decomposed into array sections by use of +# NXdetector_module groups. Detectors can be grouped logically +# together using NXdetector_group. Groups can be further grouped +# hierarchically in a single NXdetector_group (for example, if +# there are multiple detectors at an endstation or multiple +# endstations at a facility). Alternatively, multiple +# NXdetector_groups can be provided. +# +# The groups are defined hierarchically, with names given +# in the group_names field, unique identifying indices given +# in the field group_index, and the level in the hierarchy +# given in the group_parent field. For example if an x-ray +# detector group, DET, consists of four detectors in a +# rectangular array:: +# +# DTL DTR +# DLL DLR +# +# We could have:: +# +# group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] +# group_index: [1, 2, 3, 4, 5] +# group_parent: [-1, 1, 1, 1, 1] +# +# +# +# +# +# An array of the names of the detectors or the names of +# hierarchical groupings of detectors. +# +# +# +# +# +# An array of unique identifiers for detectors or groupings +# of detectors. +# +# Each ID is a unique ID for the corresponding detector or group +# named in the field group_names. The IDs are positive integers +# starting with 1. +# +# +# +# +# +# +# An array of the hierarchical levels of the parents of detectors +# or groupings of detectors. +# +# A top-level grouping has parent level -1. +# +# +# +# +# +# +# Normally the detector group will have the name ``detector``. +# However, in the case of multiple detectors, each detector +# needs a uniquely named NXdetector. +# +# +# +# +# NeXus path to the detector positioner axis that most directly +# supports the detector. In the case of a single-module +# detector, the detector axis chain may start here. +# +# +# +# +# +# Location for axes (transformations) to do with the +# detector. In the case of a single-module detector, the +# axes of the detector axis chain may be stored here. +# +# +# +# +# +# Suggested container for detailed non-standard detector +# information like corrections applied automatically or +# performance settings. +# +# +# +# +# +# For a dimension-2 detector, the rank of the data array will be 3. +# For a dimension-3 detector, the rank of the data array will be 4. +# This allows for the introduction of the frame number as the +# first index. +# +# +# +# +# +# +# +# +# +# +# +# name/manufacturer/model/etc. information. +# +# +# +# +# +# For a time-of-flight detector this is the scaling +# factor to convert from the numeric value reported to +# the flight time for a given measurement. +# +# +# +# +# +# Many detectors consist of multiple smaller modules that are +# operated in sync and store their data in a common dataset. +# To allow consistent parsing of the experimental geometry, +# this application definiton requires all detectors to +# define a detector module, even if there is only one. +# +# This group specifies the hyperslab of data in the data +# array associated with the detector that contains the +# data for this module. If the module is associated with +# a full data array, rather than with a hyperslab within +# a larger array, then a single module should be defined, +# spanning the entire array. +# +# Note, the pixel size is given as values in the array +# fast_pixel_direction and slow_pixel_direction. +# +# +# +# A dimension-2 or dimension-3 field which gives the indices +# of the origin of the hyperslab of data for this module in the +# main area detector image in the parent NXdetector module. +# +# The data_origin is 0-based. +# +# The frame number dimension (nP) is omitted. Thus the +# data_origin field for a dimension-2 dataset with indices (nP, i, j) +# will be an array with indices (i, j), and for a dimension-3 +# dataset with indices (nP, i, j, k) will be an array with indices +# (i, j, k). +# +# The :ref:`order <Design-ArrayStorageOrder>` of indices (i, j +# or i, j, k) is slow to fast. +# +# +# +# +# Two or three values for the size of the module in pixels in +# each direction. Dimensionality and order of indices is the +# same as for data_origin. +# +# +# +# +# Two or three values for the stride of the module in pixels in +# each direction. By default the stride is [1,1] or [1,1,1], +# and this is the most likely case. This optional field is +# included for completeness. +# +# +# +# +# +# Offset of the module in regards to the origin of the detector in an +# arbitrary direction. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Values along the direction of :ref:`fastest varying <Design-ArrayStorageOrder>` +# pixel direction. The direction itself is given through the vector +# attribute. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Values along the direction of :ref:`slowest varying <Design-ArrayStorageOrder>` +# pixel direction. The direction itself is given through the vector +# attribute. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance from the sample to the beam center. +# Normally this value is for guidance only, the proper +# geometry can be found following the depends_on axis chain, +# But in appropriate cases where the dectector distance +# to the sample is observable independent of the axis +# chain, that may take precedence over the axis chain +# calculation. +# +# +# +# +# +# Boolean to indicate if the distance is a derived, rather than +# a primary observation. If distance_derived true or is not specified, +# the distance is assumed to be derived from detector axis +# specifications. +# +# +# +# +# +# Detector dead time. +# +# +# +# +# +# Elapsed actual counting time. +# +# +# +# +# +# Boolean to indicate if the distance is a derived, rather than +# a primary observation. If true or not provided, that value of +# beam_center_derived is assumed to be true. +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the +# detector. This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels as +# documented by the units attribute. Normally, this should +# be derived from the axis chain, but the direct specification +# may take precedence if it is not a derived quantity. +# +# +# +# +# +# This is the y position where the direct beam would hit the +# detector. This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels as +# documented by the units attribute. Normally, this should +# be derived from the axis chain, but the direct specification +# may take precedence if it is not a derived quantity. +# +# +# +# +# +# True when the angular calibration has been applied in the +# electronics, false otherwise. +# +# +# +# +# Angular calibration data. +# +# +# +# +# +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# +# Flat field correction data. If provided, it is recommended +# that it be compressed. +# +# +# +# +# +# +# +# +# +# +# +# *** Deprecated form. Use plural form *** +# Errors of the flat field correction data. If provided, it is recommended +# that it be compressed. +# +# +# +# +# +# +# +# +# +# +# Errors of the flat field correction data. If provided, it is recommended +# that it be compressed. +# +# +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# +# The 32-bit pixel mask for the detector. Can be either one mask +# for the whole dataset (i.e. an array with indices i, j) or +# each frame can have its own mask (in which case it would be +# an array with indices nP, i, j). +# +# Contains a bit field for each pixel to signal dead, +# blind, high or otherwise unwanted or undesirable pixels. +# They have the following meaning: +# +# * bit 0: gap (pixel with no sensor) +# * bit 1: dead +# * bit 2: under-responding +# * bit 3: over-responding +# * bit 4: noisy +# * bit 5: -undefined- +# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) +# * bit 7: -undefined- +# * bit 8: user defined mask (e.g. around beamstop) +# * bits 9-30: -undefined- +# * bit 31: virtual pixel (corner pixel with interpolated value) +# +# Normal data analysis software would not take pixels into account +# when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper +# two bytes would indicate special pixel properties that normally +# would not be a sole reason to reject the intensity value (unless +# lower bits are set. +# +# If the full bit depths is not required, providing a +# mask with fewer bits is permissible. +# +# If needed, additional pixel masks can be specified by +# including additional entries named pixel_mask_N, where +# N is an integer. For example, a general bad pixel mask +# could be specified in pixel_mask that indicates noisy +# and dead pixels, and an additional pixel mask from +# experiment-specific shadowing could be specified in +# pixel_mask_2. The cumulative mask is the bitwise OR +# of pixel_mask and any pixel_mask_N entries. +# +# If provided, it is recommended that it be compressed. +# +# +# +# +# +# +# +# +# Counting detectors usually are not able to measure all incoming particles, +# especially at higher count-rates. Count-rate correction is applied to +# account for these errors. +# +# True when count-rate correction has been applied, false otherwise. +# +# +# +# +# The countrate_correction_lookup_table defines the LUT used for count-rate +# correction. It maps a measured count :math:`c` to its corrected value +# :math:`countrate\_correction\_lookup\_table[c]`. +# +# :math:`m` denotes the length of the table. +# +# +# +# +# +# +# +# True when virtual pixel interpolation has been applied, false otherwise. +# +# When virtual pixel interpolation is applied, values of some pixels may +# contain interpolated values. For example, to account for space between +# readout chips on a module, physical pixels on edges and corners between +# chips may have larger sensor areas and counts may be distributed between +# their logical pixels. +# +# +# +# +# +# How many bits the electronics record per pixel. +# +# +# +# +# +# Time it takes to read the detector (typically milliseconds). +# This is important to know for time resolved experiments. +# +# +# +# +# +# This is time for each frame. This is exposure_time + readout +# time. +# +# +# +# +# +# The gain setting of the detector. This influences +# background. This is a detector-specific value meant +# to document the gain setting of the detector during +# data collection, for detectors with multiple +# available gain settings. +# +# Examples of gain settings include: +# +# * ``standard`` +# * ``fast`` +# * ``auto`` +# * ``high`` +# * ``medium`` +# * ``low`` +# * ``mixed high to medium`` +# * ``mixed medium to low`` +# +# Developers are encouraged to use one of these terms, or to submit +# additional terms to add to the list. +# +# +# +# +# +# The value at which the detector goes into saturation. +# Data above this value is known to be invalid. +# +# For example, given a saturation_value and an underload_value, +# the valid pixels are those less than or equal to the +# saturation_value and greater than or equal to the underload_value. +# +# +# +# +# +# The lowest value at which pixels for this detector +# would be reasonably be measured. +# +# For example, given a saturation_value and an underload_value, +# the valid pixels are those less than or equal to the +# saturation_value and greater than or equal to the underload_value. +# +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the name of this converter material. +# +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. This is the thickness of this +# converter material. +# +# +# +# +# +# Single photon counter detectors can be adjusted for a certain +# energy range in which they work optimally. This is the energy +# setting for this. If the detector supports multiple thresholds, +# this is an array. +# +# +# +# +# +# Description of type such as scintillator, +# ccd, pixel, image +# plate, CMOS, ... +# +# +# +# +# +# +# Which field contains the measured flux. One of ``flux``, +# ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. +# +# Alternatively, the name being indicated could be a link +# to a dataset in an NXmonitor group that records per shot beam data. +# +# +# +# +# In the case of a monchromatic beam this is the scalar +# wavelength. +# +# Several other use cases are permitted, depending on the +# presence or absence of other incident_wavelength_X +# fields. +# +# In the case of a polychromatic beam this is an array of +# length **m** of wavelengths, with the relative weights +# in ``incident_wavelength_weights``. +# +# In the case of a monochromatic beam that varies shot- +# to-shot, this is an array of wavelengths, one for each +# recorded shot. Here, ``incident_wavelength_weights`` and +# incident_wavelength_spread are not set. +# +# In the case of a polychromatic beam that varies shot-to- +# shot, this is an array of length **m** with the relative +# weights in ``incident_wavelength_weights`` as a 2D array. +# +# In the case of a polychromatic beam that varies shot-to- +# shot and where the channels also vary, this is a 2D array +# of dimensions **nP** by **m** (slow to fast) with the +# relative weights in ``incident_wavelength_weights`` as a 2D +# array. +# +# Note, :ref:`variants <Design-Variants>` are a good way +# to represent several of these use cases in a single dataset, +# e.g. if a calibrated, single-value wavelength value is +# available along with the original spectrum from which it +# was calibrated. +# +# +# +# +# +# In the case of a polychromatic beam this is an array of +# length **m** of the relative weights of the corresponding +# wavelengths in incident_wavelength. +# +# In the case of a polychromatic beam that varies shot-to- +# shot, this is a 2D array of dimensions **nP** by **m** +# (slow to fast) of the relative weights of the +# corresponding wavelengths in incident_wavelength. +# +# +# +# +# In the case of a polychromatic beam this is an array of +# length **m** of the relative weights of the corresponding +# wavelengths in ``incident_wavelength``. +# +# In the case of a polychromatic beam that varies shot-to- +# shot, this is a 2D array of dimensions **np** by **m** +# (slow to fast) of the relative weights of the +# corresponding wavelengths in ``incident_wavelength``. +# +# +# +# +# +# The wavelength spread FWHM for the corresponding +# wavelength(s) in incident_wavelength. +# +# In the case of shot-to-shot variation in the wavelength +# spread, this is a 2D array of dimension **nP** by +# **m** (slow to fast) of the spreads of the +# corresponding wavelengths in incident_wavelength. +# +# +# +# +# +# +# +# Flux density incident on beam plane area in photons +# per second per unit area. +# +# In the case of a beam that varies in flux shot-to-shot, +# this is an array of values, one for each recorded shot. +# +# +# +# +# +# Flux incident on beam plane in photons per second. In other words +# this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` integrated +# over area. +# +# Useful where spatial beam profiles are not known. +# +# In the case of a beam that varies in total flux shot-to-shot, +# this is an array of values, one for each recorded shot. +# +# +# +# +# +# Flux density incident on beam plane area in photons +# per unit area. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` +# integrated over time. +# +# Useful where temporal beam profiles of flux are not known. +# +# In the case of a beam that varies in flux shot-to-shot, +# this is an array of values, one for each recorded shot. +# +# +# +# +# +# Flux incident on beam plane in photons. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` +# integrated over time and area. +# +# Useful where temporal beam profiles of flux are not known. +# +# In the case of a beam that varies in total flux shot-to-shot, +# this is an array of values, one for each recorded shot. +# +# +# +# +# +# Two-element array of FWHM (if Gaussian or Airy function) or +# diameters (if top hat) or widths (if rectangular) of the beam +# in the order x, y +# +# +# +# +# +# +# +# +# The beam profile, Gaussian, Airy function, top-hat or +# rectangular. The profile is given in the plane of +# incidence of the beam on the sample. +# +# +# +# +# +# +# +# +# +# +# Polarization vector on entering beamline +# component using Stokes notation +# +# +# +# +# +# +# +# +# Polarization vector on entering beamline +# component using Stokes notation. See +# incident_polarization_stokes in :ref:`NXbeam` +# +# +# +# +# +# +# +# +# +# +# The neutron or x-ray storage ring/facility. Note, the NXsource base class +# has many more fields available, but at present we only require the name. +# +# +# +# Name of source. Consistency with the naming in +# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html +# controlled vocabulary is highly recommended. +# +# +# short name for source, perhaps the acronym +# +# +# +# +# diff --git a/applications/nyaml/NXrefscan.yaml b/applications/nyaml/NXrefscan.yaml index 55bff29970..545d01fd6e 100644 --- a/applications/nyaml/NXrefscan.yaml +++ b/applications/nyaml/NXrefscan.yaml @@ -1,17 +1,14 @@ category: application -doc: | +doc: | This is an application definition for a monochromatic scanning reflectometer. It does not have the information to calculate the resolution since it does not have any apertures. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXrefscan(NXobject): (NXentry)entry: @@ -19,7 +16,7 @@ NXrefscan(NXobject): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXrefscan] (NXinstrument)instrument: @@ -45,7 +42,7 @@ NXrefscan(NXobject): dim: [[1, nP]] (NXsample)sample: name: - doc: | + doc: | Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE @@ -54,16 +51,16 @@ NXrefscan(NXobject): dim: [[1, nP]] (NXmonitor)control: mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor data(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Monitor counts for each step dimensions: rank: 1 @@ -75,3 +72,126 @@ NXrefscan(NXobject): target: /NXentry/NXsample/rotation_angle polar_angle(link): target: /NXentry/NXinstrument/NXdetector/polar_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2292093a2a73147dd621497414bfff4f52e5a2103a0c4b1e5a119e15e005b78f +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# This is an application definition for a monochromatic scanning reflectometer. +# +# It does not have the information to calculate the resolution +# since it does not have any apertures. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Monitor counts for each step +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXreftof.yaml b/applications/nyaml/NXreftof.yaml index 792aa1fbb9..760c7023fe 100644 --- a/applications/nyaml/NXreftof.yaml +++ b/applications/nyaml/NXreftof.yaml @@ -1,20 +1,15 @@ category: application -doc: | +doc: | This is an application definition for raw data from a TOF reflectometer. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - xSize: | + xSize: | xSize description - - ySize: | + ySize: | ySize description - - nTOF: | + nTOF: | nTOF description - type: group NXreftof(NXobject): (NXentry)entry: @@ -22,7 +17,7 @@ NXreftof(NXobject): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXreftof] (NXinstrument)instrument: @@ -30,7 +25,7 @@ NXreftof(NXobject): (NXdisk_chopper)chopper: distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Distance between chopper and sample (NXdetector)detector: data(NX_INT): @@ -41,7 +36,7 @@ NXreftof(NXobject): time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT axis: 3 - doc: | + doc: | Array of time values for each bin in a time-of-flight measurement dimensions: @@ -57,34 +52,163 @@ NXreftof(NXobject): unit: NX_LENGTH (NXsample)sample: name: - doc: | + doc: | Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE (NXmonitor)control: mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): unit: NX_ANY - doc: | + doc: | preset value for time or monitor integral(NX_INT): - doc: | + doc: | Total integral monitor counts time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT axis: 1 - doc: | + doc: | Time channels data(NX_INT): signal: 1 - doc: | + doc: | Monitor counts in each time channel (NXdata)data: data(link): target: /NXentry/NXinstrument/NXdetector/data time_of_flight(link): target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 11c65854a466d2dce2e11e31861b9d33736ed082b3571645b0c3f1feebd16bbd +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# xSize description +# +# +# ySize description +# +# +# nTOF description +# +# +# This is an application definition for raw data from a TOF reflectometer. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# Distance between chopper and sample +# +# +# +# +# +# +# +# +# +# +# +# +# Array of time values for each bin in a time-of-flight +# measurement +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Total integral monitor counts +# +# +# Time channels +# +# +# Monitor counts in each time channel +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXsas.yaml b/applications/nyaml/NXsas.yaml index acee101f71..2e160f0bbc 100644 --- a/applications/nyaml/NXsas.yaml +++ b/applications/nyaml/NXsas.yaml @@ -1,5 +1,5 @@ category: application -doc: | +doc: | Raw, monochromatic 2-D SAS data with an area detector. This is an application definition for raw data (not processed or reduced data) @@ -8,21 +8,17 @@ doc: | and X-ray SAXS data. It covers all raw data from any monochromatic SAS techniques that - use an area detector':' SAS, WSAS, grazing incidence, GISAS + use an area detector: SAS, WSAS, grazing incidence, GISAS It covers all raw data from any SAS techniques that use an area detector and a monochromatic beam. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate fields with the same shape. - - nXPixel: | + nXPixel: | Number of pixels in x direction. - - nYPixel: | + nYPixel: | Number of pixels in y direction. - type: group NXsas(NXobject): (NXentry): @@ -33,31 +29,31 @@ NXsas(NXobject): end_time(NX_DATE_TIME): exists: ['min', '0'] definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms. enumeration: [NXsas] (NXinstrument): (NXsource): type: - doc: | + doc: | Type of radiation source. name: exists: ['min', '0'] - doc: | + doc: | Name of the radiation source. probe: - doc: | + doc: | Name of radiation probe, necessary to compute the sample contrast. enumeration: [neutron, x-ray] (NXmonochromator): wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | - The wavelength (':'math':'`\lambda`) of the radiation. + doc: | + The wavelength (:math:`\lambda`) of the radiation. wavelength_spread(NX_FLOAT): exists: ['min', '0'] - doc: | - delta_lambda/lambda (':'math':'`\Delta\lambda/\lambda`)':' + doc: | + delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): Important for resolution calculations. (NXcollimator): exists: ['min', '0'] @@ -67,11 +63,11 @@ NXsas(NXobject): enumeration: [nxcylinder, nxbox] size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | The collimation length. (NXdetector): data(NX_NUMBER): - doc: | + doc: | This is area detector data, number of x-pixel versus number of y-pixels. @@ -86,15 +82,15 @@ NXsas(NXobject): dim: [[1, nXPixel], [2, nYPixel]] distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | The distance between detector and sample. x_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Physical size of a pixel in x-direction. y_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Physical size of a pixel in y-direction. polar_angle(NX_FLOAT): unit: NX_ANGLE @@ -111,7 +107,7 @@ NXsas(NXobject): beam_center_x(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0'] - doc: | + doc: | This is the x position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. @@ -122,7 +118,7 @@ NXsas(NXobject): beam_center_y(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0'] - doc: | + doc: | This is the y position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. @@ -131,12 +127,12 @@ NXsas(NXobject): the raw data, thus it is not required here. The instrument can provide an initial or nominal value to advise data reduction. name(NX_CHAR): - doc: | + doc: | Name of the instrument actually used to perform the experiment. (NXsample): exists: ['min', '0'] name: - doc: | + doc: | Descriptive name of sample. aequatorial_angle(NX_FLOAT): unit: NX_ANGLE @@ -144,23 +140,230 @@ NXsas(NXobject): (NXmonitor): exists: ['min', '0'] mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | Preset value for time or monitor. integral(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Total integral monitor counts. (NXdata): \@signal: exists: optional - doc: | + doc: | Name the *plottable* field. The link here defines this name as ``data``. enumeration: [data] data(link): target: /NXentry/NXinstrument/NXdetector/data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2aa6302899fe37644b84e8ae5fba65adf3e17563e6bf42afe1beee8007b93ff5 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate fields with the same shape. +# +# +# Number of pixels in x direction. +# +# +# Number of pixels in y direction. +# +# +# +# Raw, monochromatic 2-D SAS data with an area detector. +# +# This is an application definition for raw data (not processed or reduced data) +# from a 2-D small angle scattering instrument collected with a monochromatic +# beam and an area detector. It is meant to be suitable both for neutron SANS +# and X-ray SAXS data. +# +# It covers all raw data from any monochromatic SAS techniques that +# use an area detector: SAS, WSAS, grazing incidence, GISAS +# +# It covers all raw data from any SAS techniques that use an area detector and +# a monochromatic beam. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# Type of radiation source. +# +# +# Name of the radiation source. +# +# +# +# Name of radiation probe, necessary to compute the sample contrast. +# +# +# +# +# +# +# +# +# +# The wavelength (:math:`\lambda`) of the radiation. +# +# +# +# delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): +# Important for resolution calculations. +# +# +# +# +# +# +# +# +# +# +# +# +# +# The collimation length. +# +# +# +# +# +# +# +# This is area detector data, number of x-pixel versus +# number of y-pixels. +# +# Since the beam center is to be determined as a step of data +# reduction, it is not necessary to document or assume the position of +# the beam center in acquired data. +# +# It is necessary to define which are the x and y directions, to coordinate +# with the pixel size and compute Q. +# +# +# +# +# +# +# +# The distance between detector and sample. +# +# +# Physical size of a pixel in x-direction. +# +# +# Physical size of a pixel in y-direction. +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. +# This is a length, not a pixel position, and can be outside of the +# actual detector. +# +# It is expected that data reduction will determine beam center from +# the raw data, thus it is not required here. The instrument can +# provide an initial or nominal value to advise data reduction. +# +# +# +# +# This is the y position where the direct beam would hit the detector. +# This is a length, not a pixel position, and can be outside of the +# actual detector. +# +# It is expected that data reduction will determine beam center from +# the raw data, thus it is not required here. The instrument can +# provide an initial or nominal value to advise data reduction. +# +# +# +# +# Name of the instrument actually used to perform the experiment. +# +# +# +# +# Descriptive name of sample. +# +# +# +# +# +# +# Count to a preset value based on either clock time +# (timer) or received monitor counts (monitor). +# +# +# +# +# +# +# +# Preset value for time or monitor. +# +# +# Total integral monitor counts. +# +# +# +# +# +# Name the *plottable* field. The link here defines this name as +# ``data``. +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXsastof.yaml b/applications/nyaml/NXsastof.yaml index 09fd6dda0b..4a3530a29a 100644 --- a/applications/nyaml/NXsastof.yaml +++ b/applications/nyaml/NXsastof.yaml @@ -1,43 +1,38 @@ category: application -doc: | +doc: | raw, 2-D SAS data with an area detector with a time-of-flight source It covers all raw data from any SAS techniques that use an area detector at a time-of-flight source. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nXPixel: | + nXPixel: | nXPixel description - - nYPixel: | + nYPixel: | nYPixel description - - nTOF: | + nTOF: | nTOF description - type: group NXsastof(NXobject): (NXentry): \@entry: - doc: | + doc: | NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXsastof] (NXinstrument)instrument: (NXsource)source: type: - doc: | + doc: | type of radiation source name: - doc: | + doc: | Name of the radiation source probe: enumeration: [neutron, x-ray] @@ -48,12 +43,12 @@ NXsastof(NXobject): enumeration: [nxcylinder, nxbox] size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | The collimation length (NXdetector)detector: data(NX_NUMBER): signal: 1 - doc: | + doc: | This is area detector data, of number of x-pixel versus number of y-pixels. Since the beam center is to be determined as a step of data reduction, it is not necessary @@ -69,15 +64,15 @@ NXsastof(NXobject): dim: [[1, nTOF]] distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | The distance between detector and sample x_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Physical size of a pixel in x-direction y_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Size of a pixel in y direction polar_angle(NX_FLOAT): unit: NX_ANGLE @@ -89,30 +84,30 @@ NXsastof(NXobject): unit: NX_ANGLE beam_center_x(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the x position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. beam_center_y(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the y position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. name(NX_CHAR): - doc: | + doc: | Name of the instrument actually used to perform the experiment (NXsample)sample: name: - doc: | + doc: | Descriptive name of sample aequatorial_angle(NX_FLOAT): unit: NX_ANGLE (NXmonitor)control: mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor data(NX_INT): primary: 1 @@ -130,3 +125,188 @@ NXsastof(NXobject): target: /NXentry/NXinstrument/NXdetector/data time_of_flight(link): target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 18b43c8a5ad4926ae6e06b953df9d44c87db9e7f47f4f7e99e072f3950620660 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# nXPixel description +# +# +# nYPixel description +# +# +# nTOF description +# +# +# +# raw, 2-D SAS data with an area detector with a time-of-flight source +# +# It covers all raw data from any SAS techniques +# that use an area detector +# at a time-of-flight source. +# +# +# +# NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# type of radiation source +# +# +# Name of the radiation source +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The collimation length +# +# +# +# +# +# +# +# This is area detector data, of number of x-pixel versus +# number of y-pixels. Since the beam center is to be +# determined as a step of data reduction, it is not necessary +# to document or assume the position of the beam center in +# acquired data. +# +# +# +# +# +# +# +# +# +# +# +# +# The distance between detector and sample +# +# +# Physical size of a pixel in x-direction +# +# +# Size of a pixel in y direction +# +# +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. This is a +# length, not a pixel position, and can be outside of the actual detector. +# +# +# +# +# This is the y position where the direct beam would hit the detector. This is a +# length, not a pixel position, and can be outside of the actual detector. +# +# +# +# +# Name of the instrument actually used to perform the experiment +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) or received monitor counts (monitor). +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXscan.yaml b/applications/nyaml/NXscan.yaml index 978b9ee36b..38f6e0107c 100644 --- a/applications/nyaml/NXscan.yaml +++ b/applications/nyaml/NXscan.yaml @@ -1,43 +1,38 @@ category: application -doc: | +doc: | Application definition for a generic scan instrument. This definition is more an example then a stringent definition as the content of a given NeXus scan file needs to differ for different types of scans. This example definition shows a scan like done - on a rotation camera':' the sample is rotated and a detector image, the rotation angle + on a rotation camera: the sample is rotated and a detector image, the rotation angle and a monitor value is stored at each step in the scan. In the following, the symbol ``NP`` is used to represent the number of scan points. These are the rules for - storing scan data in NeXus files which are implemented in this example':' + storing scan data in NeXus files which are implemented in this example: * Each value varied throughout a scan is stored as an array of length ``NP`` at its respective location within the NeXus hierarchy. * For area detectors, ``NP`` is the first dimension, - example for a detector of 256x256':' ``data[NP,256,256]`` + example for a detector of 256x256: ``data[NP,256,256]`` * The NXdata group contains links to all variables varied in the scan and the data. This to give an equivalent to the more familiar classical tabular representation of scans. - These rules exist for a reason':' HDF allows the first dimension of a data set to be + These rules exist for a reason: HDF allows the first dimension of a data set to be unlimited. This means the data can be appended too. Thus a NeXus file built according - to the rules given above can be used in the following way':' + to the rules given above can be used in the following way: * At the start of a scan, write all the static information. * At each scan point, append new data from varied variables and the detector to the file. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - - xDim: | + xDim: | xDim description - - yDim: | + yDim: | yDim description - type: group NXscan(NXobject): (NXentry): @@ -45,7 +40,7 @@ NXscan(NXobject): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition(NX_CHAR): - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXscan] (NXinstrument): @@ -71,3 +66,116 @@ NXscan(NXobject): target: /NXentry/NXinstrument/NXdetector/data rotation_angle(link): target: /NXentry/NXsample/rotation_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0a6ad9072ad7a42beaa653d148ef9e0187624de64ae1a25be57d67eebe991360 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# xDim description +# +# +# yDim description +# +# +# +# Application definition for a generic scan instrument. +# +# This definition is more an +# example then a stringent definition as the content of a given NeXus scan file needs to +# differ for different types of scans. This example definition shows a scan like done +# on a rotation camera: the sample is rotated and a detector image, the rotation angle +# and a monitor value is stored at each step in the scan. In the following, the symbol +# ``NP`` is used to represent the number of scan points. These are the rules for +# storing scan data in NeXus files which are implemented in this example: +# +# * Each value varied throughout a scan is stored as an array of +# length ``NP`` at its respective location within the NeXus hierarchy. +# * For area detectors, ``NP`` is the first dimension, +# example for a detector of 256x256: ``data[NP,256,256]`` +# * The NXdata group contains links to all variables varied in the scan and the data. +# This to give an equivalent to the more familiar classical tabular representation of scans. +# +# These rules exist for a reason: HDF allows the first dimension of a data set to be +# unlimited. This means the data can be appended too. Thus a NeXus file built according +# to the rules given above can be used in the following way: +# +# * At the start of a scan, write all the static information. +# * At each scan point, append new data from varied variables +# and the detector to the file. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXspe.yaml b/applications/nyaml/NXspe.yaml index 6ef8843c1f..7dfb5be0a6 100644 --- a/applications/nyaml/NXspe.yaml +++ b/applications/nyaml/NXspe.yaml @@ -1,27 +1,26 @@ category: application -doc: | +doc: | NXSPE Inelastic Format. Application definition for NXSPE file format. - type: group NXspe(NXobject): (NXentry): program_name: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms. \@version: enumeration: [NXspe] (NXcollection)NXSPE_info: fixed_energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | The fixed energy used for this file. ki_over_kf_scaling(NX_BOOLEAN): - doc: | + doc: | Indicates whether ki/kf scaling has been applied or not. psi(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Orientation angle as expected in DCS-MSlice (NXdata)data: azimuthal(NX_FLOAT): @@ -49,3 +48,81 @@ NXspe(NXobject): seblock(NX_CHAR): temperature(NX_NUMBER): unit: NX_TEMPERATURE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# eec08fb3a92ba08c09d8ecb18e13c7703abf71c6e532786d2685d1c7979e52b3 +# +# +# +# +# NXSPE Inelastic Format. Application definition for NXSPE file format. +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# The fixed energy used for this file. +# +# +# Indicates whether ki/kf scaling has been applied or not. +# +# +# Orientation angle as expected in DCS-MSlice +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXsqom.yaml b/applications/nyaml/NXsqom.yaml index ed3f8680f2..c29c5e622c 100644 --- a/applications/nyaml/NXsqom.yaml +++ b/applications/nyaml/NXsqom.yaml @@ -1,26 +1,23 @@ category: application -doc: | +doc: | This is the application definition for S(Q,OM) processed data. As this kind of data is in general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their intensity, table like. It is the task of a possible visualisation program to regrid this data in a sensible way. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXsqom(NXobject): (NXentry): \@entry: title: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXsqom] (NXinstrument)instrument: @@ -30,28 +27,28 @@ NXsqom(NXobject): probe: enumeration: [neutron, x-ray, electron] name(NX_CHAR): - doc: | + doc: | Name of the instrument from which this data was reduced. (NXsample): name: - doc: | + doc: | Descriptive name of sample (NXprocess)reduction: program(NX_CHAR): version(NX_CHAR): (NXparameters)input: filenames(NX_CHAR): - doc: | + doc: | Raw data files used to generate this I(Q) - doc: | + doc: | Input parameters for the reduction program used (NXparameters)output: - doc: | + doc: | Eventual output parameters from the data reduction program used (NXdata): data(NX_INT): signal: 1 - doc: | + doc: | This is the intensity for each point in QE dimensions: rank: 1 @@ -59,7 +56,7 @@ NXsqom(NXobject): qx(NX_NUMBER): axis: 1 unit: NX_WAVENUMBER - doc: | + doc: | Positions for the first dimension of Q dimensions: rank: 1 @@ -67,7 +64,7 @@ NXsqom(NXobject): qy(NX_NUMBER): axis: 1 unit: NX_WAVENUMBER - doc: | + doc: | Positions for the the second dimension of Q dimensions: rank: 1 @@ -75,7 +72,7 @@ NXsqom(NXobject): qz(NX_NUMBER): axis: 1 unit: NX_WAVENUMBER - doc: | + doc: | Positions for the the third dimension of Q dimensions: rank: 1 @@ -83,8 +80,132 @@ NXsqom(NXobject): en(NX_FLOAT): axis: 1 unit: NX_ENERGY - doc: | + doc: | Values for the energy transfer for each point dimensions: rank: 1 dim: [[1, nP]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c4bc88346556a87d052d23ac72e3681fbbc83804dd30c5cf7656e54595f43e97 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# This is the application definition for S(Q,OM) processed data. +# +# As this kind of data is in +# general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their +# intensity, table like. It is the task of a possible visualisation program to regrid this data in +# a sensible way. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name of the instrument from which this data was reduced. +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# Raw data files used to generate this I(Q) +# +# Input parameters for the reduction program used +# +# +# Eventual output parameters from the data reduction program used +# +# +# +# +# This is the intensity for each point in QE +# +# +# +# +# +# Positions for the first dimension of Q +# +# +# +# +# +# Positions for the the second dimension of Q +# +# +# +# +# +# Positions for the the third dimension of Q +# +# +# +# +# +# Values for the energy transfer for each point +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXstxm.yaml b/applications/nyaml/NXstxm.yaml index a696f1b278..a2a6c1fc8b 100644 --- a/applications/nyaml/NXstxm.yaml +++ b/applications/nyaml/NXstxm.yaml @@ -1,5 +1,5 @@ category: application -doc: | +doc: | Application definition for a STXM instrument. The interferometer @@ -14,26 +14,19 @@ doc: | fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' are just sample_image scan types with reduced dimensions in the same way as single images have reduced E dimensions compared to image 'stacks'. - -symbols: - doc: | +symbols: + doc: | These symbols will be used below to coordinate the shapes of the datasets. - - nP: | + nP: | Total number of scan points - - nE: | + nE: | Number of photon energies scanned - - nX: | + nX: | Number of pixels in X direction - - nY: | + nY: | Number of pixels in Y direction - - detectorRank: | + detectorRank: | Rank of data array provided by the detector for a single measurement - type: group NXstxm(NXobject): (NXentry): @@ -42,7 +35,7 @@ NXstxm(NXobject): end_time(NX_DATE_TIME): definition(NX_CHAR): exists: ['min', '1', 'max', '1'] - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXstxm] (NXinstrument): @@ -67,7 +60,7 @@ NXstxm(NXobject): data(NX_NUMBER): dimensions: rank: 1+detectorRank - doc: | + doc: | Detector data should be presented with the first dimension corresponding to the scan point and subsequent dimensions corresponding to the output of the detector. Detectors that provide more than one value per scan point should have @@ -75,11 +68,11 @@ NXstxm(NXobject): scan point. For example, an area detector should have an NXdetector data array of 3 dimensions, with the first being the set of scan points and the latter two being the x- and y- extent of the detector. - NOTE':' For each dimension > 1 there must exist a dim section such as':' + NOTE: For each dimension > 1 there must exist a dim section such as: dim: [[1, nP]] (NXdetector)sample_x: exists: ['min', '0', 'max', '1'] - doc: | + doc: | Measurements of the sample position from the x-axis interferometer. data(NX_FLOAT): dimensions: @@ -87,7 +80,7 @@ NXstxm(NXobject): dim: [[1, nP]] (NXdetector)sample_y: exists: ['min', '0', 'max', '1'] - doc: | + doc: | Measurements of the sample position from the y-axis interferometer. data(NX_FLOAT): dimensions: @@ -95,7 +88,7 @@ NXstxm(NXobject): dim: [[1, nP]] (NXdetector)sample_z: exists: ['min', '0', 'max', '1'] - doc: | + doc: | Measurements of the sample position from the z-axis interferometer. data(NX_FLOAT): dimensions: @@ -106,26 +99,26 @@ NXstxm(NXobject): (NXdata): stxm_scan_type: exists: ['min', '1', 'max', '1'] - doc: | + doc: | Label for typical scan types as a convenience for humans. Each label corresponds to a specific set of axes being scanned - to produce a data array of shape':' + to produce a data array of shape: - * sample point spectrum':' (photon_energy,) - * sample line spectrum':' (photon_energy, sample_y/sample_x) - * sample image':' (sample_y, sample_x) - * sample image stack':' (photon_energy, sample_y, sample_x) - * sample focus':' (zoneplate_z, sample_y/sample_x) - * osa image':' (osa_y, osa_x) - * osa focus':' (zoneplate_z, osa_y/osa_x) - * detector image':' (detector_y, detector_x) + * sample point spectrum: (photon_energy,) + * sample line spectrum: (photon_energy, sample_y/sample_x) + * sample image: (sample_y, sample_x) + * sample image stack: (photon_energy, sample_y, sample_x) + * sample focus: (zoneplate_z, sample_y/sample_x) + * osa image: (osa_y, osa_x) + * osa focus: (zoneplate_z, osa_y/osa_x) + * detector image: (detector_y, detector_x) The "generic scan" string is to be used when none of the other choices are appropriate. enumeration: [sample point spectrum, sample line spectrum, sample image, sample image stack, sample focus, osa image, osa focus, detector image, generic scan] data(NX_NUMBER): signal: 1 - doc: | + doc: | Detectors that provide more than one value per scan point should be summarised to a single value per scan point for this array in order to simplify plotting. @@ -136,7 +129,7 @@ NXstxm(NXobject): x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. energy(NX_FLOAT): exists: ['min', '1', 'max', '1'] - doc: | + doc: | List of photon energies of the X-ray beam. If scanned through multiple values, then an 'axis' attribute will be required to link the field to the appropriate data array dimension. dimensions: @@ -144,7 +137,7 @@ NXstxm(NXobject): dim: [[1, nE]] sample_y(NX_FLOAT): exists: ['min', '1', 'max', '1'] - doc: | + doc: | List of Y positions on the sample. If scanned through multiple values, then an 'axis' attribute will be required to link the field to the appropriate data array dimension. dimensions: @@ -152,7 +145,7 @@ NXstxm(NXobject): dim: [[1, nY]] sample_x(NX_FLOAT): exists: ['min', '1', 'max', '1'] - doc: | + doc: | List of X positions on the sample. If scanned through multiple values, then an 'axis' attribute will be required to link the field to the appropriate data array dimension. dimensions: @@ -161,7 +154,213 @@ NXstxm(NXobject): (NXmonitor)control: exists: ['min', '0', 'max', '1'] data(NX_FLOAT): - doc: | + doc: | Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the NXdata groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4a65935ad78db0a1652d7fceb67425791cfecf0a6a2f24683a5798f866c9d60c +# +# +# +# +# +# +# These symbols will be used below to coordinate the shapes of the datasets. +# +# +# Total number of scan points +# +# +# Number of photon energies scanned +# +# +# Number of pixels in X direction +# +# +# Number of pixels in Y direction +# +# +# Rank of data array provided by the detector for a single measurement +# +# +# +# Application definition for a STXM instrument. +# +# The interferometer +# position measurements, monochromator photon energy values and +# detector measurements are all treated as NXdetectors and stored +# within the NXinstrument group as lists of values stored in +# chronological order. The NXdata group then holds another version +# of the data in a regular 3D array (NumE by NumY by NumX, for a +# total of nP points in a sample image stack type scan). The former +# data values should be stored with a minimum loss of precision, while +# the latter values can be simplified and/or approximated in order to +# fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' +# are just sample_image scan types with reduced dimensions in the same way +# as single images have reduced E dimensions compared to image 'stacks'. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Detector data should be presented with the first dimension corresponding to the +# scan point and subsequent dimensions corresponding to the output of the detector. +# Detectors that provide more than one value per scan point should have +# a data array of rank 1+d, where d is the dimensions of the array provided per +# scan point. For example, an area detector should have an NXdetector data array +# of 3 dimensions, with the first being the set of scan points and the latter +# two being the x- and y- extent of the detector. +# NOTE: For each dimension > 1 there must exist a dim section such as: +# +# +# +# +# +# +# Measurements of the sample position from the x-axis interferometer. +# +# +# +# +# +# +# +# Measurements of the sample position from the y-axis interferometer. +# +# +# +# +# +# +# +# Measurements of the sample position from the z-axis interferometer. +# +# +# +# +# +# +# +# +# +# +# +# +# Label for typical scan types as a convenience for humans. +# Each label corresponds to a specific set of axes being scanned +# to produce a data array of shape: +# +# * sample point spectrum: (photon_energy,) +# * sample line spectrum: (photon_energy, sample_y/sample_x) +# * sample image: (sample_y, sample_x) +# * sample image stack: (photon_energy, sample_y, sample_x) +# * sample focus: (zoneplate_z, sample_y/sample_x) +# * osa image: (osa_y, osa_x) +# * osa focus: (zoneplate_z, osa_y/osa_x) +# * detector image: (detector_y, detector_x) +# +# The "generic scan" string is to be used when none of the +# other choices are appropriate. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Detectors that provide more than one value per scan point should be summarised +# to a single value per scan point for this array in order to simplify plotting. +# +# Note that 'Line scans' and focus type scans measure along one spatial dimension +# but are not restricted to being parallel to the X or Y axes. Such scans +# should therefore use a single dimension for the positions along the spatial +# line. The 'sample_x' and 'sample_y' fields should then contain lists of the +# x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. +# +# +# List of photon energies of the X-ray beam. If scanned through multiple values, +# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. +# +# +# +# +# +# List of Y positions on the sample. If scanned through multiple values, +# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. +# +# +# +# +# +# List of X positions on the sample. If scanned through multiple values, +# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. +# +# +# +# +# +# +# +# Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring +# electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the +# NXdata groups. +# +# +# +# diff --git a/applications/nyaml/NXtas.yaml b/applications/nyaml/NXtas.yaml index 679a64f34a..8e734d65c4 100644 --- a/applications/nyaml/NXtas.yaml +++ b/applications/nyaml/NXtas.yaml @@ -1,24 +1,21 @@ category: application -doc: | +doc: | This is an application definition for a triple axis spectrometer. It is for the trademark scan of the TAS, the Q-E scan. - For your alignment scans use the rules in ':'ref':'`NXscan`. - -symbols: - doc: | + For your alignment scans use the rules in :ref:`NXscan`. +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXtas(NXobject): (NXentry)entry: title(NX_CHAR): start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXtas] (NXinstrument): @@ -68,7 +65,7 @@ NXtas(NXobject): dim: [[1, nP]] (NXsample): name: - doc: | + doc: | Descriptive name of sample qh(NX_FLOAT): unit: NX_DIMENSIONLESS @@ -126,22 +123,22 @@ NXtas(NXobject): dim: [[1, 9]] (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor data(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Total integral monitor counts dimensions: rank: 1 dim: [[1, nP]] (NXdata): - doc: | + doc: | One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis ei(link): target: /NXentry/NXinstrument/monochromator:NXcrystal/ei @@ -157,3 +154,197 @@ NXtas(NXobject): target: /NXentry/NXsample/ql data(link): target: /NXentry/NXinstrument/NXdetector/data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3e1396fcfde956ea2d5e48260644bed60a7bf6a088df0c0b5d9928c3fae99fa0 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# This is an application definition for a triple axis spectrometer. +# +# It is for the trademark scan of the TAS, the Q-E scan. +# For your alignment scans use the rules in :ref:`NXscan`. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Total integral monitor counts +# +# +# +# +# +# One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtofnpd.yaml b/applications/nyaml/NXtofnpd.yaml index cb6ea8714d..29927992f3 100644 --- a/applications/nyaml/NXtofnpd.yaml +++ b/applications/nyaml/NXtofnpd.yaml @@ -1,31 +1,27 @@ category: application -doc: | +doc: | This is a application definition for raw data from a TOF neutron powder diffractometer - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nDet: | + nDet: | Number of detectors - - nTimeChan: | + nTimeChan: | nTimeChan description - type: group NXtofnpd(NXobject): (NXentry)entry: title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXtofnpd] pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the flight path before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words':' it the distance to the component + by the moderator or the source itself. In other words: it the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. (NXuser)user: @@ -44,7 +40,7 @@ NXtofnpd(NXobject): dim: [[1, nDet]] distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | distance to sample for each detector dimensions: rank: 1 @@ -57,30 +53,30 @@ NXtofnpd(NXobject): dim: [[1, nTimeChan]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | polar angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | azimuthal angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] (NXsample): name: - doc: | + doc: | Descriptive name of sample (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor distance(NX_FLOAT): unit: NX_LENGTH @@ -102,3 +98,136 @@ NXtofnpd(NXobject): target: /NXentry/NXinstrument/NXdetector/detector_number time_of_flight(link): target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 76efa47955dd8ce499a361753ff2a4da1b9c9771c4cbfff8d5def96ed4ca69bd +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of detectors +# +# +# nTimeChan description +# +# +# This is a application definition for raw data from a TOF neutron powder diffractometer +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# This is the flight path before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# distance to sample for each detector +# +# +# +# +# +# +# +# polar angle for each detector element +# +# +# +# +# azimuthal angle for each detector element +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtofraw.yaml b/applications/nyaml/NXtofraw.yaml index 2d30efd9ca..0f3547c556 100644 --- a/applications/nyaml/NXtofraw.yaml +++ b/applications/nyaml/NXtofraw.yaml @@ -1,33 +1,29 @@ category: application -doc: | +doc: | This is an application definition for raw data from a generic TOF instrument - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nDet: | + nDet: | Number of detectors - - nTimeChan: | + nTimeChan: | nTimeChan description - type: group NXtofraw(NXobject): (NXentry)entry: title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXtofraw] duration(NX_FLOAT): run_number(NX_INT): pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the flight path before the sample position. This can be determined by a chopper, - by the moderator, or the source itself. In other words':' it is the distance to the component + by the moderator, or the source itself. In other words: it is the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. (NXuser)user: @@ -46,7 +42,7 @@ NXtofraw(NXobject): dim: [[1, nDet]] distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | distance to sample for each detector dimensions: rank: 1 @@ -59,32 +55,32 @@ NXtofraw(NXobject): dim: [[1, nTimeChan]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | polar angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | azimuthal angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] (NXsample): name: - doc: | + doc: | Descriptive name of sample nature(NX_CHAR): enumeration: [powder, liquid, single crystal] (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor distance(NX_FLOAT): unit: NX_LENGTH @@ -108,3 +104,152 @@ NXtofraw(NXobject): target: /NXentry/NXinstrument/NXdetector/detector_number time_of_flight(link): target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cf876130ab5b69d23c8694bdbbcb43d81f4121e37e52467668853246ecdbecf4 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of detectors +# +# +# nTimeChan description +# +# +# This is an application definition for raw data from a generic TOF instrument +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# This is the flight path before the sample position. This can be determined by a chopper, +# by the moderator, or the source itself. In other words: it is the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# distance to sample for each detector +# +# +# +# +# +# +# +# +# +# +# polar angle for each detector element +# +# +# +# +# +# azimuthal angle for each detector element +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtofsingle.yaml b/applications/nyaml/NXtofsingle.yaml index 626ad4240d..31eacdc3d2 100644 --- a/applications/nyaml/NXtofsingle.yaml +++ b/applications/nyaml/NXtofsingle.yaml @@ -1,38 +1,32 @@ category: application -doc: | +doc: | This is a application definition for raw data from a generic TOF instrument - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - xSize: | + xSize: | xSize description - - ySize: | + ySize: | ySize description - - nDet: | + nDet: | Number of detectors - - nTimeChan: | + nTimeChan: | nTimeChan description - type: group NXtofsingle(NXobject): (NXentry)entry: title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXtofsingle] duration(NX_FLOAT): pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the flight path before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words':' it the distance to the component + by the moderator or the source itself. In other words: it the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. (NXuser)user: @@ -46,7 +40,7 @@ NXtofsingle(NXobject): dim: [[1, xSize], [2, ySize], [3, nTimeChan]] distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Distance to sample for the center of the detector dimensions: rank: 1 @@ -59,32 +53,32 @@ NXtofsingle(NXobject): dim: [[1, nTimeChan]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | polar angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | azimuthal angle for each detector element dimensions: rank: 1 dim: [[1, nDet]] (NXsample): name: - doc: | + doc: | Descriptive name of sample nature(NX_CHAR): enumeration: [powder, liquid, single crystal] (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor distance(NX_FLOAT): unit: NX_LENGTH @@ -104,3 +98,147 @@ NXtofsingle(NXobject): target: /NXentry/NXinstrument/NXdetector/data time_of_flight(link): target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 68f4d548d9d5116bbd6e38aa5ed5230e7ac8f1f0dcb70edc3aceb398ea4983d0 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# xSize description +# +# +# ySize description +# +# +# Number of detectors +# +# +# nTimeChan description +# +# +# This is a application definition for raw data from a generic TOF instrument +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# This is the flight path before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance to sample for the center of the detector +# +# +# +# +# +# +# +# polar angle for each detector element +# +# +# +# +# azimuthal angle for each detector element +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtomo.yaml b/applications/nyaml/NXtomo.yaml index d74141d437..8ec340419e 100644 --- a/applications/nyaml/NXtomo.yaml +++ b/applications/nyaml/NXtomo.yaml @@ -1,24 +1,19 @@ category: application -doc: | +doc: | This is the application definition for x-ray or neutron tomography raw data. In tomography a number of dark field images are measured, some bright field images and, of course the sample. In order to distinguish between them images carry a image_key. - -symbols: - doc: | +symbols: + doc: | These symbols will be used below to coordinate datasets with the same shape. - - nFrames: | + nFrames: | Number of frames - - xSize: | + xSize: | Number of pixels in X direction - - ySize: | + ySize: | Number of pixels in Y direction - type: group NXtomo(NXobject): (NXentry)entry: @@ -29,7 +24,7 @@ NXtomo(NXobject): end_time(NX_DATE_TIME): exists: ['min', '0', 'max', '1'] definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXtomo] (NXinstrument)instrument: @@ -49,11 +44,11 @@ NXtomo(NXobject): rank: 3 dim: [[1, nFrames], [2, xSize], [3, ySize]] image_key(NX_INT): - doc: | + doc: | In order to distinguish between sample projections, dark and flat images, a magic number is recorded per frame. - The key is as follows':' + The key is as follows: * projection = 0 * flat field = 1 @@ -71,7 +66,7 @@ NXtomo(NXobject): distance(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] - doc: | + doc: | Distance between detector and sample x_rotation_axis_pixel_position(NX_FLOAT): exists: ['min', '0', 'max', '1'] @@ -79,12 +74,12 @@ NXtomo(NXobject): exists: ['min', '0', 'max', '1'] (NXsample)sample: name: - doc: | + doc: | Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | In practice this axis is always aligned along one pixel direction on the detector and usually vertical. There are experiments with horizontal rotation axes, so this would need to be indicated somehow. For now the best way for that is an open question. @@ -113,7 +108,7 @@ NXtomo(NXobject): exists: ['min', '0', 'max', '1'] data(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Total integral monitor counts for each measured frame. Allows a to correction for fluctuations in the beam between frames. dimensions: @@ -126,3 +121,159 @@ NXtomo(NXobject): target: /NXentry/NXsample/rotation_angle image_key(link): target: /NXentry/NXinstrument/detector:NXdetector/image_key + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2ddef81db80e94c71e2fd772d74cfdae6cf00b895087e66b9e346d23a86fbc72 +# +# +# +# +# +# +# These symbols will be used below to coordinate datasets with the same shape. +# +# +# Number of frames +# +# +# Number of pixels in X direction +# +# +# Number of pixels in Y direction +# +# +# +# This is the application definition for x-ray or neutron tomography raw data. +# +# In tomography +# a number of dark field images are measured, some bright field images and, of course the sample. +# In order to distinguish between them images carry a image_key. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# In order +# to distinguish between sample projections, dark and flat +# images, a magic number is recorded per frame. +# The key is as follows: +# +# * projection = 0 +# * flat field = 1 +# * dark field = 2 +# * invalid = 3 +# +# +# +# +# +# +# +# +# Distance between detector and sample +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# In practice this axis is always aligned along one pixel direction on the detector and usually vertical. +# There are experiments with horizontal rotation axes, so this would need to be indicated somehow. +# For now the best way for that is an open question. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total integral monitor counts for each measured frame. Allows a to correction for +# fluctuations in the beam between frames. +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtomophase.yaml b/applications/nyaml/NXtomophase.yaml index 3faa694c38..7ef44c6a21 100644 --- a/applications/nyaml/NXtomophase.yaml +++ b/applications/nyaml/NXtomophase.yaml @@ -1,33 +1,25 @@ category: application -doc: | +doc: | This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. In tomography first some dark field images are measured, some bright field images and, of course the sample. In order to properly sort the order of the images taken, a sequence number is stored with each image. - -symbols: - doc: | +symbols: + doc: | These symbols will be used below to coordinate datasets with the same shape. - - nBrightFrames: | + nBrightFrames: | Number of bright frames - - nDarkFrames: | + nDarkFrames: | Number of dark frames - - nSampleFrames: | + nSampleFrames: | Number of image (sample) frames - - nPhase: | + nPhase: | Number of phase settings - - xSize: | + xSize: | Number of pixels in X direction - - ySize: | + ySize: | Number of pixels in Y direction - type: group NXtomophase(NXobject): (NXentry)entry: @@ -35,7 +27,7 @@ NXtomophase(NXobject): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXtomophase] (NXinstrument)instrument: @@ -80,11 +72,11 @@ NXtomophase(NXobject): unit: NX_LENGTH distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Distance between detector and sample (NXsample)sample: name: - doc: | + doc: | Descriptive name of sample rotation_angle(NX_FLOAT): unit: NX_ANGLE @@ -110,14 +102,191 @@ NXtomophase(NXobject): (NXmonitor)control: integral(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Total integral monitor counts for each measured frame. Allows a correction for fluctuations in the beam between frames. dimensions: rank: 1 + + # TODO: nPhase? dim: [[1, nDarkFrames + nBrightFrames + nSampleFrame]] (NXdata)data: data(link): target: /NXentry/NXinstrument/sample:NXdetector/data rotation_angle(link): target: /NXentry/NXsample/rotation_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 61792a668d325a2c70187730d3457c9ee8aba24ca55e9405ee1dd4d29f7d2296 +# +# +# +# +# +# These symbols will be used below to coordinate datasets with the same shape. +# +# Number of bright frames +# +# +# Number of dark frames +# +# +# Number of image (sample) frames +# +# +# Number of phase settings +# +# +# Number of pixels in X direction +# +# +# Number of pixels in Y direction +# +# +# +# This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. +# +# In tomography first +# some dark field images are measured, some bright field images and, of course the sample. In order +# to properly sort the order of the images taken, a sequence number is stored with each image. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance between detector and sample +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total integral monitor counts for each measured frame. Allows a correction for +# fluctuations in the beam between frames. +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtomoproc.yaml b/applications/nyaml/NXtomoproc.yaml index 2d414bef32..48ba4c9e04 100644 --- a/applications/nyaml/NXtomoproc.yaml +++ b/applications/nyaml/NXtomoproc.yaml @@ -1,26 +1,21 @@ category: application -doc: | - This is an application definition for the final result of a tomography experiment':' a 3D construction of some volume of physical properties. - -symbols: - doc: | +doc: | + This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. +symbols: + doc: | These symbols will be used below to coordinate datasets with the same shape. - - nX: | + nX: | Number of voxels in X direction - - nY: | + nY: | Number of voxels in Y direction - - nZ: | + nZ: | Number of voxels in Z direction - type: group NXtomoproc(NXobject): (NXentry)entry: title: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXtomoproc] (NXinstrument): @@ -31,26 +26,26 @@ NXtomoproc(NXobject): enumeration: [neutron, x-ray, electron] (NXsample): name: - doc: | + doc: | Descriptive name of sample (NXprocess)reconstruction: program(NX_CHAR): - doc: | + doc: | Name of the program used for reconstruction version(NX_CHAR): - doc: | + doc: | Version of the program used date(NX_DATE_TIME): - doc: | + doc: | Date and time of reconstruction processing. (NXparameters)parameters: raw_file(NX_CHAR): - doc: | + doc: | Original raw data file this data was derived from (NXdata)data: data(NX_INT): signal: 1 - doc: | + doc: | This is the reconstructed volume. This can be different things. Please indicate in the unit attribute what physical quantity this really is. @@ -63,7 +58,7 @@ NXtomoproc(NXobject): x(NX_FLOAT): unit: NX_ANY axis: 1 - doc: | + doc: | This is an array holding the values to use for the x-axis of data. The units must be appropriate for the measurement. dimensions: @@ -72,7 +67,7 @@ NXtomoproc(NXobject): y(NX_FLOAT): unit: NX_ANY axis: 2 - doc: | + doc: | This is an array holding the values to use for the y-axis of data. The units must be appropriate for the measurement. dimensions: @@ -81,9 +76,142 @@ NXtomoproc(NXobject): z(NX_FLOAT): unit: NX_ANY axis: 3 - doc: | + doc: | This is an array holding the values to use for the z-axis of data. The units must be appropriate for the measurement. dimensions: rank: 1 dim: [[1, nZ]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f0f55737027dae413b76cbb267a0d0021482dfdf9d398c0886e5d5b4e8c8bca1 +# +# +# +# +# +# These symbols will be used below to coordinate datasets with the same shape. +# +# Number of voxels in X direction +# +# +# Number of voxels in Y direction +# +# +# Number of voxels in Z direction +# +# +# This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# Name of the program used for reconstruction +# +# +# Version of the program used +# +# +# Date and time of reconstruction processing. +# +# +# +# Original raw data file this data was derived from +# +# +# +# +# +# +# This is the reconstructed volume. This can be different +# things. Please indicate in the unit attribute what physical +# quantity this really is. +# +# +# +# +# +# +# +# +# +# +# +# +# This is an array holding the values to use for the x-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the y-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the z-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxas.yaml b/applications/nyaml/NXxas.yaml index a25e3ef589..865c953dce 100644 --- a/applications/nyaml/NXxas.yaml +++ b/applications/nyaml/NXxas.yaml @@ -1,28 +1,25 @@ category: application -doc: | +doc: | This is an application definition for raw data from an X-ray absorption spectroscopy experiment. This is essentially a scan on energy versus incoming/ absorbed beam. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXxas(NXobject): (NXentry): \@entry: - doc: | + doc: | NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry. title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxas] (NXinstrument): @@ -44,27 +41,27 @@ NXxas(NXobject): dim: [[1, nP]] (NXdetector)absorbed_beam: data(NX_NUMBER): - doc: | + doc: | This data corresponds to the sample signal. dimensions: rank: 1 dim: [[1, nP]] (NXsample): name: - doc: | + doc: | Descriptive name of sample (NXmonitor): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor data(NX_NUMBER): - doc: | - This field could be a link to ``/NXentry/NXinstrument/incoming_beam':'NXdetector/data`` + doc: | + This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` dimensions: rank: 1 dim: [[1, nP]] @@ -74,6 +71,142 @@ NXxas(NXobject): absorbed_beam(link): target: /NXentry/NXinstrument/absorbed_beam:NXdetector/data mode: - doc: | + doc: | Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) enumeration: [Total Electron Yield, Partial Electron Yield, Auger Electron Yield, Fluorescence Yield, Transmission] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2d5aaca6043db70d6315aaf4b2fbd9cc9e75ce43f1f2103fd79fdb9c11e36f4d +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# This is an application definition for raw data from an X-ray absorption spectroscopy experiment. +# +# This is essentially a scan on energy versus incoming/ +# absorbed beam. +# +# +# +# +# NeXus convention is to use "entry1", "entry2", ... +# for analysis software to locate each entry. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# This data corresponds to the sample signal. +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` +# +# +# +# +# +# +# +# +# +# Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxasproc.yaml b/applications/nyaml/NXxasproc.yaml index a0fa42db3e..111d6699bc 100644 --- a/applications/nyaml/NXxasproc.yaml +++ b/applications/nyaml/NXxasproc.yaml @@ -1,43 +1,40 @@ category: application -doc: | +doc: | Processed data from XAS. This is energy versus I(incoming)/I(absorbed). - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXxasproc(NXobject): (NXentry): \@entry: - doc: | + doc: | NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry. title: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxasproc] (NXsample): name: - doc: | + doc: | Descriptive name of sample (NXprocess)XAS_data_reduction: program(NX_CHAR): - doc: | + doc: | Name of the program used for reconstruction version(NX_CHAR): - doc: | + doc: | Version of the program used date(NX_DATE_TIME): - doc: | + doc: | Date and time of reconstruction processing. (NXparameters)parameters: raw_file(NX_CHAR): - doc: | + doc: | Original raw data file this data was derived from (NXdata): energy: @@ -46,9 +43,105 @@ NXxasproc(NXobject): rank: 1 dim: [[1, nP]] data(NX_FLOAT): - doc: | + doc: | This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. Expect attribute ``signal=1`` dimensions: rank: 1 dim: [[1, nP]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 07a20126249a01bd8a1d5b7cf0796baf16f8dd148bcddc87d976c77baa89e00c +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# Processed data from XAS. This is energy versus I(incoming)/I(absorbed). +# +# +# +# +# NeXus convention is to use "entry1", "entry2", ... +# for analysis software to locate each entry. +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# Name of the program used for reconstruction +# +# +# Version of the program used +# +# +# Date and time of reconstruction processing. +# +# +# +# Original raw data file this data was derived from +# +# +# +# +# +# +# +# +# +# +# +# This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. +# Expect attribute ``signal=1`` +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxbase.yaml b/applications/nyaml/NXxbase.yaml index f24e4b2622..46db086841 100644 --- a/applications/nyaml/NXxbase.yaml +++ b/applications/nyaml/NXxbase.yaml @@ -1,27 +1,22 @@ category: application -doc: | +doc: | This definition covers the common parts of all monochromatic single crystal raw data application definitions. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - - nXPixels: | + nXPixels: | Number of X pixels - - nYPixels: | + nYPixels: | Number of Y pixels - type: group NXxbase(NXobject): (NXentry)entry: title: start_time(NX_DATE_TIME): definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxbase] (NXinstrument)instrument: @@ -37,7 +32,7 @@ NXxbase(NXobject): exists: ['max', 'unbounded'] data(NX_INT): signal: 1 - doc: | + doc: | The area detector data, the first dimension is always the number of scan points, the second and third are the number of pixels in x and y. The origin is always assumed to be @@ -53,24 +48,24 @@ NXxbase(NXobject): unit: NX_LENGTH y_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | The name of the group is detector if there is only one detector, if there are several, names have to be detector1, detector2, ...detectorn. distance(NX_FLOAT): unit: NX_LENGTH frame_start_number(NX_INT): - doc: | + doc: | This is the start number of the first frame of a scan. In PX one often scans a couple of frames on a give sample, then does something else, then returns to the same sample and scans some more frames. Each time with a new data file. This number helps concatenating such measurements. (NXsample)sample: name(NX_CHAR): - doc: | + doc: | Descriptive name of sample orientation_matrix(NX_FLOAT): - doc: | + doc: | The orientation matrix according to Busing and Levy conventions. This is not strictly necessary as the UB can always be derived from the data. But @@ -80,45 +75,45 @@ NXxbase(NXobject): rank: 2 dim: [[1, 3], [2, 3]] unit_cell(NX_FLOAT): - doc: | + doc: | The unit cell, a, b, c, alpha, beta, gamma. Again, not strictly necessary, but normally written. dimensions: rank: 1 dim: [[1, 6]] temperature(NX_FLOAT): - doc: | + doc: | The sample temperature or whatever sensor represents this value best dimensions: rank: 1 dim: [[1, nP]] x_translation(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Translation of the sample along the X-direction of the laboratory coordinate system y_translation(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Translation of the sample along the Y-direction of the laboratory coordinate system distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Translation of the sample along the Z-direction of the laboratory coordinate system (NXmonitor)control: mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] preset(NX_FLOAT): - doc: | + doc: | preset value for time or monitor integral(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Total integral monitor counts (NXdata): - doc: | + doc: | The name of this group id data if there is only one detector; if there are several the names will be data1, data2, data3 and will point @@ -126,3 +121,188 @@ NXxbase(NXobject): instrument hierarchy. data(link): target: /NXentry/NXinstrument/NXdetector/data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 97c93a3c48735ce7430e1e80498bae3276fa68441c19151174bc943af9503be3 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# Number of X pixels +# +# +# Number of Y pixels +# +# +# +# This definition covers the common parts of all monochromatic single crystal raw data application definitions. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The area detector data, the first dimension is always the +# number of scan points, the second and third are the number +# of pixels in x and y. The origin is always assumed to be +# in the center of the detector. maxOccurs is limited to the +# the number of detectors on your instrument. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The name of the group is detector if there is only one detector, +# if there are several, names have to be detector1, +# detector2, ...detectorn. +# +# +# +# This is the start number of the first frame of a scan. In PX one often scans a couple +# of frames on a give sample, then does something else, then returns to the same sample +# and scans some more frames. Each time with a new data file. +# This number helps concatenating such measurements. +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# The orientation matrix according to Busing and +# Levy conventions. This is not strictly necessary as +# the UB can always be derived from the data. But +# let us bow to common usage which includes the +# UB nearly always. +# +# +# +# +# +# +# +# +# The unit cell, a, b, c, alpha, beta, gamma. +# Again, not strictly necessary, but normally written. +# +# +# +# +# +# +# +# The sample temperature or whatever sensor represents this value best +# +# +# +# +# +# +# Translation of the sample along the X-direction of the laboratory coordinate system +# +# +# Translation of the sample along the Y-direction of the laboratory coordinate system +# +# +# Translation of the sample along the Z-direction of the laboratory coordinate system +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Total integral monitor counts +# +# +# +# +# The name of this group id data if there is only +# one detector; if there are several the names will +# be data1, data2, data3 and will point +# to the corresponding detector groups in the +# instrument hierarchy. +# +# +# +# +# diff --git a/applications/nyaml/NXxeuler.yaml b/applications/nyaml/NXxeuler.yaml index 52b03b87ba..103128c2dc 100644 --- a/applications/nyaml/NXxeuler.yaml +++ b/applications/nyaml/NXxeuler.yaml @@ -1,23 +1,20 @@ category: application -doc: | - raw data from a ':'index':'`four-circle diffractometer` with an ':'index':'`eulerian cradle`, extends ':'ref':'`NXxbase` +doc: | + raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` - It extends ':'ref':'`NXxbase`, so the full definition is the content - of ':'ref':'`NXxbase` plus the data defined here. All four angles are + It extends :ref:`NXxbase`, so the full definition is the content + of :ref:`NXxbase` plus the data defined here. All four angles are logged in order to support arbitrary scans in reciprocal space. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXxeuler(NXxbase): (NXentry)entry: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxeuler] (NXinstrument)instrument: @@ -25,7 +22,7 @@ NXxeuler(NXxbase): polar_angle(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | The polar_angle (two theta) where the detector is placed at each scan point. dimensions: @@ -35,7 +32,7 @@ NXxeuler(NXxbase): rotation_angle(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | This is an array holding the sample rotation angle at each scan point dimensions: @@ -44,7 +41,7 @@ NXxeuler(NXxbase): chi(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | This is an array holding the chi angle of the eulerian cradle at each scan point dimensions: @@ -53,7 +50,7 @@ NXxeuler(NXxbase): phi(NX_FLOAT): unit: NX_ANGLE signal: 1 - doc: | + doc: | This is an array holding the phi rotation of the eulerian cradle at each scan point dimensions: @@ -68,3 +65,109 @@ NXxeuler(NXxbase): target: /NXentry/NXsample/chi phi(link): target: /NXentry/NXsample/phi + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 418ca04c5cb718b73b9fb0a9ba4d7834a39720336466afd0292a376c2e6db6f0 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` +# +# It extends :ref:`NXxbase`, so the full definition is the content +# of :ref:`NXxbase` plus the data defined here. All four angles are +# logged in order to support arbitrary scans in reciprocal space. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# The polar_angle (two theta) where the detector is placed +# at each scan point. +# +# +# +# +# +# +# +# +# +# +# This is an array holding the sample rotation angle at each +# scan point +# +# +# +# +# +# +# +# This is an array holding the chi angle of the eulerian +# cradle at each scan point +# +# +# +# +# +# +# +# This is an array holding the phi rotation of the eulerian +# cradle at each scan point +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxkappa.yaml b/applications/nyaml/NXxkappa.yaml index 8db2b1bba7..11ee96ea7a 100644 --- a/applications/nyaml/NXxkappa.yaml +++ b/applications/nyaml/NXxkappa.yaml @@ -1,32 +1,29 @@ category: application -doc: | - raw data from a kappa geometry (CAD4) single crystal diffractometer, extends ':'ref':'`NXxbase` +doc: | + raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` This is the application definition for raw data from a kappa geometry (CAD4) single crystal - diffractometer. It extends ':'ref':'`NXxbase`, so the full definition is - the content of ':'ref':'`NXxbase` plus the + diffractometer. It extends :ref:`NXxbase`, so the full definition is + the content of :ref:`NXxbase` plus the data defined here. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXxkappa(NXxbase): (NXentry)entry: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxkappa] (NXinstrument)instrument: (NXdetector)detector: polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | The polar_angle (two theta) at each scan point dimensions: rank: 1 @@ -35,7 +32,7 @@ NXxkappa(NXxbase): rotation_angle(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | This is an array holding the sample rotation angle at each scan point dimensions: @@ -44,7 +41,7 @@ NXxkappa(NXxbase): kappa(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | This is an array holding the kappa angle at each scan point dimensions: rank: 1 @@ -52,14 +49,14 @@ NXxkappa(NXxbase): phi(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | This is an array holding the phi angle at each scan point dimensions: rank: 1 dim: [[1, nP]] alpha(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | This holds the inclination angle of the kappa arm. (NXdata)name: polar_angle(link): @@ -70,3 +67,108 @@ NXxkappa(NXxbase): target: /NXentry/NXsample/kappa phi(link): target: /NXentry/NXsample/phi + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ab0a0187da4ac644dd64a38cf2120fa6519200d0c8097d2e33373b66c4e3fab5 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` +# +# This is the application definition for raw data from a kappa geometry +# (CAD4) single crystal +# diffractometer. It extends :ref:`NXxbase`, so the full definition is +# the content of :ref:`NXxbase` plus the +# data defined here. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# The polar_angle (two theta) at each scan point +# +# +# +# +# +# +# +# +# +# This is an array holding the sample rotation angle at each +# scan point +# +# +# +# +# +# +# +# This is an array holding the kappa angle at each scan point +# +# +# +# +# +# +# +# This is an array holding the phi angle at each scan point +# +# +# +# +# +# +# This holds the inclination angle of the kappa arm. +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxlaue.yaml b/applications/nyaml/NXxlaue.yaml index 576c39452a..82e1d406ba 100644 --- a/applications/nyaml/NXxlaue.yaml +++ b/applications/nyaml/NXxlaue.yaml @@ -1,29 +1,26 @@ category: application -doc: | - raw data from a single crystal laue camera, extends ':'ref':'`NXxrot` +doc: | + raw data from a single crystal laue camera, extends :ref:`NXxrot` This is the application definition for raw data from a single crystal laue - camera. It extends ':'ref':'`NXxrot`. - -symbols: - doc: | + camera. It extends :ref:`NXxrot`. +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nE: | + nE: | Number of energies - type: group NXxlaue(NXxrot): (NXentry)entry: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxlaue] (NXinstrument)instrument: (NXsource)source: (NXdata)distribution: data: - doc: | + doc: | expect ``signal=1 axes="energy"`` dimensions: rank: 1 @@ -33,5 +30,80 @@ NXxlaue(NXxrot): dimensions: rank: 1 dim: [[1, nE]] - doc: | + doc: | This is the wavelength distribution of the beam + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6bd59c0bb31baf46bbacaad01e38b03336b75f5d94468e0689b72386f201e77b +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of energies +# +# +# +# raw data from a single crystal laue camera, extends :ref:`NXxrot` +# +# This is the application definition for raw data from a single crystal laue +# camera. It extends :ref:`NXxrot`. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# expect ``signal=1 axes="energy"`` +# +# +# +# +# +# +# +# +# +# +# This is the wavelength distribution of the beam +# +# +# +# +# +# diff --git a/applications/nyaml/NXxlaueplate.yaml b/applications/nyaml/NXxlaueplate.yaml index a60b7f3eac..bb23a1d29f 100644 --- a/applications/nyaml/NXxlaueplate.yaml +++ b/applications/nyaml/NXxlaueplate.yaml @@ -1,20 +1,73 @@ category: application -doc: | - raw data from a single crystal Laue camera, extends ':'ref':'`NXxlaue` +doc: | + raw data from a single crystal Laue camera, extends :ref:`NXxlaue` This is the application definition for raw data from a single crystal Laue - camera with an image plate as a detector. It extends ':'ref':'`NXxlaue`. - + camera with an image plate as a detector. It extends :ref:`NXxlaue`. type: group NXxlaueplate(NXxlaue): (NXentry)entry: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxlaueplate] (NXinstrument)instrument: (NXdetector)detector: diameter(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | The diameter of a cylindrical detector + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7ad47196c57fedde1c91245a9edd7ff63d278eb1e2fbac3d8059e8f2744c3a80 +# +# +# +# +# +# raw data from a single crystal Laue camera, extends :ref:`NXxlaue` +# +# This is the application definition for raw data from a single crystal Laue +# camera with an image plate as a detector. It extends :ref:`NXxlaue`. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# The diameter of a cylindrical detector +# +# +# +# +# diff --git a/applications/nyaml/NXxnb.yaml b/applications/nyaml/NXxnb.yaml index 9458ce7804..c5f052d79a 100644 --- a/applications/nyaml/NXxnb.yaml +++ b/applications/nyaml/NXxnb.yaml @@ -1,27 +1,24 @@ category: application -doc: | - raw data from a single crystal diffractometer, extends ':'ref':'`NXxbase` +doc: | + raw data from a single crystal diffractometer, extends :ref:`NXxbase` This is the application definition for raw data from a single crystal diffractometer - measuring in normal beam mode. It extends ':'ref':'`NXxbase`, + measuring in normal beam mode. It extends :ref:`NXxbase`, so the full definition is the content of - ':'ref':'`NXxbase` plus the data defined here. All angles are + :ref:`NXxbase` plus the data defined here. All angles are logged in order to support arbitrary scans in reciprocal space. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXxnb(NXxbase): (NXentry)entry: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxnb] (NXinstrument)instrument: @@ -29,7 +26,7 @@ NXxnb(NXxbase): polar_angle(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | The polar_angle (gamma) of the detector for each scan point. dimensions: rank: 1 @@ -37,7 +34,7 @@ NXxnb(NXxbase): tilt_angle(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | The angle by which the detector has been tilted out of the scattering plane. dimensions: @@ -48,7 +45,7 @@ NXxnb(NXxbase): unit: NX_ANGLE axis: 1 primary: 1 - doc: | + doc: | This is an array holding the sample rotation angle at each scan point dimensions: @@ -61,3 +58,103 @@ NXxnb(NXxbase): target: /NXentry/NXinstrument/NXdetector/tilt rotation_angle(link): target: /NXentry/NXsample/rotation_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 08abdab5fcf7054861bd5927b569a05e6d69a55b7ed9b80344a60ede01cc3516 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# raw data from a single crystal diffractometer, extends :ref:`NXxbase` +# +# This is the application definition for raw data from +# a single crystal diffractometer +# measuring in normal beam mode. It extends :ref:`NXxbase`, +# so the full definition is the content of +# :ref:`NXxbase` plus the data defined here. All angles are +# logged in order to support arbitrary scans in +# reciprocal space. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# The polar_angle (gamma) of the detector for each scan point. +# +# +# +# +# +# +# +# The angle by which the detector has been tilted out of the +# scattering plane. +# +# +# +# +# +# +# +# +# +# +# This is an array holding the sample rotation angle at each +# scan point +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxrot.yaml b/applications/nyaml/NXxrot.yaml index 7aea09ab2e..5aa4e35558 100644 --- a/applications/nyaml/NXxrot.yaml +++ b/applications/nyaml/NXxrot.yaml @@ -1,39 +1,36 @@ category: application -doc: | - raw data from a rotation camera, extends ':'ref':'`NXxbase` +doc: | + raw data from a rotation camera, extends :ref:`NXxbase` This is the application definition for raw data from a rotation camera. - It extends ':'ref':'`NXxbase`, so the full definition is the content of ':'ref':'`NXxbase` + It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` plus the data defined here. - -symbols: - doc: | +symbols: + doc: | The symbol(s) listed here will be used below to coordinate datasets with the same shape. - - nP: | + nP: | Number of points - type: group NXxrot(NXxbase): (NXentry)entry: definition: - doc: | + doc: | Official NeXus NXDL schema to which this file conforms. enumeration: [NXxrot] (NXinstrument)instrument: (NXdetector)detector: polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | The polar_angle (two theta) where the detector is placed. beam_center_x(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the x position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. beam_center_y(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the y position where the direct beam would hit the detector. This is a length, not a pixel position, and can be outside of the actual detector. (NXattenuator)attenuator: @@ -43,7 +40,7 @@ NXxrot(NXxbase): rotation_angle(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | This is an array holding the sample rotation start angle at each scan point dimensions: rank: 1 @@ -51,7 +48,7 @@ NXxrot(NXxbase): rotation_angle_step(NX_FLOAT): unit: NX_ANGLE axis: 1 - doc: | + doc: | This is an array holding the step made for sample rotation angle at each scan point dimensions: rank: 1 @@ -59,3 +56,100 @@ NXxrot(NXxbase): (NXdata)name: rotation_angle(link): target: /NXentry/NXsample/rotation_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 996ce47ecffe4c4b4e0ffe4014ce8d5db9abb70f109b8508e5124256777ae344 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# raw data from a rotation camera, extends :ref:`NXxbase` +# +# This is the application definition for raw data from a rotation camera. +# It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` +# plus the data defined here. +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# The polar_angle (two theta) where the detector is placed. +# +# +# +# This is the x position where the direct beam would hit the detector. This is a +# length, not a pixel position, and can be outside of the actual detector. +# +# +# +# This is the y position where the direct beam would hit the detector. This is a +# length, not a pixel position, and can be outside of the actual detector. +# +# +# +# +# +# +# +# +# +# This is an array holding the sample rotation start angle at each scan point +# +# +# +# +# +# This is an array holding the step made for sample rotation angle at each scan point +# +# +# +# +# +# +# +# +# +# From 93434510186070266f7bd4ce0ae02fcbad7029ff Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 14:22:46 +0200 Subject: [PATCH 129/203] regenerated nyaml for NIAC registered unchaged Base class nxdl files --- base_classes/nyaml/NXaperture.yaml | 140 +- base_classes/nyaml/NXattenuator.yaml | 172 ++- base_classes/nyaml/NXbeam.yaml | 429 +++++- base_classes/nyaml/NXbeam_stop.yaml | 166 ++- base_classes/nyaml/NXbending_magnet.yaml | 165 ++- base_classes/nyaml/NXcapillary.yaml | 132 +- base_classes/nyaml/NXcite.yaml | 100 +- base_classes/nyaml/NXcollection.yaml | 94 +- base_classes/nyaml/NXcollimator.yaml | 159 ++- base_classes/nyaml/NXcrystal.yaml | 543 ++++++-- .../nyaml/NXcylindrical_geometry.yaml | 142 +- base_classes/nyaml/NXdata.yaml | 625 +++++++-- base_classes/nyaml/NXdetector.yaml | 1227 +++++++++++++++-- base_classes/nyaml/NXdetector_group.yaml | 135 +- base_classes/nyaml/NXdetector_module.yaml | 236 +++- base_classes/nyaml/NXdisk_chopper.yaml | 250 +++- base_classes/nyaml/NXentry.yaml | 356 ++++- base_classes/nyaml/NXenvironment.yaml | 98 +- base_classes/nyaml/NXevent_data.yaml | 154 ++- base_classes/nyaml/NXfermi_chopper.yaml | 169 ++- base_classes/nyaml/NXfilter.yaml | 304 +++- base_classes/nyaml/NXflipper.yaml | 127 +- base_classes/nyaml/NXfresnel_zone_plate.yaml | 134 +- base_classes/nyaml/NXgeometry.yaml | 112 +- base_classes/nyaml/NXgrating.yaml | 154 ++- base_classes/nyaml/NXguide.yaml | 345 ++++- base_classes/nyaml/NXinsertion_device.yaml | 160 ++- base_classes/nyaml/NXlog.yaml | 189 ++- base_classes/nyaml/NXmirror.yaml | 301 +++- base_classes/nyaml/NXmoderator.yaml | 159 ++- base_classes/nyaml/NXmonitor.yaml | 221 ++- base_classes/nyaml/NXmonochromator.yaml | 161 ++- base_classes/nyaml/NXnote.yaml | 100 +- base_classes/nyaml/NXobject.yaml | 42 +- base_classes/nyaml/NXoff_geometry.yaml | 161 ++- base_classes/nyaml/NXorientation.yaml | 94 +- base_classes/nyaml/NXparameters.yaml | 67 +- base_classes/nyaml/NXpdb.yaml | 294 +++- base_classes/nyaml/NXpinhole.yaml | 104 +- base_classes/nyaml/NXpolarizer.yaml | 113 +- base_classes/nyaml/NXpositioner.yaml | 153 +- base_classes/nyaml/NXprocess.yaml | 94 +- base_classes/nyaml/NXreflections.yaml | 877 ++++++++++-- base_classes/nyaml/NXroot.yaml | 151 +- base_classes/nyaml/NXsample.yaml | 593 ++++++-- base_classes/nyaml/NXsample_component.yaml | 227 ++- base_classes/nyaml/NXshape.yaml | 118 +- base_classes/nyaml/NXslit.yaml | 116 +- base_classes/nyaml/NXsource.yaml | 320 ++++- base_classes/nyaml/NXsubentry.yaml | 286 +++- base_classes/nyaml/NXtransformations.yaml | 278 +++- base_classes/nyaml/NXtranslation.yaml | 86 +- base_classes/nyaml/NXuser.yaml | 125 +- base_classes/nyaml/NXvelocity_selector.yaml | 157 ++- base_classes/nyaml/NXxraylens.yaml | 180 ++- 55 files changed, 10960 insertions(+), 1635 deletions(-) diff --git a/base_classes/nyaml/NXaperture.yaml b/base_classes/nyaml/NXaperture.yaml index 9d5fa64eda..a366af8970 100644 --- a/base_classes/nyaml/NXaperture.yaml +++ b/base_classes/nyaml/NXaperture.yaml @@ -1,11 +1,12 @@ category: base -doc: | +doc: | A beamline aperture. This group is deprecated, use NXslit instead. - type: group NXaperture(NXobject): + + # TODO compare with "screens" in SHADOW depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -18,20 +19,21 @@ NXaperture(NXobject): In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - .. image':'':' aperture/aperture.png - ':'width':' 40% + .. image:: aperture/aperture.png + :width: 40% (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the aperture and ':'ref':'`NXoff_geometry` to describe its shape - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the aperture and :ref:`NXoff_geometry` to describe its shape + doc: | location and shape of aperture - .. TODO':' documentation needs improvement, contributions welcome + .. TODO: documentation needs improvement, contributions welcome * description of terms is poor and leaves much to interpretation * Describe what is meant by translation _here_ and ... @@ -39,26 +41,128 @@ NXaperture(NXobject): * Some base classes do this much better * Such as where is the gap written? BLADE_GEOMETRY(NXgeometry): - deprecated: Use ':'ref':'`NXoff_geometry` instead to describe the shape of the aperture - doc: | + deprecated: + Use :ref:`NXoff_geometry` instead to describe the shape of the aperture + doc: | location and shape of each blade material: - doc: | + + # TODO Uniformity problem, "type" is used elsewhere for same context + doc: | Absorbing material of the aperture description: - doc: | + doc: | Description of aperture (NXnote): - doc: | + doc: | describe any additional information in a note* \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3d11dee2b9b432b9dc666bb1ee41813c2ef3f76f315ae2c752d74a70c969d503 +# +# +# +# +# +# A beamline aperture. This group is deprecated, use NXslit instead. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the +# surface of the aperture pointing towards the source. +# +# In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. +# +# .. image:: aperture/aperture.png +# :width: 40% +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# +# location and shape of aperture +# +# .. TODO: documentation needs improvement, contributions welcome +# +# * description of terms is poor and leaves much to interpretation +# * Describe what is meant by translation _here_ and ... +# * Similar throughout base classes +# * Some base classes do this much better +# * Such as where is the gap written? +# +# +# +# +# location and shape of each blade +# +# +# Absorbing material of the aperture +# +# +# Description of aperture +# +# describe any additional information in a note* +# +# +# .. 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/nyaml/NXattenuator.yaml b/base_classes/nyaml/NXattenuator.yaml index 1783187059..21fc404d16 100644 --- a/base_classes/nyaml/NXattenuator.yaml +++ b/base_classes/nyaml/NXattenuator.yaml @@ -1,58 +1,60 @@ category: base -doc: | +doc: | A device that reduces the intensity of a beam by attenuation. - If uncertain whether to use ':'ref':'`NXfilter` (band-pass filter) - or ':'ref':'`NXattenuator` (reduces beam intensity), then choose - ':'ref':'`NXattenuator`. - + If uncertain whether to use :ref:`NXfilter` (band-pass filter) + or :ref:`NXattenuator` (reduces beam intensity), then choose + :ref:`NXattenuator`. type: group NXattenuator(NXobject): + + # TODO compare with SHADOW definition "screen" + # TODO SHADOW: https://github.com/oasys-kit/shadow3 distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Distance from sample. Note, it is recommended to use NXtransformations instead. type: - doc: | + doc: | Type or composition of attenuator, e.g. polythene thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Thickness of attenuator along beam direction scattering_cross_section(NX_FLOAT): unit: NX_CROSS_SECTION - doc: | + doc: | Scattering cross section (coherent+incoherent) absorption_cross_section(NX_FLOAT): unit: NX_CROSS_SECTION - doc: | + doc: | Absorption cross section attenuator_transmission(NX_FLOAT): unit: NX_DIMENSIONLESS - doc: | + doc: | The nominal amount of the beam that gets through (transmitted intensity)/(incident intensity) status: - doc: | + doc: | In or out or moving of the beam \@time: type: NX_DATE_TIME - doc: | + doc: | time stamp for this observation enumeration: [in, out, moving] \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -65,14 +67,140 @@ NXattenuator(NXobject): In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - .. image':'':' attenuator/attenuator.png - ':'width':' 40% + .. image:: attenuator/attenuator.png + :width: 40% (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. shape(NXoff_geometry): - doc: | + doc: | Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5cb6333d87df9b8f1b009346d2bf55434c7d4ef72f1ce1b62db27caf873c4f7f +# +# +# +# +# +# +# A device that reduces the intensity of a beam by attenuation. +# +# If uncertain whether to use :ref:`NXfilter` (band-pass filter) +# or :ref:`NXattenuator` (reduces beam intensity), then choose +# :ref:`NXattenuator`. +# +# +# +# +# Distance from sample. Note, it is recommended to use NXtransformations instead. +# +# +# Type or composition of attenuator, e.g. polythene +# +# +# Thickness of attenuator along beam direction +# +# +# Scattering cross section (coherent+incoherent) +# +# +# Absorption cross section +# +# +# +# The nominal amount of the beam that gets through +# (transmitted intensity)/(incident intensity) +# +# +# +# In or out or moving of the beam +# +# time stamp for this observation +# +# +# +# +# +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the attenuator is its center in the x and y axis. The reference point on the z axis is the +# surface of the attenuator pointing towards the source. +# +# In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. +# +# .. image:: attenuator/attenuator.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# +# Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. +# +# +# diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml index a46245c593..5aeef146ae 100644 --- a/base_classes/nyaml/NXbeam.yaml +++ b/base_classes/nyaml/NXbeam.yaml @@ -1,61 +1,56 @@ category: base -doc: | +doc: | Properties of the neutron or X-ray beam at a given location. This group is intended to be referenced - by beamline component groups within the ':'ref':'`NXinstrument` group or by the ':'ref':'`NXsample` group. This group is + by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the ':'ref':'`NXsample` group in which it defines the results of the neutron + its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron scattering by the sample, e.g., energy transfer, polarizations. Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. - -symbols: - doc: | +symbols: + doc: | These symbols coordinate datasets with the same shape. - - nP: | + nP: | Number of scan points. - - m: | + m: | Number of channels in the incident beam spectrum, if known - - c: | + c: | Number of moments representing beam divergence (x, y, xy, etc.) - type: group NXbeam(NXobject): distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Distance from sample. Note, it is recommended to use NXtransformations instead. incident_energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | Energy carried by each particle of the beam on entering the beamline component dimensions: rank: 1 dim: [[1, m]] final_energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | Energy carried by each particle of the beam on leaving the beamline component dimensions: rank: 1 dim: [[1, m]] energy_transfer(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | Change in particle energy caused by the beamline component dimensions: rank: 1 dim: [[1, m]] incident_wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | In the case of a monochromatic beam this is the scalar wavelength. @@ -82,14 +77,14 @@ NXbeam(NXobject): relative weights in ``incident_wavelength_weights`` as a 2D array. - Note, ':'ref':'`variants ` are a good way + Note, :ref:`variants ` are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value wavelength value is available along with the original spectrum from which it was calibrated. Wavelength on entering beamline component incident_wavelength_weights(NX_FLOAT): - doc: | + doc: | In the case of a polychromatic beam this is an array of length **m** of the relative weights of the corresponding wavelengths in ``incident_wavelength``. @@ -100,7 +95,7 @@ NXbeam(NXobject): corresponding wavelengths in ``incident_wavelength``. incident_wavelength_spread(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | The wavelength spread FWHM for the corresponding wavelength(s) in incident_wavelength. @@ -113,7 +108,7 @@ NXbeam(NXobject): dim: [[1, nP]] incident_beam_divergence(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Beam crossfire in degrees parallel to the laboratory X axis The dimension **c** is a series of moments of that represent @@ -128,7 +123,7 @@ NXbeam(NXobject): dim: [[1, nP], [2, c]] extent(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Size of the beam entering this component. Note this represents a rectangular beam aperture, and values represent FWHM dimensions: @@ -136,28 +131,28 @@ NXbeam(NXobject): dim: [[1, nP], [2, 2]] final_wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | Wavelength on leaving beamline component dimensions: rank: 1 dim: [[1, m]] incident_polarization(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Polarization vector on entering beamline component dimensions: rank: 2 dim: [[1, nP], [2, 2]] final_polarization(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Polarization vector on leaving beamline component dimensions: rank: 2 dim: [[1, nP], [2, 2]] incident_polarization_stokes(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Polarization vector on entering beamline component using Stokes notation The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. @@ -184,7 +179,7 @@ NXbeam(NXobject): dim: [[1, nP], [2, 4]] final_polarization_stokes(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Polarization vector on leaving beamline component using Stokes notation (see incident_polarization_stokes). dimensions: @@ -192,80 +187,80 @@ NXbeam(NXobject): dim: [[1, nP], [2, 4]] final_wavelength_spread(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | Wavelength spread FWHM of beam leaving this component dimensions: rank: 1 dim: [[1, m]] final_beam_divergence(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Divergence FWHM of beam leaving this component dimensions: rank: 2 dim: [[1, nP], [2, 2]] flux(NX_FLOAT): unit: NX_FLUX - doc: | + doc: | flux incident on beam plane area dimensions: rank: 1 dim: [[1, nP]] (NXdata): - doc: | + doc: | Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly useful for simulations which need to store plottable information at each beamline component. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): exists: ['min', '0'] - doc: | + doc: | The NeXus coordinate system defines the Z axis to be along the nominal beam - direction. This is the same as the McStas coordinate system (see ':'ref':'Design-CoordinateSystem). + direction. This is the same as the McStas coordinate system (see :ref:Design-CoordinateSystem). However, the additional transformations needed to represent an altered beam direction can be provided using this depends_on field that contains the path to a NXtransformations group. This could represent redirection of the beam, or a refined beam direction. (NXtransformations): exists: ['min', '0'] - doc: | + doc: | Direction (and location) for the beam. The location of the beam can be given by any point which it passes through as its offset attribute. DIRECTION(NX_NUMBER): nameType: any unit: NX_TRANSFORMATION - doc: | + doc: | Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] and passes through the origin \@transformation_type: enumeration: [translation] \@vector: type: NX_NUMBER - doc: | + doc: | Three values that define the direction of beam vector \@offset: type: NX_NUMBER - doc: | + doc: | Three values that define the location of a point through which the beam passes \@depends_on: type: NX_CHAR - doc: | + doc: | Points to the path to a field defining the location on which this depends or the string "." for origin. reference_plane(NX_NUMBER): nameType: any unit: NX_TRANSFORMATION - doc: | + doc: | Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. This also defines the parallel and perpendicular components of the beam's polarization. If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin @@ -273,14 +268,354 @@ NXbeam(NXobject): enumeration: [translation] \@vector: type: NX_NUMBER - doc: | + doc: | Three values that define the direction of reference plane normal \@offset: type: NX_NUMBER - doc: | + doc: | Not required as beam direction offset locates the plane \@depends_on: type: NX_CHAR - doc: | + doc: | Points to the path to a field defining the location on which this depends or the string "." for origin. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 82a55b351e178e0a209ab7d8a7243527e49dafbfca75a4f2f597fe8bcf735e46 +# +# +# +# +# +# +# These symbols coordinate datasets with the same shape. +# +# +# Number of scan points. +# +# +# Number of channels in the incident beam spectrum, if known +# +# +# Number of moments representing beam divergence (x, y, xy, etc.) +# +# +# +# Properties of the neutron or X-ray beam at a given location. +# +# This group is intended to be referenced +# by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is +# especially valuable in storing the results of instrument simulations in which it is useful +# to specify the beam profile, time distribution etc. at each beamline component. Otherwise, +# its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron +# scattering by the sample, e.g., energy transfer, polarizations. +# +# Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. +# To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred +# by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. +# +# +# Distance from sample. Note, it is recommended to use NXtransformations instead. +# +# +# Energy carried by each particle of the beam on entering the beamline component +# +# +# +# +# +# Energy carried by each particle of the beam on leaving the beamline component +# +# +# +# +# +# Change in particle energy caused by the beamline component +# +# +# +# +# +# +# In the case of a monochromatic beam this is the scalar +# wavelength. +# +# Several other use cases are permitted, depending on the +# presence or absence of other incident_wavelength_X +# fields. +# +# In the case of a polychromatic beam this is an array of +# length **m** of wavelengths, with the relative weights +# in ``incident_wavelength_weights``. +# +# In the case of a monochromatic beam that varies shot- +# to-shot, this is an array of wavelengths, one for each +# recorded shot. Here, ``incident_wavelength_weights`` and +# incident_wavelength_spread are not set. +# +# In the case of a polychromatic beam that varies shot-to- +# shot, this is an array of length **m** with the relative +# weights in ``incident_wavelength_weights`` as a 2D array. +# +# In the case of a polychromatic beam that varies shot-to- +# shot and where the channels also vary, this is a 2D array +# of dimensions **nP** by **m** (slow to fast) with the +# relative weights in ``incident_wavelength_weights`` as a 2D +# array. +# +# Note, :ref:`variants <Design-Variants>` are a good way +# to represent several of these use cases in a single dataset, +# e.g. if a calibrated, single-value wavelength value is +# available along with the original spectrum from which it +# was calibrated. +# Wavelength on entering beamline component +# +# +# +# +# In the case of a polychromatic beam this is an array of +# length **m** of the relative weights of the corresponding +# wavelengths in ``incident_wavelength``. +# +# In the case of a polychromatic beam that varies shot-to- +# shot, this is a 2D array of dimensions **nP** by **m** +# (slow to fast) of the relative weights of the +# corresponding wavelengths in ``incident_wavelength``. +# +# +# +# +# The wavelength spread FWHM for the corresponding +# wavelength(s) in incident_wavelength. +# +# In the case of shot-to-shot variation in the wavelength +# spread, this is a 2D array of dimension **nP** by +# **m** (slow to fast) of the spreads of the +# corresponding wavelengths in incident_wavelength. +# +# +# +# +# +# +# +# Beam crossfire in degrees parallel to the laboratory X axis +# +# The dimension **c** is a series of moments of that represent +# the standard uncertainty (e.s.d.) of the directions of +# of the beam. The first and second moments are in the XZ and YZ +# planes around the mean source beam direction, respectively. +# +# Further moments in **c** characterize co-variance terms, so +# the next moment is the product of the first two, and so on. +# +# +# +# +# +# +# +# +# Size of the beam entering this component. Note this represents +# a rectangular beam aperture, and values represent FWHM +# +# +# +# +# +# +# +# Wavelength on leaving beamline component +# +# +# +# +# +# Polarization vector on entering beamline component +# +# +# +# +# +# +# Polarization vector on leaving beamline component +# +# +# +# +# +# +# +# Polarization vector on entering beamline component using Stokes notation +# +# The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. +# These are defined with the standard Nexus coordinate frame unless it is +# overridden by an NXtransformations field pointed to by a depends_on attribute. +# The last component, describing the circular polarization state, is positive +# for a right-hand circular state - that is the electric field vector rotates +# clockwise at the sample and over time when observed from the source. +# +# I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale +# linearly with the total degree of polarization, and indicate the relative +# magnitudes of the pure linear and circular orientation contributions. +# +# Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). +# +# U (S_2) is linearly polarized along the x==y axis (U > 0) or the +# -x==y axis (U < 0). +# +# V (S_3) is circularly polarized. V > 0 when the electric field vector rotates +# clockwise at the sample with respect to time when observed from the source; +# V < 0 indicates the opposite rotation. +# +# +# +# +# +# +# +# +# Polarization vector on leaving beamline component using Stokes notation +# (see incident_polarization_stokes). +# +# +# +# +# +# +# +# Wavelength spread FWHM of beam leaving this component +# +# +# +# +# +# Divergence FWHM of beam leaving this component +# +# +# +# +# +# +# flux incident on beam plane area +# +# +# +# +# +# +# Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly +# useful for simulations which need to store plottable information at each beamline +# component. +# +# +# +# .. 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. +# +# +# +# +# +# The NeXus coordinate system defines the Z axis to be along the nominal beam +# direction. This is the same as the McStas coordinate system (see :ref:Design-CoordinateSystem). +# However, the additional transformations needed to represent an altered beam +# direction can be provided using this depends_on field that contains the path +# to a NXtransformations group. This could represent redirection of the beam, +# or a refined beam direction. +# +# +# +# +# +# Direction (and location) for the beam. The location of the beam can be given by +# any point which it passes through as its offset attribute. +# +# +# +# Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] +# and passes through the origin +# +# +# +# +# +# +# +# +# Three values that define the direction of beam vector +# +# +# +# +# Three values that define the location of a point through which the beam passes +# +# +# +# +# Points to the path to a field defining the location on which this +# depends or the string "." for origin. +# +# +# +# +# +# Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. +# This also defines the parallel and perpendicular components of the beam's polarization. +# If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin +# +# +# +# +# +# +# +# +# Three values that define the direction of reference plane normal +# +# +# +# +# Not required as beam direction offset locates the plane +# +# +# +# +# Points to the path to a field defining the location on which this +# depends or the string "." for origin. +# +# +# +# +# diff --git a/base_classes/nyaml/NXbeam_stop.yaml b/base_classes/nyaml/NXbeam_stop.yaml index c087e899d8..66dce02e76 100644 --- a/base_classes/nyaml/NXbeam_stop.yaml +++ b/base_classes/nyaml/NXbeam_stop.yaml @@ -1,64 +1,64 @@ category: base -doc: | +doc: | A device that blocks the beam completely, usually to protect a detector. Beamstops and their positions are important for SANS and SAXS experiments. - type: group NXbeam_stop(NXobject): (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | engineering shape, orientation and position of the beam stop. description: - doc: | + doc: | description of beamstop enumeration: [circular, rectangular] (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component (NXcylindrical_geometry): exists: ['min', '0'] - doc: | + doc: | This group is an alternative to NXoff_geometry for describing the shape of the beam stop. size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Size of beamstop. If this is not sufficient to describe the beam stop use NXoff_geometry instead. x(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | x position of the beamstop in relation to the detector. Note, it is recommended to use NXtransformations instead. y(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | y position of the beamstop in relation to the detector. Note, it is recommended to use NXtransformations instead. distance_to_detector(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | distance of the beamstop to the detector. Note, it is recommended to use NXtransformations instead. status: enumeration: [in, out] \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -69,11 +69,139 @@ NXbeam_stop(NXobject): The reference point of the beam stop is its center in the x and y axis. The reference point on the z axis is the surface of the beam stop pointing towards the source. - .. image':'':' beam_stop/beam_stop.png - ':'width':' 40% + .. image:: beam_stop/beam_stop.png + :width: 40% (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 12ffb3bfff4f698d340f6bd19e4df67375c04a820ab060003e37688de3649898 +# +# +# +# +# +# +# A device that blocks the beam completely, usually to protect a detector. +# +# Beamstops and their positions are important for SANS +# and SAXS experiments. +# +# +# engineering shape, orientation and position of the beam stop. +# +# +# description of beamstop +# +# +# +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# This group is an alternative to NXoff_geometry for describing the shape +# of the beam stop. +# +# +# +# +# Size of beamstop. If this is not sufficient to describe the beam stop use +# NXoff_geometry instead. +# +# +# +# +# x position of the beamstop in relation to the detector. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# y position of the beamstop in relation to the detector. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# distance of the beamstop to the detector. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the beam stop is its center in the x and y axis. The reference point on the z axis is the +# surface of the beam stop pointing towards the source. +# +# .. image:: beam_stop/beam_stop.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXbending_magnet.yaml b/base_classes/nyaml/NXbending_magnet.yaml index 001e98304e..27f0ede6c1 100644 --- a/base_classes/nyaml/NXbending_magnet.yaml +++ b/base_classes/nyaml/NXbending_magnet.yaml @@ -1,7 +1,6 @@ category: base -doc: | +doc: | A bending magnet - type: group NXbending_magnet(NXobject): critical_energy(NX_FLOAT): @@ -10,66 +9,67 @@ NXbending_magnet(NXobject): unit: NX_LENGTH magnetic_field(NX_FLOAT): unit: NX_CURRENT - doc: | + doc: | strength of magnetic field of dipole magnets accepted_photon_beam_divergence(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | An array of four numbers giving X+, X-, Y+ and Y- half divergence source_distance_x(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Distance of source point from particle beam waist in X (horizontal) direction. Note, it is recommended to use NXtransformations instead to place component. source_distance_y(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Distance of source point from particle beam waist in Y (vertical) direction. Note, it is recommended to use NXtransformations instead to place component. divergence_x_plus(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Accepted photon beam divergence in X+ (horizontal outboard) direction. Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. divergence_x_minus(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Accepted photon beam divergence in X- (horizontal inboard) direction. Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. divergence_y_plus(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Accepted photon beam divergence in Y+ (vertical upward) direction. Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. divergence_y_minus(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Accepted photon beam divergence in Y- (vertical downward) direction. Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. spectrum(NXdata): - doc: | + doc: | bending magnet spectrum (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the bending magnet and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the bending magnet and NXoff_geometry to describe its shape instead + doc: | "Engineering" position of bending magnet (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -77,11 +77,134 @@ NXbending_magnet(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a bending magnet. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5b08a03dc9eadb728c7fcdf02c9c74bc20f04e7f6bfe6ed0f8bef2f20c5e1d83 +# +# +# +# +# +# A bending magnet +# +# +# +# strength of magnetic field of dipole magnets +# +# +# +# An array of four numbers giving X+, X-, Y+ and Y- half divergence +# +# +# +# +# Distance of source point from particle beam waist in X (horizontal) direction. +# Note, it is recommended to use NXtransformations instead to place component. +# +# +# +# +# Distance of source point from particle beam waist in Y (vertical) direction. +# Note, it is recommended to use NXtransformations instead to place component. +# +# +# +# +# Accepted photon beam divergence in X+ (horizontal outboard) direction. +# Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. +# +# +# +# +# Accepted photon beam divergence in X- (horizontal inboard) direction. +# Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. +# +# +# +# +# Accepted photon beam divergence in Y+ (vertical upward) direction. +# Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. +# +# +# +# +# Accepted photon beam divergence in Y- (vertical downward) direction. +# Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. +# +# +# bending magnet spectrum +# "Engineering" position of bending magnet +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a bending magnet. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXcapillary.yaml b/base_classes/nyaml/NXcapillary.yaml index 79bb1c8e7a..aacb021fd6 100644 --- a/base_classes/nyaml/NXcapillary.yaml +++ b/base_classes/nyaml/NXcapillary.yaml @@ -1,17 +1,16 @@ category: base -doc: | +doc: | A capillary lens to focus the X-ray beam. Based on information provided by Gerd Wellenreuther (DESY). - type: group NXcapillary(NXobject): type(NX_CHAR): - doc: | + doc: | Type of the capillary enumeration: [single_bounce, polycapillary, conical_capillary] manufacturer(NX_CHAR): - doc: | + doc: | The manufacturer of the capillary. This is actually important as it may have an impact on performance. maximum_incident_angle(NX_FLOAT): @@ -19,29 +18,29 @@ NXcapillary(NXobject): accepting_aperture(NX_FLOAT): unit: NX_ANGLE (NXdata)gain: - doc: | + doc: | The gain of the capillary as a function of energy (NXdata)transmission: - doc: | + doc: | The transmission of the capillary as a function of energy working_distance(NX_FLOAT): unit: NX_LENGTH focal_size(NX_FLOAT): - doc: | + doc: | The focal size in FWHM \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -49,11 +48,116 @@ NXcapillary(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a capillary lens. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 532702bd23065d69a03c9e0b7aaf7136d411799faab901669a8be1f5d007b6c9 +# +# +# +# +# +# +# A capillary lens to focus the X-ray beam. +# +# Based on information provided by Gerd Wellenreuther (DESY). +# +# +# Type of the capillary +# +# +# +# +# +# +# +# +# The manufacturer of the capillary. This is actually important as +# it may have an impact on performance. +# +# +# +# +# +# +# The gain of the capillary as a function of energy +# +# +# +# +# The transmission of the capillary as a function of energy +# +# +# +# +# +# The focal size in FWHM +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a capillary lens. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXcite.yaml b/base_classes/nyaml/NXcite.yaml index aca73c14eb..d183f1fd89 100644 --- a/base_classes/nyaml/NXcite.yaml +++ b/base_classes/nyaml/NXcite.yaml @@ -1,40 +1,112 @@ category: base -doc: | +doc: | A literature reference Definition to include references for example for detectors, manuals, instruments, acquisition or analysis software used. - The idea would be to include this in the relevant NeXus object':' - ':'ref':'`NXdetector` for detectors, ':'ref':'`NXinstrument` for instruments, etc. - + The idea would be to include this in the relevant NeXus object: + :ref:`NXdetector` for detectors, :ref:`NXinstrument` for instruments, etc. type: group NXcite(NXobject): description(NX_CHAR): - doc: | + doc: | This should describe the reason for including this reference. - For example':' The dataset in this group was normalised using the method + For example: The dataset in this group was normalised using the method which is described in detail in this reference. url(NX_CHAR): - doc: | + doc: | URL referencing the document or data. doi(NX_CHAR): - doc: | + doc: | DOI referencing the document or data. endnote(NX_CHAR): - doc: | + doc: | Bibliographic reference data in EndNote format. bibtex(NX_CHAR): - doc: | + doc: | Bibliographic reference data in BibTeX format. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 59929309fbee197465213bc3b923e04782d370b2058f5a970b41ecf71e85ba7a +# +# +# +# +# +# A literature reference +# +# Definition to include references for example for detectors, +# manuals, instruments, acquisition or analysis software used. +# +# The idea would be to include this in the relevant NeXus object: +# :ref:`NXdetector` for detectors, :ref:`NXinstrument` for instruments, etc. +# +# +# +# This should describe the reason for including this reference. +# For example: The dataset in this group was normalised using the method +# which is described in detail in this reference. +# +# +# +# URL referencing the document or data. +# +# +# DOI referencing the document or data. +# +# +# Bibliographic reference data in EndNote format. +# +# +# Bibliographic reference data in BibTeX format. +# +# +# +# .. 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/nyaml/NXcollection.yaml b/base_classes/nyaml/NXcollection.yaml index e086b9e074..5b3dd56a28 100644 --- a/base_classes/nyaml/NXcollection.yaml +++ b/base_classes/nyaml/NXcollection.yaml @@ -1,18 +1,102 @@ category: base -doc: | + +# The ignoreExtra* attributes are used in the definition to +# avoid warning messages that would be generated from +# unexpected groups, fields, and attributes. +# Since no groups or attributes are declared here, _every_ +# child of this class would generate a warning message without this +# attribute being set to "true". +doc: | An unvalidated set of terms, such as the description of a beam line. - Use ':'ref':'`NXcollection` to gather together any set of terms. + Use :ref:`NXcollection` to gather together any set of terms. The original suggestion is to use this as a container class for the description of a beamline. - For NeXus validation, ':'ref':'`NXcollection` will always generate + For NeXus validation, :ref:`NXcollection` will always generate a warning since it is always an optional group. Anything (groups, fields, or attributes) placed in - an ':'ref':'`NXcollection` group will not be validated. - + an :ref:`NXcollection` group will not be validated. type: group ignoreExtraGroups: true ignoreExtraFields: true ignoreExtraAttributes: true NXcollection(NXobject): + + # any content is purely optional + + # NOTE + # ===== + # NXcollection is an unvalidated class, do not add any subgroups. + # See: https://github.com/nexusformat/definitions/issues/259 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fdd5367211b59613e74b746761c655ba70f7ae36889538b8eec14fd904748fbf +# +# +# +# +# +# +# +# +# An unvalidated set of terms, such as the description of a beam line. +# +# Use :ref:`NXcollection` to gather together any set of terms. +# The original suggestion is to use this as a container +# class for the description of a beamline. +# +# For NeXus validation, :ref:`NXcollection` will always generate +# a warning since it is always an optional group. +# Anything (groups, fields, or attributes) placed in +# an :ref:`NXcollection` group will not be validated. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcollimator.yaml b/base_classes/nyaml/NXcollimator.yaml index 0f15239665..acb4eeadfa 100644 --- a/base_classes/nyaml/NXcollimator.yaml +++ b/base_classes/nyaml/NXcollimator.yaml @@ -1,65 +1,65 @@ category: base -doc: | +doc: | A beamline collimator. - type: group NXcollimator(NXobject): (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the collimator and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the collimator and NXoff_geometry to describe its shape instead + doc: | position, shape and size type: enumeration: [Soller, radial, oscillating, honeycomb] soller_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Angular divergence of Soller collimator divergence_x(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | divergence of collimator in local x direction divergence_y(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | divergence of collimator in local y direction frequency(NX_FLOAT): unit: NX_FREQUENCY - doc: | + doc: | Frequency of oscillating collimator (NXlog)frequency_log: - doc: | + doc: | Log of frequency blade_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | blade thickness blade_spacing(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | blade spacing absorbing_material: - doc: | + doc: | name of absorbing material transmitting_material: - doc: | + doc: | name of transmitting material (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -71,11 +71,126 @@ NXcollimator(NXobject): point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. - .. image':'':' collimator/collimator.png - ':'width':' 40% + .. image:: collimator/collimator.png + :width: 40% (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 31140b43aa9a6a9240721e618335165197faeb7dfa4d21a1148482759ac5a53f +# +# +# +# +# +# A beamline collimator. +# +# position, shape and size +# +# +# +# +# +# +# +# +# +# +# Angular divergence of Soller collimator +# +# +# divergence of collimator in local x direction +# +# +# divergence of collimator in local y direction +# +# +# Frequency of oscillating collimator +# +# +# Log of frequency +# +# +# blade thickness +# +# +# blade spacing +# +# +# name of absorbing material +# +# +# name of transmitting material +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# Assuming a collimator with a "flat" entry surface, the reference plane is the plane which contains this surface. The reference +# point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal +# to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. +# +# .. image:: collimator/collimator.png +# :width: 40% +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXcrystal.yaml b/base_classes/nyaml/NXcrystal.yaml index b40a39f94c..1da2f240db 100644 --- a/base_classes/nyaml/NXcrystal.yaml +++ b/base_classes/nyaml/NXcrystal.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | A crystal monochromator or analyzer. Permits double bent @@ -12,34 +12,31 @@ doc: | Scattering vector is perpendicular to surface. Crystal is oriented parallel to beam incident on crystal before rotation, and lies in vertical plane. - -symbols: - doc: | +symbols: + doc: | These symbols will be used below to coordinate dimensions with the same lengths. - - n_comp: | + n_comp: | number of different unit cells to be described - - i: | + i: | number of wavelengths - type: group NXcrystal(NXobject): (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the crystal and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the crystal and NXoff_geometry to describe its shape instead + doc: | Position of crystal usage(NX_CHAR): - doc: | + doc: | How this crystal is used. Choices are in the list. enumeration: Bragg: - doc: | + doc: | reflection geometry Laue: - doc: | + doc: | The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard':' + Abbreviated version of CIF standard: * 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). @@ -49,16 +46,16 @@ NXcrystal(NXobject): * 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':' + * 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. This is the *Hill* system used by Chemical Abstracts. - See, for example':' - http':'//www.iucr.org/__data/iucr/cif/standard/cifstd15.html or - http':'//www.cas.org/training/stneasytips/subinforformula1.html. + See, for example: + http://www.iucr.org/__data/iucr/cif/standard/cifstd15.html or + http://www.cas.org/training/stneasytips/subinforformula1.html. type: - doc: | + doc: | Type or material of monochromating substance. Chemical formula can be specified separately. Use the "reflection" field to indicate the (hkl) orientation. @@ -67,13 +64,15 @@ NXcrystal(NXobject): This field was changed (2010-11-17) from an enumeration to a string since common usage showed a wider variety of use than a simple list. These are the items in the list at - the time of the change':' PG (Highly Oriented Pyrolytic Graphite) | + the time of the change: PG (Highly Oriented Pyrolytic Graphite) | Ge | Si | Cu | Fe3Si | CoFe | Cu2MnAl (Heusler) | Multilayer | Diamond. chemical_formula: - doc: | + + # copied from NXsample + doc: | The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard':' + Abbreviated version of CIF standard: * Only recognized element symbols may be used. * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. @@ -84,198 +83,214 @@ NXcrystal(NXobject): * 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':' + * 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. * This is the *Hill* system used by Chemical Abstracts. order_no(NX_INT): - doc: | + doc: | A number which describes if this is the first, second,.. - ':'math':'`n^{th}` crystal in a multi crystal monochromator + :math:`n^{th}` crystal in a multi crystal monochromator cut_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Cut angle of reflecting Bragg plane and plane of crystal surface space_group: - doc: | + doc: | Space group of crystal structure unit_cell(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Unit cell parameters (lengths and angles) dimensions: rank: 2 dim: [[1, n_comp], [2, 6]] + + # NXfilter defines each unit cell parameter separately. Let's be consistent. unit_cell_a(NX_FLOAT): unit: NX_LENGTH - doc: | - Unit cell lattice parameter':' length of side a + + # as used in NXfilter + doc: | + Unit cell lattice parameter: length of side a unit_cell_b(NX_FLOAT): unit: NX_LENGTH - doc: | - Unit cell lattice parameter':' length of side b + + # as used in NXfilter + doc: | + Unit cell lattice parameter: length of side b unit_cell_c(NX_FLOAT): unit: NX_LENGTH - doc: | - Unit cell lattice parameter':' length of side c + + # as used in NXfilter + doc: | + Unit cell lattice parameter: length of side c unit_cell_alpha(NX_FLOAT): unit: NX_ANGLE - doc: | - Unit cell lattice parameter':' angle alpha + + # as used in NXfilter + doc: | + Unit cell lattice parameter: angle alpha unit_cell_beta(NX_FLOAT): unit: NX_ANGLE - doc: | - Unit cell lattice parameter':' angle beta + + # as used in NXfilter + doc: | + Unit cell lattice parameter: angle beta unit_cell_gamma(NX_FLOAT): unit: NX_ANGLE - doc: | - Unit cell lattice parameter':' angle gamma + + # as used in NXfilter + doc: | + Unit cell lattice parameter: angle gamma unit_cell_volume(NX_FLOAT): unit: NX_VOLUME - doc: | + doc: | Volume of the unit cell orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention':' + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 dimensions: rank: 2 + + # 3,3 dim: [[1, 3], [2, 3]] wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | Optimum diffracted wavelength dimensions: dim: [[1, i]] d_spacing(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | spacing between crystal planes of the reflection scattering_vector(NX_FLOAT): unit: NX_WAVENUMBER - doc: | + doc: | Scattering vector, Q, of nominal reflection reflection(NX_INT): unit: NX_UNITLESS - doc: | + doc: | Miller indices (hkl) values of nominal reflection dimensions: dim: [[1, 3]] thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Thickness of the crystal. (Required for Laue orientations - see "usage" field) density(NX_NUMBER): unit: NX_MASS_DENSITY - doc: | + doc: | mass density of the crystal segment_width(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Horizontal width of individual segment segment_height(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Vertical height of individual segment segment_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Thickness of individual segment segment_gap(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Typical gap between adjacent segments segment_columns(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | number of segment columns in horizontal direction segment_rows(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | number of segment rows in vertical direction mosaic_horizontal(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | horizontal mosaic Full Width Half Maximum mosaic_vertical(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | vertical mosaic Full Width Half Maximum curvature_horizontal(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Horizontal curvature of focusing crystal curvature_vertical(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Vertical curvature of focusing crystal is_cylindrical(NX_BOOLEAN): - doc: | + doc: | Is this crystal bent cylindrically? cylindrical_orientation_angle(NX_NUMBER): unit: NX_ANGLE - doc: | - If cylindrical':' cylinder orientation angle + doc: | + If cylindrical: cylinder orientation angle polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Polar (scattering) angle at which crystal assembly is positioned. - Note':' some instrument geometries call this term 2theta. - Note':' it is recommended to use NXtransformations instead. + Note: some instrument geometries call this term 2theta. + Note: it is recommended to use NXtransformations instead. dimensions: dim: [[1, i]] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Azimuthal angle at which crystal assembly is positioned. - Note':' it is recommended to use NXtransformations instead. + Note: it is recommended to use NXtransformations instead. dimensions: dim: [[1, i]] bragg_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Bragg angle of nominal reflection dimensions: dim: [[1, i]] temperature(NX_FLOAT): unit: NX_TEMPERATURE - doc: | + doc: | average/nominal crystal temperature temperature_coefficient(NX_FLOAT): unit: NX_ANY - doc: | + doc: | how lattice parameter changes with temperature (NXlog)temperature_log: - doc: | + doc: | log file of crystal temperature (NXdata)reflectivity: - doc: | + doc: | crystal reflectivity versus wavelength (NXdata)transmission: - doc: | + doc: | crystal transmission versus wavelength (NXshape)shape: deprecated: Use NXoff_geometry instead to describe the shape of the monochromator - doc: | + doc: | A NXshape group describing the shape of the crystal arrangement (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -283,8 +298,370 @@ NXcrystal(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a crystal. (NXtransformations): - doc: | + doc: | Transformations used by this component to define its position and orientation. + + # TODO need more parameters here, such as ... + # list from Rainer Gehrke, DESY (some items may already be present) + # Parameters for crystals + # + Field indicating whether it is Bragg or Laue see usage + # + The crystal structure (enumeration, e.g. Zincblende ..) see space_group + # + Lattice constant see unit_cell + # + Miller indices of reflection (h,k,l) see reflection + # + First (or only) element see order_no + # + Second element (if any) see order_no + # + Temperature factor (optional) see temperature_coefficient + # + Asymmetric angle (if applicable) see cut_angle + # + Mosaic angular spread (if applicable) see mosaic_horizontal and mosaic_vertical + # + Thickness (mandatory for Laue, else optional) see thickness + # Figure for crystals and mirrors (to describe curved surfaces) + # + Field indicating whether concave or convex see curvature_horizontal and curvature_vertical + # + Field indicating whether cylindrical or not see is_cylindrical + # + If cylindrical: cylinder orientation angle see cylindrical_orientation_angle + # Now come the different surface figures with the necessary parameters: + # 1. Flat + # 2. Spherical (spherical radius) + # 3. Elliptical and hyperbolical (semi-major axis, semi-minor axis, angle of major axis and pole) + # 4. Toroidal (major radius, minor radius) + # 5. Parabolical (parabolic parameter a) + # 6. Conical (cone half aperture) + # 7. Polynomial (degree of polynom, array with polynom coefficients) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2c8bcd2e0d1e3ecfb4be342deda56a44c3eb68d3f599c9ccd75b07761254f7b1 +# +# +# +# +# +# +# These symbols will be used below to coordinate dimensions with the same lengths. +# number of different unit cells to be described +# number of wavelengths +# +# +# +# A crystal monochromator or analyzer. +# +# Permits double bent +# monochromator comprised of multiple segments with anisotropic +# Gaussian mosaic. +# +# If curvatures are set to zero or are absent, array +# is considered to be flat. +# +# Scattering vector is perpendicular to surface. Crystal is oriented +# parallel to beam incident on crystal before rotation, and lies in +# vertical plane. +# +# +# +# Position of crystal +# +# +# How this crystal is used. Choices are in the list. +# +# reflection geometry +# +# +# The chemical formula specified using CIF conventions. +# Abbreviated version of CIF standard: +# * 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. +# This is the *Hill* system used by Chemical Abstracts. +# See, for example: +# http://www.iucr.org/__data/iucr/cif/standard/cifstd15.html or +# http://www.cas.org/training/stneasytips/subinforformula1.html. +# +# +# +# +# +# +# Type or material of monochromating substance. +# Chemical formula can be specified separately. +# Use the "reflection" field to indicate the (hkl) orientation. +# Use the "d_spacing" field to record the lattice plane spacing. +# +# This field was changed (2010-11-17) from an enumeration to +# a string since common usage showed a wider variety of use +# than a simple list. These are the items in the list at +# the time of the change: PG (Highly Oriented Pyrolytic Graphite) | +# Ge | Si | Cu | Fe3Si | CoFe | Cu2MnAl (Heusler) | Multilayer | +# Diamond. +# +# +# +# +# +# The chemical formula specified using CIF conventions. +# Abbreviated version of CIF standard: +# +# * 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. +# * This is the *Hill* system used by Chemical Abstracts. +# +# +# +# +# A number which describes if this is the first, second,.. +# :math:`n^{th}` crystal in a multi crystal monochromator +# +# +# +# Cut angle of reflecting Bragg plane and plane of crystal surface +# +# +# Space group of crystal structure +# +# +# Unit cell parameters (lengths and angles) +# +# +# +# +# +# +# +# Unit cell lattice parameter: length of side a +# +# +# Unit cell lattice parameter: length of side b +# +# +# Unit cell lattice parameter: length of side c +# +# +# Unit cell lattice parameter: angle alpha +# +# +# Unit cell lattice parameter: angle beta +# +# +# Unit cell lattice parameter: angle gamma +# +# +# Volume of the unit cell +# +# +# +# Orientation matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# Optimum diffracted wavelength +# +# +# +# spacing between crystal planes of the reflection +# +# +# Scattering vector, Q, of nominal reflection +# +# +# Miller indices (hkl) values of nominal reflection +# +# +# +# Thickness of the crystal. (Required for Laue orientations - see "usage" field) +# +# +# mass density of the crystal +# +# +# Horizontal width of individual segment +# +# +# Vertical height of individual segment +# +# +# Thickness of individual segment +# +# +# Typical gap between adjacent segments +# +# +# number of segment columns in horizontal direction +# +# +# number of segment rows in vertical direction +# +# +# horizontal mosaic Full Width Half Maximum +# +# +# vertical mosaic Full Width Half Maximum +# +# +# Horizontal curvature of focusing crystal +# +# +# Vertical curvature of focusing crystal +# +# +# Is this crystal bent cylindrically? +# +# +# If cylindrical: cylinder orientation angle +# +# +# +# Polar (scattering) angle at which crystal assembly is positioned. +# Note: some instrument geometries call this term 2theta. +# Note: it is recommended to use NXtransformations instead. +# +# +# +# +# +# Azimuthal angle at which crystal assembly is positioned. +# Note: it is recommended to use NXtransformations instead. +# +# +# +# +# Bragg angle of nominal reflection +# +# +# +# average/nominal crystal temperature +# +# +# how lattice parameter changes with temperature +# +# +# log file of crystal temperature +# +# +# crystal reflectivity versus wavelength +# +# +# crystal transmission versus wavelength +# +# +# A NXshape group describing the shape of the crystal arrangement +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a crystal. +# +# +# +# +# Transformations used by this component to define its position and orientation. +# +# +# +# diff --git a/base_classes/nyaml/NXcylindrical_geometry.yaml b/base_classes/nyaml/NXcylindrical_geometry.yaml index b8b1ed3b98..189ede84aa 100644 --- a/base_classes/nyaml/NXcylindrical_geometry.yaml +++ b/base_classes/nyaml/NXcylindrical_geometry.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | Geometry description for cylindrical shapes. This class can be used in place of ``NXoff_geometry`` when an exact representation for cylinders is preferred. @@ -7,25 +7,20 @@ doc: | It can be used to describe the shape of any beamline component, including detectors. In the case of detectors it can be used to define the shape of a single pixel, or, if the pixel shapes are non-uniform, to describe the shape of the whole detector. - -symbols: - doc: | +symbols: + doc: | These symbols will be used below. - - i: | + i: | number of vertices required to define all cylinders in the shape - - j: | + j: | number of cylinders in the shape - - k: | + k: | number cylinders which are detectors - type: group NXcylindrical_geometry(NXobject): vertices(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | List of x,y,z coordinates for vertices. The origin of the coordinates is the position of the parent component, for example the NXdetector which the geometry describes. @@ -36,7 +31,7 @@ NXcylindrical_geometry(NXobject): rank: 2 dim: [[1, i], [2, 3]] cylinders(NX_INT): - doc: | + doc: | List of indices of vertices in the ``vertices`` dataset to form each cylinder. Each cylinder is described by three vertices A, B, C. First vertex A lies on the cylinder axis and circular face, second point B @@ -45,19 +40,130 @@ NXcylindrical_geometry(NXobject): rank: 2 dim: [[1, j], [2, 3]] detector_number(NX_INT): - doc: | + doc: | Maps cylinders in ``cylinder``, by index, with a detector id. dimensions: rank: 1 dim: [[1, k]] \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9bbcf1ff2b2841c8960f59949dfb345ca6966cd04ab611c7e9843c1c81d643e6 +# +# +# +# +# +# +# These symbols will be used below. +# +# +# number of vertices required to define all cylinders in the shape +# +# +# number of cylinders in the shape +# number cylinders which are detectors +# +# +# +# Geometry description for cylindrical shapes. +# This class can be used in place of ``NXoff_geometry`` when an exact +# representation for cylinders is preferred. +# For example, for Helium-tube, neutron detectors. +# It can be used to describe the shape of any beamline component, including detectors. +# In the case of detectors it can be used to define the shape of a single pixel, or, +# if the pixel shapes are non-uniform, to describe the shape of the whole detector. +# +# +# +# +# +# List of x,y,z coordinates for vertices. +# The origin of the coordinates is the position of the parent component, for +# example the NXdetector which the geometry describes. +# If the shape describes a single pixel for a detector with uniform pixel shape +# then the origin is the position of each pixel as described by the +# ``x/y/z_pixel_offset`` datasets in ``NXdetector``. +# +# +# +# +# +# +# +# +# +# +# +# +# List of indices of vertices in the ``vertices`` dataset to form each cylinder. +# Each cylinder is described by three vertices A, B, C. +# First vertex A lies on the cylinder axis and circular face, second point B +# on edge of the same face as A, and third point C at the other face and on axis. +# +# +# +# +# +# +# +# +# +# +# +# Maps cylinders in ``cylinder``, by index, with a detector id. +# +# +# +# +# +# +# +# +# .. 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/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml index 637124fe5d..cc56a0676b 100644 --- a/base_classes/nyaml/NXdata.yaml +++ b/base_classes/nyaml/NXdata.yaml @@ -1,11 +1,11 @@ category: base -doc: | - ':'ref':'`NXdata` describes the plottable data and related dimension scales. +doc: | + :ref:`NXdata` describes the plottable data and related dimension scales. - .. index':'':' plotting + .. index:: plotting - It is strongly recommended that there is at least one ':'ref':'`NXdata` - group in each ':'ref':'`NXentry` group. + It is strongly recommended that there is at least one :ref:`NXdata` + group in each :ref:`NXentry` group. Note that the fields named ``AXISNAME`` and ``DATA`` can be defined with different names. (Upper case is used to indicate that the actual name is left to the user.) @@ -13,11 +13,11 @@ doc: | ``data`` group define which items are plottable data and which are *dimension scales*, respectively. - ':'ref':'`NXdata` is used to implement one of the basic motivations in NeXus, - to provide a default plot for the data of this ':'ref':'`NXentry`. The actual data - might be stored in another group and (hard) linked to the ':'ref':'`NXdata` group. + :ref:`NXdata` is used to implement one of the basic motivations in NeXus, + to provide a default plot for the data of this :ref:`NXentry`. The actual data + might be stored in another group and (hard) linked to the :ref:`NXdata` group. - * Each ':'ref':'`NXdata` group will define one field as the default + * Each :ref:`NXdata` group will define one field as the default plottable data. The value of the ``signal`` attribute names this field. Additional fields may be used to describe the dimension scales and uncertainities. @@ -26,14 +26,14 @@ doc: | * The plottable data may be of arbitrary rank up to a maximum of ``NX_MAXRANK=32`` (for compatibility with backend file formats). * The plottable data will be named as the value of - the group ``signal`` attribute, such as':'':' + the group ``signal`` attribute, such as:: - data':'NXdata + data:NXdata @signal = "counts" @axes = "mr" @mr_indices = 0 - counts':' float[100] --> the default dependent data - mr':' float[100] --> the default independent data + counts: float[100] --> the default dependent data + mr: float[100] --> the default independent data The field named in the ``signal`` attribute **must** exist, either directly as a NeXus field or defined through a link. @@ -50,28 +50,28 @@ doc: | data, *i.e*. the values of the independent variables at which the data is measured, such as scattering angle or energy transfer. - .. index':'':' link - .. index':'':' axes (attribute) + .. index:: link + .. index:: axes (attribute) The preferred method to associate each data dimension with its respective dimension scale is to specify the field name of each dimension scale in the group ``axes`` attribute as a string list. Here is an example for a 2-D data set *data* plotted against *time*, and *pressure*. (An additional *temperature* data set - is provided and could be selected as an alternate for the *pressure* axis.)':'':' + is provided and could be selected as an alternate for the *pressure* axis.):: - data_2d':'NXdata + data_2d:NXdata @signal="data" @axes=["time", "pressure"] @pressure_indices=1 @temperature_indices=1 @time_indices=0 - data':' float[1000,20] - pressure':' float[20] - temperature':' float[20] - time':' float[1000] + data: float[1000,20] + pressure: float[20] + temperature: float[20] + time: float[1000] - .. rubric':'':' Old methods to identify the plottable data + .. rubric:: Old methods to identify the plottable data There are two older methods of associating each data dimension to its respective dimension scale. @@ -87,7 +87,7 @@ doc: | *dimension scale* to identify with an integer the axis whose value is the number of the dimension. - .. index':' !plot; axis label + .. index: !plot; axis label plot, axis units units dimension scale @@ -97,76 +97,75 @@ doc: | is provided as the axis label default. If ``@long_name`` is not defined, then use the name of the dimension scale. A ``@units`` attribute, if available, may be added to the axis label for further description. - See the section ':'ref':'`Design-Units` for more information. + See the section :ref:`Design-Units` for more information. - .. index':' !plot; axis title + .. index: !plot; axis title The optional ``title`` field, if available, provides a suggested - title for the plot. If no ``title`` field is found in the ':'ref':'`NXdata` - group, look for a ``title`` field in the parent ':'ref':'`NXentry` group, - with a fallback to displaying the path to the ':'ref':'`NXdata` group. + title for the plot. If no ``title`` field is found in the :ref:`NXdata` + group, look for a ``title`` field in the parent :ref:`NXentry` group, + with a fallback to displaying the path to the :ref:`NXdata` group. NeXus is about how to find and annotate the data to be plotted but not to describe how the data is to be plotted. - (https':'//www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) + (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) -symbols: - doc: | +# The ignoreExtra* attributes are used in the definition to +# avoid warning messages that would be generated from unexpected fields or attributes. +# Since common use of NXdata indicates field names of any value, _many_ +# instances of this class would generate a warning message during validation +# without this attribute being set to "true". +symbols: + doc: | These symbols will be used below to coordinate fields with the same shape. - - dataRank: | + dataRank: | rank of the ``DATA`` field - - n: | + n: | length of the ``AXISNAME`` field - - nx: | + nx: | length of the ``x`` field - - ny: | + ny: | length of the ``y`` field - - nz: | + nz: | length of the ``z`` field - type: group ignoreExtraFields: true ignoreExtraAttributes: true NXdata(NXobject): \@auxiliary_signals: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting - Array of strings holding the ':'ref':'`names ` of additional - signals to be plotted with the default ':'ref':'`signal `. + Array of strings holding the :ref:`names ` of additional + signals to be plotted with the default :ref:`signal `. These fields or links *must* exist and be direct children of this NXdata group. Each auxiliary signal needs to be of the same shape as the default signal. - .. NIAC2018':' - https':'//www.nexusformat.org/NIAC2018Minutes.html + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html \@signal: - doc: | - .. index':'':' find the default plottable data - .. index':'':' plotting - .. index':'':' signal attribute value + doc: | + .. index:: find the default plottable data + .. index:: plotting + .. index:: signal attribute value Declares which NeXus field is the default. - The value is the ':'ref':'`name ` of the data field to be plotted. + The value is the :ref:`name ` of the data field to be plotted. This field or link *must* exist and be a direct child of this NXdata group. It is recommended (as of NIAC2014) to use this attribute rather than adding a signal attribute to the field. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. \@axes: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting - Array of strings holding the ':'ref':'`names ` of + Array of strings holding the :ref:`names ` of the independent data fields used in the default plot for all of - the dimensions of the ':'ref':'`signal ` - as well as any ':'ref':'`auxiliary signals `. + the dimensions of the :ref:`signal ` + as well as any :ref:`auxiliary signals `. One name is provided for every dimension in the *signal* or *auxiliary signal* fields. @@ -179,7 +178,7 @@ NXdata(NXobject): When no default axis is available for a particular dimension of the plottable data, use a "." in that position. - Such as':'':' + Such as:: @axes=["time", ".", "."] @@ -188,14 +187,19 @@ NXdata(NXobject): is described by the values of a one-dimensional array named ``time`` while the other two dimensions have no fields to be used as dimension scales. - See examples provided on the NeXus wiki':' - https':'//www.nexusformat.org/2014_axes_and_uncertainties.html + See examples provided on the NeXus wiki: + https://www.nexusformat.org/2014_axes_and_uncertainties.html If there are no axes at all (such as with a stack of images), the axes attribute can be omitted. \@AXISNAME_indices: type: NX_INT - doc: | + + # nxdl.xsd rules do not allow us to show this as a variable name + # - we'll use ALL CAPS (see #562) + + # AXISNAME_indices documentation copied from datarules.rst + doc: | Each ``AXISNAME_indices`` attribute indicates the dependency relationship of the ``AXISNAME`` field (where ``AXISNAME`` is the name of a field that exists in this ``NXdata`` group) @@ -210,16 +214,16 @@ NXdata(NXobject): Here, *AXISNAME* is to be replaced by the name of each field described in the ``axes`` attribute. - An example with 2-D data, ':'math':'`d(t,P)`, will illustrate':'':' + An example with 2-D data, :math:`d(t,P)`, will illustrate:: - data_2d':'NXdata + data_2d:NXdata @signal="data" @axes=["time", "pressure"] @time_indices=0 @pressure_indices=1 - data':' float[1000,20] - time':' float[1000] - pressure':' float[20] + data: float[1000,20] + time: float[1000] + pressure: float[20] This attribute is to be provided in all situations. However, if the indices attributes are missing @@ -230,12 +234,12 @@ NXdata(NXobject): ``AXISNAME_indices`` attribute is based on the model of "strict writer, liberal reader". - .. note':'':' Attributes potentially containing multiple values + .. note:: Attributes potentially containing multiple values (axes and _indices) are to be written as string or integer arrays, to avoid string parsing in reading applications. AXISNAME(NX_NUMBER): nameType: any - doc: | + doc: | Dimension scale defining an axis of the data. Client is responsible for defining the dimensions of the data. The name of this field may be changed to fit the circumstances. @@ -243,29 +247,29 @@ NXdata(NXobject): how to use this field. dimensions: rank: 1 - doc: | + doc: | A *dimension scale* must have a rank of 1 and has length ``n``. dim: [[1, n]] \@long_name: - doc: | + doc: | Axis label \@distribution: type: NX_BOOLEAN - doc: | - ``0|false``':' single value, - ``1|true``':' multiple values + doc: | + ``0|false``: single value, + ``1|true``: multiple values \@first_good: type: NX_INT - doc: | + doc: | Index of first good value \@last_good: type: NX_INT - doc: | + doc: | Index of last good value \@axis: type: NX_POSINT deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | + doc: | Index (positive integer) identifying this specific set of numbers. N.B. The ``axis`` attribute is the old way of designating a link. @@ -273,7 +277,7 @@ NXdata(NXobject): The ``axes`` *group* attribute is now preferred. FIELDNAME_errors(NX_NUMBER): nameType: any - doc: | + doc: | "Errors" (meaning *uncertainties* or *standard deviations*) associated with any field named ``FIELDNAME`` in this ``NXdata`` group (e.g. an axis, signal or auxiliary signal). @@ -282,8 +286,8 @@ NXdata(NXobject): the dimensions of the ``FIELDNAME`` field. DATA(NX_NUMBER): nameType: any - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting This field contains the data values to be used as the NeXus *plottable data*. @@ -293,7 +297,7 @@ NXdata(NXobject): how to use this field. dimensions: rank: dataRank - doc: | + doc: | The rank (``dataRank``) of the ``data`` must satisfy ``1 <= dataRank <= NX_MAXRANK=32``. At least one ``dim`` must have length ``n``. @@ -301,56 +305,56 @@ NXdata(NXobject): \@signal: type: NX_POSINT deprecated: Use the group ``signal`` attribute (NIAC2014) - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Plottable (independent) axis, indicate index number. - Only one field in a ':'ref':'`NXdata` group may have the + Only one field in a :ref:`NXdata` group may have the ``signal=1`` attribute. Do not use the ``signal`` attribute with the ``axis`` attribute. \@axes: deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | + doc: | Defines the names of the dimension scales (independent axes) for this data set as a colon-delimited array. - NOTE':' The ``axes`` attribute is the preferred + NOTE: The ``axes`` attribute is the preferred method of designating a link. Do not use the ``axes`` attribute with the ``axis`` attribute. \@long_name: - doc: | + doc: | data label errors(NX_NUMBER): deprecated: Use ``DATA_errors`` instead (NIAC2018) - doc: | + doc: | Standard deviations of data values - the data array is identified by the group attribute ``signal``. The ``errors`` array must have the same dimensions as ``DATA``. Client is responsible for defining the dimensions of the data. dimensions: rank: dataRank - doc: | + doc: | The ``errors`` must have the same rank (``dataRank``) as the ``data``. At least one ``dim`` must have length "n". dim: [] scaling_factor(NX_FLOAT): - doc: | + doc: | The elements in data are usually float values really. For efficiency reasons these are usually stored as integers after scaling with a scale factor. This value is the scale factor. It is required to get the actual physical value, when necessary. offset(NX_FLOAT): - doc: | + doc: | An optional offset to apply to the values in data. title: - doc: | + doc: | Title for the plot. x(NX_FLOAT): unit: NX_ANY - doc: | + doc: | This is an array holding the values to use for the x-axis of data. The units must be appropriate for the measurement. dimensions: @@ -358,7 +362,7 @@ NXdata(NXobject): dim: [[1, nx]] y(NX_FLOAT): unit: NX_ANY - doc: | + doc: | This is an array holding the values to use for the y-axis of data. The units must be appropriate for the measurement. dimensions: @@ -366,9 +370,438 @@ NXdata(NXobject): dim: [[1, ny]] z(NX_FLOAT): unit: NX_ANY - doc: | + doc: | This is an array holding the values to use for the z-axis of data. The units must be appropriate for the measurement. dimensions: rank: 1 dim: [[1, nz]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d6fe670cbf59475c1b29039a0baddf5bfef45444afa616430ef5d73b2465788c +# +# +# +# +# +# +# +# +# These symbols will be used below to coordinate fields with the same shape. +# rank of the ``DATA`` field +# length of the ``AXISNAME`` field +# length of the ``x`` field +# length of the ``y`` field +# length of the ``z`` field +# +# +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of additional +# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. +# These fields or links *must* exist and be direct children of this NXdata group. +# +# Each auxiliary signal needs to be of the same shape as the default signal. +# +# .. NIAC2018: +# https://www.nexusformat.org/NIAC2018Minutes.html +# +# +# +# +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: signal attribute value +# +# Declares which NeXus field is the default. +# The value is the :ref:`name <validItemName>` of the data field to be plotted. +# This field or link *must* exist and be a direct child of this NXdata group. +# +# It is recommended (as of NIAC2014) to use this attribute +# rather than adding a signal attribute to the field. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of +# the independent data fields used in the default plot for all of +# the dimensions of the :ref:`signal </NXdata@signal-attribute>` +# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. +# +# One name is provided for every dimension in the *signal* or *auxiliary signal* fields. +# +# The *axes* values are the names of fields or links that *must* exist and be direct +# children of this NXdata group. +# +# An axis slice is specified using a field named ``AXISNAME_indices`` +# as described below (where the text shown here as ``AXISNAME`` is to be +# replaced by the actual field name). +# +# When no default axis is available for a particular dimension +# of the plottable data, use a "." in that position. +# Such as:: +# +# @axes=["time", ".", "."] +# +# Since there are three items in the list, the *signal* field +# must be a three-dimensional array (rank=3). The first dimension +# is described by the values of a one-dimensional array named ``time`` +# while the other two dimensions have no fields to be used as dimension scales. +# +# See examples provided on the NeXus wiki: +# https://www.nexusformat.org/2014_axes_and_uncertainties.html +# +# If there are no axes at all (such as with a stack of images), +# the axes attribute can be omitted. +# +# +# +# +# +# +# Each ``AXISNAME_indices`` attribute indicates the dependency +# relationship of the ``AXISNAME`` field (where ``AXISNAME`` +# is the name of a field that exists in this ``NXdata`` group) +# with one or more dimensions of the plottable data. +# +# Integer array that defines the indices of the *signal* field +# (that field will be a multidimensional array) +# which need to be used in the *AXISNAME* field in +# order to reference the corresponding axis value. +# +# The first index of an array is ``0`` (zero). +# +# Here, *AXISNAME* is to be replaced by the name of each +# field described in the ``axes`` attribute. +# An example with 2-D data, :math:`d(t,P)`, will illustrate:: +# +# data_2d:NXdata +# @signal="data" +# @axes=["time", "pressure"] +# @time_indices=0 +# @pressure_indices=1 +# data: float[1000,20] +# time: float[1000] +# pressure: float[20] +# +# This attribute is to be provided in all situations. +# However, if the indices attributes are missing +# (such as for data files written before this specification), +# file readers are encouraged to make their best efforts +# to plot the data. +# Thus the implementation of the +# ``AXISNAME_indices`` attribute is based on the model of +# "strict writer, liberal reader". +# +# .. note:: Attributes potentially containing multiple values +# (axes and _indices) are to be written as string or integer arrays, +# to avoid string parsing in reading applications. +# +# +# +# +# :ref:`NXdata` describes the plottable data and related dimension scales. +# +# .. index:: plotting +# +# It is strongly recommended that there is at least one :ref:`NXdata` +# group in each :ref:`NXentry` group. +# Note that the fields named ``AXISNAME`` and ``DATA`` +# can be defined with different names. +# (Upper case is used to indicate that the actual name is left to the user.) +# The ``signal`` and ``axes`` attributes of the +# ``data`` group define which items +# are plottable data and which are *dimension scales*, respectively. +# +# :ref:`NXdata` is used to implement one of the basic motivations in NeXus, +# to provide a default plot for the data of this :ref:`NXentry`. The actual data +# might be stored in another group and (hard) linked to the :ref:`NXdata` group. +# +# * Each :ref:`NXdata` group will define one field as the default +# plottable data. The value of the ``signal`` attribute names this field. +# Additional fields may be used to describe the dimension scales and +# uncertainities. +# The ``auxiliary_signals`` attribute is a list of the other fields +# to be plotted with the ``signal`` data. +# * The plottable data may be of arbitrary rank up to a maximum +# of ``NX_MAXRANK=32`` (for compatibility with backend file formats). +# * The plottable data will be named as the value of +# the group ``signal`` attribute, such as:: +# +# data:NXdata +# @signal = "counts" +# @axes = "mr" +# @mr_indices = 0 +# counts: float[100] --> the default dependent data +# mr: float[100] --> the default independent data +# +# The field named in the ``signal`` attribute **must** exist, either +# directly as a NeXus field or defined through a link. +# +# * The group ``axes`` attribute will name the +# *dimension scale* associated with the plottable data. +# +# If available, the standard deviations of the data are to be +# stored in a data set of the same rank and dimensions, with the name ``errors``. +# +# * For each data dimension, there should be a one-dimensional array +# of the same length. +# * These one-dimensional arrays are the *dimension scales* of the +# data, *i.e*. the values of the independent variables at which the data +# is measured, such as scattering angle or energy transfer. +# +# .. index:: link +# .. index:: axes (attribute) +# +# The preferred method to associate each data dimension with +# its respective dimension scale is to specify the field name +# of each dimension scale in the group ``axes`` attribute as a string list. +# Here is an example for a 2-D data set *data* plotted +# against *time*, and *pressure*. (An additional *temperature* data set +# is provided and could be selected as an alternate for the *pressure* axis.):: +# +# data_2d:NXdata +# @signal="data" +# @axes=["time", "pressure"] +# @pressure_indices=1 +# @temperature_indices=1 +# @time_indices=0 +# data: float[1000,20] +# pressure: float[20] +# temperature: float[20] +# time: float[1000] +# +# .. rubric:: Old methods to identify the plottable data +# +# There are two older methods of associating +# each data dimension to its respective dimension scale. +# Both are now out of date and +# should not be used when writing new data files. +# However, client software should expect to see data files +# written with any of these methods. +# +# * One method uses the ``axes`` +# attribute to specify the names of each *dimension scale*. +# +# * The oldest method uses the ``axis`` attribute on each +# *dimension scale* to identify +# with an integer the axis whose value is the number of the dimension. +# +# .. index: !plot; axis label +# plot, axis units +# units +# dimension scale +# +# Each axis of the plot may be labeled with information from the +# dimension scale for that axis. The optional ``@long_name`` attribute +# is provided as the axis label default. If ``@long_name`` is not +# defined, then use the name of the dimension scale. A ``@units`` attribute, +# if available, may be added to the axis label for further description. +# See the section :ref:`Design-Units` for more information. +# +# .. index: !plot; axis title +# +# The optional ``title`` field, if available, provides a suggested +# title for the plot. If no ``title`` field is found in the :ref:`NXdata` +# group, look for a ``title`` field in the parent :ref:`NXentry` group, +# with a fallback to displaying the path to the :ref:`NXdata` group. +# +# NeXus is about how to find and annotate the data to be plotted +# but not to describe how the data is to be plotted. +# (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) +# +# +# +# Dimension scale defining an axis of the data. +# Client is responsible for defining the dimensions of the data. +# The name of this field may be changed to fit the circumstances. +# Standard NeXus client tools will use the attributes to determine +# how to use this field. +# +# +# +# A *dimension scale* must have a rank of 1 and has length ``n``. +# +# +# +# Axis label +# +# +# ``0|false``: single value, +# ``1|true``: multiple values +# +# +# Index of first good value +# Index of last good value +# +# +# Index (positive integer) identifying this specific set of numbers. +# +# N.B. The ``axis`` attribute is the old way of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# The ``axes`` *group* attribute is now preferred. +# +# +# +# +# +# "Errors" (meaning *uncertainties* or *standard deviations*) +# associated with any field named ``FIELDNAME`` in this ``NXdata`` +# group (e.g. an axis, signal or auxiliary signal). +# +# The dimensions of the ``FIELDNAME_errors`` field must match +# the dimensions of the ``FIELDNAME`` field. +# +# +# +# +# .. index:: plotting +# +# This field contains the data values to be used as the +# NeXus *plottable data*. +# Client is responsible for defining the dimensions of the data. +# The name of this field may be changed to fit the circumstances. +# Standard NeXus client tools will use the attributes to determine +# how to use this field. +# +# +# +# The rank (``dataRank``) of the ``data`` must satisfy +# ``1 <= dataRank <= NX_MAXRANK=32``. +# At least one ``dim`` must have length ``n``. +# +# +# +# +# .. index:: plotting +# +# Plottable (independent) axis, indicate index number. +# Only one field in a :ref:`NXdata` group may have the +# ``signal=1`` attribute. +# Do not use the ``signal`` attribute with the ``axis`` attribute. +# +# +# +# +# Defines the names of the dimension scales +# (independent axes) for this data set +# as a colon-delimited array. +# NOTE: The ``axes`` attribute is the preferred +# method of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# +# +# +# data label +# +# +# +# +# Standard deviations of data values - +# the data array is identified by the group attribute ``signal``. +# The ``errors`` array must have the same dimensions as ``DATA``. +# Client is responsible for defining the dimensions of the data. +# +# +# +# The ``errors`` must have +# the same rank (``dataRank``) +# as the ``data``. +# At least one ``dim`` must have length "n". +# +# +# +# +# +# The elements in data are usually float values really. For +# efficiency reasons these are usually stored as integers +# after scaling with a scale factor. This value is the scale +# factor. It is required to get the actual physical value, +# when necessary. +# +# +# +# +# An optional offset to apply to the values in data. +# +# +# +# +# Title for the plot. +# +# +# +# +# This is an array holding the values to use for the x-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the y-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the z-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml index 10c01743e1..ae8735680e 100644 --- a/base_classes/nyaml/NXdetector.yaml +++ b/base_classes/nyaml/NXdetector.yaml @@ -1,9 +1,8 @@ category: base -doc: | +doc: | A detector, detector bank, or multidetector. - -symbols: - doc: | +symbols: + doc: | These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets will vary according to the situation) and the general ordering principle is slowest to fastest. @@ -11,57 +10,54 @@ symbols: then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced by a detector at each trigger. - - nP: | + nP: | number of scan points (only present in scanning measurements) - - i: | + i: | number of detector pixels in the first (slowest) direction - - j: | + j: | number of detector pixels in the second (faster) direction - - tof: | + tof: | number of bins in the time-of-flight histogram - type: group (NXobject)NXdetector: time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT - doc: | + doc: | Total time of flight dimensions: rank: 1 dim: [[1, tof+1]] \@axis: type: NX_POSINT - deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 + deprecated: + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [3] \@primary: type: NX_POSINT - deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 + deprecated: + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: - doc: | + doc: | Total time of flight raw_time_of_flight(NX_INT): unit: NX_PULSES - doc: | + doc: | In DAQ clock pulses dimensions: rank: 1 dim: [[1, tof+1]] \@frequency: type: NX_NUMBER - doc: | + doc: | Clock frequency in Hz detector_number(NX_INT): - doc: | + doc: | Identifier for detector (pixels) Can be multidimensional, if needed data(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Data values from the detector. The rank and dimension ordering should follow a principle of slowest to fastest measurement axes and may be explicitly specified in application definitions. @@ -88,15 +84,15 @@ type: group rank: 4 dim: [[1, nP], [2, i], [3, j], [4, tof]] \@long_name: - doc: | + doc: | Title of measurement \@check_sum: type: NX_INT - doc: | + doc: | Integral of data as check of data integrity data_errors(NX_NUMBER): unit: NX_ANY - doc: | + doc: | The best estimate of the uncertainty in the data value (array size should match the data field). Where possible, this should be the standard deviation, which has the same units as the data. The form data_error is deprecated. @@ -105,7 +101,7 @@ type: group dim: [[1, nP], [2, i], [3, j], [4, tof]] x_pixel_offset(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Offset from the detector center in x-direction. Can be multidimensional when needed. dimensions: @@ -113,18 +109,20 @@ type: group dim: [[1, i], [2, j]] \@axis: type: NX_POSINT - deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 + deprecated: + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@primary: type: NX_POSINT - deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 + deprecated: + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: - doc: | + doc: | x-axis offset from detector center y_pixel_offset(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Offset from the detector center in the y-direction. Can be multidimensional when different values are required for each pixel. dimensions: @@ -132,18 +130,20 @@ type: group dim: [[1, i], [2, j]] \@axis: type: NX_POSINT - deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 + deprecated: + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [2] \@primary: type: NX_POSINT - deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 + deprecated: + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: - doc: | + doc: | y-axis offset from detector center z_pixel_offset(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Offset from the detector center in the z-direction. Can be multidimensional when different values are required for each pixel. dimensions: @@ -151,21 +151,23 @@ type: group dim: [[1, i], [2, j]] \@axis: type: NX_POSINT - deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 + deprecated: + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [3] \@primary: type: NX_POSINT - deprecated: see':' https':'//github.com/nexusformat/definitions/issues/436 + deprecated: + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: - doc: | + doc: | y-axis offset from detector center distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the distance to the previous component in the instrument; most often the sample. The usage depends on the - nature of the detector':' Most often it is the distance of the + nature of the detector: Most often it is the distance of the detector assembly. But there are irregular detectors. In this case the distance must be specified for each detector pixel. @@ -175,7 +177,7 @@ type: group dim: [[1, nP], [2, i], [3, j]] polar_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | This is the polar angle of the detector towards the previous component in the instrument; most often the sample. The usage depends on the @@ -191,7 +193,7 @@ type: group dim: [[1, nP], [2, i], [3, j]] azimuthal_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | This is the azimuthal angle angle of the detector towards the previous component in the instrument; most often the sample. The usage depends on the @@ -206,109 +208,114 @@ type: group rank: 3 dim: [[1, nP], [2, i], [3, j]] description: - doc: | + doc: | name/manufacturer/model/etc. information serial_number: - doc: | + doc: | Serial number for the detector local_name: - doc: | + doc: | Local name for the detector (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead + doc: | Position and orientation of detector solid_angle(NX_FLOAT): unit: NX_SOLID_ANGLE - doc: | + doc: | Solid angle subtended by the detector at the sample dimensions: rank: 2 dim: [[1, i], [2, j]] x_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Size of each detector pixel. If it is scalar all pixels are the same size. dimensions: rank: 2 dim: [[1, i], [2, j]] y_pixel_size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Size of each detector pixel. If it is scalar all pixels are the same size dimensions: rank: 2 dim: [[1, i], [2, j]] dead_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | Detector dead time dimensions: rank: 3 dim: [[1, nP], [2, i], [3, j]] gas_pressure(NX_FLOAT): unit: NX_PRESSURE - doc: | + doc: | Detector gas pressure dimensions: rank: 2 dim: [[1, i], [2, j]] detection_gas_path(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | maximum drift space dimension crate(NX_INT): - doc: | + doc: | Crate number of detector dimensions: rank: 2 dim: [[1, i], [2, j]] \@local_name: - doc: | + doc: | Equivalent local term slot(NX_INT): - doc: | + doc: | Slot number of detector dimensions: rank: 2 dim: [[1, i], [2, j]] \@local_name: - doc: | + doc: | Equivalent local term input(NX_INT): - doc: | + doc: | Input number of detector dimensions: rank: 2 dim: [[1, i], [2, j]] \@local_name: - doc: | + doc: | Equivalent local term type: - doc: | + doc: | Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, ... efficiency(NXdata): - doc: | + doc: | Spectral efficiency of detector with respect to e.g. wavelength \@signal: enumeration: [efficiency] \@axes: + + # TODO: clarify the various use cases enumeration: [., . ., . . ., . . . ., wavelength] \@wavelength_indices: + + # TODO: clarify the actual possibilities enumeration: [0] efficiency(NX_FLOAT): unit: NX_DIMENSIONLESS - doc: | + doc: | efficiency of the detector dimensions: rank: 2 dim: [[1, i], [2, j]] wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | - This field can be two things':' + doc: | + This field can be two things: #. For a pixel detector it provides the nominal wavelength for which the detector has been calibrated. @@ -324,7 +331,7 @@ type: group dim: [[1, i], [2, j]] real_time(NX_NUMBER): unit: NX_TIME - doc: | + doc: | Real-time of the exposure (use this if exposure time varies for each array element, otherwise use ``count_time`` field). @@ -338,7 +345,7 @@ type: group dim: [[1, nP], [2, i], [3, j]] start_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | start time for each frame, with the ``start`` attribute as absolute reference dimensions: rank: 1 @@ -347,7 +354,7 @@ type: group type: NX_DATE_TIME stop_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | stop time for each frame, with the ``start`` attribute as absolute reference dimensions: rank: 1 @@ -355,29 +362,29 @@ type: group \@start: type: NX_DATE_TIME calibration_date(NX_DATE_TIME): - doc: | + doc: | date of last calibration (geometry and/or efficiency) measurements calibration_method(NXnote): - doc: | + doc: | summary of conversion of array data to pixels (e.g. polynomial approximations) and location of details of the calibrations layout: - doc: | + doc: | How the detector is represented enumeration: [point, linear, area] count_time(NX_NUMBER): unit: NX_TIME - doc: | + doc: | Elapsed actual counting time dimensions: rank: 1 dim: [[1, nP]] data_file(NXnote): (NXcollection): - doc: | + doc: | Use this group to provide other data related to this NXdetector group. sequence_number(NX_INT): - doc: | + doc: | In order to properly sort the order of the images taken in (for example) a tomography experiment, a sequence number is stored with each image. @@ -386,65 +393,65 @@ type: group dim: [[1, nP]] beam_center_x(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the x position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as documented by the units attribute. beam_center_y(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the y position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as documented by the units attribute. frame_start_number(NX_INT): - doc: | + doc: | This is the start number of the first frame of a scan. In protein crystallography measurements one often scans a couple of frames on a give sample, then does something else, then returns to the same sample and scans some more frames. Each time with a new data file. This number helps concatenating such measurements. diameter(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | The diameter of a cylindrical detector acquisition_mode(NX_CHAR): - doc: | + doc: | The acquisition mode of the detector. enumeration: [gated, triggered, summed, event, histogrammed, decimated] angular_calibration_applied(NX_BOOLEAN): - doc: | + doc: | True when the angular calibration has been applied in the electronics, false otherwise. angular_calibration(NX_FLOAT): - doc: | + doc: | Angular calibration data. dimensions: rank: 2 dim: [[1, i], [2, j]] flatfield_applied(NX_BOOLEAN): - doc: | + doc: | True when the flat field correction has been applied in the electronics, false otherwise. flatfield(NX_FLOAT): - doc: | + doc: | Flat field correction data. dimensions: rank: 2 dim: [[1, i], [2, j]] flatfield_errors(NX_FLOAT): - doc: | + doc: | Errors of the flat field correction data. The form flatfield_error is deprecated. dimensions: rank: 2 dim: [[1, i], [2, j]] pixel_mask_applied(NX_BOOLEAN): - doc: | + doc: | True when the pixel mask correction has been applied in the electronics, false otherwise. pixel_mask(NX_INT): - doc: | + doc: | The 32-bit pixel mask for the detector. Can be either one mask for the whole dataset (i.e. an array with indices i, j) or each frame can have its own mask (in which case it would be @@ -452,21 +459,21 @@ type: group Contains a bit field for each pixel to signal dead, blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning':' + They have the following meaning: .. can't make a table here, a bullet list will have to do for now - * bit 0':' gap (pixel with no sensor) - * bit 1':' dead - * bit 2':' under responding - * bit 3':' over responding - * bit 4':' noisy - * bit 5':' -undefined- - * bit 6':' pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7':' -undefined- - * bit 8':' user defined mask (e.g. around beamstop) - * bits 9-30':' -undefined- - * bit 31':' virtual pixel (corner pixel with interpolated value) + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) Normal data analysis software would not take pixels into account @@ -493,16 +500,16 @@ type: group rank: 2 dim: [[1, i], [2, j]] image_key(NX_INT): - doc: | + doc: | This field allow to distinguish different types of exposure to the same detector "data" field. Some techniques require frequent (re-)calibration inbetween measuremnts and this way of recording the different measurements preserves the chronological order with is important for correct processing. - This is used for example in tomography (`':'ref':'`NXtomo`) sample projections, + This is used for example in tomography (`:ref:`NXtomo`) sample projections, dark and flat images, a magic number is recorded per frame. - The key is as follows':' + The key is as follows: * projection (sample) = 0 * flat field = 1 @@ -510,29 +517,29 @@ type: group * invalid = 3 * background (no sample, but buffer where applicable) = 4 - In cases where the data is of type ':'ref':'`NXlog` this can also be an NXlog. + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. dimensions: rank: 1 dim: [[1, np]] countrate_correction_applied(NX_BOOLEAN): - doc: | + doc: | Counting detectors usually are not able to measure all incoming particles, especially at higher count-rates. Count-rate correction is applied to account for these errors. True when count-rate correction has been applied, false otherwise. countrate_correction_lookup_table(NX_NUMBER): - doc: | + doc: | The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count ':'math':'`c` to its corrected value - ':'math':'`countrate\_correction\_lookup\_table[c]`. + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. - ':'math':'`m` denotes the length of the table. + :math:`m` denotes the length of the table. dimensions: rank: 1 dim: [[1, m]] virtual_pixel_interpolation_applied(NX_BOOLEAN): - doc: | + doc: | True when virtual pixel interpolation has been applied, false otherwise. When virtual pixel interpolation is applied, values of some pixels may @@ -541,30 +548,30 @@ type: group chips may have larger sensor areas and counts may be distributed between their logical pixels. bit_depth_readout(NX_INT): - doc: | + doc: | How many bits the electronics reads per pixel. With CCD's and single photon counting detectors, this must not align with traditional integer sizes. This can be 4, 8, 12, 14, 16, ... detector_readout_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | Time it takes to read the detector (typically milliseconds). This is important to know for time resolved experiments. trigger_delay_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | Time it takes to start exposure after a trigger signal has been received. This is the reaction time of the detector firmware after receiving the trigger signal to when the detector starts to acquire the exposure, including any user set delay.. This is important to know for time resolved experiments. trigger_delay_time_set(NX_FLOAT): unit: NX_TIME - doc: | + doc: | User-specified trigger delay. trigger_internal_delay_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | Time it takes to start exposure after a trigger signal has been received. This is the reaction time of the detector hardware after receiving the trigger signal to when the detector starts to acquire the exposure. @@ -572,25 +579,25 @@ type: group does not request an additional delay. trigger_dead_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | Time during which no new trigger signal can be accepted. Typically this is the trigger_delay_time + exposure_time + readout_time. This is important to know for time resolved experiments. frame_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | This is time for each frame. This is exposure_time + readout time. dimensions: rank: 1 dim: [[1, nP]] gain_setting(NX_CHAR): - doc: | + doc: | The gain setting of the detector. This is a detector-specific value meant to document the gain setting of the detector during data collection, for detectors with multiple available gain settings. - Examples of gain settings include':' + Examples of gain settings include: * ``standard`` * ``fast`` @@ -604,7 +611,7 @@ type: group Developers are encouraged to use one of these terms, or to submit additional terms to add to the list. saturation_value(NX_NUMBER): - doc: | + doc: | The value at which the detector goes into saturation. Especially common to CCD detectors, the data is known to be invalid above this value. @@ -615,7 +622,7 @@ type: group The precise type should match the type of the data. underload_value(NX_NUMBER): - doc: | + doc: | The lowest value at which pixels for this detector would be reasonably measured. The data is known to be invalid below this value. @@ -625,66 +632,66 @@ type: group The precise type should match the type of the data. number_of_cycles(NX_INT): - doc: | + doc: | CCD images are sometimes constructed by summing together multiple short exposures in the electronics. This reduces background etc. This is the number of short exposures used to sum images for an image. sensor_material(NX_CHAR): - doc: | + doc: | At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. This is the name of this converter material. sensor_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. This is the thickness of this converter material. threshold_energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | Single photon counter detectors can be adjusted for a certain energy range in which they work optimally. This is the energy setting for this. (NXdetector_module): - doc: | + doc: | For use in special cases where the data in NXdetector is represented in several parts, each with a separate geometry. pixel_shape(choice): (NXoff_geometry): - doc: | + doc: | Shape description of each pixel. Use only if all pixels in the detector are of uniform shape. (NXcylindrical_geometry): - doc: | + doc: | Shape description of each pixel. Use only if all pixels in the detector are of uniform shape and require being described by cylinders. detector_shape(choice): (NXoff_geometry): - doc: | + doc: | Shape description of the whole detector. Use only if pixels in the detector are not of uniform shape. (NXcylindrical_geometry): - doc: | + doc: | Shape description of the whole detector. Use only if pixels in the detector are not of uniform shape and require being described by cylinders. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -695,8 +702,966 @@ type: group The reference point of the detector is the center of the first pixel. In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1f2e8ea7ab0f64a22ae7363f22f0399b4f6ea9274df5976a7d312d464371fc13 +# +# +# +# +# +# +# +# These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the +# preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets +# will vary according to the situation) and the general ordering principle is slowest to fastest. +# The type of each dimension should follow the order of scan points, detector output (e.g. pixels), +# then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited +# to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced +# by a detector at each trigger. +# +# +# number of scan points (only present in scanning measurements) +# number of detector pixels in the first (slowest) direction +# number of detector pixels in the second (faster) direction +# number of bins in the time-of-flight histogram +# +# +# +# A detector, detector bank, or multidetector. +# +# +# +# Total time of flight +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total time of flight +# +# +# +# +# In DAQ clock pulses +# +# +# +# +# +# +# Clock frequency in Hz +# +# +# +# +# +# Identifier for detector (pixels) +# Can be multidimensional, if needed +# +# +# +# +# +# Data values from the detector. The rank and dimension ordering should follow a principle of +# slowest to fastest measurement axes and may be explicitly specified in application definitions. +# +# Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be +# the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions +# of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single +# scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. +# Repetition of an experiment in a time series tends to be used similar to a slow scan axis +# and so will often be in the first dimension of the data array. +# +# The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions +# (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an +# imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data +# will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to +# be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. +# +# Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift +# detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. +# +# The type of each dimension should should follow the order of scan points, detector pixels, +# then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) +# shown here are merely illustrative of coordination between related datasets. +# +# +# +# +# +# +# +# +# +# +# Title of measurement +# +# +# +# Integral of data as check of data integrity +# +# +# +# +# +# +# The best estimate of the uncertainty in the data value (array size should match the data field). Where +# possible, this should be the standard deviation, which has the same units +# as the data. The form data_error is deprecated. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Offset from the detector center in x-direction. +# Can be multidimensional when needed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# x-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the y-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# +# Offset from the detector center in the z-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# This is the distance to the previous component in the +# instrument; most often the sample. The usage depends on the +# nature of the detector: Most often it is the distance of the +# detector assembly. But there are irregular detectors. In this +# case the distance must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# +# This is the polar angle of the detector towards the previous +# component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the polar_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the polar_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# +# This is the azimuthal angle angle of the detector towards +# the previous component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the azimuthal_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the azimuthal_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# name/manufacturer/model/etc. information +# +# +# +# Serial number for the detector +# +# +# +# Local name for the detector +# +# +# +# Position and orientation of detector +# +# +# +# Solid angle subtended by the detector at the sample +# +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size. +# +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# +# +# +# +# +# Detector dead time +# +# +# +# +# +# +# +# +# +# Detector gas pressure +# +# +# +# +# +# +# +# +# maximum drift space dimension +# +# +# +# Crate number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# Slot number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# Input number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Description of type such as He3 gas cylinder, He3 PSD, scintillator, +# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, +# CMOS, ... +# +# +# +# +# Spectral efficiency of detector with respect to e.g. wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# efficiency of the detector +# +# +# +# +# +# +# +# +# +# This field can be two things: +# +# #. For a pixel detector it provides the nominal wavelength +# for which the detector has been calibrated. +# +# #. For other detectors this field has to be seen together with +# the efficiency field above. +# For some detectors, the efficiency is wavelength dependent. +# Thus this field provides the wavelength axis for the efficiency field. +# In this use case, the efficiency and wavelength arrays must +# have the same dimensionality. +# +# +# +# +# +# +# +# +# +# +# +# Real-time of the exposure (use this if exposure time varies for +# each array element, otherwise use ``count_time`` field). +# +# Most often there is a single real time value that is constant across +# an entire image frame. In such cases, only a 1-D array is needed. +# But there are detectors in which the real time +# changes per pixel. In that case, more than one dimension is needed. Therefore +# the rank of this field should be less than or equal to (detector rank + 1). +# +# +# +# +# +# +# +# +# +# start time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# stop time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# date of last calibration (geometry and/or efficiency) measurements +# +# +# +# +# +# summary of conversion of array data to pixels (e.g. polynomial +# approximations) and location of details of the calibrations +# +# +# +# +# How the detector is represented +# +# +# +# +# +# +# +# +# +# Elapsed actual counting time +# +# +# +# +# +# +# +# +# +# +# Use this group to provide other data related to this NXdetector group. +# +# +# +# +# +# In order to properly sort the order of the images taken in (for +# example) a tomography experiment, a sequence number is stored with each +# image. +# +# +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# +# This is the y position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# +# This is the start number of the first frame of a scan. In protein crystallography measurements one +# often scans a couple of frames on a give sample, then does something else, +# then returns to the same sample and scans some more frames. Each time with +# a new data file. This number helps concatenating such measurements. +# +# +# +# +# The diameter of a cylindrical detector +# +# +# +# The acquisition mode of the detector. +# +# +# +# +# +# +# +# +# +# +# +# True when the angular calibration has been applied in the +# electronics, false otherwise. +# +# +# +# Angular calibration data. +# +# +# +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# Flat field correction data. +# +# +# +# +# +# +# +# Errors of the flat field correction data. +# The form flatfield_error is deprecated. +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# The 32-bit pixel mask for the detector. Can be either one mask +# for the whole dataset (i.e. an array with indices i, j) or +# each frame can have its own mask (in which case it would be +# an array with indices np, i, j). +# +# Contains a bit field for each pixel to signal dead, +# blind or high or otherwise unwanted or undesirable pixels. +# They have the following meaning: +# +# .. can't make a table here, a bullet list will have to do for now +# +# * bit 0: gap (pixel with no sensor) +# * bit 1: dead +# * bit 2: under responding +# * bit 3: over responding +# * bit 4: noisy +# * bit 5: -undefined- +# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) +# * bit 7: -undefined- +# * bit 8: user defined mask (e.g. around beamstop) +# * bits 9-30: -undefined- +# * bit 31: virtual pixel (corner pixel with interpolated value) +# +# Normal data analysis software would +# not take pixels into account +# when a bit in (mask & 0x0000FFFF) is +# set. Tag bit in the upper +# two bytes would indicate special pixel +# properties that normally +# would not be a sole reason to reject the +# intensity value (unless +# lower bits are set. +# +# If the full bit depths is not required, providing a +# mask with fewer bits is permissible. +# +# If needed, additional pixel masks can be specified by +# including additional entries named pixel_mask_N, where +# N is an integer. For example, a general bad pixel mask +# could be specified in pixel_mask that indicates noisy +# and dead pixels, and an additional pixel mask from +# experiment-specific shadowing could be specified in +# pixel_mask_2. The cumulative mask is the bitwise OR +# of pixel_mask and any pixel_mask_N entries. +# +# +# +# +# +# +# +# +# +# This field allow to distinguish different types of exposure to the same detector "data" field. +# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of +# recording the different measurements preserves the chronological order with is important for +# correct processing. +# +# This is used for example in tomography (`:ref:`NXtomo`) sample projections, +# dark and flat images, a magic number is recorded per frame. +# +# The key is as follows: +# +# * projection (sample) = 0 +# * flat field = 1 +# * dark field = 2 +# * invalid = 3 +# * background (no sample, but buffer where applicable) = 4 +# +# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. +# +# +# +# +# +# +# +# +# Counting detectors usually are not able to measure all incoming particles, +# especially at higher count-rates. Count-rate correction is applied to +# account for these errors. +# +# True when count-rate correction has been applied, false otherwise. +# +# +# +# +# The countrate_correction_lookup_table defines the LUT used for count-rate +# correction. It maps a measured count :math:`c` to its corrected value +# :math:`countrate\_correction\_lookup\_table[c]`. +# +# :math:`m` denotes the length of the table. +# +# +# +# +# +# +# +# True when virtual pixel interpolation has been applied, false otherwise. +# +# When virtual pixel interpolation is applied, values of some pixels may +# contain interpolated values. For example, to account for space between +# readout chips on a module, physical pixels on edges and corners between +# chips may have larger sensor areas and counts may be distributed between +# their logical pixels. +# +# +# +# +# How many bits the electronics reads per pixel. +# With CCD's and single photon counting detectors, +# this must not align with traditional integer sizes. +# This can be 4, 8, 12, 14, 16, ... +# +# +# +# +# Time it takes to read the detector (typically milliseconds). +# This is important to know for time resolved experiments. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector firmware after receiving the trigger signal +# to when the detector starts to acquire the exposure, including any user set delay.. +# This is important to know for time resolved experiments. +# +# +# +# +# User-specified trigger delay. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector hardware after receiving the +# trigger signal to when the detector starts to acquire the exposure. +# It forms the lower boundary of the trigger_delay_time when the user +# does not request an additional delay. +# +# +# +# +# Time during which no new trigger signal can be accepted. +# Typically this is the +# trigger_delay_time + exposure_time + readout_time. +# This is important to know for time resolved experiments. +# +# +# +# +# This is time for each frame. This is exposure_time + readout time. +# +# +# +# +# +# +# +# The gain setting of the detector. This is a detector-specific value +# meant to document the gain setting of the detector during data +# collection, for detectors with multiple available gain settings. +# +# Examples of gain settings include: +# +# * ``standard`` +# * ``fast`` +# * ``auto`` +# * ``high`` +# * ``medium`` +# * ``low`` +# * ``mixed high to medium`` +# * ``mixed medium to low`` +# +# Developers are encouraged to use one of these terms, or to submit +# additional terms to add to the list. +# +# +# +# +# The value at which the detector goes into saturation. +# Especially common to CCD detectors, the data +# is known to be invalid above this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# The lowest value at which pixels for this detector would be reasonably +# measured. The data is known to be invalid below this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# CCD images are sometimes constructed by summing +# together multiple short exposures in the +# electronics. This reduces background etc. +# This is the number of short exposures used to sum +# images for an image. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the name of this converter material. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the thickness of this converter material. +# +# +# +# +# Single photon counter detectors can be adjusted +# for a certain energy range in which they +# work optimally. This is the energy setting for this. +# +# +# +# +# For use in special cases where the data in NXdetector +# is represented in several parts, each with a separate geometry. +# +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape. +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape and require being described by cylinders. +# +# +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape. +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape and require being described by cylinders. +# +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the detector is the center of the first pixel. +# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXdetector_group.yaml b/base_classes/nyaml/NXdetector_group.yaml index f6903e382b..c087d3b193 100644 --- a/base_classes/nyaml/NXdetector_group.yaml +++ b/base_classes/nyaml/NXdetector_group.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | Logical grouping of detectors. When used, describes a group of detectors. Each detector is represented as an NXdetector @@ -17,28 +17,27 @@ doc: | in the field group_index, and the level in the hierarchy given in the group_parent field. For example if an x-ray detector group, DET, consists of four detectors in a - rectangular array':'':' + rectangular array:: DTL DTR DLL DLR - We could have':'':' + We could have:: - group_names':' ["DET", "DTL", "DTR", "DLL", "DLR"] - group_index':' [1, 2, 3, 4, 5] - group_parent':' [-1, 1, 1, 1, 1] - + group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] + group_index: [1, 2, 3, 4, 5] + group_parent: [-1, 1, 1, 1, 1] type: group NXdetector_group(NXobject): group_names(NX_CHAR): - doc: | + doc: | An array of the names of the detectors given in NXdetector groups or the names of hierarchical groupings of detectors given as names of NXdetector_group groups or in NXdetector_group group_names and group_parent fields as having children. group_index(NX_INT): - doc: | + doc: | An array of unique identifiers for detectors or groupings of detectors. @@ -48,7 +47,7 @@ NXdetector_group(NXobject): dimensions: dim: [[1, i]] group_parent(NX_INT): - doc: | + doc: | An array of the hierarchical levels of the parents of detectors or groupings of detectors. @@ -58,20 +57,126 @@ NXdetector_group(NXobject): dim_parameters: ref: ['group_index'] group_type(NX_INT): - doc: | + doc: | Code number for group type, e.g. bank=1, tube=2 etc. dimensions: dim: [[1, ]] dim_parameters: ref: ['group_index'] \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 691ea608a29ca9acf2ea185458c9dc75285438032148ac1529e5ebcf0d96b4b7 +# +# +# +# +# +# Logical grouping of detectors. When used, describes a group of detectors. +# +# Each detector is represented as an NXdetector +# with its own detector data array. Each detector data array +# may be further decomposed into array sections by use of +# NXdetector_module groups. Detectors can be grouped logically +# together using NXdetector_group. Groups can be further grouped +# hierarchically in a single NXdetector_group (for example, if +# there are multiple detectors at an endstation or multiple +# endstations at a facility). Alternatively, multiple +# NXdetector_groups can be provided. +# +# The groups are defined hierarchically, with names given +# in the group_names field, unique identifying indices given +# in the field group_index, and the level in the hierarchy +# given in the group_parent field. For example if an x-ray +# detector group, DET, consists of four detectors in a +# rectangular array:: +# +# DTL DTR +# DLL DLR +# +# We could have:: +# +# group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] +# group_index: [1, 2, 3, 4, 5] +# group_parent: [-1, 1, 1, 1, 1] +# +# +# +# An array of the names of the detectors given in NXdetector +# groups or the names of hierarchical groupings of detectors +# given as names of NXdetector_group groups or in +# NXdetector_group group_names and group_parent fields as +# having children. +# +# +# +# +# An array of unique identifiers for detectors or groupings +# of detectors. +# +# Each ID is a unique ID for the corresponding detector or group +# named in the field group_names. The IDs are positive integers +# starting with 1. +# +# +# +# +# +# An array of the hierarchical levels of the parents of detectors +# or groupings of detectors. +# +# A top-level grouping has parent level -1. +# +# +# +# Code number for group type, e.g. bank=1, tube=2 etc. +# +# +# +# +# .. 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/nyaml/NXdetector_module.yaml b/base_classes/nyaml/NXdetector_module.yaml index 7e5b95cee6..d7e1c35f76 100644 --- a/base_classes/nyaml/NXdetector_module.yaml +++ b/base_classes/nyaml/NXdetector_module.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | Geometry and logical description of a detector module. When used, child group to NXdetector. Many detectors consist of multiple @@ -8,11 +8,10 @@ doc: | This is the purpose of this group. It is a child group to NXdetector. Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. - type: group NXdetector_module(NXobject): data_origin(NX_INT): - doc: | + doc: | A dimension-2 or dimension-3 field which gives the indices of the origin of the hyperslab of data for this module in the main area detector image in the parent NXdetector module. @@ -25,39 +24,39 @@ NXdetector_module(NXobject): dataset with indices (np, i, j, k) will be an array with indices (i, j, k). - The ':'ref':'`order ` of indices (i, j or i, j, k) is slow to fast. + The :ref:`order ` of indices (i, j or i, j, k) is slow to fast. data_size(NX_INT): - doc: | + doc: | Two or three values for the size of the module in pixels in each direction. Dimensionality and order of indices is the same as for data_origin. module_offset(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | Offset of the module in regards to the origin of the detector in an arbitrary direction. \@transformation_type: enumeration: [translation] \@vector: type: NX_NUMBER - doc: | + doc: | Three values that define the axis for this transformation \@offset: type: NX_NUMBER - doc: | + doc: | A fixed offset applied before the transformation (three vector components). \@offset_units: type: NX_CHAR - doc: | + doc: | Units of the offset. \@depends_on: type: NX_CHAR - doc: | + doc: | Points to the path of the next element in the geometry chain. fast_pixel_direction(NX_NUMBER): unit: NX_LENGTH - doc: | - Values along the direction of ':'ref':'`fastest varying ` ':'index':'`pixel direction`. Each value in this + doc: | + Values along the direction of :ref:`fastest varying ` :index:`pixel direction`. Each value in this array is the size of a pixel in the units specified. Alternatively, if only one value is given, all pixels in this direction have the same value. The direction itself is given through the vector attribute. @@ -65,24 +64,24 @@ NXdetector_module(NXobject): enumeration: [translation] \@vector: type: NX_NUMBER - doc: | + doc: | Three values that define the axis for this transformation \@offset: type: NX_NUMBER - doc: | + doc: | A fixed offset applied before the transformation (three vector components). \@offset_units: type: NX_CHAR - doc: | + doc: | Units of the offset. \@depends_on: type: NX_CHAR - doc: | + doc: | Points to the path of the next element in the geometry chain. slow_pixel_direction(NX_NUMBER): unit: NX_LENGTH - doc: | - Values along the direction of ':'ref':'`slowest varying` ':'index':'`pixel direction`. Each value in this + doc: | + Values along the direction of :ref:`slowest varying` :index:`pixel direction`. Each value in this array is the size of a pixel in the units specified. Alternatively, if only one value is given, all pixels in this direction have the same value. The direction itself is given through the vector attribute. @@ -90,31 +89,214 @@ NXdetector_module(NXobject): enumeration: [translation] \@vector: type: NX_NUMBER - doc: | + doc: | Three values that define the axis for this transformation \@offset: type: NX_NUMBER - doc: | + doc: | A fixed offset applied before the transformation (three vector components). \@offset_units: type: NX_CHAR - doc: | + doc: | Units of the offset. \@depends_on: type: NX_CHAR - doc: | + doc: | Points to the path of the next element in the geometry chain. depends_on(NX_CHAR): - doc: | + doc: | Points to the start of the dependency chain for this module. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 648bcf7b5b6f0a233d30dfbea9f75968750c251551912aa642fa2172e8d6413a +# +# +# +# +# +# Geometry and logical description of a detector module. When used, child group to NXdetector. +# +# Many detectors consist of multiple +# smaller modules. Sometimes it is important to know the exact position of such +# modules. +# This is the purpose of this group. It is a child group to NXdetector. +# +# Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. +# +# +# +# A dimension-2 or dimension-3 field which gives the indices +# of the origin of the hyperslab of data for this module in the +# main area detector image in the parent NXdetector module. +# +# The data_origin is 0-based. +# +# The frame number dimension (np) is omitted. Thus the +# data_origin field for a dimension-2 dataset with indices (np, i, j) +# will be an array with indices (i, j), and for a dimension-3 +# dataset with indices (np, i, j, k) will be an array with indices +# (i, j, k). +# +# The :ref:`order <Design-ArrayStorageOrder>` of indices (i, j or i, j, k) is slow to fast. +# +# +# +# +# Two or three values for the size of the module in pixels in +# each direction. Dimensionality and order of indices is the +# same as for data_origin. +# +# +# +# +# Offset of the module in regards to the origin of the detector in an +# arbitrary direction. +# +# +# +# +# +# +# +# +# Three values that define the axis for this transformation +# +# +# +# +# A fixed offset applied before the transformation (three vector components). +# +# +# +# +# Units of the offset. +# +# +# +# +# Points to the path of the next element in the geometry chain. +# +# +# +# +# +# Values along the direction of :ref:`fastest varying <Design-ArrayStorageOrder>` :index:`pixel direction<dimension; fastest varying>`. Each value in this +# array is the size of a pixel in the units specified. Alternatively, if only one +# value is given, all pixels in this direction have the same value. The direction +# itself is given through the vector attribute. +# +# +# +# +# +# +# +# +# Three values that define the axis for this transformation +# +# +# +# +# A fixed offset applied before the transformation (three vector components). +# +# +# +# +# Units of the offset. +# +# +# +# +# Points to the path of the next element in the geometry chain. +# +# +# +# +# +# Values along the direction of :ref:`slowest varying<Design-ArrayStorageOrder>` :index:`pixel direction<dimension; slowest varying>`. Each value in this +# array is the size of a pixel in the units specified. Alternatively, if only one +# value is given, all pixels in this direction have the same value. The direction +# itself is given through the vector attribute. +# +# +# +# +# +# +# +# +# Three values that define the axis for this transformation +# +# +# +# +# A fixed offset applied before the transformation (three vector components). +# +# +# +# +# Units of the offset. +# +# +# +# +# Points to the path of the next element in the geometry chain. +# +# +# +# +# +# Points to the start of the dependency chain for this module. +# +# +# +# +# .. 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/nyaml/NXdisk_chopper.yaml b/base_classes/nyaml/NXdisk_chopper.yaml index 45a786e60f..983e75e2b0 100644 --- a/base_classes/nyaml/NXdisk_chopper.yaml +++ b/base_classes/nyaml/NXdisk_chopper.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | A device blocking the beam in a temporal periodic pattern. A disk which blocks the beam but has one or more slits to periodically @@ -13,39 +13,36 @@ doc: | Angles and positive rotation speeds are measured in an anticlockwise direction when facing away from the source. - -symbols: - doc: | +symbols: + doc: | This symbol will be used below to coordinate datasets with the same shape. - - n: | + n: | Number of slits in the disk - type: group NXdisk_chopper(NXobject): type: - doc: | - Type of the disk-chopper':' only one from the enumerated list (match text exactly) + doc: | + Type of the disk-chopper: only one from the enumerated list (match text exactly) enumeration: [Chopper type single, contra_rotating_pair, synchro_pair] rotation_speed(NX_FLOAT): unit: NX_FREQUENCY - doc: | + doc: | Chopper rotation speed. Positive for anticlockwise rotation when facing away from the source, negative otherwise. slits(NX_INT): - doc: | + doc: | Number of slits slit_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Angular opening pair_separation(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Disk spacing in direction of beam slit_edges(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Angle of each edge of every slit from the position of the top-dead-center timestamp sensor, anticlockwise when facing away from the source. @@ -55,69 +52,70 @@ NXdisk_chopper(NXobject): dim: [[1, 2n]] top_dead_center(NX_NUMBER): unit: NX_TIME - doc: | + doc: | Timestamps of the top-dead-center signal. The times are relative to the "start" attribute and in the units specified in the "units" attribute. Please note that absolute - timestamps under unix are relative to ``1970-01-01T00':'00':'00.0Z``. + timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. \@start: type: NX_DATE_TIME beam_position(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Angular separation of the center of the beam and the top-dead-center timestamp sensor, anticlockwise when facing away from the source. radius(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Radius of the disk slit_height(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Total slit height phase(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Chopper phase angle delay(NX_NUMBER): unit: NX_TIME - doc: | + doc: | Time difference between timing system t0 and chopper driving clock signal ratio(NX_INT): - doc: | + doc: | Pulse reduction factor of this chopper in relation to other choppers/fastest pulse in the instrument distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Effective distance to the origin. Note, it is recommended to use NXtransformations instead. wavelength_range(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | Low and high values of wavelength range transmitted dimensions: dim: [[1, 2]] (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -130,13 +128,195 @@ NXdisk_chopper(NXobject): centre of the axle which the disk is spinning around. The reference plane is orthogonal to the z axis and its position is the reference point on that axis. - Note':' This reference point in almost all practical cases is not where the beam passes though. + Note: This reference point in almost all practical cases is not where the beam passes though. - .. image':'':' disk_chopper/disk_chopper.png - ':'width':' 40% + .. image:: disk_chopper/disk_chopper.png + :width: 40% (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e1666b3ec25ec80dd82906a832708fb1284d9fff6b0896e1bf720fb948b15fbe +# +# +# +# +# +# +# This symbol will be used below to coordinate datasets with the same shape. +# Number of slits in the disk +# +# +# +# A device blocking the beam in a temporal periodic pattern. +# +# A disk which blocks the beam but has one or more slits to periodically +# let neutrons through as the disk rotates. Often used in pairs, one +# NXdisk_chopper should be defined for each disk. +# +# The rotation of the disk is commonly monitored by recording a timestamp for +# each full rotation of disk, by having a sensor in the stationary disk housing +# sensing when it is aligned with a feature (such as a magnet) on the disk. +# We refer to this below as the "top-dead-center signal". +# +# Angles and positive rotation speeds are measured in an anticlockwise +# direction when facing away from the source. +# +# +# +# Type of the disk-chopper: only one from the enumerated list (match text exactly) +# +# +# +# +# +# +# +# +# Chopper rotation speed. Positive for anticlockwise rotation when +# facing away from the source, negative otherwise. +# +# +# +# Number of slits +# +# +# Angular opening +# +# +# Disk spacing in direction of beam +# +# +# +# Angle of each edge of every slit from the position of the +# top-dead-center timestamp sensor, anticlockwise when facing +# away from the source. +# The first edge must be the opening edge of a slit, thus the last edge +# may have an angle greater than 360 degrees. +# +# +# +# +# +# Timestamps of the top-dead-center signal. The times are relative +# to the "start" attribute and in the units specified in the "units" +# attribute. Please note that absolute +# timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. +# +# +# +# +# +# Angular separation of the center of the beam and the +# top-dead-center timestamp sensor, anticlockwise when facing +# away from the source. +# +# +# +# Radius of the disk +# +# +# Total slit height +# +# +# Chopper phase angle +# +# +# +# Time difference between timing system t0 and chopper driving clock signal +# +# +# +# +# Pulse reduction factor of this chopper in relation to other +# choppers/fastest pulse in the instrument +# +# +# +# +# Effective distance to the origin. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# Low and high values of wavelength range transmitted +# +# +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference plane of the disk chopper includes the surface of the spinning disk which faces +# the source. The reference point in the x and y axis is the point on this surface which is the +# centre of the axle which the disk is spinning around. The reference plane is orthogonal to +# the z axis and its position is the reference point on that axis. +# +# Note: This reference point in almost all practical cases is not where the beam passes though. +# +# .. image:: disk_chopper/disk_chopper.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXentry.yaml b/base_classes/nyaml/NXentry.yaml index e6ae50514d..78c7888e27 100644 --- a/base_classes/nyaml/NXentry.yaml +++ b/base_classes/nyaml/NXentry.yaml @@ -1,40 +1,39 @@ category: base -doc: | - (**required**) ':'ref':'`NXentry` describes the measurement. +doc: | + (**required**) :ref:`NXentry` describes the measurement. The top-level NeXus group which contains all the data and associated information that comprise a single measurement. It is mandatory that there is at least one group of this type in the NeXus file. - type: group NXentry(NXobject): \@default: - doc: | - .. index':'':' find the default plottable data - .. index':'':' plotting - .. index':'':' default attribute value + doc: | + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value - Declares which ':'ref':'`NXdata` group contains the data + Declares which :ref:`NXdata` group contains the data to be shown by default. It is used to resolve ambiguity when - one ':'ref':'`NXdata` group exists. - The value ':'ref':'`names ` a child group. If that group + one :ref:`NXdata` group exists. + The value :ref:`names ` a child group. If that group itself has a ``default`` attribute, continue this chain until an - ':'ref':'`NXdata` group is reached. + :ref:`NXdata` group is reached. For more information about how NeXus identifies the default plottable data, see the - ':'ref':'`Find Plottable Data, v3 ` + :ref:`Find Plottable Data, v3 ` section. (NXdata): - doc: | + doc: | The data group - .. note':'':' Before the NIAC2016 meeting [#]_, at least one - ':'ref':'`NXdata` group was required in each ':'ref':'`NXentry` group. - At the NIAC2016 meeting, it was decided to make ':'ref':'`NXdata` - an optional group in ':'ref':'`NXentry` groups for data files that + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that do not use an application definition. It is recommended strongly that all NeXus data files provide a NXdata group. @@ -46,55 +45,57 @@ NXentry(NXobject): makes a useful plot without extensive processing. Certain application definitions override this decision and - require an ':'ref':'`NXdata` group - in the ':'ref':'`NXentry` group. The ``minOccurs=0`` attribute + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute in the application definition will indicate the - ':'ref':'`NXdata` group + :ref:`NXdata` group is optional, otherwise, it is required. - .. [#] NIAC2016':' - https':'//www.nexusformat.org/NIAC2016.html, - https':'//github.com/nexusformat/NIAC/issues/16 + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 \@IDF_Version: - doc: | + + # as ratified at NIAC2010 + doc: | ISIS Muon IDF_Version title: - doc: | + doc: | Extended title for entry experiment_identifier: - doc: | + doc: | Unique identifier for the experiment, defined by the facility, possibly linked to the proposals experiment_description: - doc: | + doc: | Brief summary of the experiment, including key objectives. (NXnote)experiment_documentation: - doc: | + doc: | Description of the full experiment (document in pdf, latex, ...) collection_identifier: - doc: | + doc: | User or Data Acquisition defined group of NeXus files or NXentry collection_description: - doc: | + doc: | Brief summary of the collection, including grouping criteria. entry_identifier: - doc: | + doc: | unique identifier for the measurement, defined by the facility. entry_identifier_uuid: - doc: | + doc: | UUID identifier for the measurement. \@version: - doc: | + doc: | Version of UUID used features: - doc: | + doc: | Reserved for future use by NIAC. - See https':'//github.com/nexusformat/definitions/issues/382 + See https://github.com/nexusformat/definitions/issues/382 definition: - doc: | - (alternate use':' see same field in ':'ref':'`NXsubentry` for preferred) + doc: | + (alternate use: see same field in :ref:`NXsubentry` for preferred) Official NeXus NXDL schema to which this entry conforms which must be the name of the NXDL file (case sensitive without the file extension) @@ -103,79 +104,83 @@ NXentry(NXobject): For example the ``definition`` field for a file that conformed to the *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. - This field is provided so that ':'ref':'`NXentry` can be the overlay position + This field is provided so that :ref:`NXentry` can be the overlay position in a NeXus data file for an application definition and its set of groups, fields, and attributes. - *It is advised* to use ':'ref':'`NXsubentry`, instead, as the overlay position. + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. \@version: - doc: | + doc: | NXDL version number \@URL: - doc: | + doc: | URL of NXDL file definition_local: - deprecated: see same field in ':'ref':'`NXsubentry` for preferred use - doc: | + deprecated: + see same field in :ref:`NXsubentry` for preferred use + doc: | Local NXDL schema extended from the entry specified in the ``definition`` field. This contains any locally-defined, additional fields in the entry. \@version: - doc: | + doc: | NXDL version number \@URL: - doc: | + doc: | URL of NXDL file start_time(NX_DATE_TIME): - doc: | + doc: | Starting time of measurement end_time(NX_DATE_TIME): - doc: | + doc: | Ending time of measurement duration(NX_INT): unit: NX_TIME - doc: | + doc: | Duration of measurement collection_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | Time transpired actually collecting data i.e. taking out time when collection was suspended due to e.g. temperature out of range run_cycle: - doc: | + doc: | Such as "2007-3". Some user facilities organize their beam time into run cycles. program_name: - doc: | + doc: | Name of program used to generate this file \@version: - doc: | + doc: | Program version number \@configuration: - doc: | + doc: | configuration of the program revision: - doc: | + doc: | Revision id of the file due to re-calibration, reprocessing, new analysis, new instrument definition format, ... \@comment: pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words':' it the distance to the component + by the moderator or the source itself. In other words: it the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. notes(NXnote): - doc: | + doc: | Notes describing entry thumbnail(NXnote): - doc: | + doc: | A small image that is representative of the entry. An example of this is a 640x480 jpeg image automatically produced by a low resolution plot of the NXdata. \@type: - doc: | + doc: | The mime type should be an ``image/*`` + + # This is not perfect. + # How do we set a default value for the type attribute? enumeration: [image/*] (NXuser): (NXsample): @@ -185,3 +190,236 @@ NXentry(NXobject): (NXparameters): (NXprocess): (NXsubentry): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6f55039ff7886b759df0a35ec22f7e2727fe3778b1d55cba6c9c0ea1d4eaf7df +# +# +# +# +# +# +# +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXdata` group contains the data +# to be shown by default. +# It is used to resolve ambiguity when +# one :ref:`NXdata` group exists. +# The value :ref:`names <validItemName>` a child group. If that group +# itself has a ``default`` attribute, continue this chain until an +# :ref:`NXdata` group is reached. +# +# For more information about how NeXus identifies the default +# plottable data, see the +# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` +# section. +# +# +# +# +# (**required**) :ref:`NXentry` describes the measurement. +# +# The top-level NeXus group which contains all the data and associated +# information that comprise a single measurement. +# It is mandatory that there is at least one +# group of this type in the NeXus file. +# +# +# +# The data group +# +# .. note:: Before the NIAC2016 meeting [#]_, at least one +# :ref:`NXdata` group was required in each :ref:`NXentry` group. +# At the NIAC2016 meeting, it was decided to make :ref:`NXdata` +# an optional group in :ref:`NXentry` groups for data files that +# do not use an application definition. +# It is recommended strongly that all NeXus data files provide +# a NXdata group. +# It is permissable to omit the NXdata group only when +# defining the default plot is not practical or possible +# from the available data. +# +# For example, neutron event data may not have anything that +# makes a useful plot without extensive processing. +# +# Certain application definitions override this decision and +# require an :ref:`NXdata` group +# in the :ref:`NXentry` group. The ``minOccurs=0`` attribute +# in the application definition will indicate the +# :ref:`NXdata` group +# is optional, otherwise, it is required. +# +# .. [#] NIAC2016: +# https://www.nexusformat.org/NIAC2016.html, +# https://github.com/nexusformat/NIAC/issues/16 +# +# +# +# +# +# +# ISIS Muon IDF_Version +# +# +# Extended title for entry +# +# +# +# Unique identifier for the experiment, +# defined by the facility, +# possibly linked to the proposals +# +# +# +# Brief summary of the experiment, including key objectives. +# +# +# Description of the full experiment (document in pdf, latex, ...) +# +# +# User or Data Acquisition defined group of NeXus files or NXentry +# +# +# Brief summary of the collection, including grouping criteria. +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# UUID identifier for the measurement. +# Version of UUID used +# +# +# +# Reserved for future use by NIAC. +# +# See https://github.com/nexusformat/definitions/issues/382 +# +# +# +# +# (alternate use: see same field in :ref:`NXsubentry` for preferred) +# +# Official NeXus NXDL schema to which this entry conforms which must be +# the name of the NXDL file (case sensitive without the file extension) +# that the NXDL schema is defined in. +# +# For example the ``definition`` field for a file that conformed to the +# *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. +# +# This field is provided so that :ref:`NXentry` can be the overlay position +# in a NeXus data file for an application definition and its +# set of groups, fields, and attributes. +# +# *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. +# +# NXDL version number +# URL of NXDL file +# +# +# +# Local NXDL schema extended from the entry +# specified in the ``definition`` field. +# This contains any locally-defined, +# additional fields in the entry. +# +# NXDL version number +# URL of NXDL file +# +# +# Starting time of measurement +# +# +# Ending time of measurement +# +# +# Duration of measurement +# +# +# +# Time transpired actually collecting data i.e. taking out time when collection was +# suspended due to e.g. temperature out of range +# +# +# +# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# +# +# Name of program used to generate this file +# Program version number +# configuration of the program +# +# +# +# Revision id of the file due to re-calibration, reprocessing, new analysis, new +# instrument definition format, ... +# +# +# +# +# +# This is the flightpath before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# Notes describing entry +# +# +# +# A small image that is representative of the entry. An example of this is a 640x480 +# jpeg image automatically produced by a low resolution plot of the NXdata. +# +# +# The mime type should be an ``image/*`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml index efb083eb15..3ba6fd2baf 100644 --- a/base_classes/nyaml/NXenvironment.yaml +++ b/base_classes/nyaml/NXenvironment.yaml @@ -1,30 +1,29 @@ category: base -doc: | +doc: | Parameters for controlling external conditions - type: group NXenvironment(NXobject): name: - doc: | + doc: | Apparatus identification code/model number; e.g. OC100 011 short_name: - doc: | + doc: | Alternative short name, perhaps for dashboard display like a present Seblock name type: - doc: | + doc: | Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 description: - doc: | + doc: | Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump program: - doc: | + doc: | Program controlling the apparatus; e.g. LabView VI name position(NXgeometry): - doc: | + doc: | The position and orientation of the apparatus. Note, it is recommended to use NXtransformations instead. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -33,12 +32,89 @@ NXenvironment(NXobject): NXtransformations group. But NeXus allows them to be stored anywhere. (NXtransformations): exists: ['min', '0'] - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. (NXnote): - doc: | + doc: | Additional information, LabView logs, digital photographs, etc (NXsensor): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8d95a3f1615f3146244d8f2a05eda98e75a2ca49ffefa97329db446c658f9def +# +# +# +# +# Parameters for controlling external conditions +# +# Apparatus identification code/model number; e.g. OC100 011 +# +# +# Alternative short name, perhaps for dashboard display like a present Seblock name +# +# +# Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 +# +# +# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump +# +# +# Program controlling the apparatus; e.g. LabView VI name +# +# +# +# The position and orientation of the apparatus. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# Additional information, LabView logs, digital photographs, etc +# +# +# +# diff --git a/base_classes/nyaml/NXevent_data.yaml b/base_classes/nyaml/NXevent_data.yaml index f2d8d628fc..c75f0ee867 100644 --- a/base_classes/nyaml/NXevent_data.yaml +++ b/base_classes/nyaml/NXevent_data.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | NXevent_data is a special group for storing data from neutron detectors in event mode. In this mode, the detector electronics emits a stream of detectorID, timestamp pairs. With detectorID @@ -23,19 +23,18 @@ doc: | every five minutes. The cue_index will then contain the index into the event_id,event_time_offset pair of arrays for that courser cue_timestamp_zero. - type: group NXevent_data(NXobject): event_time_offset(NX_NUMBER): unit: NX_TIME_OF_FLIGHT - doc: | + doc: | A list of timestamps for each event as it comes in. dimensions: rank: 1 dim: [[1, i]] event_id(NX_INT): unit: NX_DIMENSIONLESS - doc: | + doc: | There will be extra information in the NXdetector to convert event_id to detector_number. dimensions: @@ -43,18 +42,18 @@ NXevent_data(NXobject): dim: [[1, i]] event_time_zero(NX_NUMBER): unit: NX_TIME - doc: | + doc: | The time that each pulse started with respect to the offset dimensions: rank: 1 dim: [[1, j]] \@offset: type: NX_DATE_TIME - doc: | + doc: | ISO8601 event_index(NX_INT): unit: NX_DIMENSIONLESS - doc: | + doc: | The index into the event_time_offset, event_id pair for the pulse occurring at the matching entry in event_time_zero. dimensions: @@ -62,33 +61,160 @@ NXevent_data(NXobject): dim: [[1, j]] pulse_height(NX_FLOAT): unit: NX_DIMENSIONLESS - doc: | + doc: | If voltages from the ends of the detector are read out this is where they go. This list is for all events with information to attach to a particular pulse height. The information to attach to a particular pulse is located in events_per_pulse. dimensions: rank: 2 + + # i,k? dim: [[1, i], [2, k]] cue_timestamp_zero(NX_DATE_TIME): unit: NX_TIME - doc: | + doc: | Timestamps matching the corresponding cue_index into the event_id, event_time_offset pair. \@start: type: NX_DATE_TIME cue_index(NX_INT): - doc: | + doc: | Index into the event_id, event_time_offset pair matching the corresponding cue_timestamp. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8ed9dbd7316d38b106211e5be368886684addd89e347b28ec11e7e88d6ca88bb +# +# +# +# +# +# NXevent_data is a special group for storing data from neutron +# detectors in event mode. In this mode, the detector electronics +# emits a stream of detectorID, timestamp pairs. With detectorID +# describing the detector element in which the neutron was detected +# and timestamp the timestamp at which the neutron event was +# detected. In NeXus detectorID maps to event_id, event_time_offset +# to the timestamp. +# +# As this kind of data is common at pulsed neutron +# sources, the timestamp is almost always relative to the start of a +# neutron pulse. Thus the pulse timestamp is recorded too together +# with an index in the event_id, event_time_offset pair at which data for +# that pulse starts. At reactor source the same pulsed data effect +# may be achieved through the use of choppers or in stroboscopic +# measurement setups. +# +# In order to make random access to timestamped data +# faster there is an optional array pair of +# cue_timestamp_zero and cue_index. The cue_timestamp_zero will +# contain courser timestamps then in the time array, say +# every five minutes. The cue_index will then contain the +# index into the event_id,event_time_offset pair of arrays for that +# courser cue_timestamp_zero. +# +# +# +# A list of timestamps for each event as it comes in. +# +# +# +# +# +# There will be extra information in the NXdetector to convert +# event_id to detector_number. +# +# +# +# +# +# The time that each pulse started with respect to the offset +# +# +# +# ISO8601 +# +# +# +# +# The index into the event_time_offset, event_id pair for +# the pulse occurring at the matching entry in event_time_zero. +# +# +# +# +# +# If voltages from the ends of the detector are read out this +# is where they go. This list is for all events with information +# to attach to a particular pulse height. The information to +# attach to a particular pulse is located in events_per_pulse. +# +# +# +# +# +# +# +# +# Timestamps matching the corresponding cue_index into the +# event_id, event_time_offset pair. +# +# +# +# +# +# Index into the event_id, event_time_offset pair matching the corresponding +# cue_timestamp. +# +# +# +# +# .. 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/nyaml/NXfermi_chopper.yaml b/base_classes/nyaml/NXfermi_chopper.yaml index 4665e5a978..90bf463bcd 100644 --- a/base_classes/nyaml/NXfermi_chopper.yaml +++ b/base_classes/nyaml/NXfermi_chopper.yaml @@ -1,79 +1,81 @@ category: base -doc: | +doc: | A Fermi chopper, possibly with curved slits. - type: group NXfermi_chopper(NXobject): type: - doc: | + doc: | Fermi chopper type rotation_speed(NX_FLOAT): unit: NX_FREQUENCY - doc: | + doc: | chopper rotation speed radius(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | radius of chopper slit(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | width of an individual slit r_slit(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | radius of curvature of slits number(NX_INT): unit: NX_UNITLESS - doc: | + doc: | number of slits height(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | input beam height width(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | input beam width distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | distance. Note, it is recommended to use NXtransformations instead. wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + + # should have units of angstroms or nm or pm + doc: | Wavelength transmitted by chopper energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | energy selected (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead + doc: | geometry of the fermi chopper absorbing_material: - doc: | + doc: | absorbing material transmitting_material: - doc: | + doc: | transmitting material (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -81,11 +83,128 @@ NXfermi_chopper(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a fermi chopper. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8abe047606006e4149eef1a11578301898263f4ca8c5fe2d952f4d95c0e89020 +# +# +# +# +# A Fermi chopper, possibly with curved slits. +# +# Fermi chopper type +# +# +# chopper rotation speed +# +# +# radius of chopper +# +# +# width of an individual slit +# +# +# radius of curvature of slits +# +# +# number of slits +# +# +# input beam height +# +# +# input beam width +# +# +# distance. Note, it is recommended to use NXtransformations instead. +# +# +# +# Wavelength transmitted by chopper +# +# +# energy selected +# +# +# geometry of the fermi chopper +# +# +# absorbing material +# +# +# transmitting material +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a fermi chopper. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXfilter.yaml b/base_classes/nyaml/NXfilter.yaml index e887b13e2f..77783be27c 100644 --- a/base_classes/nyaml/NXfilter.yaml +++ b/base_classes/nyaml/NXfilter.yaml @@ -1,58 +1,60 @@ category: base -doc: | +doc: | For band pass beam filters. - If uncertain whether to use ':'ref':'`NXfilter` (band-pass filter) - or ':'ref':'`NXattenuator` (reduces beam intensity), then use - ':'ref':'`NXattenuator`. - + If uncertain whether to use :ref:`NXfilter` (band-pass filter) + or :ref:`NXattenuator` (reduces beam intensity), then use + :ref:`NXattenuator`. type: group NXfilter(NXobject): (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to filter the beamstop and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to filter the beamstop and NXoff_geometry to describe its shape instead + doc: | Geometry of the filter description: - doc: | + doc: | Composition of the filter. Chemical formula can be specified separately. This field was changed (2010-11-17) from an enumeration to a string since common usage showed a wider variety of use than a simple list. These are the items in the list at - the time of the change':' Beryllium | Pyrolytic Graphite | + the time of the change: Beryllium | Pyrolytic Graphite | Graphite | Sapphire | Silicon | Supermirror. status: - doc: | + doc: | position with respect to in or out of the beam (choice of only "in" or "out") enumeration: in: - doc: | + doc: | in the beam out: - doc: | + doc: | out of the beam transmission(NXdata): - doc: | + doc: | Wavelength transmission profile of filter temperature(NX_FLOAT): unit: NX_TEMPERATURE - doc: | + doc: | average/nominal filter temperature temperature_log(NXlog): - doc: | + doc: | Linked temperature_log for the filter thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Thickness of the filter density(NX_NUMBER): unit: NX_MASS_DENSITY - doc: | + doc: | mass density of the filter chemical_formula: - doc: | + + # copied from NXsample + doc: | The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard':' + Abbreviated version of CIF standard: * Only recognized element symbols may be used. * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. @@ -63,95 +65,99 @@ NXfilter(NXobject): * 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':' + * 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. * This is the *Hill* system used by Chemical Abstracts. sensor_type(NXsensor): - doc: | + doc: | Sensor(s)used to monitor the filter temperature unit_cell_a(NX_FLOAT): unit: NX_LENGTH - doc: | - Unit cell lattice parameter':' length of side a + doc: | + Unit cell lattice parameter: length of side a unit_cell_b(NX_FLOAT): unit: NX_LENGTH - doc: | - Unit cell lattice parameter':' length of side b + doc: | + Unit cell lattice parameter: length of side b unit_cell_c(NX_FLOAT): unit: NX_LENGTH - doc: | - Unit cell lattice parameter':' length of side c + doc: | + Unit cell lattice parameter: length of side c unit_cell_alpha(NX_FLOAT): unit: NX_ANGLE - doc: | - Unit cell lattice parameter':' angle alpha + doc: | + Unit cell lattice parameter: angle alpha unit_cell_beta(NX_FLOAT): unit: NX_ANGLE - doc: | - Unit cell lattice parameter':' angle beta + doc: | + Unit cell lattice parameter: angle beta unit_cell_gamma(NX_FLOAT): unit: NX_ANGLE - doc: | - Unit cell lattice parameter':' angle gamma + doc: | + Unit cell lattice parameter: angle gamma unit_cell_volume(NX_FLOAT): unit: NX_VOLUME - doc: | + doc: | Unit cell dimensions: rank: 1 dim: [[1, n_comp]] orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal filter using Busing-Levy convention':' + doc: | + Orientation matrix of single crystal filter using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 dimensions: rank: 3 + + # n_comp,3,3 + + # TODO n_comp is number of different compositions? dim: [[1, n_comp], [2, 3], [3, 3]] m_value(NX_FLOAT): unit: NX_DIMENSIONLESS - doc: | + doc: | m value of supermirror filter substrate_material: - doc: | + doc: | substrate material of supermirror filter substrate_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | substrate thickness of supermirror filter coating_material: - doc: | + doc: | coating material of supermirror filter substrate_roughness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | substrate roughness (RMS) of supermirror filter coating_roughness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | coating roughness (RMS) of supermirror filter dimensions: rank: 1 dim: [[1, nsurf]] (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -159,11 +165,209 @@ NXfilter(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a filter. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 785085298ea124d1b61ba6667be36d608a4416471c6e7909f4c53382b216ba88 +# +# +# +# +# +# For band pass beam filters. +# +# If uncertain whether to use :ref:`NXfilter` (band-pass filter) +# or :ref:`NXattenuator` (reduces beam intensity), then use +# :ref:`NXattenuator`. +# +# +# Geometry of the filter +# +# +# +# Composition of the filter. Chemical formula can be specified separately. +# +# This field was changed (2010-11-17) from an enumeration to +# a string since common usage showed a wider variety of use +# than a simple list. These are the items in the list at +# the time of the change: Beryllium | Pyrolytic Graphite | +# Graphite | Sapphire | Silicon | Supermirror. +# +# +# +# position with respect to in or out of the beam (choice of only "in" or "out") +# +# in the beam +# out of the beam +# +# +# +# Wavelength transmission profile of filter +# +# +# average/nominal filter temperature +# +# +# Linked temperature_log for the filter +# +# +# Thickness of the filter +# +# +# mass density of the filter +# +# +# +# +# The chemical formula specified using CIF conventions. +# Abbreviated version of CIF standard: +# +# * 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. +# +# * This is the *Hill* system used by Chemical Abstracts. +# +# +# +# Sensor(s)used to monitor the filter temperature +# +# +# Unit cell lattice parameter: length of side a +# +# +# Unit cell lattice parameter: length of side b +# +# +# Unit cell lattice parameter: length of side c +# +# +# Unit cell lattice parameter: angle alpha +# +# +# Unit cell lattice parameter: angle beta +# +# +# Unit cell lattice parameter: angle gamma +# +# +# Unit cell +# +# +# +# +# Orientation matrix of single crystal filter using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# +# m value of supermirror filter +# +# +# substrate material of supermirror filter +# +# +# substrate thickness of supermirror filter +# +# +# coating material of supermirror filter +# +# +# substrate roughness (RMS) of supermirror filter +# +# +# coating roughness (RMS) of supermirror filter +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a filter. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXflipper.yaml b/base_classes/nyaml/NXflipper.yaml index 70a4416bcc..ea20d1a8d4 100644 --- a/base_classes/nyaml/NXflipper.yaml +++ b/base_classes/nyaml/NXflipper.yaml @@ -1,52 +1,51 @@ category: base -doc: | +doc: | A spin flipper. - type: group NXflipper(NXobject): type: enumeration: [coil, current-sheet] flip_turns(NX_FLOAT): unit: NX_PER_LENGTH - doc: | + doc: | Linear density of turns (such as number of turns/cm) in flipping field coils comp_turns(NX_FLOAT): unit: NX_PER_LENGTH - doc: | + doc: | Linear density of turns (such as number of turns/cm) in compensating field coils guide_turns(NX_FLOAT): unit: NX_PER_LENGTH - doc: | + doc: | Linear density of turns (such as number of turns/cm) in guide field coils flip_current(NX_FLOAT): unit: NX_CURRENT - doc: | + doc: | Flipping field coil current in "on" state" comp_current(NX_FLOAT): unit: NX_CURRENT - doc: | + doc: | Compensating field coil current in "on" state" guide_current(NX_FLOAT): unit: NX_CURRENT - doc: | + doc: | Guide field coil current in "on" state thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | thickness along path of neutron travel \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -54,11 +53,107 @@ NXflipper(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a spin flipper. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 62c4f526c364c8ede653c3a19e5aed1dae3a51685eb7137a46a3d906c1cc60bf +# +# +# +# +# A spin flipper. +# +# +# +# +# +# +# +# Linear density of turns (such as number of turns/cm) in flipping field coils +# +# +# Linear density of turns (such as number of turns/cm) in compensating field coils +# +# +# Linear density of turns (such as number of turns/cm) in guide field coils +# +# +# Flipping field coil current in "on" state" +# +# +# Compensating field coil current in "on" state" +# +# +# Guide field coil current in "on" state +# +# +# thickness along path of neutron travel +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a spin flipper. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXfresnel_zone_plate.yaml b/base_classes/nyaml/NXfresnel_zone_plate.yaml index d227bc83db..eea7e942f1 100644 --- a/base_classes/nyaml/NXfresnel_zone_plate.yaml +++ b/base_classes/nyaml/NXfresnel_zone_plate.yaml @@ -1,11 +1,10 @@ category: base -doc: | +doc: | A fresnel zone plate - type: group NXfresnel_zone_plate(NXobject): focus_parameters(NX_FLOAT): - doc: | + doc: | list of polynomial coefficients describing the focal length of the zone plate, in increasing powers of photon energy, that describes the focal length of the zone plate (in microns) at an X-ray photon energy (in electron volts). dimensions: @@ -18,16 +17,16 @@ NXfresnel_zone_plate(NXobject): central_stop_diameter(NX_FLOAT): unit: NX_LENGTH fabrication: - doc: | + doc: | how the zone plate was manufactured enumeration: [etched, plated, zone doubled, other] zone_height(NX_FLOAT): unit: NX_LENGTH zone_material: - doc: | + doc: | Material of the zones themselves zone_support_material: - doc: | + doc: | Material present between the zones. This is usually only present for the "zone doubled" fabrication process central_stop_material: central_stop_thickness(NX_FLOAT): @@ -35,24 +34,24 @@ NXfresnel_zone_plate(NXobject): mask_thickness(NX_FLOAT): unit: NX_LENGTH mask_material: - doc: | + doc: | If no mask is present, set mask_thickness to 0 and omit the mask_material field support_membrane_material: support_membrane_thickness(NX_FLOAT): unit: NX_LENGTH \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -60,13 +59,120 @@ NXfresnel_zone_plate(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a fresnel zone plate. (NXtransformations): - doc: | + doc: | "Engineering" position of the fresnel zone plate This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 53901ea435d088aedb91b2f3fa70e315e6269a25bb0b871d938a2cfd0c5a82ec +# +# +# +# +# +# A fresnel zone plate +# +# +# list of polynomial coefficients describing the focal length of the zone plate, in increasing powers of photon energy, +# that describes the focal length of the zone plate (in microns) at an X-ray photon energy (in electron volts). +# +# +# +# +# +# +# +# +# how the zone plate was manufactured +# +# +# +# +# +# +# +# +# +# Material of the zones themselves +# +# +# Material present between the zones. This is usually only present for the "zone doubled" fabrication process +# +# +# +# +# +# If no mask is present, set mask_thickness to 0 and omit the mask_material 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a fresnel zone plate. +# +# +# +# +# +# "Engineering" position of the fresnel zone plate +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXgeometry.yaml b/base_classes/nyaml/NXgeometry.yaml index f22aa83cee..5c1dfb277f 100644 --- a/base_classes/nyaml/NXgeometry.yaml +++ b/base_classes/nyaml/NXgeometry.yaml @@ -1,46 +1,128 @@ category: base -doc: | - legacy class - recommend to use ':'ref':'`NXtransformations` now +doc: | + legacy class - recommend to use :ref:`NXtransformations` now - It is recommended that instances of ':'ref':'`NXgeometry` be converted to - use ':'ref':'`NXtransformations`. + It is recommended that instances of :ref:`NXgeometry` be converted to + use :ref:`NXtransformations`. This is the description for a general position of a component. - It is recommended to name an instance of ':'ref':'`NXgeometry` as "geometry" + It is recommended to name an instance of :ref:`NXgeometry` as "geometry" to aid in the use of the definition in simulation codes such as McStas. Also, in HDF, linked items must share the same name. However, it might not be possible or practical in all situations. - type: group deprecated: as decided at 2014 NIAC meeting, convert to use :ref:`NXtransformations` NXgeometry(NXobject): (NXshape): - doc: | + doc: | shape/size information of component (NXtranslation): - doc: | + doc: | translation of component (NXorientation): - doc: | + doc: | orientation of component description: - doc: | + doc: | Optional description/label. Probably only present if we are an additional reference point for components rather than the location of a real component. component_index(NX_INT): - doc: | + doc: | Position of the component along the beam path. The sample is at 0, components upstream have negative component_index, components downstream have positive component_index. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d7d64aa78775fa8184154f30651e5def6856d4f76f490ba44df0f5a37463b670 +# +# +# +# +# +# legacy class - recommend to use :ref:`NXtransformations` now +# +# It is recommended that instances of :ref:`NXgeometry` be converted to +# use :ref:`NXtransformations`. +# +# This is the description for a general position of a component. +# It is recommended to name an instance of :ref:`NXgeometry` as "geometry" +# to aid in the use of the definition in simulation codes such as McStas. +# Also, in HDF, linked items must share the same name. +# However, it might not be possible or practical in all situations. +# +# +# shape/size information of component +# +# +# translation of component +# +# +# orientation of component +# +# +# +# Optional description/label. Probably only present if we are +# an additional reference point for components rather than the +# location of a real component. +# +# +# +# +# Position of the component along the beam path. The sample is at 0, components upstream +# have negative component_index, components downstream have positive +# component_index. +# +# +# +# +# .. 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/nyaml/NXgrating.yaml b/base_classes/nyaml/NXgrating.yaml index d9a59f03f4..9603971d7c 100644 --- a/base_classes/nyaml/NXgrating.yaml +++ b/base_classes/nyaml/NXgrating.yaml @@ -1,19 +1,18 @@ category: base -doc: | +doc: | A diffraction grating, as could be used in a soft X-ray monochromator - type: group NXgrating(NXobject): angles(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Blaze or trapezoidal angles, with the angle of the upstream facing edge listed first. Blazed gratings can be identified by the low value of the first-listed angle. dimensions: rank: 1 dim: [[1, 2]] period(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | List of polynomial coefficients describing the spatial separation of lines/grooves as a function of position along the grating, in increasing powers of position. Gratings which do not have variable line spacing will only have a single coefficient (constant). dimensions: rank: 1 @@ -26,18 +25,18 @@ NXgrating(NXobject): unit: NX_UNITLESS deflection_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Angle between the incident beam and the utilised outgoing beam. interior_atmosphere: enumeration: [vacuum, helium, argon] substrate_material: - doc: | + doc: | substrate_density(NX_FLOAT): unit: NX_MASS_DENSITY - doc: | + doc: | substrate_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | coating_material: substrate_roughness(NX_FLOAT): unit: NX_LENGTH @@ -45,32 +44,32 @@ NXgrating(NXobject): unit: NX_LENGTH layer_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | An array describing the thickness of each layer (NXshape)shape: deprecated: Use NXoff_geometry to describe the shape of grating - doc: | + doc: | A NXshape group describing the shape of the mirror figure_data(NXdata): - doc: | + doc: | Numerical description of the surface figure of the mirror. (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -78,9 +77,126 @@ NXgrating(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a bending grating. (NXtransformations): - doc: | + doc: | "Engineering" position of the grating Transformations used by this component to define its position and orientation. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e3c616b8b6027b862a3946ab63674969147bd291cefbad316bfb6fdb3477305e +# +# +# +# +# +# A diffraction grating, as could be used in a soft X-ray monochromator +# +# Blaze or trapezoidal angles, with the angle of the upstream facing edge listed first. Blazed gratings can be identified by the low value of the first-listed angle. +# +# +# +# +# +# List of polynomial coefficients describing the spatial separation of lines/grooves as a function of position along the grating, in increasing powers of position. Gratings which do not have variable line spacing will only have a single coefficient (constant). +# +# +# +# +# +# +# Angle between the incident beam and the utilised outgoing beam. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# An array describing the thickness of each layer +# +# +# A NXshape group describing the shape of the mirror +# +# +# Numerical description of the surface figure of the mirror. +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a bending grating. +# +# +# +# +# +# "Engineering" position of the grating +# Transformations used by this component to define its position and orientation. +# +# +# diff --git a/base_classes/nyaml/NXguide.yaml b/base_classes/nyaml/NXguide.yaml index bd12a29c7c..7ed8ef8f77 100644 --- a/base_classes/nyaml/NXguide.yaml +++ b/base_classes/nyaml/NXguide.yaml @@ -1,8 +1,8 @@ category: base -doc: | +doc: | A neutron optical element to direct the path of the beam. - ':'ref':'`NXguide` is used by neutron instruments to describe + :ref:`NXguide` is used by neutron instruments to describe a guide consists of several mirrors building a shape through which neutrons can be guided or directed. The simplest such form is box shaped although elliptical guides are gaining in popularity. @@ -12,43 +12,41 @@ doc: | a supermirror bender with multiple, coated vanes. To describe polarizing supermirrors such as used in neutron reflection, - it may be necessary to revise this definition of ':'ref':'`NXguide` - to include ':'ref':'`NXpolarizer` and/or ':'ref':'`NXmirror`. + it may be necessary to revise this definition of :ref:`NXguide` + to include :ref:`NXpolarizer` and/or :ref:`NXmirror`. When even greater complexity exists in the definition of what - constitutes a *guide*, it has been suggested that ':'ref':'`NXguide` - be redefined as a ':'ref':'`NXcollection` of ':'ref':'`NXmirror` each - having their own ':'ref':'`NXgeometry` describing their location(s). + constitutes a *guide*, it has been suggested that :ref:`NXguide` + be redefined as a :ref:`NXcollection` of :ref:`NXmirror` each + having their own :ref:`NXgeometry` describing their location(s). For the more general case when describing mirrors, consider using - ':'ref':'`NXmirror`. + :ref:`NXmirror`. - NOTE':' The NeXus International Advisory Committee welcomes + NOTE: The NeXus International Advisory Committee welcomes comments for revision and improvement of - this definition of ':'ref':'`NXguide`. - -symbols: - nsurf: | + this definition of :ref:`NXguide`. +symbols: + nsurf: | number of reflecting surfaces - - nwl: | + nwl: | number of wavelengths - type: group NXguide(NXobject): (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the guid and NXoff_geometry to describe its shape instead - doc: | - TODO':' Explain what this NXgeometry group means. What is intended here? + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the guid and NXoff_geometry to describe its shape instead + doc: | + TODO: Explain what this NXgeometry group means. What is intended here? description: - doc: | + doc: | A description of this particular instance of ``NXguide``. incident_angle(NX_FLOAT): unit: NX_ANGLE - doc: | - TODO':' documentation needed + doc: | + TODO: documentation needed (NXdata)reflectivity: - doc: | + doc: | Reflectivity as function of reflecting surface and wavelength \@signal: enumeration: [data] @@ -59,14 +57,16 @@ NXguide(NXobject): \@wavelength_indices: enumeration: [1] data(NX_NUMBER): - doc: | + doc: | reflectivity of each surface as a function of wavelength dimensions: rank: 2 + + # was [nsurf,i] dim: [[1, nsurf], [2, nwl]] surface(NX_NUMBER): unit: NX_ANY - doc: | + doc: | List of surfaces. Probably best to use index numbers but the specification is very loose. dimensions: @@ -74,87 +74,93 @@ NXguide(NXobject): dim: [[1, nsurf]] wavelength(NX_NUMBER): unit: NX_WAVELENGTH - doc: | + doc: | wavelengths at which reflectivity was measured dimensions: rank: 1 dim: [[1, nwl]] bend_angle_x(NX_FLOAT): unit: NX_ANGLE - doc: | - TODO':' documentation needed + doc: | + TODO: documentation needed bend_angle_y(NX_FLOAT): unit: NX_ANGLE - doc: | - TODO':' documentation needed + doc: | + TODO: documentation needed interior_atmosphere: - doc: | + doc: | + + # TODO enumeration: [vacuum, helium, argon] external_material: - doc: | + doc: | external material outside substrate m_value(NX_FLOAT): - doc: | + doc: | The ``m`` value for a supermirror, which defines the supermirror regime in multiples of the critical angle of Nickel. dimensions: rank: 1 dim: [[1, nsurf]] substrate_material(NX_FLOAT): - doc: | - TODO':' documentation needed + doc: | + TODO: documentation needed + + # Why is this field a "float"? dimensions: rank: 1 dim: [[1, nsurf]] substrate_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | - TODO':' documentation needed + doc: | + TODO: documentation needed dimensions: rank: 1 dim: [[1, nsurf]] coating_material(NX_FLOAT): - doc: | - TODO':' documentation needed + doc: | + TODO: documentation needed + + # Why is this field a "float"? dimensions: rank: 1 dim: [[1, nsurf]] substrate_roughness(NX_FLOAT): unit: NX_LENGTH - doc: | - TODO':' documentation needed + doc: | + TODO: documentation needed dimensions: rank: 1 dim: [[1, nsurf]] coating_roughness(NX_FLOAT): unit: NX_LENGTH - doc: | - TODO':' documentation needed + doc: | + TODO: documentation needed dimensions: rank: 1 dim: [[1, nsurf]] number_sections(NX_INT): unit: NX_UNITLESS - doc: | + doc: | number of substrate sections (also called ``nsurf`` as an index in the ``NXguide`` specification) (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -167,11 +173,244 @@ NXguide(NXobject): reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends in the positive direction of the z axis. - .. image':'':' guide/guide.png - ':'width':' 40% + .. image:: guide/guide.png + :width: 40% (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 54953e1fdecb5ebcd9c9e2d1ba411b0f612566299eeaa35de397e38634ab8dfe +# +# +# +# +# +# +# number of reflecting surfaces +# number of wavelengths +# +# +# +# A neutron optical element to direct the path of the beam. +# +# :ref:`NXguide` is used by neutron instruments to describe +# a guide consists of several mirrors building a shape through which +# neutrons can be guided or directed. The simplest such form is box shaped +# although elliptical guides are gaining in popularity. +# The individual parts of a guide usually have common characteristics +# but there are cases where they are different. +# For example, a neutron guide might consist of 2 or 4 coated walls or +# a supermirror bender with multiple, coated vanes. +# +# To describe polarizing supermirrors such as used in neutron reflection, +# it may be necessary to revise this definition of :ref:`NXguide` +# to include :ref:`NXpolarizer` and/or :ref:`NXmirror`. +# +# When even greater complexity exists in the definition of what +# constitutes a *guide*, it has been suggested that :ref:`NXguide` +# be redefined as a :ref:`NXcollection` of :ref:`NXmirror` each +# having their own :ref:`NXgeometry` describing their location(s). +# +# For the more general case when describing mirrors, consider using +# :ref:`NXmirror`. +# +# NOTE: The NeXus International Advisory Committee welcomes +# comments for revision and improvement of +# this definition of :ref:`NXguide`. +# +# +# +# +# TODO: Explain what this NXgeometry group means. What is intended here? +# +# +# A description of this particular instance of ``NXguide``. +# +# +# TODO: documentation needed +# +# +# Reflectivity as function of reflecting surface and wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# reflectivity of each surface as a function of wavelength +# +# +# +# +# +# +# +# List of surfaces. Probably best to use index +# numbers but the specification is very loose. +# +# +# +# +# +# +# wavelengths at which reflectivity was measured +# +# +# +# +# +# +# TODO: documentation needed +# +# +# TODO: documentation needed +# +# +# +# +# +# +# +# +# +# +# external material outside substrate +# +# +# +# The ``m`` value for a supermirror, which defines the supermirror +# regime in multiples of the critical angle of Nickel. +# +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# +# number of substrate sections (also called ``nsurf`` as an +# index in the ``NXguide`` specification) +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The entry opening of the guide lies on the reference plane. The center of the opening on that plane is +# the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the +# reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends +# in the positive direction of the z axis. +# +# .. image:: guide/guide.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXinsertion_device.yaml b/base_classes/nyaml/NXinsertion_device.yaml index 7e8a0439f8..cae0fdc3e4 100644 --- a/base_classes/nyaml/NXinsertion_device.yaml +++ b/base_classes/nyaml/NXinsertion_device.yaml @@ -1,75 +1,77 @@ category: base -doc: | +doc: | An insertion device, as used in a synchrotron light source. - type: group NXinsertion_device(NXobject): type: enumeration: [undulator, wiggler] gap(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | separation between opposing pairs of magnetic poles taper(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | angular of gap difference between upstream and downstream ends of the insertion device phase(NX_FLOAT): unit: NX_ANGLE poles(NX_INT): unit: NX_UNITLESS - doc: | + doc: | number of poles magnetic_wavelength(NX_FLOAT): unit: NX_WAVELENGTH k(NX_FLOAT): unit: NX_DIMENSIONLESS - doc: | + doc: | beam displacement parameter length(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | length of insertion device power(NX_FLOAT): unit: NX_POWER - doc: | + doc: | total power delivered by insertion device energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | energy of peak intensity in output spectrum bandwidth(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | bandwidth of peak energy + + # What are the best units here? harmonic(NX_INT): unit: NX_UNITLESS - doc: | + doc: | harmonic number of peak (NXdata)spectrum: - doc: | + doc: | spectrum of insertion device (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the device and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the device and NXoff_geometry to describe its shape instead + doc: | "Engineering" position of insertion device (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -77,11 +79,125 @@ NXinsertion_device(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a insertion device. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5bf36d34ba4e5355cac4118269f029b8f11ecbfacb3f78c3e6947dd7b394c752 +# +# +# +# +# An insertion device, as used in a synchrotron light source. +# +# +# +# +# +# +# +# separation between opposing pairs of magnetic poles +# +# +# angular of gap difference between upstream and downstream ends of the insertion device +# +# +# +# number of poles +# +# +# +# beam displacement parameter +# +# +# length of insertion device +# +# +# total power delivered by insertion device +# +# +# energy of peak intensity in output spectrum +# +# +# bandwidth of peak energy +# +# +# harmonic number of peak +# +# +# spectrum of insertion device +# +# +# "Engineering" position of insertion device +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a insertion device. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXlog.yaml b/base_classes/nyaml/NXlog.yaml index 6848474dd7..edd2d7a50a 100644 --- a/base_classes/nyaml/NXlog.yaml +++ b/base_classes/nyaml/NXlog.yaml @@ -1,9 +1,9 @@ category: base -doc: | +doc: | Information recorded as a function of time. Description of information that is recorded against - time. There are two common use cases for this':' + time. There are two common use cases for this: - When logging data such as temperature during a run - When data is taken in streaming mode data acquisition, @@ -20,8 +20,8 @@ doc: | This method of storing logged data helps to distinguish instances in which a variable is a dimension scale of the data, in which case it is stored - in an ':'ref':'`NXdata` group, and instances in which it is logged during the - run, when it should be stored in an ':'ref':'`NXlog` group. + in an :ref:`NXdata` group, and instances in which it is logged during the + run, when it should be stored in an :ref:`NXlog` group. In order to make random access to timestamped data faster there is an optional array pair of ``cue_timestamp_zero`` and ``cue_index``. The ``cue_timestamp_zero`` will @@ -29,16 +29,15 @@ doc: | every five minutes. The ``cue_index`` will then contain the index into the time,value pair of arrays for that coarser ``cue_timestamp_zero``. - type: group NXlog(NXobject): time(NX_NUMBER): unit: NX_TIME - doc: | + doc: | Time of logged entry. The times are relative to the "start" attribute and in the units specified in the "units" attribute. Please note that absolute - timestamps under unix are relative to ``1970-01-01T00':'00':'00.0Z``. + timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. The scaling_factor, when present, has to be applied to the time values in order to arrive at the units specified in the units attribute. The scaling_factor allows @@ -49,7 +48,7 @@ NXlog(NXobject): type: NX_NUMBER value(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Array of logged value, such as temperature. If this is a single value the dimensionality is nEntries. However, NXlog can also be used to store @@ -57,55 +56,197 @@ NXlog(NXobject): this example the dimensionality of values would be value[nEntries,xdim,ydim]. raw_value(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Array of raw information, such as thermocouple voltage description: - doc: | + doc: | Description of logged value average_value(NX_FLOAT): unit: NX_ANY average_value_error(NX_FLOAT): unit: NX_ANY - deprecated: see':' https':'//github.com/nexusformat/definitions/issues/639 - doc: | - estimated uncertainty (often used':' standard deviation) of average_value + deprecated: + see: https://github.com/nexusformat/definitions/issues/639 + doc: | + estimated uncertainty (often used: standard deviation) of average_value average_value_errors(NX_FLOAT): unit: NX_ANY - doc: | - estimated uncertainty (often used':' standard deviation) of average_value + doc: | + estimated uncertainty (often used: standard deviation) of average_value minimum_value(NX_FLOAT): unit: NX_ANY maximum_value(NX_FLOAT): unit: NX_ANY duration(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Total time log was taken cue_timestamp_zero(NX_NUMBER): unit: NX_TIME - doc: | + doc: | Timestamps matching the corresponding cue_index into the time, value pair. \@start: type: NX_DATE_TIME - doc: | + doc: | If missing start is assumed to be the same as for "time". \@scaling_factor: type: NX_NUMBER - doc: | + doc: | If missing start is assumed to be the same as for "time". cue_index(NX_INT): - doc: | + doc: | Index into the time, value pair matching the corresponding cue_timestamp_zero. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cd1583ea481a281c985c4ad5d3993f01d8795c3f51242392bad25bb15319b3a7 +# +# +# +# +# +# Information recorded as a function of time. +# +# Description of information that is recorded against +# time. There are two common use cases for this: +# +# - When logging data such as temperature during a run +# - When data is taken in streaming mode data acquisition, +# i.e. just timestamp, value pairs are stored and +# correlated later in data reduction with other data, +# +# +# In both cases, NXlog contains +# the logged or streamed values and the times at which they were measured as elapsed time since a starting +# time recorded in ISO8601 format. The time units are +# specified in the units attribute. An optional scaling attribute +# can be used to accomodate non standard clocks. +# +# +# This method of storing logged data helps to distinguish +# instances in which a variable is a dimension scale of the data, in which case it is stored +# in an :ref:`NXdata` group, and instances in which it is logged during the +# run, when it should be stored in an :ref:`NXlog` group. +# +# In order to make random access to timestamped data faster there is an optional array pair of +# ``cue_timestamp_zero`` and ``cue_index``. The ``cue_timestamp_zero`` will +# contain coarser timestamps than in the time array, say +# every five minutes. The ``cue_index`` will then contain the +# index into the time,value pair of arrays for that +# coarser ``cue_timestamp_zero``. +# +# +# +# +# Time of logged entry. The times are relative to the "start" attribute +# and in the units specified in the "units" +# attribute. Please note that absolute +# timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. +# +# The scaling_factor, when present, has to be applied to the time values in order +# to arrive at the units specified in the units attribute. The scaling_factor allows +# for arbitrary time units such as ticks of some hardware clock. +# +# +# +# +# +# +# Array of logged value, such as temperature. If this is +# a single value the dimensionality is +# nEntries. However, NXlog can also be used to store +# multi dimensional time stamped data such as images. In +# this example the dimensionality of values would be value[nEntries,xdim,ydim]. +# +# +# +# Array of raw information, such as thermocouple voltage +# +# +# Description of logged value +# +# +# +# estimated uncertainty (often used: standard deviation) of average_value +# +# +# estimated uncertainty (often used: standard deviation) of average_value +# +# +# +# +# Total time log was taken +# +# +# +# Timestamps matching the corresponding cue_index into the +# time, value pair. +# +# +# If missing start is assumed to be the same as for "time". +# +# +# If missing start is assumed to be the same as for "time". +# +# +# +# +# Index into the time, value pair matching the corresponding +# cue_timestamp_zero. +# +# +# +# +# .. 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/nyaml/NXmirror.yaml b/base_classes/nyaml/NXmirror.yaml index 1901e760c8..d225a05670 100644 --- a/base_classes/nyaml/NXmirror.yaml +++ b/base_classes/nyaml/NXmirror.yaml @@ -1,99 +1,108 @@ category: base -doc: | +doc: | A beamline mirror or supermirror. - type: group NXmirror(NXobject): (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the mirror and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the mirror and NXoff_geometry to describe its shape instead + doc: | + + # TODO explain what this group means type: enumeration: single: - doc: | + doc: | mirror with a single material as a reflecting surface multi: - doc: | + doc: | mirror with stacked, multiple layers as a reflecting surface description: - doc: | + doc: | description of this mirror incident_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | (NXdata)reflectivity: - doc: | + + # TODO Trac ticket #45 applies here. + # https://github.com/nexusformat/definitions/issues/45 + # TODO Solution of ticket #41 will apply here, as well. + # https://github.com/nexusformat/definitions/issues/41 + doc: | Reflectivity as function of wavelength + + # TODO need more documentation throughout bend_angle_x(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | bend_angle_y(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | interior_atmosphere: enumeration: [vacuum, helium, argon] external_material: - doc: | + doc: | external material outside substrate m_value(NX_FLOAT): unit: NX_UNITLESS - doc: | + doc: | The m value for a supermirror, which defines the supermirror regime in multiples of the critical angle of Nickel. substrate_material: - doc: | + doc: | substrate_density(NX_FLOAT): unit: NX_MASS_DENSITY - doc: | + doc: | substrate_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | coating_material: - doc: | + doc: | substrate_roughness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | coating_roughness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | even_layer_material: - doc: | + doc: | even_layer_density(NX_FLOAT): unit: NX_MASS_DENSITY - doc: | + doc: | odd_layer_material: - doc: | + doc: | odd_layer_density(NX_FLOAT): unit: NX_MASS_DENSITY - doc: | + doc: | layer_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | An array describing the thickness of each layer (NXshape)shape: deprecated: Use NXoff_geometry instead - doc: | + doc: | A NXshape group describing the shape of the mirror figure_data(NXdata): - doc: | + doc: | Numerical description of the surface figure of the mirror. (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -105,11 +114,233 @@ NXmirror(NXobject): point of the mirror in the x and y axis is the centre of the mirror on that plane. The reference plane is orthogonal to the z axis and the location of this plane is the reference point on the z axis. The mirror faces negative z values. - .. image':'':' mirror/mirror.png - ':'width':' 40% + .. image:: mirror/mirror.png + :width: 40% (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + + # TODO need more parameters here, such as ... + # list from Rainer Gehrke, DESY (some items may already be present) + # Parameters for mirrors + # Field indicating whether simple or multilayer + # Substrate element or compound + # Substrate density + # In case of multilayer: Even layer material (element or compound) + # Even layer density + # Odd layer material (element or compound) + # Odd layer density + # Number of layer pairs + # Layer thickness (array) + # Figure for crystals and mirrors (to describe curved surfaces) + # Field indicating whether concave or convex + # Field indicating whether cylindrical or not + # If cylindrical: cylinder orientation angle + # Now come the different surface figures with the necessary parameters: + # 1. Flat + # 2. Spherical (spherical radius) + # 3. Elliptical and hyperbolical (semi-major axis, semi-minor axis, angle of major axis and pole) + # 4. Toroidal (major radius, minor radius) + # 5. Parabolical (parabolic parameter a) + # 6. Conical (cone half aperture) + # 7. Polynomial (degree of polynom, array with polynom coefficients) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c83b5e3abca450466bb61a361babf63d4e730ab6116b2c76d404d217eee35a16 +# +# +# +# +# A beamline mirror or supermirror. +# +# +# +# +# +# +# mirror with a single material as a reflecting surface +# mirror with stacked, multiple layers as a reflecting surface +# +# +# +# description of this mirror +# +# +# +# +# +# +# Reflectivity as function of wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# external material outside substrate +# +# +# +# The m value for a supermirror, which defines the supermirror +# regime in multiples of the critical angle of Nickel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# An array describing the thickness of each layer +# +# +# A NXshape group describing the shape of the mirror +# +# +# Numerical description of the surface figure of the mirror. +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# Given a flat mirror, the reference plane is the plane which contains the "entry" surface of the mirror. The reference +# point of the mirror in the x and y axis is the centre of the mirror on that plane. The reference plane is orthogonal +# to the z axis and the location of this plane is the reference point on the z axis. The mirror faces negative z values. +# +# .. image:: mirror/mirror.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXmoderator.yaml b/base_classes/nyaml/NXmoderator.yaml index d58bfc5386..b31e964194 100644 --- a/base_classes/nyaml/NXmoderator.yaml +++ b/base_classes/nyaml/NXmoderator.yaml @@ -1,16 +1,16 @@ category: base -doc: | +doc: | A neutron moderator - type: group NXmoderator(NXobject): (NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the moderator and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the moderator and NXoff_geometry to describe its shape instead + doc: | "Engineering" position of moderator distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Effective distance as seen by measuring radiation. Note, it is recommended to use NXtransformations instead. type: @@ -18,40 +18,40 @@ NXmoderator(NXobject): poison_depth(NX_FLOAT): unit: NX_LENGTH coupled(NX_BOOLEAN): - doc: | + doc: | whether the moderator is coupled coupling_material: - doc: | + doc: | The material used for coupling. Usually Cd. poison_material: enumeration: [Gd, Cd] temperature(NX_FLOAT): unit: NX_TEMPERATURE - doc: | + doc: | average/nominal moderator temperature (NXlog)temperature_log: - doc: | + doc: | log file of moderator temperature (NXdata)pulse_shape: - doc: | + doc: | moderator pulse shape (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the moderator \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -62,11 +62,132 @@ NXmoderator(NXobject): The reference point of the moderator is its center in the x and y axis. The reference point on the z axis is the surface of the moderator pointing towards the source (the negative part of the z axis). - .. image':'':' moderator/moderator.png - ':'width':' 40% + .. image:: moderator/moderator.png + :width: 40% (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f85a14caae0d07b3c5be162107a20cdcc3348974facbd9458418eb0d9af986b9 +# +# +# +# +# A neutron moderator +# +# "Engineering" position of moderator +# +# +# +# Effective distance as seen by measuring radiation. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# whether the moderator is coupled +# +# +# The material used for coupling. Usually Cd. +# +# +# +# +# +# +# +# +# average/nominal moderator temperature +# +# +# log file of moderator temperature +# +# +# moderator pulse shape +# +# +# +# This group describes the shape of the moderator +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the moderator is its center in the x and y axis. The reference point on the z axis is the +# surface of the moderator pointing towards the source (the negative part of the z axis). +# +# .. image:: moderator/moderator.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXmonitor.yaml b/base_classes/nyaml/NXmonitor.yaml index ca625ffa6a..7012e09735 100644 --- a/base_classes/nyaml/NXmonitor.yaml +++ b/base_classes/nyaml/NXmonitor.yaml @@ -1,57 +1,56 @@ category: base -doc: | +doc: | A monitor of incident beam data. - It is similar to the ':'ref':'`NXdata` groups containing + It is similar to the :ref:`NXdata` groups containing monitor data and its associated dimension scale, e.g. time_of_flight or wavelength in pulsed neutron instruments. However, it may also include integrals, or scalar monitor counts, which are often used in both in both pulsed and steady-state instrumentation. - type: group NXmonitor(NXobject): mode: - doc: | + doc: | Count to a preset value based on either clock time (timer) or received monitor counts (monitor). enumeration: [monitor, timer] start_time(NX_DATE_TIME): - doc: | + doc: | Starting time of measurement end_time(NX_DATE_TIME): - doc: | + doc: | Ending time of measurement preset(NX_NUMBER): unit: NX_ANY - doc: | + doc: | preset value for time or monitor distance(NX_FLOAT): unit: NX_LENGTH deprecated: Use transformations/distance instead - doc: | + doc: | Distance of monitor from sample range(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Range (X-axis, Time-of-flight, etc.) over which the integral was calculated dimensions: dim: [[1, 2]] nominal(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Nominal reading to be used for normalisation purposes. integral(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Total integral monitor counts integral_log(NXlog): - doc: | + doc: | Time variation of monitor counts type: enumeration: [Fission Chamber, Scintillator] time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT - doc: | + doc: | Time-of-flight dimensions: dim: [[1, ]] @@ -59,7 +58,7 @@ NXmonitor(NXobject): ref: ['efficiency'] efficiency(NX_NUMBER): unit: NX_DIMENSIONLESS - doc: | + doc: | Monitor efficiency dimensions: dim: [[1, ]] @@ -67,47 +66,48 @@ NXmonitor(NXobject): ref: ['i'] data(NX_NUMBER): unit: NX_ANY - doc: | + doc: | Monitor data dimensions: rank: dataRank - doc: | + doc: | The rank (``dataRank``) of the ``data`` must satisfy ``1 <= dataRank <= NX_MAXRANK=32``. At least one ``dim`` must have length ``n``. dim: [] sampled_fraction(NX_FLOAT): unit: NX_DIMENSIONLESS - doc: | + doc: | Proportion of incident beam sampled by the monitor (0 +# +# +# +# +# A monitor of incident beam data. +# +# It is similar to the :ref:`NXdata` groups containing +# monitor data and its associated dimension scale, e.g. time_of_flight or +# wavelength in pulsed neutron instruments. However, it may also include +# integrals, or scalar monitor counts, which are often used in both in both +# pulsed and steady-state instrumentation. +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# Starting time of measurement +# +# +# Ending time of measurement +# +# +# preset value for time or monitor +# +# +# Distance of monitor from sample +# +# +# Range (X-axis, Time-of-flight, etc.) over which the integral was calculated +# +# +# +# Nominal reading to be used for normalisation purposes. +# +# +# Total integral monitor counts +# +# +# Time variation of monitor counts +# +# +# +# +# +# +# +# +# Time-of-flight +# +# +# +# +# +# Monitor efficiency +# +# +# +# +# Monitor data +# +# +# +# The rank (``dataRank``) of the ``data`` must satisfy +# ``1 <= dataRank <= NX_MAXRANK=32``. +# At least one ``dim`` must have length ``n``. +# +# +# +# +# Proportion of incident beam sampled by the monitor (0<x<1) +# +# +# Geometry of the monitor +# +# +# +# Elapsed actual counting time, can be an array of size ``np`` +# when scanning. This is not the difference of the calendar time +# but the time the instrument was really counting, without +# pauses or times lost due beam unavailability +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference plane of the monitor contains the surface of the detector that faces the source +# and is the entry point of the beam. The reference point of the monitor in the x and y axis is +# its centre on this surface. The reference plane is orthogonal to the the z axis and the +# reference point on this z axis is where they intersect. +# +# .. image:: monitor/monitor.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXmonochromator.yaml b/base_classes/nyaml/NXmonochromator.yaml index 58f84a90c5..4a3015db69 100644 --- a/base_classes/nyaml/NXmonochromator.yaml +++ b/base_classes/nyaml/NXmonochromator.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | A wavelength defining device. This is a base class for everything which @@ -7,66 +7,68 @@ doc: | monochromator crystal, a velocity selector, an undulator or whatever. - The expected units are':' + The expected units are: - * wavelength':' angstrom - * energy':' eV - + * wavelength: angstrom + * energy: eV type: group NXmonochromator(NXobject): wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | wavelength selected wavelength_error(NX_FLOAT): unit: NX_WAVELENGTH - deprecated: see https':'//github.com/nexusformat/definitions/issues/820 - doc: | + deprecated: + see https://github.com/nexusformat/definitions/issues/820 + doc: | wavelength standard deviation wavelength_errors(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | wavelength standard deviation energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | energy selected energy_error(NX_FLOAT): unit: NX_ENERGY - deprecated: see https':'//github.com/nexusformat/definitions/issues/820 - doc: | + deprecated: + see https://github.com/nexusformat/definitions/issues/820 + doc: | energy standard deviation energy_errors(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | energy standard deviation (NXdata)distribution: (NXgeometry)geometry: - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the monochromator and NXoff_geometry to describe its shape instead + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the monochromator and NXoff_geometry to describe its shape instead (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component (NXcrystal): - doc: | + doc: | Use as many crystals as necessary to describe (NXvelocity_selector): (NXgrating): - doc: | + doc: | For diffraction grating based monochromators \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -74,11 +76,122 @@ NXmonochromator(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a monochromator. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 91cfc4f0c4c8a300d58a88a2194cb4b98e229bb849f4904aa264c96fe6894e16 +# +# +# +# +# +# A wavelength defining device. +# +# This is a base class for everything which +# selects a wavelength or energy, be it a +# monochromator crystal, a velocity selector, +# an undulator or whatever. +# +# The expected units are: +# +# * wavelength: angstrom +# * energy: eV +# +# +# +# wavelength selected +# +# +# wavelength standard deviation +# +# +# wavelength standard deviation +# +# +# energy selected +# +# +# energy standard deviation +# +# +# energy standard deviation +# +# +# +# +# +# This group describes the shape of the beam line component +# +# +# Use as many crystals as necessary to describe +# +# For diffraction grating based monochromators +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a monochromator. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXnote.yaml b/base_classes/nyaml/NXnote.yaml index eb2bcaa247..229f0c82b0 100644 --- a/base_classes/nyaml/NXnote.yaml +++ b/base_classes/nyaml/NXnote.yaml @@ -1,42 +1,116 @@ category: base -doc: | +doc: | Any additional freeform information not covered by the other base classes. This class can be used to store additional information in a NeXus file e.g. pictures, movies, audio, additional text logs - type: group NXnote(NXobject): author: - doc: | + doc: | Author or creator of note date(NX_DATE_TIME): - doc: | + doc: | Date note created/added type: - doc: | + doc: | Mime content type of note data field e.g. image/jpeg, text/plain, text/html file_name: - doc: | + doc: | Name of original file name if note was read from an external source description: - doc: | + doc: | Title of an image or other details of the note sequence_index(NX_POSINT): - doc: | + doc: | Sequence index of note, for placing a sequence of multiple **NXnote** groups in an order. Starts with 1. data(NX_BINARY): - doc: | + doc: | Binary note data - if text, line terminator is [CR][LF]. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cac46891aabdb595f69910c7ddb6a496bd16f4e98055ddc5570ef01fbeed1e73 +# +# +# +# +# +# Any additional freeform information not covered by the other base classes. +# +# This class can be used to store additional information in a +# NeXus file e.g. pictures, movies, audio, additional text logs +# +# +# Author or creator of note +# +# +# Date note created/added +# +# +# Mime content type of note data field e.g. image/jpeg, text/plain, text/html +# +# +# Name of original file name if note was read from an external source +# +# +# Title of an image or other details of the note +# +# +# +# Sequence index of note, for placing a sequence of +# multiple **NXnote** groups in an order. Starts with 1. +# +# +# +# Binary note data - if text, line terminator is [CR][LF]. +# +# +# +# .. 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/nyaml/NXobject.yaml b/base_classes/nyaml/NXobject.yaml index d9f2bbb4d4..cbf07862fb 100644 --- a/base_classes/nyaml/NXobject.yaml +++ b/base_classes/nyaml/NXobject.yaml @@ -1,6 +1,44 @@ category: base -doc: | +doc: | This is the base object of NeXus - type: group NXobject: + + # attribute name="name">name of instance +# +# +# +# +# This is the base object of NeXus +# +# +# +# diff --git a/base_classes/nyaml/NXoff_geometry.yaml b/base_classes/nyaml/NXoff_geometry.yaml index 5b9dd6aa2b..abc3de7ede 100644 --- a/base_classes/nyaml/NXoff_geometry.yaml +++ b/base_classes/nyaml/NXoff_geometry.yaml @@ -1,31 +1,26 @@ category: base -doc: | +doc: | Geometry (shape) description. The format closely matches the Object File Format (OFF) which can be output by most CAD software. It can be used to describe the shape of any beamline component, including detectors. In the case of detectors it can be used to define the shape of a single pixel, or, if the pixel shapes are non-uniform, to describe the shape of the whole detector. - -symbols: - doc: | +symbols: + doc: | These symbols will be used below. - - i: | + i: | number of vertices in the shape - - k: | + k: | number of faces in the shape - - l: | + l: | number faces which are detecting surfaces or form the boundary of detecting volumes - type: group NXoff_geometry(NXobject): vertices(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | List of x,y,z coordinates for vertices. The origin of the coordinates is the position of the parent component, for example the NXdetector which the geometry describes. @@ -36,20 +31,20 @@ NXoff_geometry(NXobject): rank: 2 dim: [[1, i], [2, 3]] winding_order(NX_INT): - doc: | + doc: | List of indices of vertices in the ``vertices`` dataset to form each face, right-hand rule for face normal. dimensions: rank: 1 dim: [[1, j]] faces(NX_INT): - doc: | + doc: | The start index in ``winding_order`` for each face. dimensions: rank: 1 dim: [[1, k]] detector_faces(NX_INT): - doc: | + doc: | List of pairs of index in the "faces" dataset and detector id. Face IDs in the first column, and corresponding detector IDs in the second column. This dataset should only be used only if the ``NXoff_geometry`` group is @@ -62,13 +57,141 @@ NXoff_geometry(NXobject): rank: 2 dim: [[1, l], [2, 2]] \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 593884a075055d155060d7a8bb7a8d3b3164efcad905aed084064fc4ae052ead +# +# +# +# +# +# +# These symbols will be used below. +# number of vertices in the shape +# number of faces in the shape +# +# +# number faces which are detecting surfaces or form the boundary of +# detecting volumes +# +# +# +# +# +# Geometry (shape) description. +# The format closely matches the Object File Format (OFF) which can be output +# by most CAD software. +# It can be used to describe the shape of any beamline component, including detectors. +# In the case of detectors it can be used to define the shape of a single pixel, or, +# if the pixel shapes are non-uniform, to describe the shape of the whole detector. +# +# +# +# +# +# List of x,y,z coordinates for vertices. +# The origin of the coordinates is the position of the parent component, for +# example the NXdetector which the geometry describes. +# If the shape describes a single pixel for a detector with uniform pixel +# shape then the origin is the position of each pixel as described by the +# ``x/y/z_pixel_offset`` datasets in ``NXdetector``. +# +# +# +# +# +# +# +# +# +# +# +# +# List of indices of vertices in the ``vertices`` dataset to form each face, +# right-hand rule for face normal. +# +# +# +# +# +# +# +# +# +# +# The start index in ``winding_order`` for each face. +# +# +# +# +# +# +# +# +# +# +# List of pairs of index in the "faces" dataset and detector id. Face IDs in +# the first column, and corresponding detector IDs in the second column. +# This dataset should only be used only if the ``NXoff_geometry`` group is +# describing a detector. +# Note, the face indices must be in ascending order but need not be +# consecutive as not every face in faces need be a detecting surface or +# boundary of detecting volume. +# Can use multiple entries with the same detector id to define detector volumes. +# +# +# +# +# +# +# +# +# +# +# .. 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/nyaml/NXorientation.yaml b/base_classes/nyaml/NXorientation.yaml index 9895b3be13..04a28a40cb 100644 --- a/base_classes/nyaml/NXorientation.yaml +++ b/base_classes/nyaml/NXorientation.yaml @@ -1,17 +1,16 @@ category: base -doc: | - legacy class - recommend to use ':'ref':'`NXtransformations` now +doc: | + legacy class - recommend to use :ref:`NXtransformations` now - Description for a general orientation of a component - used by ':'ref':'`NXgeometry` - + Description for a general orientation of a component - used by :ref:`NXgeometry` type: group NXorientation(NXobject): (NXgeometry): - doc: | + doc: | Link to another object if we are using relative positioning, else absent value(NX_FLOAT): unit: NX_UNITLESS - doc: | + doc: | The orientation information is stored as direction cosines. The direction cosines will be between the local coordinate directions and the reference directions (to origin or relative NXgeometry). Calling the local unit vectors (x',y',z') and the reference unit @@ -23,15 +22,90 @@ NXorientation(NXobject): The pair of groups NXtranslation and NXorientation together describe the position of a component. dimensions: + + # numobj,6 dim: [[1, numobj], [2, 6]] \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b837027cfb5d13fbee2db64988ee3af2d8ea788d712eaf5455b1eba597023f42 +# +# +# +# +# +# legacy class - recommend to use :ref:`NXtransformations` now +# +# Description for a general orientation of a component - used by :ref:`NXgeometry` +# +# +# Link to another object if we are using relative positioning, else absent +# +# +# +# The orientation information is stored as direction cosines. The direction cosines will +# be between the local coordinate directions and the reference directions (to origin or +# relative NXgeometry). Calling the local unit vectors (x',y',z') and the reference unit +# vectors (x,y,z) the six numbers will be [x' dot x, x' dot y, x' dot z, y' dot x, y' dot +# y, y' dot z] where "dot" is the scalar dot product (cosine of the angle between the unit +# vectors). The unit vectors in both the local and reference coordinates are right-handed +# and orthonormal. +# +# The pair of groups NXtranslation and NXorientation together +# describe the position of a component. +# +# +# +# +# +# +# +# +# .. 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/nyaml/NXparameters.yaml b/base_classes/nyaml/NXparameters.yaml index 68e32f1729..e81a3b034b 100644 --- a/base_classes/nyaml/NXparameters.yaml +++ b/base_classes/nyaml/NXparameters.yaml @@ -1,22 +1,75 @@ category: base -doc: | +doc: | Container for parameters, usually used in processing or analysis. - type: group NXparameters(NXobject): term(NX_CHAR): exists: ['min', '0', 'max', 'unbounded'] - doc: | + + # maxOccurs="unbounded" is intended but is not allowed by current syntax + doc: | A parameter (also known as a term) that is used in or results from processing. \@units: \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4306876a0e67eaf3b38dfb0d8c2236908c7816908082629bdeb23948c1842a87 +# +# +# +# +# Container for parameters, usually used in processing or analysis. +# +# +# A parameter (also known as a term) that is used in or results from processing. +# +# +# +# +# .. 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/nyaml/NXpdb.yaml b/base_classes/nyaml/NXpdb.yaml index 67942ae356..24cfd73920 100644 --- a/base_classes/nyaml/NXpdb.yaml +++ b/base_classes/nyaml/NXpdb.yaml @@ -1,9 +1,16 @@ category: base -doc: | + +# The ignoreExtra* attributes are used in the definition to +# avoid warning messages that would be generated from +# unexpected groups, fields, and attributes. +# Since no groups or attributes are declared here, _every_ +# child of this class would generate a warning message without this +# attribute being set to "true". +doc: | A NeXus transliteration of a PDB file, to be validated only as a PDB rather than in NeXus. - Use ':'ref':'`NXpdb` to incorporate the information in an arbitrary + Use :ref:`NXpdb` to incorporate the information in an arbitrary PDB into a NeXus file. The main suggestion is to use this as a container @@ -38,36 +45,36 @@ doc: | but may be used to provide internal documentation. The nesting of NXpdb groups and datasets that correspond to a CIF with - two categories and one saveframe, including the NXpdb_class attribues is':'':' - - (datablock1)':'NXpdb - @NXpdb_class':'CBF_cbfdb - (category1)':'NXpdb - @NXpdb_class':'CBF_cbfcat - (column_name1)':'[...] - (column_name2)':'[...] - (column_name3)':'[...] + two categories and one saveframe, including the NXpdb_class attribues is:: + + (datablock1):NXpdb + @NXpdb_class:CBF_cbfdb + (category1):NXpdb + @NXpdb_class:CBF_cbfcat + (column_name1):[...] + (column_name2):[...] + (column_name3):[...] ... - (category2)':'NXpdb - @NXpdb_class':'CBF_cbfcat - (column_name4)':'[...] - (column_name5)':'[...] - (column_name6)':'[...] + (category2):NXpdb + @NXpdb_class:CBF_cbfcat + (column_name4):[...] + (column_name5):[...] + (column_name6):[...] ... - (saveframe1)':'NXpdb - @NXpdb_class':'CBF_cbfsf - (category3)':'NXpdb - @NXpdb_class':'CBF_cbfcat - (column_name7)':'[...] - (column_name8)':'[...] - (column_name9)':'[...] + (saveframe1):NXpdb + @NXpdb_class:CBF_cbfsf + (category3):NXpdb + @NXpdb_class:CBF_cbfcat + (column_name7):[...] + (column_name8):[...] + (column_name9):[...] ... ... ... - For example, a PDB entry that begins':'':' + For example, a PDB entry that begins:: data_1YVA # @@ -75,7 +82,7 @@ doc: | # _audit_conform.dict_name mmcif_pdbx.dic _audit_conform.dict_version 5.279 - _audit_conform.dict_location http':'//mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic + _audit_conform.dict_location http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic # loop_ _database_2.database_id @@ -85,22 +92,22 @@ doc: | WWPDB D_1000031959 # - would produce':'':' + would produce:: - sample':'NXsample - 1yva':'NXpdb - entry':'NXpdb - id':'"1YVA" - audit_conform':'NXpdb - dict_name':'"mmcif_pdbx.dic" - dict_version':'"5.279" - dict_location':'"http':'//mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic" - database_2':'NXpdb - database_id':'["PDB","RCSB","WWPDB"] - database_code':'["1YVA","RCSB031959","D_1000031959"] + sample:NXsample + 1yva:NXpdb + entry:NXpdb + id:"1YVA" + audit_conform:NXpdb + dict_name:"mmcif_pdbx.dic" + dict_version:"5.279" + dict_location:"http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic" + database_2:NXpdb + database_id:["PDB","RCSB","WWPDB"] + database_code:["1YVA","RCSB031959","D_1000031959"] another example is the following excerpt from pdb entry 9ins, giving the sequences - of the two chains':'':' + of the two chains:: loop_ _entity_poly.entity_id @@ -113,19 +120,210 @@ doc: | 2 no no FVNQHLCGSHLVEALYLVCGERGFFYTPKA FVNQHLCGSHLVEALYLVCGERGFFYTPKA polypeptide(L) - which converts to':'':' + which converts to:: - entity_poly':'NXpdb - @NXpdb_class':'CBF_cbfcat - entity_id':'["1", "2"] - nstd_linkage':'["no", "no"] - nstd_monomer':'["no", "no"] - pdbx_seq_one_letter_code':'["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] - pdbx_seq_one_letter_code_can':'["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] - type':'["polypeptide(L)", "polypeptide(L)"] - + entity_poly:NXpdb + @NXpdb_class:CBF_cbfcat + entity_id:["1", "2"] + nstd_linkage:["no", "no"] + nstd_monomer:["no", "no"] + pdbx_seq_one_letter_code:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] + pdbx_seq_one_letter_code_can:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] + type:["polypeptide(L)", "polypeptide(L)"] type: group ignoreExtraGroups: true ignoreExtraFields: true ignoreExtraAttributes: true NXpdb(NXobject): + + # NOTE + # ===== + # NXpdb is a class not validated by the NXDL tools. + # Do not add any subgroups in this nxdl file. + # See: https://github.com/nexusformat/definitions/issues/259 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a7abffb938a9848149b6d1c2b7f0e7d0f47792f36c6dc44ad9f3831a9c3c0172 +# +# +# +# +# +# +# +# +# A NeXus transliteration of a PDB file, to be validated only as a PDB +# rather than in NeXus. +# +# Use :ref:`NXpdb` to incorporate the information in an arbitrary +# PDB into a NeXus file. +# +# The main suggestion is to use this as a container +# class for a PDB entry to describe a sample in NXsample, +# but it may be more appropriate to place this higher in the +# hierarchy, say in NXentry. +# +# The structure has to follow the structure of a PDB +# with each PDB data block mapped to a NeXus group of class NXpdb, +# using a lowercase version of the data block name as the name +# of the NeXus group, each PDB category in that data block +# mapped to a NeXus group of class NXpdb and with each PDB column +# mapped to a NeXus field. Each column in a looped PDB category +# should always be presented as a 1-dimensional array. The columns +# in an unlooped PDB category should be presented as scalar values. +# If a PDB category specifies particular units for columns, the same +# units should beused for the corresponding fields. +# +# A PDB entry is unambigous when all information is carried as text. +# All text data should be presented as quoted strings, with the quote +# marks except for the null values "." or "?" +# +# For clarity in NXpdb form, numeric data may be presented using the +# numeric types specified in the mmCIF dictionary. In that case, +# if a PDB null value, "." or "?", is contained in a numeric column, the +# IEEE nan should be used for "?" and the IEEE inf should be used for ".". +# +# An arbitrary DDL2 CIF file can be represented in NeXus using NXpdb. +# However, if save frames are required, an NXpdb_class attribute with the +# value "CBF_cbfsf" is required for each NeXus group representing a save +# frame. NXpdb attributes are not required for other CIF components, +# but may be used to provide internal documentation. +# +# The nesting of NXpdb groups and datasets that correspond to a CIF with +# two categories and one saveframe, including the NXpdb_class attribues is:: +# +# (datablock1):NXpdb +# @NXpdb_class:CBF_cbfdb +# (category1):NXpdb +# @NXpdb_class:CBF_cbfcat +# (column_name1):[...] +# (column_name2):[...] +# (column_name3):[...] +# ... +# (category2):NXpdb +# @NXpdb_class:CBF_cbfcat +# (column_name4):[...] +# (column_name5):[...] +# (column_name6):[...] +# ... +# (saveframe1):NXpdb +# @NXpdb_class:CBF_cbfsf +# (category3):NXpdb +# @NXpdb_class:CBF_cbfcat +# (column_name7):[...] +# (column_name8):[...] +# (column_name9):[...] +# ... +# ... +# ... +# +# +# +# For example, a PDB entry that begins:: +# +# data_1YVA +# # +# _entry.id 1YVA +# # +# _audit_conform.dict_name mmcif_pdbx.dic +# _audit_conform.dict_version 5.279 +# _audit_conform.dict_location http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic +# # +# loop_ +# _database_2.database_id +# _database_2.database_code +# PDB 1YVA +# RCSB RCSB031959 +# WWPDB D_1000031959 +# # +# +# would produce:: +# +# sample:NXsample +# 1yva:NXpdb +# entry:NXpdb +# id:"1YVA" +# audit_conform:NXpdb +# dict_name:"mmcif_pdbx.dic" +# dict_version:"5.279" +# dict_location:"http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic" +# database_2:NXpdb +# database_id:["PDB","RCSB","WWPDB"] +# database_code:["1YVA","RCSB031959","D_1000031959"] +# +# another example is the following excerpt from pdb entry 9ins, giving the sequences +# of the two chains:: +# +# loop_ +# _entity_poly.entity_id +# _entity_poly.nstd_linkage +# _entity_poly.nstd_monomer +# _entity_poly.pdbx_seq_one_letter_code +# _entity_poly.pdbx_seq_one_letter_code_can +# _entity_poly.type +# 1 no no GIVEQCCTSICSLYQLENYCN GIVEQCCTSICSLYQLENYCN polypeptide(L) +# 2 no no FVNQHLCGSHLVEALYLVCGERGFFYTPKA FVNQHLCGSHLVEALYLVCGERGFFYTPKA +# polypeptide(L) +# +# which converts to:: +# +# entity_poly:NXpdb +# @NXpdb_class:CBF_cbfcat +# entity_id:["1", "2"] +# nstd_linkage:["no", "no"] +# nstd_monomer:["no", "no"] +# pdbx_seq_one_letter_code:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] +# pdbx_seq_one_letter_code_can:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] +# type:["polypeptide(L)", "polypeptide(L)"] +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXpinhole.yaml b/base_classes/nyaml/NXpinhole.yaml index 7b7ac34950..69fd2fe2cb 100644 --- a/base_classes/nyaml/NXpinhole.yaml +++ b/base_classes/nyaml/NXpinhole.yaml @@ -1,13 +1,12 @@ category: base -doc: | +doc: | A simple pinhole. - For more complex geometries, ':'ref':'`NXaperture` should be used. - + For more complex geometries, :ref:`NXaperture` should be used. type: group NXpinhole(NXobject): depends_on(NX_CHAR): - doc: | + doc: | Points to the path of the last element in the geometry chain that places this object in space. When followed through that chain is supposed to end at an element depending @@ -19,27 +18,108 @@ NXpinhole(NXobject): point of the pinhole is its center in the x and y axis. The reference point on the z axis is the plane which overlaps the side of the opening of the pin hole pointing towards the source (minus on the z axis). - .. image':'':' pinhole/pinhole.png - ':'width':' 40% + .. image:: pinhole/pinhole.png + :width: 40% diameter(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | Size of the circular hole defining the transmitted beam size. (NXtransformations): exists: ['min', '0'] - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c70638ef9748cfd94d36132613305136639cd062a10e8771d7e78ba4f865dd85 +# +# +# +# +# +# A simple pinhole. +# +# For more complex geometries, :ref:`NXaperture` should be used. +# +# +# +# Points to the path of the last element in the geometry chain that places +# this object in space. +# When followed through that chain is supposed to end at an element depending +# on "." i.e. the origin of the coordinate system. +# If desired the location of the slit can also be described relative to +# an NXbeam, which will allow a simple description of a non-centred pinhole. +# +# The reference direction of the pinhole is parallel with the z axis. The reference +# point of the pinhole is its center in the x and y axis. The reference point on the z axis is the +# plane which overlaps the side of the opening of the pin hole pointing towards the source (minus on the z axis). +# +# .. image:: pinhole/pinhole.png +# :width: 40% +# +# +# +# +# Size of the circular hole defining the transmitted beam size. +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# +# .. 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/nyaml/NXpolarizer.yaml b/base_classes/nyaml/NXpolarizer.yaml index eb2856da8d..0380ddb99e 100644 --- a/base_classes/nyaml/NXpolarizer.yaml +++ b/base_classes/nyaml/NXpolarizer.yaml @@ -1,38 +1,37 @@ category: base -doc: | +doc: | A spin polarizer. - type: group NXpolarizer(NXobject): type: - doc: | - one of these values':' "crystal", "supermirror", "3He" + doc: | + one of these values: "crystal", "supermirror", "3He" composition: - doc: | + doc: | description of the composition of the polarizing material reflection(NX_INT): unit: NX_UNITLESS - doc: | + doc: | [hkl] values of nominal reflection dimensions: dim: [[1, 3]] efficiency(NX_FLOAT): unit: NX_DIMENSIONLESS - doc: | + doc: | polarizing efficiency \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -40,11 +39,97 @@ NXpolarizer(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a polarizer. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 489a3377a505248d4d66e2c674c112f1eb6f8ca85c6f02fbedbe8b7ba40149d4 +# +# +# +# +# +# A spin polarizer. +# +# +# one of these values: "crystal", "supermirror", "3He" +# +# +# description of the composition of the polarizing material +# +# +# [hkl] values of nominal reflection +# +# +# +# +# +# polarizing efficiency +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a polarizer. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXpositioner.yaml b/base_classes/nyaml/NXpositioner.yaml index b2c8161ad0..36178fda4e 100644 --- a/base_classes/nyaml/NXpositioner.yaml +++ b/base_classes/nyaml/NXpositioner.yaml @@ -1,75 +1,76 @@ category: base -doc: | +doc: | A generic positioner such as a motor or piezo-electric transducer. - type: group NXpositioner(NXobject): name: - doc: | + doc: | symbolic or mnemonic name (one word) description: - doc: | + doc: | description of positioner value(NX_NUMBER): unit: NX_ANY - doc: | + doc: | best known value of positioner - need [n] as may be scanned dimensions: rank: 1 dim: [[1, n]] raw_value(NX_NUMBER): unit: NX_ANY - doc: | + doc: | raw value of positioner - need [n] as may be scanned dimensions: rank: 1 dim: [[1, n]] target_value(NX_NUMBER): unit: NX_ANY - doc: | + doc: | targeted (commanded) value of positioner - need [n] as may be scanned dimensions: rank: 1 dim: [[1, n]] tolerance(NX_NUMBER): unit: NX_ANY - doc: | + doc: | maximum allowable difference between target_value and value dimensions: rank: 1 dim: [[1, n]] soft_limit_min(NX_NUMBER): unit: NX_ANY - doc: | + doc: | minimum allowed limit to set value soft_limit_max(NX_NUMBER): unit: NX_ANY - doc: | + doc: | maximum allowed limit to set value velocity(NX_NUMBER): unit: NX_ANY - doc: | + doc: | velocity of the positioner (distance moved per unit time) acceleration_time(NX_NUMBER): unit: NX_ANY - doc: | + doc: | time to ramp the velocity up to full speed + + # TODO other parameters: settling time, backlash, link to readback channel controller_record: - doc: | + doc: | Hardware device record, e.g. EPICS process variable, taco/tango ... \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -77,11 +78,123 @@ NXpositioner(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a positioner. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9e3dc1962303ddef4d403e479bfde3b47cdd8a9fa15c57bf2fadfb6e55ff541f +# +# +# +# +# +# A generic positioner such as a motor or piezo-electric transducer. +# +# +# symbolic or mnemonic name (one word) +# +# +# description of positioner +# +# +# best known value of positioner - need [n] as may be scanned +# +# +# +# raw value of positioner - need [n] as may be scanned +# +# +# +# targeted (commanded) value of positioner - need [n] as may be scanned +# +# +# +# maximum allowable difference between target_value and value +# +# +# +# minimum allowed limit to set value +# +# +# maximum allowed limit to set value +# +# +# velocity of the positioner (distance moved per unit time) +# +# +# time to ramp the velocity up to full speed +# +# +# +# Hardware device record, e.g. EPICS process variable, taco/tango ... +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a positioner. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXprocess.yaml b/base_classes/nyaml/NXprocess.yaml index 6d7fc3a7eb..d2650c0e4c 100644 --- a/base_classes/nyaml/NXprocess.yaml +++ b/base_classes/nyaml/NXprocess.yaml @@ -1,25 +1,24 @@ category: base -doc: | +doc: | Document an event of data processing, reconstruction, or analysis for this data. - type: group NXprocess(NXobject): program(NX_CHAR): - doc: | + doc: | Name of the program used sequence_index(NX_POSINT): - doc: | + doc: | Sequence index of processing, for determining the order of multiple **NXprocess** steps. Starts with 1. version(NX_CHAR): - doc: | + doc: | Version of the program used date(NX_DATE_TIME): - doc: | + doc: | Date and time of processing. (NXnote): - doc: | + doc: | The note will contain information about how the data was processed or anything about the data provenance. The contents of the note can be anything that the processing code @@ -27,13 +26,86 @@ NXprocess(NXobject): The name will be numbered to allow for ordering of steps. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 58b609d04d449740f1f2dda2e29c406383a5c436f4f1e472a3d22fe95cfced49 +# +# +# +# +# Document an event of data processing, reconstruction, or analysis for this data. +# +# Name of the program used +# +# +# +# Sequence index of processing, +# for determining the order of multiple **NXprocess** steps. +# Starts with 1. +# +# +# +# Version of the program used +# +# +# Date and time of processing. +# +# +# +# The note will contain information about how the data was processed +# or anything about the data provenance. +# The contents of the note can be anything that the processing code +# can understand, or simple text. +# +# The name will be numbered to allow for ordering of steps. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXreflections.yaml b/base_classes/nyaml/NXreflections.yaml index bf88aa6200..83523acc75 100644 --- a/base_classes/nyaml/NXreflections.yaml +++ b/base_classes/nyaml/NXreflections.yaml @@ -1,56 +1,53 @@ category: base -doc: | +doc: | Reflection data from diffraction experiments - -symbols: - n: | +symbols: + n: | number of reflections - - m: | + m: | number of experiments - type: group NXreflections(NXobject): experiments: exists: ['min', '1'] - doc: | + doc: | The experiments from which the reflection data derives dimensions: rank: 1 dim: [[1, m]] h(NX_NUMBER): exists: ['min', '1'] - doc: | + doc: | The h component of the miller index dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset k(NX_NUMBER): exists: ['min', '1'] - doc: | + doc: | The k component of the miller index dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset l(NX_NUMBER): exists: ['min', '1'] - doc: | + doc: | The l component of the miller index dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset id(NX_INT): exists: ['min', '1'] - doc: | + doc: | The id of the experiment which resulted in the reflection. If the value is greater than 0, the experiments must link to a multi-experiment NXmx group @@ -58,46 +55,46 @@ NXreflections(NXobject): rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset reflection_id(NX_INT): exists: ['min', '1'] - doc: | + doc: | The id of the reflection. Multiple partials from the same reflection should all have the same id dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset entering(NX_BOOLEAN): exists: ['min', '1'] - doc: | + doc: | Is the reflection entering or exiting the Ewald sphere dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset det_module(NX_INT): exists: ['min', '1'] - doc: | + doc: | The detector module on which the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset flags(NX_INT): exists: ['min', '1'] - doc: | + doc: | Status flags describing the reflection. This is a bit mask. The bits in the mask follow the convention - used by DIALS, and have the following names':' + used by DIALS, and have the following names: === ========================================== bit name @@ -132,21 +129,21 @@ NXreflections(NXobject): rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset d(NX_FLOAT): exists: ['min', '1'] - doc: | + doc: | The resolution of the reflection dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset partiality(NX_FLOAT): exists: ['min', '1'] - doc: | + doc: | The partiality of the reflection. Dividing by this number will inflate the measured intensity to the full reflection equivalent. @@ -154,301 +151,301 @@ NXreflections(NXobject): rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset predicted_frame(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The frame on which the bragg peak of the reflection is predicted dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset predicted_x(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1'] - doc: | + doc: | The x position at which the bragg peak of the reflection is predicted dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset predicted_y(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1'] - doc: | + doc: | The y position at which the bragg peak of the reflection is predicted dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset predicted_phi(NX_FLOAT): unit: NX_ANGLE exists: ['min', '1'] - doc: | + doc: | The phi angle at which the bragg peak of the reflection is predicted dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset predicted_px_x(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The x pixel position at which the bragg peak of the reflection is predicted dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset predicted_px_y(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The y pixel position at which the bragg peak of the reflection is predicted dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_frame(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The estimate of the frame at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_frame_var(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The variance on the estimate of the frame at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_frame_errors(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The standard deviation of the estimate of the frame at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_px_x(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The estimate of the pixel x position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_px_x_var(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The variance on the estimate of the pixel x position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_px_x_errors(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The standard deviation of the estimate of the pixel x position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_px_y(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The estimate of the pixel y position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_px_y_var(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The variance on the estimate of the pixel y position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_px_y_errors(NX_FLOAT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The standard deviation of the estimate of the pixel y position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_phi(NX_FLOAT): unit: NX_ANGLE exists: ['min', '1'] - doc: | + doc: | The estimate of the phi angle at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_phi_var(NX_FLOAT): unit: NX_ANGLE exists: ['min', '1'] - doc: | + doc: | The variance on the estimate of the phi angle at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_phi_errors(NX_FLOAT): unit: NX_ANGLE exists: ['min', '1'] - doc: | + doc: | The standard deviation of the estimate of the phi angle at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_x(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1'] - doc: | + doc: | The estimate of the x position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_x_var(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1'] - doc: | + doc: | The variance on the estimate of the x position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_x_errors(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1'] - doc: | + doc: | The standard deviation of the estimate of the x position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_y(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1'] - doc: | + doc: | The estimate of the y position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_y_var(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1'] - doc: | + doc: | The variance on the estimate of the y position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset observed_y_errors(NX_FLOAT): unit: NX_LENGTH exists: ['min', '1'] - doc: | + doc: | The standard deviation of the estimate of the y position at which the central impact of the reflection was recorded dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset bounding_box(NX_INT): unit: NX_UNITLESS exists: ['min', '1'] - doc: | + doc: | The bounding box around the recorded recorded reflection. Should be an integer array of length 6, where the 6 values - are pixel positions or frame numbers, as follows':' + are pixel positions or frame numbers, as follows: ===== =========================== index meaning @@ -464,142 +461,806 @@ NXreflections(NXobject): rank: 2 dim: [[1, n], [2, 6]] \@description: - doc: | + doc: | Describes the dataset background_mean(NX_FLOAT): exists: ['min', '1'] - doc: | + doc: | The mean background under the reflection peak dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset int_prf(NX_FLOAT): exists: ['min', '0'] - doc: | + doc: | The estimate of the reflection intensity by profile fitting dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset int_prf_var(NX_FLOAT): exists: ['min', '0'] - doc: | + doc: | The variance on the estimate of the reflection intensity by profile fitting dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset int_prf_errors(NX_FLOAT): exists: ['min', '0'] - doc: | + doc: | The standard deviation of the estimate of the reflection intensity by profile fitting dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset int_sum(NX_FLOAT): exists: ['min', '1'] - doc: | + doc: | The estimate of the reflection intensity by summation dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset int_sum_var(NX_FLOAT): exists: ['min', '1'] - doc: | + doc: | The variance on the estimate of the reflection intensity by summation dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset int_sum_errors(NX_FLOAT): exists: ['min', '1'] - doc: | + doc: | The standard deviation of the estimate of the reflection intensity by summation dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset lp(NX_FLOAT): exists: ['min', '1'] - doc: | + doc: | The LP correction factor to be applied to the reflection intensities dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset prf_cc(NX_FLOAT): exists: ['min', '0'] - doc: | + doc: | The correlation of the reflection profile with the reference profile used in profile fitting dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset overlaps(NX_INT): exists: ['min', '0'] - doc: | + doc: | An adjacency list specifying the spatial overlaps of reflections. The adjacency list is specified using an array data type where the elements of the array are the indices of the adjacent overlapped reflection \@description: - doc: | + doc: | Describes the dataset polar_angle(NX_FLOAT): unit: NX_ANGLE exists: ['min', '0'] - doc: | + doc: | Polar angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset azimuthal_angle(NX_FLOAT): unit: NX_ANGLE exists: ['min', '0'] - doc: | + doc: | Azimuthal angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system dimensions: rank: 1 dim: [[1, n]] \@description: - doc: | + doc: | Describes the dataset \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f0dd5d59e2726272e3befd4fd88df46f824c4023d04a1a1775153f79260f5b7e +# +# +# +# +# +# number of reflections +# number of experiments +# +# Reflection data from diffraction experiments +# +# The experiments from which the reflection data derives +# +# +# +# +# +# +# The h component of the miller index +# +# +# +# +# Describes the dataset +# +# +# +# +# The k component of the miller index +# +# +# +# +# Describes the dataset +# +# +# +# +# The l component of the miller index +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The id of the experiment which resulted in the reflection. If the value +# is greater than 0, the experiments must link to a multi-experiment NXmx +# group +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The id of the reflection. Multiple partials from the same reflection +# should all have the same id +# +# +# +# +# +# Describes the dataset +# +# +# +# Is the reflection entering or exiting the Ewald sphere +# +# +# +# +# Describes the dataset +# +# +# +# +# The detector module on which the reflection was recorded +# +# +# +# +# Describes the dataset +# +# +# +# +# +# Status flags describing the reflection. +# +# This is a bit mask. The bits in the mask follow the convention +# used by DIALS, and have the following names: +# +# === ========================================== +# bit name +# === ========================================== +# 0 ``predicted`` +# 1 ``observed`` +# 2 ``indexed`` +# 3 ``used_in_refinement`` +# 4 ``strong`` +# 5 ``reference_spot`` +# 6 ``dont_integrate`` +# 7 ``integrated_sum`` +# 8 ``integrated_prf`` +# 9 ``integrated`` +# 10 ``overloaded`` +# 11 ``overlapped`` +# 12 ``overlapped_fg`` +# 13 ``in_powder_ring`` +# 14 ``foreground_includes_bad_pixels`` +# 15 ``background_includes_bad_pixels`` +# 16 ``includes_bad_pixels`` +# 17 ``bad_shoebox`` +# 18 ``bad_spot`` +# 19 ``used_in_modelling`` +# 20 ``centroid_outlier`` +# 21 ``failed_during_background_modelling`` +# 22 ``failed_during_summation`` +# 23 ``failed_during_profile_fitting`` +# 24 ``bad_reference`` +# === ========================================== +# +# +# +# +# +# Describes the dataset +# +# +# +# +# The resolution of the reflection +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The partiality of the reflection. +# Dividing by this number will inflate the measured +# intensity to the full reflection equivalent. +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The frame on which the bragg peak of the reflection is predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The x position at which the bragg peak of the reflection +# is predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The y position at which the bragg peak of the reflection +# is predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The phi angle at which the bragg peak of the reflection is predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The x pixel position at which the bragg peak of the reflection is +# predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The y pixel position at which the bragg peak of the reflection is +# predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the frame at which the central impact of the +# reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the frame at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the frame at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the pixel x position at which the central impact of +# the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the pixel x position at which the +# central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the pixel x position at which the +# central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the pixel y position at which the central impact of +# the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the pixel y position at which the +# central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the pixel y position at which the +# central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the phi angle at which the central impact of the +# reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the phi angle at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the phi angle at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the x position at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the x position at which +# the central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the x position at which +# the central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the y position at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the y position at which +# the central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the y position at which +# the central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The bounding box around the recorded recorded reflection. +# Should be an integer array of length 6, where the 6 values +# are pixel positions or frame numbers, as follows: +# +# ===== =========================== +# index meaning +# ===== =========================== +# 0 The lower pixel x position +# 1 The upper pixel x position +# 2 The lower pixel y position +# 3 The upper pixel y position +# 4 The lower frame number +# 5 The upper frame number +# ===== =========================== +# +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The mean background under the reflection peak +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the reflection intensity by profile fitting +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the reflection intensity by profile +# fitting +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the reflection intensity by profile +# fitting +# +# +# +# +# +# Describes the dataset +# +# +# +# The estimate of the reflection intensity by summation +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the reflection intensity by +# summation +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the reflection intensity by +# summation +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The LP correction factor to be applied to the reflection intensities +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The correlation of the reflection profile with the reference profile +# used in profile fitting +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# An adjacency list specifying the spatial overlaps of reflections. The +# adjacency list is specified using an array data type where the elements +# of the array are the indices of the adjacent overlapped reflection +# +# +# Describes the dataset +# +# +# +# +# +# Polar angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# Azimuthal angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system +# +# +# +# +# +# +# Describes the dataset +# +# +# +# .. 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/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml index 4e5af85fd6..bcecfaa0a8 100644 --- a/base_classes/nyaml/NXroot.yaml +++ b/base_classes/nyaml/NXroot.yaml @@ -1,73 +1,180 @@ category: base -doc: | +doc: | Definition of the root NeXus group. - type: group NXroot(NXobject): \@NX_class: - doc: | + doc: | The root of any NeXus data file is an ``NXroot`` class (no other choice is allowed for a valid NeXus data file). This attribute cements that definition. enumeration: [NXroot] \@file_time: type: NX_DATE_TIME - doc: | + doc: | Date and time file was originally created \@file_name: - doc: | + doc: | File name of original NeXus file \@file_update_time: type: NX_DATE_TIME - doc: | + doc: | Date and time of last file change at close \@NeXus_version: - doc: | + doc: | Version of NeXus API used in writing the file. Only used when the NAPI has written the file. Note that this is different from the version of the base class or application definition version number. \@HDF_version: - doc: | + doc: | Version of HDF (version 4) library used in writing the file \@HDF5_Version: - doc: | + doc: | Version of HDF5 library used in writing the file. Note this attribute is spelled with uppercase "V", different than other version attributes. \@XML_version: - doc: | + doc: | Version of XML support library used in writing the XML file \@h5py_version: - doc: | + doc: | Version of h5py Python package used in writing the file \@creator: - doc: | + doc: | facility or program where file originated \@creator_version: - doc: | + doc: | Version of facility or program used in writing the file (NXentry): exists: ['min', '1'] - doc: | + doc: | entries \@default: - doc: | - .. index':'':' find the default plottable data - .. index':'':' plotting - .. index':'':' default attribute value + doc: | + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value - Declares which ':'ref':'`NXentry` group contains + Declares which :ref:`NXentry` group contains the data to be shown by default. It is used to resolve ambiguity when - more than one ':'ref':'`NXentry` group exists. - The value ':'ref':'`names ` the default ':'ref':'`NXentry` group. The + more than one :ref:`NXentry` group exists. + The value :ref:`names ` the default :ref:`NXentry` group. The value must be the name of a child of the current group. The child must be a NeXus group or a link to a NeXus 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 00ad60c31b3087963764958288477d30afe61c6888f025264db3cfb53f1068c1 +# +# +# +# +# Definition of the root NeXus group. +# +# +# The root of any NeXus data file is an ``NXroot`` class +# (no other choice is allowed for a valid NeXus data file). +# This attribute cements that definition. +# +# +# +# +# +# +# Date and time file was originally created +# +# +# File name of original NeXus file +# +# +# Date and time of last file change at close +# +# +# +# Version of NeXus API used in writing the file. +# +# Only used when the NAPI has written the file. +# Note that this is different from the version of the +# base class or application definition version number. +# +# +# +# Version of HDF (version 4) library used in writing the file +# +# +# +# Version of HDF5 library used in writing the file. +# +# Note this attribute is spelled with uppercase "V", +# different than other version attributes. +# +# +# +# Version of XML support library used in writing the XML file +# +# +# Version of h5py Python package used in writing the file +# +# +# facility or program where file originated +# +# +# Version of facility or program used in writing the file +# +# +# entries +# +# +# +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXentry` group contains +# the data to be shown by default. +# It is used to resolve ambiguity when +# more than one :ref:`NXentry` group exists. +# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus 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/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index c65363dae0..e086667736 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -1,42 +1,34 @@ category: base -doc: | +doc: | Any information on the sample. This could include scanned variables that are associated with one of the data dimensions, e.g. the magnetic field, or logged data, e.g. monitored temperature vs elapsed time. - -symbols: - doc: | +symbols: + doc: | symbolic array lengths to be coordinated between various fields - - n_comp: | + n_comp: | number of compositions - - n_Temp: | + n_Temp: | number of temperatures - - n_eField: | + n_eField: | number of values in applied electric field - - n_mField: | + n_mField: | number of values in applied magnetic field - - n_pField: | + n_pField: | number of values in applied pressure field - - n_sField: | + n_sField: | number of values in applied stress field - type: group NXsample(NXobject): name: - doc: | + doc: | Descriptive name of sample chemical_formula: - doc: | + doc: | The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard':' + Abbreviated version of CIF standard: * Only recognized element symbols may be used. * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. @@ -47,7 +39,7 @@ NXsample(NXobject): * 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':' + * 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. @@ -55,113 +47,123 @@ NXsample(NXobject): * This is the *Hill* system used by Chemical Abstracts. temperature(NX_FLOAT): unit: NX_TEMPERATURE - doc: | + doc: | Sample temperature. This could be a scanned variable dimensions: rank: anyRank + + # could be any length dim: [[1, n_Temp]] electric_field(NX_FLOAT): unit: NX_VOLTAGE - doc: | + doc: | Applied electric field dimensions: + + # could be any length dim: [[1, n_eField]] \@direction: enumeration: [x, y, z] magnetic_field(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Applied magnetic field dimensions: + + # could be any length dim: [[1, n_mField]] \@direction: enumeration: [x, y, z] stress_field(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Applied external stress field dimensions: + + # could be any length dim: [[1, n_sField]] \@direction: enumeration: [x, y, z] pressure(NX_FLOAT): unit: NX_PRESSURE - doc: | + doc: | Applied pressure dimensions: + + # could be any length dim: [[1, n_pField]] changer_position(NX_INT): unit: NX_UNITLESS - doc: | + doc: | Sample changer position unit_cell_abc(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Crystallography unit cell parameters a, b, and c dimensions: dim: [[1, 3]] unit_cell_alphabetagamma(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Crystallography unit cell parameters alpha, beta, and gamma dimensions: dim: [[1, 3]] unit_cell(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Unit cell parameters (lengths and angles) dimensions: rank: 2 dim: [[1, n_comp], [2, 6]] unit_cell_volume(NX_FLOAT): unit: NX_VOLUME - doc: | + doc: | Volume of the unit cell dimensions: rank: 1 dim: [[1, n_comp]] sample_orientation(NX_FLOAT): unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention':' + doc: | + This will follow the Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 dimensions: rank: 1 dim: [[1, 3]] orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention':' + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 dimensions: rank: 3 dim: [[1, n_comp], [2, 3], [3, 3]] ub_matrix(NX_FLOAT): - doc: | - UB matrix of single crystal sample using Busing-Levy convention':' + doc: | + 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 + with the :math:`B` matrix which can be derived from the lattice constants. dimensions: rank: 3 dim: [[1, n_comp], [2, 3], [3, 3]] mass(NX_FLOAT): unit: NX_MASS - doc: | + doc: | Mass of sample dimensions: rank: 1 dim: [[1, n_comp]] density(NX_FLOAT): unit: NX_MASS_DENSITY - doc: | + doc: | Density of sample dimensions: rank: 1 dim: [[1, n_comp]] relative_molecular_mass(NX_FLOAT): unit: NX_MASS - doc: | + doc: | Relative Molecular Mass of sample dimensions: rank: 1 @@ -169,36 +171,37 @@ NXsample(NXobject): type: enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] situation: - doc: | + doc: | The atmosphere will be one of the components, which is where its details will be stored; the relevant components will be indicated by the entry in the sample_component member. enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] description: - doc: | + doc: | Description of the sample preparation_date(NX_DATE_TIME): - doc: | + doc: | Date of preparation of the sample geometry(NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead + doc: | The position and orientation of the center of mass of the sample (NXbeam): - doc: | + doc: | Details of beam incident on sample - used to calculate sample/beam interaction point (NXsample_component): - doc: | + doc: | One group per sample component This is the perferred way of recording per component information over the n_comp arrays component: - doc: | + doc: | Details of the component of the sample and/or can dimensions: rank: 1 dim: [[1, n_comp]] sample_component: - doc: | + doc: | Type of component dimensions: rank: 1 @@ -206,119 +209,123 @@ NXsample(NXobject): enumeration: [sample, can, atmosphere, kit] concentration(NX_FLOAT): unit: NX_MASS_DENSITY - doc: | + doc: | Concentration of each component dimensions: rank: 1 dim: [[1, n_comp]] volume_fraction(NX_FLOAT): - doc: | + doc: | Volume fraction of each component dimensions: rank: 1 dim: [[1, n_comp]] scattering_length_density(NX_FLOAT): unit: NX_SCATTERING_LENGTH_DENSITY - doc: | + doc: | Scattering length density of each component dimensions: rank: 1 dim: [[1, n_comp]] unit_cell_class: - doc: | + doc: | In case it is all we know and we want to record/document it enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] space_group: - doc: | + doc: | Crystallographic space group dimensions: dim: [[1, n_comp]] point_group: - doc: | + doc: | Crystallographic point group, deprecated if space_group present dimensions: dim: [[1, n_comp]] path_length(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Path length through sample/can for simple case when it does not vary with scattering direction path_length_window(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Thickness of a beam entry/exit window on the can (mm) - assumed same for entry and exit thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | sample thickness transmission(NXdata): - doc: | + doc: | As a function of Wavelength temperature_log(NXlog): - deprecated: use ``temperature``, see':' https':'//github.com/nexusformat/definitions/issues/816 - doc: | + deprecated: + use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value temperature_env(NXenvironment): - doc: | + doc: | Additional sample temperature environment information magnetic_field(NXlog): - doc: | + doc: | magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value magnetic_field_log(NXlog): - deprecated: use ``magnetic_field``, see':' https':'//github.com/nexusformat/definitions/issues/816 - doc: | + deprecated: + use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value magnetic_field_env(NXenvironment): - doc: | + doc: | Additional sample magnetic environment information external_DAC(NX_FLOAT): unit: NX_ANY - doc: | + doc: | value sent to user's sample setup external_ADC(NXlog): - doc: | + doc: | logged value (or logic state) read from user's setup short_title: - doc: | + doc: | 20 character fixed length sample description for legends + + # How is the string length limitation imposed by the XSD? rotation_angle(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Optional rotation angle for the case when the powder diagram has been obtained through an omega-2theta scan like from a traditional single detector powder diffractometer. Note, it is recommended to use NXtransformations instead. x_translation(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Translation of the sample along the X-direction of the laboratory coordinate system Note, it is recommended to use NXtransformations instead. distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Translation of the sample along the Z-direction of the laboratory coordinate system. Note, it is recommended to use NXtransformations instead. (NXpositioner): - doc: | + doc: | Any positioner (motor, PZT, ...) used to locate the sample (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the sample \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -326,8 +333,432 @@ NXsample(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 297d53ed4ab613686ff86dc212b4a50ff9794932b6b43cb2ab2a6f9c7c7d44c8 +# +# +# +# +# +# +# symbolic array lengths to be coordinated between various fields +# number of compositions +# number of temperatures +# number of values in applied electric field +# number of values in applied magnetic field +# number of values in applied pressure field +# number of values in applied stress field +# +# +# +# Any information on the sample. +# +# This could include scanned variables that +# are associated with one of the data dimensions, e.g. the magnetic field, or +# logged data, e.g. monitored temperature vs elapsed time. +# +# +# Descriptive name of sample +# +# +# +# The chemical formula specified using CIF conventions. +# Abbreviated version of CIF standard: +# +# * 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. +# +# * This is the *Hill* system used by Chemical Abstracts. +# +# +# +# Sample temperature. This could be a scanned variable +# +# +# +# +# +# Applied electric field +# +# +# +# +# +# +# +# +# +# +# +# +# Applied magnetic field +# +# +# +# +# +# +# +# +# +# +# +# +# Applied external stress field +# +# +# +# +# +# +# +# +# +# +# +# +# Applied pressure +# +# +# +# +# +# Sample changer position +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# Unit cell parameters (lengths and angles) +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# Mass of sample +# +# +# +# +# +# Density of sample +# +# +# +# +# +# Relative Molecular Mass of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The atmosphere will be one of the components, which is where +# its details will be stored; the relevant components will be +# indicated by the entry in the sample_component member. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the sample +# +# +# +# Date of preparation of the sample +# +# +# The position and orientation of the center of mass of the sample +# +# +# Details of beam incident on sample - used to calculate sample/beam interaction point +# +# +# +# One group per sample component +# This is the perferred way of recording per component information over the n_comp arrays +# +# +# +# Details of the component of the sample and/or can +# +# +# +# +# +# Type of component +# +# +# +# +# +# +# +# +# +# +# +# Concentration of each component +# +# +# +# +# +# Volume fraction of each component +# +# +# +# +# +# Scattering length density of each component +# +# +# +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# +# +# +# Crystallographic point group, deprecated if space_group present +# +# +# +# +# +# +# Path length through sample/can for simple case when +# it does not vary with scattering direction +# +# +# +# +# Thickness of a beam entry/exit window on the can (mm) +# - assumed same for entry and exit +# +# +# +# sample thickness +# +# +# As a function of Wavelength +# +# +# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value +# +# +# Additional sample temperature environment information +# +# +# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value +# +# +# magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value +# +# +# Additional sample magnetic environment information +# +# +# value sent to user's sample setup +# +# +# logged value (or logic state) read from user's setup +# +# +# 20 character fixed length sample description for legends +# +# +# +# +# Optional rotation angle for the case when the powder diagram has +# been obtained through an omega-2theta scan like from a traditional +# single detector powder diffractometer. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the X-direction of the laboratory coordinate system +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the Z-direction of the laboratory coordinate system. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# Any positioner (motor, PZT, ...) used to locate the sample +# +# +# +# This group describes the shape of the sample +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index 0723818866..79db66dec6 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -1,35 +1,28 @@ category: base -doc: | +doc: | One group like this per component can be recorded For a sample consisting of multiple components. - -symbols: - doc: | +symbols: + doc: | symbolic array lengths to be coordinated between various fields - - n_Temp: | + n_Temp: | number of temperatures - - n_eField: | + n_eField: | number of values in applied electric field - - n_mField: | + n_mField: | number of values in applied magnetic field - - n_pField: | + n_pField: | number of values in applied pressure field - - n_sField: | + n_sField: | number of values in applied stress field - type: group NXsample_component(NXobject): name: - doc: | + doc: | Descriptive name of sample component chemical_formula: - doc: | + doc: | The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard':' + Abbreviated version of CIF standard: * Only recognized element symbols may be used. * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. @@ -40,7 +33,7 @@ NXsample_component(NXobject): * 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':' + * 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. @@ -48,29 +41,29 @@ NXsample_component(NXobject): * This is the *Hill* system used by Chemical Abstracts. unit_cell_abc(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Crystallography unit cell parameters a, b, and c dimensions: dim: [[1, 3]] unit_cell_alphabetagamma(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | Crystallography unit cell parameters alpha, beta, and gamma dimensions: dim: [[1, 3]] unit_cell_volume(NX_FLOAT): unit: NX_VOLUME - doc: | + doc: | Volume of the unit cell sample_orientation(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) dimensions: rank: 1 dim: [[1, 3]] orientation_matrix(NX_FLOAT): - doc: | + doc: | Orientation matrix of single crystal sample component. This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) dimensions: @@ -78,47 +71,205 @@ NXsample_component(NXobject): dim: [[1, 3], [2, 3]] mass(NX_FLOAT): unit: NX_MASS - doc: | + doc: | Mass of sample component density(NX_FLOAT): unit: NX_MASS_DENSITY - doc: | + doc: | Density of sample component relative_molecular_mass(NX_FLOAT): unit: NX_MASS - doc: | + doc: | Relative Molecular Mass of sample component description: - doc: | + doc: | Description of the sample component volume_fraction(NX_FLOAT): - doc: | + doc: | Volume fraction of component scattering_length_density(NX_FLOAT): unit: NX_SCATTERING_LENGTH_DENSITY - doc: | + doc: | Scattering length density of component unit_cell_class: - doc: | + doc: | In case it is all we know and we want to record/document it enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] space_group: - doc: | + doc: | Crystallographic space group point_group: - doc: | + doc: | Crystallographic point group, deprecated if space_group present transmission(NXdata): - doc: | + doc: | As a function of Wavelength \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ff01cd0073031e1be0af7ac769912f5e25a58642674c61264b226c807703a8fc +# +# +# +# +# +# +# symbolic array lengths to be coordinated between various fields +# number of temperatures +# number of values in applied electric field +# number of values in applied magnetic field +# number of values in applied pressure field +# number of values in applied stress field +# +# +# +# One group like this per component can be recorded For a sample consisting of multiple components. +# +# +# Descriptive name of sample component +# +# +# +# The chemical formula specified using CIF conventions. +# Abbreviated version of CIF standard: +# +# * 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. +# +# * This is the *Hill* system used by Chemical Abstracts. +# +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# Volume of the unit cell +# +# +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) +# +# +# +# +# +# +# Orientation matrix of single crystal sample component. +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) +# +# +# +# +# +# +# +# Mass of sample component +# +# +# Density of sample component +# +# +# Relative Molecular Mass of sample component +# +# +# +# Description of the sample component +# +# +# +# Volume fraction of component +# +# +# Scattering length density of component +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# Crystallographic point group, deprecated if space_group present +# +# +# As a function of Wavelength +# +# +# +# .. 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/nyaml/NXshape.yaml b/base_classes/nyaml/NXshape.yaml index 2679d37772..f5222b30de 100644 --- a/base_classes/nyaml/NXshape.yaml +++ b/base_classes/nyaml/NXshape.yaml @@ -1,25 +1,24 @@ category: base -doc: | - legacy class - (used by ':'ref':'`NXgeometry`) - the shape and size of a component. +doc: | + legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. This is the description of the general shape and size of a component, which may be made up of ``numobj`` separate - elements - it is used by the ':'ref':'`NXgeometry` class - + elements - it is used by the :ref:`NXgeometry` class type: group NXshape(NXobject): shape: - doc: | + doc: | general shape of a component enumeration: [nxflat, nxcylinder, nxbox, nxsphere, nxcone, nxelliptical, nxtoroidal, nxparabolic, nxpolynomial] size(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | physical extent of the object along its local axes (after NXorientation) with the center of mass at the local origin (after NXtranslation). The meaning and location of these axes will vary according to the value of the "shape" variable. - ``nshapepar`` defines how many parameters':' + ``nshapepar`` defines how many parameters: - For "nxcylinder" type the parameters are (diameter,height) and a three value orientation vector of the cylinder. - For the "nxbox" type the parameters are (length,width,height). @@ -35,13 +34,110 @@ NXshape(NXobject): direction: enumeration: [concave, convex] \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c273b2f18be61f791d2fc4da9ecefbb880d180a9f83536ad161f2f685127f209 +# +# +# +# +# +# legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. +# +# This is the description of the general shape and size of a +# component, which may be made up of ``numobj`` separate +# elements - it is used by the :ref:`NXgeometry` class +# +# +# general shape of a component +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# physical extent of the object along its local axes (after NXorientation) +# with the center of mass at the local origin (after NXtranslation). +# The meaning and location of these axes will vary according to the value +# of the "shape" variable. +# ``nshapepar`` defines how many parameters: +# +# - For "nxcylinder" type the parameters are (diameter,height) and a three value orientation vector of the cylinder. +# - For the "nxbox" type the parameters are (length,width,height). +# - For the "nxsphere" type the parameters are (diameter). +# - For nxcone cone half aperture +# - For nxelliptical, semi-major axis, semi-minor-axis, angle of major axis and pole +# - For nxtoroidal, major radius, minor radius +# - For nxparabolic, parabolic parameter a +# - For nxpolynomial, an array of polynom coefficients, the dimension of the array +# encodes the degree of the polynom +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# .. 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/nyaml/NXslit.yaml b/base_classes/nyaml/NXslit.yaml index e56fbb2798..364a1c539c 100644 --- a/base_classes/nyaml/NXslit.yaml +++ b/base_classes/nyaml/NXslit.yaml @@ -1,13 +1,12 @@ category: base -doc: | +doc: | A simple slit. - For more complex geometries, ':'ref':'`NXaperture` should be used. - + For more complex geometries, :ref:`NXaperture` should be used. type: group NXslit(NXobject): depends_on(NX_CHAR): - doc: | + doc: | Points to the path of the last element in the geometry chain that places this object in space. When followed through that chain is supposed to end at an element depending @@ -20,32 +19,123 @@ NXslit(NXobject): is the centre of the slit opening in the x and y axis on the reference plane. The reference point on the z axis is the reference plane. - .. image':'':' slit/slit.png - ':'width':' 40% + .. image:: slit/slit.png + :width: 40% x_gap(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | Size of the gap opening in the first dimension of the local coordinate system. y_gap(NX_NUMBER): unit: NX_LENGTH - doc: | + doc: | Size of the gap opening in the second dimension of the local coordinate system. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 417ccad73271f355d1d59bfad75b0a0622636749a18b54e8d6f71ec54a968203 +# +# +# +# +# +# A simple slit. +# +# For more complex geometries, :ref:`NXaperture` should be used. +# +# +# +# Points to the path of the last element in the geometry chain that places +# this object in space. +# When followed through that chain is supposed to end at an element depending +# on "." i.e. the origin of the coordinate system. +# If desired the location of the slit can also be described relative to +# an NXbeam, which will allow a simple description of a non-centred slit. +# +# The reference plane of the slit is orthogonal to the z axis and includes the +# surface that is the entry surface of the slit. The reference point of the slit +# is the centre of the slit opening in the x and y axis on the reference plane. +# The reference point on the z axis is the reference plane. +# +# .. image:: slit/slit.png +# :width: 40% +# +# +# +# +# +# Size of the gap opening in the first dimension of the local +# coordinate system. +# +# +# +# +# Size of the gap opening in the second dimension of the local +# 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. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index cfc3ce8f2f..eecc390a53 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -1,153 +1,161 @@ category: base -doc: | +doc: | The neutron or x-ray storage ring/facility. - type: group NXsource(NXobject): distance(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Effective distance from sample Distance as seen by radiation from sample. This number should be negative to signify that it is upstream of the sample. name: - doc: | + doc: | Name of source \@short_name: - doc: | + doc: | short name for source, perhaps the acronym type: - doc: | + doc: | type of radiation source (pick one from the enumerated list and spell exactly) enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] probe: - doc: | + doc: | type of radiation probe (pick one from the enumerated list and spell exactly) enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] power(NX_FLOAT): unit: NX_POWER - doc: | + doc: | Source power emittance_x(NX_FLOAT): unit: NX_EMITTANCE - doc: | + doc: | Source emittance (nm-rad) in X (horizontal) direction. emittance_y(NX_FLOAT): unit: NX_EMITTANCE - doc: | + doc: | Source emittance (nm-rad) in Y (horizontal) direction. sigma_x(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | particle beam size in x sigma_y(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | particle beam size in y flux(NX_FLOAT): unit: NX_FLUX - doc: | - Source intensity/area (example':' s-1 cm-2) + doc: | + Source intensity/area (example: s-1 cm-2) energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | Source energy. For storage rings, this would be the particle beam energy. For X-ray tubes, this would be the excitation voltage. current(NX_FLOAT): unit: NX_CURRENT - doc: | + doc: | Accelerator, X-ray tube, or storage ring current voltage(NX_FLOAT): unit: NX_VOLTAGE - doc: | + doc: | Accelerator voltage frequency(NX_FLOAT): unit: NX_FREQUENCY - doc: | + doc: | Frequency of pulsed source period(NX_FLOAT): unit: NX_PERIOD - doc: | + doc: | Period of pulsed source target_material: - doc: | + doc: | Pulsed source target material enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] notes(NXnote): - doc: | + doc: | any source/facility related messages/events that occurred during the experiment bunch_pattern(NXdata): - doc: | + doc: | For storage rings, description of the bunch pattern. This is useful to describe irregular bunch patterns. title: - doc: | + doc: | name of the bunch pattern number_of_bunches(NX_INT): - doc: | + doc: | For storage rings, the number of bunches in use. bunch_length(NX_FLOAT): unit: NX_TIME - doc: | + doc: | For storage rings, temporal length of the bunch bunch_distance(NX_FLOAT): unit: NX_TIME - doc: | + doc: | For storage rings, time between bunches pulse_width(NX_FLOAT): unit: NX_TIME - doc: | + doc: | temporal width of source pulse + + # pulsed sources or storage rings could use this pulse_shape(NXdata): - doc: | + doc: | source pulse shape + + # pulsed sources or storage rings could use this mode: - doc: | + doc: | source operating mode enumeration: Single Bunch: - doc: | + doc: | for storage rings Multi Bunch: - doc: | + doc: | for storage rings + + # other sources could add to this + + # other sources could add to this top_up(NX_BOOLEAN): - doc: | + doc: | Is the synchrotron operating in top_up mode? last_fill(NX_NUMBER): unit: NX_CURRENT - doc: | + doc: | For storage rings, the current at the end of the most recent injection. \@time: type: NX_DATE_TIME - doc: | + doc: | date and time of the most recent injection. geometry(NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the source and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead + doc: | "Engineering" location of source. (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component (NXdata)distribution: - doc: | + doc: | The wavelength or energy distribution of the source \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -158,11 +166,231 @@ NXsource(NXobject): The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the z axis. - .. image':'':' source/source.png - ':'width':' 40% + .. image:: source/source.png + :width: 40% (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 039c5318d84993a4f6151230f9a20ae19276d21bf2d8552e450f1a5eb0c810ad +# +# +# +# +# The neutron or x-ray storage ring/facility. +# +# +# Effective distance from sample +# Distance as seen by radiation from sample. This number should be negative +# to signify that it is upstream of the sample. +# +# +# +# Name of source +# +# short name for source, perhaps the acronym +# +# +# +# type of radiation source (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# type of radiation probe (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# Source power +# +# +# Source emittance (nm-rad) in X (horizontal) direction. +# +# +# Source emittance (nm-rad) in Y (horizontal) direction. +# +# +# particle beam size in x +# +# +# particle beam size in y +# +# +# Source intensity/area (example: s-1 cm-2) +# +# +# +# Source energy. +# For storage rings, this would be the particle beam energy. +# For X-ray tubes, this would be the excitation voltage. +# +# +# +# Accelerator, X-ray tube, or storage ring current +# +# +# Accelerator voltage +# +# +# Frequency of pulsed source +# +# +# Period of pulsed source +# +# +# Pulsed source target material +# +# +# +# +# +# +# +# +# +# +# +# +# any source/facility related messages/events that +# occurred during the experiment +# +# +# +# +# For storage rings, description of the bunch pattern. +# This is useful to describe irregular bunch patterns. +# +# name of the bunch pattern +# +# +# For storage rings, the number of bunches in use. +# +# +# For storage rings, temporal length of the bunch +# +# +# For storage rings, time between bunches +# +# +# temporal width of source pulse +# +# +# source pulse shape +# +# +# source operating mode +# +# for storage rings +# for storage rings +# +# +# +# +# Is the synchrotron operating in top_up mode? +# +# +# For storage rings, the current at the end of the most recent injection. +# date and time of the most recent injection. +# +# +# +# "Engineering" location of source. +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# The wavelength or energy distribution of the source +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the +# z axis. +# +# .. image:: source/source.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXsubentry.yaml b/base_classes/nyaml/NXsubentry.yaml index 840297cfbf..248111e211 100644 --- a/base_classes/nyaml/NXsubentry.yaml +++ b/base_classes/nyaml/NXsubentry.yaml @@ -1,142 +1,146 @@ category: base -doc: | +doc: | Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. - ``NXsubentry`` is a base class virtually identical to ':'ref':'`NXentry` + ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` and is used as the (overlay) location for application definitions. Use a separate ``NXsubentry`` for each application definition. To use ``NXsubentry`` with a hypothetical application definition - called ``NXmyappdef``':' + called ``NXmyappdef``: * Create a group with attribute ``NX_class="NXsubentry"`` * Within that group, create a field called ``definition="NXmyappdef"``. - * There are two optional attributes of definition':' ``version`` and ``URL`` + * There are two optional attributes of definition: ``version`` and ``URL`` The intended use is to define application definitions for a - multi-modal (a.k.a. multi-technique) ':'ref':'`NXentry`. + multi-modal (a.k.a. multi-technique) :ref:`NXentry`. Previously, an application definition - replaced ':'ref':'`NXentry` with its own definition. + replaced :ref:`NXentry` with its own definition. With the increasing popularity of instruments combining multiple techniques for data collection (such as SAXS/WAXS instruments), it was recognized the application definitions must be entered in the NeXus - data file tree as children of ':'ref':'`NXentry`. - + data file tree as children of :ref:`NXentry`. type: group NXsubentry(NXobject): \@default: - doc: | - .. index':'':' find the default plottable data - .. index':'':' plotting - .. index':'':' default attribute value + doc: | + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value - Declares which ':'ref':'`NXdata` group contains the data + Declares which :ref:`NXdata` group contains the data to be shown by default. It is used to resolve ambiguity when - one ':'ref':'`NXdata` group exists. - The value ':'ref':'`names ` the default ':'ref':'`NXentry` group. The + one :ref:`NXdata` group exists. + The value :ref:`names ` the default :ref:`NXentry` group. The value must be the name of a child of the current group. The child must be a NeXus group or a link to a NeXus group. For more information about how NeXus identifies the default plottable data, see the - ':'ref':'`Find Plottable Data, v3 ` + :ref:`Find Plottable Data, v3 ` section. \@IDF_Version: - doc: | + + # as ratified at NIAC2010 + doc: | ISIS Muon IDF_Version title: - doc: | + doc: | Extended title for entry experiment_identifier: - doc: | + doc: | Unique identifier for the experiment, defined by the facility, possibly linked to the proposals experiment_description: - doc: | + doc: | Brief summary of the experiment, including key objectives. (NXnote)experiment_documentation: - doc: | + doc: | Description of the full experiment (document in pdf, latex, ...) collection_identifier: - doc: | - User or Data Acquisition defined group of NeXus files or ':'ref':'`NXentry` + doc: | + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` collection_description: - doc: | + doc: | Brief summary of the collection, including grouping criteria. entry_identifier: - doc: | + doc: | unique identifier for the measurement, defined by the facility. definition: - doc: | + doc: | Official NeXus NXDL schema to which this subentry conforms \@version: - doc: | + doc: | NXDL version number \@URL: - doc: | + doc: | URL of NXDL file definition_local: - doc: | + doc: | Local NXDL schema extended from the subentry specified in the ``definition`` field. This contains any locally-defined, additional fields in the subentry. \@version: - doc: | + doc: | NXDL version number \@URL: - doc: | + doc: | URL of NXDL file start_time(NX_DATE_TIME): - doc: | + doc: | Starting time of measurement end_time(NX_DATE_TIME): - doc: | + doc: | Ending time of measurement duration(NX_INT): unit: NX_TIME - doc: | + doc: | Duration of measurement collection_time(NX_FLOAT): unit: NX_TIME - doc: | + doc: | Time transpired actually collecting data i.e. taking out time when collection was suspended due to e.g. temperature out of range run_cycle: - doc: | + doc: | Such as "2007-3". Some user facilities organize their beam time into run cycles. program_name: - doc: | + doc: | Name of program used to generate this file \@version: - doc: | + doc: | Program version number \@configuration: - doc: | + doc: | configuration of the program revision: - doc: | + doc: | Revision id of the file due to re-calibration, reprocessing, new analysis, new instrument definition format, ... \@comment: pre_sample_flightpath(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words':' it the distance to the component + by the moderator or the source itself. In other words: it the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. notes(NXnote): - doc: | + doc: | Notes describing entry thumbnail(NXnote): - doc: | + doc: | A small image that is representative of the entry. An example of this is a 640x480 jpeg image automatically produced by a low resolution plot of the NXdata. \@mime_type: - doc: | + doc: | The value should be an ``image/*`` + + # This is not perfect. + # How do we set a default value for the mime_type attribute? enumeration: [image/*] (NXuser): (NXsample): @@ -146,3 +150,195 @@ NXsubentry(NXobject): (NXdata): (NXparameters): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 73d58acb9360e8891346fefd2018fc630e5216eb27617d7dc5aec05808025224 +# +# +# +# +# +# +# +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXdata` group contains the data +# to be shown by default. +# It is used to resolve ambiguity when +# one :ref:`NXdata` group exists. +# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus group. +# +# For more information about how NeXus identifies the default +# plottable data, see the +# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` +# section. +# +# +# +# +# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. +# +# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` +# and is used as the (overlay) location for application definitions. +# Use a separate ``NXsubentry`` for each application definition. +# +# To use ``NXsubentry`` with a hypothetical application definition +# called ``NXmyappdef``: +# +# * Create a group with attribute ``NX_class="NXsubentry"`` +# * Within that group, create a field called ``definition="NXmyappdef"``. +# * There are two optional attributes of definition: ``version`` and ``URL`` +# +# The intended use is to define application definitions for a +# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. +# Previously, an application definition +# replaced :ref:`NXentry` with its own definition. +# With the increasing popularity of instruments combining +# multiple techniques for data collection (such as SAXS/WAXS instruments), +# it was recognized the application definitions must be entered in the NeXus +# data file tree as children of :ref:`NXentry`. +# +# +# +# +# ISIS Muon IDF_Version +# +# +# +# Extended title for entry +# +# +# +# Unique identifier for the experiment, defined by +# the facility, possibly linked to the proposals +# +# +# +# Brief summary of the experiment, including key objectives. +# +# +# Description of the full experiment (document in pdf, latex, ...) +# +# +# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` +# +# +# Brief summary of the collection, including grouping criteria. +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# Official NeXus NXDL schema to which this subentry conforms +# NXDL version number +# URL of NXDL file +# +# +# +# Local NXDL schema extended from the subentry +# specified in the ``definition`` field. +# This contains any locally-defined, +# additional fields in the subentry. +# +# NXDL version number +# URL of NXDL file +# +# +# Starting time of measurement +# +# +# Ending time of measurement +# +# +# Duration of measurement +# +# +# +# Time transpired actually collecting data i.e. taking out time when collection was +# suspended due to e.g. temperature out of range +# +# +# +# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# +# +# Name of program used to generate this file +# Program version number +# configuration of the program +# +# +# +# Revision id of the file due to re-calibration, reprocessing, new analysis, new +# instrument definition format, ... +# +# +# +# +# +# This is the flightpath before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# Notes describing entry +# +# +# +# A small image that is representative of the entry. An example of this is a 640x480 +# jpeg image automatically produced by a low resolution plot of the NXdata. +# +# +# The value should be an ``image/*`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml index e27b95ac1f..0a5efe9061 100644 --- a/base_classes/nyaml/NXtransformations.yaml +++ b/base_classes/nyaml/NXtransformations.yaml @@ -1,5 +1,5 @@ category: base -doc: | +doc: | Collection of axis-based translations and rotations to describe a geometry. May also contain axes that do not move and therefore do not have a transformation type specified, but are useful in understanding coordinate frames within which @@ -14,7 +14,7 @@ doc: | the values change with time. The all-caps name ``AXISNAME`` designates the particular axis generating a transformation (e.g. a rotation axis or a translation axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the - units will be appropriate to the ``transformation_type`` attribute':' + units will be appropriate to the ``transformation_type`` attribute: * ``NX_LENGTH`` for ``translation`` * ``NX_ANGLE`` for ``rotation`` @@ -31,24 +31,24 @@ doc: | a relative path is given, it is relative to the group enclosing the ``depends_on`` specification. - For a chain of three transformations, where ':'math':'`T_1` depends on ':'math':'`T_2` - and that in turn depends on ':'math':'`T_3`, the final transformation ':'math':'`T_f` is + For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` + and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is - .. math':'':' T_f = T_3 T_2 T_1 + .. math:: T_f = T_3 T_2 T_1 In explicit terms, the transformations are a subset of affine transformations - expressed as 4x4 matrices that act on homogeneous coordinates, ':'math':'`w=(x,y,z,1)^T`. + expressed as 4x4 matrices that act on homogeneous coordinates, :math:`w=(x,y,z,1)^T`. For rotation and translation, - .. math':'':' T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} + .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} - where ':'math':'`R` is the usual 3x3 rotation matrix, ':'math':'`o` is an offset vector, - ':'math':'`0_3` is a row of 3 zeros, ':'math':'`I_3` is the 3x3 identity matrix and - ':'math':'`t` is the translation vector. + where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, + :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and + :math:`t` is the translation vector. - ':'math':'`o` is given by the ``offset`` attribute, ':'math':'`t` is given by the ``vector`` - attribute multiplied by the field value, and ':'math':'`R` is defined as a rotation + :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` + attribute multiplied by the field value, and :math:`R` is defined as a rotation about an axis in the direction of ``vector``, of angle of the field value. NOTE @@ -66,7 +66,7 @@ doc: | there is a need for positioning a beam line component please use the existing names. Use as many fields as needed in order to position the component. Feel free to add more axis if required. In the description given below, only those atttributes which are defined through the name are spcified. Add the other attributes - of the full set':' + of the full set: * vector * offset @@ -74,7 +74,6 @@ doc: | * depends_on as needed. - type: group ignoreExtraGroups: true ignoreExtraFields: true @@ -84,7 +83,7 @@ NXtransformations(NXobject): nameType: any unit: NX_TRANSFORMATION exists: ['max', 'unbounded'] - doc: | + doc: | Units need to be appropriate for translation or rotation The name of this field is not forced. The user is free to use any name @@ -96,7 +95,7 @@ NXtransformations(NXobject): frames. The end points should be given in ``AXISNAME_end``. \@transformation_type: exists: optional - doc: | + doc: | The transformation_type may be ``translation``, in which case the values are linear displacements along the axis, ``rotation``, in which case the values are angular rotations around the axis. @@ -105,11 +104,13 @@ NXtransformations(NXobject): is no motion to be specifies, such as the direction of gravity, or the direction to the source, or a basis vector of a coordinate frame. + + # enumeration: [translation, rotation] \@vector: exists: optional type: NX_NUMBER - doc: | + doc: | Three values that define the axis for this transformation. The axis should be normalized to unit length, making it dimensionless. For ``rotation`` axes, the direction should be @@ -122,7 +123,7 @@ NXtransformations(NXobject): dim: [[1, 3]] \@offset: type: NX_NUMBER - doc: | + doc: | A fixed offset applied before the transformation (three vector components). This is not intended to be a substitute for a fixed ``translation`` axis but, for example, as the mechanical offset from mounting the axis to its dependency. @@ -131,16 +132,16 @@ NXtransformations(NXobject): dim: [[1, 3]] \@offset_units: type: NX_CHAR - doc: | + doc: | Units of the offset. Values should be consistent with NX_LENGTH. \@depends_on: type: NX_CHAR - doc: | + doc: | Points to the path to a field defining the axis on which this depends or the string ".". \@equipment_component: type: NX_CHAR - doc: | + doc: | An arbitrary identifier of a component of the equipment to which the transformation belongs, such as 'detector_arm' or 'detector_module'. NXtransformations with the same equipment_component label form a logical @@ -150,7 +151,7 @@ NXtransformations(NXobject): unit: NX_TRANSFORMATION nameType: any exists: ['min', '0'] - doc: | + doc: | ``AXISNAME_end`` is a placeholder for a name constructed from the actual name of an axis to which ``_end`` has been appended. @@ -160,7 +161,7 @@ NXtransformations(NXobject): unit: NX_TRANSFORMATION nameType: any exists: ['min', '0'] - doc: | + doc: | ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual name of an axis to which ``_increment_set`` has been appended. @@ -170,13 +171,236 @@ NXtransformations(NXobject): corresponding values of ``AXISNAME_end``, but there is a possibility of significant differences. Use of ``AXISNAME_end`` is recommended. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f47cb808914aa3b75fb05b4c97d8f4ff4c1c08478e44a502c50e2ca5b50682c3 +# +# +# +# +# +# +# Collection of axis-based translations and rotations to describe a geometry. +# May also contain axes that do not move and therefore do not have a transformation +# type specified, but are useful in understanding coordinate frames within which +# transformations are done, or in documenting important directions, such as the +# direction of gravity. +# +# A nested sequence of transformations lists the translation and rotation steps +# needed to describe the position and orientation of any movable or fixed device. +# +# There will be one or more transformations (axes) defined by one or more fields +# for each transformation. Transformations can also be described by NXlog groups when +# the values change with time. The all-caps name ``AXISNAME`` designates the +# particular axis generating a transformation (e.g. a rotation axis or a translation +# axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the +# units will be appropriate to the ``transformation_type`` attribute: +# +# * ``NX_LENGTH`` for ``translation`` +# * ``NX_ANGLE`` for ``rotation`` +# * ``NX_UNITLESS`` for axes for which no transformation type is specified +# +# This class will usually contain all axes of a sample stage or goniometer or +# a detector. The NeXus default McSTAS coordinate frame is assumed, but additional +# useful coordinate axes may be defined by using axes for which no transformation +# type has been specified. +# +# The entry point (``depends_on``) will be outside of this class and point to a +# field in here. Following the chain may also require following ``depends_on`` +# links to transformations outside, for example to a common base table. If +# a relative path is given, it is relative to the group enclosing the ``depends_on`` +# specification. +# +# For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` +# and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is +# +# .. math:: T_f = T_3 T_2 T_1 +# +# In explicit terms, the transformations are a subset of affine transformations +# expressed as 4x4 matrices that act on homogeneous coordinates, :math:`w=(x,y,z,1)^T`. +# +# For rotation and translation, +# +# .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} +# +# where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, +# :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and +# :math:`t` is the translation vector. +# +# :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` +# attribute multiplied by the field value, and :math:`R` is defined as a rotation +# about an axis in the direction of ``vector``, of angle of the field value. +# +# NOTE +# +# One possible use of ``NXtransformations`` is to define the motors and +# transformations for a diffractometer (goniometer). Such use is mentioned +# in the ``NXinstrument`` base class. Use one ``NXtransformations`` group +# for each diffractometer and name the group appropriate to the device. +# Collecting the motors of a sample table or xyz-stage in an NXtransformations +# group is equally possible. +# +# +# Following the section on the general dscription of axis in NXtransformations is a section which +# documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever +# there is a need for positioning a beam line component please use the existing names. Use as many fields +# as needed in order to position the component. Feel free to add more axis if required. In the description +# given below, only those atttributes which are defined through the name are spcified. Add the other attributes +# of the full set: +# +# * vector +# * offset +# * transformation_type +# * depends_on +# +# as needed. +# +# +# +# Units need to be appropriate for translation or rotation +# +# The name of this field is not forced. The user is free to use any name +# that does not cause confusion. When using more than one ``AXISNAME`` field, +# make sure that each field name is unique in the same group, as required +# by HDF5. +# +# The values given should be the start points of exposures for the corresponding +# frames. The end points should be given in ``AXISNAME_end``. +# +# +# +# The transformation_type may be ``translation``, in which case the +# values are linear displacements along the axis, ``rotation``, +# in which case the values are angular rotations around the axis. +# +# If this attribute is omitted, this is an axis for which there +# is no motion to be specifies, such as the direction of gravity, +# or the direction to the source, or a basis vector of a +# coordinate frame. +# +# +# +# +# +# +# +# +# +# Three values that define the axis for this transformation. +# The axis should be normalized to unit length, making it +# dimensionless. For ``rotation`` axes, the direction should be +# chosen for a right-handed rotation with increasing angle. +# For ``translation`` axes the direction should be chosen for +# increasing displacement. For general axes, an appropriate direction +# should be chosen. +# +# +# +# +# +# +# +# A fixed offset applied before the transformation (three vector components). +# This is not intended to be a substitute for a fixed ``translation`` axis but, for example, +# as the mechanical offset from mounting the axis to its dependency. +# +# +# +# +# +# +# +# Units of the offset. Values should be consistent with NX_LENGTH. +# +# +# +# +# Points to the path to a field defining the axis on which this +# depends or the string ".". +# +# +# +# +# An arbitrary identifier of a component of the equipment to which +# the transformation belongs, such as 'detector_arm' or 'detector_module'. +# NXtransformations with the same equipment_component label form a logical +# grouping which can be combined together into a single change-of-basis +# operation. +# +# +# +# +# +# ``AXISNAME_end`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_end`` has been appended. +# +# The values in this field are the end points of the motions that start +# at the corresponding positions given in the ``AXISNAME`` field. +# +# +# +# +# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_increment_set`` has been appended. +# +# The value of this optional field is the intended average range through which +# the corresponding axis moves during the exposure of a frame. Ideally, the +# value of this field added to each value of ``AXISNAME`` would agree with the +# corresponding values of ``AXISNAME_end``, but there is a possibility of significant +# differences. Use of ``AXISNAME_end`` is recommended. +# +# +# +# +# .. 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/nyaml/NXtranslation.yaml b/base_classes/nyaml/NXtranslation.yaml index 5a0337be14..99b08fc4fe 100644 --- a/base_classes/nyaml/NXtranslation.yaml +++ b/base_classes/nyaml/NXtranslation.yaml @@ -1,15 +1,14 @@ category: base -doc: | - legacy class - (used by ':'ref':'`NXgeometry`) - general spatial location of a component. - +doc: | + legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. type: group NXtranslation(NXobject): geometry(NXgeometry): - doc: | + doc: | Link to other object if we are relative, else absent distances(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | (x,y,z) This field describes the lateral movement of a component. The pair of groups NXtranslation and NXorientation together @@ -22,13 +21,82 @@ NXtranslation(NXobject): dimensions: dim: [[1, numobj], [2, 3]] \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3d64610ba1f1776cf277b5aca7e63bf3e504ed9a3f558bf28241565df29d6cc1 +# +# +# +# +# +# legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. +# +# +# Link to other object if we are relative, else absent +# +# +# +# (x,y,z) +# This field describes the lateral movement of a component. +# The pair of groups NXtranslation and NXorientation together +# describe the position of a component. +# For absolute position, the origin is the scattering center (where a perfectly +# aligned sample would be) with the z-axis pointing downstream and the y-axis +# pointing gravitationally up. For a relative position the NXtranslation is +# taken into account before the NXorientation. The axes are right-handed and +# orthonormal. +# +# +# +# +# +# +# +# +# .. 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/nyaml/NXuser.yaml b/base_classes/nyaml/NXuser.yaml index b0dbe8ed04..383a8e9d17 100644 --- a/base_classes/nyaml/NXuser.yaml +++ b/base_classes/nyaml/NXuser.yaml @@ -1,54 +1,145 @@ category: base -doc: | +doc: | Contact information for a user. The format allows more than one user with the same affiliation and contact information, - but a second ':'ref':'`NXuser` group should be used if they have different + but a second :ref:`NXuser` group should be used if they have different affiliations, etc. - type: group NXuser(NXobject): name: - doc: | + doc: | Name of user responsible for this entry role: - doc: | + doc: | Role of user responsible for this entry. Suggested roles are "local_contact", "principal_investigator", and "proposer" affiliation: - doc: | + doc: | Affiliation of user address: - doc: | + doc: | Address of user telephone_number: - doc: | + doc: | Telephone number of user fax_number: - doc: | + doc: | Fax number of user email: - doc: | + doc: | Email of user facility_user_id: - doc: | + doc: | facility based unique identifier for this person e.g. their identification code on the facility address/contact database ORCID: - doc: | + doc: | an author code, Open Researcher and Contributor ID, - defined by https':'//orcid.org and expressed as a URI + defined by https://orcid.org and expressed as a URI \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 095127b2420c5cc3523306d64ff34d05b413ff6c5aa8b3fcb470cba610d93e6a +# +# +# +# +# +# Contact information for a user. +# +# The format allows more +# than one user with the same affiliation and contact information, +# but a second :ref:`NXuser` group should be used if they have different +# affiliations, etc. +# +# +# Name of user responsible for this entry +# +# +# +# Role of user responsible for this entry. +# Suggested roles are "local_contact", +# "principal_investigator", and "proposer" +# +# +# +# Affiliation of user +# +# +# Address of user +# +# +# Telephone number of user +# +# +# Fax number of user +# +# +# Email of user +# +# +# +# facility based unique identifier for this person +# e.g. their identification code on the facility +# address/contact database +# +# +# +# +# an author code, Open Researcher and Contributor ID, +# defined by https://orcid.org and expressed as a URI +# +# +# +# +# .. 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/nyaml/NXvelocity_selector.yaml b/base_classes/nyaml/NXvelocity_selector.yaml index 76079fd503..824a94f9bd 100644 --- a/base_classes/nyaml/NXvelocity_selector.yaml +++ b/base_classes/nyaml/NXvelocity_selector.yaml @@ -1,75 +1,75 @@ category: base -doc: | +doc: | A neutron velocity selector - type: group NXvelocity_selector(NXobject): type: - doc: | + doc: | velocity selector type rotation_speed(NX_FLOAT): unit: NX_FREQUENCY - doc: | + doc: | velocity selector rotation speed radius(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | radius at beam centre spwidth(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | spoke width at beam centre length(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | rotor length num(NX_INT): unit: NX_UNITLESS - doc: | + doc: | number of spokes/lamella twist(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | twist angle along axis table(NX_FLOAT): unit: NX_ANGLE - doc: | + doc: | offset vertical angle height(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | input beam height width(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | input beam width wavelength(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | wavelength wavelength_spread(NX_FLOAT): unit: NX_WAVELENGTH - doc: | + doc: | deviation FWHM /Wavelength (NXgeometry)geometry: - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the velocity selector and NXoff_geometry to describe its shape instead + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the velocity selector and NXoff_geometry to describe its shape instead (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -77,11 +77,122 @@ NXvelocity_selector(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a velocity selector. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a279cfc81cdbfe08cac7842689855bf0a197c1861b8872616295751eaab26e12 +# +# +# +# +# A neutron velocity selector +# +# velocity selector type +# +# +# velocity selector rotation speed +# +# +# radius at beam centre +# +# +# spoke width at beam centre +# +# +# rotor length +# +# +# number of spokes/lamella +# +# +# twist angle along axis +# +# +# offset vertical angle +# +# +# input beam height +# +# +# input beam width +# +# +# wavelength +# +# +# deviation FWHM /Wavelength +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a velocity selector. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXxraylens.yaml b/base_classes/nyaml/NXxraylens.yaml index 5c46e87fc1..f08f4867fc 100644 --- a/base_classes/nyaml/NXxraylens.yaml +++ b/base_classes/nyaml/NXxraylens.yaml @@ -1,74 +1,73 @@ category: base -doc: | +doc: | An X-ray lens, typically at a synchrotron X-ray beam line. Based on information provided by Gerd Wellenreuther (DESY). - type: group NXxraylens(NXobject): lens_geometry(NX_CHAR): - doc: | + doc: | Geometry of the lens enumeration: [paraboloid, spherical, elliptical, hyperbolical] symmetric(NX_BOOLEAN): - doc: | + doc: | Is the device symmetric? cylindrical(NX_BOOLEAN): - doc: | + doc: | Is the device cylindrical? cylinder_orientation(NXnote): - doc: | + doc: | Orientation of the cylinder axis. focus_type(NX_CHAR): - doc: | + doc: | The type of focus of the lens enumeration: [line, point] lens_thickness(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Thickness of the lens lens_length(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Length of the lens curvature(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Radius of the curvature as measured in the middle of the lens aperture(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: | Diameter of the lens. number_of_lenses(NX_INT): - doc: | + doc: | Number of lenses that make up the compound lens. lens_material(NX_CHAR): - doc: | + doc: | Material used to make the lens. gas(NX_CHAR): - doc: | + doc: | Gas used to fill the lens gas_pressure(NX_FLOAT): unit: NX_PRESSURE - doc: | + doc: | Gas pressure in the lens (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the beam line component \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -76,11 +75,146 @@ NXxraylens(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a x-ray lens. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 289923b77926b2d3ad18298238dbafdbb5bb6f038e6d25947224cd1e39a0c04d +# +# +# +# +# +# +# An X-ray lens, typically at a synchrotron X-ray beam line. +# +# Based on information provided by Gerd Wellenreuther (DESY). +# +# +# Geometry of the lens +# +# +# +# +# +# +# +# +# +# Is the device symmetric? +# +# +# +# +# Is the device cylindrical? +# +# +# +# +# Orientation of the cylinder axis. +# +# +# +# +# The type of focus of the lens +# +# +# +# +# +# +# +# Thickness of the lens +# +# +# Length of the lens +# +# +# Radius of the curvature as measured in the middle of the lens +# +# +# Diameter of the lens. +# +# +# Number of lenses that make up the compound lens. +# +# +# Material used to make the lens. +# +# +# Gas used to fill the lens +# +# +# Gas pressure in the lens +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a x-ray lens. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# From fa8baf75175f09896425bff37fcd227be6dbf7bd Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 14:46:23 +0200 Subject: [PATCH 130/203] merge NXaperture changes --- base_classes/NXaperture.nxdl.xml | 150 ++++++++++++++++++----------- base_classes/nyaml/NXaperture.yaml | 13 +++ 2 files changed, 105 insertions(+), 58 deletions(-) diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index e18b2a5f0e..7e64513caf 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -1,14 +1,14 @@ - + - - - A beamline aperture. This group is deprecated, use NXslit instead. - - + + + A beamline aperture. This group is deprecated, use NXslit instead. + + - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the - surface of the aperture pointing towards the source. - - In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - - .. image:: aperture/aperture.png - :width: 40% - + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the + surface of the aperture pointing towards the source. + + In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + + .. image:: aperture/aperture.png + :width: 40% + - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + + + Stores the raw positions of aperture motors. + - location and shape of aperture - - .. TODO: documentation needs improvement, contributions welcome - - * description of terms is poor and leaves much to interpretation - * Describe what is meant by translation _here_ and ... - * Similar throughout base classes - * Some base classes do this much better - * Such as where is the gap written? - + location and shape of aperture + + .. TODO: documentation needs improvement, contributions welcome + + * description of terms is poor and leaves much to interpretation + * Describe what is meant by translation _here_ and ... + * Similar throughout base classes + * Some base classes do this much better + * Such as where is the gap written? - location and shape of each blade + + location and shape of each blade + - - Absorbing material of the aperture + + + + Absorbing material of the aperture + - Description of aperture + + Description of aperture + + + + + Shape of the aperture. + + + + + + + + + + + + + - describe any additional information in a note* + + + The relevant dimension for the aperture, i.e. slit width, pinhole and iris + diameter + + + + + describe any additional information in a note* + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/nyaml/NXaperture.yaml b/base_classes/nyaml/NXaperture.yaml index a366af8970..bc656d852f 100644 --- a/base_classes/nyaml/NXaperture.yaml +++ b/base_classes/nyaml/NXaperture.yaml @@ -27,6 +27,9 @@ NXaperture(NXobject): and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + (NXpositioner): + doc: | + Stores the raw positions of aperture motors. (NXgeometry): deprecated: Use the field `depends_on` and :ref:`NXtransformations` to position the aperture and :ref:`NXoff_geometry` to describe its shape @@ -53,6 +56,15 @@ NXaperture(NXobject): description: doc: | Description of aperture + shape: + doc: | + Shape of the aperture. + enumeration: [straight slit, curved slit, pinhole, circle, square, hexagon, octagon, bladed, open, grid] + size(NX_NUMBER): + unit: NX_LENGTH + doc: | + The relevant dimension for the aperture, i.e. slit width, pinhole and iris + diameter (NXnote): doc: | describe any additional information in a note* @@ -166,3 +178,4 @@ NXaperture(NXobject): # # # + From 549d885f4d7f0378198ca686bfa7a057dac25634 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 17:22:03 +0200 Subject: [PATCH 131/203] removing NXaperture from contributed as it was moved to base_classes --- contributed_definitions/NXaperture.nxdl.xml | 88 ------------------- contributed_definitions/nyaml/NXaperture.yaml | 55 ------------ 2 files changed, 143 deletions(-) delete mode 100644 contributed_definitions/NXaperture.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXaperture.yaml diff --git a/contributed_definitions/NXaperture.nxdl.xml b/contributed_definitions/NXaperture.nxdl.xml deleted file mode 100644 index 3e4b8dd42c..0000000000 --- a/contributed_definitions/NXaperture.nxdl.xml +++ /dev/null @@ -1,88 +0,0 @@ - - - - - A beamline aperture - - - - 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. - - - - - Absorbing material of the aperture. - - - - - Description of the aperture. - - - - - Shape of the aperture. - - - - - - - - - - - - - - - - - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter - - - - - Specifies the position of the aperture 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 - 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. - - - - - Stores the raw positions of aperture motors. - - - - - Location and shape of the aperture. - - - - - Location and shape of each blade. - - - - - Describes any additional information. - - - diff --git a/contributed_definitions/nyaml/NXaperture.yaml b/contributed_definitions/nyaml/NXaperture.yaml deleted file mode 100644 index 4fea9d7800..0000000000 --- a/contributed_definitions/nyaml/NXaperture.yaml +++ /dev/null @@ -1,55 +0,0 @@ -category: base -doc: | - A beamline aperture - -type: group -(NXobject)NXaperture: - \@default: - doc: | - 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. - material(NX_CHAR): - doc: | - Absorbing material of the aperture. - description(NX_CHAR): - doc: | - Description of the aperture. - shape(NX_CHAR): - doc: | - Shape of the aperture. - enumeration: [straight slit, curved slit, pinhole, circle, square, hexagon, octagon, bladed, open, grid] - size(NX_NUMBER): - unit: NX_LENGTH - doc: | - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter - depends_on(NX_CHAR): - doc: | - Specifies the position of the aperture by pointing to the last transformation in - the transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - 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 - 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. - (NXpositioner): - doc: | - Stores the raw positions of aperture motors. - (NXgeometry): - doc: | - Location and shape of the aperture. - BLADE_GEOMETRY(NXgeometry): - doc: | - Location and shape of each blade. - (NXnote): - doc: | - Describes any additional information. From eb919e02a9205c8fe3ecb754995206f9be4029e3 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 17:42:56 +0200 Subject: [PATCH 132/203] merging and putting NXbeam from contributed to base_classes --- base_classes/NXbeam.nxdl.xml | 369 ++++++++++++++-------- base_classes/nyaml/NXbeam.yaml | 56 +++- contributed_definitions/NXbeam.nxdl.xml | 286 ----------------- contributed_definitions/nyaml/NXbeam.yaml | 242 -------------- 4 files changed, 284 insertions(+), 669 deletions(-) delete mode 100644 contributed_definitions/NXbeam.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXbeam.yaml diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 232a75e46d..28c331fdf6 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -1,14 +1,14 @@ - + - + - These symbols coordinate datasets with the same shape. + These symbols coordinate datasets with the same shape. - Number of scan points. + + Number of scan points. + - Number of channels in the incident beam spectrum, if known + + Number of channels in the incident beam spectrum, if known + - Number of moments representing beam divergence (x, y, xy, etc.) + + Number of moments representing beam divergence (x, y, xy, etc.) + + + + + Number of pixels of the horizontal axis (e.g. delay) of a FROG trace + + + + + Number of pixels of the vertical axis (e.g. frequency) of a FROG trace + - Properties of the neutron or X-ray beam at a given location. - - This group is intended to be referenced - by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. - To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred - by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. - + Properties of the neutron or X-ray beam at a given location. + + This group is intended to be referenced + by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is + especially valuable in storing the results of instrument simulations in which it is useful + to specify the beam profile, time distribution etc. at each beamline component. Otherwise, + its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. + + Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. + To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred + by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. + - Distance from sample. Note, it is recommended to use NXtransformations instead. + + Distance from sample. Note, it is recommended to use NXtransformations instead. + - Energy carried by each particle of the beam on entering the beamline component + + Energy carried by each particle of the beam on entering the beamline component + - Energy carried by each particle of the beam on leaving the beamline component + + Energy carried by each particle of the beam on leaving the beamline component + - Change in particle energy caused by the beamline component + + Change in particle energy caused by the beamline component + - In the case of a monochromatic beam this is the scalar - wavelength. - - Several other use cases are permitted, depending on the - presence or absence of other incident_wavelength_X - fields. - - In the case of a polychromatic beam this is an array of - length **m** of wavelengths, with the relative weights - in ``incident_wavelength_weights``. - - In the case of a monochromatic beam that varies shot- - to-shot, this is an array of wavelengths, one for each - recorded shot. Here, ``incident_wavelength_weights`` and - incident_wavelength_spread are not set. - - In the case of a polychromatic beam that varies shot-to- - shot, this is an array of length **m** with the relative - weights in ``incident_wavelength_weights`` as a 2D array. - - In the case of a polychromatic beam that varies shot-to- - shot and where the channels also vary, this is a 2D array - of dimensions **nP** by **m** (slow to fast) with the - relative weights in ``incident_wavelength_weights`` as a 2D - array. - - Note, :ref:`variants <Design-Variants>` are a good way - to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value wavelength value is - available along with the original spectrum from which it - was calibrated. - Wavelength on entering beamline component + In the case of a monochromatic beam this is the scalar + wavelength. + + Several other use cases are permitted, depending on the + presence or absence of other incident_wavelength_X + fields. + + In the case of a polychromatic beam this is an array of + length **m** of wavelengths, with the relative weights + in ``incident_wavelength_weights``. + + In the case of a monochromatic beam that varies shot- + to-shot, this is an array of wavelengths, one for each + recorded shot. Here, ``incident_wavelength_weights`` and + incident_wavelength_spread are not set. + + In the case of a polychromatic beam that varies shot-to- + shot, this is an array of length **m** with the relative + weights in ``incident_wavelength_weights`` as a 2D array. + + In the case of a polychromatic beam that varies shot-to- + shot and where the channels also vary, this is a 2D array + of dimensions **nP** by **m** (slow to fast) with the + relative weights in ``incident_wavelength_weights`` as a 2D + array. + + Note, :ref:`variants <Design-Variants>` are a good way + to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value wavelength value is + available along with the original spectrum from which it + was calibrated. + Wavelength on entering beamline component - In the case of a polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in ``incident_wavelength``. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **nP** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in ``incident_wavelength``. + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in ``incident_wavelength``. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **nP** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in ``incident_wavelength``. - The wavelength spread FWHM for the corresponding - wavelength(s) in incident_wavelength. - - In the case of shot-to-shot variation in the wavelength - spread, this is a 2D array of dimension **nP** by - **m** (slow to fast) of the spreads of the - corresponding wavelengths in incident_wavelength. + The wavelength spread FWHM for the corresponding + wavelength(s) in incident_wavelength. + + In the case of shot-to-shot variation in the wavelength + spread, this is a 2D array of dimension **nP** by + **m** (slow to fast) of the spreads of the + corresponding wavelengths in incident_wavelength. @@ -139,15 +159,15 @@ - Beam crossfire in degrees parallel to the laboratory X axis - - The dimension **c** is a series of moments of that represent - the standard uncertainty (e.s.d.) of the directions of - of the beam. The first and second moments are in the XZ and YZ - planes around the mean source beam direction, respectively. - - Further moments in **c** characterize co-variance terms, so - the next moment is the product of the first two, and so on. + Beam crossfire in degrees parallel to the laboratory X axis + + The dimension **c** is a series of moments of that represent + the standard uncertainty (e.s.d.) of the directions of + of the beam. The first and second moments are in the XZ and YZ + planes around the mean source beam direction, respectively. + + Further moments in **c** characterize co-variance terms, so + the next moment is the product of the first two, and so on. @@ -156,8 +176,8 @@ - Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM + Size of the beam entering this component. Note this represents + a rectangular beam aperture, and values represent FWHM @@ -165,20 +185,26 @@ - Wavelength on leaving beamline component + + Wavelength on leaving beamline component + - Polarization vector on entering beamline component + + Incident polarization as a Stokes vector on entering beamline component + - Polarization vector on leaving beamline component + + Polarization as Strokes vector on leaving beamline component + @@ -187,25 +213,25 @@ Polarization vector on entering beamline component using Stokes notation - + The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. These are defined with the standard Nexus coordinate frame unless it is overridden by an NXtransformations field pointed to by a depends_on attribute. The last component, describing the circular polarization state, is positive for a right-hand circular state - that is the electric field vector rotates clockwise at the sample and over time when observed from the source. - - I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale + + I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale linearly with the total degree of polarization, and indicate the relative magnitudes of the pure linear and circular orientation contributions. Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). U (S_2) is linearly polarized along the x==y axis (U > 0) or the - -x==y axis (U < 0). - + -x==y axis (U < 0). + V (S_3) is circularly polarized. V > 0 when the electric field vector rotates - clockwise at the sample with respect to time when observed from the source; + clockwise at the sample with respect to time when observed from the source; V < 0 indicates the opposite rotation. @@ -224,112 +250,177 @@ - Wavelength spread FWHM of beam leaving this component + + Wavelength spread FWHM of beam leaving this component + - Divergence FWHM of beam leaving this component + + Divergence FWHM of beam leaving this component + - flux incident on beam plane area + + flux incident on beam plane area + + + + Energy of a single pulse at the diagnostic point + + + + + Average power at the diagnostic point + + + + + Incident fluence at the diagnostic point + + + + Here: SI units are ''J/m2'', customary ''mJ/cm2''. + + + + + + FWHM duration of the pulses at the diagnostic point + + + + + FROG trace of the pulse. + + + + + + + + + Horizontal axis of a FROG trace, i.e. delay. + + + + + + + + Vertical axis of a FROG trace, i.e. frequency. + + + + + + + + The type of chirp implemented + + + + + Group delay dispersion of the pulse for linear chirp + + - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly - useful for simulations which need to store plottable information at each beamline - component. + Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly + useful for simulations which need to store plottable information at each beamline + component. + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - - + - The NeXus coordinate system defines the Z axis to be along the nominal beam - direction. This is the same as the McStas coordinate system (see :ref:Design-CoordinateSystem). - However, the additional transformations needed to represent an altered beam - direction can be provided using this depends_on field that contains the path - to a NXtransformations group. This could represent redirection of the beam, - or a refined beam direction. + The NeXus coordinate system defines the Z axis to be along the nominal beam + direction. This is the same as the McStas coordinate system (see :ref:Design-CoordinateSystem). + However, the additional transformations needed to represent an altered beam + direction can be provided using this depends_on field that contains the path + to a NXtransformations group. This could represent redirection of the beam, + or a refined beam direction. - - Direction (and location) for the beam. The location of the beam can be given by - any point which it passes through as its offset attribute. + Direction (and location) for the beam. The location of the beam can be given by + any point which it passes through as its offset attribute. - + - Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] - and passes through the origin + Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] + and passes through the origin - + - Three values that define the direction of beam vector + Three values that define the direction of beam vector - Three values that define the location of a point through which the beam passes + Three values that define the location of a point through which the beam passes - Points to the path to a field defining the location on which this - depends or the string "." for origin. + Points to the path to a field defining the location on which this + depends or the string "." for origin. - + - Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. - This also defines the parallel and perpendicular components of the beam's polarization. - If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin + Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. + This also defines the parallel and perpendicular components of the beam's polarization. + If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin - + - Three values that define the direction of reference plane normal + Three values that define the direction of reference plane normal - Not required as beam direction offset locates the plane + Not required as beam direction offset locates the plane - Points to the path to a field defining the location on which this - depends or the string "." for origin. + Points to the path to a field defining the location on which this + depends or the string "." for origin. diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml index 5aeef146ae..a1dcb46912 100644 --- a/base_classes/nyaml/NXbeam.yaml +++ b/base_classes/nyaml/NXbeam.yaml @@ -21,6 +21,10 @@ symbols: Number of channels in the incident beam spectrum, if known c: | Number of moments representing beam divergence (x, y, xy, etc.) + nx: | + Number of pixels of the horizontal axis (e.g. delay) of a FROG trace + ny: | + Number of pixels of the vertical axis (e.g. frequency) of a FROG trace type: group NXbeam(NXobject): distance(NX_FLOAT): @@ -139,14 +143,14 @@ NXbeam(NXobject): incident_polarization(NX_NUMBER): unit: NX_ANY doc: | - Polarization vector on entering beamline component + Incident polarization as a Stokes vector on entering beamline component dimensions: rank: 2 dim: [[1, nP], [2, 2]] final_polarization(NX_NUMBER): unit: NX_ANY doc: | - Polarization vector on leaving beamline component + Polarization as Strokes vector on leaving beamline component dimensions: rank: 2 dim: [[1, nP], [2, 2]] @@ -206,6 +210,53 @@ NXbeam(NXobject): dimensions: rank: 1 dim: [[1, nP]] + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy of a single pulse at the diagnostic point + average_power(NX_FLOAT): + unit: NX_POWER + doc: | + Average power at the diagnostic point + fluence(NX_FLOAT): + unit: NX_ANY + doc: | + Incident fluence at the diagnostic point + \@units: + type: NX_CHAR + doc: | + Here':' SI units are ''J/m2'', customary ''mJ/cm2''. + pulse_duration(NX_FLOAT): + unit: NX_TIME + doc: | + FWHM duration of the pulses at the diagnostic point + frog_trace(NX_FLOAT): + doc: | + FROG trace of the pulse. + dimensions: + rank: 2 + dim: [[1, nx], [2, ny]] + frog_delays(NX_FLOAT): + unit: NX_TIME + doc: | + Horizontal axis of a FROG trace, i.e. delay. + dimensions: + rank: 1 + dim: [[1, nx]] + frog_frequencies(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Vertical axis of a FROG trace, i.e. frequency. + dimensions: + rank: 1 + dim: [[1, ny]] + chirp_type(NX_CHAR): + doc: | + The type of chirp implemented + chirp_GDD(NX_FLOAT): + unit: NX_TIME + doc: | + Group delay dispersion of the pulse for linear chirp (NXdata): doc: | Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly @@ -619,3 +670,4 @@ NXbeam(NXobject): # # # + diff --git a/contributed_definitions/NXbeam.nxdl.xml b/contributed_definitions/NXbeam.nxdl.xml deleted file mode 100644 index ffbe10b857..0000000000 --- a/contributed_definitions/NXbeam.nxdl.xml +++ /dev/null @@ -1,286 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of pixels of the horizontal axis (e.g. delay) of a FROG trace - - - - - Number of pixels of the vertical axis (e.g. frequency) of a FROG trace - - - - - Properties of the neutron or X-ray beam at a given location. - - It will be referenced by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. - Note that variables such as the incident energy could be scalar values or arrays. - This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, - time distribution etc. at each beamline component. - Otherwise, its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - - - Distance from sample - - - - - In the case of a monchromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - - - - - - - - The energy spread FWHM for the corresponding energy(ies) in incident_energy. In - the case of shot-to-shot variation in the energy spread, this is a 2D array of - dimension nP by m (slow to fast) of the spreads of the corresponding wavelength - in incident_wavelength. - - - - - In the case of a polychromatic beam this is an array of length m of the relative - weights of the corresponding energies in incident_energy. In the case of a - polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np - by m (slow to fast) of the relative weights of the corresponding energies in - incident_energy. - - - - - Energy on leaving beamline component - - - - - - - - Energy change caused by beamline component - - - - - - - - In the case of a monchromatic beam this is the scalar wavelength. - Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. - - * In the case of a polychromatic beam this is an array of length m of wavelengths, - with the relative weights in incident_wavelength_weights. - * In the case of a monochromatic beam that varies shot-to-shot, - this is an array of wavelengths, one for each recorded shot. - Here, incident_wavelength_weights and incident_wavelength_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, - single-value wavelength value is available along with the original spectrum from which it was calibrated. - - - - - - - - Wavelength spread FWHM on entering component - - - - - - - - Divergence of beam entering this component - - - - - - - - - Size of the beam entering this component - - - - - - - - - Wavelength on leaving beamline component - - - - - - - - Incident polarization as a Stokes vector - - - - - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. - Correct parsing can still be implemented by using this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: 'T' for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: 'farad' for capacitance). - * A string describing the units according to unidata unit operation notation, - if the unit is a complex combination of named units and does not have a name. - - Example: for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. - Here: SI units are 'V2/m2'. - - - - - - Polarization as Stokes vector on leaving beamline component - - - - - - - Here: SI units are 'V2/m2'. - - - - - - Wavelength spread FWHM of beam leaving this component - - - - - - - - Divergence FWHM of beam leaving this component - - - - - - - - - flux incident on beam plane area - - - - - - - - Energy of a single pulse at the diagnostic point - - - - - Average power at the diagnostic point - - - - - Incident fluence at the diagnostic point - - - - Here: SI units are ''J/m2'', customary ''mJ/cm2''. - - - - - - FWHM duration of the pulses at the diagnostic point - - - - - FROG trace of the pulse. - - - - - - - - - Horizontal axis of a FROG trace, i.e. delay. - - - - - - - - Vertical axis of a FROG trace, i.e. frequency. - - - - - - - - The type of chirp implemented - - - - - Group delay dispersion of the pulse for linear chirp - - - - - Distribution of beam with respect to relevant variable e.g. wavelength. This is - mainly useful for simulations which need to store plottable information at each - beamline component. - - - - - .. 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/nyaml/NXbeam.yaml b/contributed_definitions/nyaml/NXbeam.yaml deleted file mode 100644 index e7a51cdc81..0000000000 --- a/contributed_definitions/nyaml/NXbeam.yaml +++ /dev/null @@ -1,242 +0,0 @@ -category: base -doc: | - Properties of the neutron or X-ray beam at a given location. - - It will be referenced by beamline component groups within the ':'ref':'`NXinstrument` group or by the ':'ref':'`NXsample` group. - Note that variables such as the incident energy could be scalar values or arrays. - This group is especially valuable in storing the results of instrument simulations in which it is useful to specify the beam profile, - time distribution etc. at each beamline component. - Otherwise, its most likely use is in the ':'ref':'`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays - - nx: | - Number of pixels of the horizontal axis (e.g. delay) of a FROG trace - - ny: | - Number of pixels of the vertical axis (e.g. frequency) of a FROG trace - -type: group -(NXobject)NXbeam: - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance from sample - incident_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - In the case of a monchromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - dimensions: - rank: 1 - dim: [[1, i]] - incident_energy_spread(NX_NUMBER): - unit: NX_ENERGY - doc: | - The energy spread FWHM for the corresponding energy(ies) in incident_energy. In - the case of shot-to-shot variation in the energy spread, this is a 2D array of - dimension nP by m (slow to fast) of the spreads of the corresponding wavelength - in incident_wavelength. - incident_energy_weights(NX_NUMBER): - unit: NX_ENERGY - doc: | - In the case of a polychromatic beam this is an array of length m of the relative - weights of the corresponding energies in incident_energy. In the case of a - polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np - by m (slow to fast) of the relative weights of the corresponding energies in - incident_energy. - final_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy on leaving beamline component - dimensions: - rank: 1 - dim: [[1, i]] - energy_transfer(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy change caused by beamline component - dimensions: - rank: 1 - dim: [[1, i]] - incident_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - In the case of a monchromatic beam this is the scalar wavelength. - Several other use cases are permitted, depending on the presence of other incident_wavelength_X fields. - - * In the case of a polychromatic beam this is an array of length m of wavelengths, - with the relative weights in incident_wavelength_weights. - * In the case of a monochromatic beam that varies shot-to-shot, - this is an array of wavelengths, one for each recorded shot. - Here, incident_wavelength_weights and incident_wavelength_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, - single-value wavelength value is available along with the original spectrum from which it was calibrated. - dimensions: - rank: 1 - dim: [[1, i]] - incident_wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Wavelength spread FWHM on entering component - dimensions: - rank: 1 - dim: [[1, i]] - incident_beam_divergence(NX_FLOAT): - unit: NX_ANGLE - doc: | - Divergence of beam entering this component - dimensions: - rank: 2 - dim: [[1, 2], [2, j]] - extent(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of the beam entering this component - dimensions: - rank: 2 - dim: [[1, 2], [2, j]] - final_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Wavelength on leaving beamline component - dimensions: - rank: 1 - dim: [[1, i]] - incident_polarization(NX_FLOAT): - unit: NX_ANY - doc: | - Incident polarization as a Stokes vector - dimensions: - rank: 1 - dim: [[1, 4]] - \@units: - type: NX_CHAR - doc: | - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user by using 'NX_ANY'. - Correct parsing can still be implemented by using this attribute. - - | Fill with':' - - * The unit unidata symbol if the unit has one (Example':' 'T' for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example':' 'farad' for capacitance). - * A string describing the units according to unidata unit operation notation, - if the unit is a complex combination of named units and does not have a name. - - Example':' for lightsource brilliance (SI) '1/(s.mm2.mrad2)'. - Here':' SI units are 'V2/m2'. - final_polarization(NX_FLOAT): - unit: NX_ANY - doc: | - Polarization as Stokes vector on leaving beamline component - dimensions: - rank: 1 - dim: [[1, 4]] - \@units: - type: NX_CHAR - doc: | - Here':' SI units are 'V2/m2'. - final_wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Wavelength spread FWHM of beam leaving this component - dimensions: - rank: 1 - dim: [[1, i]] - final_beam_divergence(NX_FLOAT): - unit: NX_ANGLE - doc: | - Divergence FWHM of beam leaving this component - dimensions: - rank: 2 - dim: [[1, 2], [2, j]] - flux(NX_FLOAT): - unit: NX_FLUX - doc: | - flux incident on beam plane area - dimensions: - rank: 1 - dim: [[1, i]] - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy of a single pulse at the diagnostic point - average_power(NX_FLOAT): - unit: NX_POWER - doc: | - Average power at the diagnostic point - fluence(NX_FLOAT): - unit: NX_ANY - doc: | - Incident fluence at the diagnostic point - \@units: - type: NX_CHAR - doc: | - Here':' SI units are ''J/m2'', customary ''mJ/cm2''. - pulse_duration(NX_FLOAT): - unit: NX_TIME - doc: | - FWHM duration of the pulses at the diagnostic point - frog_trace(NX_FLOAT): - doc: | - FROG trace of the pulse. - dimensions: - rank: 2 - dim: [[1, nx], [2, ny]] - frog_delays(NX_FLOAT): - unit: NX_TIME - doc: | - Horizontal axis of a FROG trace, i.e. delay. - dimensions: - rank: 1 - dim: [[1, nx]] - frog_frequencies(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Vertical axis of a FROG trace, i.e. frequency. - dimensions: - rank: 1 - dim: [[1, ny]] - chirp_type(NX_CHAR): - doc: | - The type of chirp implemented - chirp_GDD(NX_FLOAT): - unit: NX_TIME - doc: | - Group delay dispersion of the pulse for linear chirp - (NXdata): - doc: | - Distribution of beam with respect to relevant variable e.g. wavelength. This is - mainly useful for simulations which need to store plottable information at each - beamline component. - \@default: - doc: | - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. From d217acaf109f2890f904a2ef87034ed5f6051faa Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 20:48:51 +0200 Subject: [PATCH 133/203] merging and putting NXdetector from contributed to base_classes --- base_classes/NXdetector.nxdl.xml | 1913 +++++++++-------- base_classes/nyaml/NXdetector.yaml | 67 +- contributed_definitions/NXdetector.nxdl.xml | 801 ------- contributed_definitions/nyaml/NXdetector.yaml | 589 ----- 4 files changed, 1035 insertions(+), 2335 deletions(-) delete mode 100644 contributed_definitions/NXdetector.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXdetector.yaml diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index a6bb0b8c68..cb017217b2 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -1,14 +1,14 @@ - + - - - - - These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the - preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering principle is slowest to fastest. - The type of each dimension should follow the order of scan points, detector output (e.g. pixels), - then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited - to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced - by a detector at each trigger. - - - number of scan points (only present in scanning measurements) - number of detector pixels in the first (slowest) direction - number of detector pixels in the second (faster) direction - number of bins in the time-of-flight histogram - - - - A detector, detector bank, or multidetector. - - - - Total time of flight - - - - - - - - - - - - - - - - - - - Total time of flight - - - - - In DAQ clock pulses - - - - - - - Clock frequency in Hz - - - - - - Identifier for detector (pixels) - Can be multidimensional, if needed - - - - - - Data values from the detector. The rank and dimension ordering should follow a principle of - slowest to fastest measurement axes and may be explicitly specified in application definitions. - - Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be - the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions - of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single - scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. - Repetition of an experiment in a time series tends to be used similar to a slow scan axis - and so will often be in the first dimension of the data array. - - The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions - (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an - imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data - will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to - be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. - - Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift - detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. - - The type of each dimension should should follow the order of scan points, detector pixels, - then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) - shown here are merely illustrative of coordination between related datasets. - - - - - - - - - - - Title of measurement - - - - Integral of data as check of data integrity - - - - - - - The best estimate of the uncertainty in the data value (array size should match the data field). Where - possible, this should be the standard deviation, which has the same units - as the data. The form data_error is deprecated. - - - - - - - - - - - - - - Offset from the detector center in x-direction. - Can be multidimensional when needed. - - - - - - - - - - - - - - - - - - - - - x-axis offset from detector center - - - - - - Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - - Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - This is the distance to the previous component in the - instrument; most often the sample. The usage depends on the - nature of the detector: Most often it is the distance of the - detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - - - This is the polar angle of the detector towards the previous - component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the polar_angle of the detector assembly. - But there are irregular detectors. - In this - case, the polar_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - - - This is the azimuthal angle angle of the detector towards - the previous component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the azimuthal_angle of the detector assembly. - But there are irregular detectors. - In this - case, the azimuthal_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - - name/manufacturer/model/etc. information - - - - Serial number for the detector - - - - Local name for the detector - - - - Position and orientation of detector - - - - Solid angle subtended by the detector at the sample - - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size. - - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size - - - - - - - - - Detector dead time - - - - - - - - - - Detector gas pressure - - - - - - - - - maximum drift space dimension - - - - Crate number of detector - - - - - - - - Equivalent local term - - - - - Slot number of detector - - - - - - - - Equivalent local term - - - - - Input number of detector - - - - - - - - Equivalent local term - - - - - - Description of type such as He3 gas cylinder, He3 PSD, scintillator, - fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ... - - - - - Spectral efficiency of detector with respect to e.g. wavelength - - - - - - - - - - - - - - - - - - - - - - - - efficiency of the detector - - - - - - - - - - This field can be two things: - - #. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - #. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - - - - - - - - - - - - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - - - - - - - - - - start time for each frame, with the ``start`` attribute as absolute reference - - - - - - - stop time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - date of last calibration (geometry and/or efficiency) measurements - - - - - - summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations - - - - - How the detector is represented - - - - - - - - - - Elapsed actual counting time - - - - - - - - - - - Use this group to provide other data related to this NXdetector group. - - - - - - In order to properly sort the order of the images taken in (for - example) a tomography experiment, a sequence number is stored with each - image. - - - - - - - - - - This is the x position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - - This is the y position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - - This is the start number of the first frame of a scan. In protein crystallography measurements one - often scans a couple of frames on a give sample, then does something else, - then returns to the same sample and scans some more frames. Each time with - a new data file. This number helps concatenating such measurements. - - - - - The diameter of a cylindrical detector - - - - The acquisition mode of the detector. - - - - - - - - - - - - True when the angular calibration has been applied in the - electronics, false otherwise. - - - - Angular calibration data. - - - - - - - - True when the flat field correction has been applied in the - electronics, false otherwise. - - - - Flat field correction data. - - - - - - - - Errors of the flat field correction data. - The form flatfield_error is deprecated. - - - - - - - - - True when the pixel mask correction has been applied in the - electronics, false otherwise. - - - - - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - - - - - - - - - - This field allow to distinguish different types of exposure to the same detector "data" field. - Some techniques require frequent (re-)calibration inbetween measuremnts and this way of - recording the different measurements preserves the chronological order with is important for - correct processing. - - This is used for example in tomography (`:ref:`NXtomo`) sample projections, - dark and flat images, a magic number is recorded per frame. - - The key is as follows: - - * projection (sample) = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - * background (no sample, but buffer where applicable) = 4 - - In cases where the data is of type :ref:`NXlog` this can also be an NXlog. - - - - - - - - - Counting detectors usually are not able to measure all incoming particles, - especially at higher count-rates. Count-rate correction is applied to - account for these errors. - - True when count-rate correction has been applied, false otherwise. - - - - - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - - - - - - - - True when virtual pixel interpolation has been applied, false otherwise. - - When virtual pixel interpolation is applied, values of some pixels may - contain interpolated values. For example, to account for space between - readout chips on a module, physical pixels on edges and corners between - chips may have larger sensor areas and counts may be distributed between - their logical pixels. - - - - - How many bits the electronics reads per pixel. - With CCD's and single photon counting detectors, - this must not align with traditional integer sizes. - This can be 4, 8, 12, 14, 16, ... - - - - - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set delay.. - This is important to know for time resolved experiments. - - - - - User-specified trigger delay. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector hardware after receiving the - trigger signal to when the detector starts to acquire the exposure. - It forms the lower boundary of the trigger_delay_time when the user - does not request an additional delay. - - - - - Time during which no new trigger signal can be accepted. - Typically this is the - trigger_delay_time + exposure_time + readout_time. - This is important to know for time resolved experiments. - - - - - This is time for each frame. This is exposure_time + readout time. - - - - - - - - The gain setting of the detector. This is a detector-specific value - meant to document the gain setting of the detector during data - collection, for detectors with multiple available gain settings. - - Examples of gain settings include: - - * ``standard`` - * ``fast`` - * ``auto`` - * ``high`` - * ``medium`` - * ``low`` - * ``mixed high to medium`` - * ``mixed medium to low`` - - Developers are encouraged to use one of these terms, or to submit - additional terms to add to the list. - - - - - The value at which the detector goes into saturation. - Especially common to CCD detectors, the data - is known to be invalid above this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - The lowest value at which pixels for this detector would be reasonably - measured. The data is known to be invalid below this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - CCD images are sometimes constructed by summing - together multiple short exposures in the - electronics. This reduces background etc. - This is the number of short exposures used to sum - images for an image. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the name of this converter material. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the thickness of this converter material. - - - - - Single photon counter detectors can be adjusted - for a certain energy range in which they - work optimally. This is the energy setting for this. - - - - - For use in special cases where the data in NXdetector - is represented in several parts, each with a separate geometry. - - - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape. - + + + + These symbols will be used below to illustrate the coordination of the + rank and sizes of datasets and the preferred ordering of the + dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering + principle is slowest to fastest. The type of each dimension should + follow the order of scan points, detector output (e.g. pixels), then + time-of-flight (i.e. spectroscopy, spectrometry). Note that the output + of a detector is not limited to single values (0D), lists (1D) and + images (2), but three or higher dimensional arrays can be produced by + a detector at each trigger. + + + + number of scan points (only present in scanning measurements) + + + + + number of detector pixels in the first (slowest) direction + + + + + number of detector pixels in the second (faster) direction + + + + + number of detector pixels in the third (if necessary, fastest) + direction + + + + + number of bins in the time-of-flight histogram + + + + + A detector, detector bank, or multidetector. + + + + Total time of flight + + + + + + + + + + + + + + + + + Total time of flight + + + + + + In DAQ clock pulses + + + + + + + Clock frequency in Hz + + + + + + Identifier for detector (pixels) + Can be multidimensional, if needed + + + + + Data values from the detector. The rank and dimension ordering should follow a principle of + slowest to fastest measurement axes and may be explicitly specified in application definitions. + + Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be + the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions + of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single + scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. + Repetition of an experiment in a time series tends to be used similar to a slow scan axis + and so will often be in the first dimension of the data array. + + The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions + (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an + imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data + will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to + be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. + + Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift + detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. + + The type of each dimension should should follow the order of scan points, detector pixels, + then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) + shown here are merely illustrative of coordination between related datasets. + + + + + + + + + + Title of measurement + + + + + Integral of data as check of data integrity + + + + + + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + + + + + + + + + + + Offset from the detector center in x-direction. + Can be multidimensional when needed. + + + + + + + + + + + + + + + + + + x-axis offset from detector center + + + + + + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + name/manufacturer/model/etc. information + + + + + Serial number for the detector + + + + + Local name for the detector + + + + + Position and orientation of detector + + + + + Solid angle subtended by the detector at the sample + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size. + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size + + + + + + + + + Detector dead time + + + + + + + + + + Detector gas pressure + + + + + + + + + maximum drift space dimension + + + + + Crate number of detector + + + + + + + + Equivalent local term + + + + + + Slot number of detector + + + + + + + + Equivalent local term + + + + + + Input number of detector + + + + + + + + Equivalent local term + + + + + + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + + + + + Spectral efficiency of detector with respect to e.g. wavelength + + + + + + + + + + + + + + + + + + + + + + + + + efficiency of the detector + + + + + + + + + + This field can be two things: + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + + + + + + + + + + + + + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + + + + + + + + + + start time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + stop time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + date of last calibration (geometry and/or efficiency) measurements + + + + + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders. - + + + How the detector is represented + + + + + + + + + + Elapsed actual counting time + + + + + + + + + Use this group to provide other data related to this NXdetector group. + - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape. - + + + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + + + + + + + + This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + + + + + The diameter of a cylindrical detector + + + + + The acquisition mode of the detector. + + + + + + + + + + + + + True when the angular calibration has been applied in the + electronics, false otherwise. + + + + + Angular calibration data. + + + + + + + + + True when the flat field correction has been applied in the + electronics, false otherwise. + + + + + Flat field correction data. + + + + + + + + + Errors of the flat field correction data. + The form flatfield_error is deprecated. + + + + + + + + + True when the pixel mask correction has been applied in the + electronics, false otherwise. + + + + + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + + + + + + + + + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + + + + + + + + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + + + + + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + + + + + + + + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + + + + + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + + + + + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + + + + + User-specified trigger delay. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + + + + + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + + + + + This is time for each frame. This is exposure_time + readout time. + + + + + + + + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + + + + + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. + + + + + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + + + + + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + + + + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + + + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + + + + + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + + + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + + + + + + .. 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. + + + + + Type of electron amplifier, MCP, channeltron, etc. + + + + + Description of the detector type, DLD, Phosphor+CCD, CMOS. + + + + + Voltage applied to detector. + + + + + Voltage applied to the amplifier. + + + + + The low voltage of the amplifier migh not be the ground. + + + + + Size of each imaging sensor chip on the detector. + + + + + Number of imaging sensor chips on the detector. + + + + + Physical size of the pixels of the imaging chip on the detector. + + + + + Number of raw active elements in each dimension. Important for swept scans. + + + + + raw data output from the detector + - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders. - + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + - - - - .. 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. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the detector is the center of the first pixel. - In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml index ae8735680e..6e01f8adc6 100644 --- a/base_classes/nyaml/NXdetector.yaml +++ b/base_classes/nyaml/NXdetector.yaml @@ -16,6 +16,9 @@ symbols: number of detector pixels in the first (slowest) direction j: | number of detector pixels in the second (faster) direction + k: | + number of detector pixels in the third (if necessary, fastest) + direction tof: | number of bins in the time-of-flight histogram type: group @@ -29,12 +32,12 @@ type: group dim: [[1, tof+1]] \@axis: type: NX_POSINT - deprecated: + deprecated: | see: https://github.com/nexusformat/definitions/issues/436 enumeration: [3] \@primary: type: NX_POSINT - deprecated: + deprecated: | see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: @@ -109,12 +112,12 @@ type: group dim: [[1, i], [2, j]] \@axis: type: NX_POSINT - deprecated: + deprecated: | see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@primary: type: NX_POSINT - deprecated: + deprecated: | see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: @@ -130,12 +133,12 @@ type: group dim: [[1, i], [2, j]] \@axis: type: NX_POSINT - deprecated: + deprecated: | see: https://github.com/nexusformat/definitions/issues/436 enumeration: [2] \@primary: type: NX_POSINT - deprecated: + deprecated: | see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: @@ -151,12 +154,12 @@ type: group dim: [[1, i], [2, j]] \@axis: type: NX_POSINT - deprecated: + deprecated: | see: https://github.com/nexusformat/definitions/issues/436 enumeration: [3] \@primary: type: NX_POSINT - deprecated: + deprecated: | see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: @@ -310,8 +313,8 @@ type: group doc: | efficiency of the detector dimensions: - rank: 2 - dim: [[1, i], [2, j]] + rank: 3 + dim: [[1, i], [2, j], [3, k]] wavelength(NX_FLOAT): unit: NX_WAVELENGTH doc: | @@ -327,8 +330,8 @@ type: group In this use case, the efficiency and wavelength arrays must have the same dimensionality. dimensions: - rank: 2 - dim: [[1, i], [2, j]] + rank: 3 + dim: [[1, i], [2, j], [3, k]] real_time(NX_NUMBER): unit: NX_TIME doc: | @@ -390,7 +393,7 @@ type: group image. dimensions: rank: 1 - dim: [[1, nP]] + dim: [[1, nBrightFrames]] beam_center_x(NX_FLOAT): unit: NX_LENGTH doc: | @@ -690,6 +693,43 @@ type: group 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. + amplifier_type(NX_CHAR): + doc: | + Type of electron amplifier, MCP, channeltron, etc. + detector_type(NX_CHAR): + doc: | + Description of the detector type, DLD, Phosphor+CCD, CMOS. + detector_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to detector. + amplifier_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the amplifier. + amplifier_bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + The low voltage of the amplifier migh not be the ground. + sensor_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each imaging sensor chip on the detector. + sensor_count(NX_INT): + unit: NX_UNITLESS + doc: | + Number of imaging sensor chips on the detector. + sensor_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Physical size of the pixels of the imaging chip on the detector. + sensor_pixels(NX_INT): + unit: NX_UNITLESS + doc: | + Number of raw active elements in each dimension. Important for swept scans. + (NXdata): + doc: | + raw data output from the detector depends_on(NX_CHAR): doc: | NeXus positions components by applying a set of translations and rotations @@ -1665,3 +1705,4 @@ type: group # # # + diff --git a/contributed_definitions/NXdetector.nxdl.xml b/contributed_definitions/NXdetector.nxdl.xml deleted file mode 100644 index d5df7c8c66..0000000000 --- a/contributed_definitions/NXdetector.nxdl.xml +++ /dev/null @@ -1,801 +0,0 @@ - - - - - - These symbols will be used below to coordinate datasets with the same - shape. - - - - number of scan points (only present in scanning measurements) - - - - - number of detector pixels in the first (slowest) direction - - - - - number of detector pixels in the second (faster) direction - - - - - number of detector pixels in the third (if necessary, fastest) - direction - - - - - number of bins in the time-of-flight histogram - - - - - A detector, detector bank, or multidetector. - - - - Total time of flight - - - - - - - - - - - - - - - - - Total time of flight - - - - - - In DAQ clock pulses - - - - - - - Clock frequency in Hz - - - - - - Identifier for detector (pixels) Can be multidimensional, if needed - - - - - Data values from the detector. - - - - - - - - - - Title of measurement - - - - - Integral of data as check of data integrity - - - - - - The best estimate of the uncertainty in the data value. Where possible, this - should be the standard deviation, which has the same units as the data. The form - data_error is deprecated. - - - - - - - - - - - Offset from the detector center in x-direction. Can be multidimensional when - needed. - - - - - - - - - - - - - - x-axis offset from detector center - - - - - - Offset from the detector center in the y-direction. Can be multidimensional when - different values are required for each pixel. - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - Offset from the detector center in the z-direction. Can be multidimensional when - different values are required for each pixel. - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - This is the distance to the previous component in the instrument; most often the - sample. The usage depends on the nature of the detector: Most often it is the - distance of the detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - - - - - - - - - This is the polar angle of the detector towards the previous component in the - instrument; most often the sample. The usage depends on the nature of the - detector. Most often it is the polar_angle of the detector assembly. But there - are irregular detectors. In this case, the polar_angle must be specified for - each detector pixel. - - - - - - - - - - This is the azimuthal angle angle of the detector towards the previous component - in the instrument; most often the sample. The usage depends on the nature of the - detector. Most often it is the azimuthal_angle of the detector assembly. But - there are irregular detectors. In this case, the azimuthal_angle must be - specified for each detector pixel. - - - - - - - - - - name/manufacturer/model/etc. information - - - - - Serial number for the detector - - - - - Local name for the detector - - - - - Position and orientation of detector - - - - - Solid angle subtended by the detector at the sample - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size. - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size - - - - - - - - - Detector dead time - - - - - - - - - - Detector gas pressure - - - - - - - - - maximum drift space dimension - - - - - Crate number of detector - - - - - - - - Equivalent local term - - - - - - Slot number of detector - - - - - - - - Equivalent local term - - - - - - Input number of detector - - - - - - - - Equivalent local term - - - - - - Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission - chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, ... - - - - - Spectral efficiency of detector with respect to e.g. wavelength - - - - - - - - - - - - - - - - - - - - - - - efficiency of the detector - - - - - - - - - - This field can be two things: - - #. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - #. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - - - - - - - - - - - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - - - - - - - - - - Start time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - stop time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - date of last calibration (geometry and/or efficiency) measurements - - - - - summary of conversion of array data to pixels (e.g. polynomial approximations) - and location of details of the calibrations - - - - - How the detector is represented - - - - - - - - - - Elapsed actual counting time - - - - - - - - - Use this group to provide other data related to this NXdetector group. - - - - - In order to properly sort the order of the images taken in (for example) a - tomography experiment, a sequence number is stored with each image. - - - - - - - - This is the x position where the direct beam would hit the detector. This is a - length and can be outside of the actual detector. The length can be in physical - units or pixels as documented by the units attribute. - - - - - This is the y position where the direct beam would hit the detector. This is a - length and can be outside of the actual detector. The length can be in physical - units or pixels as documented by the units attribute. - - - - - This is the start number of the first frame of a scan. In PX one often scans a - couple of frames on a give sample, then does something else, then returns to the - same sample and scans some more frames. Each time with a new data file. This - number helps concatenating such measurements. - - - - - The diameter of a cylindrical detector - - - - - The acquisition mode of the detector. - - - - - - - - - - - - - True when the angular calibration has been applied in the electronics, false - otherwise. - - - - - Angular calibration data. - - - - - - - - - True when the flat field correction has been applied in the electronics, false - otherwise. - - - - - Flat field correction data. - - - - - - - - - Errors of the flat field correction data. The form flatfield_error is - deprecated. - - - - - - - - - True when the pixel mask correction has been applied in the electronics, false - otherwise. - - - - - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - - - - - - - - - True when a count-rate correction has already been applied in the electronics, - false otherwise. - - - - - How many bits the electronics reads per pixel. With CCD's and single photon - counting detectors, this must not align with traditional integer sizes. This can - be 4, 8, 12, 14, 16, ... - - - - - Time it takes to read the detector (typically milliseconds). This is important - to know for time resolved experiments. - - - - - Time it takes to start exposure after a trigger signal has been received. This - is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set - delay.. This is important to know for time resolved experiments. - - - - - User-specified trigger delay. - - - - - Time it takes to start exposure after a trigger signal has been received. This - is the reaction time of the detector hardware after receiving the trigger signal - to when the detector starts to acquire the exposure. It forms the lower boundary - of the trigger_delay_time when the user does not request an additional delay. - - - - - Time during which no new trigger signal can be accepted. Typically this is the - trigger_delay_time + exposure_time + readout_time. This is important to know for - time resolved experiments. - - - - - This is time for each frame. This is exposure_time + readout time. - - - - - - - - The gain setting of the detector. This influences background etc. - - - - - - - - - - - The value at which the detector goes into saturation. Especially common to CCD - detectors, the data is known to be invalid above this value. For example, given - a saturation_value and an underload_value, the valid pixels are those less than - or equal to the saturation_value and greater than or equal to the - underload_value. - - - - - The lowest value at which pixels for this detector would be reasonably measured. - The data is known to be invalid below this value. For example, given a - saturation_value and an underload_value, the valid pixels are those less than or - equal to the saturation_value and greater than or equal to the underload_value. - - - - - CCD images are sometimes constructed by summing together multiple short - exposures in the electronics. This reduces background etc. This is the number of - short exposures used to sum images for an image. - - - - - At times, radiation is not directly sensed by the detector. Rather, the detector - might sense the output from some converter like a scintillator. This is the name - of this converter material. - - - - - At times, radiation is not directly sensed by the detector. Rather, the detector - might sense the output from some converter like a scintillator. This is the - thickness of this converter material. - - - - - Single photon counter detectors can be adjusted for a certain energy range in - which they work optimally. This is the energy setting for this. - - - - - For use in special cases where the data in NXdetector is represented in several - parts, each with a separate geometry. Use one or more instances of the - NXdetector_module group to declare regions of interest or some other subdivision - of a detector. - - - - Shape description of the whole detector. Use only if pixels in the detector are - not of uniform shape. - - - - - Shape description of the whole detector. Use only if pixels in the detector are - not of uniform shape and require being described by cylinders. - - - - - - .. 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. - - - - - Type of electron amplifier, MCP, channeltron, etc. - - - - - Description of the detector type, DLD, Phosphor+CCD, CMOS. - - - - - Voltage applied to detector. - - - - - Voltage applied to the amplifier. - - - - - The low voltage of the amplifier migh not be the ground. - - - - - Size of each imaging sensor chip on the detector. - - - - - Number of imaging sensor chips on the detector. - - - - - Physical size of the pixels of the imaging chip on the detector. - - - - - Number of raw active elements in each dimension. Important for swept scans. - - - - - raw data output from the detector - - - diff --git a/contributed_definitions/nyaml/NXdetector.yaml b/contributed_definitions/nyaml/NXdetector.yaml deleted file mode 100644 index 6fefa6bfb3..0000000000 --- a/contributed_definitions/nyaml/NXdetector.yaml +++ /dev/null @@ -1,589 +0,0 @@ -category: base -doc: | - A detector, detector bank, or multidetector. - -symbols: - doc: | - These symbols will be used below to coordinate datasets with the same - shape. - - np: | - number of scan points (only present in scanning measurements) - - i: | - number of detector pixels in the first (slowest) direction - - j: | - number of detector pixels in the second (faster) direction - - k: | - number of detector pixels in the third (if necessary, fastest) - direction - - tof: | - number of bins in the time-of-flight histogram - -type: group -(NXobject)NXdetector: - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - doc: | - Total time of flight - dimensions: - rank: 1 - dim: [[1, tof+1]] - \@axis: - type: NX_CHAR - enumeration: [3] - \@primary: - type: NX_CHAR - enumeration: [1] - \@long_name: - type: NX_CHAR - doc: | - Total time of flight - raw_time_of_flight(NX_INT): - unit: NX_PULSES - doc: | - In DAQ clock pulses - dimensions: - rank: 1 - dim: [[1, tof+1]] - \@frequency: - type: NX_CHAR - doc: | - Clock frequency in Hz - detector_number(NX_INT): - doc: | - Identifier for detector (pixels) Can be multidimensional, if needed - data(NX_NUMBER): - unit: NX_ANY - doc: | - Data values from the detector. - dimensions: - rank: 4 - dim: [[1, np], [2, i], [3, j], [4, tof]] - \@long_name: - type: NX_CHAR - doc: | - Title of measurement - \@check_sum: - type: NX_CHAR - doc: | - Integral of data as check of data integrity - data_errors(NX_NUMBER): - unit: NX_ANY - doc: | - The best estimate of the uncertainty in the data value. Where possible, this - should be the standard deviation, which has the same units as the data. The form - data_error is deprecated. - dimensions: - rank: 4 - dim: [[1, np], [2, i], [3, j], [4, tof]] - x_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in x-direction. Can be multidimensional when - needed. - \@axis: - type: NX_CHAR - enumeration: [1] - \@primary: - type: NX_CHAR - enumeration: [1] - \@long_name: - type: NX_CHAR - doc: | - x-axis offset from detector center - y_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in the y-direction. Can be multidimensional when - different values are required for each pixel. - \@axis: - type: NX_CHAR - enumeration: [2] - \@primary: - type: NX_CHAR - enumeration: [1] - \@long_name: - type: NX_CHAR - doc: | - y-axis offset from detector center - z_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in the z-direction. Can be multidimensional when - different values are required for each pixel. - \@axis: - type: NX_CHAR - enumeration: [3] - \@primary: - type: NX_CHAR - enumeration: [1] - \@long_name: - type: NX_CHAR - doc: | - y-axis offset from detector center - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the distance to the previous component in the instrument; most often the - sample. The usage depends on the nature of the detector':' Most often it is the - distance of the detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - dimensions: - rank: 3 - dim: [[1, np], [2, i], [3, j]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - This is the polar angle of the detector towards the previous component in the - instrument; most often the sample. The usage depends on the nature of the - detector. Most often it is the polar_angle of the detector assembly. But there - are irregular detectors. In this case, the polar_angle must be specified for - each detector pixel. - dimensions: - rank: 3 - dim: [[1, np], [2, i], [3, j]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - This is the azimuthal angle angle of the detector towards the previous component - in the instrument; most often the sample. The usage depends on the nature of the - detector. Most often it is the azimuthal_angle of the detector assembly. But - there are irregular detectors. In this case, the azimuthal_angle must be - specified for each detector pixel. - dimensions: - rank: 3 - dim: [[1, np], [2, i], [3, j]] - description(NX_CHAR): - doc: | - name/manufacturer/model/etc. information - serial_number(NX_CHAR): - doc: | - Serial number for the detector - local_name(NX_CHAR): - doc: | - Local name for the detector - (NXgeometry): - doc: | - Position and orientation of detector - solid_angle(NX_FLOAT): - unit: NX_SOLID_ANGLE - doc: | - Solid angle subtended by the detector at the sample - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - dead_time(NX_FLOAT): - unit: NX_TIME - doc: | - Detector dead time - dimensions: - rank: 3 - dim: [[1, np], [2, i], [3, j]] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Detector gas pressure - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - detection_gas_path(NX_FLOAT): - unit: NX_LENGTH - doc: | - maximum drift space dimension - crate(NX_INT): - doc: | - Crate number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - type: NX_CHAR - doc: | - Equivalent local term - slot(NX_INT): - doc: | - Slot number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - type: NX_CHAR - doc: | - Equivalent local term - input(NX_INT): - doc: | - Input number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - type: NX_CHAR - doc: | - Equivalent local term - type(NX_CHAR): - doc: | - Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission - chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, ... - efficiency(NXdata): - doc: | - Spectral efficiency of detector with respect to e.g. wavelength - \@signal: - enumeration: [efficiency] - \@axes: - enumeration: [., . ., . . ., . . . ., wavelength] - \@wavelength_indices: - enumeration: [0] - efficiency(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - efficiency of the detector - dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - This field can be two things':' - - #. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - #. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] - real_time(NX_NUMBER): - unit: NX_TIME - doc: | - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - dimensions: - rank: 3 - dim: [[1, np], [2, i], [3, j]] - start_time(NX_FLOAT): - unit: NX_TIME - doc: | - Start time for each frame, with the ``start`` attribute as absolute reference - dimensions: - rank: 1 - dim: [[1, np]] - \@start: - type: NX_CHAR - stop_time(NX_FLOAT): - unit: NX_TIME - doc: | - stop time for each frame, with the ``start`` attribute as absolute reference - dimensions: - rank: 1 - dim: [[1, np]] - \@start: - type: NX_CHAR - calibration_date(NX_DATE_TIME): - doc: | - date of last calibration (geometry and/or efficiency) measurements - calibration_method(NXnote): - doc: | - summary of conversion of array data to pixels (e.g. polynomial approximations) - and location of details of the calibrations - layout(NX_CHAR): - doc: | - How the detector is represented - enumeration: [point, linear, area] - count_time(NX_NUMBER): - unit: NX_TIME - doc: | - Elapsed actual counting time - dimensions: - rank: 1 - dim: [[1, np]] - data_file(NXnote): - (NXcollection): - doc: | - Use this group to provide other data related to this NXdetector group. - sequence_number(NX_INT): - doc: | - In order to properly sort the order of the images taken in (for example) a - tomography experiment, a sequence number is stored with each image. - dimensions: - rank: 1 - dim: [[1, nBrightFrames]] - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the x position where the direct beam would hit the detector. This is a - length and can be outside of the actual detector. The length can be in physical - units or pixels as documented by the units attribute. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the y position where the direct beam would hit the detector. This is a - length and can be outside of the actual detector. The length can be in physical - units or pixels as documented by the units attribute. - frame_start_number(NX_INT): - doc: | - This is the start number of the first frame of a scan. In PX one often scans a - couple of frames on a give sample, then does something else, then returns to the - same sample and scans some more frames. Each time with a new data file. This - number helps concatenating such measurements. - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - The diameter of a cylindrical detector - acquisition_mode(NX_CHAR): - doc: | - The acquisition mode of the detector. - enumeration: [gated, triggered, summed, event, histogrammed, decimated] - angular_calibration_applied(NX_BOOLEAN): - doc: | - True when the angular calibration has been applied in the electronics, false - otherwise. - angular_calibration(NX_FLOAT): - doc: | - Angular calibration data. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - flatfield_applied(NX_BOOLEAN): - doc: | - True when the flat field correction has been applied in the electronics, false - otherwise. - flatfield(NX_FLOAT): - doc: | - Flat field correction data. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - flatfield_errors(NX_FLOAT): - doc: | - Errors of the flat field correction data. The form flatfield_error is - deprecated. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - pixel_mask_applied(NX_BOOLEAN): - doc: | - True when the pixel mask correction has been applied in the electronics, false - otherwise. - pixel_mask(NX_INT): - doc: | - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning':' - - .. can't make a table here, a bullet list will have to do for now - - * bit 0':' gap (pixel with no sensor) - * bit 1':' dead - * bit 2':' under responding - * bit 3':' over responding - * bit 4':' noisy - * bit 5':' -undefined- - * bit 6':' pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7':' -undefined- - * bit 8':' user defined mask (e.g. around beamstop) - * bits 9-30':' -undefined- - * bit 31':' virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - countrate_correction_applied(NX_BOOLEAN): - doc: | - True when a count-rate correction has already been applied in the electronics, - false otherwise. - bit_depth_readout(NX_INT): - doc: | - How many bits the electronics reads per pixel. With CCD's and single photon - counting detectors, this must not align with traditional integer sizes. This can - be 4, 8, 12, 14, 16, ... - detector_readout_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to read the detector (typically milliseconds). This is important - to know for time resolved experiments. - trigger_delay_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to start exposure after a trigger signal has been received. This - is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set - delay.. This is important to know for time resolved experiments. - trigger_delay_time_set(NX_FLOAT): - unit: NX_TIME - doc: | - User-specified trigger delay. - trigger_internal_delay_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to start exposure after a trigger signal has been received. This - is the reaction time of the detector hardware after receiving the trigger signal - to when the detector starts to acquire the exposure. It forms the lower boundary - of the trigger_delay_time when the user does not request an additional delay. - trigger_dead_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time during which no new trigger signal can be accepted. Typically this is the - trigger_delay_time + exposure_time + readout_time. This is important to know for - time resolved experiments. - frame_time(NX_FLOAT): - unit: NX_TIME - doc: | - This is time for each frame. This is exposure_time + readout time. - dimensions: - rank: 1 - dim: [[1, NP]] - gain_setting(NX_CHAR): - doc: | - The gain setting of the detector. This influences background etc. - enumeration: [high, standard, fast, auto] - saturation_value(NX_INT): - doc: | - The value at which the detector goes into saturation. Especially common to CCD - detectors, the data is known to be invalid above this value. For example, given - a saturation_value and an underload_value, the valid pixels are those less than - or equal to the saturation_value and greater than or equal to the - underload_value. - underload_value(NX_INT): - doc: | - The lowest value at which pixels for this detector would be reasonably measured. - The data is known to be invalid below this value. For example, given a - saturation_value and an underload_value, the valid pixels are those less than or - equal to the saturation_value and greater than or equal to the underload_value. - number_of_cycles(NX_INT): - doc: | - CCD images are sometimes constructed by summing together multiple short - exposures in the electronics. This reduces background etc. This is the number of - short exposures used to sum images for an image. - sensor_material(NX_CHAR): - doc: | - At times, radiation is not directly sensed by the detector. Rather, the detector - might sense the output from some converter like a scintillator. This is the name - of this converter material. - sensor_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - At times, radiation is not directly sensed by the detector. Rather, the detector - might sense the output from some converter like a scintillator. This is the - thickness of this converter material. - threshold_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Single photon counter detectors can be adjusted for a certain energy range in - which they work optimally. This is the energy setting for this. - (NXdetector_module): - doc: | - For use in special cases where the data in NXdetector is represented in several - parts, each with a separate geometry. Use one or more instances of the - NXdetector_module group to declare regions of interest or some other subdivision - of a detector. - (NXoff_geometry): - doc: | - Shape description of the whole detector. Use only if pixels in the detector are - not of uniform shape. - (NXcylindrical_geometry): - doc: | - Shape description of the whole detector. Use only if pixels in the detector are - not of uniform shape and require being described by cylinders. - \@default: - doc: | - .. 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. - amplifier_type(NX_CHAR): - doc: | - Type of electron amplifier, MCP, channeltron, etc. - detector_type(NX_CHAR): - doc: | - Description of the detector type, DLD, Phosphor+CCD, CMOS. - detector_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to detector. - amplifier_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to the amplifier. - amplifier_bias(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - The low voltage of the amplifier migh not be the ground. - sensor_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each imaging sensor chip on the detector. - sensor_count(NX_INT): - unit: NX_UNITLESS - doc: | - Number of imaging sensor chips on the detector. - sensor_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of the pixels of the imaging chip on the detector. - sensor_pixels(NX_INT): - unit: NX_UNITLESS - doc: | - Number of raw active elements in each dimension. Important for swept scans. - (NXdata): - doc: | - raw data output from the detector From 03c1b38b62828b5ffda02f44beaa0475ac1d1953 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 20:59:43 +0200 Subject: [PATCH 134/203] removing NXentry from contributed to base_classes --- contributed_definitions/NXentry.nxdl.xml | 270 --------------------- contributed_definitions/nyaml/NXentry.yaml | 202 --------------- 2 files changed, 472 deletions(-) delete mode 100644 contributed_definitions/NXentry.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXentry.yaml diff --git a/contributed_definitions/NXentry.nxdl.xml b/contributed_definitions/NXentry.nxdl.xml deleted file mode 100644 index b062a10d3d..0000000000 --- a/contributed_definitions/NXentry.nxdl.xml +++ /dev/null @@ -1,270 +0,0 @@ - - - - - (**required**) :ref:`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. - - - - .. index:: plotting - - Declares which :ref:`NXdata` (or :ref:`NXsubentry`) group - contains the data to be shown by default. - It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. - The value is the name of the default :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. - - .. [#] NIAC2014 discussion summary: - https://www.nexusformat.org/2014_How_to_find_default_data.html - - - - - The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 - - - - - ISIS Muon IDF_Version - - - - - Extended title for entry - - - - - Unique identifier for the experiment, defined by the facility, possibly linked - to the proposals - - - - - Brief summary of the experiment, including key objectives. - - - - - Description of the full experiment (document in pdf, latex, ...) - - - - - User or Data Acquisition defined group of NeXus files or NXentry - - - - - Brief summary of the collection, including grouping criteria. - - - - - Unique identifier for the measurement, defined by the facility. - - - - - UUID identifier for the measurement. - - - - Version of UUID used - - - - - - Reserved for future use by NIAC. See - https://github.com/nexusformat/definitions/issues/382 - - - - - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms. - This field is provided so that :ref:`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Local NXDL schema extended from the entry specified in the ``definition`` field. - This contains any locally-defined, additional fields in the entry. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Starting time of measurement - - - - - Ending time of measurement - - - - - Duration of measurement - - - - - Time transpired actually collecting data i.e. taking out time when collection - was suspended due to e.g. temperature out of range - - - - - Such as '2007-3'. Some user facilities organize their beam time into run cycles. - - - - - Name of program used to generate this file - - - - Program version number - - - - - configuration of the program - - - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a - chopper, by the moderator or the source itself. In other words: it the distance - to the component which gives the T0 signal to the detector electronics. If - another component in the NXinstrument hierarchy provides this information, this - should be a link. - - - - - City and country where the experiment took place - - - - - Start time of experimental run that includes the current measurement, for - example a beam time. - - - - - End time of experimental run that includes the current measurement, for example - a beam time. - - - - - Name of the institution hosting the facility - - - - - Name of the experimental facility - - - - - Name of the laboratory or beamline - - - - - Notes describing entry - - - - - A small image that is representative of the entry. An example of this is a - 640x480 jpeg image automatically produced by a low resolution plot of the - NXdata. - - - - The mime type should be an ``image/*`` - - - - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXentry.yaml b/contributed_definitions/nyaml/NXentry.yaml deleted file mode 100644 index 7527a9528e..0000000000 --- a/contributed_definitions/nyaml/NXentry.yaml +++ /dev/null @@ -1,202 +0,0 @@ -category: base -doc: | - (**required**) ':'ref':'`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. - -type: group -(NXobject)NXentry: - \@default: - doc: | - .. index':'':' plotting - - Declares which ':'ref':'`NXdata` (or ':'ref':'`NXsubentry`) group - contains the data to be shown by default. - It is needed to resolve ambiguity when more than one ':'ref':'`NXdata` group exists. - The value is the name of the default ':'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. - - .. [#] NIAC2014 discussion summary':' - https':'//www.nexusformat.org/2014_How_to_find_default_data.html - (NXdata): - doc: | - The data group - - .. note':'':' Before the NIAC2016 meeting [#]_, at least one - ':'ref':'`NXdata` group was required in each ':'ref':'`NXentry` group. - At the NIAC2016 meeting, it was decided to make ':'ref':'`NXdata` - an optional group in ':'ref':'`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an ':'ref':'`NXdata` group - in the ':'ref':'`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - ':'ref':'`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016':' - https':'//www.nexusformat.org/NIAC2016.html, - https':'//github.com/nexusformat/NIAC/issues/16 - \@IDF_Version: - doc: | - ISIS Muon IDF_Version - title(NX_CHAR): - doc: | - Extended title for entry - experiment_identifier(NX_CHAR): - doc: | - Unique identifier for the experiment, defined by the facility, possibly linked - to the proposals - experiment_description(NX_CHAR): - doc: | - Brief summary of the experiment, including key objectives. - experiment_documentation(NXnote): - doc: | - Description of the full experiment (document in pdf, latex, ...) - collection_identifier(NX_CHAR): - doc: | - User or Data Acquisition defined group of NeXus files or NXentry - collection_description(NX_CHAR): - doc: | - Brief summary of the collection, including grouping criteria. - entry_identifier(NX_CHAR): - doc: | - Unique identifier for the measurement, defined by the facility. - entry_identifier_uuid(NX_CHAR): - doc: | - UUID identifier for the measurement. - \@version: - type: NX_CHAR - doc: | - Version of UUID used - features(NX_CHAR): - doc: | - Reserved for future use by NIAC. See - https':'//github.com/nexusformat/definitions/issues/382 - definition(NX_CHAR): - doc: | - (alternate use':' see same field in ':'ref':'`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms. - This field is provided so that ':'ref':'`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use ':'ref':'`NXsubentry`, instead, as the overlay position. - \@version: - type: NX_CHAR - doc: | - NXDL version number - \@URL: - type: NX_CHAR - doc: | - URL of NXDL file - definition_local(NX_CHAR): - doc: | - Local NXDL schema extended from the entry specified in the ``definition`` field. - This contains any locally-defined, additional fields in the entry. - \@version: - type: NX_CHAR - doc: | - NXDL version number - \@URL: - type: NX_CHAR - doc: | - URL of NXDL file - start_time(NX_DATE_TIME): - doc: | - Starting time of measurement - end_time(NX_DATE_TIME): - doc: | - Ending time of measurement - duration(NX_INT): - unit: NX_TIME - doc: | - Duration of measurement - collection_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time transpired actually collecting data i.e. taking out time when collection - was suspended due to e.g. temperature out of range - run_cycle(NX_CHAR): - doc: | - Such as '2007-3'. Some user facilities organize their beam time into run cycles. - program_name(NX_CHAR): - doc: | - Name of program used to generate this file - \@version: - type: NX_CHAR - doc: | - Program version number - \@configuration: - type: NX_CHAR - doc: | - configuration of the program - revision(NX_CHAR): - doc: | - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - \@comment: - type: NX_CHAR - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flightpath before the sample position. This can be determined by a - chopper, by the moderator or the source itself. In other words':' it the distance - to the component which gives the T0 signal to the detector electronics. If - another component in the NXinstrument hierarchy provides this information, this - should be a link. - experiment_location(NX_CHAR): - doc: | - City and country where the experiment took place - experiment_start_date(NX_DATE_TIME): - doc: | - Start time of experimental run that includes the current measurement, for - example a beam time. - experiment_end_date(NX_DATE_TIME): - doc: | - End time of experimental run that includes the current measurement, for example - a beam time. - experiment_institution(NX_CHAR): - doc: | - Name of the institution hosting the facility - experiment_facility(NX_CHAR): - doc: | - Name of the experimental facility - experiment_laboratory(NX_CHAR): - doc: | - Name of the laboratory or beamline - notes(NXnote): - doc: | - Notes describing entry - thumbnail(NXnote): - doc: | - A small image that is representative of the entry. An example of this is a - 640x480 jpeg image automatically produced by a low resolution plot of the - NXdata. - \@type: - doc: | - The mime type should be an ``image/*`` - enumeration: [image/*] - (NXuser): - (NXsample): - (NXinstrument): - (NXcollection): - (NXmonitor): - (NXparameters): - (NXprocess): - (NXsubentry): From fffc69da98be823b1bf4705822fb51e37ea4c54c Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 21:16:51 +0200 Subject: [PATCH 135/203] merging and putting NXinstrument from contributed to base_classes --- base_classes/NXinstrument.nxdl.xml | 147 ++++++++++-------- base_classes/nyaml/NXinstrument.yaml | 21 +++ contributed_definitions/NXinstrument.nxdl.xml | 82 ---------- .../nyaml/NXinstrument.yaml | 71 --------- 4 files changed, 107 insertions(+), 214 deletions(-) delete mode 100644 contributed_definitions/NXinstrument.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXinstrument.yaml diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index 249cbeda82..c5cb0a26fb 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -1,14 +1,14 @@ - + - - - Collection of the components of the instrument or beamline. - - Template of instrument descriptions comprising various beamline components. - Each component will also be a NeXus group defined by its distance from the - sample. Negative distances represent beamline components that are before the - sample while positive distances represent components that are after the sample. - This device allows the unique identification of beamline components in a way - that is valid for both reactor and pulsed instrumentation. - - - Name of instrument - - short name for instrument, perhaps the acronym - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + Collection of the components of the instrument or beamline. + + Template of instrument descriptions comprising various beamline components. + Each component will also be a NeXus group defined by its distance from the + sample. Negative distances represent beamline components that are before the + sample while positive distances represent components that are after the sample. + This device allows the unique identification of beamline components in a way + that is valid for both reactor and pulsed instrumentation. + + + + Name of instrument + + + + short name for instrument, perhaps the acronym + + + + + + Energy resolution of the experiment (FWHM or gaussian broadening) + + + + + Momentum resolution of the experiment (FWHM) + + + + + Angular resolution of the experiment (FWHM) + + + + + Spatial resolution of the experiment (Airy disk radius) + + + + + Temporal resolution of the experiment (FWHM) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml index b9912d9b54..154dc0b387 100644 --- a/base_classes/nyaml/NXinstrument.yaml +++ b/base_classes/nyaml/NXinstrument.yaml @@ -17,6 +17,26 @@ NXinstrument(NXobject): \@short_name: doc: | short name for instrument, perhaps the acronym + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the experiment (FWHM or gaussian broadening) + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the experiment (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the experiment (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the experiment (Airy disk radius) + temporal_resolution(NX_FLOAT): + unit: NX_TIME + doc: | + Temporal resolution of the experiment (FWHM) (NXaperture): (NXattenuator): (NXbeam): @@ -56,3 +76,4 @@ NXinstrument(NXobject): 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/NXinstrument.nxdl.xml b/contributed_definitions/NXinstrument.nxdl.xml deleted file mode 100644 index bec81c7a30..0000000000 --- a/contributed_definitions/NXinstrument.nxdl.xml +++ /dev/null @@ -1,82 +0,0 @@ - - - - - Collection of the components of the instrument or beamline. Template of - instrument descriptions comprising various beamline components. Each component - will also be a NeXus group defined by its distance from the sample. Negative - distances represent beamline components that are before the sample while - positive distances represent components that are after the sample. This device - allows the unique identification of beamline components in a way that is valid - for both reactor and pulsed instrumentation. - - - - Name of instrument - - - - short name for instrument, perhaps the acronym - - - - - - Energy resolution of the experiment (FWHM or gaussian broadening) - - - - - Momentum resolution of the experiment (FWHM) - - - - - Angular resolution of the experiment (FWHM) - - - - - Spatial resolution of the experiment (Airy disk radius) - - - - - Temporal resolution of the experiment (FWHM) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .. 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/nyaml/NXinstrument.yaml b/contributed_definitions/nyaml/NXinstrument.yaml deleted file mode 100644 index 6a223092c4..0000000000 --- a/contributed_definitions/nyaml/NXinstrument.yaml +++ /dev/null @@ -1,71 +0,0 @@ -category: base -doc: | - Collection of the components of the instrument or beamline. Template of - instrument descriptions comprising various beamline components. Each component - will also be a NeXus group defined by its distance from the sample. Negative - distances represent beamline components that are before the sample while - positive distances represent components that are after the sample. This device - allows the unique identification of beamline components in a way that is valid - for both reactor and pulsed instrumentation. - -type: group -(NXobject)NXinstrument: - name(NX_CHAR): - doc: | - Name of instrument - \@short_name: - type: NX_CHAR - doc: | - short name for instrument, perhaps the acronym - energy_resolution(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy resolution of the experiment (FWHM or gaussian broadening) - momentum_resolution(NX_FLOAT): - unit: NX_WAVENUMBER - doc: | - Momentum resolution of the experiment (FWHM) - angular_resolution(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angular resolution of the experiment (FWHM) - spatial_resolution(NX_FLOAT): - unit: NX_LENGTH - doc: | - Spatial resolution of the experiment (Airy disk radius) - temporal_resolution(NX_FLOAT): - unit: NX_TIME - doc: | - Temporal resolution of the experiment (FWHM) - (NXaperture): - (NXattenuator): - (NXbeam): - (NXbeam_stop): - (NXbending_magnet): - (NXcollimator): - (NXcollection): - (NXcapillary): - (NXcrystal): - (NXdetector): - (NXdetector_group): - (NXdisk_chopper): - (NXevent_data): - (NXfermi_chopper): - (NXfilter): - (NXflipper): - (NXguide): - (NXinsertion_device): - (NXmirror): - (NXmoderator): - (NXmonochromator): - (NXpolarizer): - (NXpositioner): - (NXsource): - DIFFRACTOMETER(NXtransformations): - (NXvelocity_selector): - (NXxraylens): - \@default: - doc: | - .. index':'':' plotting - Declares which child group contains a path leading to a ':'ref':'`NXdata` group. - It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https':'//www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. From ee82bece091b90bcb8e975a0a92b37775d9b4cc9 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 26 Apr 2023 21:21:55 +0200 Subject: [PATCH 136/203] merging and putting NXprocess from contributed to base_classes --- base_classes/NXprocess.nxdl.xml | 80 ++++++++++++-------- base_classes/nyaml/NXprocess.yaml | 10 +++ contributed_definitions/NXprocess.nxdl.xml | 64 ---------------- contributed_definitions/nyaml/NXprocess.yaml | 45 ----------- 4 files changed, 59 insertions(+), 140 deletions(-) delete mode 100644 contributed_definitions/NXprocess.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXprocess.yaml diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index d6a3346af1..9da6f78ce7 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -1,14 +1,14 @@ - + - - Document an event of data processing, reconstruction, or analysis for this data. + + + Document an event of data processing, reconstruction, or analysis for this data. + - Name of the program used + + Name of the program used + - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. - Version of the program used + + Version of the program used + - Date and time of processing. + + Date and time of processing. + + + + Describes the operations of image registration + + + + + Describes the operations of image distortion correction + + + + + Describes the operations of calibration procedures, e.g. axis calibrations. + + - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - diff --git a/base_classes/nyaml/NXprocess.yaml b/base_classes/nyaml/NXprocess.yaml index d2650c0e4c..6ea8529d13 100644 --- a/base_classes/nyaml/NXprocess.yaml +++ b/base_classes/nyaml/NXprocess.yaml @@ -17,6 +17,15 @@ NXprocess(NXobject): date(NX_DATE_TIME): doc: | Date and time of processing. + (NXregistration): + doc: | + Describes the operations of image registration + (NXdistortion): + doc: | + Describes the operations of image distortion correction + (NXcalibration): + doc: | + Describes the operations of calibration procedures, e.g. axis calibrations. (NXnote): doc: | The note will contain information about how the data was processed @@ -109,3 +118,4 @@ NXprocess(NXobject): # # # + diff --git a/contributed_definitions/NXprocess.nxdl.xml b/contributed_definitions/NXprocess.nxdl.xml deleted file mode 100644 index 5b12ff4776..0000000000 --- a/contributed_definitions/NXprocess.nxdl.xml +++ /dev/null @@ -1,64 +0,0 @@ - - - - - Document an event of data processing, reconstruction, or analysis for this data. - - - - Name of the program used - - - - - Sequence index of processing, for determining the order of multiple - **NXprocess** steps. Starts with 1. - - - - - Version of the program used - - - - - Date and time of processing. - - - - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - - - - Notes contain information about how the data was processed or anything about the - data provenance. The contents of the note can be anything that the processing - code can understand, or simple text. The name will be numbered to allow for - ordering of steps. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - diff --git a/contributed_definitions/nyaml/NXprocess.yaml b/contributed_definitions/nyaml/NXprocess.yaml deleted file mode 100644 index 2e3ab2fd39..0000000000 --- a/contributed_definitions/nyaml/NXprocess.yaml +++ /dev/null @@ -1,45 +0,0 @@ -category: base -doc: | - Document an event of data processing, reconstruction, or analysis for this data. - -type: group -(NXobject)NXprocess: - program(NX_CHAR): - doc: | - Name of the program used - sequence_index(NX_POSINT): - doc: | - Sequence index of processing, for determining the order of multiple - **NXprocess** steps. Starts with 1. - version(NX_CHAR): - doc: | - Version of the program used - date(NX_DATE_TIME): - doc: | - Date and time of processing. - (NXregistration): - doc: | - Describes the operations of image registration - (NXdistortion): - doc: | - Describes the operations of image distortion correction - (NXcalibration): - doc: | - Describes the operations of calibration procedures, e.g. axis calibrations. - (NXnote): - doc: | - Notes contain information about how the data was processed or anything about the - data provenance. The contents of the note can be anything that the processing - code can understand, or simple text. The name will be numbered to allow for - ordering of steps. - \@default: - doc: | - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. From 562425222c48f4c5271b258d94840edb04f8f0c0 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 27 Apr 2023 09:39:51 +0200 Subject: [PATCH 137/203] merging and putting NXsample from contributed to base_classes --- base_classes/NXsample.nxdl.xml | 970 ++++++++++++-------- base_classes/nyaml/NXsample.yaml | 84 +- contributed_definitions/NXsample.nxdl.xml | 599 ------------ contributed_definitions/nyaml/NXsample.yaml | 412 --------- 4 files changed, 671 insertions(+), 1394 deletions(-) mode change 100755 => 100644 base_classes/NXsample.nxdl.xml delete mode 100644 contributed_definitions/NXsample.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXsample.yaml diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml old mode 100755 new mode 100644 index 43bb316334..27ede84e5a --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -1,14 +1,14 @@ - + - - - - symbolic array lengths to be coordinated between various fields - number of compositions - number of temperatures - number of values in applied electric field - number of values in applied magnetic field - number of values in applied pressure field - number of values in applied stress field - - - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - - - Descriptive name of sample - - - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * 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. - - * This is the *Hill* system used by Chemical Abstracts. - - - - Sample temperature. This could be a scanned variable - - - - - - Applied electric field - - - + + + + symbolic array lengths to be coordinated between various fields + + + + number of compositions + + + + + number of temperatures + + + + + number of values in applied electric field + + + + + number of values in applied magnetic field + + + + + number of values in applied pressure field + + + + + number of values in applied stress field + + + + + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + + + + Descriptive name of sample + + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * 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. + + * This is the *Hill* system used by Chemical Abstracts. + + + + + Sample temperature. This could be a scanned variable + + + + + + + + + Applied electric field + + + + + - - - - - + + + + + - - - Applied magnetic field - - - + + + + Applied magnetic field + + + + + - - - - - + + + + + - - - Applied external stress field - - - + + + + Applied external stress field + + + + + - - - - - + + + + + - - - Applied pressure - - - - - - Sample changer position - - - Crystallography unit cell parameters a, b, and c - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - Unit cell parameters (lengths and angles) - - - - - - - Volume of the unit cell - - - - - - - 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. - - - - - - - - - Mass of sample - - - - - - Density of sample - - - - - - Relative Molecular Mass of sample - - - - - - - - - - - - - - - - - - - - - The atmosphere will be one of the components, which is where - its details will be stored; the relevant components will be - indicated by the entry in the sample_component member. - - - - - - - - - - - - - - Description of the sample - - - - Date of preparation of the sample - - - The position and orientation of the center of mass of the sample - - - Details of beam incident on sample - used to calculate sample/beam interaction point - - - - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - - - - Details of the component of the sample and/or can - - - - - - Type of component - - - - - - - - - - - - Concentration of each component - - - - - - Volume fraction of each component - - - - - - Scattering length density of each component - - - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - Crystallographic space group - - - - - - Crystallographic point group, deprecated if space_group present - - + + + + Applied pressure + + + + + + + + + Sample changer position + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Unit cell parameters (lengths and angles) + + + + + + + + + Volume of the unit cell + + + + + + + + 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. + + + + + + + + + + Mass of sample + + + + + + + + Density of sample + + + + + + + + Relative Molecular Mass of sample + + + + + + + + + + + + + + + + + + + + + + The atmosphere will be one of the components, which is where + its details will be stored; the relevant components will be + indicated by the entry in the sample_component member. + + + + + + + + + + + + + + Description of the sample + + + + + Date of preparation of the sample + + + + + The position and orientation of the center of mass of the sample + + + + + Details of beam incident on sample - used to calculate sample/beam interaction point + + + + + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + + + + + Details of the component of the sample and/or can + + + + + + + + Type of component + + + + + + + + + + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + + + + + + Crystallographic point group, deprecated if space_group present + + + - - - - Path length through sample/can for simple case when - it does not vary with scattering direction - - - - - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - - - - sample thickness - - - As a function of Wavelength - - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - - - Additional sample temperature environment information - - - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - - - magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value - - - Additional sample magnetic environment information - - - value sent to user's sample setup - - - logged value (or logic state) read from user's setup - - - 20 character fixed length sample description for legends - - - - - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - - - - Any positioner (motor, PZT, ...) used to locate the sample - - - - This group describes the shape of the sample - - + + + + Path length through sample/can for simple case when + it does not vary with scattering direction + + + + + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + + + + + sample thickness + + + + + Identification number or signatures of the sample used. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (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 + + + + + Physical state of the sample + + + + + Chemical purity of the sample + + + + + Surface termination of the sample (if crystalline) + + + + + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + + + + + Full chemical name of the sample + + + + + CAS registry number of the sample chemical content. + + + + + Gases might be fluxed on the surface for various reasons. Chemical designation, + or residual. + + + + + In the case of a fixed pressure measurement this is the scalar pressure. In the + case of an experiment in which pressure changes, or anyway is recorded, this is + an array of length m of pressures. + + + + + Element of evaporated surface dopant such as alkali or other + + + + + Nominal thickness of the evaporated dopant + + + + + Voltage applied to sample and sample holder. + + + + + Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition + etc.) + + + + + Name of the sample vendor (company or research group) + + + + + Material of the substrate in direct contact with the sample. + + + + + Physical state of the substrate, similar options to sample_state + + + + + Current to neutralize the photoemission current. This field may also be found in + NXmanpulator if present. + + + + + Possible bias of the sample with respect to analyser ground. This field may also + be found as sample_bias in NXmanipulator if present. + + + + + Further notes. + + + + + As a function of Wavelength + + + + + temperature.value is a link to e.g. temperature_env.sensor1.value + + + + + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + + + + + Additional sample temperature environment information + + + + + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + + + + + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value + + + + + Additional sample magnetic environment information + + + + + value sent to user's sample setup + + + + + logged value (or logic state) read from user's setup + + + + + 20 character fixed length sample description for legends + + + + + + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + + + + + Any positioner (motor, PZT, ...) used to locate the sample + + + + + This group describes the shape of the sample + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. - diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index e086667736..b6601258c1 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -255,11 +255,90 @@ NXsample(NXobject): unit: NX_LENGTH doc: | sample thickness + sample_id(NX_CHAR): + doc: | + Identification number or signatures of the sample used. + sample_history(NXnote): + doc: | + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (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 + state(NX_CHAR): + doc: | + Physical state of the sample + purity(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Chemical purity of the sample + orientation(NX_CHAR): + doc: | + Surface termination of the sample (if crystalline) + layer(NX_CHAR): + doc: | + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + chemical_name(NX_CHAR): + doc: | + Full chemical name of the sample + chem_id_cas(NX_CHAR): + doc: | + CAS registry number of the sample chemical content. + gas(NX_CHAR): + doc: | + Gases might be fluxed on the surface for various reasons. Chemical designation, + or residual. + gas_pressure(NX_NUMBER): + unit: NX_PRESSURE + doc: | + In the case of a fixed pressure measurement this is the scalar pressure. In the + case of an experiment in which pressure changes, or anyway is recorded, this is + an array of length m of pressures. + surface_dopant(NX_CHAR): + doc: | + Element of evaporated surface dopant such as alkali or other + surface_dopant_coverage(NX_FLOAT): + unit: NX_LENGTH + doc: | + Nominal thickness of the evaporated dopant + bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to sample and sample holder. + growth_method(NX_CHAR): + doc: | + Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition + etc.) + vendor(NX_CHAR): + doc: | + Name of the sample vendor (company or research group) + substrate_material(NX_CHAR): + doc: | + Material of the substrate in direct contact with the sample. + substrate_state(NX_CHAR): + doc: | + Physical state of the substrate, similar options to sample_state + drain_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Current to neutralize the photoemission current. This field may also be found in + NXmanpulator if present. + bias_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Possible bias of the sample with respect to analyser ground. This field may also + be found as sample_bias in NXmanipulator if present. + notes(NXnote): + doc: | + Further notes. transmission(NXdata): doc: | As a function of Wavelength + temperature(NXlog): + doc: | + temperature.value is a link to e.g. temperature_env.sensor1.value temperature_log(NXlog): - deprecated: + deprecated: | use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 doc: | temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value @@ -270,7 +349,7 @@ NXsample(NXobject): doc: | magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value magnetic_field_log(NXlog): - deprecated: + deprecated: | use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 doc: | magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value @@ -762,3 +841,4 @@ NXsample(NXobject): # # # + diff --git a/contributed_definitions/NXsample.nxdl.xml b/contributed_definitions/NXsample.nxdl.xml deleted file mode 100644 index 5dac64b788..0000000000 --- a/contributed_definitions/NXsample.nxdl.xml +++ /dev/null @@ -1,599 +0,0 @@ - - - - - - symbolic array lengths to be coordinated between various fields - - - - number of compositions - - - - - number of temperatures - - - - - number of values in applied electric field - - - - - number of values in applied magnetic field - - - - - number of values in applied pressure field - - - - - number of values in applied stress field - - - - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - - - - Descriptive name of sample - - - - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * 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. - * This is the *Hill* system used by Chemical Abstracts. - - - - - Sample temperature. This could be a scanned variable - - - - - - - - Applied electric field - - - - - - - - - - - - - - - Applied magnetic field - - - - - - - - - - - - - - - Applied external stress field - - - - - - - - - - - - - - - Applied pressure - - - - - - - - Sample changer position - - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - Unit cell parameters (lengths and angles) - - - - - - - - - Volume of the unit cell - - - - - - - - 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. - - - - - - - - - - Mass of sample - - - - - - - - Density of sample - - - - - - - - Relative Molecular Mass of sample - - - - - - - - - - - - - - - - - - - - - - The atmosphere will be one of the components, which is where its details will be - stored; the relevant components will be indicated by the entry in the - sample_component member. - - - - - - - - - - - - - - Description of the sample - - - - - Date of preparation of the sample - - - - - The position and orientation of the center of mass of the sample - - - - - Details of beam incident on sample - used to calculate sample/beam interaction - point - - - - - One group per sample component This is the perferred way of recording per - component information over the n_comp arrays - - - - - Details of the component of the sample and/or can - - - - - - - - Type of component - - - - - - - - - - - - - - Concentration of each component - - - - - - - - Volume fraction of each component - - - - - - - - Scattering length density of each component - - - - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - - Crystallographic space group - - - - - - - - Crystallographic point group, deprecated if space_group present - - - - - - - - Path length through sample/can for simple case when it does not vary with - scattering direction - - - - - Thickness of a beam entry/exit window on the can (mm). It is assumed to be the - same for entry and exit - - - - - sample thickness - - - - - Identification number or signatures of the sample used. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (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 - - - - - Physical state of the sample - - - - - Chemical purity of the sample - - - - - Surface termination of the sample (if crystalline) - - - - - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - - - - - Full chemical name of the sample - - - - - CAS registry number of the sample chemical content. - - - - - Gases might be fluxed on the surface for various reasons. Chemical designation, - or residual. - - - - - In the case of a fixed pressure measurement this is the scalar pressure. In the - case of an experiment in which pressure changes, or anyway is recorded, this is - an array of length m of pressures. - - - - - Element of evaporated surface dopant such as alkali or other - - - - - Nominal thickness of the evaporated dopant - - - - - Voltage applied to sample and sample holder. - - - - - Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition - etc.) - - - - - Name of the sample vendor (company or research group) - - - - - Material of the substrate in direct contact with the sample. - - - - - Physical state of the substrate, similar options to sample_state - - - - - Current to neutralize the photoemission current. This field may also be found in - NXmanpulator if present. - - - - - Possible bias of the sample with respect to analyser ground. This field may also - be found as sample_bias in NXmanipulator if present. - - - - - Further notes. - - - - - As a function of Wavelength - - - - - temperature.value is a link to e.g. temperature_env.sensor1.value - - - - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - - - - - Additional sample temperature environment information - - - - - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - - - - - magnetic_field_log.value is a link to e.g. - magnetic_field_env.sensor1.value_log.value - - - - - Additional sample magnetic environment information - - - - - value sent to user's sample setup - - - - - logged value (or logic state) read from user's setup - - - - - 20 character fixed length sample description for legends - - - - - Optional rotation angle for the case when the powder diagram has been obtained - through an omega-2theta scan like from a traditional single detector powder - diffractometer - - - - - Translation of the sample along the X-direction of the laboratory coordinate - system - - - - - Translation of the sample along the Z-direction of the laboratory coordinate - system - - - - - Any positioner (motor, PZT, ...) used to locate the sample - - - - - 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/contributed_definitions/nyaml/NXsample.yaml b/contributed_definitions/nyaml/NXsample.yaml deleted file mode 100644 index 6a2cf4d1de..0000000000 --- a/contributed_definitions/nyaml/NXsample.yaml +++ /dev/null @@ -1,412 +0,0 @@ -category: base -doc: | - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - -symbols: - doc: | - symbolic array lengths to be coordinated between various fields - - n_comp: | - number of compositions - - n_Temp: | - number of temperatures - - n_eField: | - number of values in applied electric field - - n_mField: | - number of values in applied magnetic field - - n_pField: | - number of values in applied pressure field - - n_sField: | - number of values in applied stress field - -type: group -(NXobject)NXsample: - name(NX_CHAR): - doc: | - Descriptive name of sample - chemical_formula(NX_CHAR): - doc: | - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard':' - - * 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. - * This is the *Hill* system used by Chemical Abstracts. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Sample temperature. This could be a scanned variable - dimensions: - rank: anyRank - dim: [[1, n_Temp]] - electric_field(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Applied electric field - dimensions: - dim: [[1, n_eField]] - \@direction: - type: NX_CHAR - enumeration: [x, y, z] - magnetic_field(NX_FLOAT): - unit: NX_ANY - doc: | - Applied magnetic field - dimensions: - dim: [[1, n_mField]] - \@direction: - type: NX_CHAR - enumeration: [x, y, z] - stress_field(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external stress field - dimensions: - dim: [[1, n_sField]] - \@direction: - type: NX_CHAR - enumeration: [x, y, z] - pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Applied pressure - dimensions: - dim: [[1, n_pField]] - changer_position(NX_INT): - unit: NX_UNITLESS - doc: | - Sample changer position - unit_cell_abc(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dimensions: - dim: [[1, 3]] - unit_cell_alphabetagamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma - dimensions: - dim: [[1, 3]] - unit_cell(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell parameters (lengths and angles) - dimensions: - rank: 2 - dim: [[1, n_comp], [2, 6]] - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - dimensions: - rank: 1 - dim: [[1, n_comp]] - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention':' - - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 1 - dim: [[1, 3]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention':' - - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 3 - dim: [[1, n_comp], [2, 3], [3, 3]] - ub_matrix(NX_FLOAT): - doc: | - 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. - dimensions: - rank: 3 - dim: [[1, n_comp], [2, 3], [3, 3]] - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Mass of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative Molecular Mass of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - type(NX_CHAR): - enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] - situation(NX_CHAR): - doc: | - The atmosphere will be one of the components, which is where its details will be - stored; the relevant components will be indicated by the entry in the - sample_component member. - enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] - description(NX_CHAR): - doc: | - Description of the sample - preparation_date(NX_DATE_TIME): - doc: | - Date of preparation of the sample - geometry(NXgeometry): - doc: | - The position and orientation of the center of mass of the sample - (NXbeam): - doc: | - Details of beam incident on sample - used to calculate sample/beam interaction - point - (NXsample_component): - doc: | - One group per sample component This is the perferred way of recording per - component information over the n_comp arrays - component(NX_CHAR): - doc: | - Details of the component of the sample and/or can - dimensions: - rank: 1 - dim: [[1, n_comp]] - sample_component(NX_CHAR): - doc: | - Type of component - dimensions: - rank: 1 - dim: [[1, n_comp]] - enumeration: [sample, can, atmosphere, kit] - concentration(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Concentration of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - volume_fraction(NX_FLOAT): - doc: | - Volume fraction of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - scattering_length_density(NX_FLOAT): - unit: NX_SCATTERING_LENGTH_DENSITY - doc: | - Scattering length density of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - unit_cell_class(NX_CHAR): - doc: | - In case it is all we know and we want to record/document it - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group(NX_CHAR): - doc: | - Crystallographic space group - dimensions: - dim: [[1, n_comp]] - point_group(NX_CHAR): - doc: | - Crystallographic point group, deprecated if space_group present - dimensions: - dim: [[1, n_comp]] - path_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Path length through sample/can for simple case when it does not vary with - scattering direction - path_length_window(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of a beam entry/exit window on the can (mm). It is assumed to be the - same for entry and exit - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - sample thickness - sample_id(NX_CHAR): - doc: | - Identification number or signatures of the sample used. - sample_history(NXnote): - doc: | - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (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 - state(NX_CHAR): - doc: | - Physical state of the sample - purity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Chemical purity of the sample - orientation(NX_CHAR): - doc: | - Surface termination of the sample (if crystalline) - layer(NX_CHAR): - doc: | - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - chemical_name(NX_CHAR): - doc: | - Full chemical name of the sample - chem_id_cas(NX_CHAR): - doc: | - CAS registry number of the sample chemical content. - gas(NX_CHAR): - doc: | - Gases might be fluxed on the surface for various reasons. Chemical designation, - or residual. - gas_pressure(NX_NUMBER): - unit: NX_PRESSURE - doc: | - In the case of a fixed pressure measurement this is the scalar pressure. In the - case of an experiment in which pressure changes, or anyway is recorded, this is - an array of length m of pressures. - surface_dopant(NX_CHAR): - doc: | - Element of evaporated surface dopant such as alkali or other - surface_dopant_coverage(NX_FLOAT): - unit: NX_LENGTH - doc: | - Nominal thickness of the evaporated dopant - bias(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to sample and sample holder. - growth_method(NX_CHAR): - doc: | - Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition - etc.) - vendor(NX_CHAR): - doc: | - Name of the sample vendor (company or research group) - substrate_material(NX_CHAR): - doc: | - Material of the substrate in direct contact with the sample. - substrate_state(NX_CHAR): - doc: | - Physical state of the substrate, similar options to sample_state - drain_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Current to neutralize the photoemission current. This field may also be found in - NXmanpulator if present. - bias_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Possible bias of the sample with respect to analyser ground. This field may also - be found as sample_bias in NXmanipulator if present. - notes(NXnote): - doc: | - Further notes. - transmission(NXdata): - doc: | - As a function of Wavelength - temperature(NXlog): - doc: | - temperature.value is a link to e.g. temperature_env.sensor1.value - temperature_log(NXlog): - doc: | - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - temperature_env(NXenvironment): - doc: | - Additional sample temperature environment information - magnetic_field(NXlog): - doc: | - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - magnetic_field_log(NXlog): - doc: | - magnetic_field_log.value is a link to e.g. - magnetic_field_env.sensor1.value_log.value - magnetic_field_env(NXenvironment): - doc: | - Additional sample magnetic environment information - external_DAC(NX_FLOAT): - unit: NX_ANY - doc: | - value sent to user's sample setup - external_ADC(NXlog): - doc: | - logged value (or logic state) read from user's setup - short_title(NX_CHAR): - doc: | - 20 character fixed length sample description for legends - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder diagram has been obtained - through an omega-2theta scan like from a traditional single detector powder - diffractometer - x_translation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the X-direction of the laboratory coordinate - system - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the Z-direction of the laboratory coordinate - system - (NXpositioner): - doc: | - Any positioner (motor, PZT, ...) used to locate the sample - depends_on(NX_CHAR): - doc: | - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - (NXtransformations): - doc: | - 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. - \@default: - doc: | - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. From 2be9f96ace001c0ff45a2fd55528e5ed6477e226 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 27 Apr 2023 09:47:27 +0200 Subject: [PATCH 138/203] removing NXsource from contributed to base_classes --- contributed_definitions/NXsource.nxdl.xml | 274 -------------------- contributed_definitions/nyaml/NXsource.yaml | 172 ------------ 2 files changed, 446 deletions(-) delete mode 100644 contributed_definitions/NXsource.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXsource.yaml diff --git a/contributed_definitions/NXsource.nxdl.xml b/contributed_definitions/NXsource.nxdl.xml deleted file mode 100644 index ae24b92e00..0000000000 --- a/contributed_definitions/NXsource.nxdl.xml +++ /dev/null @@ -1,274 +0,0 @@ - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of points in a spectrum - - - - - The neutron or x-ray storage ring/facility. - - - - Effective distance from sample Distance as seen by radiation from sample. This - number should be negative to signify that it is upstream of the sample. - - - - - Name of source - - - - short name for source, perhaps the acronym - - - - - - Type of radiation source (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - - - - - - - - - - - Type of radiation probe (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - - - Source power - - - - - Source emittance (nm-rad) in X (horizontal) direction. - - - - - Source emittance (nm-rad) in Y (horizontal) direction. - - - - - Particle beam size in x - - - - - Particle beam size in y - - - - - Source intensity/area (example: s-1 cm-2) - - - - - Source energy. For storage rings, this would be the particle beam energy. For - X-ray tubes, this would be the excitation voltage. - - - - - Accelerator, X-ray tube, or storage ring current - - - - - Accelerator voltage - - - - - Frequency of pulsed source - - - - - Period of pulsed source - - - - - Pulsed source target material or other material used to generate light, e.g. He, - Ar gas for lasers, Xe or Hg/Cd vapor for arc lamps, etc. - - - - - - - - - - - - - - - - - - - Any source/facility related messages/events that occurred during the experiment - - - - - For storage rings, description of the bunch pattern. This is useful to describe - irregular bunch patterns. - - - - name of the bunch pattern - - - - - - For storage rings, the number of bunches in use. - - - - - For storage rings, temporal length of the bunch - - - - - For storage rings, time between bunches - - - - - Temporal width of source pulse - - - - - Source pulse shape - - - - - Source operating mode - - - - - For storage rings - - - - - For storage rings - - - - - - - Is the synchrotron operating in top_up mode? - - - - - For storage rings, the current at the end of the most recent injection. - - - - Date and time of the most recent injection. - - - - - - The center photon energy of the source, before it is monochromatized or - converted - - - - - The center wavelength of the source, before it is monochromatized or converted - - - - - For pulsed sources, the energy of a single pulse - - - - - For pulsed sources, the pulse energy divided by the pulse duration - - - - - Some facilities tag each bunch. First bunch of the measurement - - - - - Last bunch of the measurement - - - - - 'Engineering' location of source - - - - - The wavelength or energy distribution of the source - - - - - .. 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/nyaml/NXsource.yaml b/contributed_definitions/nyaml/NXsource.yaml deleted file mode 100644 index e1e1cd74bb..0000000000 --- a/contributed_definitions/nyaml/NXsource.yaml +++ /dev/null @@ -1,172 +0,0 @@ -category: base -doc: | - The neutron or x-ray storage ring/facility. - -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays - - nx: | - Number of points in a spectrum - -type: group -(NXobject)NXsource: - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Effective distance from sample Distance as seen by radiation from sample. This - number should be negative to signify that it is upstream of the sample. - name(NX_CHAR): - doc: | - Name of source - \@short_name: - type: NX_CHAR - doc: | - short name for source, perhaps the acronym - type(NX_CHAR): - doc: | - Type of radiation source (pick one from the enumerated list and spell exactly) - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray, arc lamp, halogen lamp, LED] - probe(NX_CHAR): - doc: | - Type of radiation probe (pick one from the enumerated list and spell exactly) - enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] - power(NX_FLOAT): - unit: NX_POWER - doc: | - Source power - emittance_x(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in X (horizontal) direction. - emittance_y(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in Y (horizontal) direction. - sigma_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - Particle beam size in x - sigma_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - Particle beam size in y - flux(NX_FLOAT): - unit: NX_FLUX - doc: | - Source intensity/area (example':' s-1 cm-2) - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Source energy. For storage rings, this would be the particle beam energy. For - X-ray tubes, this would be the excitation voltage. - current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Accelerator, X-ray tube, or storage ring current - voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Accelerator voltage - frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency of pulsed source - period(NX_FLOAT): - unit: NX_PERIOD - doc: | - Period of pulsed source - target_material(NX_CHAR): - doc: | - Pulsed source target material or other material used to generate light, e.g. He, - Ar gas for lasers, Xe or Hg/Cd vapor for arc lamps, etc. - enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C, Ar, He, Xe, Hg/Cd, H] - notes(NXnote): - doc: | - Any source/facility related messages/events that occurred during the experiment - bunch_pattern(NXdata): - doc: | - For storage rings, description of the bunch pattern. This is useful to describe - irregular bunch patterns. - title(NX_CHAR): - doc: | - name of the bunch pattern - number_of_bunches(NX_INT): - doc: | - For storage rings, the number of bunches in use. - bunch_length(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, temporal length of the bunch - bunch_distance(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, time between bunches - pulse_width(NX_FLOAT): - unit: NX_TIME - doc: | - Temporal width of source pulse - pulse_shape(NXdata): - doc: | - Source pulse shape - mode(NX_CHAR): - doc: | - Source operating mode - enumeration: - Single Bunch: - doc: | - For storage rings - Multi Bunch: - doc: | - For storage rings - top_up(NX_BOOLEAN): - doc: | - Is the synchrotron operating in top_up mode? - last_fill(NX_NUMBER): - unit: NX_CURRENT - doc: | - For storage rings, the current at the end of the most recent injection. - \@time: - type: NX_CHAR - doc: | - Date and time of the most recent injection. - photon_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - The center photon energy of the source, before it is monochromatized or - converted - center_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The center wavelength of the source, before it is monochromatized or converted - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - For pulsed sources, the energy of a single pulse - peak_power(NX_FLOAT): - unit: NX_POWER - doc: | - For pulsed sources, the pulse energy divided by the pulse duration - bunch_number_start(NX_INT): - doc: | - Some facilities tag each bunch. First bunch of the measurement - bunch_number_end(NX_INT): - doc: | - Last bunch of the measurement - geometry(NXgeometry): - doc: | - 'Engineering' location of source - distribution(NXdata): - doc: | - The wavelength or energy distribution of the source - \@default: - doc: | - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. From a27237b348ef79694c8b1e25c5f2c0a3bcce3607 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 27 Apr 2023 09:56:59 +0200 Subject: [PATCH 139/203] regenerating NXsensor.yaml --- base_classes/nyaml/NXsensor.yaml | 269 ++++++++++++++++++++++++++----- 1 file changed, 233 insertions(+), 36 deletions(-) diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml index 2a07d35a13..f290ddbe79 100644 --- a/base_classes/nyaml/NXsensor.yaml +++ b/base_classes/nyaml/NXsensor.yaml @@ -1,68 +1,68 @@ category: base -doc: | +doc: | A sensor used to monitor an external condition - The condition itself is described in ':'ref':'`NXenvironment`. - + The condition itself is described in :ref:`NXenvironment`. type: group NXsensor(NXobject): model: - doc: | + doc: | Sensor identification code/model number name: - doc: | + doc: | Name for the sensor short_name: - doc: | + doc: | Short name of sensor used e.g. on monitor display program attached_to: - doc: | + doc: | where sensor is attached to ("sample" | "can") geometry(NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | + deprecated: + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | Defines the axes for logged vector quantities if they are not the global instrument axes. measurement: - doc: | + doc: | name for measured signal enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, current, pressure, flow, stress, strain, shear, surface_pressure] type: - doc: | + doc: | The type of hardware used for the measurement. - Examples (suggestions but not restrictions)':' + Examples (suggestions but not restrictions): - ':'Temperature':' + :Temperature: J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe - ':'pH':' + :pH: Hg/Hg2Cl2 | Ag/AgCl | ISFET - ':'Ion selective electrode':' + :Ion selective electrode: specify species; e.g. Ca2+ - ':'Magnetic field':' + :Magnetic field: Hall - ':'Surface pressure':' + :Surface pressure: wilhelmy plate run_control(NX_BOOLEAN): - doc: | - Is data collection controlled or synchronised to this quantity':' + doc: | + Is data collection controlled or synchronised to this quantity: 1=no, 0=to "value", 1=to "value_deriv1", etc. high_trip_value(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Upper control bound of sensor reading if using run_control low_trip_value(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Lower control bound of sensor reading if using run_control value(NX_FLOAT): unit: NX_ANY - doc: | + doc: | nominal setpoint or average value - need [n] as may be a vector dimensions: dim: [[1, n]] value_deriv1(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Nominal/average first derivative of value e.g. strain rate - same dimensions as "value" (may be a vector) @@ -72,7 +72,7 @@ NXsensor(NXobject): ref: ['value'] value_deriv2(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Nominal/average second derivative of value - same dimensions as "value" (may be a vector) dimensions: @@ -80,36 +80,36 @@ NXsensor(NXobject): dim_parameters: ref: ['value'] value_log(NXlog): - doc: | + doc: | Time history of sensor readings value_deriv1_log(NXlog): - doc: | + doc: | Time history of first derivative of sensor readings value_deriv2_log(NXlog): - doc: | + doc: | Time history of second derivative of sensor readings external_field_brief: enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] external_field_full(NXorientation): - doc: | + doc: | For complex external fields not satisfied by External_field_brief (NXoff_geometry): exists: ['min', '0'] - doc: | + doc: | This group describes the shape of the sensor when necessary. \@default: - doc: | - .. index':'':' plotting + doc: | + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + 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 + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. depends_on(NX_CHAR): - doc: | + doc: | NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations is critical and forms what NeXus calls a dependency chain. The depends_on @@ -117,11 +117,208 @@ NXsensor(NXobject): string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a sensor. (NXtransformations): - doc: | + doc: | This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e09b8ec8aaac9fdd491b083bd1ecdfc2d991f89e9fdb7aff06675009f14fcc69 +# +# +# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# Sensor identification code/model number +# +# +# Name for the sensor +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# Defines the axes for logged vector quantities if they are not the global instrument axes. +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# Time history of sensor readings +# +# +# Time history of first derivative of sensor readings +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# This group describes the shape of the sensor when necessary. +# +# +# +# +# .. 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. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# From d3474fe876048cffe87945bf4b960f429b154d8b Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 27 Apr 2023 13:49:33 +0200 Subject: [PATCH 140/203] Checked Sandors comments for apm, em, matwerk and consolidated with latest fixes needed for apm, em_om, and em_spctrscpy readers --- contributed_definitions/NXapm.nxdl.xml | 24 +- contributed_definitions/NXem.nxdl.xml | 6 +- contributed_definitions/NXem_ebsd.nxdl.xml | 13 +- .../NXimage_set_em.nxdl.xml | 107 -------- .../NXimage_set_em_bf.nxdl.xml | 9 - .../NXimage_set_em_bse.nxdl.xml | 9 - .../NXimage_set_em_chamber.nxdl.xml | 9 - .../NXimage_set_em_df.nxdl.xml | 9 - .../NXimage_set_em_diffrac.nxdl.xml | 9 - .../NXimage_set_em_ecci.nxdl.xml | 9 - .../NXimage_set_em_ronchigram.nxdl.xml | 12 - .../NXimage_set_em_se.nxdl.xml | 142 ---------- .../NXms_atom_set.nxdl.xml | 38 --- .../NXms_crystal_set.nxdl.xml | 144 ---------- .../NXms_dislocation_set.nxdl.xml | 101 ------- .../NXms_interface_set.nxdl.xml | 108 -------- .../NXspectrum_set_em_auger.nxdl.xml | 9 - .../NXspectrum_set_em_cathodolum.nxdl.xml | 9 - contributed_definitions/nyaml/NXapm.yaml | 22 +- contributed_definitions/nyaml/NXem.yaml | 2 + contributed_definitions/nyaml/NXem_ebsd.yaml | 10 +- .../nyaml/NXimage_set_em.yaml | 69 ----- .../nyaml/NXimage_set_em_bf.yaml | 19 -- .../nyaml/NXimage_set_em_bse.yaml | 19 -- .../nyaml/NXimage_set_em_chamber.yaml | 19 -- .../nyaml/NXimage_set_em_df.yaml | 19 -- .../nyaml/NXimage_set_em_diffrac.yaml | 19 -- .../nyaml/NXimage_set_em_ecci.yaml | 19 -- .../nyaml/NXimage_set_em_ronchigram.yaml | 25 -- .../nyaml/NXimage_set_em_se.yaml | 252 ------------------ .../nyaml/NXms_atom_set.yaml | 12 - .../nyaml/NXms_crystal_set.yaml | 129 --------- .../nyaml/NXms_dislocation_set.yaml | 119 --------- .../nyaml/NXms_interface_set.yaml | 106 -------- .../nyaml/NXspectrum_set_em_auger.yaml | 19 -- .../nyaml/NXspectrum_set_em_cathodolum.yaml | 19 -- 36 files changed, 49 insertions(+), 1616 deletions(-) delete mode 100644 contributed_definitions/NXimage_set_em.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_bf.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_bse.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_chamber.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_df.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_diffrac.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_ecci.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_se.nxdl.xml delete mode 100644 contributed_definitions/NXms_atom_set.nxdl.xml delete mode 100644 contributed_definitions/NXms_crystal_set.nxdl.xml delete mode 100644 contributed_definitions/NXms_dislocation_set.nxdl.xml delete mode 100644 contributed_definitions/NXms_interface_set.nxdl.xml delete mode 100644 contributed_definitions/NXspectrum_set_em_auger.nxdl.xml delete mode 100644 contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_bf.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_bse.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_chamber.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_df.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_ecci.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_se.yaml delete mode 100644 contributed_definitions/nyaml/NXms_atom_set.yaml delete mode 100644 contributed_definitions/nyaml/NXms_crystal_set.yaml delete mode 100644 contributed_definitions/nyaml/NXms_dislocation_set.yaml delete mode 100644 contributed_definitions/nyaml/NXms_interface_set.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 86a6a4e3e6..265367a226 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -104,8 +104,11 @@ to describe also the upcoming technique of atomic scale analytical tomography ht of reconstructed positions of certain ions. During ranging time-of-flight data are identified as representing specific ions to annotate each ion with a label. - Commercial software used in atom probe research is designed as an integrated acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which are proprietary and their file format specifications not publicly documented. + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. Supplementary metadata are kept in a database (formerly known as the ISDb) which is connected to the instrument control software and synced with the @@ -147,8 +150,9 @@ to describe also the upcoming technique of atomic scale analytical tomography ht key post-processing steps which transform the proprietary data into a tomographic reconstruction with ranging definitions. - Future guidance by the technology partners like AMETEK/Cameca could improve this description to cover a substantial larger number of eventually metadata that - so far are neither publicly documented nor accessible. + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. @@ -703,7 +707,7 @@ NEW ISSUE: see in WO2016171675A1 Invizo 6000 patent from AMETEK--> - + @@ -1213,7 +1217,7 @@ numerically the same voltage-and-bowl correction results are obtained Mass-to-charge-state ratio values. - + @@ -1297,7 +1301,10 @@ these methods are de facto application definitions.--> An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. The XDMF primitive type is here 1, the number of primitives 1 per triplet, the last integer in each triplet is the identifier of each point starting from zero. + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. @@ -1465,6 +1472,7 @@ NEW ISSUE: unit must match with range, is Da--> Right boundary of each mass-to-charge-state ratio value bin. + @@ -1522,7 +1530,7 @@ eventually processed via deconvolution methods--> - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 5ba5c62d1d..d322bc18e6 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1145,7 +1145,11 @@ is needed, will the rest be inferred automatically?--> Different technologies are in use like CCD, scintillator, direct electron, CMOS, or image plate to name but a few. - + + + Instrument-specific alias/name + + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 02094abac1..81164db97f 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -241,7 +241,7 @@ enumeration: [sha_256_hash]--> Program which was used for creating the file instance which is formatted according to the NXem_ebsd application definition. - + @@ -382,7 +382,7 @@ in every case data are Kikuchi diffraction pattern and their metadata--> - + @@ -689,7 +689,7 @@ rank: 1 production workflow how EBSD data are collected in materials engineering, in industry, and academia. - + @@ -1233,7 +1233,7 @@ is somehow connected to pyxem. NEED TO TALK TO DEVELOPERS HERE!--> which can be for some use cases the parser. Consider the explanations in the docstring of the ipf_mapID group. - + @@ -1631,7 +1631,7 @@ while for _indices fastest to fast--> which can be for some use cases the parser. Consider the explanations in the docstring of the ipf_mapID group. - + @@ -1921,6 +1921,5 @@ acquisition_speed(NX_FLOAT): Average number of patterns taken per second averaged over entire set. unit: NX_FREQUENCY acquisition_time(NX_FLOAT): - doc: Wall-clock time the acquisition took. - unit: NX_TIME--> + doc: Wall-clock time the acquisition took.--> diff --git a/contributed_definitions/NXimage_set_em.nxdl.xml b/contributed_definitions/NXimage_set_em.nxdl.xml deleted file mode 100644 index 5d46b05415..0000000000 --- a/contributed_definitions/NXimage_set_em.nxdl.xml +++ /dev/null @@ -1,107 +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 with an electron microscope. - - - - - Imaging mode in which the instrument was and with which the images - were captured. - - - - - - 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/NXimage_set_em_bf.nxdl.xml b/contributed_definitions/NXimage_set_em_bf.nxdl.xml deleted file mode 100644 index 066b2b3e46..0000000000 --- a/contributed_definitions/NXimage_set_em_bf.nxdl.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - Container for reporting a set of images taken in bright field mode. - - - - diff --git a/contributed_definitions/NXimage_set_em_bse.nxdl.xml b/contributed_definitions/NXimage_set_em_bse.nxdl.xml deleted file mode 100644 index 6c99db5649..0000000000 --- a/contributed_definitions/NXimage_set_em_bse.nxdl.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - Container for reporting a set of back-scattered electron images. - - - - diff --git a/contributed_definitions/NXimage_set_em_chamber.nxdl.xml b/contributed_definitions/NXimage_set_em_chamber.nxdl.xml deleted file mode 100644 index 09973347dc..0000000000 --- a/contributed_definitions/NXimage_set_em_chamber.nxdl.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - Container for images recorded with e.g. a TV camera in the microscope chamber. - - - - diff --git a/contributed_definitions/NXimage_set_em_df.nxdl.xml b/contributed_definitions/NXimage_set_em_df.nxdl.xml deleted file mode 100644 index f9c37cab96..0000000000 --- a/contributed_definitions/NXimage_set_em_df.nxdl.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - Container for reporting a set of images taken in dark field mode. - - - - diff --git a/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml b/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml deleted file mode 100644 index 7065a8a981..0000000000 --- a/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - Container for reporting a set of diffraction images. - - - - diff --git a/contributed_definitions/NXimage_set_em_ecci.nxdl.xml b/contributed_definitions/NXimage_set_em_ecci.nxdl.xml deleted file mode 100644 index 820ec8869f..0000000000 --- a/contributed_definitions/NXimage_set_em_ecci.nxdl.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - Container for reporting back-scattered electron channeling contrast images. - - - - diff --git a/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml b/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml deleted file mode 100644 index 8ab388cf25..0000000000 --- a/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml +++ /dev/null @@ -1,12 +0,0 @@ - - - - - Container for reporting a set of images related to a ronchigram. - - Ronchigrams are specifically used in transmission electron microscopy - to judge the settings for the aberration corrections and alignment. - - - - diff --git a/contributed_definitions/NXimage_set_em_se.nxdl.xml b/contributed_definitions/NXimage_set_em_se.nxdl.xml deleted file mode 100644 index a5ab12200b..0000000000 --- a/contributed_definitions/NXimage_set_em_se.nxdl.xml +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - - Number of images. - - - - - Number of pixels along the slow scan direction (often y). - - - - - Number of pixels along the fast scan direction (often x). - - - - - Container for reporting a set of secondary electron images. - - Secondary electron images are one of the most important signal especially - for scanning electron microscopy in materials science and engineering, for - analyses of surface topography, getting an overview of the analysis region, - or fractography. - - - - Collected secondary electron images (eventually as an image stack). - - - - - - - - - - Secondary electron image intensity - - - - - - - - - - Image identifier - - - - - - - - - - Label for the y axis - - - - - - - - - - Label for the x axis - - - - - - - Physical dimensions of the region-of-interest on - the specimen surface which the image covers. - The first and second number are the coordinates for the - minimum edge, the third and fourth number are the coordinates - for the maximum edge of the rectangular ROI. - - - - - - - - - - How many frames were averaged to obtain the image. - - - - - - - - Bias voltage applied to the e.g. Faraday cage in front of the - SE detector to attract or repell secondary electrons below - a specific kinetic energy. - - - - - Container to store relevant settings affecting beam path, - magnification, and working_distance - - - - - Scan rotation is an option offer by most control software. - - - - - Tilt correction is an option offered by most control software of SEMs - to apply an on-the-fly processing of the image to correct for - the excursion of objects when characterized with SE images - on samples whose surface normal is tilted about an axis perpendicular - to the optical axis. - - - - Was the option switched active or not. - - - - - - Dynamic focus is an option offered by most control software of SEMs - to keep the image also focused when probing locations on the specimens - beyond those for which the lens system was calibrated. - - - - Was the option switched active or not. - - - - diff --git a/contributed_definitions/NXms_atom_set.nxdl.xml b/contributed_definitions/NXms_atom_set.nxdl.xml deleted file mode 100644 index 2367448b6d..0000000000 --- a/contributed_definitions/NXms_atom_set.nxdl.xml +++ /dev/null @@ -1,38 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - A base class to wrap details about a spatial configuration of atoms. - - - - Atom positions. - - - diff --git a/contributed_definitions/NXms_crystal_set.nxdl.xml b/contributed_definitions/NXms_crystal_set.nxdl.xml deleted file mode 100644 index ae57ebde28..0000000000 --- a/contributed_definitions/NXms_crystal_set.nxdl.xml +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the description. - - - - - The number of objects, which can be crystals, grains, phases or phase field - regions. - - - - - Base class to describe data about observed crystals in microstructures. - - Both experiments and computer simulations support that atoms organize into regions - which are often separated and interconnected by different types of crystal defects. - Crystalline regions show a long-range periodic arrangement (compared to the - length scale of nearest neighbor distances). - Although the group of atoms forming a crystal is virtually never static, due - to diffusive in- and outflux of atoms and thermal fluctuations of the atoms - about their equilibrium positions, crystals are relevant persistent features - in microstructures. The size of crystals can span orders of magnitude from - meters to nanometers. - - There are two different and (somewhat extremal) views on crystals and how to - describe their eventually very rich variety of internal defects. Either - crystals can be coarse-grained into continuum objects or not. In the second case - they need a more advanced internal description of defects inside the grains - which convinces many that eventually a grain has to be viewed from its - individual atoms, its material points, and the hierarchy of structural motifs - local arrangements in the crystal. - - Despite these details, identifying crystals is foremost a labeling task. - Atoms are clustered into structural motifs and (noise) and these motifs - are again clustered into crystals. - - There are two main approaches how crystals are described in mesoscale - microstructure evolution simulations. Assuming for now transformations in the - solid state, precipitates, phase regions, sub-grains or grains are examples - of crystals: - - * Objects are either tracked explicitly in the sense that their shape will - be resolved through the crystal interfaces using e.g. a phase-field, - level-set, grid, or finite element mesh based models and implementations. - These simulations may keep track of explicit crystal/grain/object-related - quantities. Such models can treat the interface network implicitly while - still focusing their description on the explicit crystals. - During such simulations the interface is often analyzed on-the-fly, - because of technical demands (like in level-set implementations) or to - trigger specific situations where it is relevant to resolve the - position of the interfaces explicitly (like for placing seeds for phases, - recrystallizing grains etc, or for visualization purposes), demand a - description of interfaces between crystals. - For explicitly tracking simulations this base class can be applied as is. - * Objects are tracked implicitly in the sense that the computational domain - is discretized into an ensemble of what one can call material points. - Such models can be described at different length scale: On the one hand - where atom dynamics are (whether the assumption is substantiated or not) - homogenized/-able already or not. Each material point is assumed to have - at least one associated constitutive phase. - Such simulations usually do not/cannot resolve crystal-related quantities - without executing an on-the-fly post-processing of snapshot data from - which the spatial representation of the crystal is recovered. - An important case are large-strain formalism crystal plasticity methods. - Here the initial configuration represents most frequently material points - on a regular grid. Within the course of the simulation this grid gets - deformed implicitly. The code internally keeps no track of how the cells/ - material points of what is essentially a Voronoi tessellation, are deformed. - Only in the case when one would like to visualize the deformed configuration, - a post-processing of the simulation snapshot data is executed which - recovers the positions of the material points in the deformed configuration - in the laboratory coordinate system from which one can then extract a - representation of grains/precipitates, i.e. crystals. - It is a signature of such simulations that quantities like orientation - are defined as material point quantities. This means what constitutes the grain - needs to be extracted by cluster analyses. - In this regard, such simulation are essentially matching the representation and - case of molecular dynamics simulations, with the important difference - that these track atoms, from whose configuration - in a snapshot a description has to be computed what are most likely the - atoms that belong to the volume of the crystal or the interface/defect - network. - - - - - - Integer which specifies the first index to be used for distinguishing - objects. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish objects for explicit indexing. - - - - - - - - Depending on the value of dimensionality, the area or volume of each object. - - - - - - diff --git a/contributed_definitions/NXms_dislocation_set.nxdl.xml b/contributed_definitions/NXms_dislocation_set.nxdl.xml deleted file mode 100644 index 8e42f40d58..0000000000 --- a/contributed_definitions/NXms_dislocation_set.nxdl.xml +++ /dev/null @@ -1,101 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Base class to describe details about dislocations observed in microstructures. - - Dislocations are one-dimensional crystal defects whose primary interest is - that they are the carrier of plastic deformation. Conceptually dislocations - are a continuum-scale description of how atoms arrange spatio-temporally on - the one hand as a persistent defect which on the other hand though, when - inspected in detail for the atom dynamics and their interaction with other - crystal defects manifest as an involved microstructural feature for which - very different descriptions are used depending which length-, time-scale, - and research question people address. - - This is manifested in the large amount of literature on the topic: - - * https://www.sciencedirect.com/bookseries/dislocations-in-solids - - Dislocations are one prominent group of representatives for one-dimensional - features, other defects include disconnections and/or disclinations, and even - more complicated configurations, especially when one considers not-necessarily - crystalline materials, quasi crystals. It would be rude to claim that a single - base class can encompass the entire complexity that this effectively - coarse-graining of atomic spatio-temporal configurations has, in an effort - to simplicify the description in the hope to arrive at physical models which - do not need to take into account the location and movement of every atom. - - However, it is also a fact that not every description, research question, and - thus use cases that one could think of what one should store as data and metadata - for one-dimensional, primarily line-type crystal defects, is equally relevant - for an ensemble of research studies. - - Thus, for the design of concrete schemata for the purpose of structured storage - of research data on dislocations or studies where dislocations are measured - or characterized, one has to prioritize which descriptors and aspects about - dislocations are likely relevant for a large number of users of a research - infrastructure. Consequently, it is possible to narrow down the scope of - the base class and application definition. - - It is noteworthy to mention that this applies not only to description - using NeXus, but points to the problem of creating a golden-bullet schema - capable of handling all possible subtleties. - - For now we have to accept that is not yet an ontology of e.g. the above - understanding of what dislocations are. Pragmatically we thus make the - following assumptions: - - * This base class is essentially a template how specific often referred - quantities for one-dimensional crystal defects can be stored. - * In practice dislocations have a finite length as they are embedded in a - finite specimen and wired into an ensemble of adjoining dislocations - or other adjoining crystal defects. - * There are the following general approaches of studying/characterizing - * 1. Indirect measurements where dislocations characterized statistically. - In this case different types of dislocations are distinguished - (geometrically-necessary, mobile, immobile), mainly motivated by - different constitutive, continuum-models how they are threated in - computer simulations with respect to what their effect is on ms evolution. - * 2. Electron microscopy measurements of single or several dislocation (bundles) - In this case post-processing strategies are necessary which can - extract statistical descriptors or d-dimensional reconstructions - * 3. Atomic-scale-resolved simulations. In this case the most frequently - performed tasks are again post-processing into polyline networks, - detailed local investigations of the atomic configurations, or both - with or without some correlation. - * 4. Analytical approaches whereby dislocations are resolved at the continuum - scale, as line defects containing other elementary defects (for instance) - in models of disconnection motion), or again atomically resolved treatments. - - From this we can conclude that an NXms_dislocation_set can primarily be - useful as a wrapper class in which specific details about dislocations - can be stored in an arbitrarily nested manner. - - diff --git a/contributed_definitions/NXms_interface_set.nxdl.xml b/contributed_definitions/NXms_interface_set.nxdl.xml deleted file mode 100644 index bdea106fca..0000000000 --- a/contributed_definitions/NXms_interface_set.nxdl.xml +++ /dev/null @@ -1,108 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Base class to describe details about interfaces observed in microstructures. - - Classically, interfaces are two-dimensional crystal defects whose relevance is - that they are agents which trigger crystal growth and discontinuities of the - crystal at which defects can accumulate and solutes segregate with fundamental - effect on the properties of materials. Conceptually, interfaces are a - continuum-scale description of how atoms arrange spatio-temporally. Interfaces - manifests as persistent defects. When inspected in more detail though they show - atom dynamics, coarse-grainable into again interactions between line-type - crystal defects (disconnections) through which interfaces are dynamic and can - interact with other defects. Owing to this complexity very different - descriptions are used depending on which length-, time-scale, - and research question people address. - - This is manifested in the large amount of literature on the topic: - - * A. P. Sutton et al. ISBN-13 978-0198500612 - * G. Gottstein et al. ISBN-13 978-1-4200-5436-1 - * K. Chen et al. https://doi.org/10.1073/pnas.1920504117 - - Interfaces, specifically grain and phase boundaries, are representatives of - two-dimensional microstructural features. It would be rude to claim that a single - base class can encompass the entire complexity that this effective - coarse-graining of atomic spatio-temporal configurations has. In the end, - interfaces are a model, an effort to simplicify the description in the hope - to arrive at physical models which do not need to take into account the static - and dynamic details of every atom. - - However, it is also a fact that not every description, research question, and - thus use cases that one could think of storing as data and metadata for - interfaces, is equally relevant and useful for an ensemble of research studies. - - Thus, for the design of concrete schemes for a structured storage of data on - interfaces are measured or characterized, one has to prioritize which - descriptors and aspects about interfaces are likely relevant for a large - number of users of the research infrastructure. Consequently, it is possible - to narrow down the scope of this base class. - - It is noteworthy to mention that this applies not only to schemes build - with NeXus, but points to the problem of creating a golden-bullet schema - that could handle all possible subtleties of interfaces. - - For now we have to accept that there is not yet an ontology of e.g. the - above-mentioned understanding of what interfaces are. - - Pragmatically we thus make the following assumptions: - - * This base class is essentially a template how specific, often referred to - quantities, for two-dimensional crystal defects can be stored. - * Coarse-graining point-like features into a curve or surfaces is an - ill-posed problem. In practice, it has to be accounted for that interfaces - have a finite extent, they are delineated by triple lines and quadruple - junctions. Interfaces are thus connected into a three-dimensional network - of defects. Interfaces can interact or intersect with other defects - (partially or completely, as it is the case for disconnections). - - There are the following general approaches of studying/characterizing: - - * Non-atomically resolved measurements of 2D or 3D sections. - Examples are optical, electron, X-ray, or atom probe microscopy. - * Under specific conditions using electron microscopy, electron tomography - (provided numerical post-processing is applied) as well as with atom probe - microscopy these measurement can resolve structural motifs of or in the - interface plane. - * Atomic-scale-resolved simulations. In this case the most frequently - performed tasks are again post-processing snapshots with grain identification - or graph-based techniques to identify which atoms belong to the regions - with local changes or breakdown of the long-range crystal symmetry. - * Analytical approaches whereby grain boundaries are resolved at the continuum - scale, as surface defects containing other elementary defects (for instance) - in models of disconnection motion), using eventual statistical approaches, - or again atomically resolved treatments. - - From this we can conclude that an NXms_interface_set can primarily be - useful as a wrapper class in which specific details about interfaces - can be stored in an arbitrarily nested manner. - - diff --git a/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml b/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml deleted file mode 100644 index e41ce1a860..0000000000 --- a/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - Container for reporting a set of auger electron energy spectra. - - - - diff --git a/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml b/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml deleted file mode 100644 index 20ce7bf72d..0000000000 --- a/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - Container for reporting a set of cathodoluminescence spectra. - - - - diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 8717951b63..eae1def06e 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -12,8 +12,11 @@ doc: | of reconstructed positions of certain ions. During ranging time-of-flight data are identified as representing specific ions to annotate each ion with a label. - Commercial software used in atom probe research is designed as an integrated acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which are proprietary and their file format specifications not publicly documented. + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. Supplementary metadata are kept in a database (formerly known as the ISDb) which is connected to the instrument control software and synced with the @@ -55,8 +58,9 @@ doc: | key post-processing steps which transform the proprietary data into a tomographic reconstruction with ranging definitions. - Future guidance by the technology partners like AMETEK/Cameca could improve this description to cover a substantial larger number of eventually metadata that - so far are neither publicly documented nor accessible. + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. symbols: doc: The symbols used in the schema to specify e.g. dimensions of arrays. n_ions: Total number of ions collected. @@ -593,7 +597,7 @@ NXapm: exists: recommended (NXcsg): exists: optional - LASER_SOURCE(NXsource): + SOURCE(NXsource): exists: [min, 0, max, 2] # INVIZO 6000 instrument have two symmetric lasers! so for these # laser_gun and laser_beam exists: [min, 0, max, 2] @@ -1120,7 +1124,7 @@ NXapm: doc: | Mass-to-charge-state ratio values. unit: NX_ANY - # \@units: Da + # \@units: Da / a unitless quantity because it is the charge state and not the charge dimensions: rank: 1 dim: [[1, n_ions]] @@ -1190,7 +1194,10 @@ NXapm: xdmf_topology(NX_UINT): doc: | An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. The XDMF primitive type is here 1, the number of primitives 1 per triplet, the last integer in each triplet is the identifier of each point starting from zero. + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. unit: NX_UNITLESS dimensions: rank: 1 @@ -1335,6 +1342,7 @@ NXapm: doc: | Right boundary of each mass-to-charge-state ratio value bin. unit: NX_ANY + # \@units: Da dimensions: rank: 1 dim: [[1, n_bins]] diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 86e616c11a..8bce61967d 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -1379,6 +1379,8 @@ NXem: Different technologies are in use like CCD, scintillator, direct electron, CMOS, or image plate to name but a few. local_name: + doc: | + Instrument-specific alias/name (NXfabrication): # it is unfortunate that for NXdetector there are already many places # how one can specify details which could equally end up in fabrications diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 44638e4335..2c9a1b72d2 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -185,7 +185,7 @@ NXem_ebsd: doc: | Program which was used for creating the file instance which is formatted according to the NXem_ebsd application definition. - program_name: + program: \@version: (NXuser): exists: [min, 0, max, infty] @@ -306,7 +306,7 @@ NXem_ebsd: sequence_index(NX_POSINT): # 1 (NXprogram): exists: [min, 0, max, infty] - program_name: + program: \@version: (NXcg_geodesic_mesh): exists: [min, 0, max, infty] @@ -592,7 +592,7 @@ NXem_ebsd: microscope was capturing (on-the-fly). This is the usual production workflow how EBSD data are collected in materials engineering, in industry, and academia. - program_name: + program: \@version: origin: doc: | @@ -1098,7 +1098,7 @@ NXem_ebsd: which performs the computation of the inverse pole figure mappings which can be for some use cases the parser. Consider the explanations in the docstring of the ipf_mapID group. - program_name: + program: \@version: # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] @@ -1442,7 +1442,7 @@ NXem_ebsd: which performs the computation of the inverse pole figure mappings which can be for some use cases the parser. Consider the explanations in the docstring of the ipf_mapID group. - program_name: + program: \@version: # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] diff --git a/contributed_definitions/nyaml/NXimage_set_em.yaml b/contributed_definitions/nyaml/NXimage_set_em.yaml deleted file mode 100644 index 9acd6e6fb2..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em.yaml +++ /dev/null @@ -1,69 +0,0 @@ -category: base -doc: | - Container for reporting a set of images taken with an electron microscope. -symbols: - n_images: Number of images in the stack. - n_y: Number of pixel per image in the slow direction. - n_x: Number of pixel per image in the fast direction. -NXimage_set_em: - (NXprocess): - doc: | - Details how images were processed from the detector readings. - source: - doc: | - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXimage_set_em were loaded during - parsing to represent them in e.g. databases. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - program: - doc: | - Commercial or otherwise given name to the program which was used - to process detector data into the adf image(s). - \@version: - doc: | - Program 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. - (NXprocess): - mode: - doc: | - Imaging mode in which the instrument was and with which the images - were captured. - stack(NXdata): - doc: | - Image (stack). - data_counts(NX_NUMBER): - doc: Image intensity values. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_image_identifier(NX_UINT): - doc: Image identifier - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_images]] - \@long_name: - doc: Image identifier. - axis_y(NX_NUMBER): - doc: Pixel coordinate center of mass along y direction. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: Coordinate along y direction. - axis_x(NX_NUMBER): - doc: Pixel coordinate center of mass along x direction. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_set_em_bf.yaml b/contributed_definitions/nyaml/NXimage_set_em_bf.yaml deleted file mode 100644 index 18f462d3f5..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_bf.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Container for reporting a set of images taken in bright field mode. -type: group -(NXobject)NXimage_set_em_bf: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 97b1cbbb65471ab425b7b56afe4fb7656087e13682a01527eb0f8c479b4afde0 -# -# -# -# -# Container for reporting a set of images taken in bright field mode. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set_em_bse.yaml b/contributed_definitions/nyaml/NXimage_set_em_bse.yaml deleted file mode 100644 index 80b5de171f..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_bse.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Container for reporting a set of back-scattered electron images. -type: group -(NXobject)NXimage_set_em_bse: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# dd6e820f87f0f28d05c4b326a9c7c10182844dca68f531c96c53f23f9e032404 -# -# -# -# -# Container for reporting a set of back-scattered electron images. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml b/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml deleted file mode 100644 index 34c00c6c72..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_chamber.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Container for images recorded with e.g. a TV camera in the microscope chamber. -type: group -(NXobject)NXimage_set_em_chamber: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d7cf1580a93b0e7d3e0707fd6c0755ea4cc2088b1fa90bb7103e7944cb2cb023 -# -# -# -# -# Container for images recorded with e.g. a TV camera in the microscope chamber. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set_em_df.yaml b/contributed_definitions/nyaml/NXimage_set_em_df.yaml deleted file mode 100644 index c92af257c5..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_df.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Container for reporting a set of images taken in dark field mode. -type: group -(NXobject)NXimage_set_em_df: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ae023c1522bd25c3f09b11c773b64dffc20163523750045d878d5aefd181d0d6 -# -# -# -# -# Container for reporting a set of images taken in dark field mode. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml b/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml deleted file mode 100644 index d34c9bb5fe..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_diffrac.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Container for reporting a set of diffraction images. -type: group -(NXobject)NXimage_set_em_diffrac: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8ed8592c148009db926f1d317b7a02c479604c26664cf5da49619911b4c171d6 -# -# -# -# -# Container for reporting a set of diffraction images. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml b/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml deleted file mode 100644 index 917171d918..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_ecci.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Container for reporting back-scattered electron channeling contrast images. -type: group -(NXobject)NXimage_set_em_ecci: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8bab1f8cdf185ad16552fff19483fc7336a544e55ae323b2c3d1b7106c60848f -# -# -# -# -# Container for reporting back-scattered electron channeling contrast images. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml b/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml deleted file mode 100644 index 06fa6aa369..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_ronchigram.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Container for reporting a set of images related to a ronchigram. - - Ronchigrams are specifically used in transmission electron microscopy - to judge the settings for the aberration corrections and alignment. -type: group -(NXobject)NXimage_set_em_ronchigram: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f11728363f198092b5506064b30ea5e65cea08e628d4b8c7d1f5e2241bd57dcb -# -# -# -# -# Container for reporting a set of images related to a ronchigram. -# -# Ronchigrams are specifically used in transmission electron microscopy -# to judge the settings for the aberration corrections and alignment. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set_em_se.yaml b/contributed_definitions/nyaml/NXimage_set_em_se.yaml deleted file mode 100644 index 03cd5e92a7..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_se.yaml +++ /dev/null @@ -1,252 +0,0 @@ -category: base -doc: | - Container for reporting a set of secondary electron images. - - Secondary electron images are one of the most important signal especially - for scanning electron microscopy in materials science and engineering, for - analyses of surface topography, getting an overview of the analysis region, - or fractography. -symbols: - n_images: | - Number of images. - n_y: | - Number of pixels along the slow scan direction (often y). - n_x: | - Number of pixels along the fast scan direction (often x). -type: group -(NXobject)NXimage_set_em_se: - (NXdata): - doc: | - Collected secondary electron images (eventually as an image stack). - intensity(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_p], [2, n_y], [3, n_x]] - \@long_name: - type: NX_CHAR - doc: | - Secondary electron image intensity - image_id(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_p]] - \@long_name: - type: NX_CHAR - doc: | - Image identifier - ypos(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - type: NX_CHAR - doc: | - Label for the y axis - xpos(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - type: NX_CHAR - doc: | - Label for the x axis - roi(NX_NUMBER): - unit: NX_LENGTH - doc: | - Physical dimensions of the region-of-interest on - the specimen surface which the image covers. - The first and second number are the coordinates for the - minimum edge, the third and fourth number are the coordinates - for the maximum edge of the rectangular ROI. - dimensions: - rank: 2 - dim: [[1, n_images], [2, 4]] - dwell_time(NX_FLOAT): - unit: NX_TIME - number_of_frames_averaged(NX_UINT): - unit: NX_UNITLESS - doc: | - How many frames were averaged to obtain the image. - dimensions: - rank: 1 - dim: [[1, n_images]] - bias_voltage(NX_FLOAT): - doc: | - Bias voltage applied to the e.g. Faraday cage in front of the - SE detector to attract or repell secondary electrons below - a specific kinetic energy. - (NXoptical_system_em): - exists: optional - doc: | - Container to store relevant settings affecting beam path, - magnification, and working_distance - scan_rotation(NXprocess): - doc: | - Scan rotation is an option offer by most control software. - tilt_correction(NXprocess): - doc: | - Tilt correction is an option offered by most control software of SEMs - to apply an on-the-fly processing of the image to correct for - the excursion of objects when characterized with SE images - on samples whose surface normal is tilted about an axis perpendicular - to the optical axis. - active(NX_BOOLEAN): - doc: | - Was the option switched active or not. - dynamic_focus(NXprocess): - doc: | - Dynamic focus is an option offered by most control software of SEMs - to keep the image also focused when probing locations on the specimens - beyond those for which the lens system was calibrated. - active(NX_BOOLEAN): - doc: | - Was the option switched active or not. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e840afac66f17f804831854d8f4a942ec96a646e3eed57dcd48e6c66ab5d552c -# -# -# -# -# -# -# Number of images. -# -# -# -# -# Number of pixels along the slow scan direction (often y). -# -# -# -# -# Number of pixels along the fast scan direction (often x). -# -# -# -# -# Container for reporting a set of secondary electron images. -# -# Secondary electron images are one of the most important signal especially -# for scanning electron microscopy in materials science and engineering, for -# analyses of surface topography, getting an overview of the analysis region, -# or fractography. -# -# -# -# Collected secondary electron images (eventually as an image stack). -# -# -# -# -# -# -# -# -# -# Secondary electron image intensity -# -# -# -# -# -# -# -# -# -# Image identifier -# -# -# -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# -# Physical dimensions of the region-of-interest on -# the specimen surface which the image covers. -# The first and second number are the coordinates for the -# minimum edge, the third and fourth number are the coordinates -# for the maximum edge of the rectangular ROI. -# -# -# -# -# -# -# -# -# -# How many frames were averaged to obtain the image. -# -# -# -# -# -# -# -# Bias voltage applied to the e.g. Faraday cage in front of the -# SE detector to attract or repell secondary electrons below -# a specific kinetic energy. -# -# -# -# -# Container to store relevant settings affecting beam path, -# magnification, and working_distance -# -# -# -# -# Scan rotation is an option offer by most control software. -# -# -# -# -# Tilt correction is an option offered by most control software of SEMs -# to apply an on-the-fly processing of the image to correct for -# the excursion of objects when characterized with SE images -# on samples whose surface normal is tilted about an axis perpendicular -# to the optical axis. -# -# -# -# Was the option switched active or not. -# -# -# -# -# -# Dynamic focus is an option offered by most control software of SEMs -# to keep the image also focused when probing locations on the specimens -# beyond those for which the lens system was calibrated. -# -# -# -# Was the option switched active or not. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXms_atom_set.yaml b/contributed_definitions/nyaml/NXms_atom_set.yaml deleted file mode 100644 index 61cc2be11a..0000000000 --- a/contributed_definitions/nyaml/NXms_atom_set.yaml +++ /dev/null @@ -1,12 +0,0 @@ -category: base -doc: | - A base class to wrap details about a spatial configuration of atoms. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXms_atom_set: - (NXcg_point_set): - doc: Atom positions. - # the application-definition specific NXcg_point_set instance - # should be extended then by a field type(NX_UINT): - # we need a case-dependent discussion with e.g. Joseph, Nathan, and Luca - # on time-tracking of atom sets diff --git a/contributed_definitions/nyaml/NXms_crystal_set.yaml b/contributed_definitions/nyaml/NXms_crystal_set.yaml deleted file mode 100644 index b9da729eef..0000000000 --- a/contributed_definitions/nyaml/NXms_crystal_set.yaml +++ /dev/null @@ -1,129 +0,0 @@ -category: base -doc: | - Base class to describe data about observed crystals in microstructures. - - Both experiments and computer simulations support that atoms organize into regions - which are often separated and interconnected by different types of crystal defects. - Crystalline regions show a long-range periodic arrangement (compared to the - length scale of nearest neighbor distances). - Although the group of atoms forming a crystal is virtually never static, due - to diffusive in- and outflux of atoms and thermal fluctuations of the atoms - about their equilibrium positions, crystals are relevant persistent features - in microstructures. The size of crystals can span orders of magnitude from - meters to nanometers. - - There are two different and (somewhat extremal) views on crystals and how to - describe their eventually very rich variety of internal defects. Either - crystals can be coarse-grained into continuum objects or not. In the second case - they need a more advanced internal description of defects inside the grains - which convinces many that eventually a grain has to be viewed from its - individual atoms, its material points, and the hierarchy of structural motifs - local arrangements in the crystal. - - Despite these details, identifying crystals is foremost a labeling task. - Atoms are clustered into structural motifs and (noise) and these motifs - are again clustered into crystals. - - There are two main approaches how crystals are described in mesoscale - microstructure evolution simulations. Assuming for now transformations in the - solid state, precipitates, phase regions, sub-grains or grains are examples - of crystals: - - * Objects are either tracked explicitly in the sense that their shape will - be resolved through the crystal interfaces using e.g. a phase-field, - level-set, grid, or finite element mesh based models and implementations. - These simulations may keep track of explicit crystal/grain/object-related - quantities. Such models can treat the interface network implicitly while - still focusing their description on the explicit crystals. - During such simulations the interface is often analyzed on-the-fly, - because of technical demands (like in level-set implementations) or to - trigger specific situations where it is relevant to resolve the - position of the interfaces explicitly (like for placing seeds for phases, - recrystallizing grains etc, or for visualization purposes), demand a - description of interfaces between crystals. - For explicitly tracking simulations this base class can be applied as is. - * Objects are tracked implicitly in the sense that the computational domain - is discretized into an ensemble of what one can call material points. - Such models can be described at different length scale: On the one hand - where atom dynamics are (whether the assumption is substantiated or not) - homogenized/-able already or not. Each material point is assumed to have - at least one associated constitutive phase. - Such simulations usually do not/cannot resolve crystal-related quantities - without executing an on-the-fly post-processing of snapshot data from - which the spatial representation of the crystal is recovered. - An important case are large-strain formalism crystal plasticity methods. - Here the initial configuration represents most frequently material points - on a regular grid. Within the course of the simulation this grid gets - deformed implicitly. The code internally keeps no track of how the cells/ - material points of what is essentially a Voronoi tessellation, are deformed. - Only in the case when one would like to visualize the deformed configuration, - a post-processing of the simulation snapshot data is executed which - recovers the positions of the material points in the deformed configuration - in the laboratory coordinate system from which one can then extract a - representation of grains/precipitates, i.e. crystals. - It is a signature of such simulations that quantities like orientation - are defined as material point quantities. This means what constitutes the grain - needs to be extracted by cluster analyses. - In this regard, such simulation are essentially matching the representation and - case of molecular dynamics simulations, with the important difference - that these track atoms, from whose configuration - in a snapshot a description has to be computed what are most likely the - atoms that belong to the volume of the crystal or the interface/defect - network. -# for implicitly tracking simulation one can also argue that as -# one anyway needs to do post-processing to extract at all what the grains -# one could also group fields from this base class into an NXprocess -# the fundamental problem making a decision is that depending on which -# model and implementation is used some of these post-processes are -# executed on-the-fly, so from the perspective of an application definition -# the internal workflows in the software are irrelevant but instead one -# just cares what is reported as a result from the software -# !!! this example nicely shows that drafting an application definition is -# !!! eventually also demanding to make a somewhat arbitrary cutting of the -# !!! workflow steps, tag this sub-workflow as some entity -# !!! (e.g. the phase field simulation) -# !!! and thus have application definitions that merely assure specific data -# !!! are passed into this sub-graph or expect as output from the sub-graph -# !!! in a particular application -# a general enough phase-field description needs to account for the -# fact that not necessarily each region is crystalline -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - d: The dimensionality of the description. - n_objects: The number of objects, which can be crystals, grains, phases or phase field regions. -# how can we elegantly implement that in simulations and situations where the number -# of objects remains static there is no need to store identifiers several times? -NXms_crystal_set: - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_objects(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - objects. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: Integer used to distinguish objects for explicit indexing. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_objects]] - object_size(NX_NUMBER): - doc: Depending on the value of dimensionality, the area or volume of each object. - dimensions: - rank: 1 - dim: [[1, n_objects]] - # add further object specific properties - # (NXorientation_set): - # (NXms_dislocation_set): - # (NXms_boundary_set): - # (NXms_triple_line_set): - # (NXms_quadruple_junction_set): diff --git a/contributed_definitions/nyaml/NXms_dislocation_set.yaml b/contributed_definitions/nyaml/NXms_dislocation_set.yaml deleted file mode 100644 index f0fe08f36f..0000000000 --- a/contributed_definitions/nyaml/NXms_dislocation_set.yaml +++ /dev/null @@ -1,119 +0,0 @@ -category: base -doc: | - Base class to describe details about dislocations observed in microstructures. - - Dislocations are one-dimensional crystal defects whose primary interest is - that they are the carrier of plastic deformation. Conceptually dislocations - are a continuum-scale description of how atoms arrange spatio-temporally on - the one hand as a persistent defect which on the other hand though, when - inspected in detail for the atom dynamics and their interaction with other - crystal defects manifest as an involved microstructural feature for which - very different descriptions are used depending which length-, time-scale, - and research question people address. - - This is manifested in the large amount of literature on the topic: - - * https://www.sciencedirect.com/bookseries/dislocations-in-solids - - Dislocations are one prominent group of representatives for one-dimensional - features, other defects include disconnections and/or disclinations, and even - more complicated configurations, especially when one considers not-necessarily - crystalline materials, quasi crystals. It would be rude to claim that a single - base class can encompass the entire complexity that this effectively - coarse-graining of atomic spatio-temporal configurations has, in an effort - to simplicify the description in the hope to arrive at physical models which - do not need to take into account the location and movement of every atom. - - However, it is also a fact that not every description, research question, and - thus use cases that one could think of what one should store as data and metadata - for one-dimensional, primarily line-type crystal defects, is equally relevant - for an ensemble of research studies. - - Thus, for the design of concrete schemata for the purpose of structured storage - of research data on dislocations or studies where dislocations are measured - or characterized, one has to prioritize which descriptors and aspects about - dislocations are likely relevant for a large number of users of a research - infrastructure. Consequently, it is possible to narrow down the scope of - the base class and application definition. - - It is noteworthy to mention that this applies not only to description - using NeXus, but points to the problem of creating a golden-bullet schema - capable of handling all possible subtleties. - - For now we have to accept that is not yet an ontology of e.g. the above - understanding of what dislocations are. Pragmatically we thus make the - following assumptions: - - * This base class is essentially a template how specific often referred - quantities for one-dimensional crystal defects can be stored. - * In practice dislocations have a finite length as they are embedded in a - finite specimen and wired into an ensemble of adjoining dislocations - or other adjoining crystal defects. - * There are the following general approaches of studying/characterizing - * 1. Indirect measurements where dislocations characterized statistically. - In this case different types of dislocations are distinguished - (geometrically-necessary, mobile, immobile), mainly motivated by - different constitutive, continuum-models how they are threated in - computer simulations with respect to what their effect is on ms evolution. - * 2. Electron microscopy measurements of single or several dislocation (bundles) - In this case post-processing strategies are necessary which can - extract statistical descriptors or d-dimensional reconstructions - * 3. Atomic-scale-resolved simulations. In this case the most frequently - performed tasks are again post-processing into polyline networks, - detailed local investigations of the atomic configurations, or both - with or without some correlation. - * 4. Analytical approaches whereby dislocations are resolved at the continuum - scale, as line defects containing other elementary defects (for instance) - in models of disconnection motion), or again atomically resolved treatments. - - From this we can conclude that an NXms_dislocation_set can primarily be - useful as a wrapper class in which specific details about dislocations - can be stored in an arbitrarily nested manner. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXms_dislocation_set: -# doc: A starting point for the discussion. - -# doc: Needs to be extended based on the NXannealing appdef. -# lets sketch for each of the four above-mentioned frequent use cases what -# could be relevant to be nested inside such base classes -# !!! here we really need to discuss if these many options -# !!! warrant necessary deeper nesting or further splitting of the base class -# !!! essentially pseudo-code yaml follows !!! -# USE CASE statistical treatments -# (NXslip_system_set): -# for each slip system one would add -# symbols: -# n_types: Number of different types. -# density(NX_NUMBER): -# doc: Dislocation density as number of dislocations per unit area. -# dimensions: -# rank: 1 -# dim: [[1, n_types]] -# USE CASE spatially-resolved -# (NXcg_point_set): # !!! should one at all consider any longer 2D or 2.5D simulations... -# (NXcg_polyline_set): -# for each polyline eventual further properties like mobility etc. -# USE CASE analytical treatment -# !!! there is no clear separation between these use case -# one might also just want to store elementary properties of dislocations in the set -# burgers_vector(NX_NUMBER): -# doc: Burgers vector -# dimensions: -# rank: 2 -# dim: [[1, n], [2, 3]] -# line_element(NX_NUMBER): # but the line element for a general dislocation -# is a position dependent quantity, expect for the very specific text book -# simple configuration like straight edge and straight screw dislocations -# !!! especially for analytical treatment one may resolve individual dislocations -# at the continuu-scale using some domain, discretized and analyze the strain and stress fields, -# solute concentrations -# !!! admittedly these combinations and configurations are very specific for a research study -# !!! however, this can not be an excuse for aiming at a controlled and shared vocabulary to use -# !!! otherwise how should a machine ever understand how jog is different to kink -# !!! especially in theoretical analyses at the continuum-scale it has been frequently -# discussed that dislocations host an ensemble of other defects along their, jogs, kinks, stacking faults, -# core structure anomalies, the point is again they either have to be measured or simulated -# and this results in either a description at the continuum-scale or based on the atomic architecture and dynamics -# often thermodynamics are used to describe ensemble statistics about these defects along the dislocation line -# or of the dislocation network, a distinction, which is especially in the research on recovery phenomena, oftentimes not well separated. diff --git a/contributed_definitions/nyaml/NXms_interface_set.yaml b/contributed_definitions/nyaml/NXms_interface_set.yaml deleted file mode 100644 index c2028f6e7c..0000000000 --- a/contributed_definitions/nyaml/NXms_interface_set.yaml +++ /dev/null @@ -1,106 +0,0 @@ -category: base -doc: | - Base class to describe details about interfaces observed in microstructures. - - Classically, interfaces are two-dimensional crystal defects whose relevance is - that they are agents which trigger crystal growth and discontinuities of the - crystal at which defects can accumulate and solutes segregate with fundamental - effect on the properties of materials. Conceptually, interfaces are a - continuum-scale description of how atoms arrange spatio-temporally. Interfaces - manifests as persistent defects. When inspected in more detail though they show - atom dynamics, coarse-grainable into again interactions between line-type - crystal defects (disconnections) through which interfaces are dynamic and can - interact with other defects. Owing to this complexity very different - descriptions are used depending on which length-, time-scale, - and research question people address. - - This is manifested in the large amount of literature on the topic: - - * A. P. Sutton et al. ISBN-13 978-0198500612 - * G. Gottstein et al. ISBN-13 978-1-4200-5436-1 - * K. Chen et al. https://doi.org/10.1073/pnas.1920504117 - - Interfaces, specifically grain and phase boundaries, are representatives of - two-dimensional microstructural features. It would be rude to claim that a single - base class can encompass the entire complexity that this effective - coarse-graining of atomic spatio-temporal configurations has. In the end, - interfaces are a model, an effort to simplicify the description in the hope - to arrive at physical models which do not need to take into account the static - and dynamic details of every atom. - - However, it is also a fact that not every description, research question, and - thus use cases that one could think of storing as data and metadata for - interfaces, is equally relevant and useful for an ensemble of research studies. - - Thus, for the design of concrete schemes for a structured storage of data on - interfaces are measured or characterized, one has to prioritize which - descriptors and aspects about interfaces are likely relevant for a large - number of users of the research infrastructure. Consequently, it is possible - to narrow down the scope of this base class. - - It is noteworthy to mention that this applies not only to schemes build - with NeXus, but points to the problem of creating a golden-bullet schema - that could handle all possible subtleties of interfaces. - - For now we have to accept that there is not yet an ontology of e.g. the - above-mentioned understanding of what interfaces are. - - Pragmatically we thus make the following assumptions: - - * This base class is essentially a template how specific, often referred to - quantities, for two-dimensional crystal defects can be stored. - * Coarse-graining point-like features into a curve or surfaces is an - ill-posed problem. In practice, it has to be accounted for that interfaces - have a finite extent, they are delineated by triple lines and quadruple - junctions. Interfaces are thus connected into a three-dimensional network - of defects. Interfaces can interact or intersect with other defects - (partially or completely, as it is the case for disconnections). - - There are the following general approaches of studying/characterizing: - - * Non-atomically resolved measurements of 2D or 3D sections. - Examples are optical, electron, X-ray, or atom probe microscopy. - * Under specific conditions using electron microscopy, electron tomography - (provided numerical post-processing is applied) as well as with atom probe - microscopy these measurement can resolve structural motifs of or in the - interface plane. - * Atomic-scale-resolved simulations. In this case the most frequently - performed tasks are again post-processing snapshots with grain identification - or graph-based techniques to identify which atoms belong to the regions - with local changes or breakdown of the long-range crystal symmetry. - * Analytical approaches whereby grain boundaries are resolved at the continuum - scale, as surface defects containing other elementary defects (for instance) - in models of disconnection motion), using eventual statistical approaches, - or again atomically resolved treatments. - - From this we can conclude that an NXms_interface_set can primarily be - useful as a wrapper class in which specific details about interfaces - can be stored in an arbitrarily nested manner. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. -NXms_interface_set: -# doc: A starting point for the discussion. -# needs to be extended based on the NXannealing appdef. - -# lets sketch for each of the four above-mentioned frequent use cases what -# could be relevant to nest inside such base classes -# !!! here we really need to discuss if these many options -# !!! warrant necessary deeper nesting or further splitting of the base class -# !!! essentially pseudo-code yaml follows !!! -# USE CASE statistical treatments -# # described via representatives of geometric descriptors, for instance -# depending on which method one uses interfaces are described in 2D via their traces -# (NXcg_polyline_set) -# more frequently nowadays though one resorts to 3D -# (NXcg_triangle_set) -# (NXcg_triangulated_surface_mesh_set) -# (NXcg_polygon_set) -# (NXcg_polyhedra_set) -# instances for all of these base class can be customized with specific fields -# i.e. properties -# !!! a particular challenge in certain applications/use cases is that -# descriptions are combined (continuum with atomic scale) -# in such a case NXcg_roi_set can be used to add further nested -# NXcg_*_set), e.g. NXcg_cuboid_set or NXcg_cylinder_set which detail how -# atoms are arranged inside such sub-volumina -# similar statements as they were made for NXms_dislocation_set apply diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml deleted file mode 100644 index 198e3b928d..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set_em_auger.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Container for reporting a set of auger electron energy spectra. -type: group -(NXobject)NXspectrum_set_em_auger: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eaf9e6b72cc5c4cc91bcb6198acbc2cf74dcc00d16469feb27aeb92b41d35924 -# -# -# -# -# Container for reporting a set of auger electron energy spectra. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml deleted file mode 100644 index 635cac8f74..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set_em_cathodolum.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Container for reporting a set of cathodoluminescence spectra. -type: group -(NXobject)NXspectrum_set_em_cathodolum: - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 90fc581369c8fbf7c59f4066e6dc149890981b03400042962d78acd505535563 -# -# -# -# -# Container for reporting a set of cathodoluminescence spectra. -# -# -# -# From 75042e241bde2677c9a7c5101feb68c256996e16 Mon Sep 17 00:00:00 2001 From: cmmngr Date: Thu, 4 May 2023 02:46:59 +0200 Subject: [PATCH 141/203] Drafts of new app def NXopt and new base classes --- .../nyaml/NXbeam_path.yaml | 361 ++++++++++ .../nyaml/NXbeam_splitter.yaml | 314 +++++++++ contributed_definitions/nyaml/NXfiber.yaml | 160 +++++ contributed_definitions/nyaml/NXlens_opt.yaml | 144 ++++ contributed_definitions/nyaml/NXopt.yaml | 633 ++++++++++++++++++ .../nyaml/NXpolarizer_opt.yaml | 203 ++++++ .../nyaml/NXwaveplate.yaml | 133 ++++ 7 files changed, 1948 insertions(+) create mode 100644 contributed_definitions/nyaml/NXbeam_path.yaml create mode 100644 contributed_definitions/nyaml/NXbeam_splitter.yaml create mode 100644 contributed_definitions/nyaml/NXfiber.yaml create mode 100644 contributed_definitions/nyaml/NXlens_opt.yaml create mode 100644 contributed_definitions/nyaml/NXopt.yaml create mode 100644 contributed_definitions/nyaml/NXpolarizer_opt.yaml create mode 100644 contributed_definitions/nyaml/NXwaveplate.yaml diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml new file mode 100644 index 0000000000..abf6d097db --- /dev/null +++ b/contributed_definitions/nyaml/NXbeam_path.yaml @@ -0,0 +1,361 @@ +# 05/2023 +# A draft of a new base class to describe a beam path consisting of one or +# more optical elements (e.g. a beam path in a luminescence setup). +# ------------------------------------------------------------------------------ +# Comments: +# * +# ------------------------------------------------------------------------------ +# To do: +# [ ] Harmonize common fields/classes among base classes used in NXbeam_path, +# e.g. NXshape in NXbeam_splitter and NXpolarizer_opt, or NXsample used for +# describing substrates and coatings etc. +# [ ] How to describe a setup or beam path? Order/sequence defined by +# NXtransformations? --> discussion needed +# ______________________________________________________________________________ + +category: base +symbols: + N_spectrum: | + Size of the wavelength or energy vector for which quantities of the optical + element, such as reflectivity or efficiency, are provided. + # N_excitation: | + # Length of the wavelength or energy vector of the excitation source. This + # can be a single value or a spectrum, depending on the type of experiment. + N_beam_profile_dim: | + Number of dimensions for which the beam profile is given. + N_beam_profile_points: | + Number of points of the beam profile. + +doc: | + A beam path consisting of one or more optical elements. + + NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement + of optical elements between the excitation source and the sample, or between + the sample and the detector unit. + + To describe the order of the elements, use 'order(NXtransformations)', where + each element's position points to the preceding element via '@depends_on'. + Special case beam splitter: A beam splitter is a device which separates the + beam into two or more beams. If such a device is part of the beam path use + two or more NXbeam_paths to describe the beam paths after the beam splitter. + In this case, in the dependency chain of the new beam paths, the first + elements each point to the beam splitter, as this is the previous element. + +(NXbeam_path): + doc: | + Describe the relevant optical elements in the beam path by using the + appropriate sub classes. You may use as many elements as needed, also + several elements of the same type as long as each element has its own name. + Capital letters in the names can be replaced, e.g. lens_NUMBER can be + lens_1, lens_2, or lens_first, lens_second etc. + + depends_on: + doc: | + Entry point of the dependency chain defined by the NXtransformations + field, i.e. a link to the first element in the beam path. + Example: /entry/instrument/beam_path/radiation_source. + + (NXtransformations): + # Possibilities: + # (1) Modify NXtransformations to include properties that modify the light beam + # (e.g. polarization state) instead (or in addition) to transformations like + # translation and rotation + # (2) Base class similar to NXtransformations but for changes of optical + # properties (e.g. polarization state) + doc: | + Specify the order of the optical elements by defining a dependency chain. + For each element, a '@depends_on' attribute should be used to state the + position of the element in the beam path by pointing to the previous + element. For the very first element, use the string "." instead. + ELEMENT(NX_NUMBER): # instead of AXES in NXtransformations... + doc: | + For each element in the beam path, one such field must exist with a + '@depends_on' attribute defined to specify its position in the beam + path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows + ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and + 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the + dependency chain, i.e. may have an entry in this class even if they are + not described in the beam path. + ELEMENT is a place holder for the name of an optical beam path element. + Note that the name of this field must be exactly the same as the + element's field name. + unit: NX_TRANSFORMATIONS + \@depends_on: + doc: Add a link to the previous beam path element. + + (NXsource): + doc: | + Excitation source. One or more may be needed (e.g. two for a pump-probe + setup with one pump and one probe beam). + Depending on the source type, different properties are relevant, which + are provided through the respective base class (e.g. use NXopt_source for + lamps or lasers, NXchem_source for chemical reaction etc.). + Some base classes are incomplete (NXchem_source, NXbio_source); the + expertise of the respective communities is needed. + depends_on: + doc: Use this field to point to the previous optical element. + type: + exists: required + doc: Type of excitation source. + enumeration: + # Spallation Neutron Source + # Pulsed Reactor Neutron Source + # Reactor Neutron Source + # Synchrotron X-ray Source + # Pulsed Muon Source + # Rotating Anode X-ray + # Fixed Tube X-ray + # UV Laser + # Free-Electron Laser + # Optical Laser + # Ion Source + # UV Plasma Source + # Metal Jet X-ray + [ + semiconductor laser, # NXopt_source + gas laser, # NXopt_source + other laser, # NXopt_source + lamp, # NXopt_source + X-rays, # NXsource ??? + silicon carbide globar, # NXopt_source + super continuum, # NXopt_source + chemical reaction, # NXchem_source + ultrasound, # NXacoustic_source + sound, # NXacoustic_source + living organism, # NXbio_source + power supply, # NXpower_supply + electron source, # from NXem ??? + other + ] + # separate base classes for different sources: + (NXacoustic_source): # needs to be developed + doc: | + Acoustic source, e.g. an ultrasonic transducero or a imploding gas + bubble (sonoluminescence). + (NXpower_supply): # needs to be developed + (NXchem_source): # input for experts from that field needed + (NXbio_source): # input for experts from that field needed + # is NXsource sufficient for x-rays? + (NXopt_source): + lifespan(NX_NUMBER): + exists: recommended + doc: Lifespan of the excitation (typically provided in hours). + unit: NX_TIME + measure_time(NX_NUMBER): + exists: recommended + doc: How many hours has the lamp been used? + unit: NX_TIME + excitation_wavelength(NX_FLOAT): + exists: required + doc: | + Wavelengths or energy vector of the excitation source. This can be a + single value or a spectrum, depending on the type of experiment. + unit: NX_ANY + \@units: + doc: Unit of wavelength or energy. + beam_profile: + # ??? What's the best way to enter this ??? + doc: Two- or three-dimensional beam profile. + dimensions: + rank: 2 + dim: + [ + [1, N_beam_profile_dim], + [2, N_beam_profile_points] + ] + peak_power(NX_FLOAT): + doc: Power of one light pulse if the source is a pulsed source. + unit: NX_POWER + cw(NX_BOOLEAN): + exists: required + doc: Is the excitation source continuous wave (CW)? + cw_power(NX_FLOAT): + doc: Power of CW beam. + bandwidth(NX_FLOAT): + exists: recommended + doc: FWHM bandwidth of the excitation source. + unit: NX_WAVELENGTH + coherence_length(NX_FLOAT): + doc: Coherence length. + unit: NX_LENGTH + divergence(NX_FLOAT): + doc: Divergence of the excitation beam. + unit: NX_ANGLE + + (NXpinhole): + doc: | + Use this field to describe a simple pinhole (round geometry). Define its + dimension using 'diameter'. For more complex geometries, 'NXaperture' + should be used. + + (NXslit): + doc: | + Use this field to describe a simple slit (rectangular geometry). Define + its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, + 'NXaperture' should be used. + + aperture_NUMBER(NXaperture): + doc: | + Use this field to describe an aperture. To specify a window, use the + field 'window_NUMBER(NXaperture)'. + + window_NUMBER(NXaperture): + doc: | + A window, e.g. an entry or exit window of a cryostat. + depends_on: + doc: Use this field to point to the previous optical element. + material(NX_CHAR): + exists: required + doc: The material of the window. + enumeration: + [ + quartz, + diamond, + calcium fluoride, + zinc selenide, + thallium bromoiodide, + alkali halide compound, + Mylar, + other, + ] + other_material(NX_CHAR): + exists: optional + doc: | + If you specified 'other' as material, decsribe here what it is. + thickness(NX_FLOAT): + doc: Thickness of the window + unit: NX_LENGTH + orientation_angle(NX_FLOAT): + doc: | + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + unit: NX_ANGLE + reference_data_link: + doc: | + If reference data were measured add a link to the NeXus file where they + are described. + + (NXmirror): + + filter_NUMBER(NXfilter): + + (NXattenuator): + doc: A device that reduces the intensity of a beam by attenuation. + attenuator_transmission(NX_FLOAT): + doc: The transmitted intensity divided by the incident intensity. + unit: NX_DIMENSIONLESS + attenuation(NX_FLOAT): + doc: Attenuation of the attenuator in dB. + unit: NX_ANY + \@units: + doc: | + Unit of the measured data is not covered by NXDL units state + here which unit was used. + (NXaperture): + doc: Input and output aperture of the attenuator. + (NXgeomtry): + doc: Geometry (shape, size etc.) of the attenuator. + + (NXgrating): + doc: | + A diffraction grating. Define relevant parameters in the corresponding + fields, e.g. order of diffration (diffraction_order) or angular + dispersion (angular_dispersion). + type: + exists: required + doc: Define the type of the grating. + angular_dispersion(NX_FLOAT): + doc: Dispersion of the grating in nm/mm (or e.g. nm/mrad). + unit: NX_UNITLESS + grooves(NX_FLOAT): + doc: Number of grooves per mm. + unit: NX_PER_LENGTH + blaze_wavelength(NX_FLOAT): + doc: Blaze wavelength of the grating. + unit: NX_WAVELENGTH + efficiency(NX_FLOAT): + doc: Efficiency curve versus wavelength or energy. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: + [[1, N_spectrum]] + spectrum(NX_FLOAT): + doc: | + Spectral values, e.g. wavelength or energy. Vector of length + N_spectrum. + unit: NX_ANY + \@units: + doc: Unit of wavelength array (e.g. nanometer or Angstrom) + + (NXdisk_chopper): + doc: | + A device blocking the beam in a temporal periodic pattern, e.g. a optical + chopper wheel. Specify the frequency range using 'min_frequency' and + 'max_frequency'. + min_frequency(NX_FLOAT): + doc: Minimum frequency in Hertz. + unit: NX_FREQUENCY + max_frequency(NX_FLOAT): + doc: Maximum frequency in Hertz. + unit: NX_FREQUENCY + frequency_resolution(NX_FLOAT): + doc: Frequency resolution in Hertz. + unit: NX_FREQUENCY + + (NXmonochromator): + doc: | + A monochromator or spectrometer. + spectrum(NX_FLOAT): + doc: | + Spectral values of the monochromator, e.g. wavelength or energy values + used for the measurement. + unit: NX_ANY + \@units: + doc: Unit of wavelength array (e.g. nanometer or Angstrom) + (NXgrating): + exists: optional + doc: | + Diffraction grating. If two or more gratings were used, define the + angular dispersion and the wavelength range (min/max wavelength) for + each grating and make sure that the wavelength ranges do not overlap. + The dispersion should be defined for the entire wavelength range of the + experiment. + angular_dispersion(NX_FLOAT): + exists: optional + doc: Dispersion of the grating in nm/mm. + unit: NX_DIMENSIONLESS + grating_wavelength_min(NX_FLOAT): + exists: optional + doc: Minimum wavelength of the grating. + unit: NX_WAVELENGTH + grating_wavelength_max(NX_FLOAT): + exists: optional + doc: Maximum wavelength of the grating. + unit: NX_WAVELENGTH + spectral_resolution(NX_FLOAT): + exists: optional + doc: Spectral resolution of the instrument. + unit: NX_WAVENUMBER + (NXslit): + exists: optional + doc: Define the width of the monochromator slit in the subfield x_gap. + fixed_slit(NX_BOOLEAN): + exists: optional + doc: Was the slit width fixed? + max_gap(NX_FLOAT): + exists: optional + doc: If slit width was not fixed, define the maximum slit width. + unit: NX_LENGTH + + # x-ray optics: + (NXxraylens): + # what else? + + # ====== New base classes: ====== + (NXpolarizer_opt): + (NXbeam_splitter): + (NXwaveplate): + (NXlens_opt): + (NXfiber): + diff --git a/contributed_definitions/nyaml/NXbeam_splitter.yaml b/contributed_definitions/nyaml/NXbeam_splitter.yaml new file mode 100644 index 0000000000..f9f01bf748 --- /dev/null +++ b/contributed_definitions/nyaml/NXbeam_splitter.yaml @@ -0,0 +1,314 @@ +# A draft of a new base class to describe a beam splitting device. + +category: base +symbols: + N_spectrum: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the beam splitter material and/or coating is defined. + N_spectrum_RT: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + reflectance or transmission of the beam splitter is given. + N_shapepar: | + Number of parameters needed do descripe the shape of the beam splitter. + N_objects: | + Number of objects the beam splitter is made up of. + N_outputs: | + Number of outputs, i.e. number of paths the beam takes after being split by + the beam splitter. + +doc: | + A beam splitter, i.e. a device splitting the light into two or more beams. + + Information about types and properties of beam splitters is provided e.g. + [here](https://www.rp-photonics.com/beam_splitters.html). + + Use two or more NXbeam_paths to describe the beam paths after the beam + splitter. In the dependency chain of the new beam paths, the first elements + each point to this beam splitter, as this is the previous element. + +NXbeam_splitter: + type: + exists: required + doc: | + Specify the beam splitter type (e.g. dielectric mirror, pellicle, + dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension + should be described in 'geometry'. Define if the beam splitter is + polarizing or not in the field 'polarizing(NX_BOOLEAN)'. + enumeration: + [ + "dichroic mirror", + "dielectric mirror", + "metal-coated mirror", + "Nicol prism", + "Glan-Thompson prism", + "pellicle mirror", + "Polka dot beam splitter", + "fiber optic splitter", + "other" + ] + # ??? Are there any other common types of beam splitters ??? + other_type: + doc: | + If you selected 'other' in 'type' use this field to specify which type of + beam splitter was used. + + polarizing(NX_BOOLEAN): + exists: required + doc: Is the beam splitter polarizing? + + multiple_outputs(NX_BOOLEAN): + # ??? Redundant because number of outputs is defined by N_outputs ??? + exists: required + doc: | + Does the beam splitter have multiple outputs (diffractive optical + element), i.e. more than two outputs? + + (NXshape): + exists: recommended + doc: | + Describe the geometry (shape, dimension etc.) of the beam splitter. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). + # Specify the length and height if the surface facing the incident + # beam is a square or rectangle. Otherwise, if the device has a round + # geometry (disc), sepcify the diameter instead. + # The thickness or depth of the device should be defined in 'depth', + # while the thickness of the substrate and coating should be specified + # in 'substrate/substrate_thickness' and 'coating/coating_thickness'. + shape: + doc: Describe the shape (plate, cube, wedged, prism etc.). + enumeration: + [ + cube, + cylinder, + plate, + prism, + wedged, + other + ] + other_shape: + doc: If you chose 'other' in 'shape' describe what it is. + sketch(NXdata): + doc: | + Sketch of the beam splitter showing its geometry. The paths of the + incoming and split beam should be illustrated and labelled (0 for the + incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split + beam paths)). + size: + doc: | + Physical extent of the beam splitter device. The beam splitter might be + made up of one or more objects (NX_objects). The meaning and location + of the axes used will vary according to the value of the 'shape' + variable. 'N_shapepar' defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. + dimensions: + rank: 2 + dim: + [ + [1, N_objects], + [2, N_shapepar] + ] + wedge_angle(NX_FLOAT): + doc: Wedge angle if 'shape' is 'wedged'. + unit: NX_ANGLE + # width, height, diameter, depth: Should we use 'size' in NXshape instead? + # width(NX_FLOAT): + # doc: | + # Width of the device's surface facing the incident beam if the surface + # is square or rectangular (e.g. is shape is a cube). + # unit: NX_LENGTH + # height(NX_FLOAT): + # doc: | + # Height of the device's surface facing the incident beam if the surface + # is square or rectangular (e.g. is shape is a cube). + # unit: NX_LENGTH + # diameter(NX_FLOAT): + # doc: | + # Diameter of the device's surface facing the incident beam if the + # surface has circular geometry (e.g. is shape is a cylinder). + # unit: NX_LENGTH + # length(NX_FLOAT): + # doc: | + # Specify the length of the beam splitter. If the device has a wedged + # shape provide the minimum and maximum length of the device. + # Otherwise, if the beam splitter has a homogeneous thickness, the two + # values are equal. + # dimensions: + # rank: 1 + # dim: [[1,2]] + + splitting_ratio(NX_NUMBER): + doc: | + Beam splitting ratio(s) for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, N_outputs]] + + clear_aperture(NX_FLOAT): + doc: | + Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of + length and height for square geometry). + unit: NX_UNITLESS + # ??? Would it be better to provide the clear aperture as length ??? + + substrate(NXsample): + doc: | + Substrate of the beam splitter. Describe the material of the substrate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. + substrate_material: + doc: | + Specify the material of the beam splitter. If the device has a coating + it should be described in coating/coating_material. Is the material + birefringent? + substrate_thickness(NX_FLOAT): + doc: | + Thickness of the beam splitter substrate. Define the minimum and + maximum thickness (for a wedged geomtry). For a homogeneous thickness + (e.g. as in plate beam splitters) the minimum and maximum values are + equal. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1,2]] + index_of_refration_substrate(NX_FLOAT): + doc: | + Complex index of refraction of the beam splitter substrate. Specify at + given spectral values (e.g. wavelength, energy, wavenumber etc.). + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum] + ] + + coating(NXsample): + doc: | + Is the beam splitter coated? If yes, specify the type and material of the + coating and the spectral range for which it is designed. If known, you + may also provide its index of refraction. For a beam splitter cube + consisting of two prisms which are glued together, you may want to + specify the the glue and the coatings of each prism. + coating_type: + doc: | + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + coating_material: + doc: Specify the coating material. + coating_thickness(NX_FLOAT): + doc: Thickness of the coating. + unit: NX_LENGTH + wavelength_range_coating(NX_FLOAT): + exists: recommended + doc: | + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. + unit: NX_WAVELENGTH + dimensions: + rank: 1 + dim: [[1,2]] + index_of_refraction_coating(NX_FLOAT): + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (e.g. wavelength, energy, wavenumber etc.). + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum] + ] + + wavelength_range(NX_FLOAT): + exists: recommended + doc: | + Wavelength range for which the beam splitter is designed. Enter the + minimum and maximum values of the wavelength range. Alternatively, or + additionally, you may define the wavelength range for the coating in + coating/wavelength_range_coating. + unit: NX_WAVELENGTH + dimensions: + rank: 1 + dim: [[1, 2]] + + optical_loss(NX_NUMBER): + doc: | + Optical loss of the beam splitter for the various outputs (i.e. the paths + of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, N_outputs]] + + incident_angle(NX_NUMBER): + doc: Optimized angle of incidence for the desired splitting ratio. + unit: NX_ANGLE + + deflection_angle(NX_NUMBER): + # is this really needed? + doc: | + Angle of deflection corresponding to the optimized angle of incidence + defined in incident_angle. + unit: NX_ANGLE + + AOI_range(NX_NUMBER): + doc: | + Range of the angles of incidence (AOI) for which the beam splitter can be + operated. Specify the minimum and maximum angles of the range. + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, 2]] + # Aren't some beamsplitters defined for specific angles? Should we instead + # use dim: [[1,N_angles]], N_angles being the number of angles for which the + # beam splitter can be operated? + # If this is the case for some devices, we might also have to define a field + # for the corresponding defelction angles... + + reflectance(NX_FLOAT): + doc: | + Reflectance of the beam splitter at given spectral values. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: + [ + [1, N_spectrum_RT] + ] + + transmission(NX_FLOAT): + doc: | + Transmission at given spectral values for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, N_outputs], + [2, N_spectrum_RT] + ] + diff --git a/contributed_definitions/nyaml/NXfiber.yaml b/contributed_definitions/nyaml/NXfiber.yaml new file mode 100644 index 0000000000..d8d47d63c2 --- /dev/null +++ b/contributed_definitions/nyaml/NXfiber.yaml @@ -0,0 +1,160 @@ +# A draft of a new base class to describe an optical fiber (e.g. glass fiber) + +category: base +symbols: + N_spectrum_core: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the core material is given. + N_spectrum_clad: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the cladding material is given. + N_spectrum_attenuation: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + attenuation curve is given. + +doc: | + An optical fiber, e.g. glass fiber. + + Specify the quantities that define the fiber. Fiber optics are described in + detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for + example. + +NXfiber: + + description: + exists: recommended + doc: | + Descriptive name or brief description of the fiber, e.g. by stating its + dimension. The dimension of a fiber can be given as 60/100/200 which + refers to a core diameter of 60 micron, a clad diameter of 100 micron, + and a coating diameter of 200 micron. + + type: + exists: required + doc: | + Type/mode of the fiber. Modes of fiber transmission are shown in + Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). + enumeration: + [ + "single mode", + "multimode graded index", + "multimode step index" + ] + + dispersion_type: + doc: Type of dispersion. + enumeration: + [ + "modal", + "material", + "chromatic" + ] + dispersion(NX_FLOAT): + doc: | + Spectrum-dependent (or refractive index-dependent) dispersion of the + fiber. Specify in ps/nm*km. + unit: NX_TIME + dimensions: + rank: 1 + dim: + [ + [1, N_spectrum_core] + ] + + core(NXsample): + doc: | + Core of the fiber, i.e. the part of the fiber which transmits the light. + core_material: + doc: Specify the material of the core of the fiber. + core_diameter(NX_FLOAT): + doc: Core diameter of the fiber (e.g. given in micrometer). + unit: NX_LENGTH + core_index_of_refraction(NX_FLOAT): + doc: | + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum_core] + ] + + cladding(NXsample): + doc: | + Core of the fiber, i.e. the part of the fiber which transmits the light. + clad_material: + doc: Specify the material of the core of the fiber. + clad_diameter(NX_FLOAT): + doc: Clad diameter of the fiber (e.g. given in micrometer). + unit: NX_LENGTH + clad_index_of_refraction(NX_FLOAT): + doc: | + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum_clad] + ] + + coating(NXsample): + doc: Coating of the fiber. + coating_material: + doc: Specify the material of the coating of the fiber. + coating_diameter(NX_FLOAT): + doc: Outer diameter of the fiber (e.g. given in micrometer). + unit: NX_LENGTH + + length(NX_FLOAT): + doc: Length of the fiber. + unit: NX_LENGTH + + spectral_range(NX_FLOAT): + exists: recommended + doc: | + Spectral range for which the fiber is designed. Enter the minimum and + maximum values (lower and upper limit) of the wavelength range. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1,2]] + \@units: + doc: | + Unit of spectral array (e.g. nanometer or angstrom for wavelength, or + electronvolt for energy etc.). + + transfer_rate(NX_FLOAT): + doc: Transfer rate of the fiber (in GB per second). + unit: NX_ANY + \@units: + doc: GB/s + + numerical_aperture(NX_FLOAT): + doc: Numerical aperture (NA) of the fiber. + unit: NX_UNITLESS + + attenuation(NX_FLOAT): + doc: Wavelength-dependent attenuation of the fiber (specify in dB/km). + unit: NX_ANY + \@units: + doc: dB/km + dimensions: + rank: 1 + dim: + [ + [1, N_spectrum_attenuation] + ] + + power_loss(NX_FLOAT): + doc: Power loss of the fiber in percentage. + unit: NX_UNITLESS + + acceptance_angle(NX_FLOAT): + doc: Acceptance angle of the fiber. + unit: NX_ANGLE diff --git a/contributed_definitions/nyaml/NXlens_opt.yaml b/contributed_definitions/nyaml/NXlens_opt.yaml new file mode 100644 index 0000000000..42d150d741 --- /dev/null +++ b/contributed_definitions/nyaml/NXlens_opt.yaml @@ -0,0 +1,144 @@ +# A draft of a new base class describing an optical lens +# (Note: NXlens_em describes an electro-magnetic lens or a compound lens) + +category: base +symbols: + N_spectrum: | + Size of the wavelength array for which the refractive index of the material + is given. + N_spectrum_coating: | + Size of the wavelength array for which the refractive index of the coating + is given. + N_spectrum_RT: | + Size of the wavelength array for which the reflectance or transmission of + the lens is given. +doc: | + Description of an optical lens. + +NXlens_opt: + doc: Specify the properties of the lens. + + type: + exists: required + doc: Type of the lens (e.g. concave, convex etc.). + enumeration: + [ + "biconcave", + "plano-concave", + "convexo-concave", + "biconvex", + "plano-convex", + "concavo-convex", + "Fresnel lens", + "other" + ] + other_type: + doc: If you chose 'other' as type specify what it is. + + chromatic(NX_BOOLEAN): # chromatic or achromatic + exists: required + doc: Is it a chromatic lens? + + lens_diameter(NX_NUMBER): + doc: Diameter of the lens. + unit: NX_LENGTH + + substrate(NXsample): + doc: | + Properties of the substrate material of the lens. If the lens has a + coating specify the coating material and its properties in 'coating'. + substrate_material: + doc: Specify the substrate material of the lens. + substrate_thickness(NX_NUMBER): + doc: Thickness of the lens substrate at the optical axis. + unit: NX_LENGTH + index_of_refraction(NX_NUMBER): + doc: | + Complex index of refraction of the lens material. Specify at given + wavelength (or energy, wavenumber etc.) values. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum] + ] + + COATING(NXsample): + # Used captial letters for COATING so that more than one can be defined if + # the lens has different coatings on the front and back side. + doc: | + If the lens has a coating describe the material and its properties. + Some basic information can be found e.g. [here] + (https://www.opto-e.com/basics/reflection-transmission-and-coatings). + If the back and front side of the lens are coated with different + materials, use separate COATING(NXsample) fields to describe the coatings + on the front and back side, respectively. For example: + coating_front(NXsample) and coating_back(NXsample). + coating_type: + doc: | + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + coating_material: + doc: Describe the coating material (e.g. MgF2). + coating_thickness(NX_NUMBER): + doc: Thickness of the coating. + unit: NX_LENGTH + index_of_refraction_coating(NX_NUMBER): + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum_coating] + ] + + reflectance: + doc: Reflectance of the lens at given spectral values. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: + [ + [1, N_spectrum_RT] + ] + + transmission: + doc: Transmission of the lens at given spectral values. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: + [ + [1, N_spectrum_RT] + ] + + focal_length(NX_NUMBER): + exists: recommended + doc: | + Focal length of the lens on the front side (first value), i.e. where the + beam is incident, and on the back side (second value). + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 2]] + + curvature_radius_FACE(NX_NUMBER): + exists: recommended + doc: | + Curvature radius of the lens. + Instead of 'FACE' in the name of this field, the user is advised to + specify for which surface (e.g. front or back) the curvature is provided: + e.g. curvature_front or curvature_back. The front face is the surface on + which the light beam is incident, while the back face is the one from + which the light beam exits the lens. + unit: NX_LENGTH + + Abbe_number(NX_NUMBER): + doc: Abbe number (or V-number) of the lens. + unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml new file mode 100644 index 0000000000..9638cd818e --- /dev/null +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -0,0 +1,633 @@ +# 05/2023 +# Draft of a NeXus application definition which serves as a template for various +# optical spectroscopy experiments +# ------------------------------------------------------------------------------ +# Comments: +# * +# ------------------------------------------------------------------------------ +# To do: +# [ ] Check base classes (NXbeam_path + base classes used by it) +# [ ] Harmonize NXopt and NXellipsometry +# [ ] Fix dimensions and ranks +# ______________________________________________________________________________ + +category: application +doc: | + An application definition for optical spectroscopy experiments. +symbols: + doc: Variables used throughout the document, e.g. dimensions or parameters. + N_spectrum: | + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + N_sensors: | + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + N_measurements: | + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + N_detection_angles: | + Number of detection angles of the beam reflected or scattered off the + sample. + N_incident_angles: Number of angles of incidence of the incident beam. + N_observables: | + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. + +NXopt: + (NXentry): + doc: | + An application definition template for optical spectroscopy experiments. + + A general optical experiment consists of a light or excitation source, a + beam path, a sample + its stage + its environment, and a detection unit. + Examples are reflection or transmission measurements, photoluminescence, + Raman spectroscopy, ellipsometry etc. + + definition: + doc: An application definition describing a general optical experiment. + \@version: + doc: | + Version number to identify which definition of this application + definition was used for this entry/data. + \@url: + doc: | + URL where to find further material (documentation, examples) relevant + to the application definition. + enumeration: [NXopt] + experiment_identifier: + doc: | + A (globally persistent) unique identifier of the experiment. + (i) The identifier is usually defined by the facility or principle + investigator. + (ii) The identifier enables to link experiments to e.g. proposals. + experiment_description: + exists: optional + doc: | + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. + experiment_type: + doc: Specify the type of the optical experiment. + start_time(NX_DATE_TIME): + doc: Start time of the experiment. UTC offset should be specified. + (NXuser): + exists: [min, 1] + doc: | + Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users, if relevant, is recommended. + name: + doc: Name of the user. + affiliation: + doc: | + Name of the affiliation of the user at the point in time when the + experiment was performed. + address: + doc: Street address of the user's affiliation. + email: + doc: Email address of the user. + orcid: + exists: recommended + doc: Author ID defined by https://orcid.org/. + telephone_number: + exists: recommended + doc: Telephone number of the user. + + (NXinstrument): + doc: | + Properties of the experimental setup. This includes general information + about the instrument (such as model, company etc.), information about + the calibration of the instrument, elements of the beam path including + the excitation or light source and the detector unit, the sample stage + (plus the sample environment, which also includes sensors used to + monitor external conditions) and elements of the beam path. + + Meta data describing the sample should be specified in ENTRY/SAMPLE + outside of ENTRY/INSTRUMENT. + model: + doc: The name of the instrument. + \@version: + doc: | + The used version of the hardware if available. If not a commercial + instrument use date of completion of the hardware. + company: + exists: optional + doc: Name of the company which build the instrument. + construction_year(NX_DATE_TIME): + exists: optional + doc: | + ISO8601 date when the instrument was constructed. + UTC offset should be specified. + software(NXprocess): + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and metadata. + This program converts the measured signals to ellipsometry data. If + home written, one can provide the actual steps in the NOTE subfield + here. + version: + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@url: + exists: optional + doc: Website of the software. + firmware: + exists: recommended + doc: | + Commercial or otherwise defined name of the software that was used + for the measurement - if available. + \@version: + doc: | + Version and build number or commit hash of the software source code. + \@url: + doc: Website of the software. + calibration_status(NX_CHAR): + doc: | + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. + enumeration: + [ + calibration time provided, + no calibration, + within 1 hour, + within 1 day, + within 1 week, + ] + calibration(NXsubentry): + exists: recommended + doc: The calibration data and metadata should be described in a + separate NeXus file with the link provided in 'calibration_link'. + calibration_time(NX_DATE_TIME): + exists: optional + doc: | + If calibtration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + calibration_data_link: + doc: | + Link to the NeXus file containing the calibration data and metadata. + incident_light(NXbeam_path): + doc: | + Describes the light source and the beam path between the source and + the sample. + If a beam splitter (i.e. a device that splits the incoming beam into + two or more beams) is part of the beam path, two or more NXbeam_path + fields may be needed to fully describe the beam paths and the correct + sequence of the beam path elements. + angle_of_incidence(NX_NUMBER): + doc: | + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, N_incident_angles]] + detection(NXbeam_path): + doc: | + Describes the beam path between the sample and the detector unit, as + well as the detector itself. + If a beam splitter (i.e. a device that splits the incoming beam into + two or more beams) is part of the beam path, two or more NXbeam_path + fields may be needed to fully describe the beam paths and the correct + sequence of the beam path elements. + detection_angle(NX_NUMBER): + exists: optional + doc: | + Detection angle(s) of the beam reflected or scattered off the sample + vs. the normal of the bottom reflective (substrate) surface in the + sample if not equal to the angle(s) of incidence. + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, N_detection_angles]] + sample_stage(NXsubentry): + doc: | + Sample stage, holding the sample at a specific position in X,Y,Z + (Cartesian) coordinate system and at an orientation defined + by three Euler angles (alpha, beta, gamma). + stage_type: + doc: Specify the type of the sample stage. + enumeration: + [ + manual stage, + scanning stage, + liquid stage, + gas cell, + cryostat + ] + (NXtransformations): + exists: recommended + doc: | + The stage coordinate system vs. the incident beam. The Z-axis of + the stage is considered to point along the normal of the substrate + (bottom reflecting surface) from the stage towards the general + direction of the light source. The beam comes with angle of + incidence towards this Z-axis, but in opposite direction, thus they + are connected with a rotation of 180 - angle of incidence (in + degrees). + + This transformation brings us from the NeXus to the stage + coordinates. + + Then provide the set of translations (if there are any). These all + have a vector defining their relative direction in the current + coordinate system. (This current coordinate system changes with + every transformation if you set the parameter 'depends' to the name + of the previous step.) + + Last, provide the rotations of the sample. + alternative: + exists: optional + doc: | + If there is no motorized stage, we should at least qualify where + the beam hits the sample and in what direction the sample stands + in a free-text description, e.g. 'center of sample, long edge + parallel to the plane of incidence'. + environment_conditions(NXenvironment): + doc: | + Specify external parameters that have influenced the sample, such + as the surrounding medium, and varied parameters e.g. temperature, + pressure, pH value, optical excitation etc. + medium: + doc: | + Describe what was the medium above or around the sample. The + common model is built up from the substrate to the medium on the + other side. Both boundaries are assumed infinite in the model. + Here, define the name of the medium (e.g. water, air, UHV, etc.). + medium_refractive_indices(NX_FLOAT): + exists: optional + doc: | + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum] + ] + PARAMETER(NXsensor): + exists: optional + doc: | + A sensor used to monitor an external condition influencing the + sample, such as temperature or pressure. It is suggested to + replace 'PARAMETER' by the type of the varied parameter defined + in 'parameter_type'. + The measured parameter values should be provided in 'values'. + For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. + In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. + parameter_type: + doc: | + Indicates which parameter was changed. Its definition must exist + below. The specified variable has to be N_measurements long, + providing the parameters for each data set. If you vary more than + one parameter simultaneously. + enumeration: + [ + conductivity, + detection_angle, + electric field, + flow, + incident angle, + magnetic field, + optical excitation, + pH, + pressure, + resistance, + shear, + stage positions, + strain, + stress, + surface pressure, + temperature, + voltage, + ] + number_of_parameters(NX_COUNT): + doc: | + Number of different parameter values at which the measurement + was performed. For example, if the measurement was performed at + temperatures of 4, 77 and 300 K, then number_of_parameters = 3. + unit: NX_UNITLESS + values: + doc: | + Vector containing the values of the varied parameter. Its + length is equal to N_measurements. The order of the values + should be as follows: + + * Order the sensors according to number_of_parameters starting + with the lowest number. If number_of_parameters is equal for + two sensors order them alphabetically (sensor/parameter name). + * The first sensor's j parameters should be ordered in the + following way. The first N_measurements/number_of_parameters + entries of the vector contain the first parameter (a1), the + second N_measurements/number_of_parameters contain the second + parameter (a2) etc., so the vector looks like: + [ + a1,a1,...,a1, + a2,a2,...,a2, + ... + aj,aj,...aj + ] + * The kth sensor's m parameters should be ordered in the + following way: + [ + p1,...p1,p2,...,p2,...pm,...,pm, + p1,...p1,p2,...,p2,...pm,...,pm, + ... + p1,...p1,p2,...,p2,...pm,...,pm + ] + * The last sensor's n parameters should be ordered in the + following way: + [ + z1,z2,...,zn, + z1,z2,...,zn, + ... + z1,z2,...,zn] + + For example, if the experiment was performed at three different + temperatures (T1, T2, T3), two different pressures (p1, p2) and + two different angles of incidence (a1, a2), then + N_measurements = 12 and the order of the values for the various + parameter vectors is: + + * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] + * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] + * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] + dimensions: + rank: 1 + dim: [[1, N_measurements]] + WINDOW(NXaperture): + exists: optional + doc: | + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(MXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. + depends_on: + exists: recommended + doc: | + Specify the position of the window in the beam path by pointing + to the preceding element in the sequence of beam path elements. + window_effects_corrected(NX_BOOLEAN): + doc: | + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + window_correction(NXprocess): + exists: optional + doc: | + Was a window correction performed? If 'True' describe the + window correction procedure in '' + procedure: + doc: | + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. + reference_data_link: + exists: optional + doc: | + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + material(NX_CHAR): + doc: The material of the window. + enumeration: + [ + quartz, + diamond, + calcium fluoride, + zinc selenide, + thallium bromoiodide, + alkali halide compound, + Mylar, + other, + ] + other_material(NX_CHAR): + exists: optional + doc: | + If you specified 'other' as material, decsribe here what it is. + thickness(NX_FLOAT): + doc: Thickness of the window. + unit: NX_LENGTH + orientation_angle(NX_FLOAT): + doc: | + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + unit: NX_ANGLE + (NXsample): + doc: | + Properties of the sample, such as sample type, layer structure, + chemical formula, atom types, its history etc. + Information about the sample stage and sample environment should be + described in ENTRY/INSTRUMENT/sample_stage. + sample_name: + doc: Descriptive name of the sample + sample_type: + doc: | + Specify the type of sample, e.g. thin film, single crystal etc. + enumeration: + [ + 'thin film', + 'single crystal', + 'poly crystal', + 'single layer', + 'multi layer' + ] + layer_structure: + doc: | + Qualitative description of the layer structure for the sample, + starting with the top layer (i.e. the one on the front surface, on + which the light incident), e.g. native oxide/bulk substrate, or + Si/native oxide/thermal oxide/polymer/peptide. + chemical_formula: + doc: | + Chemical formula of the sample. Use the Hill system (explained here: + https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write + the chemical formula. In case the sample consists of several layers, + this should be a list of the chemical formulas of the individual + layers, where the first entry is the chemical formula of the top + layer (the one on the front surface, on which the light incident). + The order must be consistent with layer_structure + atom_types: + doc: | + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + 'atom_types'. + sample_history: + doc: | + Ideally, a reference to the location or a unique (globally + persistent) identifier (e.g.) of e.g. another file which gives + as many as possible details of the material, its microstructure, + and its thermo-chemo-mechanical processing/preparation history. + In the case that such a detailed history of the sample is not + available, use this field as a free-text description to specify + details of the sample and its preparation. + preparation_date(NX_DATE_TIME): + exists: recommended + doc: ISO8601 date with time zone (UTC offset) specified. + data_identifier(NX_NUMBER): + doc: | + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. + substrate: + exists: recommended + doc: Description of the substrate. + sample_orientation: + exists: optional + doc: Specify the sample orientation. + data(NXprocess): + doc: | + Measured data, data errors, and varied parameters. If reference data + were measured they should be considered a separate experiment and a + link to its NeXus file should be added in reference_data_link. + data_type: + doc: | + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + enumeration: + [ + intensity, + reflectivity, + transmittance, + Psi/Delta, + tan(Psi)/cos(Delta), + Mueller matrix, + Jones matrix, + N/C/S, + raw data, + ] + column_names: + doc: | + Please list in this array the column names used in your actual data. + That is ['Psi', 'Delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16'] for a + full Mueller matrix, etc. + dimensions: + rank: 1 + dim: [[1, N_observables]] + SPECTRUM(NX_FLOAT): + doc: | + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + measured_data(NX_FLOAT): + doc: | + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + unit: NX_ANY + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + dimensions: + rank: 3 + dim: + [ + [1, N_measurements], + [2, N_observables], + [3, N_spectrum] + ] + data_error(NX_FLOAT): + exists: optional + doc: | + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + unit: NX_ANY + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + dimensions: + rank: 3 + dim: + [ + [1, N_measurements], + [2, N_observables], + [3, N_spectrum] + ] + varied_parameter_link: + exists: optional + doc: | + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + dimensions: + rank: 1 + dim: [[1, N_sensors]] + reference_data_link: + exists: optional + doc: | + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + plot(NXdata): + exists: recommended + doc: | + A default view of the data provided in ENTRY/data/measured_data. This + should be the part of the data set which provides the most suitable + representation of the data. + \@axes: + doc: Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + \@units: + doc: Unit of the x-axis (e.g. nanometer, Angstrom, electron volt etc.) \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXpolarizer_opt.yaml b/contributed_definitions/nyaml/NXpolarizer_opt.yaml new file mode 100644 index 0000000000..e8f789503d --- /dev/null +++ b/contributed_definitions/nyaml/NXpolarizer_opt.yaml @@ -0,0 +1,203 @@ +# A draft of a new base class to describe an optical polarizer +# (NXpolarizer describes a spin polarizer) + +category: base +symbols: + N_spectrum: | + Size of the wavelength array for which the refractive index of the material + and/or coating is given. + N_spectrum_RT: | + Size of the wavelength array for which the reflectance or transmission of + the polarizer is given. + +doc: | + An optical polarizer. + + Information on the properties of polarizer is provided e.g. + [here](https://www.rp-photonics.com/polarizers.html). + +NXpolarizer_opt: + doc: Specify the properties of a polarizer. + type: + exists: required + doc: Type of the polarizer (e.g. dichroic, linear, circular etc.) + enumeration: + [ + "dichroic", + "linear", + "circular", + "Glan-Thompson prism", + "Nicol prism", + "Glan-Taylor prism", + "Glan-Focault prism", + "Wollaston prism", + "Normarski prism", + "Senarmont prism", + "thin-film polarizer", + "wire grid polarizer", + "other" + ] + # ??? Any other common polarizer types ??? + type_other: + doc: If you selected 'other' in type specify what it is. + + polarizer_angle(NX_NUMBER): + exists: recommended + doc: Angle of the polarizer. + unit: NX_ANGLE + + acceptance_angle(NX_NUMBER): + exists: recommended + doc: Acceptance angle of the polarizer (range). + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, 2]] + + (NXshape): + exists: recommended + doc: | + Describe the geometry (shape, dimension etc.) of the device. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). + # !!! NOTE: this class is the same as for NXbeam_path !!! + shape: + doc: Describe the shape (plate, cube, wedged, prism etc.). + enumeration: + [ + cube, + cylinder, + plate, + prism, + wedged, + other + ] + other_shape: + doc: If you chose 'other' in 'shape' describe what it is. + sketch(NXdata): + doc: | + Sketch of thedevice showing its geometry. The paths of the + incoming and outgoing beam should be illustrated and labelled (0 for + the incoming beam, and 1, 2,..., N_outputs for the outputs). + size: + doc: | + Physical extent of the device. The device might be made up of one or + more objects (NX_objects). The meaning and location of the axes used + will vary according to the value of the 'shape' variable. 'N_shapepar' + defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. + dimensions: + rank: 2 + dim: + [ + [1, N_objects], + [2, N_shapepar] + ] + wedge_angle(NX_FLOAT): + doc: Wedge angle if 'shape' is 'wedged'. + unit: NX_ANGLE + + wavelength_range(NX_FLOAT): + exists: recommended + doc: | + Wavelength range for which the polarizer is designed. Enter the minimum + and maximum wavelength (lower and upper limit) of the range. + unit: NX_WAVELENGTH + dimensions: + rank: 1 + dim: [[1,2]] + + substrate(NXsample): + doc: | + Properties of the substrate material of the polarizer. If the device has + a coating specify the coating material and its properties in 'coating'. + substrate_material: + doc: Specify the substrate material of the polarizer. + substrate_thickness(NX_FLOAT): + doc: Thickness of the polarizer substrate. + unit: NX_LENGTH + index_of_refraction(NX_FLOAT): + doc: | + Complex index of refraction of the polarizer material. Specify at given + spectral values (wavelength, energy, wavenumber etc.). + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum] + ] + + COATING(NXsample): + # Used captial letters for COATING so that more than one can be defined if + # the device has different coatings on the front and back side. + doc: | + If the device has a coating describe the material and its properties. + Some basic information can be found e.g. [here] + (https://www.opto-e.com/basics/reflection-transmission-and-coatings). + If the back and front side of the polarizer are coated with different + materials, you may define two coatings (e.g. COATING1 and COATING2). + coating_type: + doc: | + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + coating_material: + doc: Describe the coating material (e.g. MgF2). + coating_thickness(NX_FLOAT): + doc: Thickness of the coating. + unit: NX_LENGTH + index_of_refraction_coating(NX_FLOAT): + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum_coating] + ] + + extinction_ratio(NX_FLOAT): + doc: Extinction ratio (maximum to minimum transmission). + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: + [ + [1, N_spectrum] + ] + + reflection(NX_FLOAT): + doc: Reflection of the polarizer at given wavelength values. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: + [ + [1, N_spectrum_RT], + ] + + transmission(NX_FLOAT): + doc: Transmission of the polarizer at given wavelength values. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, N_spectrum_RT], + ] + + # anything missing? \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXwaveplate.yaml b/contributed_definitions/nyaml/NXwaveplate.yaml new file mode 100644 index 0000000000..5a3ccb86ba --- /dev/null +++ b/contributed_definitions/nyaml/NXwaveplate.yaml @@ -0,0 +1,133 @@ +# A draft of a new base class to describe a waveplate + +category: base +symbols: + N_spectrum: | + Size of the wavelength array for which the refractive index of the material + and/or coating is given. + N_wavelengths: | + Number of discrete wavelengths for which the waveplate is designed. If it + operates for a range of wavelengths then N_wavelengths = 2 and the minimum + and maximum values of the range should be provided. + +doc: | + A waveplate or retarder. + +NXwaveplate: + type: + exists: required + doc: | + Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). + # A waveplate can be e.g. a dual-wavelength multi-order plate + # => multiple selection needs to be possible + enumeration: + [ + "zero-order waveplate", + "achromatic waveplate", + "multiple-order waveplate", + "dual-wavelength waveplate", + "other" + ] + # Are there any other common wave plate types? + other_type: + doc: If you selected 'other' in type describe what it is. + + retardance: + doc: | + Specify the retardance of the waveplate (e.g. full-wave, half-wave + (lambda/2), quarter-wave (lambda/4) plate). + enumeration: + [ + "full-wave plate", + "half-wave plate", + "quarter-wave plate", + ] + + wavelengths(NX_NUMBER): + exists: recommended + doc: | + Discrete wavelengths for which the waveplate is designed. If the + waveplate operates over an entire range of wavelengths, enter the minimum + and maximum values of the wavelength range (in this case + N_wavelengths = 2). + dimensions: + rank: 1 + dim: + [ + [1, N_wavelengths] + ] + + diameter(NX_FLOAT): + doc: Diameter of the waveplate. + unit: NX_LENGTH + + clear_aperture(NX_FLOAT): + doc: | + Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of + length/height for square geometry). + unit: NX_UNITLESS + # Would it be better to provide the clear aperture as length? + + substrate(NXsample): + doc: | + Describe the material of the substrate of the wave plate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. + substrate_material: + doc: | + Specify the material of the wave plate. If the device has a + coating it should be described in coating/coating_material. + substrate_thickness(NX_NUMBER): + doc: Thickness of the wave plate substrate. + unit: NX_LENGTH + index_of_refration_substrate(NX_NUMBER): + doc: | + Complex index of refraction of the wave plate substrate. Specify at + given wavelength (or energy, wavenumber etc.) values. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum] + ] + + coating(NXsample): + doc: | + Is the wave plate coated? If yes, specify the type and material of the + coating and the wavelength range for which it is designed. If known, you + may also provide its index of refraction. + coating_type: + doc: | + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + coating_material: + doc: Specify the coating material. + coating_thickness(NX_NUMBER): + doc: Thickness of the coating. + unit: NX_LENGTH + wavelength_range_coating(NX_NUMBER): + exists: recommended + doc: | + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. + dimensions: + rank: 1 + dim: [[1,2]] + index_of_refraction_coating(NX_NUMBER): + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: + [ + [1, 2], + [2, N_spectrum] + ] + + reflectance(NX_NUMBER): + doc: Average reflectance of the waveplate in percentage. + unit: NX_UNITLESS \ No newline at end of file From 9e37956ca38be998344324ce928aa6007836d005 Mon Sep 17 00:00:00 2001 From: cmmngr Date: Thu, 4 May 2023 02:57:00 +0200 Subject: [PATCH 142/203] Correction in NXbeam_path --- contributed_definitions/nyaml/NXbeam_path.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml index abf6d097db..375c67a5b0 100644 --- a/contributed_definitions/nyaml/NXbeam_path.yaml +++ b/contributed_definitions/nyaml/NXbeam_path.yaml @@ -41,7 +41,7 @@ doc: | In this case, in the dependency chain of the new beam paths, the first elements each point to the beam splitter, as this is the previous element. -(NXbeam_path): +NXbeam_path: doc: | Describe the relevant optical elements in the beam path by using the appropriate sub classes. You may use as many elements as needed, also From 7bf501ff611bc49a66609b2cb3e1f3f2b51ae098 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 4 May 2023 19:27:33 +0200 Subject: [PATCH 143/203] Fixing accidentally removed or modified base classes during the earlier consolidation related to merging of NIAC changes --- base_classes/NXbeam.nxdl.xml | 404 ++++++++++++++++++++++++- base_classes/NXentry.nxdl.xml | 505 +++++++++++++++++++++++++------ base_classes/NXsource.nxdl.xml | 433 ++++++++++++++++++++++---- base_classes/nyaml/NXbeam.yaml | 80 ++++- base_classes/nyaml/NXentry.yaml | 29 +- base_classes/nyaml/NXsource.yaml | 30 +- 6 files changed, 1299 insertions(+), 182 deletions(-) mode change 100755 => 100644 base_classes/NXentry.nxdl.xml diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 28c331fdf6..885f5c5b9d 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -73,12 +73,44 @@ - Energy carried by each particle of the beam on entering the beamline component + Energy carried by each particle of the beam on entering the beamline component. + + In the case of a monochromatic beam this is the scalar energy. + Several other use cases are permitted, depending on the + presence of other incident_energy_X fields. + + * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + Here, incident_energy_weights and incident_energy_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_energy_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + + + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in + the energy spread, this is a 2D array of dimension nP by m + (slow to fast) of the spreads of the corresponding + wavelength in incident_wavelength. + + + + + In the case of a polychromatic beam this is an array of length m of the relative + weights of the corresponding energies in incident_energy. In the case of a + polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np + by m (slow to fast) of the relative weights of the corresponding energies in + incident_energy. + + Energy carried by each particle of the beam on leaving the beamline component @@ -194,16 +226,35 @@ - Incident polarization as a Stokes vector on entering beamline component + Incident polarization as a Stokes vector + on entering beamline component + + + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. + + - Polarization as Strokes vector on leaving beamline component + Polarization as Stokes vector on leaving beamline component @@ -290,7 +341,7 @@ - Here: SI units are ''J/m2'', customary ''mJ/cm2''. + Here: SI units are 'J/m2', customary 'mJ/cm2'. @@ -336,9 +387,9 @@ - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly - useful for simulations which need to store plottable information at each beamline - component. + Distribution of beam with respect to relevant variable e.g. wavelength. + This is mainly useful for simulations which need to store plottable + information at each beamline component. @@ -425,4 +476,343 @@ + diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml old mode 100755 new mode 100644 index 2bb4ca533e..8de48bc0f8 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -1,7 +1,315 @@ - + + + + (**required**) :ref:`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. + + + + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXdata` group contains the data + to be shown by default. + It is used to resolve ambiguity when + one :ref:`NXdata` group exists. + The value :ref:`names <validItemName>` a child group. If that group + itself has a ``default`` attribute, continue this chain until an + :ref:`NXdata` group is reached. + + For more information about how NeXus identifies the default + plottable data, see the + :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` + section. + + + + + The data group + + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 + + + + + + ISIS Muon IDF_Version + + + + + Extended title for entry + + + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + + + + Brief summary of the experiment, including key objectives. + + + + + Description of the full experiment (document in pdf, latex, ...) + + + + + User or Data Acquisition defined group of NeXus files or NXentry + + + + + Brief summary of the collection, including grouping criteria. + + + + + Unique identifier for the measurement, defined by the facility. + + + + + UUID identifier for the measurement. + + + + Version of UUID used + + + + + + Reserved for future use by NIAC. + + See https://github.com/nexusformat/definitions/issues/382 + + + + + (alternate use: see same field in :ref:`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms which must be + the name of the NXDL file (case sensitive without the file extension) + that the NXDL schema is defined in. + + For example the ``definition`` field for a file that conformed to the + *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. + + This field is provided so that :ref:`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Starting time of measurement + + + + + Ending time of measurement + + + + + Duration of measurement + + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + + + Name of program used to generate this file + + + + Program version number + + + + + configuration of the program + + + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + + City and country where the experiment took place + + + + + Start time of experimental run that includes the current + measurement, for example a beam time. + + + + + End time of experimental run that includes the current + measurement, for example a beam time. + + + + + Name of the institution hosting the facility + + + + + Name of the experimental facility + + + + + Name of the laboratory or beamline + + + + + Notes describing entry + + + + + A small image that is representative of the entry. An example of this is + a 640x480 jpeg image automatically produced by a low resolution plot + of the NXdata. + + + + The mime type should be an ``image/*`` + + + + + + + + + + + + + + + + +-\-> - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXdata` group contains the data - to be shown by default. - It is used to resolve ambiguity when - one :ref:`NXdata` group exists. - The value :ref:`names <validItemName>` a child group. If that group - itself has a ``default`` attribute, continue this chain until an - :ref:`NXdata` group is reached. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` - section. - + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXdata` group contains the data + to be shown by default. + It is used to resolve ambiguity when + one :ref:`NXdata` group exists. + The value :ref:`names <validItemName>` a child group. If that group + itself has a ``default`` attribute, continue this chain until an + :ref:`NXdata` group is reached. + + For more information about how NeXus identifies the default + plottable data, see the + :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` + section. + - (**required**) :ref:`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. + (**required**) :ref:`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. - The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 - - + The data group + + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 + + - + ISIS Muon IDF_Version @@ -100,10 +408,10 @@ - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + Brief summary of the experiment, including key objectives. @@ -126,38 +434,38 @@ - Reserved for future use by NIAC. - - See https://github.com/nexusformat/definitions/issues/382 - + Reserved for future use by NIAC. + + See https://github.com/nexusformat/definitions/issues/382 + - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms which must be - the name of the NXDL file (case sensitive without the file extension) - that the NXDL schema is defined in. - - For example the ``definition`` field for a file that conformed to the - *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. - - This field is provided so that :ref:`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. - + (alternate use: see same field in :ref:`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms which must be + the name of the NXDL file (case sensitive without the file extension) + that the NXDL schema is defined in. + + For example the ``definition`` field for a file that conformed to the + *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. + + This field is provided so that :ref:`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + NXDL version number URL of NXDL file - Local NXDL schema extended from the entry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the entry. - + Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry. + NXDL version number URL of NXDL file @@ -172,9 +480,9 @@ - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + Such as "2007-3". Some user facilities organize their beam time into run cycles. @@ -186,35 +494,35 @@ - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + Notes describing entry - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + The mime type should be an ``image/*`` - + -\-> @@ -227,4 +535,5 @@ +--> diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 85900d3f03..f7c6f7e376 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -1,14 +1,14 @@ - + + + + The neutron or x-ray storage ring/facility. + + + + Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample. + + + + + Name of source + + + + short name for source, perhaps the acronym + + + + + + type of radiation source (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + + + + + + + + + type of radiation probe (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + Source power + + + + + Source emittance (nm-rad) in X (horizontal) direction. + + + + + Source emittance (nm-rad) in Y (horizontal) direction. + + + + + particle beam size in x + + + + + particle beam size in y + + + + + Source intensity/area (example: s-1 cm-2) + + + + + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. + + + + + Accelerator, X-ray tube, or storage ring current + + + + + Accelerator voltage + + + + + Frequency of pulsed source + + + + + Period of pulsed source + + + + + Pulsed source target material + + + + + + + + + + + + + + + + + + + any source/facility related messages/events that + occurred during the experiment + + + + + For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns. + + + + name of the bunch pattern + + + + + + For storage rings, the number of bunches in use. + + + + + For storage rings, temporal length of the bunch + + + + + For storage rings, time between bunches + + + + + temporal width of source pulse + + + + + + source pulse shape + + + + + + source operating mode + + + + + for storage rings + + + + + for storage rings + + + + + + + + + Is the synchrotron operating in top_up mode? + + + + + For storage rings, the current at the end of the most recent injection. + + + + date and time of the most recent injection. + + + + + + The center photon energy of the source, before it is + monochromatized or converted + + + + + The center wavelength of the source, before it is + monochromatized or converted + + + + + For pulsed sources, the energy of a single pulse + + + + + For pulsed sources, the pulse energy divided + by the pulse duration + + + + + Some facilities tag each bunch. + First bunch of the measurement + + + + + Last bunch of the measurement + + + + + "Engineering" location of source. + + + + + This group describes the shape of the beam line component + + + + + The wavelength or energy distribution of the source + + + + + .. 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. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image:: source/source.png + :width: 40% + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + + temporal width of source pulse - source pulse shape + source pulse shape source operating mode for storage rings for storage rings - + @@ -165,53 +489,54 @@ - "Engineering" location of source. - + "Engineering" location of source. + - This group describes the shape of the beam line component - + This group describes the shape of the beam line component + The wavelength or energy distribution of the source - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. - - .. image:: source/source.png - :width: 40% - - + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image:: source/source.png + :width: 40% + + - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + +--> diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml index a1dcb46912..551a5dcd54 100644 --- a/base_classes/nyaml/NXbeam.yaml +++ b/base_classes/nyaml/NXbeam.yaml @@ -34,10 +34,40 @@ NXbeam(NXobject): incident_energy(NX_FLOAT): unit: NX_ENERGY doc: | - Energy carried by each particle of the beam on entering the beamline component + Energy carried by each particle of the beam on entering the beamline component. + + In the case of a monochromatic beam this is the scalar energy. + Several other use cases are permitted, depending on the + presence of other incident_energy_X fields. + + * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + Here, incident_energy_weights and incident_energy_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_energy_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. dimensions: rank: 1 dim: [[1, m]] + incident_energy_spread(NX_NUMBER): + unit: NX_ENERGY + doc: | + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in + the energy spread, this is a 2D array of dimension nP by m + (slow to fast) of the spreads of the corresponding + wavelength in incident_wavelength. + incident_energy_weights(NX_NUMBER): + unit: NX_ENERGY + doc: | + In the case of a polychromatic beam this is an array of length m of the relative + weights of the corresponding energies in incident_energy. In the case of a + polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np + by m (slow to fast) of the relative weights of the corresponding energies in + incident_energy. final_energy(NX_FLOAT): unit: NX_ENERGY doc: | @@ -143,14 +173,32 @@ NXbeam(NXobject): incident_polarization(NX_NUMBER): unit: NX_ANY doc: | - Incident polarization as a Stokes vector on entering beamline component + Incident polarization as a Stokes vector + on entering beamline component dimensions: rank: 2 dim: [[1, nP], [2, 2]] + \@units: + type: NX_CHAR + doc: | + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. final_polarization(NX_NUMBER): unit: NX_ANY doc: | - Polarization as Strokes vector on leaving beamline component + Polarization as Stokes vector on leaving beamline component dimensions: rank: 2 dim: [[1, nP], [2, 2]] @@ -212,7 +260,7 @@ NXbeam(NXobject): dim: [[1, nP]] pulse_energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: | Energy of a single pulse at the diagnostic point average_power(NX_FLOAT): unit: NX_POWER @@ -220,48 +268,48 @@ NXbeam(NXobject): Average power at the diagnostic point fluence(NX_FLOAT): unit: NX_ANY - doc: | + doc: | Incident fluence at the diagnostic point \@units: type: NX_CHAR - doc: | - Here':' SI units are ''J/m2'', customary ''mJ/cm2''. + doc: | + Here: SI units are 'J/m2', customary 'mJ/cm2'. pulse_duration(NX_FLOAT): unit: NX_TIME - doc: | + doc: | FWHM duration of the pulses at the diagnostic point frog_trace(NX_FLOAT): - doc: | + doc: | FROG trace of the pulse. dimensions: rank: 2 dim: [[1, nx], [2, ny]] frog_delays(NX_FLOAT): unit: NX_TIME - doc: | + doc: | Horizontal axis of a FROG trace, i.e. delay. dimensions: rank: 1 dim: [[1, nx]] frog_frequencies(NX_FLOAT): unit: NX_FREQUENCY - doc: | + doc: | Vertical axis of a FROG trace, i.e. frequency. dimensions: rank: 1 dim: [[1, ny]] chirp_type(NX_CHAR): - doc: | + doc: | The type of chirp implemented chirp_GDD(NX_FLOAT): unit: NX_TIME - doc: | + doc: | Group delay dispersion of the pulse for linear chirp (NXdata): doc: | - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly - useful for simulations which need to store plottable information at each beamline - component. + Distribution of beam with respect to relevant variable e.g. wavelength. + This is mainly useful for simulations which need to store plottable + information at each beamline component. \@default: doc: | .. index:: plotting diff --git a/base_classes/nyaml/NXentry.yaml b/base_classes/nyaml/NXentry.yaml index 78c7888e27..02ff63a813 100644 --- a/base_classes/nyaml/NXentry.yaml +++ b/base_classes/nyaml/NXentry.yaml @@ -81,7 +81,7 @@ NXentry(NXobject): Brief summary of the collection, including grouping criteria. entry_identifier: doc: | - unique identifier for the measurement, defined by the facility. + Unique identifier for the measurement, defined by the facility. entry_identifier_uuid: doc: | UUID identifier for the measurement. @@ -116,8 +116,6 @@ NXentry(NXobject): doc: | URL of NXDL file definition_local: - deprecated: - see same field in :ref:`NXsubentry` for preferred use doc: | Local NXDL schema extended from the entry specified in the ``definition`` field. @@ -168,13 +166,34 @@ NXentry(NXobject): by the moderator or the source itself. In other words: it the distance to the component which gives the T0 signal to the detector electronics. If another component in the NXinstrument hierarchy provides this information, this should be a link. + experiment_location: + doc: | + City and country where the experiment took place + experiment_start_date(NX_DATE_TIME): + doc: | + Start time of experimental run that includes the current + measurement, for example a beam time. + experiment_end_date(NX_DATE_TIME): + doc: | + End time of experimental run that includes the current + measurement, for example a beam time. + experiment_institution: + doc: | + Name of the institution hosting the facility + experiment_facility: + doc: | + Name of the experimental facility + experiment_laboratory: + doc: | + Name of the laboratory or beamline notes(NXnote): doc: | Notes describing entry thumbnail(NXnote): doc: | - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. + A small image that is representative of the entry. An example of this is + a 640x480 jpeg image automatically produced by a low resolution plot + of the NXdata. \@type: doc: | The mime type should be an ``image/*`` diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index eecc390a53..f6c2210879 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -18,7 +18,7 @@ NXsource(NXobject): type: doc: | type of radiation source (pick one from the enumerated list and spell exactly) - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray, Arc Lamp, Halogen Lamp, LED] probe: doc: | type of radiation probe (pick one from the enumerated list and spell exactly) @@ -72,7 +72,7 @@ NXsource(NXobject): target_material: doc: | Pulsed source target material - enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] + enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C, Ar, He, Xe, Hg/Cd, H] notes(NXnote): doc: | any source/facility related messages/events that @@ -131,6 +131,32 @@ NXsource(NXobject): type: NX_DATE_TIME doc: | date and time of the most recent injection. + photon_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + The center photon energy of the source, before it is + monochromatized or converted + center_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The center wavelength of the source, before it is + monochromatized or converted + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + For pulsed sources, the energy of a single pulse + peak_power(NX_FLOAT): + unit: NX_POWER + doc: | + For pulsed sources, the pulse energy divided + by the pulse duration + bunch_number_start(NX_INT): + doc: | + Some facilities tag each bunch. + First bunch of the measurement + bunch_number_end(NX_INT): + doc: | + Last bunch of the measurement geometry(NXgeometry): deprecated: Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead From 3f50b9bbf8cd063ddd8b6047e587930c230c9cef Mon Sep 17 00:00:00 2001 From: cmmngr Date: Mon, 8 May 2023 12:30:40 +0200 Subject: [PATCH 144/203] Removed '--' from comments in NXopt and NXbeam_path --- .../nyaml/NXbeam_path.yaml | 40 +++++++++++++++---- contributed_definitions/nyaml/NXopt.yaml | 6 +-- 2 files changed, 34 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml index 375c67a5b0..30372e080b 100644 --- a/contributed_definitions/nyaml/NXbeam_path.yaml +++ b/contributed_definitions/nyaml/NXbeam_path.yaml @@ -1,17 +1,13 @@ # 05/2023 # A draft of a new base class to describe a beam path consisting of one or # more optical elements (e.g. a beam path in a luminescence setup). -# ------------------------------------------------------------------------------ -# Comments: -# * -# ------------------------------------------------------------------------------ + # To do: # [ ] Harmonize common fields/classes among base classes used in NXbeam_path, # e.g. NXshape in NXbeam_splitter and NXpolarizer_opt, or NXsample used for # describing substrates and coatings etc. # [ ] How to describe a setup or beam path? Order/sequence defined by -# NXtransformations? --> discussion needed -# ______________________________________________________________________________ +# NXtransformations? => discussion needed category: base symbols: @@ -55,13 +51,42 @@ NXbeam_path: field, i.e. a link to the first element in the beam path. Example: /entry/instrument/beam_path/radiation_source. + (NXsetup): # or NXorder, NXopt_setup, ... + exists: optional + doc: | + Specify the order of the optical elements by defining a dependency chain. + Each element or device through which the beam passes needs to have an + entry in this class, and the element's or device's name must be + consistend with the name outside of this class (i.e. the field in + NXbeam_path in which its properties are provided) + For each element, a '@depends_on' attribute should be used to state the + position of the element in the beam path by pointing to the previous + element. For the very first element, use the string "." instead. + ELEMENT: + doc: | + For each element in the beam path, one such field must exist with a + '@depends_on' attribute defined to specify its position in the beam + path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows + ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and + 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the + dependency chain, i.e. may have an entry in this class even if they are + not described in the beam path. + ELEMENT is a place holder for the name of an optical beam path element. + Note that the name of this field must be exactly the same as the + element's field name. + \@depends_on: + doc: Add a link to the previous beam path element. + (NXtransformations): + exists: optional + (NXtransformations): # Possibilities: # (1) Modify NXtransformations to include properties that modify the light beam # (e.g. polarization state) instead (or in addition) to transformations like # translation and rotation # (2) Base class similar to NXtransformations but for changes of optical - # properties (e.g. polarization state) + # properties (e.g. polarization state). + exists: optional doc: | Specify the order of the optical elements by defining a dependency chain. For each element, a '@depends_on' attribute should be used to state the @@ -137,6 +162,7 @@ NXbeam_path: (NXbio_source): # input for experts from that field needed # is NXsource sufficient for x-rays? (NXopt_source): + doc: Specify the properties of the optical source. lifespan(NX_NUMBER): exists: recommended doc: Lifespan of the excitation (typically provided in hours). diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 9638cd818e..5baf7ab8ff 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -1,15 +1,11 @@ # 05/2023 # Draft of a NeXus application definition which serves as a template for various # optical spectroscopy experiments -# ------------------------------------------------------------------------------ -# Comments: -# * -# ------------------------------------------------------------------------------ + # To do: # [ ] Check base classes (NXbeam_path + base classes used by it) # [ ] Harmonize NXopt and NXellipsometry # [ ] Fix dimensions and ranks -# ______________________________________________________________________________ category: application doc: | From c85b282826008ecb94927ffd767155219b008a02 Mon Sep 17 00:00:00 2001 From: cmmngr Date: Mon, 8 May 2023 12:31:51 +0200 Subject: [PATCH 145/203] ellipsometry yaml files for testing reader --- .../nyaml/NXellipsometry_new.yaml | 210 +++++ .../nyaml/NXellipsometry_test.yaml | 734 ++++++++++++++++++ 2 files changed, 944 insertions(+) create mode 100644 contributed_definitions/nyaml/NXellipsometry_new.yaml create mode 100644 contributed_definitions/nyaml/NXellipsometry_test.yaml diff --git a/contributed_definitions/nyaml/NXellipsometry_new.yaml b/contributed_definitions/nyaml/NXellipsometry_new.yaml new file mode 100644 index 0000000000..5b3d5ed08e --- /dev/null +++ b/contributed_definitions/nyaml/NXellipsometry_new.yaml @@ -0,0 +1,210 @@ +# 05/2023 +# Application definition for ellipsometry based on NXopt + +# Open questions: +# * Are the symbols inherited from NXopt or do we need to define them here? + +# To do: +# [ ] Harmonize NXopt and NXellipsometry + +category: application +doc: | + An application definition for ellipsometry. +symbols: + doc: Variables used throughout the document, e.g. dimensions or parameters. + N_spectrum: | + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + N_sensors: | + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + N_measurements: | + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + N_incident_angles: Number of angles of incidence of the incident beam. + N_observables: | + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. + +NXellipsometry(Xopt): + (NXentry): + doc: | + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition defines: + + * elements of the experimental instrument + * calibration information if available + * parameters used to tune the state of the sample + * sample description + + definition: + doc: An application definition describing a general optical experiment. + \@version: + doc: | + Version number to identify which definition of this application + definition was used for this entry/data. + \@url: + doc: | + URL where to find further material (documentation, examples) relevant + to the application definition. + enumeration: [NXellipsometry] + + (NXinstrument): + doc: | + General properties of the ellipsometry equipment including information + about the instrument (such as model, company etc.), information about + the calibration of the instrument, elements of the beam path including + the excitation or light source and the detector unit, the sample stage + (plus the sample environment, which also includes sensors used to + monitor external conditions) and elements of the beam path. + + Meta data describing the sample should be specified in ENTRY/SAMPLE + outside of ENTRY/INSTRUMENT. + ellipsometry_type: + doc: What type of ellipsometry was used? See Fujiwara Table 4.2. + enumeration: + [ + rotating analyzer, + rotating analyzer with analyzer compensator, + rotating analyzer with polarizer compensator, + rotating polarizer, + rotating compensator on polarizer side, + rotating compensator on analyzer side, + modulator on polarizer side, + modulator on analyzer side, + dual compensator, + phase modulation, + imaging ellipsometry, + null ellipsometry, + ] + incident_light(NXbeam_path): + doc: | + Describes the light source and the beam path between the source and + the sample. + If a beam splitter (i.e. a device that splits the incoming beam into + two or more beams) is part of the beam path, two or more NXbeam_path + fields may be needed to fully describe the beam paths and the correct + sequence of the beam path elements. + LIGHT_source(NXsource): + doc: | + Specify the used light source and its properties. In case of a + pump-probe setup, use one such field for the source of the probe + and one for the pump beam. It is suggested to use the names + 'probe_source' or 'pump_source' instead of 'LIGHT_source'. + (NXopt_source): + doc: Specify the properties of the optical source. + (NXmonochromator): + exists: optional + doc: | + Monochromator placed before the sample. If the monochromator is + placed after the sample (before the detector), the information + should be provided in 'INSTRUMENT/detection/MONOCHROMATOR'. + The spectral values (wavelength, energy, wavenumber etc.) should + be provided in 'data/SPECTRUM'. + (NXgrating): + exists: optional + doc: "Diffraction grating, as could be used in a monochromator. + If two or more gratings were used, define the angular + dispersion and the wavelength range (min/max wavelength) + for each grating and make sure that the wavelength ranges + do not overlap. The dispersion should be defined for the + entire wavelength range of the experiment." + angular_dispersion(NX_NUMBER): + exists: optional + doc: "Dispersion of the grating in nm/mm used." + grating_wavelength_min(NX_NUMBER): + exists: optional + doc: "Minimum wavelength of the grating." + unit: NX_LENGTH + grating_wavelength_max(NX_NUMBER): + exists: optional + doc: "Maximum wavelength of the grating." + unit: NX_LENGTH + spectral_resolution(NX_NUMBER): + exists: optional + doc: "Spectral resolution of the instrument." + unit: NX_WAVENUMBER + (NXslit): + exists: optional + doc: "Define the width of the monochromator slit in the subfield x_gap." + fixed_slit(NX_BOOLEAN): + exists: optional + doc: "Was the slit width fixed?" + max_gap(NX_NUMBER): + exists: optional + doc: "If slit width was not fixed, define the maximum slit width." + unit: NX_LENGTH + focussing_probes(NX_BOOLEAN): + doc: Were focussing probes (lenses) used? + data_correction(NX_BOOLEAN): + exists: optional + doc: | + Were the recorded data corrected by the window effects of the lenses? + angular_spread(NX_NUMBER): + exists: optional + doc: Specify the angular spread caused by the focussing probes + unit: NX_ANGLE + detection(NXbeam_path): + doc: | + Describes the beam path between the sample and the detector unit, as + well as the detector itself. A detector can be a photomultiplier + (PMT), a CCD in a camera, or an array in a spectrometer. If so, the + whole detector unit goes in here. It is also possible that more than + one detector are part of the setup. Use as many NXdetector fields as + needed. + + If a beam splitter (i.e. a device that splits the incoming beam into + two or more beams) is part of the beam path, two or more NXbeam_path + fields may be needed to fully describe the beam paths and the correct + sequence of the beam path elements. + (NXmonochromator): + exists: optional + doc: | + The spectroscope element of the ellipsometer before the detector, + but often integrated to form one closed unit. + If the monochromator is placed before the sample, it should be + specified in 'INSTRUMENT/incident_light/MONOCHROMATOR'. + The spectral values (wavelength, energy, wavenumber etc.) should + be provided in 'data/SPECTRUM'. + Information on the dispersive element can be specified in the + subfield GRATING. Note that different gratings might be used for + different wavelength ranges. The dispersion of the grating for each + wavelength range can be stored in grating_dispersion. + data(NXprocess): + doc: | + Measured data, data errors, and varied parameters. If reference data + were measured they should be considered a separate experiment and a + link to its NeXus file should be added in reference_data_link. + data_type: + doc: | + Select which type of data was recorded, for example Psi and Delta, + Mueller matrix, Jones matrix etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + enumeration: + [ + Psi/Delta, + tan(Psi)/cos(Delta), + Mueller matrix, + Jones matrix, + N/C/S, + raw data, + ] + column_names: + doc: | + Please list in this array the column names used in your actual data. + That is ['Psi', 'Delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16'] for a + full Mueller matrix, etc. + dimensions: + rank: 1 + dim: [[1, N_observables]] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXellipsometry_test.yaml b/contributed_definitions/nyaml/NXellipsometry_test.yaml new file mode 100644 index 0000000000..68a52830e3 --- /dev/null +++ b/contributed_definitions/nyaml/NXellipsometry_test.yaml @@ -0,0 +1,734 @@ +# 06/2022 +# A draft version of a NeXus application definition for ellipsometry. + +# The document has the following main elements: +# - Instrument used and is characteristics +# - Measured data, the discription of the sample and what was measured about it +# - Derived parameters: extra parameters derived in the measurement software + +category: application +doc: | + Ellipsometry, complex systems, up to variable angle spectroscopy. + + Information on ellipsometry is provided, e.g. in: + + * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, + John Wiley & Sons, 2007. + * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, + North-Holland Publishing Company, 1977. + * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, + William Andrew, 2005. + + Open access sources: + + * https://www.angstromadvanced.com/resource.asp + * https://pypolar.readthedocs.io/en/latest/ + + Review articles: + + * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", + J. Phys. D: Appl. Phys. 32, R45 (1999), + https://doi.org/10.1088/0022-3727/32/9/201 + * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", + Thin Solid Films 571, 334-344 (2014), + https://doi.org/10.1016/j.tsf.2014.03.056 + * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", + Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, + (3 October 1997), + https://doi.org/10.1117/12.283870 + * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", + Thin Solid Films 233, 96-111 (1993), + https://doi.org/10.1016/0040-6090(93)90069-2 + * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", + Adv. Opt. Techn., (2022), + https://doi.org/10.1515/aot-2022-0016 + +symbols: + doc: "Variables used throughout the document, e.g. dimensions and important parameters" + N_wavelength: "Size of the energy or wavelength vector used, the length of + NXinstrument/spectrometer/wavelength array" + N_variables: "How many variables are saved in a measurement. e.g. 2 for Psi + and Delta, 16 for Mueller matrix elements, 15 for normalized + Mueller matrix, 3 for NCS, the length of NXsample/column_names" + N_angles: "Number of incident angles used, the length of + NXinstrument/angle_of_incidence array" + + N_p1: + "Number of sample parameters scanned, if you varied any of the parameters + such as temperature, pressure, or pH, the maximal length of the arrays + specified by NXsample/environment_conditions/SENSOR/value if it exists." + N_time: "Number of time points measured, the length of NXsample/time_points" + +NXellipsometry: + (NXentry): + doc: | + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition defines: + + * elements of the experimental instrument + * calibration information if available + * parameters used to tune the state of the sample + * sample description + + definition: + doc: "An application definition for ellipsometry." + \@version: + doc: "Version number to identify which definition of this application + definition was used for this entry/data." + \@url: + doc: "URL where to find further material (documentation, examples) + relevant to the application definition" + enumeration: [NXellipsometry] + + experiment_identifier: + doc: | + Unique identifier of the experiment, such as a (globally persistent) unique + identifier. + i) The identifier is usually defined by the facility or principle investigator. + ii) The identifier enables to link experiments to e.g. proposals. + + experiment_description: + exists: recommended + doc: "A free-text description of the experiment. What is the aim of the + experiment? The general procedure." + + start_time(NX_DATE_TIME): + doc: "Start time of the experiment. UTC offset should be specified." + + acquisition_program(NXprocess): + exists: optional + program: + doc: "Commercial or otherwise defined given name to the program that was + used to generate the result file(s) with measured data and metadata. + This program converts the measured signals to ellipsometry data. If + home written, one can provide the actual steps in the NOTE subfield + here." + version: + doc: "Either version with build number, commit hash, or description of + a (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner." + \@url: + doc: "Website of the software." + + (NXuser): + exists: [min, 1] + doc: "Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users if relevant is recommended." + name: + doc: "Name of the user." + affiliation: + doc: "Name of the affiliation of the user at the point in time when the + experiment was performed." + address: + doc: "Full address (street, street number, ZIP, city, country) of the + user's affiliation." + email: + doc: "Email address of the user." + orcid: + exists: recommended + doc: "Author ID defined by https://orcid.org/." + telephone_number: + exists: recommended + doc: "Official telephone number of the user." + + (NXinstrument): + doc: "General properties of the ellipsometry equipment" + model: + doc: The name of the instrument + \@version: + doc: "The used version of the hardware if available. If not a + commercial instrument use date of completion of the hardware." + company: + exists: optional + doc: "Name of the company which build the instrument" + + construction_year(NX_DATE_TIME): + exists: optional + doc: "ISO8601 date when the instrument was constructed. + UTC offset should be specified." + + firmware: + doc: "Commercial or otherwise defined name of the software that was + used for the measurement" + \@version: + doc: "Version and build number or commit hash of the software source code" + \@url: + doc: "Website of the software." + + light_source(NXsource): + doc: "Specify the used light source. Multiple selection possible." + + #type: -- be added into the base class + # doc: "NXsource lists already possible sources, and here we list some + # further sources to complement the original list. Please select one or + # more, according to the setup" + # enumeration: [arc lamp, halogen lamp, LED, other] + + #target_material: + # doc: "unlike in the original, the material used to generate the light, that is + # argon, helium, neon, gases, or mercury/cadmium vapor, etc." + + focussing_probes(NX_BOOLEAN): + doc: "Were focussing probes (lenses) used?" + + data_correction(NX_BOOLEAN): + exists: optional + doc: "Were the recorded data corrected by the window effects of the lenses?" + + angular_spread(NX_NUMBER): + exists: optional + doc: "Specify the angular spread caused by the focussing probes" + unit: NX_ANGLE + + ellipsometry_type: + doc: "What type of ellipsometry was used? See Fujiwara Table 4.2" + enumeration: + [ + rotating analyzer, + rotating analyzer with analyzer compensator, + rotating analyzer with polarizer compensator, + rotating polarizer, + rotating compensator on polarizer side, + rotating compensator on analyzer side, + modulator on polarizer side, + modulator on analyzer side, + dual compensator, + phase modulation, + imaging ellipsometry, + null ellipsometry, + ] + + calibration_status(NX_CHAR): + doc: "Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + calibration/calibration_time." + enumeration: + [ + calibration time provided, + no calibration, + within 1 hour, + within 1 day, + within 1 week, + ] + + calibration(NXsubentry): + exists: recommended + doc: "Ellipsometers require regular calibration to adjust the hardware + parameters for proper zero values and background light compensation." + calibration_time(NX_DATE_TIME): + exists: optional + doc: "If calibtration status is 'calibration time provided', specify + the ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified." + + calibration_data(NXsubentry): + doc: "Arrays which provide the measured calibration data. + Multiple sets are possible, e.g. Psi and delta measured on a + e.g. silicon calibration wafer, and the straight-through data. + We recommend to provide data that is measured under the same + settings as the measurement was performed, that is if Psi and + Delta are measured for your data, also provide Psi and Delta + here and use the same wavelenghts as for the measured data." + + calibration_data_type: + doc: "What data were recorded for the calibration? + The number of variables (N_variables) have to be set to the + number of provided data columns accordingly, + e.g. psi/delta -> N_variables = 2, + Jones vector -> N_variables = 4, + Mueller martix -> N_variables = 16, etc." + enumeration: + [ + psi/delta, + tan(psi)/cos(delta), + Jones matrix, + Mueller matrix, + not provided, + ] + calibration_angle_of_incidence(NX_NUMBER): + doc: "Angle(s) of incidence used during the calibration measurement + (excluding straight through mode)" + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, N_calibration_angles]] + + calibration_wavelength(NX_NUMBER): + doc: | + The wavelength or equivalent values (which are inter-convertible). + The importer should convert all to one unit, and make the others + accessible. Historically, energy is used in eV, but for visible + spectroscopy wavelength is more common, for IR wave numbers in + 1/cm units. + + Possibly use the same type of data as for the measurement. + dimensions: + rank: 1 + dim: [[1, N_calibration_wavelength]] + + calibration_data(NX_NUMBER): + doc: "Calibration is performed on a reference surface (usually a + silicon wafer with a well defined oxide layer) at a number of + angles of incidence and in a straight through mode + (transmission in air)." + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: + [ + [1, N_calibration_angles+1], + [2, N_variables], + [3, N_calibration_wavelength], + ] + + calibration_sample(NX_CHAR): + doc: "Free-text to describe which sample was used for calibration, + e.g. silicon wafer with 25 nm thermal oxide layer." + + angle_of_incidence(NX_NUMBER): + doc: "Incident angle of the beam vs. the normal of the bottom + reflective (substrate) surface in the sample" + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, N_angles]] + + stage(NXsubentry): + doc: "Sample stage, holding the sample at a specific position in X,Y,Z + (Cartesian) coordinate system and at an orientation defined + by three Euler angles (alpha, beta, gamma). + The stage may be motorized or manual, special for liquids or gas + environment." + stage_type(NX_CHAR): + doc: "Specify what type of stage was used." + enumeration: + [manual stage, scanning stage, liquid stage, gas cell, cryostat] + + description: + doc: "A free-text field to provide information about the stage." + exists: recommended + (NXtransformations): + exists: recommended + doc: "The stage coordinate system vs. the incident beam. The Z-axis + of the stage is considered to point along the normal of the + substrate (bottom reflecting surface) from the stage towards + the general direction of the light source. The beam comes with + the angle of incidence towards this Z-axis, but in opposite + direction, thus they are connected with a rotation of + 180 - angle of incidence (in degrees). + + This transformation brings us from the NEXUS coordinates to the + stage coordinates. + + Then provide the set of translations (if there are any). These + all have a vector defining their relative direction in the + current coordinate system. (This current coordinate system + changes with every transformation if you set the parameter + 'depends' to the name of the previous step.) + + Last, provide the rotations of the sample" + + alternative: + exists: optional + doc: "If there is no motorized stage, we should at least qualify + where the beam hits the sample and in what direction the + sample stands in a free-text description, e.g. 'center of + sample, long edge parallel to plane of incidence'." + + window(NXaperture): + exists: optional + doc: "For environmental measurements, the environment (liquid, vapor, + vacuum etc.) is enclosed in a cell or cryostat, which has windows + both in the direction of the source and the detector (looking + from the sample). These windows also add a phase shift to the + light altering the measured signal. This shift has to be + corrected based on measuring a known sample in the environmental + cell." + + material(NX_CHAR): + doc: The material of the window + enumeration: + [ + quartz, + diamond, + calcium fluoride, + zinc selenide, + thallium bromoiodide, + alkali halide compound, + Mylar, + other, + ] + + other_material(NX_CHAR): + exists: optional + doc: "If you specified 'other' as window material, decsribe here + what it is." + + thickness(NX_NUMBER): + doc: Thickness of the window + unit: NX_LENGTH + + orientation_angle(NX_NUMBER): + doc: "Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence)." + unit: NX_ANGLE + + reference_data(NXsubentry): + doc: "Recorded data that can be used to calculate the window effect. + Typically this is the substrate (e.g. silicon with thermal + oxide layer) in air without window and in a known medium with + the window." + + reference_sample: + doc: "What sample was used to estimate the window effect?" + + reference_wavelength(NX_NUMBER): + doc: "Wavelength of the reference data. Use the same wavelengths + at which all other measurements are recorded" + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, N_wavelength]] + + data(NX_NUMBER): + exists: recommended + doc: "Recorded data of a reference surface with and without window/medium." + unit: NX_UNITLESS + dimensions: + rank: 4 + dim: [[1, 2], [2, N_angles], [3, N_variables], [4, N_wavelength]] + + (NXdetector): + doc: "Which type of detector was used, and what is known about it? + A detector can be a photomultiplier (PMT), a CCD in a camera, or + an array in a spectrometer. If so, the whole detector unit goes + in here. + Integration time is the count time field, or the real time + field. See their definition." + + detector_type: + doc: "What kind of detector module is used, e.g. CCD-spectrometer, + CCD camera, PMT, photodiode, etc." + enumeration: + [ + PMT, + photodiode, + avalanche diode, + CCD camera, + CCD spectrometer, + other, + ] + + other_detector: + exists: optional + doc: "If you specified 'other' as detector type, please write down + what it is." + + revolution(NX_NUMBER): + exists: optional + doc: "Define how many rotations of the rotating element were taken + into account per spectrum." + unit: NX_ANY + + rotating_element: + doc: "Define which element rotates, e.g. polarizer or analyzer." + enumeration: + [ + polarizer (source side), + analyzer (detector side), + compensator (source side), + compensator (detector side), + ] + + fixed_revolution(NX_NUMBER): + exists: optional + doc: "Rotation rate, if the revolution does not change during + the measurement." + unit: NX_FREQUENCY + + variable_revolution(NX_NUMBER): + exists: optional + doc: "Specify maximum and minimum values for the revolution." + dimensions: + rank: 1 + dim: [[1, 2]] + + intensity_threshold(NX_NUMBER): + exists: optional + doc: "Minimum signal for which dynamic averaging is performed." + unit: NX_UNITLESS + + min_intensity(NX_NUMBER): + exists: optional + doc: "Value for the minimum intensity chosen. + Data points below this value might be skipped by the instrument" + unit: NX_UNITLESS + + spectrometer(NXmonochromator): + doc: "The spectroscope element of the ellipsometer before the detector, + but often integrated to form one closed unit. Information on the + dispersive element can be specified in the subfield GRATING. Note + that different gratings might be used for different wavelength + ranges. The dispersion of the grating for each wavelength range + can be stored in grating_dispersion." + + wavelength(NX_NUMBER): + doc: "Wavelength value(s) used for the measurement. + An array of 1 or more elements. Length defines N_wavelength" + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, N_wavelength]] + + (NXgrating): + exists: optional + doc: "Diffraction grating, as could be used in a monochromator. + If two or more gratings were used, define the angular + dispersion and the wavelength range (min/max wavelength) + for each grating and make sure that the wavelength ranges + do not overlap. The dispersion should be defined for the + entire wavelength range of the experiment." + + angular_dispersion(NX_NUMBER): + exists: optional + doc: "Dispersion of the grating in nm/mm used." + + grating_wavelength_min(NX_NUMBER): + exists: optional + doc: "Minimum wavelength of the grating." + unit: NX_LENGTH + + grating_wavelength_max(NX_NUMBER): + exists: optional + doc: "Maximum wavelength of the grating." + unit: NX_LENGTH + + spectral_resolution(NX_NUMBER): + exists: optional + doc: "Spectral resolution of the instrument." + unit: NX_WAVENUMBER + + (NXslit): + exists: optional + doc: "Define the width of the monochromator slit in the subfield x_gap." + + fixed_slit(NX_BOOLEAN): + exists: optional + doc: "Was the slit width fixed?" + + max_gap(NX_NUMBER): + exists: optional + doc: "If slit width was not fixed, define the maximum slit width." + unit: NX_LENGTH + + (NXsample): + doc: "Properties of the sample, its history, the sample environment and + experimental conditions (e.g. surrounding medium, temperature, + pressure etc.), along with the data (data type, wavelength array, + measured data)." + atom_types: + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + sample_name: + doc: "Descriptive name of the sample" + + sample_history: + doc: "Ideally, a reference to the location or a unique (globally + persistent) identifier (e.g.) of e.g. another file which gives + as many as possible details of the material, its microstructure, + and its thermo-chemo-mechanical processing/preparation history. + In the case that such a detailed history of the sample is not + available, use this field as a free-text description to specify + details of the sample and its preparation." + + preparation_date(NX_DATE_TIME): + exists: recommended + doc: "ISO8601 date with time zone (UTC offset) specified." + + layer_structure: + doc: "Qualitative description of the layer structure for the sample. + For example: Si/native oxide/thermal oxide/polymer/peptide" + + data_identifier(NX_NUMBER): + doc: "An identifier to correlate data to the experimental conditions, + if several were used in this measurement; + typically an index of 0 - N" + + data_type: + doc: "Select which type of data was recorded, for example Psi and Delta + (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). + It is possible to have multiple selections. Data types may also be + converted to each other, e.g. a Mueller matrix contains N,C,S data + as well. This selection defines how many columns (N_variables) are + stored in the data array." + enumeration: + [ + psi/delta, + tan(psi)/cos(delta), + Mueller matrix, + Jones matrix, + N/C/S, + raw data, + ] + + column_names: + doc: + "Please list in this array the column names used in your actual data. + That is ['psi', 'delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for + a full Mueller matrix, etc." + dimensions: + rank: 1 + dim: [[1, N_variables]] + + measured_data(NX_NUMBER): + doc: "Resulting data from the measurement, described by data type. + Minimum two columns containing Psi and Delta, or for the normalized + Mueller matrix it may be 16 (or 15 if the element (1,1) is all 1)." + dimensions: + rank: 5 + dim: + [ + [1, N_time], + [2, N_p1], + [3, N_angles], + [4, N_variables], + [5, N_wavelength], + ] + + data_error(NX_NUMBER): + doc: + "Specified uncertainties (errors) of the data described by data type. + The structure is the same as for the measured data." + exists: recommended + dimensions: + rank: 5 + dim: + [ + [1, N_time], + [2, N_p1], + [3, N_angles], + [4, N_variables], + [5, N_wavelength], + ] + + time_points(NX_NUMBER): + exists: optional + doc: "An array of relative time points if a time series was recorded." + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, N_time]] + + environment_conditions(NXenvironment): + doc: "Specify external parameters that have influenced the sample." + + medium: + doc: "Describe what was the medium above or around the sample. The + common model is built up from the substrate to the medium on the + other side. Both boundaries are assumed infinite in the model. + Here, define the name of the medium (e.g. water, air, UHV, etc.)." + + medium_refractive_indices(NX_NUMBER): + exists: optional + doc: "Array of pairs of complex refractive indices of the medium for + every measured wavelength. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + Specify the complex refractive index: n + ik" + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, N_wavelength]] + + number_of_runs(NX_UINT): + exists: optional + doc: "How many measurements were done varying the parameters? This + forms an extra dimension beyond incident angle, time points and + energy/wavelength (this is the length of the 4th dimension of + the data). Defaults to 1." + unit: NX_DIMENSIONLESS + + varied_parameters: + exists: optional + doc: "Indicates which parameter was changed. Its definition must exist + below. The specified variable has to be number_of_runs long, + providing the parameters for each data set. If you vary more than + one parameter simultaneously use one signal instance for each. + Record every parameter value in a linear manner, so N_p1 is the + number of measurements taken. + For example, if you measure at two temperatures and three pressures + the temperature signal value looks like [T1, T1, T1, T2, T2, T2] + and the pressure signal value looks like [p1, p2, p3, p1, p2, p3], + and N_p1 = 6." + enumeration: + [ + optical excitation, + voltage, + temperature, + pH, + stress, + stage positions, + ] + + optical_excitation(NXsource): + exists: optional + doc: + "Was the sample modified using an optical source? Describe in this + group the parameters of the optical excitation used." + + wavelength(NX_NUMBER): + doc: "Wavelength value(s) or the range used for excitation. + In cases of continuous laser radiation, a value or a set of + values may do but for other illumination types, such as pulsed + lasers, or lamps, a range may describe the source better." + unit: NX_LENGTH + + broadening(NX_NUMBER): + exists: optional + doc: "Specify the FWHM of the excitation" + unit: NX_LENGTH + + duration(NX_NUMBER): + exists: optional + doc: "How long was the sample excited." + unit: NX_TIME + + pulse_energy(NX_NUMBER): + exists: optional + doc: "The integrated energy of light pulse." + unit: NX_ENERGY + + (NXsensor): + exists: optional + doc: "A sensor used to monitor an external condition. The value + field contains the measured values. If it is constant within + an error for every run then use only an array of length one." + + derived_parameters(NXprocess): + exists: optional + doc: "What parameters are derived from the above data." + depolarization(NX_NUMBER): + exists: optional + doc: "Light loss due to depolarization as a value in [0-1]." + unit: NX_UNITLESS + + plot(NXdata): + exists: optional + doc: "A default view of the data, in this case Psi vs. wavelength and + the angles of incidence. If Psi does not exist, use other Mueller + matrix elements, such as N, C and S." + \@axes: + doc: "We recommend to use wavelength as a default attribute, but it + can be replaced in the case of not full spectral ellipsometry + to any suitable parameter along the X-axis." From 4cc77a0fc672ec247e95b54648a6bc694b3c7138 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 25 May 2023 21:15:46 +0200 Subject: [PATCH 146/203] Added base classes for em_nion reader to represent the magboard of Nion microscopes --- contributed_definitions/NXadc.nxdl.xml | 38 ++ .../NXapm_composition_space_results.nxdl.xml | 488 ++++++++++++++++++ .../NXcircuit_board.nxdl.xml | 45 ++ contributed_definitions/NXdac.nxdl.xml | 38 ++ contributed_definitions/nyaml/NXadc.yaml | 10 + .../NXapm_composition_space_results.yaml | 398 ++++++++++++++ .../nyaml/NXcircuit_board.yaml | 17 + contributed_definitions/nyaml/NXdac.yaml | 10 + manual/source/apm-structure.rst | 18 + manual/source/em-structure.rst | 2 + 10 files changed, 1064 insertions(+) create mode 100644 contributed_definitions/NXadc.nxdl.xml create mode 100644 contributed_definitions/NXapm_composition_space_results.nxdl.xml create mode 100644 contributed_definitions/NXcircuit_board.nxdl.xml create mode 100644 contributed_definitions/NXdac.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXadc.yaml create mode 100644 contributed_definitions/nyaml/NXapm_composition_space_results.yaml create mode 100644 contributed_definitions/nyaml/NXcircuit_board.yaml create mode 100644 contributed_definitions/nyaml/NXdac.yaml diff --git a/contributed_definitions/NXadc.nxdl.xml b/contributed_definitions/NXadc.nxdl.xml new file mode 100644 index 0000000000..498c27dbaf --- /dev/null +++ b/contributed_definitions/NXadc.nxdl.xml @@ -0,0 +1,38 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Analog-to-digital converter component/integrated circuit. + + + + TBD. + + + diff --git a/contributed_definitions/NXapm_composition_space_results.nxdl.xml b/contributed_definitions/NXapm_composition_space_results.nxdl.xml new file mode 100644 index 0000000000..72dbb28419 --- /dev/null +++ b/contributed_definitions/NXapm_composition_space_results.nxdl.xml @@ -0,0 +1,488 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of voxel of discretized domain for analyzed part of the dataset. + + + + + The dimensionality of the grid. + + + + + The cardinality or total number of cells/grid points. + + + + + Number of terms in the composition clustering dictionary + + + + + Number of terms in the position clustering dictionary + + + + + Results of a run with Alaukik Saxena's composition space tool. + + This is an initial draft application definition for the common NFDI-MatWerk, + FAIRmat infrastructure use case IUC09 how to improve the organization and + results storage of the composition space tool and make these data at the same + time directly understandable for NOMAD. + + This draft does no contain yet the annotations for how to also store + in the HDF5 file a default visualization whereby the composition grid + could directly be explored using H5Web. I am happy to add this ones the + data have been mapped on this schema, i.e. more discussion needed. + + Also iso-surfaces can be described, for paraprobe, this is a solved problem, + check the respective group in the NXapm_paraprobe_results_nanochem data + schema/application definition. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + + TBD, maybe how to link between pyiron state tracking and app state tracking + + + + + Disencouraged place for free-text for e.g. comments. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. when composition space tool was started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and composition space tool exited as a process. + + + + + The path and name of the config file for this analysis. + TBD, this can be e.g. Alaukik's YAML file for composition space. + + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + + The path and name of the file (technology partner or community format) + from which reconstructed ion positions were loaded. + + + + + + + + The path and name of the file (technology partner or community format + from which ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes were loaded. + + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the executable managed to process the analysis + or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Some suggestions follow, e.g. that field names should be prefixed + with the following controlled terms indicating which individual + coordinate system is described: + + * world + * composition_space + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + + + + + Position of each cell in Euclidean space. + + + + + + + + + + + + + + + + For each ion, the identifier of the voxel in which the ion is located. + + + + + + + + + + + + + + + + + + In Alaukik's tool the GMM step. + + + + + + + + + The keywords of the dictionary of distinguished compositionally- + defined cluster, e.g. the phases. Examples for keywords could be + phase1, phase2, and so one and so forth. + + + + + + + + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + + + + + + + + + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of either phase1 + or phase2, the cluster_dict_keyword would be a list with two names + phase1 and phase2, respectively. The cluster_dict_value would be a + list of e.g. integers 1 and 2. These could be used to build an + array with as many entries as there are voxel and store in this array + the respective value to encode which phase is assumed for each voxel. + + + + + + + + + + In Alaukik's tool the DBScan step after the GMM step. + + + + + + + + + The keywords of the dictionary of distinguished spatially-contiguous + clusters. Examples for keywords could be precipitate1, precipitate2, + and so one and so forth. + + + + + + + + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + + + + + + + + + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of certain precipitates, + say we found ten precipitates and consider the rest as matrix. + We could make a list of say matrix, precipitate1, precipitate2, ..., + precipitate10. With cluster_dict_value then running from 0 to 10, + i.e. matrix is flagged special as 0 and the remaining particles + are indexed conveniently as 1, 2, ..., 10 like end users expect. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXcircuit_board.nxdl.xml b/contributed_definitions/NXcircuit_board.nxdl.xml new file mode 100644 index 0000000000..9610f8f43f --- /dev/null +++ b/contributed_definitions/NXcircuit_board.nxdl.xml @@ -0,0 +1,45 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Circuit board with e.g. ADC and/or DAC electronic components. + + Currently used to store the settings of the so-called magboards used in + Nion electron microscopes but likely this could be a useful base class for + substantially more use cases where details at a deep technical instrument design + level are relevant or important. + + + + TBD by Nion Co. + + + + + diff --git a/contributed_definitions/NXdac.nxdl.xml b/contributed_definitions/NXdac.nxdl.xml new file mode 100644 index 0000000000..b73dc7abee --- /dev/null +++ b/contributed_definitions/NXdac.nxdl.xml @@ -0,0 +1,38 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Digital-to-analog converter component/integrated circuit. + + + + TBD. + + + diff --git a/contributed_definitions/nyaml/NXadc.yaml b/contributed_definitions/nyaml/NXadc.yaml new file mode 100644 index 0000000000..7d6e08bf3c --- /dev/null +++ b/contributed_definitions/nyaml/NXadc.yaml @@ -0,0 +1,10 @@ +category: base +doc: | + Analog-to-digital converter component/integrated circuit. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXadc: + value(NX_NUMBER): + doc: | + TBD. + unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXapm_composition_space_results.yaml b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml new file mode 100644 index 0000000000..3b88c7b1fb --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml @@ -0,0 +1,398 @@ +category: application +doc: | + Results of a run with Alaukik Saxena's composition space tool. + + This is an initial draft application definition for the common NFDI-MatWerk, + FAIRmat infrastructure use case IUC09 how to improve the organization and + results storage of the composition space tool and make these data at the same + time directly understandable for NOMAD. + + This draft does no contain yet the annotations for how to also store + in the HDF5 file a default visualization whereby the composition grid + could directly be explored using H5Web. I am happy to add this ones the + data have been mapped on this schema, i.e. more discussion needed. + + Also iso-surfaces can be described, for paraprobe, this is a solved problem, + check the respective group in the NXapm_paraprobe_results_nanochem data + schema/application definition. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_voxel: Number of voxel of discretized domain for analyzed part of the dataset. + d: The dimensionality of the grid. + c: The cardinality or total number of cells/grid points. + n_clst_dict: Number of terms in the composition clustering dictionary + n_spat_dict: Number of terms in the position clustering dictionary + +NXapm_composition_space_results: + (NXentry): + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + exists: [min, 1, max, 1] + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_composition_space_results] + # can be used for the name of the tool and version but also + # for if desired all the dependencies and libraries + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + job_pyiron_identifier: # TBD, name of the field arguably for sure ... + exists: recommended + doc: | + TBD, maybe how to link between pyiron state tracking and app state tracking + description: + exists: optional + doc: | + Disencouraged place for free-text for e.g. comments. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. when composition space tool was started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and composition space tool exited as a process. + config_filename: + doc: | + The path and name of the config file for this analysis. + TBD, this can be e.g. Alaukik's YAML file for composition space. + # one could also wrap the entire triple of NXprocess (voxelization, gmm, real space) + # by a parent NXprocess whereby one could store the results of multiple analyses + # runs of the tool in the same individually documented way for as many parameter + # runs as desired... + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + dataset(NXapm_input_reconstruction): + filename: + doc: | + The path and name of the file (technology partner or community format) + from which reconstructed ion positions were loaded. + \@version: + iontypes(NXapm_input_ranging): + filename: + doc: | + The path and name of the file (technology partner or community format + from which ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes were loaded. + \@version: + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the executable managed to process the analysis + or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: Details about the coordinate system conventions used. + (NXtransformations): + exists: [min, 1, max, infty] + doc: | + The individual coordinate systems which should be used. + Some suggestions follow, e.g. that field names should be prefixed + with the following controlled terms indicating which individual + coordinate system is described: + + * world + * composition_space + * lab + * specimen + * laser + * leap + * detector + * recon + + + voxelization(NXprocess): + sequence_index(NX_POSINT): + enumeration: [1] + # specify the grid your using and for each ion in which cell i.e. voxel it is + # one could also have a more sophisticated data model where there is some + # fuzziness i.e. if an ML/AI model returns multiple values or a probability + # how likely an ion is in which voxel, for this + # inspect the example of the NXem_ebsd application definition + (NXcg_grid): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + origin(NX_NUMBER): + # default behaviour, if no coordinate system defined, unclear + # if one coordinate system is defined the origin is defined in this cs + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, d]] + symmetry: + enumeration: [cubic] + cell_dimensions(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, d]] + extent(NX_POSINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, d]] + (NXtransformations): + exists: recommended + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + identifier_offset(NX_INT): + doc: | + unit: NX_UNITLESS + position(NX_NUMBER): + doc: Position of each cell in Euclidean space. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + coordinate(NX_INT): + exists: optional + unit: NX_DIMENSIONLESS + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + # bounding box if needed + voxel_identifier(NX_UINT): + doc: | + For each ion, the identifier of the voxel in which the ion is located. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_ions]] + (NXion): + exists: [min, 0, max, infty] + name: + composition(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, n_voxel]] + + clustering_composition_space(NXprocess): + doc: | + In Alaukik's tool the GMM step. + sequence_index(NX_POSINT): + enumeration: [2] + cluster_dict_keyword: + doc: | + The keywords of the dictionary of distinguished compositionally- + defined cluster, e.g. the phases. Examples for keywords could be + phase1, phase2, and so one and so forth. + dimensions: + rank: 1 + dim: [[1, n_clst_dict]] + cluster_dict_value(NX_UINT): + doc: | + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_clst_dict]] + # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd + cluster_identifier(NX_UINT): + doc: | + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of either phase1 + or phase2, the cluster_dict_keyword would be a list with two names + phase1 and phase2, respectively. The cluster_dict_value would be a + list of e.g. integers 1 and 2. These could be used to build an + array with as many entries as there are voxel and store in this array + the respective value to encode which phase is assumed for each voxel. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_voxel]] + # use the fact that with e.g. XDMF one can on-the-fly reinterpret + # a 1d array to represent an explicit 3d grid + # default plots would be nice could directly be integrated in the results file + + clustering_real_space(NXprocess): + doc: | + In Alaukik's tool the DBScan step after the GMM step. + sequence_index(NX_POSINT): + enumeration: [3] + cluster_dict_keyword: + doc: | + The keywords of the dictionary of distinguished spatially-contiguous + clusters. Examples for keywords could be precipitate1, precipitate2, + and so one and so forth. + dimensions: + rank: 1 + dim: [[1, n_spat_dict]] + cluster_dict_value(NX_UINT): + doc: | + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_spat_dict]] + # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd + cluster_identifier(NX_UINT): + doc: | + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of certain precipitates, + say we found ten precipitates and consider the rest as matrix. + We could make a list of say matrix, precipitate1, precipitate2, ..., + precipitate10. With cluster_dict_value then running from 0 to 10, + i.e. matrix is flagged special as 0 and the remaining particles + are indexed conveniently as 1, 2, ..., 10 like end users expect. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_voxel]] + # use the fact that with e.g. XDMF one can on-the-fly reinterpret + # a 1d array to represent an explicit 3d grid + # then the entire visualization just needs a smart XDMF file with + # one section with the coordinates of the voxel center of masses + # one section with the voxel identifier + # one section with the "phase" identifier referring to the clustering_composition_space NXprocess group + # one section with the "precipitate" identifier referring to the clustering_real_space NXprocess group + # technically one should get rid of the unnecessary chunks + # instead define an (nx, ny, nz) C-style array which whose data space + # is reserved by the h5py library upon first call and then (if desired) + # filled incrementally + # the array should be chunked not with an auto-chunking but with a nx, ny, >=1 chunking + # which will make visualization of nx, ny slices naturally fast, making the z-dimension + # chunking as fast as large as possible (needs compromise to remain within chunk cache size) + # will also make the orthogonal section a good compromise fast + # data should be gzip, level 1 compressed and all the redundant parts of the current + # output will collapse substantially + + performance(NXcs_profiling): + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: [min, 0, max, infty] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: [min, 0, max, 1] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: [min, 0, max, 1] + (NXcs_io_obj): + exists: [min, 1, max, infty] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + diff --git a/contributed_definitions/nyaml/NXcircuit_board.yaml b/contributed_definitions/nyaml/NXcircuit_board.yaml new file mode 100644 index 0000000000..882a9ca2c6 --- /dev/null +++ b/contributed_definitions/nyaml/NXcircuit_board.yaml @@ -0,0 +1,17 @@ +category: base +doc: | + Circuit board with e.g. ADC and/or DAC electronic components. + + Currently used to store the settings of the so-called magboards used in + Nion electron microscopes but likely this could be a useful base class for + substantially more use cases where details at a deep technical instrument design + level are relevant or important. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXcircuit_board: + relay(NX_NUMBER): + doc: | + TBD by Nion Co. + unit: NX_UNITLESS + (NXdac): + (NXadc): diff --git a/contributed_definitions/nyaml/NXdac.yaml b/contributed_definitions/nyaml/NXdac.yaml new file mode 100644 index 0000000000..b8fb0aa99c --- /dev/null +++ b/contributed_definitions/nyaml/NXdac.yaml @@ -0,0 +1,10 @@ +category: base +doc: | + Digital-to-analog converter component/integrated circuit. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. +NXdac: + value(NX_NUMBER): + doc: | + TBD. + unit: NX_UNITLESS diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index d1d30ba644..11ef11f39b 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -9,6 +9,7 @@ B5: Atom-probe tomography ApmAppDef ApmBC ApmRemovedBC + ApmFurtherDefs .. _IntroductionApm: @@ -70,3 +71,20 @@ a set of frequently on-the-fly processed computational data. For now we represen .. Removed base classes .. #################### + +.. _ApmFurtherDefs: + +Further data schemas for atom probe +################################### + +We have also developed a collection of application definition which exemplify how data post-processing workflows +with typical steps specific for atom probe and reconstruction of microstructural features can be described with NeXus. +These application definitions and base classes have an own section in the proposal which you can find on the landing +page by inspection the section on computational geometry and microstructures. + +Furthermore, we are working with the NFDI-MatWerk consortium to explore how tools from the FAIRmat and the NFDI-MatWerk +consortium can be used to describe research, data, metadata, and workflows. This work is organized in the infrastructure +use case IUC09 within the NFDI-MatWerk project. One example how NeXus could be used to describe processing of +atom probe data with a tool which was developed by Alaukik Saxena et al. at the Max-Planck-Institut für Eisenforschung GmbH +in Düsseldorf is available as the so-called :ref:`NXapm_composition_space_results` application definition. + diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 5d2dd181f8..dce0dad05b 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -104,6 +104,8 @@ We developed entirely new base classes. Some of them are also used for other tec :ref:`NXstage_lab`: As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. + :ref:`NXcircuit_board`:, :ref:`NXadc`, and :ref:`NXdac`: + Base classes to describe electronic components of an electron microscope. These base classes need still to be harmonized with those used in the field of low-temperature scanning probe microscopy. .. _EmCommonBC: From 5a89a4d1aa8e6be5a766260e7f9888afd5c05050 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Tue, 30 May 2023 15:31:06 +0200 Subject: [PATCH 147/203] New version of NXellipsometry NXellipsometry(NXopt) --- .../nyaml/NXellipsometry.yaml | 772 ++++-------------- 1 file changed, 151 insertions(+), 621 deletions(-) diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index 68a52830e3..b8b39f2040 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -3,8 +3,9 @@ # The document has the following main elements: # - Instrument used and is characteristics -# - Measured data, the discription of the sample and what was measured about it -# - Derived parameters: extra parameters derived in the measurement software +# - Sample: Properties of the sample +# - Data: measured data, data errors +# - Derived parameters: e.g. extra parameters derived in the measurement software category: application doc: | @@ -43,23 +44,46 @@ doc: | Adv. Opt. Techn., (2022), https://doi.org/10.1515/aot-2022-0016 +# symbols: +# doc: "Variables used throughout the document, e.g. dimensions and important parameters" +# N_wavelength: "Size of the energy or wavelength vector used, the length of +# NXinstrument/spectrometer/wavelength array" +# N_variables: "How many variables are saved in a measurement. e.g. 2 for Psi +# and Delta, 16 for Mueller matrix elements, 15 for normalized +# Mueller matrix, 3 for NCS, the length of NXsample/column_names" +# N_angles: "Number of incident angles used, the length of +# NXinstrument/angle_of_incidence array" + +# N_p1: +# "Number of sample parameters scanned, if you varied any of the parameters +# such as temperature, pressure, or pH, the maximal length of the arrays +# specified by NXsample/environment_conditions/SENSOR/value if it exists." +# N_time: "Number of time points measured, the length of NXsample/time_points" symbols: - doc: "Variables used throughout the document, e.g. dimensions and important parameters" - N_wavelength: "Size of the energy or wavelength vector used, the length of - NXinstrument/spectrometer/wavelength array" - N_variables: "How many variables are saved in a measurement. e.g. 2 for Psi - and Delta, 16 for Mueller matrix elements, 15 for normalized - Mueller matrix, 3 for NCS, the length of NXsample/column_names" - N_angles: "Number of incident angles used, the length of - NXinstrument/angle_of_incidence array" - - N_p1: - "Number of sample parameters scanned, if you varied any of the parameters - such as temperature, pressure, or pH, the maximal length of the arrays - specified by NXsample/environment_conditions/SENSOR/value if it exists." + doc: Variables used throughout the document, e.g. dimensions or parameters. + N_spectrum: | + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + N_sensors: | + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + N_measurements: | + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + N_detection_angles: | + Number of detection angles of the beam reflected or scattered off the + sample. + N_incident_angles: Number of angles of incidence of the incident beam. + N_observables: | + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. N_time: "Number of time points measured, the length of NXsample/time_points" -NXellipsometry: +NXellipsometry(NXopt): (NXentry): doc: | This is the application definition describing ellipsometry experiments. @@ -76,120 +100,56 @@ NXellipsometry: * sample description definition: - doc: "An application definition for ellipsometry." + doc: An application definition for ellipsometry. \@version: - doc: "Version number to identify which definition of this application - definition was used for this entry/data." + doc: | + Version number to identify which definition of this application + definition was used for this entry/data. \@url: - doc: "URL where to find further material (documentation, examples) - relevant to the application definition" + doc: | + URL where to find further material (documentation, examples) relevant + to the application definition. enumeration: [NXellipsometry] - - experiment_identifier: - doc: | - Unique identifier of the experiment, such as a (globally persistent) unique - identifier. - i) The identifier is usually defined by the facility or principle investigator. - ii) The identifier enables to link experiments to e.g. proposals. - experiment_description: - exists: recommended - doc: "A free-text description of the experiment. What is the aim of the - experiment? The general procedure." - - start_time(NX_DATE_TIME): - doc: "Start time of the experiment. UTC offset should be specified." - - acquisition_program(NXprocess): - exists: optional - program: - doc: "Commercial or otherwise defined given name to the program that was - used to generate the result file(s) with measured data and metadata. - This program converts the measured signals to ellipsometry data. If - home written, one can provide the actual steps in the NOTE subfield - here." - version: - doc: "Either version with build number, commit hash, or description of - a (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner." - \@url: - doc: "Website of the software." - - (NXuser): - exists: [min, 1] - doc: "Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users if relevant is recommended." - name: - doc: "Name of the user." - affiliation: - doc: "Name of the affiliation of the user at the point in time when the - experiment was performed." - address: - doc: "Full address (street, street number, ZIP, city, country) of the - user's affiliation." - email: - doc: "Email address of the user." - orcid: - exists: recommended - doc: "Author ID defined by https://orcid.org/." - telephone_number: - exists: recommended - doc: "Official telephone number of the user." + doc: | + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. + experiment_type: + doc: Specify the type of ellipsometry. + enumeration: + [ + in situ spectroscopic ellipsometry, + THz spectroscopic ellipsometry, + infrared spectroscopic ellipsometry, + ultraviolet spectroscopic ellipsometry, + uv-vis spectroscopic ellipsometry, + NIR-Vis-UV spectroscopic ellipsometry, + imaging ellipsometry + ] (NXinstrument): - doc: "General properties of the ellipsometry equipment" - model: - doc: The name of the instrument - \@version: - doc: "The used version of the hardware if available. If not a - commercial instrument use date of completion of the hardware." + doc: Properties of the ellipsometry equipment. company: exists: optional - doc: "Name of the company which build the instrument" - + doc: Name of the company which build the instrument. construction_year(NX_DATE_TIME): exists: optional - doc: "ISO8601 date when the instrument was constructed. - UTC offset should be specified." - - firmware: - doc: "Commercial or otherwise defined name of the software that was - used for the measurement" - \@version: - doc: "Version and build number or commit hash of the software source code" - \@url: - doc: "Website of the software." - - light_source(NXsource): - doc: "Specify the used light source. Multiple selection possible." - - #type: -- be added into the base class - # doc: "NXsource lists already possible sources, and here we list some - # further sources to complement the original list. Please select one or - # more, according to the setup" - # enumeration: [arc lamp, halogen lamp, LED, other] - - #target_material: - # doc: "unlike in the original, the material used to generate the light, that is - # argon, helium, neon, gases, or mercury/cadmium vapor, etc." - - focussing_probes(NX_BOOLEAN): - doc: "Were focussing probes (lenses) used?" - - data_correction(NX_BOOLEAN): - exists: optional - doc: "Were the recorded data corrected by the window effects of the lenses?" - - angular_spread(NX_NUMBER): - exists: optional - doc: "Specify the angular spread caused by the focussing probes" - unit: NX_ANGLE - - ellipsometry_type: - doc: "What type of ellipsometry was used? See Fujiwara Table 4.2" + doc: | + ISO8601 date when the instrument was constructed. + UTC offset should be specified. + software(NXprocess): + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and metadata. + This program converts the measured signals to ellipsometry data. If + home written, one can provide the actual steps in the NOTE subfield + here. + ellipsometer_type: + doc: What type of ellipsometry was used? See Fujiwara Table 4.2. enumeration: [ rotating analyzer, @@ -205,530 +165,100 @@ NXellipsometry: imaging ellipsometry, null ellipsometry, ] - - calibration_status(NX_CHAR): - doc: "Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - calibration/calibration_time." + rotating_element_type: + doc: Define which element rotates, e.g. polarizer or analyzer. enumeration: [ - calibration time provided, - no calibration, - within 1 hour, - within 1 day, - within 1 week, + polarizer (source side), + analyzer (detector side), + compensator (source side), + compensator (detector side), ] - - calibration(NXsubentry): - exists: recommended - doc: "Ellipsometers require regular calibration to adjust the hardware - parameters for proper zero values and background light compensation." - calibration_time(NX_DATE_TIME): + (NXbeam_path): + light_source(NXsource): + doc: Specify the used light source. Multiple selection possible. + enumeration: [arc lamp, halogen lamp, LED, other] + focussing_probes(NXlens_opt): exists: optional - doc: "If calibtration status is 'calibration time provided', specify - the ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified." - - calibration_data(NXsubentry): - doc: "Arrays which provide the measured calibration data. - Multiple sets are possible, e.g. Psi and delta measured on a - e.g. silicon calibration wafer, and the straight-through data. - We recommend to provide data that is measured under the same - settings as the measurement was performed, that is if Psi and - Delta are measured for your data, also provide Psi and Delta - here and use the same wavelenghts as for the measured data." - - calibration_data_type: - doc: "What data were recorded for the calibration? - The number of variables (N_variables) have to be set to the - number of provided data columns accordingly, - e.g. psi/delta -> N_variables = 2, - Jones vector -> N_variables = 4, - Mueller martix -> N_variables = 16, etc." - enumeration: - [ - psi/delta, - tan(psi)/cos(delta), - Jones matrix, - Mueller matrix, - not provided, - ] - calibration_angle_of_incidence(NX_NUMBER): - doc: "Angle(s) of incidence used during the calibration measurement - (excluding straight through mode)" - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, N_calibration_angles]] - - calibration_wavelength(NX_NUMBER): + doc: | + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. + data_correction(NX_BOOLEAN): doc: | - The wavelength or equivalent values (which are inter-convertible). - The importer should convert all to one unit, and make the others - accessible. Historically, energy is used in eV, but for visible - spectroscopy wavelength is more common, for IR wave numbers in - 1/cm units. - - Possibly use the same type of data as for the measurement. - dimensions: - rank: 1 - dim: [[1, N_calibration_wavelength]] - - calibration_data(NX_NUMBER): - doc: "Calibration is performed on a reference surface (usually a - silicon wafer with a well defined oxide layer) at a number of - angles of incidence and in a straight through mode - (transmission in air)." - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_calibration_angles+1], - [2, N_variables], - [3, N_calibration_wavelength], - ] - - calibration_sample(NX_CHAR): - doc: "Free-text to describe which sample was used for calibration, - e.g. silicon wafer with 25 nm thermal oxide layer." - - angle_of_incidence(NX_NUMBER): - doc: "Incident angle of the beam vs. the normal of the bottom - reflective (substrate) surface in the sample" - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, N_angles]] - - stage(NXsubentry): - doc: "Sample stage, holding the sample at a specific position in X,Y,Z - (Cartesian) coordinate system and at an orientation defined - by three Euler angles (alpha, beta, gamma). - The stage may be motorized or manual, special for liquids or gas - environment." - stage_type(NX_CHAR): - doc: "Specify what type of stage was used." - enumeration: - [manual stage, scanning stage, liquid stage, gas cell, cryostat] - - description: - doc: "A free-text field to provide information about the stage." - exists: recommended - (NXtransformations): - exists: recommended - doc: "The stage coordinate system vs. the incident beam. The Z-axis - of the stage is considered to point along the normal of the - substrate (bottom reflecting surface) from the stage towards - the general direction of the light source. The beam comes with - the angle of incidence towards this Z-axis, but in opposite - direction, thus they are connected with a rotation of - 180 - angle of incidence (in degrees). - - This transformation brings us from the NEXUS coordinates to the - stage coordinates. - - Then provide the set of translations (if there are any). These - all have a vector defining their relative direction in the - current coordinate system. (This current coordinate system - changes with every transformation if you set the parameter - 'depends' to the name of the previous step.) - - Last, provide the rotations of the sample" - - alternative: - exists: optional - doc: "If there is no motorized stage, we should at least qualify - where the beam hits the sample and in what direction the - sample stands in a free-text description, e.g. 'center of - sample, long edge parallel to plane of incidence'." - - window(NXaperture): - exists: optional - doc: "For environmental measurements, the environment (liquid, vapor, - vacuum etc.) is enclosed in a cell or cryostat, which has windows - both in the direction of the source and the detector (looking - from the sample). These windows also add a phase shift to the - light altering the measured signal. This shift has to be - corrected based on measuring a known sample in the environmental - cell." - - material(NX_CHAR): - doc: The material of the window - enumeration: - [ - quartz, - diamond, - calcium fluoride, - zinc selenide, - thallium bromoiodide, - alkali halide compound, - Mylar, - other, - ] - - other_material(NX_CHAR): - exists: optional - doc: "If you specified 'other' as window material, decsribe here - what it is." - - thickness(NX_NUMBER): - doc: Thickness of the window - unit: NX_LENGTH - - orientation_angle(NX_NUMBER): - doc: "Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence)." - unit: NX_ANGLE - - reference_data(NXsubentry): - doc: "Recorded data that can be used to calculate the window effect. - Typically this is the substrate (e.g. silicon with thermal - oxide layer) in air without window and in a known medium with - the window." - - reference_sample: - doc: "What sample was used to estimate the window effect?" - - reference_wavelength(NX_NUMBER): - doc: "Wavelength of the reference data. Use the same wavelengths - at which all other measurements are recorded" - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, N_wavelength]] - - data(NX_NUMBER): + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? + angular_spread(NX_NUMBER): exists: recommended - doc: "Recorded data of a reference surface with and without window/medium." - unit: NX_UNITLESS - dimensions: - rank: 4 - dim: [[1, 2], [2, N_angles], [3, N_variables], [4, N_wavelength]] - - (NXdetector): - doc: "Which type of detector was used, and what is known about it? - A detector can be a photomultiplier (PMT), a CCD in a camera, or - an array in a spectrometer. If so, the whole detector unit goes - in here. - Integration time is the count time field, or the real time - field. See their definition." - - detector_type: - doc: "What kind of detector module is used, e.g. CCD-spectrometer, - CCD camera, PMT, photodiode, etc." - enumeration: - [ - PMT, - photodiode, - avalanche diode, - CCD camera, - CCD spectrometer, - other, - ] - - other_detector: - exists: optional - doc: "If you specified 'other' as detector type, please write down - what it is." - - revolution(NX_NUMBER): - exists: optional - doc: "Define how many rotations of the rotating element were taken - into account per spectrum." - unit: NX_ANY - - rotating_element: - doc: "Define which element rotates, e.g. polarizer or analyzer." - enumeration: - [ - polarizer (source side), - analyzer (detector side), - compensator (source side), - compensator (detector side), - ] - - fixed_revolution(NX_NUMBER): - exists: optional - doc: "Rotation rate, if the revolution does not change during - the measurement." - unit: NX_FREQUENCY - - variable_revolution(NX_NUMBER): - exists: optional - doc: "Specify maximum and minimum values for the revolution." - dimensions: - rank: 1 - dim: [[1, 2]] - - intensity_threshold(NX_NUMBER): - exists: optional - doc: "Minimum signal for which dynamic averaging is performed." - unit: NX_UNITLESS - - min_intensity(NX_NUMBER): - exists: optional - doc: "Value for the minimum intensity chosen. - Data points below this value might be skipped by the instrument" - unit: NX_UNITLESS - - spectrometer(NXmonochromator): - doc: "The spectroscope element of the ellipsometer before the detector, - but often integrated to form one closed unit. Information on the - dispersive element can be specified in the subfield GRATING. Note - that different gratings might be used for different wavelength - ranges. The dispersion of the grating for each wavelength range - can be stored in grating_dispersion." - - wavelength(NX_NUMBER): - doc: "Wavelength value(s) used for the measurement. - An array of 1 or more elements. Length defines N_wavelength" - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, N_wavelength]] - - (NXgrating): + doc: Specify the angular spread caused by the focussing probes. + unit: NX_ANGLE + (NXdetector): + doc: | + Properties of the detector used. Integration time is the count time + field, or the real time field. See their definition. + rotating_element(NXwaveplate): exists: optional - doc: "Diffraction grating, as could be used in a monochromator. - If two or more gratings were used, define the angular - dispersion and the wavelength range (min/max wavelength) - for each grating and make sure that the wavelength ranges - do not overlap. The dispersion should be defined for the - entire wavelength range of the experiment." - - angular_dispersion(NX_NUMBER): + doc: | + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + revolutions(NX_NUMBER): exists: optional - doc: "Dispersion of the grating in nm/mm used." - - grating_wavelength_min(NX_NUMBER): + doc: | + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. + unit: NX_COUNTS + fixed_revolutions(NX_NUMBER): exists: optional - doc: "Minimum wavelength of the grating." - unit: NX_LENGTH - - grating_wavelength_max(NX_NUMBER): + doc: | + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). + unit: NX_COUNTS + max_revolutions(NX_NUMBER): exists: optional - doc: "Maximum wavelength of the grating." - unit: NX_LENGTH - - spectral_resolution(NX_NUMBER): - exists: optional - doc: "Spectral resolution of the instrument." - unit: NX_WAVENUMBER - - (NXslit): + doc: | + Specify the maximum value of revolutions of the rotating element + for each measurement. + unit: NX_COUNTS + spectrometer(NXmonochromator): exists: optional - doc: "Define the width of the monochromator slit in the subfield x_gap." - - fixed_slit(NX_BOOLEAN): - exists: optional - doc: "Was the slit width fixed?" - - max_gap(NX_NUMBER): - exists: optional - doc: "If slit width was not fixed, define the maximum slit width." - unit: NX_LENGTH + doc: | + The spectroscope element of the ellipsometer before the detector, + but often integrated to form one closed unit. Information on the + dispersive element can be specified in the subfield GRATING. Note + that different gratings might be used for different wavelength + ranges. The dispersion of the grating for each wavelength range can + be stored in grating_dispersion. (NXsample): - doc: "Properties of the sample, its history, the sample environment and - experimental conditions (e.g. surrounding medium, temperature, - pressure etc.), along with the data (data type, wavelength array, - measured data)." - atom_types: + backside_roughness(NX_BOOLEAN): doc: | - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - sample_name: - doc: "Descriptive name of the sample" - - sample_history: - doc: "Ideally, a reference to the location or a unique (globally - persistent) identifier (e.g.) of e.g. another file which gives - as many as possible details of the material, its microstructure, - and its thermo-chemo-mechanical processing/preparation history. - In the case that such a detailed history of the sample is not - available, use this field as a free-text description to specify - details of the sample and its preparation." - - preparation_date(NX_DATE_TIME): - exists: recommended - doc: "ISO8601 date with time zone (UTC offset) specified." - - layer_structure: - doc: "Qualitative description of the layer structure for the sample. - For example: Si/native oxide/thermal oxide/polymer/peptide" - - data_identifier(NX_NUMBER): - doc: "An identifier to correlate data to the experimental conditions, - if several were used in this measurement; - typically an index of 0 - N" + Was the backside of the sample roughened? Relevant for infrared + ellipsometry. + data_collection(NXprocess): data_type: - doc: "Select which type of data was recorded, for example Psi and Delta + doc: | + Select which type of data was recorded, for example Psi and Delta (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It is possible to have multiple selections. Data types may also be converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. This selection defines how many columns (N_variables) are - stored in the data array." + as well. This selection defines how many columns (N_observables) are + stored in the data array. enumeration: [ - psi/delta, - tan(psi)/cos(delta), + Psi/Delta, + tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data, ] - - column_names: - doc: - "Please list in this array the column names used in your actual data. - That is ['psi', 'delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for - a full Mueller matrix, etc." - dimensions: - rank: 1 - dim: [[1, N_variables]] - - measured_data(NX_NUMBER): - doc: "Resulting data from the measurement, described by data type. - Minimum two columns containing Psi and Delta, or for the normalized - Mueller matrix it may be 16 (or 15 if the element (1,1) is all 1)." - dimensions: - rank: 5 - dim: - [ - [1, N_time], - [2, N_p1], - [3, N_angles], - [4, N_variables], - [5, N_wavelength], - ] - - data_error(NX_NUMBER): - doc: - "Specified uncertainties (errors) of the data described by data type. - The structure is the same as for the measured data." - exists: recommended - dimensions: - rank: 5 - dim: - [ - [1, N_time], - [2, N_p1], - [3, N_angles], - [4, N_variables], - [5, N_wavelength], - ] - - time_points(NX_NUMBER): - exists: optional - doc: "An array of relative time points if a time series was recorded." - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, N_time]] - - environment_conditions(NXenvironment): - doc: "Specify external parameters that have influenced the sample." - - medium: - doc: "Describe what was the medium above or around the sample. The - common model is built up from the substrate to the medium on the - other side. Both boundaries are assumed infinite in the model. - Here, define the name of the medium (e.g. water, air, UHV, etc.)." - - medium_refractive_indices(NX_NUMBER): - exists: optional - doc: "Array of pairs of complex refractive indices of the medium for - every measured wavelength. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - Specify the complex refractive index: n + ik" - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, N_wavelength]] - - number_of_runs(NX_UINT): - exists: optional - doc: "How many measurements were done varying the parameters? This - forms an extra dimension beyond incident angle, time points and - energy/wavelength (this is the length of the 4th dimension of - the data). Defaults to 1." - unit: NX_DIMENSIONLESS - - varied_parameters: - exists: optional - doc: "Indicates which parameter was changed. Its definition must exist - below. The specified variable has to be number_of_runs long, - providing the parameters for each data set. If you vary more than - one parameter simultaneously use one signal instance for each. - Record every parameter value in a linear manner, so N_p1 is the - number of measurements taken. - For example, if you measure at two temperatures and three pressures - the temperature signal value looks like [T1, T1, T1, T2, T2, T2] - and the pressure signal value looks like [p1, p2, p3, p1, p2, p3], - and N_p1 = 6." - enumeration: - [ - optical excitation, - voltage, - temperature, - pH, - stress, - stage positions, - ] - - optical_excitation(NXsource): - exists: optional - doc: - "Was the sample modified using an optical source? Describe in this - group the parameters of the optical excitation used." - - wavelength(NX_NUMBER): - doc: "Wavelength value(s) or the range used for excitation. - In cases of continuous laser radiation, a value or a set of - values may do but for other illumination types, such as pulsed - lasers, or lamps, a range may describe the source better." - unit: NX_LENGTH - - broadening(NX_NUMBER): - exists: optional - doc: "Specify the FWHM of the excitation" - unit: NX_LENGTH - - duration(NX_NUMBER): - exists: optional - doc: "How long was the sample excited." - unit: NX_TIME - - pulse_energy(NX_NUMBER): - exists: optional - doc: "The integrated energy of light pulse." - unit: NX_ENERGY - - (NXsensor): - exists: optional - doc: "A sensor used to monitor an external condition. The value - field contains the measured values. If it is constant within - an error for every run then use only an array of length one." - - derived_parameters(NXprocess): - exists: optional - doc: "What parameters are derived from the above data." - depolarization(NX_NUMBER): - exists: optional - doc: "Light loss due to depolarization as a value in [0-1]." - unit: NX_UNITLESS - - plot(NXdata): - exists: optional - doc: "A default view of the data, in this case Psi vs. wavelength and - the angles of incidence. If Psi does not exist, use other Mueller - matrix elements, such as N, C and S." - \@axes: - doc: "We recommend to use wavelength as a default attribute, but it - can be replaced in the case of not full spectral ellipsometry - to any suitable parameter along the X-axis." + # column_names: + # doc: | + # Please list in this array the column names used in your actual data. + # That is ['Psi', 'Delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for + # a full Mueller matrix, etc. + # dimensions: + # rank: 1 + # dim: [[1, N_observables]] From 0e131fa33271aedcc6c23dbbe23ea347e77894d4 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Tue, 30 May 2023 16:11:48 +0200 Subject: [PATCH 148/203] Updated NXopt --- contributed_definitions/nyaml/NXopt.yaml | 229 +++++++++++++++-------- 1 file changed, 147 insertions(+), 82 deletions(-) diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 5baf7ab8ff..eb595635b6 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -42,7 +42,7 @@ NXopt: beam path, a sample + its stage + its environment, and a detection unit. Examples are reflection or transmission measurements, photoluminescence, Raman spectroscopy, ellipsometry etc. - + definition: doc: An application definition describing a general optical experiment. \@version: @@ -71,30 +71,31 @@ NXopt: experiment_type: doc: Specify the type of the optical experiment. start_time(NX_DATE_TIME): - doc: Start time of the experiment. UTC offset should be specified. + doc: Start time of the experiment. UTC offset should be specified. (NXuser): - exists: [min, 1] doc: | Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users, if relevant, is recommended. - name: + name(NX_CHAR): doc: Name of the user. - affiliation: + affiliation(NX_CHAR): + exists: recommended doc: | Name of the affiliation of the user at the point in time when the experiment was performed. - address: + address(NX_CHAR): + exists: recommended doc: Street address of the user's affiliation. - email: + email(NX_CHAR): doc: Email address of the user. - orcid: + orcid(NX_CHAR): exists: recommended doc: Author ID defined by https://orcid.org/. - telephone_number: + telephone_number(NX_CHAR): exists: recommended doc: Telephone number of the user. - + (NXinstrument): doc: | Properties of the experimental setup. This includes general information @@ -108,7 +109,7 @@ NXopt: outside of ENTRY/INSTRUMENT. model: doc: The name of the instrument. - \@version: + \@version: doc: | The used version of the hardware if available. If not a commercial instrument use date of completion of the hardware. @@ -124,10 +125,10 @@ NXopt: program: doc: | Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and metadata. - This program converts the measured signals to ellipsometry data. If - home written, one can provide the actual steps in the NOTE subfield - here. + used to measure the data, i.e. the software used to start and + record the measured data and/or metadata. + If home written, one can provide the actual steps in the NOTE + subfield here. version: doc: | Either version with build number, commit hash, or description of a @@ -138,15 +139,16 @@ NXopt: \@url: exists: optional doc: Website of the software. - firmware: + firmware(NXprogram): exists: recommended doc: | - Commercial or otherwise defined name of the software that was used + Commercial or otherwise defined name of the firmware that was used for the measurement - if available. \@version: doc: | Version and build number or commit hash of the software source code. \@url: + exists: optional doc: Website of the software. calibration_status(NX_CHAR): doc: | @@ -160,7 +162,7 @@ NXopt: within 1 hour, within 1 day, within 1 week, - ] + ] calibration(NXsubentry): exists: recommended doc: The calibration data and metadata should be described in a @@ -173,15 +175,19 @@ NXopt: measurement. UTC offset should be specified. calibration_data_link: doc: | - Link to the NeXus file containing the calibration data and metadata. - incident_light(NXbeam_path): + Link to the NeXus file containing the calibration data and metadata. + (NXbeam_path): doc: | - Describes the light source and the beam path between the source and - the sample. + Describes an arrangement of optical or other elements, e.g. the beam + path between the light source and the sample, or between the sample + and the detector unit (including the sources and detectors + themselves). + If a beam splitter (i.e. a device that splits the incoming beam into two or more beams) is part of the beam path, two or more NXbeam_path fields may be needed to fully describe the beam paths and the correct sequence of the beam path elements. + Use as many beam paths as needed to describe the setup. angle_of_incidence(NX_NUMBER): doc: | Angle(s) of the incident beam vs. the normal of the bottom reflective @@ -190,14 +196,7 @@ NXopt: dimensions: rank: 1 dim: [[1, N_incident_angles]] - detection(NXbeam_path): - doc: | - Describes the beam path between the sample and the detector unit, as - well as the detector itself. - If a beam splitter (i.e. a device that splits the incoming beam into - two or more beams) is part of the beam path, two or more NXbeam_path - fields may be needed to fully describe the beam paths and the correct - sequence of the beam path elements. + \@units: detection_angle(NX_NUMBER): exists: optional doc: | @@ -215,7 +214,7 @@ NXopt: by three Euler angles (alpha, beta, gamma). stage_type: doc: Specify the type of the sample stage. - enumeration: + enumeration: [ manual stage, scanning stage, @@ -223,27 +222,6 @@ NXopt: gas cell, cryostat ] - (NXtransformations): - exists: recommended - doc: | - The stage coordinate system vs. the incident beam. The Z-axis of - the stage is considered to point along the normal of the substrate - (bottom reflecting surface) from the stage towards the general - direction of the light source. The beam comes with angle of - incidence towards this Z-axis, but in opposite direction, thus they - are connected with a rotation of 180 - angle of incidence (in - degrees). - - This transformation brings us from the NeXus to the stage - coordinates. - - Then provide the set of translations (if there are any). These all - have a vector defining their relative direction in the current - coordinate system. (This current coordinate system changes with - every transformation if you set the parameter 'depends' to the name - of the previous step.) - - Last, provide the rotations of the sample. alternative: exists: optional doc: | @@ -255,7 +233,7 @@ NXopt: doc: | Specify external parameters that have influenced the sample, such as the surrounding medium, and varied parameters e.g. temperature, - pressure, pH value, optical excitation etc. + pressure, pH value, optical excitation etc. medium: doc: | Describe what was the medium above or around the sample. The @@ -272,7 +250,7 @@ NXopt: unit: NX_UNITLESS dimensions: rank: 2 - dim: + dim: [ [1, 2], [2, N_spectrum] @@ -293,7 +271,7 @@ NXopt: below. The specified variable has to be N_measurements long, providing the parameters for each data set. If you vary more than one parameter simultaneously. - enumeration: + enumeration: [ conductivity, detection_angle, @@ -443,7 +421,8 @@ NXopt: doc: | Angle of the window normal (outer) vs. the substrate normal (similar to the angle of incidence). - unit: NX_ANGLE + unit: NX_ANGLE + (NXsample): doc: | Properties of the sample, such as sample type, layer structure, @@ -496,21 +475,22 @@ NXopt: preparation_date(NX_DATE_TIME): exists: recommended doc: ISO8601 date with time zone (UTC offset) specified. - data_identifier(NX_NUMBER): - doc: | - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0-N. substrate: exists: recommended doc: Description of the substrate. sample_orientation: exists: optional doc: Specify the sample orientation. - data(NXprocess): + + data_collection(NXprocess): doc: | Measured data, data errors, and varied parameters. If reference data were measured they should be considered a separate experiment and a link to its NeXus file should be added in reference_data_link. + data_identifier(NX_NUMBER): + doc: | + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. data_type: doc: | Select which type of data was recorded, for example intensity, @@ -530,15 +510,9 @@ NXopt: N/C/S, raw data, ] - column_names: - doc: | - Please list in this array the column names used in your actual data. - That is ['Psi', 'Delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16'] for a - full Mueller matrix, etc. - dimensions: - rank: 1 - dim: [[1, N_observables]] - SPECTRUM(NX_FLOAT): + NAME_spectrum(NX_FLOAT): + # This should be a required field, but is set to 'optional' for the moment + exists: optional doc: | Spectral values (e.g. wavelength or energy) used for the measurement. An array of 1 or more elements. Length defines N_spectrum. Replace @@ -555,8 +529,8 @@ NXopt: here which unit was used. measured_data(NX_FLOAT): doc: | - Resulting data from the measurement, described by 'data_type'. - + Resulting data from the measurement, described by 'data_type'. + The first dimension is defined by the number of measurements taken, (N_measurements). The instructions on how to order the values contained in the parameter vectors given in the doc string of @@ -575,13 +549,13 @@ NXopt: here which unit was used. dimensions: rank: 3 - dim: + dim: [ [1, N_measurements], - [2, N_observables], + [2, N_observables], # 2 for Psi and Delta, 16 for Mueller matrix etc [3, N_spectrum] ] - data_error(NX_FLOAT): + measured_data_errors(NX_FLOAT): exists: optional doc: | Specified uncertainties (errors) of the data described by 'data_type' @@ -595,7 +569,7 @@ NXopt: here which unit was used. dimensions: rank: 3 - dim: + dim: [ [1, N_measurements], [2, N_observables], @@ -616,14 +590,105 @@ NXopt: reference measurement was performed. Ideally, the reference measurement was performed using the same conditions as the actual measurement and should be as close in time to the actual measurement - as possible. - plot(NXdata): - exists: recommended + as possible. + data_software(NXprocess): + exists: optional + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + version: + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@url: + exists: optional + doc: Website of the software. + (NXdata): + exists: optional + doc: | + A plot of the multi-dimensional data array provided in + ENTRY/data/measured_data. + \@axes: + doc: Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + + derived_parameters(NXprocess): + exists: optional + doc: Parameters that are derived from the measured data. + depolarization(NX_NUMBER): + exists: optional + doc: Light loss due to depolarization as a value in [0-1]. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: + [ + [1, N_measurements], + [2, 1], + [3, N_spectrum] + ] + Jones_quality_factor(NX_NUMBER): + exists: optional + doc: Jones quality factor. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: + [ + [1, N_measurements], + [2, 1], + [3, N_spectrum] + ] + reflectivity(NX_NUMBER): + exists: optional + doc: Reflectivity. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: + [ + [1, N_measurements], + [2, 1], + [3, N_spectrum] + ] + transmittance(NX_NUMBER): + exists: optional + doc: Transmittance. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: + [ + [1, N_measurements], + [2, 1], + [3, N_spectrum] + ] + ANALYSIS_program(NXprocess): + exists: optional + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to generate or calculate the derived parameters. + If home written, one can provide the actual steps in the NOTE + subfield here. + version: + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + plot(NXdata): doc: | - A default view of the data provided in ENTRY/data/measured_data. This + A default view of the data provided in ENTRY/data_collection/measured_data. This should be the part of the data set which provides the most suitable representation of the data. \@axes: doc: Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - \@units: - doc: Unit of the x-axis (e.g. nanometer, Angstrom, electron volt etc.) \ No newline at end of file From fb048ba29d677a918ba8e1ef805cf87454e81d2b Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Tue, 30 May 2023 16:12:36 +0200 Subject: [PATCH 149/203] new NXbeam_path --- .../nyaml/NXbeam_path.yaml | 335 +----------------- 1 file changed, 13 insertions(+), 322 deletions(-) diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml index 30372e080b..74d4e7e542 100644 --- a/contributed_definitions/nyaml/NXbeam_path.yaml +++ b/contributed_definitions/nyaml/NXbeam_path.yaml @@ -10,18 +10,6 @@ # NXtransformations? => discussion needed category: base -symbols: - N_spectrum: | - Size of the wavelength or energy vector for which quantities of the optical - element, such as reflectivity or efficiency, are provided. - # N_excitation: | - # Length of the wavelength or energy vector of the excitation source. This - # can be a single value or a spectrum, depending on the type of experiment. - N_beam_profile_dim: | - Number of dimensions for which the beam profile is given. - N_beam_profile_points: | - Number of points of the beam profile. - doc: | A beam path consisting of one or more optical elements. @@ -40,44 +28,15 @@ doc: | NXbeam_path: doc: | Describe the relevant optical elements in the beam path by using the - appropriate sub classes. You may use as many elements as needed, also - several elements of the same type as long as each element has its own name. - Capital letters in the names can be replaced, e.g. lens_NUMBER can be - lens_1, lens_2, or lens_first, lens_second etc. - + appropriate base classes. in NXopt_element You may use as many elements as + needed, also several elements of the same type as long as each element has + its own name. + depends_on: doc: | Entry point of the dependency chain defined by the NXtransformations - field, i.e. a link to the first element in the beam path. + field, i.e. a link to the first element in the beam path. Example: /entry/instrument/beam_path/radiation_source. - - (NXsetup): # or NXorder, NXopt_setup, ... - exists: optional - doc: | - Specify the order of the optical elements by defining a dependency chain. - Each element or device through which the beam passes needs to have an - entry in this class, and the element's or device's name must be - consistend with the name outside of this class (i.e. the field in - NXbeam_path in which its properties are provided) - For each element, a '@depends_on' attribute should be used to state the - position of the element in the beam path by pointing to the previous - element. For the very first element, use the string "." instead. - ELEMENT: - doc: | - For each element in the beam path, one such field must exist with a - '@depends_on' attribute defined to specify its position in the beam - path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows - ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and - 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the - dependency chain, i.e. may have an entry in this class even if they are - not described in the beam path. - ELEMENT is a place holder for the name of an optical beam path element. - Note that the name of this field must be exactly the same as the - element's field name. - \@depends_on: - doc: Add a link to the previous beam path element. - (NXtransformations): - exists: optional (NXtransformations): # Possibilities: @@ -86,13 +45,12 @@ NXbeam_path: # translation and rotation # (2) Base class similar to NXtransformations but for changes of optical # properties (e.g. polarization state). - exists: optional doc: | Specify the order of the optical elements by defining a dependency chain. For each element, a '@depends_on' attribute should be used to state the position of the element in the beam path by pointing to the previous element. For the very first element, use the string "." instead. - ELEMENT(NX_NUMBER): # instead of AXES in NXtransformations... + AXISNAME(NX_NUMBER): doc: | For each element in the beam path, one such field must exist with a '@depends_on' attribute defined to specify its position in the beam @@ -107,281 +65,14 @@ NXbeam_path: unit: NX_TRANSFORMATIONS \@depends_on: doc: Add a link to the previous beam path element. - - (NXsource): - doc: | - Excitation source. One or more may be needed (e.g. two for a pump-probe - setup with one pump and one probe beam). - Depending on the source type, different properties are relevant, which - are provided through the respective base class (e.g. use NXopt_source for - lamps or lasers, NXchem_source for chemical reaction etc.). - Some base classes are incomplete (NXchem_source, NXbio_source); the - expertise of the respective communities is needed. - depends_on: - doc: Use this field to point to the previous optical element. - type: - exists: required - doc: Type of excitation source. - enumeration: - # Spallation Neutron Source - # Pulsed Reactor Neutron Source - # Reactor Neutron Source - # Synchrotron X-ray Source - # Pulsed Muon Source - # Rotating Anode X-ray - # Fixed Tube X-ray - # UV Laser - # Free-Electron Laser - # Optical Laser - # Ion Source - # UV Plasma Source - # Metal Jet X-ray - [ - semiconductor laser, # NXopt_source - gas laser, # NXopt_source - other laser, # NXopt_source - lamp, # NXopt_source - X-rays, # NXsource ??? - silicon carbide globar, # NXopt_source - super continuum, # NXopt_source - chemical reaction, # NXchem_source - ultrasound, # NXacoustic_source - sound, # NXacoustic_source - living organism, # NXbio_source - power supply, # NXpower_supply - electron source, # from NXem ??? - other - ] - # separate base classes for different sources: - (NXacoustic_source): # needs to be developed - doc: | - Acoustic source, e.g. an ultrasonic transducero or a imploding gas - bubble (sonoluminescence). - (NXpower_supply): # needs to be developed - (NXchem_source): # input for experts from that field needed - (NXbio_source): # input for experts from that field needed - # is NXsource sufficient for x-rays? - (NXopt_source): - doc: Specify the properties of the optical source. - lifespan(NX_NUMBER): - exists: recommended - doc: Lifespan of the excitation (typically provided in hours). - unit: NX_TIME - measure_time(NX_NUMBER): - exists: recommended - doc: How many hours has the lamp been used? - unit: NX_TIME - excitation_wavelength(NX_FLOAT): - exists: required - doc: | - Wavelengths or energy vector of the excitation source. This can be a - single value or a spectrum, depending on the type of experiment. - unit: NX_ANY - \@units: - doc: Unit of wavelength or energy. - beam_profile: - # ??? What's the best way to enter this ??? - doc: Two- or three-dimensional beam profile. - dimensions: - rank: 2 - dim: - [ - [1, N_beam_profile_dim], - [2, N_beam_profile_points] - ] - peak_power(NX_FLOAT): - doc: Power of one light pulse if the source is a pulsed source. - unit: NX_POWER - cw(NX_BOOLEAN): - exists: required - doc: Is the excitation source continuous wave (CW)? - cw_power(NX_FLOAT): - doc: Power of CW beam. - bandwidth(NX_FLOAT): - exists: recommended - doc: FWHM bandwidth of the excitation source. - unit: NX_WAVELENGTH - coherence_length(NX_FLOAT): - doc: Coherence length. - unit: NX_LENGTH - divergence(NX_FLOAT): - doc: Divergence of the excitation beam. - unit: NX_ANGLE - - (NXpinhole): - doc: | - Use this field to describe a simple pinhole (round geometry). Define its - dimension using 'diameter'. For more complex geometries, 'NXaperture' - should be used. - - (NXslit): - doc: | - Use this field to describe a simple slit (rectangular geometry). Define - its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, - 'NXaperture' should be used. - - aperture_NUMBER(NXaperture): - doc: | - Use this field to describe an aperture. To specify a window, use the - field 'window_NUMBER(NXaperture)'. - - window_NUMBER(NXaperture): - doc: | - A window, e.g. an entry or exit window of a cryostat. - depends_on: - doc: Use this field to point to the previous optical element. - material(NX_CHAR): - exists: required - doc: The material of the window. - enumeration: - [ - quartz, - diamond, - calcium fluoride, - zinc selenide, - thallium bromoiodide, - alkali halide compound, - Mylar, - other, - ] - other_material(NX_CHAR): - exists: optional - doc: | - If you specified 'other' as material, decsribe here what it is. - thickness(NX_FLOAT): - doc: Thickness of the window - unit: NX_LENGTH - orientation_angle(NX_FLOAT): - doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - unit: NX_ANGLE - reference_data_link: - doc: | - If reference data were measured add a link to the NeXus file where they - are described. - - (NXmirror): - - filter_NUMBER(NXfilter): - (NXattenuator): - doc: A device that reduces the intensity of a beam by attenuation. - attenuator_transmission(NX_FLOAT): - doc: The transmitted intensity divided by the incident intensity. - unit: NX_DIMENSIONLESS - attenuation(NX_FLOAT): - doc: Attenuation of the attenuator in dB. - unit: NX_ANY - \@units: - doc: | - Unit of the measured data is not covered by NXDL units state - here which unit was used. - (NXaperture): - doc: Input and output aperture of the attenuator. - (NXgeomtry): - doc: Geometry (shape, size etc.) of the attenuator. - - (NXgrating): - doc: | - A diffraction grating. Define relevant parameters in the corresponding - fields, e.g. order of diffration (diffraction_order) or angular - dispersion (angular_dispersion). - type: - exists: required - doc: Define the type of the grating. - angular_dispersion(NX_FLOAT): - doc: Dispersion of the grating in nm/mm (or e.g. nm/mrad). - unit: NX_UNITLESS - grooves(NX_FLOAT): - doc: Number of grooves per mm. - unit: NX_PER_LENGTH - blaze_wavelength(NX_FLOAT): - doc: Blaze wavelength of the grating. - unit: NX_WAVELENGTH - efficiency(NX_FLOAT): - doc: Efficiency curve versus wavelength or energy. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: - [[1, N_spectrum]] - spectrum(NX_FLOAT): - doc: | - Spectral values, e.g. wavelength or energy. Vector of length - N_spectrum. - unit: NX_ANY - \@units: - doc: Unit of wavelength array (e.g. nanometer or Angstrom) - - (NXdisk_chopper): + (NXopt_element): + exists: [min, 1] doc: | - A device blocking the beam in a temporal periodic pattern, e.g. a optical - chopper wheel. Specify the frequency range using 'min_frequency' and - 'max_frequency'. - min_frequency(NX_FLOAT): - doc: Minimum frequency in Hertz. - unit: NX_FREQUENCY - max_frequency(NX_FLOAT): - doc: Maximum frequency in Hertz. - unit: NX_FREQUENCY - frequency_resolution(NX_FLOAT): - doc: Frequency resolution in Hertz. - unit: NX_FREQUENCY - - (NXmonochromator): - doc: | - A monochromator or spectrometer. - spectrum(NX_FLOAT): - doc: | - Spectral values of the monochromator, e.g. wavelength or energy values - used for the measurement. - unit: NX_ANY - \@units: - doc: Unit of wavelength array (e.g. nanometer or Angstrom) - (NXgrating): + An optical element that is part of an optical setup or beam path. + If a commercial device, the company and model may be defined in the + respective fields. + company: exists: optional - doc: | - Diffraction grating. If two or more gratings were used, define the - angular dispersion and the wavelength range (min/max wavelength) for - each grating and make sure that the wavelength ranges do not overlap. - The dispersion should be defined for the entire wavelength range of the - experiment. - angular_dispersion(NX_FLOAT): - exists: optional - doc: Dispersion of the grating in nm/mm. - unit: NX_DIMENSIONLESS - grating_wavelength_min(NX_FLOAT): - exists: optional - doc: Minimum wavelength of the grating. - unit: NX_WAVELENGTH - grating_wavelength_max(NX_FLOAT): - exists: optional - doc: Maximum wavelength of the grating. - unit: NX_WAVELENGTH - spectral_resolution(NX_FLOAT): - exists: optional - doc: Spectral resolution of the instrument. - unit: NX_WAVENUMBER - (NXslit): + model: exists: optional - doc: Define the width of the monochromator slit in the subfield x_gap. - fixed_slit(NX_BOOLEAN): - exists: optional - doc: Was the slit width fixed? - max_gap(NX_FLOAT): - exists: optional - doc: If slit width was not fixed, define the maximum slit width. - unit: NX_LENGTH - - # x-ray optics: - (NXxraylens): - # what else? - - # ====== New base classes: ====== - (NXpolarizer_opt): - (NXbeam_splitter): - (NXwaveplate): - (NXlens_opt): - (NXfiber): - From 14575e45e7b0ca532a5f72affe51e0581ebbcc15 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Tue, 30 May 2023 16:15:17 +0200 Subject: [PATCH 150/203] new base class NXopt_element --- .../nyaml/NXopt_element.yaml | 274 ++++++++++++++++++ 1 file changed, 274 insertions(+) create mode 100644 contributed_definitions/nyaml/NXopt_element.yaml diff --git a/contributed_definitions/nyaml/NXopt_element.yaml b/contributed_definitions/nyaml/NXopt_element.yaml new file mode 100644 index 0000000000..ebfab7115e --- /dev/null +++ b/contributed_definitions/nyaml/NXopt_element.yaml @@ -0,0 +1,274 @@ +# 05/2023 +# Base class describing optical elements + +category: base +symbols: + N_spectrum: | + Size of the wavelength or energy vector for which quantities of the optical + element, such as reflectivity or efficiency, are provided. + N_beam_profile_dim: | + Number of dimensions for which the beam profile is given. + N_beam_profile_points: | + Number of points of the beam profile. + +doc: | + Optical elements that may be part of an optical setup or beam path. + +NXopt_element: + doc: | + Describe the optical element by using the appropriate sub class. + + (NXsource): + doc: | + Excitation source. One or more may be needed (e.g. two for a pump-probe + setup with one pump and one probe beam). + Depending on the source type, different properties are relevant, which + are provided through the respective base class (e.g. use NXopt_source for + lamps or lasers, NXchem_source for chemical reaction etc.). + Some base classes are incomplete (NXchem_source, NXbio_source); the + expertise of the respective communities is needed. + depends_on: + doc: Use this field to point to the previous optical element. + type: + exists: required + doc: Type of excitation source. + enumeration: + # Spallation Neutron Source + # Pulsed Reactor Neutron Source + # Reactor Neutron Source + # Synchrotron X-ray Source + # Pulsed Muon Source + # Rotating Anode X-ray + # Fixed Tube X-ray + # UV Laser + # Free-Electron Laser + # Optical Laser + # Ion Source + # UV Plasma Source + # Metal Jet X-ray + [ + semiconductor laser, # NXopt_source + gas laser, # NXopt_source + other laser, # NXopt_source + lamp, # NXopt_source + X-rays, # NXsource ??? + silicon carbide globar, # NXopt_source + super continuum, # NXopt_source + chemical reaction, # NXchem_source + ultrasound, # NXacoustic_source + sound, # NXacoustic_source + living organism, # NXbio_source + power supply, # NXpower_supply + electron source, # from NXem ??? + other + ] + # separate base classes for different sources: + (NXacoustic_source): # needs to be developed + doc: | + Acoustic source, e.g. an ultrasonic transducero or a imploding gas + bubble (sonoluminescence). + (NXpower_supply): # needs to be developed + (NXchem_source): # input for experts from that field needed + (NXbio_source): # input for experts from that field needed + # is NXsource sufficient for x-rays? + (NXopt_source): + doc: Specify the properties of the optical source. + lifespan(NX_NUMBER): + doc: Lifespan of the excitation (typically provided in hours). + unit: NX_TIME + measure_time(NX_NUMBER): + doc: How many hours has the lamp been used? + unit: NX_TIME + excitation_wavelength(NX_FLOAT): + exists: required + doc: | + Wavelengths or energy vector of the excitation source. This can be a + single value or a spectrum, depending on the type of experiment. + unit: NX_ANY + \@units: + doc: Unit of wavelength or energy. + beam_profile: + # ??? What's the best way to enter this ??? + doc: Two- or three-dimensional beam profile. + dimensions: + rank: 2 + dim: + [ + [1, N_beam_profile_dim], + [2, N_beam_profile_points] + ] + peak_power(NX_FLOAT): + doc: Power of one light pulse if the source is a pulsed source. + unit: NX_POWER + cw(NX_BOOLEAN): + exists: required + doc: Is the excitation source continuous wave (CW)? + cw_power(NX_FLOAT): + doc: Power of CW beam. + bandwidth(NX_FLOAT): + doc: FWHM bandwidth of the excitation source. + unit: NX_WAVELENGTH + coherence_length(NX_FLOAT): + doc: Coherence length. + unit: NX_LENGTH + divergence(NX_FLOAT): + doc: Divergence of the excitation beam. + unit: NX_ANGLE + (NXpinhole): + doc: | + Use this field to describe a simple pinhole (round geometry). Define its + dimension using 'diameter'. For more complex geometries, 'NXaperture' + should be used. + (NXslit): + doc: | + Use this field to describe a simple slit (rectangular geometry). Define + its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, + 'NXaperture' should be used. + aperture_NUMBER(NXaperture): + doc: | + Use this field to describe an aperture. To specify a window, use the + field 'window_NUMBER(NXaperture)'. + window_NUMBER(NXaperture): + doc: | + A window, e.g. an entry or exit window of a cryostat. + depends_on: + doc: Use this field to point to the previous optical element. + material(NX_CHAR): + exists: required + doc: The material of the window. + enumeration: + [ + quartz, + diamond, + calcium fluoride, + zinc selenide, + thallium bromoiodide, + alkali halide compound, + Mylar, + other, + ] + other_material(NX_CHAR): + doc: | + If you specified 'other' as material, decsribe here what it is. + thickness(NX_FLOAT): + doc: Thickness of the window + unit: NX_LENGTH + orientation_angle(NX_FLOAT): + doc: | + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + unit: NX_ANGLE + reference_data_link: + doc: | + If reference data were measured add a link to the NeXus file where they + are described. + (NXmirror): + filter_NUMBER(NXfilter): + (NXattenuator): + doc: A device that reduces the intensity of a beam by attenuation. + attenuator_transmission(NX_FLOAT): + doc: The transmitted intensity divided by the incident intensity. + unit: NX_DIMENSIONLESS + attenuation(NX_FLOAT): + doc: Attenuation of the attenuator in dB. + unit: NX_ANY + \@units: + doc: | + Unit of the measured data is not covered by NXDL units state + here which unit was used. + (NXaperture): + doc: Input and output aperture of the attenuator. + (NXgeomtry): + doc: Geometry (shape, size etc.) of the attenuator. + (NXgrating): + doc: | + A diffraction grating. Define relevant parameters in the corresponding + fields, e.g. order of diffration (diffraction_order) or angular + dispersion (angular_dispersion). + type: + exists: required + doc: Define the type of the grating. + angular_dispersion(NX_FLOAT): + doc: Dispersion of the grating in nm/mm (or e.g. nm/mrad). + unit: NX_UNITLESS + grooves(NX_FLOAT): + doc: Number of grooves per mm. + unit: NX_PER_LENGTH + blaze_wavelength(NX_FLOAT): + doc: Blaze wavelength of the grating. + unit: NX_WAVELENGTH + efficiency(NX_FLOAT): + doc: Efficiency curve versus wavelength or energy. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: + [[1, N_spectrum]] + spectrum(NX_FLOAT): + doc: | + Spectral values, e.g. wavelength or energy. Vector of length + N_spectrum. + unit: NX_ANY + \@units: + doc: Unit of wavelength array (e.g. nanometer or Angstrom) + (NXdisk_chopper): + doc: | + A device blocking the beam in a temporal periodic pattern, e.g. a optical + chopper wheel. Specify the frequency range using 'min_frequency' and + 'max_frequency'. + min_frequency(NX_FLOAT): + doc: Minimum frequency in Hertz. + unit: NX_FREQUENCY + max_frequency(NX_FLOAT): + doc: Maximum frequency in Hertz. + unit: NX_FREQUENCY + frequency_resolution(NX_FLOAT): + doc: Frequency resolution in Hertz. + unit: NX_FREQUENCY + (NXmonochromator): + doc: | + A monochromator or spectrometer. + spectrum(NX_FLOAT): + doc: | + Spectral values of the monochromator, e.g. wavelength or energy values + used for the measurement. + unit: NX_ANY + \@units: + doc: Unit of wavelength array (e.g. nanometer or Angstrom) + (NXgrating): + doc: | + Diffraction grating. If two or more gratings were used, define the + angular dispersion and the wavelength range (min/max wavelength) for + each grating and make sure that the wavelength ranges do not overlap. + The dispersion should be defined for the entire wavelength range of the + experiment. + angular_dispersion(NX_FLOAT): + doc: Dispersion of the grating in nm/mm. + unit: NX_DIMENSIONLESS + grating_wavelength_min(NX_FLOAT): + doc: Minimum wavelength of the grating. + unit: NX_WAVELENGTH + grating_wavelength_max(NX_FLOAT): + doc: Maximum wavelength of the grating. + unit: NX_WAVELENGTH + spectral_resolution(NX_FLOAT): + doc: Spectral resolution of the instrument. + unit: NX_WAVENUMBER + (NXslit): + doc: Define the width of the monochromator slit in the subfield x_gap. + fixed_slit(NX_BOOLEAN): + doc: Was the slit width fixed? + max_gap(NX_FLOAT): + doc: If slit width was not fixed, define the maximum slit width. + unit: NX_LENGTH + + # x-ray optics: + (NXxraylens): + # what else? + + # ====== New base classes: ====== + (NXpolarizer_opt): + (NXbeam_splitter): + (NXwaveplate): + (NXlens_opt): + (NXfiber): From e25ce555edadbca60b25095d92d33c2283e856b7 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Tue, 30 May 2023 16:16:10 +0200 Subject: [PATCH 151/203] nxdl files of app defs and base classes --- contributed_definitions/NXbeam_path.nxdl.xml | 104 +++ .../NXbeam_splitter.nxdl.xml | 363 ++++++++ .../NXellipsometry.nxdl.xml | 809 ++++------------ contributed_definitions/NXfiber.nxdl.xml | 214 +++++ contributed_definitions/NXlens_opt.nxdl.xml | 188 ++++ contributed_definitions/NXopt.nxdl.xml | 860 ++++++++++++++++++ .../NXopt_element.nxdl.xml | 415 +++++++++ .../NXpolarizer_opt.nxdl.xml | 247 +++++ contributed_definitions/NXwaveplate.nxdl.xml | 173 ++++ 9 files changed, 2717 insertions(+), 656 deletions(-) create mode 100644 contributed_definitions/NXbeam_path.nxdl.xml create mode 100644 contributed_definitions/NXbeam_splitter.nxdl.xml create mode 100644 contributed_definitions/NXfiber.nxdl.xml create mode 100644 contributed_definitions/NXlens_opt.nxdl.xml create mode 100644 contributed_definitions/NXopt.nxdl.xml create mode 100644 contributed_definitions/NXopt_element.nxdl.xml create mode 100644 contributed_definitions/NXpolarizer_opt.nxdl.xml create mode 100644 contributed_definitions/NXwaveplate.nxdl.xml diff --git a/contributed_definitions/NXbeam_path.nxdl.xml b/contributed_definitions/NXbeam_path.nxdl.xml new file mode 100644 index 0000000000..64179dbcdd --- /dev/null +++ b/contributed_definitions/NXbeam_path.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + + + A beam path consisting of one or more optical elements. + + NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement + of optical elements between the excitation source and the sample, or between + the sample and the detector unit. + + To describe the order of the elements, use 'order(NXtransformations)', where + each element's position points to the preceding element via '@depends_on'. + Special case beam splitter: A beam splitter is a device which separates the + beam into two or more beams. If such a device is part of the beam path use + two or more NXbeam_paths to describe the beam paths after the beam splitter. + In this case, in the dependency chain of the new beam paths, the first + elements each point to the beam splitter, as this is the previous element. + + + Describe the relevant optical elements in the beam path by using the + appropriate base classes. in NXopt_element You may use as many elements as + needed, also several elements of the same type as long as each element has + its own name. + + + + Entry point of the dependency chain defined by the NXtransformations + field, i.e. a link to the first element in the beam path. + Example: /entry/instrument/beam_path/radiation_source. + + + + + + Specify the order of the optical elements by defining a dependency chain. + For each element, a '@depends_on' attribute should be used to state the + position of the element in the beam path by pointing to the previous + element. For the very first element, use the string "." instead. + + + + For each element in the beam path, one such field must exist with a + '@depends_on' attribute defined to specify its position in the beam + path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows + ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and + 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the + dependency chain, i.e. may have an entry in this class even if they are + not described in the beam path. + ELEMENT is a place holder for the name of an optical beam path element. + Note that the name of this field must be exactly the same as the + element's field name. + + + + Add a link to the previous beam path element. + + + + + + + An optical element that is part of an optical setup or beam path. + If a commercial device, the company and model may be defined in the + respective fields. + + + + + diff --git a/contributed_definitions/NXbeam_splitter.nxdl.xml b/contributed_definitions/NXbeam_splitter.nxdl.xml new file mode 100644 index 0000000000..9e137211fb --- /dev/null +++ b/contributed_definitions/NXbeam_splitter.nxdl.xml @@ -0,0 +1,363 @@ + + + + + + + + + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the beam splitter material and/or coating is defined. + + + + + Length of the spectrum vector (e.g. wavelength or energy) for which the + reflectance or transmission of the beam splitter is given. + + + + + Number of parameters needed do descripe the shape of the beam splitter. + + + + + Number of objects the beam splitter is made up of. + + + + + Number of outputs, i.e. number of paths the beam takes after being split by + the beam splitter. + + + + + A beam splitter, i.e. a device splitting the light into two or more beams. + + Information about types and properties of beam splitters is provided e.g. + [here](https://www.rp-photonics.com/beam_splitters.html). + + Use two or more NXbeam_paths to describe the beam paths after the beam + splitter. In the dependency chain of the new beam paths, the first elements + each point to this beam splitter, as this is the previous element. + + + + Specify the beam splitter type (e.g. dielectric mirror, pellicle, + dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension + should be described in 'geometry'. Define if the beam splitter is + polarizing or not in the field 'polarizing(NX_BOOLEAN)'. + + + + + + + + + + + + + + + + + If you selected 'other' in 'type' use this field to specify which type of + beam splitter was used. + + + + + Is the beam splitter polarizing? + + + + + + Does the beam splitter have multiple outputs (diffractive optical + element), i.e. more than two outputs? + + + + + Describe the geometry (shape, dimension etc.) of the beam splitter. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). + + + + + Describe the shape (plate, cube, wedged, prism etc.). + + + + + + + + + + + + + If you chose 'other' in 'shape' describe what it is. + + + + + Sketch of the beam splitter showing its geometry. The paths of the + incoming and split beam should be illustrated and labelled (0 for the + incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split + beam paths)). + + + + + Physical extent of the beam splitter device. The beam splitter might be + made up of one or more objects (NX_objects). The meaning and location + of the axes used will vary according to the value of the 'shape' + variable. 'N_shapepar' defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. + + + + + + + + + Wedge angle if 'shape' is 'wedged'. + + + + + + + Beam splitting ratio(s) for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. + + + + + + + + Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of + length and height for square geometry). + + + + + + Substrate of the beam splitter. Describe the material of the substrate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. + + + + Specify the material of the beam splitter. If the device has a coating + it should be described in coating/coating_material. Is the material + birefringent? + + + + + Thickness of the beam splitter substrate. Define the minimum and + maximum thickness (for a wedged geomtry). For a homogeneous thickness + (e.g. as in plate beam splitters) the minimum and maximum values are + equal. + + + + + + + + Complex index of refraction of the beam splitter substrate. Specify at + given spectral values (e.g. wavelength, energy, wavenumber etc.). + + + + + + + + + + Is the beam splitter coated? If yes, specify the type and material of the + coating and the spectral range for which it is designed. If known, you + may also provide its index of refraction. For a beam splitter cube + consisting of two prisms which are glued together, you may want to + specify the the glue and the coatings of each prism. + + + + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + + + + + Specify the coating material. + + + + + Thickness of the coating. + + + + + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. + + + + + + + + Complex index of refraction of the coating. Specify at given spectral + values (e.g. wavelength, energy, wavenumber etc.). + + + + + + + + + + Wavelength range for which the beam splitter is designed. Enter the + minimum and maximum values of the wavelength range. Alternatively, or + additionally, you may define the wavelength range for the coating in + coating/wavelength_range_coating. + + + + + + + + Optical loss of the beam splitter for the various outputs (i.e. the paths + of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. + + + + + + + + Optimized angle of incidence for the desired splitting ratio. + + + + + + Angle of deflection corresponding to the optimized angle of incidence + defined in incident_angle. + + + + + Range of the angles of incidence (AOI) for which the beam splitter can be + operated. Specify the minimum and maximum angles of the range. + + + + + + + + + Reflectance of the beam splitter at given spectral values. + + + + + + + + Transmission at given spectral values for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. + + + + + + + diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 197b3f7d2e..2bd9ddd3ee 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,36 +21,69 @@ # # For further information, see http://www.nexusformat.org --> - + + + + + - Variables used throughout the document, e.g. dimensions and important - parameters + Variables used throughout the document, e.g. dimensions or parameters. - + - Size of the energy or wavelength vector used, the length of - NXinstrument/spectrometer/wavelength array + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. - + - How many variables are saved in a measurement. e.g. 2 for Psi and Delta, 16 for - Mueller matrix elements, 15 for normalized Mueller matrix, 3 for NCS, the length - of NXsample/column_names + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. - + - Number of incident angles used, the length of NXinstrument/angle_of_incidence - array + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. - + - Number of sample parameters scanned, if you varied any of the parameters such as - temperature, pressure, or pH, the maximal length of the arrays specified by - NXsample/environment_conditions/SENSOR/value if it exists. + Number of detection angles of the beam reflected or scattered off the + sample. + + + + + Number of angles of incidence of the incident beam. + + + + + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. @@ -116,165 +149,72 @@ - Version number to identify which definition of this application definition was - used for this entry/data. + Version number to identify which definition of this application + definition was used for this entry/data. - URL where to find further material (documentation, examples) relevant to the - application definition + URL where to find further material (documentation, examples) relevant + to the application definition. - - - Unique identifier of the experiment, such as a (globally persistent) unique - identifier. - i) The identifier is usually defined by the facility or principle investigator. - ii) The identifier enables to link experiments to e.g. proposals. - - - + - A free-text description of the experiment. What is the aim of the experiment? - The general procedure. + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. - + - Start time of the experiment. UTC offset should be specified. + Specify the type of ellipsometry. + + + + + + + + + - - - - Commercial or otherwise defined given name to the program that was used to - generate the result file(s) with measured data and metadata. This program - converts the measured signals to ellipsometry data. If home written, one can - provide the actual steps in the NOTE subfield here. - - - - - Either version with build number, commit hash, or description of a (online) - repository where the source code of the program and build instructions can be - found so that the program can be configured in such a way that result files can - be created ideally in a deterministic manner. - - - - - Website of the software. - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - Official telephone number of the user. - - - - General properties of the ellipsometry equipment + Properties of the ellipsometry equipment. - - - The name of the instrument - - - - The used version of the hardware if available. If not a commercial instrument - use date of completion of the hardware. - - - - Name of the company which build the instrument + Name of the company which build the instrument. - ISO8601 date when the instrument was constructed. UTC offset should be - specified. + ISO8601 date when the instrument was constructed. + UTC offset should be specified. - - - Commercial or otherwise defined name of the software that was used for the - measurement - - - - Version and build number or commit hash of the software source code - - - + + - Website of the software. + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and metadata. + This program converts the measured signals to ellipsometry data. If + home written, one can provide the actual steps in the NOTE subfield + here. - - - - - Specify the used light source. Multiple selection possible. - + - - - Were focussing probes (lenses) used? - - - - - Were the recorded data corrected by the window effects of the lenses? - - - + - Specify the angular spread caused by the focussing probes - - - - - What type of ellipsometry was used? See Fujiwara Table 4.2 + What type of ellipsometry was used? See Fujiwara Table 4.2. @@ -291,568 +231,125 @@ - + - Was a calibration performed? If yes, when was it done? If the calibration time - is provided, it should be specified in calibration/calibration_time. + Define which element rotates, e.g. polarizer or analyzer. - - - - - + + + + - - - Ellipsometers require regular calibration to adjust the hardware parameters for - proper zero values and background light compensation. - - - - If calibtration status is 'calibration time provided', specify the ISO8601 date - when calibration was last performed before this measurement. UTC offset should - be specified. - - - - - Arrays which provide the measured calibration data. Multiple sets are possible, - e.g. Psi and delta measured on a e.g. silicon calibration wafer, and the - straight-through data. We recommend to provide data that is measured under the - same settings as the measurement was performed, that is if Psi and Delta are - measured for your data, also provide Psi and Delta here and use the same - wavelenghts as for the measured data. - - - - What data were recorded for the calibration? The number of variables - (N_variables) have to be set to the number of provided data columns accordingly, - e.g. psi/delta -> N_variables = 2, Jones vector -> N_variables = 4, Mueller - martix -> N_variables = 16, etc. - - - - - - - - - - - - Angle(s) of incidence used during the calibration measurement (excluding - straight through mode) - - - - - - - - The wavelength or equivalent values (which are inter-convertible). - The importer should convert all to one unit, and make the others - accessible. Historically, energy is used in eV, but for visible - spectroscopy wavelength is more common, for IR wave numbers in - 1/cm units. - - Possibly use the same type of data as for the measurement. - - - - - - - - Calibration is performed on a reference surface (usually a silicon wafer with a - well defined oxide layer) at a number of angles of incidence and in a straight - through mode (transmission in air). - - - - - - - - - - - Free-text to describe which sample was used for calibration, e.g. silicon wafer - with 25 nm thermal oxide layer. - - - - - - Incident angle of the beam vs. the normal of the bottom reflective (substrate) - surface in the sample - - - - - - - - Sample stage, holding the sample at a specific position in X,Y,Z (Cartesian) - coordinate system and at an orientation defined by three Euler angles (alpha, - beta, gamma). The stage may be motorized or manual, special for liquids or gas - environment. - - + + - Specify what type of stage was used. + Specify the used light source. Multiple selection possible. - - - - - - - - - - A free-text field to provide information about the stage. - - - - - The stage coordinate system vs. the incident beam. The Z-axis of the stage is considered to point along the normal of the substrate (bottom reflecting surface) from the stage towards the general direction of the light source. The beam comes with the angle of incidence towards this Z-axis, but in opposite direction, thus they are connected with a rotation of 180 - angle of incidence (in degrees). - This transformation brings us from the NEXUS coordinates to the stage coordinates. - Then provide the set of translations (if there are any). These all have a vector defining their relative direction in the current coordinate system. (This current coordinate system changes with every transformation if you set the parameter 'depends' to the name of the previous step.) - Last, provide the rotations of the sample - - - - If there is no motorized stage, we should at least qualify where the beam hits - the sample and in what direction the sample stands in a free-text description, - e.g. 'center of sample, long edge parallel to plane of incidence'. - - - - - - - For environmental measurements, the environment (liquid, vapor, vacuum etc.) is - enclosed in a cell or cryostat, which has windows both in the direction of the - source and the detector (looking from the sample). These windows also add a - phase shift to the light altering the measured signal. This shift has to be - corrected based on measuring a known sample in the environmental cell. - - - - The material of the window - - - - - - - - - + + + - - - - If you specified 'other' as window material, decsribe here what it is. - - - - - Thickness of the window - - - - - Angle of the window normal (outer) vs. the substrate normal (similar to the - angle of incidence). - - - + + - Recorded data that can be used to calculate the window effect. Typically this is - the substrate (e.g. silicon with thermal oxide layer) in air without window and - in a known medium with the window. + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. - - - What sample was used to estimate the window effect? - - - + - Wavelength of the reference data. Use the same wavelengths at which all other - measurements are recorded + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? - - - - + - Recorded data of a reference surface with and without window/medium. + Specify the angular spread caused by the focussing probes. - - - - - - - - - - Which type of detector was used, and what is known about it? A detector can be a - photomultiplier (PMT), a CCD in a camera, or an array in a spectrometer. If so, - the whole detector unit goes in here. Integration time is the count time field, - or the real time field. See their definition. - - - - What kind of detector module is used, e.g. CCD-spectrometer, CCD camera, PMT, - photodiode, etc. - - - - - - - - - - - - - If you specified 'other' as detector type, please write down what it is. - - - - - Define how many rotations of the rotating element were taken into account per - spectrum. - - - - - Define which element rotates, e.g. polarizer or analyzer. - - - - - - - - - - - Rotation rate, if the revolution does not change during the measurement. - - - - - Specify maximum and minimum values for the revolution. - - - - - - - - Minimum signal for which dynamic averaging is performed. - - - - - Value for the minimum intensity chosen. Data points below this value might be - skipped by the instrument - - - - - - The spectroscope element of the ellipsometer before the detector, but often - integrated to form one closed unit. Information on the dispersive element can be - specified in the subfield GRATING. Note that different gratings might be used - for different wavelength ranges. The dispersion of the grating for each - wavelength range can be stored in grating_dispersion. - - + - Wavelength value(s) used for the measurement. An array of 1 or more elements. - Length defines N_wavelength + Properties of the detector used. Integration time is the count time + field, or the real time field. See their definition. - - - - - + + - Diffraction grating, as could be used in a monochromator. If two or more - gratings were used, define the angular dispersion and the wavelength range - (min/max wavelength) for each grating and make sure that the wavelength ranges - do not overlap. The dispersion should be defined for the entire wavelength range - of the experiment. + Properties of the rotating element defined in + 'instrument/rotating_element_type'. - + - Dispersion of the grating in nm/mm used. + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. - + - Minimum wavelength of the grating. + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). - + - Maximum wavelength of the grating. + Specify the maximum value of revolutions of the rotating element + for each measurement. - - - Spectral resolution of the instrument. - - - + - Define the width of the monochromator slit in the subfield x_gap. + The spectroscope element of the ellipsometer before the detector, + but often integrated to form one closed unit. Information on the + dispersive element can be specified in the subfield GRATING. Note + that different gratings might be used for different wavelength + ranges. The dispersion of the grating for each wavelength range can + be stored in grating_dispersion. - - - Was the slit width fixed? - - - - - If slit width was not fixed, define the maximum slit width. - - - - Properties of the sample, its history, the sample environment and experimental - conditions (e.g. surrounding medium, temperature, pressure etc.), along with the - data (data type, wavelength array, measured data). - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Descriptive name of the sample - - - - - Ideally, a reference to the location or a unique (globally persistent) - identifier (e.g.) of e.g. another file which gives as many as possible details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history. In the case that such a detailed history of the - sample is not available, use this field as a free-text description to specify - details of the sample and its preparation. - - - - - ISO8601 date with time zone (UTC offset) specified. - - - - - Qualitative description of the layer structure for the sample. For example: - Si/native oxide/thermal oxide/polymer/peptide - - - + - An identifier to correlate data to the experimental conditions, if several were - used in this measurement; typically an index of 0 - N + Was the backside of the sample roughened? Relevant for infrared + ellipsometry. + + - Select which type of data was recorded, for example Psi and Delta (see: - https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It is possible to - have multiple selections. Data types may also be converted to each other, e.g. a - Mueller matrix contains N,C,S data as well. This selection defines how many - columns (N_variables) are stored in the data array. + Select which type of data was recorded, for example Psi and Delta + (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). + It is possible to have multiple selections. Data types may also be + converted to each other, e.g. a Mueller matrix contains N,C,S data + as well. This selection defines how many columns (N_observables) are + stored in the data array. - - + + - - - Please list in this array the column names used in your actual data. That is - ['psi', 'delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for a full Mueller matrix, - etc. - - - - - - - - Resulting data from the measurement, described by data type. Minimum two columns - containing Psi and Delta, or for the normalized Mueller matrix it may be 16 (or - 15 if the element (1,1) is all 1). - - - - - - - - - - - - Specified uncertainties (errors) of the data described by data type. The - structure is the same as for the measured data. - - - - - - - - - - - - An array of relative time points if a time series was recorded. - - - - - - - - Specify external parameters that have influenced the sample. - - - - Describe what was the medium above or around the sample. The common model is - built up from the substrate to the medium on the other side. Both boundaries are - assumed infinite in the model. Here, define the name of the medium (e.g. water, - air, UHV, etc.). - - - - - Array of pairs of complex refractive indices of the medium for every measured - wavelength. Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. Specify the complex - refractive index: n + ik - - - - - - - - How many measurements were done varying the parameters? This forms an extra - dimension beyond incident angle, time points and energy/wavelength (this is the - length of the 4th dimension of the data). Defaults to 1. - - - - - Indicates which parameter was changed. Its definition must exist below. The - specified variable has to be number_of_runs long, providing the parameters for - each data set. If you vary more than one parameter simultaneously use one signal - instance for each. Record every parameter value in a linear manner, so N_p1 is - the number of measurements taken. For example, if you measure at two - temperatures and three pressures the temperature signal value looks like [T1, - T1, T1, T2, T2, T2] and the pressure signal value looks like [p1, p2, p3, p1, - p2, p3], and N_p1 = 6. - - - - - - - - - - - - - Was the sample modified using an optical source? Describe in this group the - parameters of the optical excitation used. - - - - Wavelength value(s) or the range used for excitation. In cases of continuous - laser radiation, a value or a set of values may do but for other illumination - types, such as pulsed lasers, or lamps, a range may describe the source better. - - - - - Specify the FWHM of the excitation - - - - - How long was the sample excited. - - - - - The integrated energy of light pulse. - - - - - - A sensor used to monitor an external condition. The value field contains the - measured values. If it is constant within an error for every run then use only - an array of length one. - - - - - - - What parameters are derived from the above data. - - - - Light loss due to depolarization as a value in [0-1]. - - - - - - A default view of the data, in this case Psi vs. wavelength and the angles of - incidence. If Psi does not exist, use other Mueller matrix elements, such as N, - C and S. - - - - We recommend to use wavelength as a default attribute, but it can be replaced in - the case of not full spectral ellipsometry to any suitable parameter along the - X-axis. - - + diff --git a/contributed_definitions/NXfiber.nxdl.xml b/contributed_definitions/NXfiber.nxdl.xml new file mode 100644 index 0000000000..da8aece675 --- /dev/null +++ b/contributed_definitions/NXfiber.nxdl.xml @@ -0,0 +1,214 @@ + + + + + + + + + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the core material is given. + + + + + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the cladding material is given. + + + + + Length of the spectrum vector (e.g. wavelength or energy) for which the + attenuation curve is given. + + + + + An optical fiber, e.g. glass fiber. + + Specify the quantities that define the fiber. Fiber optics are described in + detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for + example. + + + + Descriptive name or brief description of the fiber, e.g. by stating its + dimension. The dimension of a fiber can be given as 60/100/200 which + refers to a core diameter of 60 micron, a clad diameter of 100 micron, + and a coating diameter of 200 micron. + + + + + Type/mode of the fiber. Modes of fiber transmission are shown in + Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). + + + + + + + + + + Type of dispersion. + + + + + + + + + + Spectrum-dependent (or refractive index-dependent) dispersion of the + fiber. Specify in ps/nm*km. + + + + + + + + Core of the fiber, i.e. the part of the fiber which transmits the light. + + + + Specify the material of the core of the fiber. + + + + + Core diameter of the fiber (e.g. given in micrometer). + + + + + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. + + + + + + + + + + Core of the fiber, i.e. the part of the fiber which transmits the light. + + + + Specify the material of the core of the fiber. + + + + + Clad diameter of the fiber (e.g. given in micrometer). + + + + + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. + + + + + + + + + + Coating of the fiber. + + + + Specify the material of the coating of the fiber. + + + + + Outer diameter of the fiber (e.g. given in micrometer). + + + + + + Length of the fiber. + + + + + Spectral range for which the fiber is designed. Enter the minimum and + maximum values (lower and upper limit) of the wavelength range. + + + + + + + Unit of spectral array (e.g. nanometer or angstrom for wavelength, or + electronvolt for energy etc.). + + + + + + Transfer rate of the fiber (in GB per second). + + + + GB/s + + + + + + Numerical aperture (NA) of the fiber. + + + + + Wavelength-dependent attenuation of the fiber (specify in dB/km). + + + + dB/km + + + + + + + + + Power loss of the fiber in percentage. + + + + + Acceptance angle of the fiber. + + + diff --git a/contributed_definitions/NXlens_opt.nxdl.xml b/contributed_definitions/NXlens_opt.nxdl.xml new file mode 100644 index 0000000000..3328b87007 --- /dev/null +++ b/contributed_definitions/NXlens_opt.nxdl.xml @@ -0,0 +1,188 @@ + + + + + + + + + Size of the wavelength array for which the refractive index of the material + is given. + + + + + Size of the wavelength array for which the refractive index of the coating + is given. + + + + + Size of the wavelength array for which the reflectance or transmission of + the lens is given. + + + + + Description of an optical lens. + + + Specify the properties of the lens. + + + + Type of the lens (e.g. concave, convex etc.). + + + + + + + + + + + + + + + If you chose 'other' as type specify what it is. + + + + + Is it a chromatic lens? + + + + + Diameter of the lens. + + + + + Properties of the substrate material of the lens. If the lens has a + coating specify the coating material and its properties in 'coating'. + + + + Specify the substrate material of the lens. + + + + + Thickness of the lens substrate at the optical axis. + + + + + Complex index of refraction of the lens material. Specify at given + wavelength (or energy, wavenumber etc.) values. + + + + + + + + + + + If the lens has a coating describe the material and its properties. + Some basic information can be found e.g. [here] + (https://www.opto-e.com/basics/reflection-transmission-and-coatings). + If the back and front side of the lens are coated with different + materials, use separate COATING(NXsample) fields to describe the coatings + on the front and back side, respectively. For example: + coating_front(NXsample) and coating_back(NXsample). + + + + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + + + + + Describe the coating material (e.g. MgF2). + + + + + Thickness of the coating. + + + + + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + + + + + + + + + + Reflectance of the lens at given spectral values. + + + + + + + + Transmission of the lens at given spectral values. + + + + + + + + Focal length of the lens on the front side (first value), i.e. where the + beam is incident, and on the back side (second value). + + + + + + + + Curvature radius of the lens. + Instead of 'FACE' in the name of this field, the user is advised to + specify for which surface (e.g. front or back) the curvature is provided: + e.g. curvature_front or curvature_back. The front face is the surface on + which the light beam is incident, while the back face is the one from + which the light beam exits the lens. + + + + + Abbe number (or V-number) of the lens. + + + diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml new file mode 100644 index 0000000000..8f3b7ed651 --- /dev/null +++ b/contributed_definitions/NXopt.nxdl.xml @@ -0,0 +1,860 @@ + + + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + + + + + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + + + + + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + + + + + Number of detection angles of the beam reflected or scattered off the + sample. + + + + + Number of angles of incidence of the incident beam. + + + + + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. + + + + + An application definition for optical spectroscopy experiments. + + + + An application definition template for optical spectroscopy experiments. + + A general optical experiment consists of a light or excitation source, a + beam path, a sample + its stage + its environment, and a detection unit. + Examples are reflection or transmission measurements, photoluminescence, + Raman spectroscopy, ellipsometry etc. + + + + An application definition describing a general optical experiment. + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition. + + + + + + + + + A (globally persistent) unique identifier of the experiment. + (i) The identifier is usually defined by the facility or principle + investigator. + (ii) The identifier enables to link experiments to e.g. proposals. + + + + + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. + + + + + Specify the type of the optical experiment. + + + + + Start time of the experiment. UTC offset should be specified. + + + + + Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users, if relevant, is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the + experiment was performed. + + + + + Street address of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + Telephone number of the user. + + + + + + Properties of the experimental setup. This includes general information + about the instrument (such as model, company etc.), information about + the calibration of the instrument, elements of the beam path including + the excitation or light source and the detector unit, the sample stage + (plus the sample environment, which also includes sensors used to + monitor external conditions) and elements of the beam path. + + Meta data describing the sample should be specified in ENTRY/SAMPLE + outside of ENTRY/INSTRUMENT. + + + + The name of the instrument. + + + + The used version of the hardware if available. If not a commercial + instrument use date of completion of the hardware. + + + + + + Name of the company which build the instrument. + + + + + ISO8601 date when the instrument was constructed. + UTC offset should be specified. + + + + + + Commercial or otherwise defined given name of the program that was + used to measure the data, i.e. the software used to start and + record the measured data and/or metadata. + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + Commercial or otherwise defined name of the firmware that was used + for the measurement - if available. + + + + Version and build number or commit hash of the software source code. + + + + + Website of the software. + + + + + + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. + + + + + + + + + + + + The calibration data and metadata should be described in a separate NeXus file + with the link provided in 'calibration_link'. + + + + If calibtration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + + + + + Link to the NeXus file containing the calibration data and metadata. + + + + + + Describes an arrangement of optical or other elements, e.g. the beam + path between the light source and the sample, or between the sample + and the detector unit (including the sources and detectors + themselves). + + If a beam splitter (i.e. a device that splits the incoming beam into + two or more beams) is part of the beam path, two or more NXbeam_path + fields may be needed to fully describe the beam paths and the correct + sequence of the beam path elements. + Use as many beam paths as needed to describe the setup. + + + + + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. + + + + + + + + + Detection angle(s) of the beam reflected or scattered off the sample + vs. the normal of the bottom reflective (substrate) surface in the + sample if not equal to the angle(s) of incidence. + + + + + + + + Sample stage, holding the sample at a specific position in X,Y,Z + (Cartesian) coordinate system and at an orientation defined + by three Euler angles (alpha, beta, gamma). + + + + Specify the type of the sample stage. + + + + + + + + + + + If there is no motorized stage, we should at least qualify where + the beam hits the sample and in what direction the sample stands + in a free-text description, e.g. 'center of sample, long edge + parallel to the plane of incidence'. + + + + + + Specify external parameters that have influenced the sample, such + as the surrounding medium, and varied parameters e.g. temperature, + pressure, pH value, optical excitation etc. + + + + Describe what was the medium above or around the sample. The + common model is built up from the substrate to the medium on the + other side. Both boundaries are assumed infinite in the model. + Here, define the name of the medium (e.g. water, air, UHV, etc.). + + + + + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + + + + + + + + + A sensor used to monitor an external condition influencing the + sample, such as temperature or pressure. It is suggested to + replace 'PARAMETER' by the type of the varied parameter defined + in 'parameter_type'. + The measured parameter values should be provided in 'values'. + For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. + In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. + + + + Indicates which parameter was changed. Its definition must exist + below. The specified variable has to be N_measurements long, + providing the parameters for each data set. If you vary more than + one parameter simultaneously. + + + + + + + + + + + + + + + + + + + + + + + + Number of different parameter values at which the measurement + was performed. For example, if the measurement was performed at + temperatures of 4, 77 and 300 K, then number_of_parameters = 3. + + + + + Vector containing the values of the varied parameter. Its + length is equal to N_measurements. The order of the values + should be as follows: + + * Order the sensors according to number_of_parameters starting + with the lowest number. If number_of_parameters is equal for + two sensors order them alphabetically (sensor/parameter name). + * The first sensor's j parameters should be ordered in the + following way. The first N_measurements/number_of_parameters + entries of the vector contain the first parameter (a1), the + second N_measurements/number_of_parameters contain the second + parameter (a2) etc., so the vector looks like: + [ + a1,a1,...,a1, + a2,a2,...,a2, + ... + aj,aj,...aj + ] + * The kth sensor's m parameters should be ordered in the + following way: + [ + p1,...p1,p2,...,p2,...pm,...,pm, + p1,...p1,p2,...,p2,...pm,...,pm, + ... + p1,...p1,p2,...,p2,...pm,...,pm + ] + * The last sensor's n parameters should be ordered in the + following way: + [ + z1,z2,...,zn, + z1,z2,...,zn, + ... + z1,z2,...,zn] + + For example, if the experiment was performed at three different + temperatures (T1, T2, T3), two different pressures (p1, p2) and + two different angles of incidence (a1, a2), then + N_measurements = 12 and the order of the values for the various + parameter vectors is: + + * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] + * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] + * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] + + + + + + + + + + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(MXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. + + + + Specify the position of the window in the beam path by pointing + to the preceding element in the sequence of beam path elements. + + + + + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + + + + + Was a window correction performed? If 'True' describe the + window correction procedure in '' + + + + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. + + + + + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + + + + + + The material of the window. + + + + + + + + + + + + + + + If you specified 'other' as material, decsribe here what it is. + + + + + Thickness of the window. + + + + + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + + + + + + + + Properties of the sample, such as sample type, layer structure, + chemical formula, atom types, its history etc. + Information about the sample stage and sample environment should be + described in ENTRY/INSTRUMENT/sample_stage. + + + + Descriptive name of the sample + + + + + Specify the type of sample, e.g. thin film, single crystal etc. + + + + + + + + + + + + Qualitative description of the layer structure for the sample, + starting with the top layer (i.e. the one on the front surface, on + which the light incident), e.g. native oxide/bulk substrate, or + Si/native oxide/thermal oxide/polymer/peptide. + + + + + Chemical formula of the sample. Use the Hill system (explained here: + https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write + the chemical formula. In case the sample consists of several layers, + this should be a list of the chemical formulas of the individual + layers, where the first entry is the chemical formula of the top + layer (the one on the front surface, on which the light incident). + The order must be consistent with layer_structure + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + 'atom_types'. + + + + + Ideally, a reference to the location or a unique (globally + persistent) identifier (e.g.) of e.g. another file which gives + as many as possible details of the material, its microstructure, + and its thermo-chemo-mechanical processing/preparation history. + In the case that such a detailed history of the sample is not + available, use this field as a free-text description to specify + details of the sample and its preparation. + + + + + ISO8601 date with time zone (UTC offset) specified. + + + + + Description of the substrate. + + + + + Specify the sample orientation. + + + + + + Measured data, data errors, and varied parameters. If reference data + were measured they should be considered a separate experiment and a + link to its NeXus file should be added in reference_data_link. + + + + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. + + + + + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + + + + + + + + + + + + + + + + + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + + + + + + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + + + + + + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + + + + + + + + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + + + + + + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + A plot of the multi-dimensional data array provided in + ENTRY/data/measured_data. + + + + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + + + + + + + Parameters that are derived from the measured data. + + + + Light loss due to depolarization as a value in [0-1]. + + + + + + + + + + Jones quality factor. + + + + + + + + + + Reflectivity. + + + + + + + + + + Transmittance. + + + + + + + + + + + Commercial or otherwise defined given name of the program that was + used to generate or calculate the derived parameters. + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + + + A default view of the data provided in ENTRY/data/measured_data. This + should be the part of the data set which provides the most suitable + representation of the data. + + + + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + + + + + diff --git a/contributed_definitions/NXopt_element.nxdl.xml b/contributed_definitions/NXopt_element.nxdl.xml new file mode 100644 index 0000000000..7cf26c73c4 --- /dev/null +++ b/contributed_definitions/NXopt_element.nxdl.xml @@ -0,0 +1,415 @@ + + + + + + + + + Size of the wavelength or energy vector for which quantities of the optical + element, such as reflectivity or efficiency, are provided. + + + + + Number of dimensions for which the beam profile is given. + + + + + Number of points of the beam profile. + + + + + Optical elements that may be part of an optical setup or beam path. + + + Describe the optical element by using the appropriate sub class. + + + + Excitation source. One or more may be needed (e.g. two for a pump-probe + setup with one pump and one probe beam). + Depending on the source type, different properties are relevant, which + are provided through the respective base class (e.g. use NXopt_source for + lamps or lasers, NXchem_source for chemical reaction etc.). + Some base classes are incomplete (NXchem_source, NXbio_source); the + expertise of the respective communities is needed. + + + + Use this field to point to the previous optical element. + + + + + Type of excitation source. + + + + + + + + + + + + + + + + + + + + + + + Acoustic source, e.g. an ultrasonic transducero or a imploding gas + bubble (sonoluminescence). + + + + + + + + + Specify the properties of the optical source. + + + + Lifespan of the excitation (typically provided in hours). + + + + + How many hours has the lamp been used? + + + + + Wavelengths or energy vector of the excitation source. This can be a + single value or a spectrum, depending on the type of experiment. + + + + Unit of wavelength or energy. + + + + + + + Two- or three-dimensional beam profile. + + + + + + + + + Power of one light pulse if the source is a pulsed source. + + + + + Is the excitation source continuous wave (CW)? + + + + + Power of CW beam. + + + + + FWHM bandwidth of the excitation source. + + + + + Coherence length. + + + + + Divergence of the excitation beam. + + + + + + + Use this field to describe a simple pinhole (round geometry). Define its + dimension using 'diameter'. For more complex geometries, 'NXaperture' + should be used. + + + + + Use this field to describe a simple slit (rectangular geometry). Define + its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, + 'NXaperture' should be used. + + + + + Use this field to describe an aperture. To specify a window, use the + field 'window_NUMBER(NXaperture)'. + + + + + A window, e.g. an entry or exit window of a cryostat. + + + + Use this field to point to the previous optical element. + + + + + The material of the window. + + + + + + + + + + + + + + + If you specified 'other' as material, decsribe here what it is. + + + + + Thickness of the window + + + + + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + + + + + If reference data were measured add a link to the NeXus file where they + are described. + + + + + + + + A device that reduces the intensity of a beam by attenuation. + + + + The transmitted intensity divided by the incident intensity. + + + + + Attenuation of the attenuator in dB. + + + + Unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Input and output aperture of the attenuator. + + + + + Geometry (shape, size etc.) of the attenuator. + + + + + + A diffraction grating. Define relevant parameters in the corresponding + fields, e.g. order of diffration (diffraction_order) or angular + dispersion (angular_dispersion). + + + + Define the type of the grating. + + + + + Dispersion of the grating in nm/mm (or e.g. nm/mrad). + + + + + Number of grooves per mm. + + + + + Blaze wavelength of the grating. + + + + + Efficiency curve versus wavelength or energy. + + + + + + + + Spectral values, e.g. wavelength or energy. Vector of length + N_spectrum. + + + + Unit of wavelength array (e.g. nanometer or Angstrom) + + + + + + + A device blocking the beam in a temporal periodic pattern, e.g. a optical + chopper wheel. Specify the frequency range using 'min_frequency' and + 'max_frequency'. + + + + Minimum frequency in Hertz. + + + + + Maximum frequency in Hertz. + + + + + Frequency resolution in Hertz. + + + + + + A monochromator or spectrometer. + + + + Spectral values of the monochromator, e.g. wavelength or energy values + used for the measurement. + + + + Unit of wavelength array (e.g. nanometer or Angstrom) + + + + + + Diffraction grating. If two or more gratings were used, define the + angular dispersion and the wavelength range (min/max wavelength) for + each grating and make sure that the wavelength ranges do not overlap. + The dispersion should be defined for the entire wavelength range of the + experiment. + + + + Dispersion of the grating in nm/mm. + + + + + Minimum wavelength of the grating. + + + + + Maximum wavelength of the grating. + + + + + + Spectral resolution of the instrument. + + + + + Define the width of the monochromator slit in the subfield x_gap. + + + + Was the slit width fixed? + + + + + If slit width was not fixed, define the maximum slit width. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXpolarizer_opt.nxdl.xml b/contributed_definitions/NXpolarizer_opt.nxdl.xml new file mode 100644 index 0000000000..98ee05b46b --- /dev/null +++ b/contributed_definitions/NXpolarizer_opt.nxdl.xml @@ -0,0 +1,247 @@ + + + + + + + + + Size of the wavelength array for which the refractive index of the material + and/or coating is given. + + + + + Size of the wavelength array for which the reflectance or transmission of + the polarizer is given. + + + + + An optical polarizer. + + Information on the properties of polarizer is provided e.g. + [here](https://www.rp-photonics.com/polarizers.html). + + + Specify the properties of a polarizer. + + + + Type of the polarizer (e.g. dichroic, linear, circular etc.) + + + + + + + + + + + + + + + + + + + + + If you selected 'other' in type specify what it is. + + + + + Angle of the polarizer. + + + + + Acceptance angle of the polarizer (range). + + + + + + + + Describe the geometry (shape, dimension etc.) of the device. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). + + + + + Describe the shape (plate, cube, wedged, prism etc.). + + + + + + + + + + + + + If you chose 'other' in 'shape' describe what it is. + + + + + Sketch of thedevice showing its geometry. The paths of the + incoming and outgoing beam should be illustrated and labelled (0 for + the incoming beam, and 1, 2,..., N_outputs for the outputs). + + + + + Physical extent of the device. The device might be made up of one or + more objects (NX_objects). The meaning and location of the axes used + will vary according to the value of the 'shape' variable. 'N_shapepar' + defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. + + + + + + + + + Wedge angle if 'shape' is 'wedged'. + + + + + + Wavelength range for which the polarizer is designed. Enter the minimum + and maximum wavelength (lower and upper limit) of the range. + + + + + + + + Properties of the substrate material of the polarizer. If the device has + a coating specify the coating material and its properties in 'coating'. + + + + Specify the substrate material of the polarizer. + + + + + Thickness of the polarizer substrate. + + + + + Complex index of refraction of the polarizer material. Specify at given + spectral values (wavelength, energy, wavenumber etc.). + + + + + + + + + + + If the device has a coating describe the material and its properties. + Some basic information can be found e.g. [here] + (https://www.opto-e.com/basics/reflection-transmission-and-coatings). + If the back and front side of the polarizer are coated with different + materials, you may define two coatings (e.g. COATING1 and COATING2). + + + + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + + + + + Describe the coating material (e.g. MgF2). + + + + + Thickness of the coating. + + + + + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + + + + + + + + + + Extinction ratio (maximum to minimum transmission). + + + + + + + + Reflection of the polarizer at given wavelength values. + + + + + + + + Transmission of the polarizer at given wavelength values. + + + + + + + diff --git a/contributed_definitions/NXwaveplate.nxdl.xml b/contributed_definitions/NXwaveplate.nxdl.xml new file mode 100644 index 0000000000..74e4d4da5d --- /dev/null +++ b/contributed_definitions/NXwaveplate.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + + + + Size of the wavelength array for which the refractive index of the material + and/or coating is given. + + + + + Number of discrete wavelengths for which the waveplate is designed. If it + operates for a range of wavelengths then N_wavelengths = 2 and the minimum + and maximum values of the range should be provided. + + + + + A waveplate or retarder. + + + + Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). + + + + + + + + + + + + + + If you selected 'other' in type describe what it is. + + + + + Specify the retardance of the waveplate (e.g. full-wave, half-wave + (lambda/2), quarter-wave (lambda/4) plate). + + + + + + + + + + Discrete wavelengths for which the waveplate is designed. If the + waveplate operates over an entire range of wavelengths, enter the minimum + and maximum values of the wavelength range (in this case + N_wavelengths = 2). + + + + + + + + Diameter of the waveplate. + + + + + Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of + length/height for square geometry). + + + + + + Describe the material of the substrate of the wave plate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. + + + + Specify the material of the wave plate. If the device has a + coating it should be described in coating/coating_material. + + + + + Thickness of the wave plate substrate. + + + + + Complex index of refraction of the wave plate substrate. Specify at + given wavelength (or energy, wavenumber etc.) values. + + + + + + + + + + Is the wave plate coated? If yes, specify the type and material of the + coating and the wavelength range for which it is designed. If known, you + may also provide its index of refraction. + + + + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + + + + + Specify the coating material. + + + + + Thickness of the coating. + + + + + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. + + + + + + + + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + + + + + + + + + + Average reflectance of the waveplate in percentage. + + + From f492595a91601848b7bd7d8e2a4c9b9e191aa45a Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Tue, 30 May 2023 16:31:23 +0200 Subject: [PATCH 152/203] removed 'required' from base classes --- contributed_definitions/NXbeam_splitter.nxdl.xml | 14 +++++++------- contributed_definitions/NXfiber.nxdl.xml | 2 +- contributed_definitions/NXlens_opt.nxdl.xml | 6 +++--- contributed_definitions/NXopt_element.nxdl.xml | 10 +++++----- contributed_definitions/NXpolarizer_opt.nxdl.xml | 2 +- contributed_definitions/NXwaveplate.nxdl.xml | 2 +- 6 files changed, 18 insertions(+), 18 deletions(-) diff --git a/contributed_definitions/NXbeam_splitter.nxdl.xml b/contributed_definitions/NXbeam_splitter.nxdl.xml index 9e137211fb..bbb399929a 100644 --- a/contributed_definitions/NXbeam_splitter.nxdl.xml +++ b/contributed_definitions/NXbeam_splitter.nxdl.xml @@ -63,7 +63,7 @@ splitter. In the dependency chain of the new beam paths, the first elements each point to this beam splitter, as this is the previous element. - + Specify the beam splitter type (e.g. dielectric mirror, pellicle, dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension @@ -89,13 +89,13 @@ beam splitter was used. - + Is the beam splitter polarizing? - - + + Does the beam splitter have multiple outputs (diffractive optical element), i.e. more than two outputs? @@ -197,7 +197,7 @@ length(NX_FLOAT): Beam splitting ratio(s) for the various outputs (i.e. the paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels + The order of the ratios must be consistent with the labels 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. @@ -305,7 +305,7 @@ length(NX_FLOAT): Optical loss of the beam splitter for the various outputs (i.e. the paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels + The order of the ratios must be consistent with the labels 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. @@ -351,7 +351,7 @@ for the corresponding defelction angles...--> Transmission at given spectral values for the various outputs (i.e. the paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels + The order of the ratios must be consistent with the labels 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. diff --git a/contributed_definitions/NXfiber.nxdl.xml b/contributed_definitions/NXfiber.nxdl.xml index da8aece675..364a06e2ea 100644 --- a/contributed_definitions/NXfiber.nxdl.xml +++ b/contributed_definitions/NXfiber.nxdl.xml @@ -58,7 +58,7 @@ and a coating diameter of 200 micron. - + Type/mode of the fiber. Modes of fiber transmission are shown in Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). diff --git a/contributed_definitions/NXlens_opt.nxdl.xml b/contributed_definitions/NXlens_opt.nxdl.xml index 3328b87007..f411ef16f5 100644 --- a/contributed_definitions/NXlens_opt.nxdl.xml +++ b/contributed_definitions/NXlens_opt.nxdl.xml @@ -50,7 +50,7 @@ Specify the properties of the lens. - + Type of the lens (e.g. concave, convex etc.). @@ -70,7 +70,7 @@ If you chose 'other' as type specify what it is. - + Is it a chromatic lens? @@ -172,7 +172,7 @@ the lens has different coatings on the front and back side.--> - Curvature radius of the lens. + Curvature radius of the lens. Instead of 'FACE' in the name of this field, the user is advised to specify for which surface (e.g. front or back) the curvature is provided: e.g. curvature_front or curvature_back. The front face is the surface on diff --git a/contributed_definitions/NXopt_element.nxdl.xml b/contributed_definitions/NXopt_element.nxdl.xml index 7cf26c73c4..e46928c446 100644 --- a/contributed_definitions/NXopt_element.nxdl.xml +++ b/contributed_definitions/NXopt_element.nxdl.xml @@ -63,7 +63,7 @@ Base class describing optical elements--> Use this field to point to the previous optical element. - + Type of excitation source. @@ -122,7 +122,7 @@ Metal Jet X-ray--> How many hours has the lamp been used? - + Wavelengths or energy vector of the excitation source. This can be a single value or a spectrum, depending on the type of experiment. @@ -148,7 +148,7 @@ Metal Jet X-ray--> Power of one light pulse if the source is a pulsed source. - + Is the excitation source continuous wave (CW)? @@ -204,7 +204,7 @@ Metal Jet X-ray--> Use this field to point to the previous optical element. - + The material of the window. @@ -281,7 +281,7 @@ Metal Jet X-ray--> fields, e.g. order of diffration (diffraction_order) or angular dispersion (angular_dispersion). - + Define the type of the grating. diff --git a/contributed_definitions/NXpolarizer_opt.nxdl.xml b/contributed_definitions/NXpolarizer_opt.nxdl.xml index 98ee05b46b..6611052a48 100644 --- a/contributed_definitions/NXpolarizer_opt.nxdl.xml +++ b/contributed_definitions/NXpolarizer_opt.nxdl.xml @@ -47,7 +47,7 @@ Specify the properties of a polarizer. - + Type of the polarizer (e.g. dichroic, linear, circular etc.) diff --git a/contributed_definitions/NXwaveplate.nxdl.xml b/contributed_definitions/NXwaveplate.nxdl.xml index 74e4d4da5d..e5c76dbfca 100644 --- a/contributed_definitions/NXwaveplate.nxdl.xml +++ b/contributed_definitions/NXwaveplate.nxdl.xml @@ -41,7 +41,7 @@ A waveplate or retarder. - + Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). From 678a6c86d94ddba71ad44c77802e2bcba4222be5 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Wed, 31 May 2023 07:16:21 +0200 Subject: [PATCH 153/203] updated beam path --- .../nyaml/NXbeam_path.yaml | 266 +++++++++++++++++- 1 file changed, 252 insertions(+), 14 deletions(-) diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml index 74d4e7e542..c9221b6538 100644 --- a/contributed_definitions/nyaml/NXbeam_path.yaml +++ b/contributed_definitions/nyaml/NXbeam_path.yaml @@ -28,15 +28,14 @@ doc: | NXbeam_path: doc: | Describe the relevant optical elements in the beam path by using the - appropriate base classes. in NXopt_element You may use as many elements as - needed, also several elements of the same type as long as each element has - its own name. + appropriate base classes. You may use as many elements as needed, also + several elements of the same type as long as each element has its own name. depends_on: doc: | Entry point of the dependency chain defined by the NXtransformations - field, i.e. a link to the first element in the beam path. - Example: /entry/instrument/beam_path/radiation_source. + field, i.e. a link to the last element in the beam path. + Example: /entry/instrument/beam_path/detector. (NXtransformations): # Possibilities: @@ -66,13 +65,252 @@ NXbeam_path: \@depends_on: doc: Add a link to the previous beam path element. - (NXopt_element): - exists: [min, 1] + (NXsource): doc: | - An optical element that is part of an optical setup or beam path. - If a commercial device, the company and model may be defined in the - respective fields. - company: - exists: optional - model: - exists: optional + Excitation source. One or more may be needed (e.g. two for a pump-probe + setup with one pump and one probe beam). + Depending on the source type, different properties are relevant, which + are provided through the respective base class (e.g. use NXopt_source for + lamps or lasers, NXchem_source for chemical reaction etc.). + Some base classes are incomplete (NXchem_source, NXbio_source); the + expertise of the respective communities is needed. + depends_on: + doc: Use this field to point to the previous optical element. + type: + doc: Type of excitation source. + enumeration: + # Spallation Neutron Source + # Pulsed Reactor Neutron Source + # Reactor Neutron Source + # Synchrotron X-ray Source + # Pulsed Muon Source + # Rotating Anode X-ray + # Fixed Tube X-ray + # UV Laser + # Free-Electron Laser + # Optical Laser + # Ion Source + # UV Plasma Source + # Metal Jet X-ray + [ + semiconductor laser, # NXopt_source + gas laser, # NXopt_source + other laser, # NXopt_source + lamp, # NXopt_source + X-rays, # NXsource ??? + silicon carbide globar, # NXopt_source + super continuum, # NXopt_source + chemical reaction, # NXchem_source + ultrasound, # NXacoustic_source + sound, # NXacoustic_source + living organism, # NXbio_source + power supply, # NXpower_supply + electron source, # from NXem ??? + other + ] + # separate base classes for different sources: + (NXacoustic_source): # needs to be developed + doc: | + Acoustic source, e.g. an ultrasonic transducero or a imploding gas + bubble (sonoluminescence). + (NXpower_supply): # needs to be developed + (NXchem_source): # input for experts from that field needed + (NXbio_source): # input for experts from that field needed + # is NXsource sufficient for x-rays? + (NXopt_source): + doc: Specify the properties of the optical source. + lifespan(NX_NUMBER): + doc: Lifespan of the excitation (typically provided in hours). + unit: NX_TIME + measure_time(NX_NUMBER): + doc: How many hours has the lamp been used? + unit: NX_TIME + excitation_wavelength(NX_FLOAT): + doc: | + Wavelengths or energy vector of the excitation source. This can be a + single value or a spectrum, depending on the type of experiment. + unit: NX_ANY + \@units: + doc: Unit of wavelength or energy. + beam_profile: + # ??? What's the best way to enter this ??? + doc: Two- or three-dimensional beam profile. + dimensions: + rank: 2 + dim: + [ + [1, N_beam_profile_dim], + [2, N_beam_profile_points] + ] + peak_power(NX_FLOAT): + doc: Power of one light pulse if the source is a pulsed source. + unit: NX_POWER + cw(NX_BOOLEAN): + doc: Is the excitation source continuous wave (CW)? + cw_power(NX_FLOAT): + doc: Power of CW beam. + bandwidth(NX_FLOAT): + doc: FWHM bandwidth of the excitation source. + unit: NX_WAVELENGTH + coherence_length(NX_FLOAT): + doc: Coherence length. + unit: NX_LENGTH + divergence(NX_FLOAT): + doc: Divergence of the excitation beam. + unit: NX_ANGLE + (NXpinhole): + doc: | + Use this field to describe a simple pinhole (round geometry). Define its + dimension using 'diameter'. For more complex geometries, 'NXaperture' + should be used. + (NXslit): + doc: | + Use this field to describe a simple slit (rectangular geometry). Define + its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, + 'NXaperture' should be used. + aperture_NUMBER(NXaperture): + doc: | + Use this field to describe an aperture. To specify a window, use the + field 'window_NUMBER(NXaperture)'. + window_NUMBER(NXaperture): + doc: | + A window, e.g. an entry or exit window of a cryostat. + depends_on: + doc: Use this field to point to the previous optical element. + material(NX_CHAR): + doc: The material of the window. + enumeration: + [ + quartz, + diamond, + calcium fluoride, + zinc selenide, + thallium bromoiodide, + alkali halide compound, + Mylar, + other, + ] + other_material(NX_CHAR): + doc: | + If you specified 'other' as material, decsribe here what it is. + thickness(NX_FLOAT): + doc: Thickness of the window + unit: NX_LENGTH + orientation_angle(NX_FLOAT): + doc: | + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + unit: NX_ANGLE + reference_data_link: + doc: | + If reference data were measured add a link to the NeXus file where they + are described. + (NXmirror): + filter_NUMBER(NXfilter): + (NXattenuator): + doc: A device that reduces the intensity of a beam by attenuation. + attenuator_transmission(NX_FLOAT): + doc: The transmitted intensity divided by the incident intensity. + unit: NX_DIMENSIONLESS + attenuation(NX_FLOAT): + doc: Attenuation of the attenuator in dB. + unit: NX_ANY + \@units: + doc: | + Unit of the measured data is not covered by NXDL units state + here which unit was used. + (NXaperture): + doc: Input and output aperture of the attenuator. + (NXgeomtry): + doc: Geometry (shape, size etc.) of the attenuator. + (NXgrating): + doc: | + A diffraction grating. Define relevant parameters in the corresponding + fields, e.g. order of diffration (diffraction_order) or angular + dispersion (angular_dispersion). + type: + doc: Define the type of the grating. + angular_dispersion(NX_FLOAT): + doc: Dispersion of the grating in nm/mm (or e.g. nm/mrad). + unit: NX_UNITLESS + grooves(NX_FLOAT): + doc: Number of grooves per mm. + unit: NX_PER_LENGTH + blaze_wavelength(NX_FLOAT): + doc: Blaze wavelength of the grating. + unit: NX_WAVELENGTH + efficiency(NX_FLOAT): + doc: Efficiency curve versus wavelength or energy. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: + [[1, N_spectrum]] + spectrum(NX_FLOAT): + doc: | + Spectral values, e.g. wavelength or energy. Vector of length + N_spectrum. + unit: NX_ANY + \@units: + doc: Unit of wavelength array (e.g. nanometer or Angstrom) + (NXdisk_chopper): + doc: | + A device blocking the beam in a temporal periodic pattern, e.g. a optical + chopper wheel. Specify the frequency range using 'min_frequency' and + 'max_frequency'. + min_frequency(NX_FLOAT): + doc: Minimum frequency in Hertz. + unit: NX_FREQUENCY + max_frequency(NX_FLOAT): + doc: Maximum frequency in Hertz. + unit: NX_FREQUENCY + frequency_resolution(NX_FLOAT): + doc: Frequency resolution in Hertz. + unit: NX_FREQUENCY + (NXmonochromator): + doc: | + A monochromator or spectrometer. + spectrum(NX_FLOAT): + doc: | + Spectral values of the monochromator, e.g. wavelength or energy values + used for the measurement. + unit: NX_ANY + \@units: + doc: Unit of wavelength array (e.g. nanometer or Angstrom) + (NXgrating): + doc: | + Diffraction grating. If two or more gratings were used, define the + angular dispersion and the wavelength range (min/max wavelength) for + each grating and make sure that the wavelength ranges do not overlap. + The dispersion should be defined for the entire wavelength range of the + experiment. + angular_dispersion(NX_FLOAT): + doc: Dispersion of the grating in nm/mm. + unit: NX_DIMENSIONLESS + grating_wavelength_min(NX_FLOAT): + doc: Minimum wavelength of the grating. + unit: NX_WAVELENGTH + grating_wavelength_max(NX_FLOAT): + doc: Maximum wavelength of the grating. + unit: NX_WAVELENGTH + spectral_resolution(NX_FLOAT): + doc: Spectral resolution of the instrument. + unit: NX_WAVENUMBER + (NXslit): + doc: Define the width of the monochromator slit in the subfield x_gap. + fixed_slit(NX_BOOLEAN): + doc: Was the slit width fixed? + max_gap(NX_FLOAT): + doc: If slit width was not fixed, define the maximum slit width. + unit: NX_LENGTH + + # x-ray optics: + (NXxraylens): + # what else? + + # ====== New base classes: ====== + (NXpolarizer_opt): + (NXbeam_splitter): + (NXwaveplate): + (NXlens_opt): + (NXfiber): From 6a8dd2da1a7fa5f752bbbdf05c216c1cc2915698 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Wed, 31 May 2023 07:17:21 +0200 Subject: [PATCH 154/203] updated beam path --- contributed_definitions/NXbeam_path.nxdl.xml | 376 ++++++++++++++++++- 1 file changed, 365 insertions(+), 11 deletions(-) diff --git a/contributed_definitions/NXbeam_path.nxdl.xml b/contributed_definitions/NXbeam_path.nxdl.xml index 64179dbcdd..fce893a8dc 100644 --- a/contributed_definitions/NXbeam_path.nxdl.xml +++ b/contributed_definitions/NXbeam_path.nxdl.xml @@ -48,15 +48,14 @@ more optical elements (e.g. a beam path in a luminescence setup).--> Describe the relevant optical elements in the beam path by using the - appropriate base classes. in NXopt_element You may use as many elements as - needed, also several elements of the same type as long as each element has - its own name. + appropriate base classes. You may use as many elements as needed, also + several elements of the same type as long as each element has its own name. Entry point of the dependency chain defined by the NXtransformations - field, i.e. a link to the first element in the beam path. - Example: /entry/instrument/beam_path/radiation_source. + field, i.e. a link to the last element in the beam path. + Example: /entry/instrument/beam_path/detector. @@ -92,13 +91,368 @@ properties (e.g. polarization state).--> - + - An optical element that is part of an optical setup or beam path. - If a commercial device, the company and model may be defined in the - respective fields. + Excitation source. One or more may be needed (e.g. two for a pump-probe + setup with one pump and one probe beam). + Depending on the source type, different properties are relevant, which + are provided through the respective base class (e.g. use NXopt_source for + lamps or lasers, NXchem_source for chemical reaction etc.). + Some base classes are incomplete (NXchem_source, NXbio_source); the + expertise of the respective communities is needed. - - + + + Use this field to point to the previous optical element. + + + + + Type of excitation source. + + + + + + + + + + + + + + + + + + + + + + + Acoustic source, e.g. an ultrasonic transducero or a imploding gas + bubble (sonoluminescence). + + + + + + + + + Specify the properties of the optical source. + + + + Lifespan of the excitation (typically provided in hours). + + + + + How many hours has the lamp been used? + + + + + Wavelengths or energy vector of the excitation source. This can be a + single value or a spectrum, depending on the type of experiment. + + + + Unit of wavelength or energy. + + + + + + + Two- or three-dimensional beam profile. + + + + + + + + + Power of one light pulse if the source is a pulsed source. + + + + + Is the excitation source continuous wave (CW)? + + + + + Power of CW beam. + + + + + FWHM bandwidth of the excitation source. + + + + + Coherence length. + + + + + Divergence of the excitation beam. + + + + + + + Use this field to describe a simple pinhole (round geometry). Define its + dimension using 'diameter'. For more complex geometries, 'NXaperture' + should be used. + + + + + Use this field to describe a simple slit (rectangular geometry). Define + its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, + 'NXaperture' should be used. + + + + + Use this field to describe an aperture. To specify a window, use the + field 'window_NUMBER(NXaperture)'. + + + + + A window, e.g. an entry or exit window of a cryostat. + + + + Use this field to point to the previous optical element. + + + + + The material of the window. + + + + + + + + + + + + + + + If you specified 'other' as material, decsribe here what it is. + + + + + Thickness of the window + + + + + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + + + + + If reference data were measured add a link to the NeXus file where they + are described. + + + + + + + + A device that reduces the intensity of a beam by attenuation. + + + + The transmitted intensity divided by the incident intensity. + + + + + Attenuation of the attenuator in dB. + + + + Unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Input and output aperture of the attenuator. + + + + + Geometry (shape, size etc.) of the attenuator. + + + + + + A diffraction grating. Define relevant parameters in the corresponding + fields, e.g. order of diffration (diffraction_order) or angular + dispersion (angular_dispersion). + + + + Define the type of the grating. + + + + + Dispersion of the grating in nm/mm (or e.g. nm/mrad). + + + + + Number of grooves per mm. + + + + + Blaze wavelength of the grating. + + + + + Efficiency curve versus wavelength or energy. + + + + + + + + Spectral values, e.g. wavelength or energy. Vector of length + N_spectrum. + + + + Unit of wavelength array (e.g. nanometer or Angstrom) + + + + + + + A device blocking the beam in a temporal periodic pattern, e.g. a optical + chopper wheel. Specify the frequency range using 'min_frequency' and + 'max_frequency'. + + + + Minimum frequency in Hertz. + + + + + Maximum frequency in Hertz. + + + + + Frequency resolution in Hertz. + + + + + + A monochromator or spectrometer. + + + + Spectral values of the monochromator, e.g. wavelength or energy values + used for the measurement. + + + + Unit of wavelength array (e.g. nanometer or Angstrom) + + + + + + Diffraction grating. If two or more gratings were used, define the + angular dispersion and the wavelength range (min/max wavelength) for + each grating and make sure that the wavelength ranges do not overlap. + The dispersion should be defined for the entire wavelength range of the + experiment. + + + + Dispersion of the grating in nm/mm. + + + + + Minimum wavelength of the grating. + + + + + Maximum wavelength of the grating. + + + + + + Spectral resolution of the instrument. + + + + + Define the width of the monochromator slit in the subfield x_gap. + + + + Was the slit width fixed? + + + + + If slit width was not fixed, define the maximum slit width. + + + + + + + + + + + + From 9e2d25d362e78cc93085a4df657c12b86848d679 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Wed, 31 May 2023 07:20:46 +0200 Subject: [PATCH 155/203] Delete NXopt_element.nxdl.xml --- .../NXopt_element.nxdl.xml | 415 ------------------ 1 file changed, 415 deletions(-) delete mode 100644 contributed_definitions/NXopt_element.nxdl.xml diff --git a/contributed_definitions/NXopt_element.nxdl.xml b/contributed_definitions/NXopt_element.nxdl.xml deleted file mode 100644 index e46928c446..0000000000 --- a/contributed_definitions/NXopt_element.nxdl.xml +++ /dev/null @@ -1,415 +0,0 @@ - - - - - - - - - Size of the wavelength or energy vector for which quantities of the optical - element, such as reflectivity or efficiency, are provided. - - - - - Number of dimensions for which the beam profile is given. - - - - - Number of points of the beam profile. - - - - - Optical elements that may be part of an optical setup or beam path. - - - Describe the optical element by using the appropriate sub class. - - - - Excitation source. One or more may be needed (e.g. two for a pump-probe - setup with one pump and one probe beam). - Depending on the source type, different properties are relevant, which - are provided through the respective base class (e.g. use NXopt_source for - lamps or lasers, NXchem_source for chemical reaction etc.). - Some base classes are incomplete (NXchem_source, NXbio_source); the - expertise of the respective communities is needed. - - - - Use this field to point to the previous optical element. - - - - - Type of excitation source. - - - - - - - - - - - - - - - - - - - - - - - Acoustic source, e.g. an ultrasonic transducero or a imploding gas - bubble (sonoluminescence). - - - - - - - - - Specify the properties of the optical source. - - - - Lifespan of the excitation (typically provided in hours). - - - - - How many hours has the lamp been used? - - - - - Wavelengths or energy vector of the excitation source. This can be a - single value or a spectrum, depending on the type of experiment. - - - - Unit of wavelength or energy. - - - - - - - Two- or three-dimensional beam profile. - - - - - - - - - Power of one light pulse if the source is a pulsed source. - - - - - Is the excitation source continuous wave (CW)? - - - - - Power of CW beam. - - - - - FWHM bandwidth of the excitation source. - - - - - Coherence length. - - - - - Divergence of the excitation beam. - - - - - - - Use this field to describe a simple pinhole (round geometry). Define its - dimension using 'diameter'. For more complex geometries, 'NXaperture' - should be used. - - - - - Use this field to describe a simple slit (rectangular geometry). Define - its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, - 'NXaperture' should be used. - - - - - Use this field to describe an aperture. To specify a window, use the - field 'window_NUMBER(NXaperture)'. - - - - - A window, e.g. an entry or exit window of a cryostat. - - - - Use this field to point to the previous optical element. - - - - - The material of the window. - - - - - - - - - - - - - - - If you specified 'other' as material, decsribe here what it is. - - - - - Thickness of the window - - - - - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - - - - - If reference data were measured add a link to the NeXus file where they - are described. - - - - - - - - A device that reduces the intensity of a beam by attenuation. - - - - The transmitted intensity divided by the incident intensity. - - - - - Attenuation of the attenuator in dB. - - - - Unit of the measured data is not covered by NXDL units state - here which unit was used. - - - - - - Input and output aperture of the attenuator. - - - - - Geometry (shape, size etc.) of the attenuator. - - - - - - A diffraction grating. Define relevant parameters in the corresponding - fields, e.g. order of diffration (diffraction_order) or angular - dispersion (angular_dispersion). - - - - Define the type of the grating. - - - - - Dispersion of the grating in nm/mm (or e.g. nm/mrad). - - - - - Number of grooves per mm. - - - - - Blaze wavelength of the grating. - - - - - Efficiency curve versus wavelength or energy. - - - - - - - - Spectral values, e.g. wavelength or energy. Vector of length - N_spectrum. - - - - Unit of wavelength array (e.g. nanometer or Angstrom) - - - - - - - A device blocking the beam in a temporal periodic pattern, e.g. a optical - chopper wheel. Specify the frequency range using 'min_frequency' and - 'max_frequency'. - - - - Minimum frequency in Hertz. - - - - - Maximum frequency in Hertz. - - - - - Frequency resolution in Hertz. - - - - - - A monochromator or spectrometer. - - - - Spectral values of the monochromator, e.g. wavelength or energy values - used for the measurement. - - - - Unit of wavelength array (e.g. nanometer or Angstrom) - - - - - - Diffraction grating. If two or more gratings were used, define the - angular dispersion and the wavelength range (min/max wavelength) for - each grating and make sure that the wavelength ranges do not overlap. - The dispersion should be defined for the entire wavelength range of the - experiment. - - - - Dispersion of the grating in nm/mm. - - - - - Minimum wavelength of the grating. - - - - - Maximum wavelength of the grating. - - - - - - Spectral resolution of the instrument. - - - - - Define the width of the monochromator slit in the subfield x_gap. - - - - Was the slit width fixed? - - - - - If slit width was not fixed, define the maximum slit width. - - - - - - - - - - - - - - From cfc5a801cf1d5cb15dec0e026d8050663573f705 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Wed, 31 May 2023 07:21:25 +0200 Subject: [PATCH 156/203] Delete NXopt_element.yaml --- .../nyaml/NXopt_element.yaml | 274 ------------------ 1 file changed, 274 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXopt_element.yaml diff --git a/contributed_definitions/nyaml/NXopt_element.yaml b/contributed_definitions/nyaml/NXopt_element.yaml deleted file mode 100644 index ebfab7115e..0000000000 --- a/contributed_definitions/nyaml/NXopt_element.yaml +++ /dev/null @@ -1,274 +0,0 @@ -# 05/2023 -# Base class describing optical elements - -category: base -symbols: - N_spectrum: | - Size of the wavelength or energy vector for which quantities of the optical - element, such as reflectivity or efficiency, are provided. - N_beam_profile_dim: | - Number of dimensions for which the beam profile is given. - N_beam_profile_points: | - Number of points of the beam profile. - -doc: | - Optical elements that may be part of an optical setup or beam path. - -NXopt_element: - doc: | - Describe the optical element by using the appropriate sub class. - - (NXsource): - doc: | - Excitation source. One or more may be needed (e.g. two for a pump-probe - setup with one pump and one probe beam). - Depending on the source type, different properties are relevant, which - are provided through the respective base class (e.g. use NXopt_source for - lamps or lasers, NXchem_source for chemical reaction etc.). - Some base classes are incomplete (NXchem_source, NXbio_source); the - expertise of the respective communities is needed. - depends_on: - doc: Use this field to point to the previous optical element. - type: - exists: required - doc: Type of excitation source. - enumeration: - # Spallation Neutron Source - # Pulsed Reactor Neutron Source - # Reactor Neutron Source - # Synchrotron X-ray Source - # Pulsed Muon Source - # Rotating Anode X-ray - # Fixed Tube X-ray - # UV Laser - # Free-Electron Laser - # Optical Laser - # Ion Source - # UV Plasma Source - # Metal Jet X-ray - [ - semiconductor laser, # NXopt_source - gas laser, # NXopt_source - other laser, # NXopt_source - lamp, # NXopt_source - X-rays, # NXsource ??? - silicon carbide globar, # NXopt_source - super continuum, # NXopt_source - chemical reaction, # NXchem_source - ultrasound, # NXacoustic_source - sound, # NXacoustic_source - living organism, # NXbio_source - power supply, # NXpower_supply - electron source, # from NXem ??? - other - ] - # separate base classes for different sources: - (NXacoustic_source): # needs to be developed - doc: | - Acoustic source, e.g. an ultrasonic transducero or a imploding gas - bubble (sonoluminescence). - (NXpower_supply): # needs to be developed - (NXchem_source): # input for experts from that field needed - (NXbio_source): # input for experts from that field needed - # is NXsource sufficient for x-rays? - (NXopt_source): - doc: Specify the properties of the optical source. - lifespan(NX_NUMBER): - doc: Lifespan of the excitation (typically provided in hours). - unit: NX_TIME - measure_time(NX_NUMBER): - doc: How many hours has the lamp been used? - unit: NX_TIME - excitation_wavelength(NX_FLOAT): - exists: required - doc: | - Wavelengths or energy vector of the excitation source. This can be a - single value or a spectrum, depending on the type of experiment. - unit: NX_ANY - \@units: - doc: Unit of wavelength or energy. - beam_profile: - # ??? What's the best way to enter this ??? - doc: Two- or three-dimensional beam profile. - dimensions: - rank: 2 - dim: - [ - [1, N_beam_profile_dim], - [2, N_beam_profile_points] - ] - peak_power(NX_FLOAT): - doc: Power of one light pulse if the source is a pulsed source. - unit: NX_POWER - cw(NX_BOOLEAN): - exists: required - doc: Is the excitation source continuous wave (CW)? - cw_power(NX_FLOAT): - doc: Power of CW beam. - bandwidth(NX_FLOAT): - doc: FWHM bandwidth of the excitation source. - unit: NX_WAVELENGTH - coherence_length(NX_FLOAT): - doc: Coherence length. - unit: NX_LENGTH - divergence(NX_FLOAT): - doc: Divergence of the excitation beam. - unit: NX_ANGLE - (NXpinhole): - doc: | - Use this field to describe a simple pinhole (round geometry). Define its - dimension using 'diameter'. For more complex geometries, 'NXaperture' - should be used. - (NXslit): - doc: | - Use this field to describe a simple slit (rectangular geometry). Define - its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, - 'NXaperture' should be used. - aperture_NUMBER(NXaperture): - doc: | - Use this field to describe an aperture. To specify a window, use the - field 'window_NUMBER(NXaperture)'. - window_NUMBER(NXaperture): - doc: | - A window, e.g. an entry or exit window of a cryostat. - depends_on: - doc: Use this field to point to the previous optical element. - material(NX_CHAR): - exists: required - doc: The material of the window. - enumeration: - [ - quartz, - diamond, - calcium fluoride, - zinc selenide, - thallium bromoiodide, - alkali halide compound, - Mylar, - other, - ] - other_material(NX_CHAR): - doc: | - If you specified 'other' as material, decsribe here what it is. - thickness(NX_FLOAT): - doc: Thickness of the window - unit: NX_LENGTH - orientation_angle(NX_FLOAT): - doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - unit: NX_ANGLE - reference_data_link: - doc: | - If reference data were measured add a link to the NeXus file where they - are described. - (NXmirror): - filter_NUMBER(NXfilter): - (NXattenuator): - doc: A device that reduces the intensity of a beam by attenuation. - attenuator_transmission(NX_FLOAT): - doc: The transmitted intensity divided by the incident intensity. - unit: NX_DIMENSIONLESS - attenuation(NX_FLOAT): - doc: Attenuation of the attenuator in dB. - unit: NX_ANY - \@units: - doc: | - Unit of the measured data is not covered by NXDL units state - here which unit was used. - (NXaperture): - doc: Input and output aperture of the attenuator. - (NXgeomtry): - doc: Geometry (shape, size etc.) of the attenuator. - (NXgrating): - doc: | - A diffraction grating. Define relevant parameters in the corresponding - fields, e.g. order of diffration (diffraction_order) or angular - dispersion (angular_dispersion). - type: - exists: required - doc: Define the type of the grating. - angular_dispersion(NX_FLOAT): - doc: Dispersion of the grating in nm/mm (or e.g. nm/mrad). - unit: NX_UNITLESS - grooves(NX_FLOAT): - doc: Number of grooves per mm. - unit: NX_PER_LENGTH - blaze_wavelength(NX_FLOAT): - doc: Blaze wavelength of the grating. - unit: NX_WAVELENGTH - efficiency(NX_FLOAT): - doc: Efficiency curve versus wavelength or energy. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: - [[1, N_spectrum]] - spectrum(NX_FLOAT): - doc: | - Spectral values, e.g. wavelength or energy. Vector of length - N_spectrum. - unit: NX_ANY - \@units: - doc: Unit of wavelength array (e.g. nanometer or Angstrom) - (NXdisk_chopper): - doc: | - A device blocking the beam in a temporal periodic pattern, e.g. a optical - chopper wheel. Specify the frequency range using 'min_frequency' and - 'max_frequency'. - min_frequency(NX_FLOAT): - doc: Minimum frequency in Hertz. - unit: NX_FREQUENCY - max_frequency(NX_FLOAT): - doc: Maximum frequency in Hertz. - unit: NX_FREQUENCY - frequency_resolution(NX_FLOAT): - doc: Frequency resolution in Hertz. - unit: NX_FREQUENCY - (NXmonochromator): - doc: | - A monochromator or spectrometer. - spectrum(NX_FLOAT): - doc: | - Spectral values of the monochromator, e.g. wavelength or energy values - used for the measurement. - unit: NX_ANY - \@units: - doc: Unit of wavelength array (e.g. nanometer or Angstrom) - (NXgrating): - doc: | - Diffraction grating. If two or more gratings were used, define the - angular dispersion and the wavelength range (min/max wavelength) for - each grating and make sure that the wavelength ranges do not overlap. - The dispersion should be defined for the entire wavelength range of the - experiment. - angular_dispersion(NX_FLOAT): - doc: Dispersion of the grating in nm/mm. - unit: NX_DIMENSIONLESS - grating_wavelength_min(NX_FLOAT): - doc: Minimum wavelength of the grating. - unit: NX_WAVELENGTH - grating_wavelength_max(NX_FLOAT): - doc: Maximum wavelength of the grating. - unit: NX_WAVELENGTH - spectral_resolution(NX_FLOAT): - doc: Spectral resolution of the instrument. - unit: NX_WAVENUMBER - (NXslit): - doc: Define the width of the monochromator slit in the subfield x_gap. - fixed_slit(NX_BOOLEAN): - doc: Was the slit width fixed? - max_gap(NX_FLOAT): - doc: If slit width was not fixed, define the maximum slit width. - unit: NX_LENGTH - - # x-ray optics: - (NXxraylens): - # what else? - - # ====== New base classes: ====== - (NXpolarizer_opt): - (NXbeam_splitter): - (NXwaveplate): - (NXlens_opt): - (NXfiber): From e461851fb243c595008c3255994f9ce5460cba09 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Wed, 31 May 2023 16:37:52 +0200 Subject: [PATCH 157/203] Delete NXellipsometry_new.yaml --- .../nyaml/NXellipsometry_new.yaml | 210 ------------------ 1 file changed, 210 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXellipsometry_new.yaml diff --git a/contributed_definitions/nyaml/NXellipsometry_new.yaml b/contributed_definitions/nyaml/NXellipsometry_new.yaml deleted file mode 100644 index 5b3d5ed08e..0000000000 --- a/contributed_definitions/nyaml/NXellipsometry_new.yaml +++ /dev/null @@ -1,210 +0,0 @@ -# 05/2023 -# Application definition for ellipsometry based on NXopt - -# Open questions: -# * Are the symbols inherited from NXopt or do we need to define them here? - -# To do: -# [ ] Harmonize NXopt and NXellipsometry - -category: application -doc: | - An application definition for ellipsometry. -symbols: - doc: Variables used throughout the document, e.g. dimensions or parameters. - N_spectrum: | - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - N_sensors: | - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. - N_measurements: | - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - N_incident_angles: Number of angles of incidence of the incident beam. - N_observables: | - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - -NXellipsometry(Xopt): - (NXentry): - doc: | - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition defines: - - * elements of the experimental instrument - * calibration information if available - * parameters used to tune the state of the sample - * sample description - - definition: - doc: An application definition describing a general optical experiment. - \@version: - doc: | - Version number to identify which definition of this application - definition was used for this entry/data. - \@url: - doc: | - URL where to find further material (documentation, examples) relevant - to the application definition. - enumeration: [NXellipsometry] - - (NXinstrument): - doc: | - General properties of the ellipsometry equipment including information - about the instrument (such as model, company etc.), information about - the calibration of the instrument, elements of the beam path including - the excitation or light source and the detector unit, the sample stage - (plus the sample environment, which also includes sensors used to - monitor external conditions) and elements of the beam path. - - Meta data describing the sample should be specified in ENTRY/SAMPLE - outside of ENTRY/INSTRUMENT. - ellipsometry_type: - doc: What type of ellipsometry was used? See Fujiwara Table 4.2. - enumeration: - [ - rotating analyzer, - rotating analyzer with analyzer compensator, - rotating analyzer with polarizer compensator, - rotating polarizer, - rotating compensator on polarizer side, - rotating compensator on analyzer side, - modulator on polarizer side, - modulator on analyzer side, - dual compensator, - phase modulation, - imaging ellipsometry, - null ellipsometry, - ] - incident_light(NXbeam_path): - doc: | - Describes the light source and the beam path between the source and - the sample. - If a beam splitter (i.e. a device that splits the incoming beam into - two or more beams) is part of the beam path, two or more NXbeam_path - fields may be needed to fully describe the beam paths and the correct - sequence of the beam path elements. - LIGHT_source(NXsource): - doc: | - Specify the used light source and its properties. In case of a - pump-probe setup, use one such field for the source of the probe - and one for the pump beam. It is suggested to use the names - 'probe_source' or 'pump_source' instead of 'LIGHT_source'. - (NXopt_source): - doc: Specify the properties of the optical source. - (NXmonochromator): - exists: optional - doc: | - Monochromator placed before the sample. If the monochromator is - placed after the sample (before the detector), the information - should be provided in 'INSTRUMENT/detection/MONOCHROMATOR'. - The spectral values (wavelength, energy, wavenumber etc.) should - be provided in 'data/SPECTRUM'. - (NXgrating): - exists: optional - doc: "Diffraction grating, as could be used in a monochromator. - If two or more gratings were used, define the angular - dispersion and the wavelength range (min/max wavelength) - for each grating and make sure that the wavelength ranges - do not overlap. The dispersion should be defined for the - entire wavelength range of the experiment." - angular_dispersion(NX_NUMBER): - exists: optional - doc: "Dispersion of the grating in nm/mm used." - grating_wavelength_min(NX_NUMBER): - exists: optional - doc: "Minimum wavelength of the grating." - unit: NX_LENGTH - grating_wavelength_max(NX_NUMBER): - exists: optional - doc: "Maximum wavelength of the grating." - unit: NX_LENGTH - spectral_resolution(NX_NUMBER): - exists: optional - doc: "Spectral resolution of the instrument." - unit: NX_WAVENUMBER - (NXslit): - exists: optional - doc: "Define the width of the monochromator slit in the subfield x_gap." - fixed_slit(NX_BOOLEAN): - exists: optional - doc: "Was the slit width fixed?" - max_gap(NX_NUMBER): - exists: optional - doc: "If slit width was not fixed, define the maximum slit width." - unit: NX_LENGTH - focussing_probes(NX_BOOLEAN): - doc: Were focussing probes (lenses) used? - data_correction(NX_BOOLEAN): - exists: optional - doc: | - Were the recorded data corrected by the window effects of the lenses? - angular_spread(NX_NUMBER): - exists: optional - doc: Specify the angular spread caused by the focussing probes - unit: NX_ANGLE - detection(NXbeam_path): - doc: | - Describes the beam path between the sample and the detector unit, as - well as the detector itself. A detector can be a photomultiplier - (PMT), a CCD in a camera, or an array in a spectrometer. If so, the - whole detector unit goes in here. It is also possible that more than - one detector are part of the setup. Use as many NXdetector fields as - needed. - - If a beam splitter (i.e. a device that splits the incoming beam into - two or more beams) is part of the beam path, two or more NXbeam_path - fields may be needed to fully describe the beam paths and the correct - sequence of the beam path elements. - (NXmonochromator): - exists: optional - doc: | - The spectroscope element of the ellipsometer before the detector, - but often integrated to form one closed unit. - If the monochromator is placed before the sample, it should be - specified in 'INSTRUMENT/incident_light/MONOCHROMATOR'. - The spectral values (wavelength, energy, wavenumber etc.) should - be provided in 'data/SPECTRUM'. - Information on the dispersive element can be specified in the - subfield GRATING. Note that different gratings might be used for - different wavelength ranges. The dispersion of the grating for each - wavelength range can be stored in grating_dispersion. - data(NXprocess): - doc: | - Measured data, data errors, and varied parameters. If reference data - were measured they should be considered a separate experiment and a - link to its NeXus file should be added in reference_data_link. - data_type: - doc: | - Select which type of data was recorded, for example Psi and Delta, - Mueller matrix, Jones matrix etc. - It is possible to have multiple selections. The enumeration list - depends on the type of experiment and may differ for different - application definitions. - enumeration: - [ - Psi/Delta, - tan(Psi)/cos(Delta), - Mueller matrix, - Jones matrix, - N/C/S, - raw data, - ] - column_names: - doc: | - Please list in this array the column names used in your actual data. - That is ['Psi', 'Delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16'] for a - full Mueller matrix, etc. - dimensions: - rank: 1 - dim: [[1, N_observables]] \ No newline at end of file From 793a7b6eefc28e47677c404954b95df5f71b5893 Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Wed, 31 May 2023 16:38:10 +0200 Subject: [PATCH 158/203] Delete NXellipsometry_test.yaml --- .../nyaml/NXellipsometry_test.yaml | 734 ------------------ 1 file changed, 734 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXellipsometry_test.yaml diff --git a/contributed_definitions/nyaml/NXellipsometry_test.yaml b/contributed_definitions/nyaml/NXellipsometry_test.yaml deleted file mode 100644 index 68a52830e3..0000000000 --- a/contributed_definitions/nyaml/NXellipsometry_test.yaml +++ /dev/null @@ -1,734 +0,0 @@ -# 06/2022 -# A draft version of a NeXus application definition for ellipsometry. - -# The document has the following main elements: -# - Instrument used and is characteristics -# - Measured data, the discription of the sample and what was measured about it -# - Derived parameters: extra parameters derived in the measurement software - -category: application -doc: | - Ellipsometry, complex systems, up to variable angle spectroscopy. - - Information on ellipsometry is provided, e.g. in: - - * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, - John Wiley & Sons, 2007. - * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, - North-Holland Publishing Company, 1977. - * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, - William Andrew, 2005. - - Open access sources: - - * https://www.angstromadvanced.com/resource.asp - * https://pypolar.readthedocs.io/en/latest/ - - Review articles: - - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", - J. Phys. D: Appl. Phys. 32, R45 (1999), - https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", - Thin Solid Films 571, 334-344 (2014), - https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", - Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, - (3 October 1997), - https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", - Thin Solid Films 233, 96-111 (1993), - https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", - Adv. Opt. Techn., (2022), - https://doi.org/10.1515/aot-2022-0016 - -symbols: - doc: "Variables used throughout the document, e.g. dimensions and important parameters" - N_wavelength: "Size of the energy or wavelength vector used, the length of - NXinstrument/spectrometer/wavelength array" - N_variables: "How many variables are saved in a measurement. e.g. 2 for Psi - and Delta, 16 for Mueller matrix elements, 15 for normalized - Mueller matrix, 3 for NCS, the length of NXsample/column_names" - N_angles: "Number of incident angles used, the length of - NXinstrument/angle_of_incidence array" - - N_p1: - "Number of sample parameters scanned, if you varied any of the parameters - such as temperature, pressure, or pH, the maximal length of the arrays - specified by NXsample/environment_conditions/SENSOR/value if it exists." - N_time: "Number of time points measured, the length of NXsample/time_points" - -NXellipsometry: - (NXentry): - doc: | - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition defines: - - * elements of the experimental instrument - * calibration information if available - * parameters used to tune the state of the sample - * sample description - - definition: - doc: "An application definition for ellipsometry." - \@version: - doc: "Version number to identify which definition of this application - definition was used for this entry/data." - \@url: - doc: "URL where to find further material (documentation, examples) - relevant to the application definition" - enumeration: [NXellipsometry] - - experiment_identifier: - doc: | - Unique identifier of the experiment, such as a (globally persistent) unique - identifier. - i) The identifier is usually defined by the facility or principle investigator. - ii) The identifier enables to link experiments to e.g. proposals. - - experiment_description: - exists: recommended - doc: "A free-text description of the experiment. What is the aim of the - experiment? The general procedure." - - start_time(NX_DATE_TIME): - doc: "Start time of the experiment. UTC offset should be specified." - - acquisition_program(NXprocess): - exists: optional - program: - doc: "Commercial or otherwise defined given name to the program that was - used to generate the result file(s) with measured data and metadata. - This program converts the measured signals to ellipsometry data. If - home written, one can provide the actual steps in the NOTE subfield - here." - version: - doc: "Either version with build number, commit hash, or description of - a (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner." - \@url: - doc: "Website of the software." - - (NXuser): - exists: [min, 1] - doc: "Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users if relevant is recommended." - name: - doc: "Name of the user." - affiliation: - doc: "Name of the affiliation of the user at the point in time when the - experiment was performed." - address: - doc: "Full address (street, street number, ZIP, city, country) of the - user's affiliation." - email: - doc: "Email address of the user." - orcid: - exists: recommended - doc: "Author ID defined by https://orcid.org/." - telephone_number: - exists: recommended - doc: "Official telephone number of the user." - - (NXinstrument): - doc: "General properties of the ellipsometry equipment" - model: - doc: The name of the instrument - \@version: - doc: "The used version of the hardware if available. If not a - commercial instrument use date of completion of the hardware." - company: - exists: optional - doc: "Name of the company which build the instrument" - - construction_year(NX_DATE_TIME): - exists: optional - doc: "ISO8601 date when the instrument was constructed. - UTC offset should be specified." - - firmware: - doc: "Commercial or otherwise defined name of the software that was - used for the measurement" - \@version: - doc: "Version and build number or commit hash of the software source code" - \@url: - doc: "Website of the software." - - light_source(NXsource): - doc: "Specify the used light source. Multiple selection possible." - - #type: -- be added into the base class - # doc: "NXsource lists already possible sources, and here we list some - # further sources to complement the original list. Please select one or - # more, according to the setup" - # enumeration: [arc lamp, halogen lamp, LED, other] - - #target_material: - # doc: "unlike in the original, the material used to generate the light, that is - # argon, helium, neon, gases, or mercury/cadmium vapor, etc." - - focussing_probes(NX_BOOLEAN): - doc: "Were focussing probes (lenses) used?" - - data_correction(NX_BOOLEAN): - exists: optional - doc: "Were the recorded data corrected by the window effects of the lenses?" - - angular_spread(NX_NUMBER): - exists: optional - doc: "Specify the angular spread caused by the focussing probes" - unit: NX_ANGLE - - ellipsometry_type: - doc: "What type of ellipsometry was used? See Fujiwara Table 4.2" - enumeration: - [ - rotating analyzer, - rotating analyzer with analyzer compensator, - rotating analyzer with polarizer compensator, - rotating polarizer, - rotating compensator on polarizer side, - rotating compensator on analyzer side, - modulator on polarizer side, - modulator on analyzer side, - dual compensator, - phase modulation, - imaging ellipsometry, - null ellipsometry, - ] - - calibration_status(NX_CHAR): - doc: "Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - calibration/calibration_time." - enumeration: - [ - calibration time provided, - no calibration, - within 1 hour, - within 1 day, - within 1 week, - ] - - calibration(NXsubentry): - exists: recommended - doc: "Ellipsometers require regular calibration to adjust the hardware - parameters for proper zero values and background light compensation." - calibration_time(NX_DATE_TIME): - exists: optional - doc: "If calibtration status is 'calibration time provided', specify - the ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified." - - calibration_data(NXsubentry): - doc: "Arrays which provide the measured calibration data. - Multiple sets are possible, e.g. Psi and delta measured on a - e.g. silicon calibration wafer, and the straight-through data. - We recommend to provide data that is measured under the same - settings as the measurement was performed, that is if Psi and - Delta are measured for your data, also provide Psi and Delta - here and use the same wavelenghts as for the measured data." - - calibration_data_type: - doc: "What data were recorded for the calibration? - The number of variables (N_variables) have to be set to the - number of provided data columns accordingly, - e.g. psi/delta -> N_variables = 2, - Jones vector -> N_variables = 4, - Mueller martix -> N_variables = 16, etc." - enumeration: - [ - psi/delta, - tan(psi)/cos(delta), - Jones matrix, - Mueller matrix, - not provided, - ] - calibration_angle_of_incidence(NX_NUMBER): - doc: "Angle(s) of incidence used during the calibration measurement - (excluding straight through mode)" - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, N_calibration_angles]] - - calibration_wavelength(NX_NUMBER): - doc: | - The wavelength or equivalent values (which are inter-convertible). - The importer should convert all to one unit, and make the others - accessible. Historically, energy is used in eV, but for visible - spectroscopy wavelength is more common, for IR wave numbers in - 1/cm units. - - Possibly use the same type of data as for the measurement. - dimensions: - rank: 1 - dim: [[1, N_calibration_wavelength]] - - calibration_data(NX_NUMBER): - doc: "Calibration is performed on a reference surface (usually a - silicon wafer with a well defined oxide layer) at a number of - angles of incidence and in a straight through mode - (transmission in air)." - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: - [ - [1, N_calibration_angles+1], - [2, N_variables], - [3, N_calibration_wavelength], - ] - - calibration_sample(NX_CHAR): - doc: "Free-text to describe which sample was used for calibration, - e.g. silicon wafer with 25 nm thermal oxide layer." - - angle_of_incidence(NX_NUMBER): - doc: "Incident angle of the beam vs. the normal of the bottom - reflective (substrate) surface in the sample" - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, N_angles]] - - stage(NXsubentry): - doc: "Sample stage, holding the sample at a specific position in X,Y,Z - (Cartesian) coordinate system and at an orientation defined - by three Euler angles (alpha, beta, gamma). - The stage may be motorized or manual, special for liquids or gas - environment." - stage_type(NX_CHAR): - doc: "Specify what type of stage was used." - enumeration: - [manual stage, scanning stage, liquid stage, gas cell, cryostat] - - description: - doc: "A free-text field to provide information about the stage." - exists: recommended - (NXtransformations): - exists: recommended - doc: "The stage coordinate system vs. the incident beam. The Z-axis - of the stage is considered to point along the normal of the - substrate (bottom reflecting surface) from the stage towards - the general direction of the light source. The beam comes with - the angle of incidence towards this Z-axis, but in opposite - direction, thus they are connected with a rotation of - 180 - angle of incidence (in degrees). - - This transformation brings us from the NEXUS coordinates to the - stage coordinates. - - Then provide the set of translations (if there are any). These - all have a vector defining their relative direction in the - current coordinate system. (This current coordinate system - changes with every transformation if you set the parameter - 'depends' to the name of the previous step.) - - Last, provide the rotations of the sample" - - alternative: - exists: optional - doc: "If there is no motorized stage, we should at least qualify - where the beam hits the sample and in what direction the - sample stands in a free-text description, e.g. 'center of - sample, long edge parallel to plane of incidence'." - - window(NXaperture): - exists: optional - doc: "For environmental measurements, the environment (liquid, vapor, - vacuum etc.) is enclosed in a cell or cryostat, which has windows - both in the direction of the source and the detector (looking - from the sample). These windows also add a phase shift to the - light altering the measured signal. This shift has to be - corrected based on measuring a known sample in the environmental - cell." - - material(NX_CHAR): - doc: The material of the window - enumeration: - [ - quartz, - diamond, - calcium fluoride, - zinc selenide, - thallium bromoiodide, - alkali halide compound, - Mylar, - other, - ] - - other_material(NX_CHAR): - exists: optional - doc: "If you specified 'other' as window material, decsribe here - what it is." - - thickness(NX_NUMBER): - doc: Thickness of the window - unit: NX_LENGTH - - orientation_angle(NX_NUMBER): - doc: "Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence)." - unit: NX_ANGLE - - reference_data(NXsubentry): - doc: "Recorded data that can be used to calculate the window effect. - Typically this is the substrate (e.g. silicon with thermal - oxide layer) in air without window and in a known medium with - the window." - - reference_sample: - doc: "What sample was used to estimate the window effect?" - - reference_wavelength(NX_NUMBER): - doc: "Wavelength of the reference data. Use the same wavelengths - at which all other measurements are recorded" - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, N_wavelength]] - - data(NX_NUMBER): - exists: recommended - doc: "Recorded data of a reference surface with and without window/medium." - unit: NX_UNITLESS - dimensions: - rank: 4 - dim: [[1, 2], [2, N_angles], [3, N_variables], [4, N_wavelength]] - - (NXdetector): - doc: "Which type of detector was used, and what is known about it? - A detector can be a photomultiplier (PMT), a CCD in a camera, or - an array in a spectrometer. If so, the whole detector unit goes - in here. - Integration time is the count time field, or the real time - field. See their definition." - - detector_type: - doc: "What kind of detector module is used, e.g. CCD-spectrometer, - CCD camera, PMT, photodiode, etc." - enumeration: - [ - PMT, - photodiode, - avalanche diode, - CCD camera, - CCD spectrometer, - other, - ] - - other_detector: - exists: optional - doc: "If you specified 'other' as detector type, please write down - what it is." - - revolution(NX_NUMBER): - exists: optional - doc: "Define how many rotations of the rotating element were taken - into account per spectrum." - unit: NX_ANY - - rotating_element: - doc: "Define which element rotates, e.g. polarizer or analyzer." - enumeration: - [ - polarizer (source side), - analyzer (detector side), - compensator (source side), - compensator (detector side), - ] - - fixed_revolution(NX_NUMBER): - exists: optional - doc: "Rotation rate, if the revolution does not change during - the measurement." - unit: NX_FREQUENCY - - variable_revolution(NX_NUMBER): - exists: optional - doc: "Specify maximum and minimum values for the revolution." - dimensions: - rank: 1 - dim: [[1, 2]] - - intensity_threshold(NX_NUMBER): - exists: optional - doc: "Minimum signal for which dynamic averaging is performed." - unit: NX_UNITLESS - - min_intensity(NX_NUMBER): - exists: optional - doc: "Value for the minimum intensity chosen. - Data points below this value might be skipped by the instrument" - unit: NX_UNITLESS - - spectrometer(NXmonochromator): - doc: "The spectroscope element of the ellipsometer before the detector, - but often integrated to form one closed unit. Information on the - dispersive element can be specified in the subfield GRATING. Note - that different gratings might be used for different wavelength - ranges. The dispersion of the grating for each wavelength range - can be stored in grating_dispersion." - - wavelength(NX_NUMBER): - doc: "Wavelength value(s) used for the measurement. - An array of 1 or more elements. Length defines N_wavelength" - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, N_wavelength]] - - (NXgrating): - exists: optional - doc: "Diffraction grating, as could be used in a monochromator. - If two or more gratings were used, define the angular - dispersion and the wavelength range (min/max wavelength) - for each grating and make sure that the wavelength ranges - do not overlap. The dispersion should be defined for the - entire wavelength range of the experiment." - - angular_dispersion(NX_NUMBER): - exists: optional - doc: "Dispersion of the grating in nm/mm used." - - grating_wavelength_min(NX_NUMBER): - exists: optional - doc: "Minimum wavelength of the grating." - unit: NX_LENGTH - - grating_wavelength_max(NX_NUMBER): - exists: optional - doc: "Maximum wavelength of the grating." - unit: NX_LENGTH - - spectral_resolution(NX_NUMBER): - exists: optional - doc: "Spectral resolution of the instrument." - unit: NX_WAVENUMBER - - (NXslit): - exists: optional - doc: "Define the width of the monochromator slit in the subfield x_gap." - - fixed_slit(NX_BOOLEAN): - exists: optional - doc: "Was the slit width fixed?" - - max_gap(NX_NUMBER): - exists: optional - doc: "If slit width was not fixed, define the maximum slit width." - unit: NX_LENGTH - - (NXsample): - doc: "Properties of the sample, its history, the sample environment and - experimental conditions (e.g. surrounding medium, temperature, - pressure etc.), along with the data (data type, wavelength array, - measured data)." - atom_types: - doc: | - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - sample_name: - doc: "Descriptive name of the sample" - - sample_history: - doc: "Ideally, a reference to the location or a unique (globally - persistent) identifier (e.g.) of e.g. another file which gives - as many as possible details of the material, its microstructure, - and its thermo-chemo-mechanical processing/preparation history. - In the case that such a detailed history of the sample is not - available, use this field as a free-text description to specify - details of the sample and its preparation." - - preparation_date(NX_DATE_TIME): - exists: recommended - doc: "ISO8601 date with time zone (UTC offset) specified." - - layer_structure: - doc: "Qualitative description of the layer structure for the sample. - For example: Si/native oxide/thermal oxide/polymer/peptide" - - data_identifier(NX_NUMBER): - doc: "An identifier to correlate data to the experimental conditions, - if several were used in this measurement; - typically an index of 0 - N" - - data_type: - doc: "Select which type of data was recorded, for example Psi and Delta - (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). - It is possible to have multiple selections. Data types may also be - converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. This selection defines how many columns (N_variables) are - stored in the data array." - enumeration: - [ - psi/delta, - tan(psi)/cos(delta), - Mueller matrix, - Jones matrix, - N/C/S, - raw data, - ] - - column_names: - doc: - "Please list in this array the column names used in your actual data. - That is ['psi', 'delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for - a full Mueller matrix, etc." - dimensions: - rank: 1 - dim: [[1, N_variables]] - - measured_data(NX_NUMBER): - doc: "Resulting data from the measurement, described by data type. - Minimum two columns containing Psi and Delta, or for the normalized - Mueller matrix it may be 16 (or 15 if the element (1,1) is all 1)." - dimensions: - rank: 5 - dim: - [ - [1, N_time], - [2, N_p1], - [3, N_angles], - [4, N_variables], - [5, N_wavelength], - ] - - data_error(NX_NUMBER): - doc: - "Specified uncertainties (errors) of the data described by data type. - The structure is the same as for the measured data." - exists: recommended - dimensions: - rank: 5 - dim: - [ - [1, N_time], - [2, N_p1], - [3, N_angles], - [4, N_variables], - [5, N_wavelength], - ] - - time_points(NX_NUMBER): - exists: optional - doc: "An array of relative time points if a time series was recorded." - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, N_time]] - - environment_conditions(NXenvironment): - doc: "Specify external parameters that have influenced the sample." - - medium: - doc: "Describe what was the medium above or around the sample. The - common model is built up from the substrate to the medium on the - other side. Both boundaries are assumed infinite in the model. - Here, define the name of the medium (e.g. water, air, UHV, etc.)." - - medium_refractive_indices(NX_NUMBER): - exists: optional - doc: "Array of pairs of complex refractive indices of the medium for - every measured wavelength. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - Specify the complex refractive index: n + ik" - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, N_wavelength]] - - number_of_runs(NX_UINT): - exists: optional - doc: "How many measurements were done varying the parameters? This - forms an extra dimension beyond incident angle, time points and - energy/wavelength (this is the length of the 4th dimension of - the data). Defaults to 1." - unit: NX_DIMENSIONLESS - - varied_parameters: - exists: optional - doc: "Indicates which parameter was changed. Its definition must exist - below. The specified variable has to be number_of_runs long, - providing the parameters for each data set. If you vary more than - one parameter simultaneously use one signal instance for each. - Record every parameter value in a linear manner, so N_p1 is the - number of measurements taken. - For example, if you measure at two temperatures and three pressures - the temperature signal value looks like [T1, T1, T1, T2, T2, T2] - and the pressure signal value looks like [p1, p2, p3, p1, p2, p3], - and N_p1 = 6." - enumeration: - [ - optical excitation, - voltage, - temperature, - pH, - stress, - stage positions, - ] - - optical_excitation(NXsource): - exists: optional - doc: - "Was the sample modified using an optical source? Describe in this - group the parameters of the optical excitation used." - - wavelength(NX_NUMBER): - doc: "Wavelength value(s) or the range used for excitation. - In cases of continuous laser radiation, a value or a set of - values may do but for other illumination types, such as pulsed - lasers, or lamps, a range may describe the source better." - unit: NX_LENGTH - - broadening(NX_NUMBER): - exists: optional - doc: "Specify the FWHM of the excitation" - unit: NX_LENGTH - - duration(NX_NUMBER): - exists: optional - doc: "How long was the sample excited." - unit: NX_TIME - - pulse_energy(NX_NUMBER): - exists: optional - doc: "The integrated energy of light pulse." - unit: NX_ENERGY - - (NXsensor): - exists: optional - doc: "A sensor used to monitor an external condition. The value - field contains the measured values. If it is constant within - an error for every run then use only an array of length one." - - derived_parameters(NXprocess): - exists: optional - doc: "What parameters are derived from the above data." - depolarization(NX_NUMBER): - exists: optional - doc: "Light loss due to depolarization as a value in [0-1]." - unit: NX_UNITLESS - - plot(NXdata): - exists: optional - doc: "A default view of the data, in this case Psi vs. wavelength and - the angles of incidence. If Psi does not exist, use other Mueller - matrix elements, such as N, C and S." - \@axes: - doc: "We recommend to use wavelength as a default attribute, but it - can be replaced in the case of not full spectral ellipsometry - to any suitable parameter along the X-axis." From ad0dfa773a78b189186c72d4d73a8ced4a2b955f Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Wed, 31 May 2023 16:38:53 +0200 Subject: [PATCH 159/203] Corrected app defs and base classes --- contributed_definitions/NXbeam_path.nxdl.xml | 140 +++++++++--------- .../NXellipsometry.nxdl.xml | 14 +- contributed_definitions/NXfiber.nxdl.xml | 11 +- contributed_definitions/NXlens_opt.nxdl.xml | 3 - contributed_definitions/NXopt.nxdl.xml | 42 +++--- .../NXpolarizer_opt.nxdl.xml | 5 +- 6 files changed, 104 insertions(+), 111 deletions(-) diff --git a/contributed_definitions/NXbeam_path.nxdl.xml b/contributed_definitions/NXbeam_path.nxdl.xml index fce893a8dc..1169fc670b 100644 --- a/contributed_definitions/NXbeam_path.nxdl.xml +++ b/contributed_definitions/NXbeam_path.nxdl.xml @@ -45,8 +45,7 @@ more optical elements (e.g. a beam path in a luminescence setup).--> two or more NXbeam_paths to describe the beam paths after the beam splitter. In this case, in the dependency chain of the new beam paths, the first elements each point to the beam splitter, as this is the previous element. - - + Describe the relevant optical elements in the beam path by using the appropriate base classes. You may use as many elements as needed, also several elements of the same type as long as each element has its own name. @@ -140,83 +139,78 @@ Optical Laser Ion Source UV Plasma Source Metal Jet X-ray--> - - + + - Acoustic source, e.g. an ultrasonic transducero or a imploding gas - bubble (sonoluminescence). + Lifespan of the excitation (typically provided in hours). - - - - - - + + - Specify the properties of the optical source. + How many hours has the lamp been used? - - - Lifespan of the excitation (typically provided in hours). - - - - - How many hours has the lamp been used? - - - - - Wavelengths or energy vector of the excitation source. This can be a - single value or a spectrum, depending on the type of experiment. - - - - Unit of wavelength or energy. - - - - - - - Two- or three-dimensional beam profile. - - - - - - - - - Power of one light pulse if the source is a pulsed source. - - - - - Is the excitation source continuous wave (CW)? - - - - - Power of CW beam. - - - - - FWHM bandwidth of the excitation source. - - - - - Coherence length. - - - + + + + Wavelengths or energy vector of the excitation source. This can be a + single value or a spectrum, depending on the type of experiment. + + - Divergence of the excitation beam. + Unit of wavelength or energy. - - + + + + + + Two- or three-dimensional beam profile. + + + + + + + + + Power of one light pulse if the source is a pulsed source. + + + + + Is the excitation source continuous wave (CW)? + + + + + Power of CW beam. + + + + + FWHM bandwidth of the excitation source. + + + + + Coherence length. + + + + + Divergence of the excitation beam. + + diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 2bd9ddd3ee..345b070607 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -247,12 +247,14 @@ A draft version of a NeXus application definition for ellipsometry.--> Specify the used light source. Multiple selection possible. - - - - - - + + + + + + + + diff --git a/contributed_definitions/NXfiber.nxdl.xml b/contributed_definitions/NXfiber.nxdl.xml index 364a06e2ea..ef32b14a45 100644 --- a/contributed_definitions/NXfiber.nxdl.xml +++ b/contributed_definitions/NXfiber.nxdl.xml @@ -192,14 +192,17 @@ Wavelength-dependent attenuation of the fiber (specify in dB/km). + + + - dB/km + Use dB/km. + + + - - - diff --git a/contributed_definitions/NXlens_opt.nxdl.xml b/contributed_definitions/NXlens_opt.nxdl.xml index f411ef16f5..e3bf121dac 100644 --- a/contributed_definitions/NXlens_opt.nxdl.xml +++ b/contributed_definitions/NXlens_opt.nxdl.xml @@ -47,9 +47,6 @@ Description of an optical lens. - - Specify the properties of the lens. - Type of the lens (e.g. concave, convex etc.). diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 8f3b7ed651..7f6d7e5b76 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -328,14 +328,14 @@ optical spectroscopy experiments--> - - - If there is no motorized stage, we should at least qualify where - the beam hits the sample and in what direction the sample stands - in a free-text description, e.g. 'center of sample, long edge - parallel to the plane of incidence'. - - + + + + If there is no motorized stage, we should at least qualify where + the beam hits the sample and in what direction the sample stands + in a free-text description, e.g. 'center of sample, long edge + parallel to the plane of incidence'. + @@ -400,13 +400,13 @@ optical spectroscopy experiments--> - + Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - + Vector containing the values of the varied parameter. Its @@ -694,6 +694,11 @@ optical spectroscopy experiments--> angles of incidence (a1, a2), the first measurement was taken at the parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. @@ -701,17 +706,17 @@ optical spectroscopy experiments--> here which unit was used. - - - - - Specified uncertainties (errors) of the data described by 'data_type' and provided in 'measured_data'. + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. @@ -719,11 +724,6 @@ optical spectroscopy experiments--> here which unit was used. - - - - - @@ -846,7 +846,7 @@ optical spectroscopy experiments--> - A default view of the data provided in ENTRY/data/measured_data. This + A default view of the data provided in ENTRY/data_collection/measured_data. This should be the part of the data set which provides the most suitable representation of the data. diff --git a/contributed_definitions/NXpolarizer_opt.nxdl.xml b/contributed_definitions/NXpolarizer_opt.nxdl.xml index 6611052a48..8edba8ecd3 100644 --- a/contributed_definitions/NXpolarizer_opt.nxdl.xml +++ b/contributed_definitions/NXpolarizer_opt.nxdl.xml @@ -44,9 +44,6 @@ Information on the properties of polarizer is provided e.g. [here](https://www.rp-photonics.com/polarizers.html). - - Specify the properties of a polarizer. - Type of the polarizer (e.g. dichroic, linear, circular etc.) @@ -239,7 +236,7 @@ the device has different coatings on the front and back side.--> Transmission of the polarizer at given wavelength values. - + From 0db20e50435dc78d78dbb7334fea0440308ebe3f Mon Sep 17 00:00:00 2001 From: cmmngr <98404894+cmmngr@users.noreply.github.com> Date: Wed, 31 May 2023 16:40:25 +0200 Subject: [PATCH 160/203] Corrected app defs and base classes --- .../nyaml/NXbeam_path.yaml | 105 +++++++++--------- .../nyaml/NXbeam_splitter.yaml | 29 +++-- .../nyaml/NXellipsometry.yaml | 3 +- contributed_definitions/nyaml/NXfiber.yaml | 32 +++--- contributed_definitions/nyaml/NXlens_opt.yaml | 30 +++-- contributed_definitions/nyaml/NXopt.yaml | 45 ++++---- .../nyaml/NXpolarizer_opt.yaml | 26 ++--- .../nyaml/NXwaveplate.yaml | 13 +-- 8 files changed, 137 insertions(+), 146 deletions(-) diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml index c9221b6538..2d88fbd450 100644 --- a/contributed_definitions/nyaml/NXbeam_path.yaml +++ b/contributed_definitions/nyaml/NXbeam_path.yaml @@ -25,12 +25,11 @@ doc: | In this case, in the dependency chain of the new beam paths, the first elements each point to the beam splitter, as this is the previous element. -NXbeam_path: - doc: | - Describe the relevant optical elements in the beam path by using the - appropriate base classes. You may use as many elements as needed, also - several elements of the same type as long as each element has its own name. + Describe the relevant optical elements in the beam path by using the + appropriate base classes. You may use as many elements as needed, also + several elements of the same type as long as each element has its own name. +NXbeam_path: depends_on: doc: | Entry point of the dependency chain defined by the NXtransformations @@ -109,55 +108,55 @@ NXbeam_path: other ] # separate base classes for different sources: - (NXacoustic_source): # needs to be developed + # (NXacoustic_source): # needs to be developed + # doc: | + # Acoustic source, e.g. an ultrasonic transducero or a imploding gas + # bubble (sonoluminescence). + # (NXpower_supply): # needs to be developed + # (NXchem_source): # input for experts from that field needed + # (NXbio_source): # input for experts from that field needed + # # is NXsource sufficient for x-rays? + # (NXopt_source): + # doc: Specify the properties of the optical source. + lifespan(NX_NUMBER): + doc: Lifespan of the excitation (typically provided in hours). + unit: NX_TIME + measure_time(NX_NUMBER): + doc: How many hours has the lamp been used? + unit: NX_TIME + excitation_wavelength(NX_FLOAT): doc: | - Acoustic source, e.g. an ultrasonic transducero or a imploding gas - bubble (sonoluminescence). - (NXpower_supply): # needs to be developed - (NXchem_source): # input for experts from that field needed - (NXbio_source): # input for experts from that field needed - # is NXsource sufficient for x-rays? - (NXopt_source): - doc: Specify the properties of the optical source. - lifespan(NX_NUMBER): - doc: Lifespan of the excitation (typically provided in hours). - unit: NX_TIME - measure_time(NX_NUMBER): - doc: How many hours has the lamp been used? - unit: NX_TIME - excitation_wavelength(NX_FLOAT): - doc: | - Wavelengths or energy vector of the excitation source. This can be a - single value or a spectrum, depending on the type of experiment. - unit: NX_ANY - \@units: - doc: Unit of wavelength or energy. - beam_profile: - # ??? What's the best way to enter this ??? - doc: Two- or three-dimensional beam profile. - dimensions: - rank: 2 - dim: - [ - [1, N_beam_profile_dim], - [2, N_beam_profile_points] - ] - peak_power(NX_FLOAT): - doc: Power of one light pulse if the source is a pulsed source. - unit: NX_POWER - cw(NX_BOOLEAN): - doc: Is the excitation source continuous wave (CW)? - cw_power(NX_FLOAT): - doc: Power of CW beam. - bandwidth(NX_FLOAT): - doc: FWHM bandwidth of the excitation source. - unit: NX_WAVELENGTH - coherence_length(NX_FLOAT): - doc: Coherence length. - unit: NX_LENGTH - divergence(NX_FLOAT): - doc: Divergence of the excitation beam. - unit: NX_ANGLE + Wavelengths or energy vector of the excitation source. This can be a + single value or a spectrum, depending on the type of experiment. + unit: NX_ANY + \@units: + doc: Unit of wavelength or energy. + beam_profile: + # ??? What's the best way to enter this ??? + doc: Two- or three-dimensional beam profile. + dimensions: + rank: 2 + dim: + [ + [1, N_beam_profile_dim], + [2, N_beam_profile_points] + ] + peak_power(NX_FLOAT): + doc: Power of one light pulse if the source is a pulsed source. + unit: NX_POWER + cw(NX_BOOLEAN): + doc: Is the excitation source continuous wave (CW)? + cw_power(NX_FLOAT): + doc: Power of CW beam. + bandwidth(NX_FLOAT): + doc: FWHM bandwidth of the excitation source. + unit: NX_WAVELENGTH + coherence_length(NX_FLOAT): + doc: Coherence length. + unit: NX_LENGTH + divergence(NX_FLOAT): + doc: Divergence of the excitation beam. + unit: NX_ANGLE (NXpinhole): doc: | Use this field to describe a simple pinhole (round geometry). Define its diff --git a/contributed_definitions/nyaml/NXbeam_splitter.yaml b/contributed_definitions/nyaml/NXbeam_splitter.yaml index f9f01bf748..0699f53184 100644 --- a/contributed_definitions/nyaml/NXbeam_splitter.yaml +++ b/contributed_definitions/nyaml/NXbeam_splitter.yaml @@ -27,14 +27,13 @@ doc: | each point to this beam splitter, as this is the previous element. NXbeam_splitter: - type: - exists: required + type: doc: | Specify the beam splitter type (e.g. dielectric mirror, pellicle, dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension should be described in 'geometry'. Define if the beam splitter is polarizing or not in the field 'polarizing(NX_BOOLEAN)'. - enumeration: + enumeration: [ "dichroic mirror", "dielectric mirror", @@ -53,16 +52,14 @@ NXbeam_splitter: beam splitter was used. polarizing(NX_BOOLEAN): - exists: required doc: Is the beam splitter polarizing? multiple_outputs(NX_BOOLEAN): # ??? Redundant because number of outputs is defined by N_outputs ??? - exists: required doc: | Does the beam splitter have multiple outputs (diffractive optical element), i.e. more than two outputs? - + (NXshape): exists: recommended doc: | @@ -151,7 +148,7 @@ NXbeam_splitter: doc: | Beam splitting ratio(s) for the various outputs (i.e. the paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels + The order of the ratios must be consistent with the labels 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. unit: NX_UNITLESS dimensions: @@ -230,12 +227,12 @@ NXbeam_splitter: unit: NX_UNITLESS dimensions: rank: 2 - dim: + dim: [ [1, 2], [2, N_spectrum] ] - + wavelength_range(NX_FLOAT): exists: recommended doc: | @@ -247,12 +244,12 @@ NXbeam_splitter: dimensions: rank: 1 dim: [[1, 2]] - + optical_loss(NX_NUMBER): doc: | Optical loss of the beam splitter for the various outputs (i.e. the paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels + The order of the ratios must be consistent with the labels 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. unit: NX_UNITLESS @@ -281,10 +278,10 @@ NXbeam_splitter: dim: [[1, 2]] # Aren't some beamsplitters defined for specific angles? Should we instead # use dim: [[1,N_angles]], N_angles being the number of angles for which the - # beam splitter can be operated? + # beam splitter can be operated? # If this is the case for some devices, we might also have to define a field # for the corresponding defelction angles... - + reflectance(NX_FLOAT): doc: | Reflectance of the beam splitter at given spectral values. @@ -300,15 +297,15 @@ NXbeam_splitter: doc: | Transmission at given spectral values for the various outputs (i.e. the paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels + The order of the ratios must be consistent with the labels 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. unit: NX_UNITLESS dimensions: rank: 2 - dim: + dim: [ [1, N_outputs], [2, N_spectrum_RT] ] - + diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index b8b39f2040..abd20ae9af 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -177,7 +177,8 @@ NXellipsometry(NXopt): (NXbeam_path): light_source(NXsource): doc: Specify the used light source. Multiple selection possible. - enumeration: [arc lamp, halogen lamp, LED, other] + source_type: + enumeration: [arc lamp, halogen lamp, LED, other] focussing_probes(NXlens_opt): exists: optional doc: | diff --git a/contributed_definitions/nyaml/NXfiber.yaml b/contributed_definitions/nyaml/NXfiber.yaml index d8d47d63c2..29201d6a7f 100644 --- a/contributed_definitions/nyaml/NXfiber.yaml +++ b/contributed_definitions/nyaml/NXfiber.yaml @@ -20,7 +20,6 @@ doc: | example. NXfiber: - description: exists: recommended doc: | @@ -30,20 +29,19 @@ NXfiber: and a coating diameter of 200 micron. type: - exists: required doc: | Type/mode of the fiber. Modes of fiber transmission are shown in Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). - enumeration: + enumeration: [ "single mode", "multimode graded index", "multimode step index" ] - + dispersion_type: doc: Type of dispersion. - enumeration: + enumeration: [ "modal", "material", @@ -56,7 +54,7 @@ NXfiber: unit: NX_TIME dimensions: rank: 1 - dim: + dim: [ [1, N_spectrum_core] ] @@ -76,12 +74,12 @@ NXfiber: unit: NX_UNITLESS dimensions: rank: 2 - dim: + dim: [ [1, 2], [2, N_spectrum_core] ] - + cladding(NXsample): doc: | Core of the fiber, i.e. the part of the fiber which transmits the light. @@ -102,7 +100,7 @@ NXfiber: [1, 2], [2, N_spectrum_clad] ] - + coating(NXsample): doc: Coating of the fiber. coating_material: @@ -114,7 +112,7 @@ NXfiber: length(NX_FLOAT): doc: Length of the fiber. unit: NX_LENGTH - + spectral_range(NX_FLOAT): exists: recommended doc: | @@ -132,24 +130,26 @@ NXfiber: transfer_rate(NX_FLOAT): doc: Transfer rate of the fiber (in GB per second). unit: NX_ANY - \@units: + \@units: doc: GB/s numerical_aperture(NX_FLOAT): doc: Numerical aperture (NA) of the fiber. - unit: NX_UNITLESS - + unit: NX_UNITLESS + attenuation(NX_FLOAT): doc: Wavelength-dependent attenuation of the fiber (specify in dB/km). unit: NX_ANY - \@units: - doc: dB/km dimensions: rank: 1 - dim: + dim: [ [1, N_spectrum_attenuation] ] + \@units: + doc: Use dB/km. + enumeration: + [dB/km] power_loss(NX_FLOAT): doc: Power loss of the fiber in percentage. diff --git a/contributed_definitions/nyaml/NXlens_opt.yaml b/contributed_definitions/nyaml/NXlens_opt.yaml index 42d150d741..9669433ddd 100644 --- a/contributed_definitions/nyaml/NXlens_opt.yaml +++ b/contributed_definitions/nyaml/NXlens_opt.yaml @@ -12,16 +12,13 @@ symbols: N_spectrum_RT: | Size of the wavelength array for which the reflectance or transmission of the lens is given. -doc: | - Description of an optical lens. + +doc: Description of an optical lens. NXlens_opt: - doc: Specify the properties of the lens. - type: - exists: required doc: Type of the lens (e.g. concave, convex etc.). - enumeration: + enumeration: [ "biconcave", "plano-concave", @@ -34,9 +31,8 @@ NXlens_opt: ] other_type: doc: If you chose 'other' as type specify what it is. - + chromatic(NX_BOOLEAN): # chromatic or achromatic - exists: required doc: Is it a chromatic lens? lens_diameter(NX_NUMBER): @@ -59,13 +55,13 @@ NXlens_opt: unit: NX_UNITLESS dimensions: rank: 2 - dim: + dim: [ [1, 2], [2, N_spectrum] ] - COATING(NXsample): + COATING(NXsample): # Used captial letters for COATING so that more than one can be defined if # the lens has different coatings on the front and back side. doc: | @@ -92,22 +88,22 @@ NXlens_opt: unit: NX_UNITLESS dimensions: rank: 2 - dim: + dim: [ [1, 2], [2, N_spectrum_coating] ] - + reflectance: doc: Reflectance of the lens at given spectral values. unit: NX_UNITLESS dimensions: rank: 1 - dim: + dim: [ [1, N_spectrum_RT] ] - + transmission: doc: Transmission of the lens at given spectral values. unit: NX_UNITLESS @@ -131,14 +127,14 @@ NXlens_opt: curvature_radius_FACE(NX_NUMBER): exists: recommended doc: | - Curvature radius of the lens. + Curvature radius of the lens. Instead of 'FACE' in the name of this field, the user is advised to specify for which surface (e.g. front or back) the curvature is provided: e.g. curvature_front or curvature_back. The front face is the surface on which the light beam is incident, while the back face is the one from which the light beam exits the lens. unit: NX_LENGTH - + Abbe_number(NX_NUMBER): doc: Abbe number (or V-number) of the lens. - unit: NX_UNITLESS + unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index eb595635b6..67c1fb078b 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -222,13 +222,13 @@ NXopt: gas cell, cryostat ] - alternative: - exists: optional - doc: | - If there is no motorized stage, we should at least qualify where - the beam hits the sample and in what direction the sample stands - in a free-text description, e.g. 'center of sample, long edge - parallel to the plane of incidence'. + alternative: + exists: optional + doc: | + If there is no motorized stage, we should at least qualify where + the beam hits the sample and in what direction the sample stands + in a free-text description, e.g. 'center of sample, long edge + parallel to the plane of incidence'. environment_conditions(NXenvironment): doc: | Specify external parameters that have influenced the sample, such @@ -291,12 +291,12 @@ NXopt: temperature, voltage, ] - number_of_parameters(NX_COUNT): + number_of_parameters(NX_UINT): doc: | Number of different parameter values at which the measurement was performed. For example, if the measurement was performed at temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - unit: NX_UNITLESS + unit: NX_COUNT values: doc: | Vector containing the values of the varied parameter. Its @@ -342,6 +342,7 @@ NXopt: * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] + dimensions: rank: 1 dim: [[1, N_measurements]] @@ -541,12 +542,6 @@ NXopt: angles of incidence (a1, a2), the first measurement was taken at the parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. unit: NX_ANY - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. dimensions: rank: 3 dim: @@ -555,26 +550,32 @@ NXopt: [2, N_observables], # 2 for Psi and Delta, 16 for Mueller matrix etc [3, N_spectrum] ] - measured_data_errors(NX_FLOAT): - exists: optional - doc: | - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. - unit: NX_ANY \@units: exists: optional doc: | If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. If the unit of the measured data is not covered by NXDL units state here which unit was used. + measured_data_errors(NX_FLOAT): + exists: optional + doc: | + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + unit: NX_ANY dimensions: rank: 3 dim: [ [1, N_measurements], - [2, N_observables], + [2, N_observables], # 2 for Psi and Delta, 16 for Mueller matrix etc [3, N_spectrum] ] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. varied_parameter_link: exists: optional doc: | diff --git a/contributed_definitions/nyaml/NXpolarizer_opt.yaml b/contributed_definitions/nyaml/NXpolarizer_opt.yaml index e8f789503d..e4eeb7e17a 100644 --- a/contributed_definitions/nyaml/NXpolarizer_opt.yaml +++ b/contributed_definitions/nyaml/NXpolarizer_opt.yaml @@ -9,7 +9,7 @@ symbols: N_spectrum_RT: | Size of the wavelength array for which the reflectance or transmission of the polarizer is given. - + doc: | An optical polarizer. @@ -17,9 +17,7 @@ doc: | [here](https://www.rp-photonics.com/polarizers.html). NXpolarizer_opt: - doc: Specify the properties of a polarizer. type: - exists: required doc: Type of the polarizer (e.g. dichroic, linear, circular etc.) enumeration: [ @@ -32,7 +30,7 @@ NXpolarizer_opt: "Glan-Focault prism", "Wollaston prism", "Normarski prism", - "Senarmont prism", + "Senarmont prism", "thin-film polarizer", "wire grid polarizer", "other" @@ -40,12 +38,12 @@ NXpolarizer_opt: # ??? Any other common polarizer types ??? type_other: doc: If you selected 'other' in type specify what it is. - + polarizer_angle(NX_NUMBER): exists: recommended doc: Angle of the polarizer. unit: NX_ANGLE - + acceptance_angle(NX_NUMBER): exists: recommended doc: Acceptance angle of the polarizer (range). @@ -53,7 +51,7 @@ NXpolarizer_opt: dimensions: rank: 1 dim: [[1, 2]] - + (NXshape): exists: recommended doc: | @@ -139,7 +137,7 @@ NXpolarizer_opt: [2, N_spectrum] ] - COATING(NXsample): + COATING(NXsample): # Used captial letters for COATING so that more than one can be defined if # the device has different coatings on the front and back side. doc: | @@ -169,13 +167,13 @@ NXpolarizer_opt: [1, 2], [2, N_spectrum_coating] ] - + extinction_ratio(NX_FLOAT): doc: Extinction ratio (maximum to minimum transmission). - unit: NX_UNITLESS + unit: NX_UNITLESS dimensions: rank: 1 - dim: + dim: [ [1, N_spectrum] ] @@ -185,16 +183,16 @@ NXpolarizer_opt: unit: NX_UNITLESS dimensions: rank: 1 - dim: + dim: [ [1, N_spectrum_RT], ] - + transmission(NX_FLOAT): doc: Transmission of the polarizer at given wavelength values. unit: NX_UNITLESS dimensions: - rank: 2 + rank: 1 dim: [ [1, N_spectrum_RT], diff --git a/contributed_definitions/nyaml/NXwaveplate.yaml b/contributed_definitions/nyaml/NXwaveplate.yaml index 5a3ccb86ba..aca40c9a9f 100644 --- a/contributed_definitions/nyaml/NXwaveplate.yaml +++ b/contributed_definitions/nyaml/NXwaveplate.yaml @@ -15,12 +15,11 @@ doc: | NXwaveplate: type: - exists: required doc: | Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). # A waveplate can be e.g. a dual-wavelength multi-order plate # => multiple selection needs to be possible - enumeration: + enumeration: [ "zero-order waveplate", "achromatic waveplate", @@ -31,18 +30,18 @@ NXwaveplate: # Are there any other common wave plate types? other_type: doc: If you selected 'other' in type describe what it is. - + retardance: doc: | Specify the retardance of the waveplate (e.g. full-wave, half-wave (lambda/2), quarter-wave (lambda/4) plate). - enumeration: + enumeration: [ "full-wave plate", "half-wave plate", "quarter-wave plate", ] - + wavelengths(NX_NUMBER): exists: recommended doc: | @@ -52,7 +51,7 @@ NXwaveplate: N_wavelengths = 2). dimensions: rank: 1 - dim: + dim: [ [1, N_wavelengths] ] @@ -87,7 +86,7 @@ NXwaveplate: unit: NX_UNITLESS dimensions: rank: 2 - dim: + dim: [ [1, 2], [2, N_spectrum] From e0079c9a4a3d40d041c27f29415e5250590769a9 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Sat, 10 Jun 2023 15:09:38 +0200 Subject: [PATCH 161/203] NXapm-relevant changes for a functional atom probe deployment in Leoben and other places --- contributed_definitions/NXapm.nxdl.xml | 216 +++++++++++++++++++---- contributed_definitions/nyaml/NXapm.yaml | 198 ++++++++++++++++++--- 2 files changed, 355 insertions(+), 59 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 265367a226..93669ff299 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -188,9 +188,12 @@ to describe also the upcoming technique of atomic scale analytical tomography ht respective field and fill rather as completely as possible the fields of the application definition behind instead of filling in these details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. - + ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. @@ -231,7 +234,7 @@ are required LAS root version camecaroot version analysis software--> - + Neither the specimen_name nor the experiment_identifier but the identifier through which the experiment is referred to in the control software. @@ -239,6 +242,10 @@ are required LAS root version camecaroot version analysis software--> run_number. For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, or the instruments at GPM in Rouen, use the identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. As a destructive microscopy technique, a run can be performed only once. It is possible, however, to interrupt a run and restart data acquisition @@ -246,12 +253,12 @@ are required LAS root version camecaroot version analysis software--> needs to be distinguished with different run numbers. We follow this habit of most atom probe groups. - This application definition does currently not allow to store the - entire set of such interrupted runs to be stored and covered. However, - this is not because of a technical limitation within NeXus but - because we have not seen a covering use case based on which we could - have implemented and conceptualized this. Atom probers are invited to - contact the respective people in the FAIRmat team to fix this. + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. @@ -301,12 +308,11 @@ are required LAS root version camecaroot version analysis software--> - + - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. @@ -370,6 +376,140 @@ are required LAS root version camecaroot version analysis software--> + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + Standard deviation to the grain_diameter. + + + + + The temperature of the last heat treatment step before quenching. + Knowledge about this value can give an idea how the sample + was heat treated, however if available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + Standard deviation to the heat_treatment_temperature. + + + + + Rate of the last quenching step. + Knowledge about this value can give an idea how the specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + Standard deviation of the heat_treatment_quenching_rate. + + + + + + The chemical composition of the sample. Typically it is assumed that + this more macroscopic composition is representative for the material + so that the composition of the typically substantially less voluminous + specimen probes from the more voluminous sample. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + - + A statement whether the measurement was successful or failed prematurely. + - + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index eae1def06e..461b09006e 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -118,8 +118,10 @@ NXapm: respective field and fill rather as completely as possible the fields of the application definition behind instead of filling in these details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. start_time(NX_DATE_TIME): - exists: recommended doc: | ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. @@ -158,6 +160,7 @@ NXapm: program: \@version: run_number: + exists: recommended doc: | Neither the specimen_name nor the experiment_identifier but the identifier through which the experiment is referred to in the control software. @@ -165,6 +168,10 @@ NXapm: run_number. For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, or the instruments at GPM in Rouen, use the identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. As a destructive microscopy technique, a run can be performed only once. It is possible, however, to interrupt a run and restart data acquisition @@ -172,12 +179,12 @@ NXapm: needs to be distinguished with different run numbers. We follow this habit of most atom probe groups. - This application definition does currently not allow to store the - entire set of such interrupted runs to be stored and covered. However, - this is not because of a technical limitation within NeXus but - because we have not seen a covering use case based on which we could - have implemented and conceptualized this. Atom probers are invited to - contact the respective people in the FAIRmat team to fix this. + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. experiment_documentation(NXnote): exists: optional doc: | @@ -218,12 +225,11 @@ NXapm: # exists: optional # doc: | (NXuser): - exists: [min, 1, max, infty] + exists: [min, 0, max, infty] doc: | - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. name: doc: Given (first) name and surname of the user. affiliation: @@ -272,6 +278,131 @@ NXapm: doc: | Name of the social media platform where the account under social_media_name is registered. + sample(NXsample): + exists: recommended + doc: | + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + grain_diameter(NX_FLOAT): + exists: optional + doc: | + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + unit: NX_LENGTH + grain_diameter_error(NX_FLOAT): + exists: optional + doc: | + Standard deviation to the grain_diameter. + unit: NX_LENGTH + heat_treatment_temperature(NX_FLOAT): + exists: optional + doc: | + The temperature of the last heat treatment step before quenching. + Knowledge about this value can give an idea how the sample + was heat treated, however if available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + unit: NX_TEMPERATURE + heat_treatment_temperature_error(NX_FLOAT): + exists: optional + doc: | + Standard deviation to the heat_treatment_temperature. + unit: NX_TEMPERATURE + heat_treatment_quenching_rate(NX_FLOAT): + exists: optional + doc: | + Rate of the last quenching step. + Knowledge about this value can give an idea how the specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + unit: NX_ANY + heat_treatment_quenching_rate_error(NX_FLOAT): + exists: optional + doc: | + Standard deviation of the heat_treatment_quenching_rate. + unit: NX_ANY + description: + exists: optional + (NXchemical_composition): + exists: recommended + doc: | + The chemical composition of the sample. Typically it is assumed that + this more macroscopic composition is representative for the material + so that the composition of the typically substantially less voluminous + specimen probes from the more voluminous sample. + normalization: + doc: | + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + enumeration: [atom_percent, weight_percent] + ION(NXion): + exists: [min, 1, max, 118] + name: + doc: | + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + composition(NX_FLOAT): + doc: | + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + unit: NX_DIMENSIONLESS specimen(NXsample): # NEW ISSUE: inject the conclusion from the discussion with Andrea # according to SAMPLE.yaml 0f8df14 2022/06/15 @@ -283,24 +414,29 @@ NXapm: doc: | Descriptive name or ideally (globally) unique persistent identifier. The name distinguishes the specimen from all others and especially the - predecessor/origin from where the specimen was cut. - In cases where the specimen was e.g. site-specifically cut from - samples or in cases of an instrument session during which multiple - specimens are loaded, the name has to be descriptive enough to resolve - which specimen on e.g. the microtip array was taken. + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. - The user is advised to store the details how specimens were - cut/prepared from samples in the sample history. This field must - not be used for an alias of the specimen. Instead, use short_title. + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. In cases where multiple specimens have been loaded into the microscope the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen in a single continuous run. + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. Details about the specimen preparation should be stored in the - sample history. + sample_history or if this is not possible in the sample group. sample_history: + exists: recommended doc: | Ideally, a reference to the location of or a (globally) unique persistent identifier of e.g. another file which should document @@ -315,6 +451,7 @@ NXapm: its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation. preparation_date(NX_DATE_TIME): + exists: recommended doc: | ISO 8601 time code with local time zone offset to UTC information when the specimen was prepared. @@ -330,10 +467,10 @@ NXapm: hydrogen charged specimens or experiments including tracers with a short half time. Further time stamps prior to preparation_date should better be placed in resources which describe the sample_history. - short_title: + alias: exists: optional doc: | - Possibility to give an abbreviation of the specimen name field. + Short_name or abbreviation of the specimen name field. atom_types: doc: | List of comma-separated elements from the periodic table @@ -348,7 +485,13 @@ NXapm: exists: optional doc: | Discouraged free-text field in case properly designed records - for the sample_history are not available. + for the sample_history or sample section are not available. + is_polycrystalline(NX_BOOLEAN): + exists: recommended + doc: | + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. # NEW ISSUE: error model # NEW ISSUE: use Andrea and MarkusK groups for # describing the geometry of the sample @@ -897,9 +1040,10 @@ NXapm: # most cases the processing is done in commercial software. status: + exists: recommended doc: | A statement whether the measurement was successful or failed prematurely. - enumeration: [success, failure] + enumeration: [success, failure, unknown] # NEW ISSUE: atomic volume, detection efficiency, electric field (assumptions), # final specimen state, pre, post image analysis, a reference to three images From e445bf59fcf547eb0699580e46523ba9f47b2cca Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Sat, 10 Jun 2023 17:11:02 +0200 Subject: [PATCH 162/203] Language edits and composition error --- contributed_definitions/NXapm.nxdl.xml | 11 ++++++++--- contributed_definitions/nyaml/NXapm.yaml | 10 +++++++--- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 93669ff299..4d991f59a2 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -421,7 +421,7 @@ are required LAS root version camecaroot version analysis software--> - Standard deviation to the grain_diameter. + Magnitude of the standard deviation of the grain_diameter. @@ -437,7 +437,7 @@ are required LAS root version camecaroot version analysis software--> - Standard deviation to the heat_treatment_temperature. + Magnitude of the standard deviation of the heat_treatment_temperature. @@ -465,7 +465,7 @@ are required LAS root version camecaroot version analysis software--> - Standard deviation of the heat_treatment_quenching_rate. + Magnitude of the standard deviation of the heat_treatment_quenching_rate. @@ -507,6 +507,11 @@ are required LAS root version camecaroot version analysis software--> is either an atom or weight percent quantity. + + + Magnitude of the standard deviation of the composition (value). + + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 461b09006e..30729bdf1a 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -324,7 +324,7 @@ NXapm: grain_diameter_error(NX_FLOAT): exists: optional doc: | - Standard deviation to the grain_diameter. + Magnitude of the standard deviation of the grain_diameter. unit: NX_LENGTH heat_treatment_temperature(NX_FLOAT): exists: optional @@ -340,7 +340,7 @@ NXapm: heat_treatment_temperature_error(NX_FLOAT): exists: optional doc: | - Standard deviation to the heat_treatment_temperature. + Magnitude of the standard deviation of the heat_treatment_temperature. unit: NX_TEMPERATURE heat_treatment_quenching_rate(NX_FLOAT): exists: optional @@ -368,7 +368,7 @@ NXapm: heat_treatment_quenching_rate_error(NX_FLOAT): exists: optional doc: | - Standard deviation of the heat_treatment_quenching_rate. + Magnitude of the standard deviation of the heat_treatment_quenching_rate. unit: NX_ANY description: exists: optional @@ -403,6 +403,10 @@ NXapm: The value is normalized based on normalization, i.e. composition is either an atom or weight percent quantity. unit: NX_DIMENSIONLESS + composition_error(NX_FLOAT): + doc: | + Magnitude of the standard deviation of the composition (value). + unit: NX_DIMENSIONLESS specimen(NXsample): # NEW ISSUE: inject the conclusion from the discussion with Andrea # according to SAMPLE.yaml 0f8df14 2022/06/15 From 732cc9ed09d24cb9b36d294ed8fe64d6084ca56f Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 12 Jun 2023 10:30:24 +0200 Subject: [PATCH 163/203] Minor reorganization of NXpulser_apm for the example with e.g. the Sydney group to support two lasers of the e.g. LEAP6000 series instruments --- contributed_definitions/NXapm.nxdl.xml | 8 +-- contributed_definitions/NXpulser_apm.nxdl.xml | 58 +++++++++---------- contributed_definitions/nyaml/NXapm.yaml | 12 ++-- .../nyaml/NXpulser_apm.yaml | 42 +++++++------- 4 files changed, 59 insertions(+), 61 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 4d991f59a2..da4736dfa9 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -889,10 +889,10 @@ laser_gun and laser_beam exists: [min, 0, max, 2]--> - - - - + + + + diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index feadaffa46..b45230e1ec 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -95,7 +95,7 @@ - + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the @@ -124,6 +124,33 @@ Average energy of the laser at peak of each pulse. + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + Affine transformations which describe the geometry how the @@ -136,31 +163,4 @@ - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 30729bdf1a..4fed5f857c 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -778,12 +778,12 @@ NXapm: exists: recommended pulse_energy(NX_FLOAT): exists: recommended - laser_beam(NXbeam): - exists: recommended - pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set - exists: recommended - spot_position(NXcollection): # NXsnapshot, NXcg_point_set - exists: recommended + (NXbeam): + exists: [min, 0, max, infty] + pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set + exists: recommended + spot_position(NXcollection): # NXsnapshot, NXcg_point_set + exists: recommended stage_lab(NXstage_lab): # NEW ISSUE: consider more detailed opportunities for specifying holders like cryo-controller holder, type of holder, material for pucks make a difference for studies which hunt for hydrogen signal, equally dwell time in buffer and load lock chamber and environmental transfer, the application definition does not account for this at the moment, would need a class representing stage and specimen holder hierarchy of the entire sample loading and transfer system and the contributions or not these components make wrt to contamination. diff --git a/contributed_definitions/nyaml/NXpulser_apm.yaml b/contributed_definitions/nyaml/NXpulser_apm.yaml index 347fc8608e..54021f6e78 100644 --- a/contributed_definitions/nyaml/NXpulser_apm.yaml +++ b/contributed_definitions/nyaml/NXpulser_apm.yaml @@ -54,8 +54,7 @@ NXpulser_apm: dimensions: rank: 1 dim: [[1, n_ions]] - - laser_gun(NXsource): + (NXsource): doc: | Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the @@ -74,6 +73,25 @@ NXpulser_apm: doc: Average energy of the laser at peak of each pulse. # NEW ISSUE: needs clearer specification/definition unit: NX_ENERGY + (NXbeam): + doc: | + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + incidence_vector(NXcollection): + doc: | + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set + doc: | + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + spot_position(NXcollection): # NXsnapshot, NXcg_point_set + doc: | + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. (NXtransformations): doc: | Affine transformations which describe the geometry how the @@ -83,23 +101,3 @@ NXpulser_apm: A right-handed Cartesian coordinate system, the so-called laser space, should be assumed, whose positive z-axis points into the direction of the propagating laser beam. - - laser_beam(NXbeam): - doc: | - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - incidence_vector(NXcollection): - doc: | - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set - doc: | - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - spot_position(NXcollection): # NXsnapshot, NXcg_point_set - doc: | - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. From 5bf6c2dd75043935bd503be8d0394f1d724a2fb5 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 12 Jun 2023 11:50:27 +0200 Subject: [PATCH 164/203] Changed composition_error to optional --- contributed_definitions/NXapm.nxdl.xml | 2 +- contributed_definitions/nyaml/NXapm.yaml | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index da4736dfa9..0ae0d98094 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -507,7 +507,7 @@ are required LAS root version camecaroot version analysis software--> is either an atom or weight percent quantity. - + Magnitude of the standard deviation of the composition (value). diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 4fed5f857c..42094b1d02 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -404,6 +404,7 @@ NXapm: is either an atom or weight percent quantity. unit: NX_DIMENSIONLESS composition_error(NX_FLOAT): + exists: optional doc: | Magnitude of the standard deviation of the composition (value). unit: NX_DIMENSIONLESS From eb0437cb9e8a9acd7bd8ea72c2051d4a9e727191 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Mon, 12 Jun 2023 19:36:54 +0200 Subject: [PATCH 165/203] Fixes NXellipsometry (#37) * Fixes typos in NXellipsometry and NXbeam_path * Corrects typo in NXgeometry --- contributed_definitions/NXbeam_path.nxdl.xml | 4 ++-- contributed_definitions/NXellipsometry.nxdl.xml | 6 +++--- contributed_definitions/nyaml/NXbeam_path.yaml | 4 ++-- contributed_definitions/nyaml/NXellipsometry.yaml | 6 +++--- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXbeam_path.nxdl.xml b/contributed_definitions/NXbeam_path.nxdl.xml index 1169fc670b..9dc4546fa7 100644 --- a/contributed_definitions/NXbeam_path.nxdl.xml +++ b/contributed_definitions/NXbeam_path.nxdl.xml @@ -70,7 +70,7 @@ properties (e.g. polarization state).--> position of the element in the beam path by pointing to the previous element. For the very first element, use the string "." instead. - + For each element in the beam path, one such field must exist with a '@depends_on' attribute defined to specify its position in the beam @@ -306,7 +306,7 @@ doc: Specify the properties of the optical source.--> Input and output aperture of the attenuator. - + Geometry (shape, size etc.) of the attenuator. diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 345b070607..2af9c29691 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -284,21 +284,21 @@ A draft version of a NeXus application definition for ellipsometry.--> Properties of the rotating element defined in 'instrument/rotating_element_type'. - + Define how many revolutions of the rotating element were averaged for each measurement. If the number of revolutions was fixed to a certain value use the field 'fixed_revolutions' instead. - + Define how many revolutions of the rotating element were taken into account for each measurement (if number of revolutions was fixed to a certain value, i.e. not averaged). - + Specify the maximum value of revolutions of the rotating element for each measurement. diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml index 2d88fbd450..81e27f6305 100644 --- a/contributed_definitions/nyaml/NXbeam_path.yaml +++ b/contributed_definitions/nyaml/NXbeam_path.yaml @@ -60,7 +60,7 @@ NXbeam_path: ELEMENT is a place holder for the name of an optical beam path element. Note that the name of this field must be exactly the same as the element's field name. - unit: NX_TRANSFORMATIONS + unit: NX_TRANSFORMATION \@depends_on: doc: Add a link to the previous beam path element. @@ -220,7 +220,7 @@ NXbeam_path: here which unit was used. (NXaperture): doc: Input and output aperture of the attenuator. - (NXgeomtry): + (NXgeometry): doc: Geometry (shape, size etc.) of the attenuator. (NXgrating): doc: | diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index abd20ae9af..d5d4651628 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -207,20 +207,20 @@ NXellipsometry(NXopt): Define how many revolutions of the rotating element were averaged for each measurement. If the number of revolutions was fixed to a certain value use the field 'fixed_revolutions' instead. - unit: NX_COUNTS + unit: NX_COUNT fixed_revolutions(NX_NUMBER): exists: optional doc: | Define how many revolutions of the rotating element were taken into account for each measurement (if number of revolutions was fixed to a certain value, i.e. not averaged). - unit: NX_COUNTS + unit: NX_COUNT max_revolutions(NX_NUMBER): exists: optional doc: | Specify the maximum value of revolutions of the rotating element for each measurement. - unit: NX_COUNTS + unit: NX_COUNT spectrometer(NXmonochromator): exists: optional doc: | From d45fc10ac2ff877161ca3fd43054afb61164d7b5 Mon Sep 17 00:00:00 2001 From: Rubel Date: Tue, 13 Jun 2023 17:07:55 +0200 Subject: [PATCH 166/203] Newly generated from yaml file for compare with fairmat_2023 branch. --- base_classes/NXaperture.nxdl.xml | 2 +- base_classes/NXbeam.nxdl.xml | 341 +---------------------------- base_classes/NXdetector.nxdl.xml | 26 +-- base_classes/NXentry.nxdl.xml | 234 +------------------- base_classes/NXinstrument.nxdl.xml | 2 +- base_classes/NXprocess.nxdl.xml | 2 +- base_classes/NXsample.nxdl.xml | 14 +- base_classes/NXsource.nxdl.xml | 221 +------------------ 8 files changed, 22 insertions(+), 820 deletions(-) diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index 7e64513caf..23c325e191 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 885f5c5b9d..9a32be4b7b 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -476,343 +476,4 @@ - diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index cb017217b2..9237df09ea 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -72,14 +72,12 @@ - + - + @@ -173,14 +171,12 @@ - + - + @@ -200,14 +196,12 @@ - + - + @@ -227,14 +221,12 @@ - + - + diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml index 8de48bc0f8..d110e2bcfb 100644 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -304,236 +304,4 @@ How do we set a default value for the type attribute?--> - diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index c5cb0a26fb..7ea8771cbb 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index 9da6f78ce7..ac5a8b81de 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 27ede84e5a..1834d3f4d0 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -300,7 +300,8 @@ - Details of beam incident on sample - used to calculate sample/beam interaction point + Details of beam incident on sample - used to calculate sample/beam interaction + point @@ -522,8 +523,7 @@ temperature.value is a link to e.g. temperature_env.sensor1.value - + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value @@ -538,10 +538,10 @@ magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - + - magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index f7c6f7e376..50f743ece4 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -320,223 +320,4 @@ other component groups. - From d2b3b290efc3ff54beb62ec4527277019866730d Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Tue, 13 Jun 2023 18:44:27 +0200 Subject: [PATCH 167/203] Added inheritance links to docs generation --- Makefile | 1 + dev_tools/docs/nxdl.py | 29 +++++++++++++++++++++++++++-- requirements.txt | 2 ++ 3 files changed, 30 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 65d1840899..e8a0ae2b59 100644 --- a/Makefile +++ b/Makefile @@ -6,6 +6,7 @@ PYTHON = python3 SPHINX = sphinx-build BUILD_DIR = "build" +export NEXUS_DEF_PATH = $(shell pwd) .PHONY: help install style autoformat test clean prepare html pdf impatient-guide all local diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 8da3ebbc05..3aff9e52a2 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -7,6 +7,8 @@ from typing import Optional import lxml +from pynxtools.dataconverter import helpers as pynxtools_helpers +from pynxtools.nexus import nexus as pynxtools_nxlib from ..globals.directories import get_nxdl_root from ..globals.errors import NXDLParseError @@ -506,7 +508,7 @@ def _print_attribute(self, ns, kind, node, optional, indent, parent_path): ) self._print(f"{indent}.. index:: {index_name} ({kind} attribute)\n") self._print( - f"{indent}**@{name}**: {optional}{self._format_type(node)}{self._format_units(node)}\n" + f"{indent}**@{name}**: {optional}{self._format_type(node)}{self._format_units(node)} {self.get_first_parent_ref(f'{parent_path}/{name}', 'attribute')}\n" ) self._print_doc(indent + self._INDENTATION_UNIT, ns, node) node_list = node.xpath("nx:enumeration", namespaces=ns) @@ -549,6 +551,7 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): f"{self._format_type(node)}" f"{dims}" f"{self._format_units(node)}" + f" {self.get_first_parent_ref(f'{parent_path}/{name}', 'field')}" "\n" ) @@ -585,7 +588,7 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): # target = hTarget.replace(".. _", "").replace(":\n", "") # TODO: https://github.com/nexusformat/definitions/issues/1057 self._print(f"{indent}{hTarget}") - self._print(f"{indent}**{name}**: {optional_text}{typ}\n") + self._print(f"{indent}**{name}**: {optional_text}{typ} {self.get_first_parent_ref(f'{parent_path}/{name}', 'group')}\n") self._print_if_deprecated(ns, node, indent + self._INDENTATION_UNIT) self._print_doc(indent + self._INDENTATION_UNIT, ns, node) @@ -624,3 +627,25 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): def _print(self, *args, end="\n"): # TODO: change instances of \t to proper indentation self._rst_lines.append(" ".join(args) + end) + + def get_first_parent_ref(self, path, tag): + nx_name = path[1:path.find("/", 1)] + path = path[path.find("/", 1):] + + parents = pynxtools_nxlib.get_inherited_nodes(path, nx_name)[2] + if len(parents) > 1: + parent = parents[1] + parent_path = parent_display_name = parent.attrib['nxdlpath'] + parent_path_segments = parent_path[1:].split("/") + parent_def_name = parent.attrib["nxdlbase"][parent.attrib["nxdlbase"].rfind("/"):parent.attrib["nxdlbase"].rfind(".nxdl")] + + # Case where the first parent is a base_class + if parent_path_segments[0] == '': + return f":ref:`<{parent_def_name[1:]}> <{parent_def_name[1:]}>`" + + parent_display_name = f"{parent_def_name[1:]}/.../{parent_path_segments[-1]}" if len(parent_path_segments)>1 else f"{parent_def_name[1:]}/{parent_path_segments[-1]}" + if tag == "attribute": + pos_of_right_slash = parent_path.rfind("/") + parent_path = parent_path[:pos_of_right_slash] + "@" + parent_path[pos_of_right_slash + 1:] + return f":ref:`<{parent_display_name}> <{parent_def_name}{parent_path}-{tag}>`" + return "" \ No newline at end of file diff --git a/requirements.txt b/requirements.txt index df2e384663..8b22819ff4 100644 --- a/requirements.txt +++ b/requirements.txt @@ -14,3 +14,5 @@ pytest black>=22.3 flake8>=4 isort>=5.10 + +pynxtools>=0.0.3 \ No newline at end of file From 62d45d812ea690e77f1f42229b6f6b98b6362424 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Jun 2023 10:57:28 +0200 Subject: [PATCH 168/203] NXellipsometry: removes spaces from parameter_type options --- contributed_definitions/NXopt.nxdl.xml | 20 ++++++++++++++------ contributed_definitions/nyaml/NXopt.yaml | 19 +++++++++++++------ 2 files changed, 27 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 7f6d7e5b76..98f9b496a8 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -379,27 +379,35 @@ optical spectroscopy experiments--> below. The specified variable has to be N_measurements long, providing the parameters for each data set. If you vary more than one parameter simultaneously. + If the measured parameter is not contained in the list `other` + should be specified and the `parameter_type_name` should be provided. - + - - - + + + - + - + + + + + If the parameter_type is `other` a name should be specified here. + + Number of different parameter values at which the measurement diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 67c1fb078b..244c75c928 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -271,26 +271,33 @@ NXopt: below. The specified variable has to be N_measurements long, providing the parameters for each data set. If you vary more than one parameter simultaneously. + If the measured parameter is not contained in the list `other` + should be specified and the `parameter_type_name` should be provided. enumeration: [ conductivity, detection_angle, - electric field, + electric_field, flow, - incident angle, - magnetic field, - optical excitation, + incident_angle, + magnetic_field, + optical_excitation, pH, pressure, resistance, shear, - stage positions, + stage_positions, strain, stress, - surface pressure, + surface_pressure, temperature, voltage, + other, ] + parameter_type_name: + doc: | + If the parameter_type is `other` a name should be specified here. + exists: optional number_of_parameters(NX_UINT): doc: | Number of different parameter values at which the measurement From 843283acb772b6a7eab4248afc2783a69b9fdba1 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Jun 2023 11:11:19 +0200 Subject: [PATCH 169/203] Reverts NXmpes base classes --- base_classes/NXaperture.nxdl.xml | 150 ++---- base_classes/NXbeam.nxdl.xml | 759 +++++---------------------- base_classes/NXinstrument.nxdl.xml | 146 +++--- base_classes/NXprocess.nxdl.xml | 80 ++- base_classes/nyaml/NXaperture.yaml | 19 +- base_classes/nyaml/NXbeam.yaml | 112 +--- base_classes/nyaml/NXinstrument.yaml | 123 ++++- base_classes/nyaml/NXprocess.yaml | 10 - 8 files changed, 391 insertions(+), 1008 deletions(-) diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index 7e64513caf..e18b2a5f0e 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -1,14 +1,14 @@ - + - - - A beamline aperture. This group is deprecated, use NXslit instead. - - + + + A beamline aperture. This group is deprecated, use NXslit instead. + + - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the - surface of the aperture pointing towards the source. - - In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - - .. image:: aperture/aperture.png - :width: 40% - + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the + surface of the aperture pointing towards the source. + + In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + + .. image:: aperture/aperture.png + :width: 40% + - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - - - Stores the raw positions of aperture motors. - + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + - location and shape of aperture - - .. TODO: documentation needs improvement, contributions welcome - - * description of terms is poor and leaves much to interpretation - * Describe what is meant by translation _here_ and ... - * Similar throughout base classes - * Some base classes do this much better - * Such as where is the gap written? + location and shape of aperture + + .. TODO: documentation needs improvement, contributions welcome + + * description of terms is poor and leaves much to interpretation + * Describe what is meant by translation _here_ and ... + * Similar throughout base classes + * Some base classes do this much better + * Such as where is the gap written? + - - location and shape of each blade - + location and shape of each blade - - - - Absorbing material of the aperture - + + Absorbing material of the aperture - - Description of aperture - - - - - Shape of the aperture. - - - - - - - - - - - - - + Description of aperture - - - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter - - - - - describe any additional information in a note* - - + describe any additional information in a note* - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 885f5c5b9d..232a75e46d 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -1,14 +1,14 @@ - + - + - These symbols coordinate datasets with the same shape. + These symbols coordinate datasets with the same shape. - - Number of scan points. - + Number of scan points. - - Number of channels in the incident beam spectrum, if known - + Number of channels in the incident beam spectrum, if known - - Number of moments representing beam divergence (x, y, xy, etc.) - - - - - Number of pixels of the horizontal axis (e.g. delay) of a FROG trace - - - - - Number of pixels of the vertical axis (e.g. frequency) of a FROG trace - + Number of moments representing beam divergence (x, y, xy, etc.) - Properties of the neutron or X-ray beam at a given location. - - This group is intended to be referenced - by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. - To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred - by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. - - - - Distance from sample. Note, it is recommended to use NXtransformations instead. + Properties of the neutron or X-ray beam at a given location. + + This group is intended to be referenced + by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is + especially valuable in storing the results of instrument simulations in which it is useful + to specify the beam profile, time distribution etc. at each beamline component. Otherwise, + its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. + + Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. + To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred + by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. + + Distance from sample. Note, it is recommended to use NXtransformations instead. - - Energy carried by each particle of the beam on entering the beamline component. - - In the case of a monochromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the - presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - + Energy carried by each particle of the beam on entering the beamline component - - - The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in - the energy spread, this is a 2D array of dimension nP by m - (slow to fast) of the spreads of the corresponding - wavelength in incident_wavelength. - - - - - In the case of a polychromatic beam this is an array of length m of the relative - weights of the corresponding energies in incident_energy. In the case of a - polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np - by m (slow to fast) of the relative weights of the corresponding energies in - incident_energy. - - - - Energy carried by each particle of the beam on leaving the beamline component - + Energy carried by each particle of the beam on leaving the beamline component - - Change in particle energy caused by the beamline component - + Change in particle energy caused by the beamline component - In the case of a monochromatic beam this is the scalar - wavelength. - - Several other use cases are permitted, depending on the - presence or absence of other incident_wavelength_X - fields. - - In the case of a polychromatic beam this is an array of - length **m** of wavelengths, with the relative weights - in ``incident_wavelength_weights``. - - In the case of a monochromatic beam that varies shot- - to-shot, this is an array of wavelengths, one for each - recorded shot. Here, ``incident_wavelength_weights`` and - incident_wavelength_spread are not set. - - In the case of a polychromatic beam that varies shot-to- - shot, this is an array of length **m** with the relative - weights in ``incident_wavelength_weights`` as a 2D array. - - In the case of a polychromatic beam that varies shot-to- - shot and where the channels also vary, this is a 2D array - of dimensions **nP** by **m** (slow to fast) with the - relative weights in ``incident_wavelength_weights`` as a 2D - array. - - Note, :ref:`variants <Design-Variants>` are a good way - to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value wavelength value is - available along with the original spectrum from which it - was calibrated. - Wavelength on entering beamline component + In the case of a monochromatic beam this is the scalar + wavelength. + + Several other use cases are permitted, depending on the + presence or absence of other incident_wavelength_X + fields. + + In the case of a polychromatic beam this is an array of + length **m** of wavelengths, with the relative weights + in ``incident_wavelength_weights``. + + In the case of a monochromatic beam that varies shot- + to-shot, this is an array of wavelengths, one for each + recorded shot. Here, ``incident_wavelength_weights`` and + incident_wavelength_spread are not set. + + In the case of a polychromatic beam that varies shot-to- + shot, this is an array of length **m** with the relative + weights in ``incident_wavelength_weights`` as a 2D array. + + In the case of a polychromatic beam that varies shot-to- + shot and where the channels also vary, this is a 2D array + of dimensions **nP** by **m** (slow to fast) with the + relative weights in ``incident_wavelength_weights`` as a 2D + array. + + Note, :ref:`variants <Design-Variants>` are a good way + to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value wavelength value is + available along with the original spectrum from which it + was calibrated. + Wavelength on entering beamline component - In the case of a polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in ``incident_wavelength``. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **nP** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in ``incident_wavelength``. + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in ``incident_wavelength``. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **nP** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in ``incident_wavelength``. - The wavelength spread FWHM for the corresponding - wavelength(s) in incident_wavelength. - - In the case of shot-to-shot variation in the wavelength - spread, this is a 2D array of dimension **nP** by - **m** (slow to fast) of the spreads of the - corresponding wavelengths in incident_wavelength. + The wavelength spread FWHM for the corresponding + wavelength(s) in incident_wavelength. + + In the case of shot-to-shot variation in the wavelength + spread, this is a 2D array of dimension **nP** by + **m** (slow to fast) of the spreads of the + corresponding wavelengths in incident_wavelength. @@ -191,15 +139,15 @@ - Beam crossfire in degrees parallel to the laboratory X axis - - The dimension **c** is a series of moments of that represent - the standard uncertainty (e.s.d.) of the directions of - of the beam. The first and second moments are in the XZ and YZ - planes around the mean source beam direction, respectively. - - Further moments in **c** characterize co-variance terms, so - the next moment is the product of the first two, and so on. + Beam crossfire in degrees parallel to the laboratory X axis + + The dimension **c** is a series of moments of that represent + the standard uncertainty (e.s.d.) of the directions of + of the beam. The first and second moments are in the XZ and YZ + planes around the mean source beam direction, respectively. + + Further moments in **c** characterize co-variance terms, so + the next moment is the product of the first two, and so on. @@ -208,8 +156,8 @@ - Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM + Size of the beam entering this component. Note this represents + a rectangular beam aperture, and values represent FWHM @@ -217,45 +165,20 @@ - - Wavelength on leaving beamline component - + Wavelength on leaving beamline component - - Incident polarization as a Stokes vector - on entering beamline component - + Polarization vector on entering beamline component - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - - - - Polarization as Stokes vector on leaving beamline component - + Polarization vector on leaving beamline component @@ -264,25 +187,25 @@ Polarization vector on entering beamline component using Stokes notation - + The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. These are defined with the standard Nexus coordinate frame unless it is overridden by an NXtransformations field pointed to by a depends_on attribute. The last component, describing the circular polarization state, is positive for a right-hand circular state - that is the electric field vector rotates clockwise at the sample and over time when observed from the source. - - I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale + + I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale linearly with the total degree of polarization, and indicate the relative magnitudes of the pure linear and circular orientation contributions. Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). U (S_2) is linearly polarized along the x==y axis (U > 0) or the - -x==y axis (U < 0). - + -x==y axis (U < 0). + V (S_3) is circularly polarized. V > 0 when the electric field vector rotates - clockwise at the sample with respect to time when observed from the source; + clockwise at the sample with respect to time when observed from the source; V < 0 indicates the opposite rotation. @@ -301,518 +224,114 @@ - - Wavelength spread FWHM of beam leaving this component - + Wavelength spread FWHM of beam leaving this component - - Divergence FWHM of beam leaving this component - + Divergence FWHM of beam leaving this component - - flux incident on beam plane area - + flux incident on beam plane area - - - Energy of a single pulse at the diagnostic point - - - - - Average power at the diagnostic point - - - - - Incident fluence at the diagnostic point - - - - Here: SI units are 'J/m2', customary 'mJ/cm2'. - - - - - - FWHM duration of the pulses at the diagnostic point - - - - - FROG trace of the pulse. - - - - - - - - - Horizontal axis of a FROG trace, i.e. delay. - - - - - - - - Vertical axis of a FROG trace, i.e. frequency. - - - - - - - - The type of chirp implemented - - - - - Group delay dispersion of the pulse for linear chirp - - - Distribution of beam with respect to relevant variable e.g. wavelength. - This is mainly useful for simulations which need to store plottable - information at each beamline component. - + Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly + useful for simulations which need to store plottable information at each beamline + component. - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - + + - The NeXus coordinate system defines the Z axis to be along the nominal beam - direction. This is the same as the McStas coordinate system (see :ref:Design-CoordinateSystem). - However, the additional transformations needed to represent an altered beam - direction can be provided using this depends_on field that contains the path - to a NXtransformations group. This could represent redirection of the beam, - or a refined beam direction. + The NeXus coordinate system defines the Z axis to be along the nominal beam + direction. This is the same as the McStas coordinate system (see :ref:Design-CoordinateSystem). + However, the additional transformations needed to represent an altered beam + direction can be provided using this depends_on field that contains the path + to a NXtransformations group. This could represent redirection of the beam, + or a refined beam direction. + - Direction (and location) for the beam. The location of the beam can be given by - any point which it passes through as its offset attribute. + Direction (and location) for the beam. The location of the beam can be given by + any point which it passes through as its offset attribute. - + - Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] - and passes through the origin + Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] + and passes through the origin - + - Three values that define the direction of beam vector + Three values that define the direction of beam vector - Three values that define the location of a point through which the beam passes + Three values that define the location of a point through which the beam passes - Points to the path to a field defining the location on which this - depends or the string "." for origin. + Points to the path to a field defining the location on which this + depends or the string "." for origin. - + - Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. - This also defines the parallel and perpendicular components of the beam's polarization. - If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin + Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. + This also defines the parallel and perpendicular components of the beam's polarization. + If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin - + - Three values that define the direction of reference plane normal + Three values that define the direction of reference plane normal - Not required as beam direction offset locates the plane + Not required as beam direction offset locates the plane - Points to the path to a field defining the location on which this - depends or the string "." for origin. - - - - - diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index c5cb0a26fb..e385f3671d 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -1,14 +1,14 @@ - + - - - Collection of the components of the instrument or beamline. - - Template of instrument descriptions comprising various beamline components. - Each component will also be a NeXus group defined by its distance from the - sample. Negative distances represent beamline components that are before the - sample while positive distances represent components that are after the sample. - This device allows the unique identification of beamline components in a way - that is valid for both reactor and pulsed instrumentation. - - - - Name of instrument - - - - short name for instrument, perhaps the acronym - - - - - - Energy resolution of the experiment (FWHM or gaussian broadening) - - - - - Momentum resolution of the experiment (FWHM) - - - - - Angular resolution of the experiment (FWHM) - - - - - Spatial resolution of the experiment (Airy disk radius) - - - - - Temporal resolution of the experiment (FWHM) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + Collection of the components of the instrument or beamline. + + Template of instrument descriptions comprising various beamline components. + Each component will also be a NeXus group defined by its distance from the + sample. Negative distances represent beamline components that are before the + sample while positive distances represent components that are after the sample. + This device allows the unique identification of beamline components in a way + that is valid for both reactor and pulsed instrumentation. + + + Name of instrument + + short name for instrument, perhaps the acronym + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index 9da6f78ce7..d6a3346af1 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -1,14 +1,14 @@ - + - - - Document an event of data processing, reconstruction, or analysis for this data. - + + Document an event of data processing, reconstruction, or analysis for this data. - - Name of the program used - + Name of the program used - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. - - Version of the program used - + Version of the program used - - Date and time of processing. - + Date and time of processing. - - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + diff --git a/base_classes/nyaml/NXaperture.yaml b/base_classes/nyaml/NXaperture.yaml index bc656d852f..e728c15505 100644 --- a/base_classes/nyaml/NXaperture.yaml +++ b/base_classes/nyaml/NXaperture.yaml @@ -27,11 +27,8 @@ NXaperture(NXobject): and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. - (NXpositioner): - doc: | - Stores the raw positions of aperture motors. (NXgeometry): - deprecated: + deprecated: | Use the field `depends_on` and :ref:`NXtransformations` to position the aperture and :ref:`NXoff_geometry` to describe its shape doc: | location and shape of aperture @@ -44,7 +41,7 @@ NXaperture(NXobject): * Some base classes do this much better * Such as where is the gap written? BLADE_GEOMETRY(NXgeometry): - deprecated: + deprecated: | Use :ref:`NXoff_geometry` instead to describe the shape of the aperture doc: | location and shape of each blade @@ -56,15 +53,6 @@ NXaperture(NXobject): description: doc: | Description of aperture - shape: - doc: | - Shape of the aperture. - enumeration: [straight slit, curved slit, pinhole, circle, square, hexagon, octagon, bladed, open, grid] - size(NX_NUMBER): - unit: NX_LENGTH - doc: | - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter (NXnote): doc: | describe any additional information in a note* @@ -81,7 +69,7 @@ NXaperture(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3d11dee2b9b432b9dc666bb1ee41813c2ef3f76f315ae2c752d74a70c969d503 +# 106da0bc8d01d7fed9a85f73a915d0b6815b83cdaa4d84b76228767be1543c00 # # # +# +# +# Collection of the components of the instrument or beamline. +# +# Template of instrument descriptions comprising various beamline components. +# Each component will also be a NeXus group defined by its distance from the +# sample. Negative distances represent beamline components that are before the +# sample while positive distances represent components that are after the sample. +# This device allows the unique identification of beamline components in a way +# that is valid for both reactor and pulsed instrumentation. +# +# +# Name of instrument +# +# short name for instrument, perhaps the acronym +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# .. 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/nyaml/NXprocess.yaml b/base_classes/nyaml/NXprocess.yaml index 6ea8529d13..d2650c0e4c 100644 --- a/base_classes/nyaml/NXprocess.yaml +++ b/base_classes/nyaml/NXprocess.yaml @@ -17,15 +17,6 @@ NXprocess(NXobject): date(NX_DATE_TIME): doc: | Date and time of processing. - (NXregistration): - doc: | - Describes the operations of image registration - (NXdistortion): - doc: | - Describes the operations of image distortion correction - (NXcalibration): - doc: | - Describes the operations of calibration procedures, e.g. axis calibrations. (NXnote): doc: | The note will contain information about how the data was processed @@ -118,4 +109,3 @@ NXprocess(NXobject): # # # - From 6c537cd6bfa7d43779d1f9b56cefabaeef4425f8 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Jun 2023 11:16:12 +0200 Subject: [PATCH 170/203] Black formatting --- dev_tools/docs/nxdl.py | 38 +++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 3aff9e52a2..b20a99dd5c 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -588,7 +588,9 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): # target = hTarget.replace(".. _", "").replace(":\n", "") # TODO: https://github.com/nexusformat/definitions/issues/1057 self._print(f"{indent}{hTarget}") - self._print(f"{indent}**{name}**: {optional_text}{typ} {self.get_first_parent_ref(f'{parent_path}/{name}', 'group')}\n") + self._print( + f"{indent}**{name}**: {optional_text}{typ} {self.get_first_parent_ref(f'{parent_path}/{name}', 'group')}\n" + ) self._print_if_deprecated(ns, node, indent + self._INDENTATION_UNIT) self._print_doc(indent + self._INDENTATION_UNIT, ns, node) @@ -629,23 +631,37 @@ def _print(self, *args, end="\n"): self._rst_lines.append(" ".join(args) + end) def get_first_parent_ref(self, path, tag): - nx_name = path[1:path.find("/", 1)] - path = path[path.find("/", 1):] - + nx_name = path[1 : path.find("/", 1)] + path = path[path.find("/", 1) :] + parents = pynxtools_nxlib.get_inherited_nodes(path, nx_name)[2] if len(parents) > 1: parent = parents[1] - parent_path = parent_display_name = parent.attrib['nxdlpath'] + parent_path = parent_display_name = parent.attrib["nxdlpath"] parent_path_segments = parent_path[1:].split("/") - parent_def_name = parent.attrib["nxdlbase"][parent.attrib["nxdlbase"].rfind("/"):parent.attrib["nxdlbase"].rfind(".nxdl")] + parent_def_name = parent.attrib["nxdlbase"][ + parent.attrib["nxdlbase"] + .rfind("/") : parent.attrib["nxdlbase"] + .rfind(".nxdl") + ] # Case where the first parent is a base_class - if parent_path_segments[0] == '': + if parent_path_segments[0] == "": return f":ref:`<{parent_def_name[1:]}> <{parent_def_name[1:]}>`" - parent_display_name = f"{parent_def_name[1:]}/.../{parent_path_segments[-1]}" if len(parent_path_segments)>1 else f"{parent_def_name[1:]}/{parent_path_segments[-1]}" + parent_display_name = ( + f"{parent_def_name[1:]}/.../{parent_path_segments[-1]}" + if len(parent_path_segments) > 1 + else f"{parent_def_name[1:]}/{parent_path_segments[-1]}" + ) if tag == "attribute": pos_of_right_slash = parent_path.rfind("/") - parent_path = parent_path[:pos_of_right_slash] + "@" + parent_path[pos_of_right_slash + 1:] - return f":ref:`<{parent_display_name}> <{parent_def_name}{parent_path}-{tag}>`" - return "" \ No newline at end of file + parent_path = ( + parent_path[:pos_of_right_slash] + + "@" + + parent_path[pos_of_right_slash + 1 :] + ) + return ( + f":ref:`<{parent_display_name}> <{parent_def_name}{parent_path}-{tag}>`" + ) + return "" From 673d10f8a95316670574c77ba51be2cabeb53cb6 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 14 Jun 2023 11:23:23 +0200 Subject: [PATCH 171/203] Removes unused import --- dev_tools/docs/nxdl.py | 1 - 1 file changed, 1 deletion(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index b20a99dd5c..9fee58a9c8 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -7,7 +7,6 @@ from typing import Optional import lxml -from pynxtools.dataconverter import helpers as pynxtools_helpers from pynxtools.nexus import nexus as pynxtools_nxlib from ..globals.directories import get_nxdl_root From 47a094a3ecfb606e185c56abe4def4b653bbbebd Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 11:32:21 +0200 Subject: [PATCH 172/203] Generating nxdl.xml from contributed definitions nyaml. --- contributed_definitions/NXaberration.nxdl.xml | 2 +- .../NXaberration_model.nxdl.xml | 4 +- .../NXaberration_model_ceos.nxdl.xml | 4 +- .../NXaberration_model_nion.nxdl.xml | 4 +- .../NXaperture_em.nxdl.xml | 3 +- .../NXapm_input_ranging.nxdl.xml | 3 +- .../NXapm_input_reconstruction.nxdl.xml | 3 +- .../NXapm_paraprobe_config_clusterer.nxdl.xml | 2 +- .../NXapm_paraprobe_config_distancer.nxdl.xml | 2 +- ...Xapm_paraprobe_config_intersector.nxdl.xml | 2 +- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 5 +- .../NXapm_paraprobe_config_ranger.nxdl.xml | 2 +- .../NXapm_paraprobe_config_selector.nxdl.xml | 2 +- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 2 +- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 2 +- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 2 +- ...NXapm_paraprobe_config_transcoder.nxdl.xml | 2 +- ...NXapm_paraprobe_results_clusterer.nxdl.xml | 2 +- ...NXapm_paraprobe_results_distancer.nxdl.xml | 2 +- ...apm_paraprobe_results_intersector.nxdl.xml | 2 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 2 +- .../NXapm_paraprobe_results_ranger.nxdl.xml | 2 +- .../NXapm_paraprobe_results_selector.nxdl.xml | 2 +- .../NXapm_paraprobe_results_spatstat.nxdl.xml | 2 +- .../NXapm_paraprobe_results_surfacer.nxdl.xml | 2 +- ...apm_paraprobe_results_tessellator.nxdl.xml | 2 +- ...Xapm_paraprobe_results_transcoder.nxdl.xml | 2 +- .../NXcalibration.nxdl.xml | 6 +- .../NXcg_alpha_complex.nxdl.xml | 33 ++++++++- .../NXcg_cylinder_set.nxdl.xml | 14 +++- .../NXcg_ellipsoid_set.nxdl.xml | 5 +- .../NXcg_face_list_data_structure.nxdl.xml | 5 +- .../NXcg_geodesic_mesh.nxdl.xml | 3 +- contributed_definitions/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- .../NXcg_hexahedron_set.nxdl.xml | 13 +++- .../NXcg_marching_cubes.nxdl.xml | 5 +- .../NXcg_parallelogram_set.nxdl.xml | 8 ++- .../NXcg_point_set.nxdl.xml | 2 +- .../NXcg_polygon_set.nxdl.xml | 71 ++++++++++++++++++- .../NXcg_polyhedron_set.nxdl.xml | 25 ++++++- .../NXcg_polyline_set.nxdl.xml | 2 +- contributed_definitions/NXcg_roi_set.nxdl.xml | 5 +- .../NXcg_sphere_set.nxdl.xml | 4 +- .../NXcg_tetrahedron_set.nxdl.xml | 24 ++++++- .../NXcg_triangle_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 15 +++- .../NXcg_unit_normal_set.nxdl.xml | 5 +- contributed_definitions/NXchamber.nxdl.xml | 2 +- .../NXchemical_composition.nxdl.xml | 2 +- contributed_definitions/NXclustering.nxdl.xml | 2 +- .../NXcollectioncolumn.nxdl.xml | 6 +- .../NXcoordinate_system_set.nxdl.xml | 56 ++++++++++++++- .../NXcorrector_cs.nxdl.xml | 5 +- .../NXcs_computer.nxdl.xml | 4 +- contributed_definitions/NXcs_cpu.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 2 +- contributed_definitions/NXcs_gpu.nxdl.xml | 2 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 4 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 3 +- contributed_definitions/NXcs_prng.nxdl.xml | 5 +- .../NXcs_profiling.nxdl.xml | 2 +- .../NXcs_profiling_event.nxdl.xml | 2 +- contributed_definitions/NXdeflector.nxdl.xml | 4 +- .../NXdelocalization.nxdl.xml | 18 ++++- contributed_definitions/NXdispersion.nxdl.xml | 2 +- .../NXdispersion_function.nxdl.xml | 2 +- .../NXdispersion_repeated_parameter.nxdl.xml | 2 +- .../NXdispersion_single_parameter.nxdl.xml | 2 +- .../NXdispersion_table.nxdl.xml | 2 +- .../NXdispersive_material.nxdl.xml | 2 +- contributed_definitions/NXdistortion.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 2 +- .../NXelectronanalyser.nxdl.xml | 10 +-- contributed_definitions/NXem.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 5 +- .../NXem_ebsd_conventions.nxdl.xml | 15 +++- ...NXem_ebsd_crystal_structure_model.nxdl.xml | 16 ++++- .../NXenergydispersion.nxdl.xml | 6 +- .../NXevent_data_em.nxdl.xml | 2 +- .../NXevent_data_em_set.nxdl.xml | 2 +- .../NXfabrication.nxdl.xml | 3 +- .../NXgraph_edge_set.nxdl.xml | 2 +- .../NXgraph_node_set.nxdl.xml | 2 +- contributed_definitions/NXgraph_root.nxdl.xml | 3 +- .../NXibeam_column.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 2 +- .../NXimage_set_em_adf.nxdl.xml | 7 +- .../NXimage_set_em_kikuchi.nxdl.xml | 14 +++- contributed_definitions/NXion.nxdl.xml | 2 +- contributed_definitions/NXisocontour.nxdl.xml | 2 +- contributed_definitions/NXiv_temp.nxdl.xml | 2 +- ...ctro_chemo_mechanical_preparation.nxdl.xml | 2 +- .../NXlab_sample_mounting.nxdl.xml | 19 ++++- contributed_definitions/NXlens_em.nxdl.xml | 2 +- .../NXmanipulator.nxdl.xml | 6 +- .../NXmatch_filter.nxdl.xml | 2 +- contributed_definitions/NXmpes.nxdl.xml | 17 ++++- contributed_definitions/NXms.nxdl.xml | 2 +- .../NXms_feature_set.nxdl.xml | 2 +- .../NXms_score_config.nxdl.xml | 14 ++-- .../NXms_score_results.nxdl.xml | 8 ++- .../NXms_snapshot.nxdl.xml | 5 +- .../NXms_snapshot_set.nxdl.xml | 8 ++- .../NXoptical_system_em.nxdl.xml | 2 +- .../NXorientation_set.nxdl.xml | 2 +- contributed_definitions/NXpeak.nxdl.xml | 2 +- contributed_definitions/NXpid.nxdl.xml | 2 +- contributed_definitions/NXprogram.nxdl.xml | 2 +- contributed_definitions/NXpump.nxdl.xml | 5 +- contributed_definitions/NXreflectron.nxdl.xml | 2 +- .../NXregistration.nxdl.xml | 4 +- contributed_definitions/NXscanbox_em.nxdl.xml | 8 ++- .../NXsensor_scan.nxdl.xml | 5 +- .../NXsimilarity_grouping.nxdl.xml | 2 +- .../NXslip_system_set.nxdl.xml | 10 ++- .../NXspatial_filter.nxdl.xml | 8 ++- .../NXspectrum_set.nxdl.xml | 2 +- .../NXspectrum_set_em_eels.nxdl.xml | 11 ++- .../NXspectrum_set_em_xray.nxdl.xml | 21 +++++- .../NXspindispersion.nxdl.xml | 6 +- contributed_definitions/NXstage_lab.nxdl.xml | 17 ++++- .../NXsubsampling_filter.nxdl.xml | 2 +- .../NXtransmission.nxdl.xml | 12 +++- 125 files changed, 611 insertions(+), 162 deletions(-) diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml index a26f988e43..be1835cc39 100644 --- a/contributed_definitions/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index 64c1c012e4..42a2a7eab1 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -25,7 +25,7 @@ Models for aberrations of electro-magnetic lenses in electron microscopy. - See `S. J. Pennycock and P. D. Nellist <https':'//doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how to convert from the NION to the CEOS definitions. diff --git a/contributed_definitions/NXaberration_model_ceos.nxdl.xml b/contributed_definitions/NXaberration_model_ceos.nxdl.xml index 20bf7e2a06..de6804487a 100644 --- a/contributed_definitions/NXaberration_model_ceos.nxdl.xml +++ b/contributed_definitions/NXaberration_model_ceos.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -25,7 +25,7 @@ CEOS definitions/model for aberrations of electro-magnetic lenses. - See `S. J. Pennycock and P. D. Nellist <https':'//doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how to convert from the NION to the CEOS definitions. diff --git a/contributed_definitions/NXaberration_model_nion.nxdl.xml b/contributed_definitions/NXaberration_model_nion.nxdl.xml index bd1dc9a7d9..e88e5c0f06 100644 --- a/contributed_definitions/NXaberration_model_nion.nxdl.xml +++ b/contributed_definitions/NXaberration_model_nion.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -25,7 +25,7 @@ NION definitions/model for aberrations of electro-magnetic lenses. - See `S. J. Pennycock and P. D. Nellist <https':'//doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how to convert from the NION to the CEOS definitions. diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 1c3d7a3a0e..a382ec143b 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -22,6 +22,7 @@ # For further information, see http://www.nexusformat.org --> + Details of an individual aperture for beams in electron microscopy. diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml index 2f44bec9a8..b8561c5589 100644 --- a/contributed_definitions/NXapm_input_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_input_ranging.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + Metadata to ranging definitions made for a dataset in atom probe microscopy. diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml index c6d9401be5..07275cd254 100644 --- a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml index ffebc158a5..c1a766d5a3 100644 --- a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml index dfa6181a6c..1d7b252085 100644 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml index 00e5b4c730..f8de608ff4 100644 --- a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml index 5a2c720e31..9b2564cf71 100644 --- a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -316,7 +316,8 @@ plus another process packing all your chromium delocalization and isosurfaces--> - Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`. + Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot + \sigma_z`. diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml index 4b3d3d633a..903fd73d9b 100644 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml index 6e8583ece5..41d049ef07 100644 --- a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml index 3db0b7f1fb..d9e2b26f0e 100644 --- a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml index 8ec33204e2..e421eaaaa0 100644 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml index 3f846cac1c..24f2202166 100644 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml index e230219d3b..fb4973f03b 100644 --- a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml index d2398a8d90..74b8a6133d 100644 --- a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml index 20035c0486..5edb36e604 100644 --- a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml index 7daf7e57b0..efa4b5baeb 100644 --- a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index 11f52ab6da..1e5015b5d1 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml index e0b9b736d6..9840e724c3 100644 --- a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml index 7211093546..791323a938 100644 --- a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml index 643e18a695..674afbe853 100644 --- a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml index 421670cdae..0e24bccc8b 100644 --- a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml index 3fcb3d2be2..dc2bf91198 100644 --- a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml index 93e2363ba0..cdab497064 100644 --- a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 86a0453c7e..422c486083 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -24,7 +24,7 @@ - The symbols used in the schema to specify e.g. dimensions of arrays + The symbols used in the schema to specify e.g. dimensions of arrays @@ -43,7 +43,7 @@ - Subclass of NXprocess to describe post-processing calibrations. + Subclass of NXprocess to describe post-processing calibrations. diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml index a7e2d7828c..b1def2e9a5 100644 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -22,6 +22,9 @@ # For further information, see http://www.nexusformat.org --> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -31,6 +34,7 @@ The dimensionality of the alpha shape, for now 2 or 3. + The number of edges. @@ -84,6 +88,7 @@ Specifically when computed with the CGAL, the mode specifies if singular faces are removed (regularized) of the alpha complex. + @@ -101,11 +106,24 @@ in the case of alpha_wrapping. + Point cloud for which the alpha shape or wrapping should be computed. + Triangle soup for which the alpha wrapping should be computed. @@ -116,5 +134,18 @@ A meshed representation of the resulting shape. + + diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index e71adff6fd..ae36e40bf4 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,8 @@ # # For further information, see http://www.nexusformat.org --> + @@ -86,6 +88,10 @@ + @@ -117,6 +123,7 @@ which the positions and directions are interpretable. + Interior volume of each cylinder @@ -150,4 +157,9 @@ + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index bcc121fe9c..6d0e1886e4 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -102,6 +103,7 @@ which the positions and directions are interpretable. + Are the ellipsoids closed or hollow? @@ -120,6 +122,7 @@ + Direction unit vector which points along the largest half-axes. diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 270582a939..6118e2ea03 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -85,6 +86,7 @@ Dimensionality. + Array which specifies of how many vertices each face is built. @@ -211,6 +213,7 @@ + If true indicates that the vertices are all placed at different positions diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index 2ad1e03bb8..29f4fef9d0 100644 --- a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -53,4 +53,5 @@ + diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index 2586709ef9..2893cf2a50 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index 0451f3cf86..fd003dfc68 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index f9ff489f56..a604913d9b 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,11 @@ # # For further information, see http://www.nexusformat.org --> + @@ -88,6 +93,7 @@ + A qualitative description of each hexahedron/cuboid/cube/box. @@ -203,22 +209,27 @@ + + + A simple approach to describe the entire set of hexahedra when the main intention is to store the shape of the hexahedra for visualization. + Disentangled representations of the mesh of specific hexahedra. + Disentangled representation of the planar graph that each hexahedron represents. Such a description simplifies topological processing diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index 25a58d5b53..4f3f1e008c 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -68,4 +68,7 @@ + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index 2486ad7ad8..2fadb8df7f 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -79,6 +79,7 @@ + A qualitative description of each parallelogram/rectangle/square/box. @@ -159,19 +160,24 @@ + + + A simple approach to describe the entire set of parallelograms when the main intention is to store the shape of the parallelograms for visualization. + Disentangled representations of the mesh of specific parallelograms. + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml index 29863ab4ba..78367f5ae2 100644 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index efa99c5d1c..6bf48cad49 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -22,6 +22,9 @@ # For further information, see http://www.nexusformat.org --> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -36,12 +39,14 @@ The cardinality of the set, i.e. the number of polygons. + The total number of vertices when visiting every polygon. + Computational geometry description of a set of polygons in Euclidean space. @@ -95,14 +100,18 @@ + A simple approach to describe the entire set of polygons when the main intention is to store the shape of the polygons for visualization. + + @@ -153,4 +162,64 @@ Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 5525812aa7..57fffc68db 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,15 @@ # # For further information, see http://www.nexusformat.org --> + @@ -61,6 +70,7 @@ + Interior volume @@ -126,6 +136,7 @@ which the qualifiers and mesh data are interpretable. + Integer which specifies the first index to be used for distinguishing @@ -150,22 +161,34 @@ + + A simple approach to describe the entire set of polyhedra when the main intention is to store the shape of the polyhedra for visualization. + Disentangled representations of the mesh of specific polyhedron. + Disentangled representation of the planar graph that each polyhedron represents. Such a description simplifies topological processing or analyses of mesh primitive operations and neighborhood queries. + diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index bda0b73eaf..5235f93211 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml index 96b299aa8d..13c2608cd4 100644 --- a/contributed_definitions/NXcg_roi_set.nxdl.xml +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -34,4 +35,6 @@ + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 80f53d17e4..716715f892 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,7 @@ # # For further information, see http://www.nexusformat.org --> + @@ -98,6 +99,7 @@ which the positions and directions are interpretable. + Are the spheres closed or hollow? diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 4cae3e4229..62796fd9f1 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,11 @@ # # For further information, see http://www.nexusformat.org --> + @@ -57,6 +62,7 @@ + Interior volume @@ -107,6 +113,18 @@ which the qualifiers and mesh data are interpretable. + Integer which specifies the first index to be used for distinguishing @@ -131,7 +149,9 @@ + + A simple approach to describe the entire set of tetrahedra when the main intention is to store the shape of the tetrahedra for visualization. @@ -139,11 +159,13 @@ + Disentangled representations of the mesh of specific tetrahedra. + Disentangled representation of the planar graph that each tetrahedron represents. Such a description simplifies topological processing diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 8bf4467570..b6165ebc45 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -76,14 +76,18 @@ + A simple approach to describe the entire set of triangles when the main intention is to store the shape of the triangles for visualization. + + diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index 06210e334b..6b8adf5262 100644 --- a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -33,6 +33,19 @@ The mesh may be self-intersecting and have holes but the triangles must not be degenerated. + diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index cf2213b4ac..26b49c145a 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,9 @@ # # For further information, see http://www.nexusformat.org --> + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml index 795cbac192..fec3864684 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXchemical_composition.nxdl.xml b/contributed_definitions/NXchemical_composition.nxdl.xml index 6f1c2e6c80..fd92848709 100644 --- a/contributed_definitions/NXchemical_composition.nxdl.xml +++ b/contributed_definitions/NXchemical_composition.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml index 68ee6cca76..147c4baa1b 100644 --- a/contributed_definitions/NXclustering.nxdl.xml +++ b/contributed_definitions/NXclustering.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index c8bd717074..d2a5fb8fa5 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -23,8 +23,8 @@ --> - Subclass of NXelectronanalyser to describe the electron collection - column of a photoelectron analyser. + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index 17fc4368f6..7f32f0c7ed 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -57,6 +57,10 @@ 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: @@ -80,4 +84,54 @@ according to the descriptions in NXtransformations. + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index b7e5be8c41..c2e8f7c678 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -59,7 +59,8 @@ NEW ISSUE: following parameters of the these constants and how they are useful-- - Discouraged free-text field to add further details about the alignment procedure. + Discouraged free-text field to add further details about the alignment + procedure. diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index be45aa4453..4f05228e90 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -49,12 +49,14 @@ + 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). diff --git a/contributed_definitions/NXcs_cpu.nxdl.xml b/contributed_definitions/NXcs_cpu.nxdl.xml index 603c352ddd..13357448b3 100644 --- a/contributed_definitions/NXcs_cpu.nxdl.xml +++ b/contributed_definitions/NXcs_cpu.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 9256b02c88..0e1aec63c8 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml index 1bf1d91032..94adaf58ef 100644 --- a/contributed_definitions/NXcs_gpu.nxdl.xml +++ b/contributed_definitions/NXcs_gpu.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index aa1b2bd32f..294e033ffc 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -40,11 +40,13 @@ + Total amount of data which the medium can hold. + Given name to the I/O unit. diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 517fd99016..82bae62a9a 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index fc25da0a1a..b06478a53a 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -35,4 +35,5 @@ How much physical memory does the system provide. + diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml index 99bbcec883..f288e15092 100644 --- a/contributed_definitions/NXcs_prng.nxdl.xml +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -71,6 +71,7 @@ sequence of numbers it generates. + Number of initial draws from the PRNG which are discarded in an effort @@ -79,4 +80,6 @@ users should set the value to zero. + diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml index 3cf1cb9741..9e1e7798c6 100644 --- a/contributed_definitions/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 53b4854579..02c06b97d1 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml index f362abb3fd..f1774a1ba5 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -23,7 +23,7 @@ --> - Deflectors as they are used e.g. in an electron analyser. + Deflectors as they are used e.g. in an electron analyser. diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 7487e80c86..c5b8558746 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -65,6 +65,17 @@ Reference or link to the points which are delocalized on the grid. + The weighting model specifies how mark data are mapped to a weight per point. @@ -87,6 +98,11 @@ + A list of elements (via proton number) to consider for the atomic_decomposition diff --git a/contributed_definitions/NXdispersion.nxdl.xml b/contributed_definitions/NXdispersion.nxdl.xml index 6f73ea5afd..3351b27465 100644 --- a/contributed_definitions/NXdispersion.nxdl.xml +++ b/contributed_definitions/NXdispersion.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXdispersion_function.nxdl.xml b/contributed_definitions/NXdispersion_function.nxdl.xml index 7cd4a1ed2b..d056b35b08 100644 --- a/contributed_definitions/NXdispersion_function.nxdl.xml +++ b/contributed_definitions/NXdispersion_function.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml index 1f4527c848..e2b8dcfce9 100644 --- a/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml +++ b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml index 1a520d9613..f8c45ba098 100644 --- a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml +++ b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXdispersion_table.nxdl.xml b/contributed_definitions/NXdispersion_table.nxdl.xml index fd53463982..9cca5ae70d 100644 --- a/contributed_definitions/NXdispersion_table.nxdl.xml +++ b/contributed_definitions/NXdispersion_table.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index 5b41b10dca..452c384824 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml index b47f0aa734..08517614a8 100644 --- a/contributed_definitions/NXdistortion.nxdl.xml +++ b/contributed_definitions/NXdistortion.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -43,7 +43,7 @@ - Subclass of NXprocess to describe post-processing distortion correction. + Subclass of NXprocess to describe post-processing distortion correction. diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index a21a0fb47f..3ac4b15ae9 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 0ef6f51315..dfc4b339a6 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -28,18 +28,18 @@ - Number of fast axes (axes acquired symultaneously, without scanning - a physical quantity) + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) - Number of slow axes (axes acquired scanning a physical quantity) + Number of slow axes (axes acquired scanning a pysical quantity) - Subclass of NXinstrument to describe a photoelectron analyser. + Subclass of NXinstrument to describe a photoelectron analyser. diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index d322bc18e6..5b2eceb134 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 81164db97f..8b1160db3e 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -1921,5 +1921,6 @@ acquisition_speed(NX_FLOAT): Average number of patterns taken per second averaged over entire set. unit: NX_FREQUENCY acquisition_time(NX_FLOAT): - doc: Wall-clock time the acquisition took.--> + doc: Wall-clock time the acquisition took. + unit: NX_TIME--> diff --git a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml index 5a46756065..eedbd637d5 100644 --- a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -22,6 +22,7 @@ # For further information, see http://www.nexusformat.org --> + Conventions for rotations and coordinate systems to interpret EBSD data. @@ -31,6 +32,8 @@ and the use of file formats which do not store this information is the key unsolved problem. + Mathematical conventions and materials-science-specific conventions @@ -594,4 +597,14 @@ + diff --git a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml index 1205dd6c0c..48a053c833 100644 --- a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -50,6 +50,9 @@ used algorithm. More and more dictionary based alternatives are used. Either way both algorithm need a crystal structure model. + Identifier of an entry from crystallographic_database which was used @@ -62,6 +65,7 @@ crystallographic_database_identifier e.g. COD or others. + Crystallography unit cell parameters a, b, and c. @@ -70,6 +74,7 @@ + Crystallography unit cell parameters alpha, beta, and gamma. @@ -88,6 +93,7 @@ Crystallographic space group + True if space group is considered a centrosymmetric one. @@ -109,11 +115,13 @@ Laue group + Point group using International Notation. + Crystal system @@ -169,6 +177,8 @@ + Relative occupancy of the atom position. @@ -182,6 +192,7 @@ How many reflectors are distinguished. Value has to be n_hkl. + Miller indices :math:`(hkl)`. @@ -207,4 +218,7 @@ + diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index d408627e24..dd283a570b 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -23,8 +23,8 @@ --> - Subclass of NXelectronanalyser to describe the energy dispersion - section of a photoelectron analyser. + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 35e42c292d..2127e9b84d 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml index 1af6d974c0..c722947267 100644 --- a/contributed_definitions/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index 160cc82aa8..169959754a 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -47,4 +47,5 @@ functionalities which the component offers. + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index f9fd3d38dc..9a0ebfca19 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 94ccadcae1..afd24d2c69 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index 1ed723f89a..48fd163d8b 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -32,4 +32,5 @@ + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml index 0b25782f92..bbf4f13e06 100644 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml index 9426823645..9643dc936d 100644 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml index 56edf87880..66e439190c 100644 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -98,6 +98,11 @@ Annular dark field image stack. + Image intensity values. diff --git a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml index 8d052150de..7e395cee64 100644 --- a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml +++ b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -92,6 +92,7 @@ the spatial arrangement of the features, their individual properties, and (macroscopic) properties of materials. + Details how Kikuchi pattern were processed from the detector readings. @@ -144,12 +145,20 @@ + Kikuchi pattern intensity + Pattern are enumerated starting from 0 to n_p - 1. @@ -190,4 +199,7 @@ + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index fa8bba72ca..82cd91a10f 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index 4f5a59c7ef..bd81dc5f69 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index fee057bb33..7805ef4320 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml index a3777873d0..c34bb25db5 100644 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml index a60bf2ca4d..98dc044ce2 100644 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -31,6 +31,7 @@ Embedding of a sample in a medium for easing processability. + Version specifier of this application definition. @@ -48,6 +49,7 @@ + @@ -64,7 +66,7 @@ - Type of material. + Type of material. @@ -73,8 +75,19 @@ - Electrical conductivity of the embedding medium. + Electrical conductivity of the embedding medium. + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index fa46ddab30..2af323f4d5 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index ef2d40ad81..ad59e06205 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -23,8 +23,8 @@ --> - Extension of NXpositioner to include fields to describe the use of - manipulators in photoemission experiments. + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index e3d0b200dd..235169910d 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index ff13c5e93d..8a92c050ce 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -22,9 +22,13 @@ # For further information, see http://www.nexusformat.org --> + - This is the most general application definition for multidimensional - photoelectron spectroscopy. + This is the most general application definition for multidimensional + photoelectron spectroscopy. @@ -192,6 +196,7 @@ + Description of the detector type. @@ -323,6 +328,11 @@ other metadata file. In the case these are not available, free-text description. + In the case of a fixed temperature measurement this is the scalar temperature of @@ -339,6 +349,7 @@ + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 274838adeb..cd506fa214 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml index 07173292f1..a3ef27cbc6 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml index fafa5217d3..30573be7e9 100644 --- a/contributed_definitions/NXms_score_config.nxdl.xml +++ b/contributed_definitions/NXms_score_config.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -122,7 +122,8 @@ - Extent of each deformed grain along the x, y, and z direction when type is cuboidal. + Extent of each deformed grain along the x, y, and z direction when type is + cuboidal. @@ -149,7 +150,8 @@ - Path and name of the EBSD dataset from which to generate the starting microstructure. + Path and name of the EBSD dataset from which to generate the starting + microstructure. @@ -239,7 +241,8 @@ SecondOrderThermalExpCoeff--> - Model for the assumed mobility of grain boundaries with different disorientation. + Model for the assumed mobility of grain boundaries with different + disorientation. @@ -428,7 +431,8 @@ SecondOrderThermalExpCoeff--> - Into how many time steps should the real time interval be discretized upon during post-processing the results with the solitary unit modeling approach. + Into how many time steps should the real time interval be discretized upon + during post-processing the results with the solitary unit modeling approach. diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index d68f6f50c4..849373a882 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -509,7 +509,8 @@ snapshots--> - Grain identifier assigned to each nucleus which affected that cell in the recrystallization front. + Grain identifier assigned to each nucleus which affected that cell in the + recrystallization front. @@ -525,7 +526,8 @@ snapshots--> - Identifier of the OpenMP thread processing each cell in the recrystallization front. + Identifier of the OpenMP thread processing each cell in the recrystallization + front. diff --git a/contributed_definitions/NXms_snapshot.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml index f22be2334e..b2b0e26f18 100644 --- a/contributed_definitions/NXms_snapshot.nxdl.xml +++ b/contributed_definitions/NXms_snapshot.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -28,7 +28,8 @@ - Base class for data on the state of the microstructure at a given time/iteration. + Base class for data on the state of the microstructure at a given + time/iteration. diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml index 1f68d4dc86..4bc9269763 100644 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -52,5 +52,11 @@ or from 0 (referred to as C-, Python-style index notation) respectively. + + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index b36ebee14d..c925e2b35a 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXorientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml index 9183f4afbf..e8056053e0 100644 --- a/contributed_definitions/NXorientation_set.nxdl.xml +++ b/contributed_definitions/NXorientation_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index f723dd7e7c..f39d938c2c 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml index 01f72626e7..a2a98375e8 100644 --- a/contributed_definitions/NXpid.nxdl.xml +++ b/contributed_definitions/NXpid.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXprogram.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml index ca42571e62..2a2c10c03e 100644 --- a/contributed_definitions/NXprogram.nxdl.xml +++ b/contributed_definitions/NXprogram.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index b536259d6b..c1951c37f9 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -37,4 +37,7 @@ + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml index 5d0262be25..20d083590e 100644 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml index c725562743..0b328b1edc 100644 --- a/contributed_definitions/NXregistration.nxdl.xml +++ b/contributed_definitions/NXregistration.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -23,7 +23,7 @@ --> - Describes image registration procedures. + Describes image registration procedures. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 4bb59f8bf1..e341f65792 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -31,11 +31,17 @@ + + + diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index 24754f5e2d..21a8f317ab 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -130,7 +130,8 @@ - Plot of measured signal as a function of the timestamp of when they have been acquired is also possible. + Plot of measured signal as a function of the timestamp of when they have been + acquired is also possible. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index fba612d346..74cd0a1771 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXslip_system_set.nxdl.xml b/contributed_definitions/NXslip_system_set.nxdl.xml index 12f064ce2c..4e7d65b5c0 100644 --- a/contributed_definitions/NXslip_system_set.nxdl.xml +++ b/contributed_definitions/NXslip_system_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -35,7 +35,11 @@ Base class for describing a set of crystallographic slip systems. + + @@ -46,6 +50,9 @@ + Array of Miller indices which describe the crystallographic plane. @@ -55,6 +62,7 @@ + Array of Miller indices which describe the crystallographic direction. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 28d2e2c518..7a0680911d 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,9 @@ # # For further information, see http://www.nexusformat.org --> + @@ -43,7 +46,8 @@ - Spatial filter to filter entries within a region-of-interest based on their position. + Spatial filter to filter entries within a region-of-interest based on their + position. diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 0ee718b967..d75ef0778d 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml index dd6df8264d..43467f73f2 100644 --- a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -23,6 +23,7 @@ --> + Number of pixel per EELS mapping in the slow direction. @@ -104,6 +105,11 @@ + Pixel center of mass position y-coordinates. @@ -162,6 +168,9 @@ + Pixel center of mass energy loss bins. diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml index af0e8dccd4..fd19cb1dab 100644 --- a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -22,7 +22,10 @@ # For further information, see http://www.nexusformat.org --> + + Number of pixel per X-ray mapping in the slow direction @@ -97,6 +100,8 @@ + Collected X-ray spectra for all pixels of a rectangular region-of-interest. @@ -114,6 +119,11 @@ + @@ -160,6 +170,9 @@ + @@ -171,6 +184,7 @@ + Details about computational steps how peaks were indexed as elements. @@ -250,6 +264,7 @@ Human-readable, given name to the image. + Individual element-specific maps. Individual maps should @@ -266,6 +281,10 @@ + diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index 6539130950..2153672719 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -23,8 +23,8 @@ --> - Subclass of NXelectronanalyser to describe the spin filters in - photoemission experiments. + Subclass of NXelectronanalyser to describe the spin filters in photoemission + experiments. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 308a23cc6d..a55571e87b 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -147,6 +147,7 @@ Voltage applied to the stage to decelerate electrons. + The rotation, tilt and position of stage components can be specified @@ -155,4 +156,18 @@ + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index f19fa0c856..2253cbf9a4 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 8362cce7d0..c56878d6da 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,6 +21,8 @@ # # For further information, see http://www.nexusformat.org --> + @@ -38,7 +40,7 @@ - Application definition for transmission experiments + Application definition for transmission experiments @@ -86,6 +88,10 @@ definition rather than in this experiment description. + @@ -327,6 +333,8 @@ + Properties of the sample measured From e01bc507e5d678d60f99d776e327468dcb1a202e Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 14 Jun 2023 14:10:18 +0200 Subject: [PATCH 173/203] removing FAIRmat documentation --- .github/nexus-fairmat-gen-docs.yml | 94 ------ .github/workflows/nexus-fairmat-gen-docs.yml | 98 ------ __init__.py | 0 applications/__init__.py | 0 base_classes/__init__.py | 0 contributed_definitions/__init__.py | 0 manual/source/_static/blockquote.css.bak | 23 -- manual/source/_static/to_alabaster.css | 65 ---- manual/source/_static/to_rtd.css | 10 - manual/source/apm-structure.rst | 90 ----- manual/source/cgms-structure.rst | 284 ---------------- .../applications/canSAS/2012-minimum.png | Bin 8405 -> 0 bytes .../applications/canSAS/Q-geometry.jpg | Bin 12380 -> 0 bytes .../applications/canSAS/minimum-required.txt | 18 - manual/source/classes/applications/index.rst | 171 ---------- manual/source/classes/base_classes/index.rst | 252 -------------- .../container/ComplexContainerBeampath.png | Bin 7089 -> 0 bytes .../container/ComplexExampleContainer.png | Bin 25103 -> 0 bytes .../classes/contributed_definitions/index.rst | 319 ------------------ manual/source/ellipsometry-structure.rst | 157 --------- manual/source/em-structure.rst | 151 --------- manual/source/fairmat-cover.rst | 146 -------- manual/source/img/FAIRmat.png | Bin 114746 -> 0 bytes manual/source/laboratory-structure.rst | 25 -- manual/source/mpes-structure.rst | 111 ------ manual/source/nexus-index.rst | 20 -- manual/source/north-structure.rst | 264 --------------- manual/source/sed/entry-page.html | 6 - manual/source/stm-structure.rst | 32 -- manual/source/transport-structure.rst | 26 -- 30 files changed, 2362 deletions(-) delete mode 100644 .github/nexus-fairmat-gen-docs.yml delete mode 100644 .github/workflows/nexus-fairmat-gen-docs.yml delete mode 100644 __init__.py delete mode 100644 applications/__init__.py delete mode 100644 base_classes/__init__.py delete mode 100644 contributed_definitions/__init__.py delete mode 100644 manual/source/_static/blockquote.css.bak delete mode 100644 manual/source/_static/to_alabaster.css delete mode 100644 manual/source/_static/to_rtd.css delete mode 100644 manual/source/apm-structure.rst delete mode 100644 manual/source/cgms-structure.rst delete mode 100644 manual/source/classes/applications/canSAS/2012-minimum.png delete mode 100644 manual/source/classes/applications/canSAS/Q-geometry.jpg delete mode 100644 manual/source/classes/applications/canSAS/minimum-required.txt delete mode 100644 manual/source/classes/applications/index.rst delete mode 100644 manual/source/classes/base_classes/index.rst delete mode 100644 manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png delete mode 100644 manual/source/classes/contributed_definitions/container/ComplexExampleContainer.png delete mode 100644 manual/source/classes/contributed_definitions/index.rst delete mode 100644 manual/source/ellipsometry-structure.rst delete mode 100644 manual/source/em-structure.rst delete mode 100644 manual/source/fairmat-cover.rst delete mode 100644 manual/source/img/FAIRmat.png delete mode 100644 manual/source/laboratory-structure.rst delete mode 100644 manual/source/mpes-structure.rst delete mode 100644 manual/source/nexus-index.rst delete mode 100644 manual/source/north-structure.rst delete mode 100644 manual/source/sed/entry-page.html delete mode 100644 manual/source/stm-structure.rst delete mode 100644 manual/source/transport-structure.rst diff --git a/.github/nexus-fairmat-gen-docs.yml b/.github/nexus-fairmat-gen-docs.yml deleted file mode 100644 index 4d7e3813a4..0000000000 --- a/.github/nexus-fairmat-gen-docs.yml +++ /dev/null @@ -1,94 +0,0 @@ -name: Publish Sphinx Docs to GitHub Pages -on: [push] - -# see: https://sphinx-notes.github.io/pages/ -# see: https://github.com/marketplace/actions/sphinx-to-github-pages - -jobs: - - build: - runs-on: ubuntu-latest - - steps: - - name: Checkout - uses: actions/checkout@master - with: - fetch-depth: 0 # otherwise, you will fail to push refs to dest repo - - - name: Install build requirements - run: | - pip install -r requirements.txt - - name: Diagnostic - run: | - pip list - - name: Run the test suite - run: | - # stops publishing when known problems are found - python utils/test_suite.py - - name: Prepare for out-of-source Sphinx build - run: | - rm -rf ./build - mkdir ./build - python ./utils/build_preparation.py . ./build - - name: Diagnostic - run: | - ls -lAFGh - ls -lAFGh ./build - - name: Install LaTeX - run: | - sudo apt-get update -y && \ - sudo apt-get install -y \ - latexmk \ - texlive-latex-recommended \ - texlive-latex-extra \ - texlive-fonts-recommended - - name: Build impatient guide - run: | - make -C ./build/impatient-guide html latexpdf - ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf - # Copy to documentation source directory - cp \ - ./build/impatient-guide/_build/latex/NXImpatient.pdf \ - ./build/manual/source/_static/ - - name: Build PDF of manual - run: | - # expect next make (PDF) to fail (thus exit 0) - # since nexus.ind not found first time - # extra option for "levels nested too deeply" error - ( \ - make latexpdf \ - LATEXOPTS="--interaction=nonstopmode" \ - -C build/manual \ - || exit 0 \ - ) - # make that missing file - makeindex build/manual/build/latex/nexus.idx - # build the PDF, still a failure will be noted - # but we can ignore it without problem - ( \ - make latexpdf \ - LATEXOPTS="--interaction=nonstopmode" \ - -C build/manual \ - || exit 0\ - ) - # Copy to documentation source directory - cp \ - ./build/manual/build/latex/nexus.pdf \ - ./build/manual/source/_static/NeXusManual.pdf - - name: Include other PDFs - run: | - wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf - wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf - - name: Build (html) and Commit - uses: sphinx-notes/pages@master - with: - # path to conf.py directory - documentation_path: build/manual/source - - - name: Publish if refs/tags - # remove/comment next line to push right away - if: startsWith(github.ref, 'refs/tags') - uses: ad-m/github-push-action@master - with: - github_token: ${{ secrets.GITHUB_TOKEN }} - branch: gh-pages diff --git a/.github/workflows/nexus-fairmat-gen-docs.yml b/.github/workflows/nexus-fairmat-gen-docs.yml deleted file mode 100644 index 53c001e241..0000000000 --- a/.github/workflows/nexus-fairmat-gen-docs.yml +++ /dev/null @@ -1,98 +0,0 @@ -name: NeXus/FAIRmat-Experimental Sphinx Docs to GitHub Pages -on: - #push: - # branches: - # - fairmat - workflow_dispatch: - -# see: https://sphinx-notes.github.io/pages/ -# see: https://github.com/marketplace/actions/sphinx-to-github-pages - -jobs: - - build: - runs-on: ubuntu-latest - - steps: - - name: Checkout - uses: actions/checkout@fairmat - with: - fetch-depth: 0 # otherwise, you will fail to push refs to dest repo - - #- name: Install build requirements - # run: | - # pip install -r requirements.txt - #- name: Diagnostic - # run: | - # pip list - #- name: Run the test suite - # run: | - # # stops publishing when known problems are found - # python utils/test_suite.py - #- name: Prepare for out-of-source Sphinx build - # run: | - # rm -rf ./build - # mkdir ./build - # python ./utils/build_preparation.py . ./build - #- name: Diagnostic - # run: | - # ls -lAFGh - # ls -lAFGh ./build - #- name: Install LaTeX - # run: | - # sudo apt-get update -y && \ - # sudo apt-get install -y \ - # latexmk \ - # texlive-latex-recommended \ - # texlive-latex-extra \ - # texlive-fonts-recommended - #- name: Build impatient guide - # run: | - # make -C ./build/impatient-guide html latexpdf - # ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf - # # Copy to documentation source directory - # cp \ - # ./build/impatient-guide/_build/latex/NXImpatient.pdf \ - # ./build/manual/source/_static/ - #- name: Build PDF of manual - # run: | - # # expect next make (PDF) to fail (thus exit 0) - # # since nexus.ind not found first time - # # extra option for "levels nested too deeply" error - # ( \ - # make latexpdf \ - # LATEXOPTS="--interaction=nonstopmode" \ - # -C build/manual \ - # || exit 0 \ - # ) - # # make that missing file - # makeindex build/manual/build/latex/nexus.idx - # # build the PDF, still a failure will be noted - # # but we can ignore it without problem - # ( \ - # make latexpdf \ - # LATEXOPTS="--interaction=nonstopmode" \ - # -C build/manual \ - # || exit 0\ - # ) - # # Copy to documentation source directory - # cp \ - # ./build/manual/build/latex/nexus.pdf \ - # ./build/manual/source/_static/NeXusManual.pdf - #- name: Include other PDFs - # run: | - # wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf - # wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf - #- name: Build (html) and Commit - # uses: sphinx-notes/pages@master - # with: - # # path to conf.py directory - # documentation_path: build/manual/source - - - name: Publish if refs/tags - # remove/comment next line to push right away - if: startsWith(github.ref, 'refs/tags') - uses: ad-m/github-push-action@master - with: - github_token: ${{ secrets.GITHUB_TOKEN }} - branch: gh-pages diff --git a/__init__.py b/__init__.py deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/applications/__init__.py b/applications/__init__.py deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/base_classes/__init__.py b/base_classes/__init__.py deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/contributed_definitions/__init__.py b/contributed_definitions/__init__.py deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/manual/source/_static/blockquote.css.bak b/manual/source/_static/blockquote.css.bak deleted file mode 100644 index 4ce6e9b98f..0000000000 --- a/manual/source/_static/blockquote.css.bak +++ /dev/null @@ -1,23 +0,0 @@ -/* - * blockquote.css - * ~~~~~~~~~~~~~~~ - * - * custom Sphinx stylesheet -- define margins in blockquotes with NXDL documentation - * - * :see: http://stackoverflow.com/questions/23462494/how-to-add-custom-css-file - * - */ - -/* do NOT import, causes sidebar to disappear, see issue 341 -@import url("basic.css"); -*/ - -/* -- page layout ----------------------------------------------------------- */ - -/* github issue 341: nicer to solve this just for NXDL documentation files - * but this works for now - */ - -blockquote { - margin-right: 100px; -} diff --git a/manual/source/_static/to_alabaster.css b/manual/source/_static/to_alabaster.css deleted file mode 100644 index 32ccc19a69..0000000000 --- a/manual/source/_static/to_alabaster.css +++ /dev/null @@ -1,65 +0,0 @@ -/* Theme override commands to control the html aspect in alabaster sphinx theme */ - -/* Override sidebar background color default (#FFFFFF) */ -.sphinxsidebar { - background: #005F73 !important; - } - - /* Control logo positioning */ -.sphinxsidebarwrapper p.logo { - margin-top: -8px !important; - margin-bottom: -8px !important; - text-align: center !important; -} - -/* Control sidebar headers (non clickable)*/ -.sphinxsidebarwrapper h3 { - font-size: 18pt !important; -} - -/* Control logo name string */ -.sphinxsidebarwrapper h1.logo { - margin-top: 0px !important; - font-size: 21pt !important; - margin-bottom: 10px !important; -} - -/* Control TOC tree top level links */ -.sphinxsidebar ul li.toctree-l1 > a { - font-size: 11pt !important; - line-height: 1.8 !important; -} - -/* Control TOC tree second level links */ -.sphinxsidebar ul li.toctree-l2 > a { - font-size: 10pt !important; - line-height: 1.8 !important; -} - -/* Control quick search bar */ -.sphinxsidebar input { - margin-top: 5px !important; - margin-bottom: 12px !important; -} - -/* Control quick search bar wrapper, nasty alignment with the google search bar */ -.sphinxsidebar div.searchformwrapper { - width: 209px !important; - align-self: center !important; - margin-left: 3px !important; -} - -/* Control text blurb explaining the project under the logo name */ -.sphinxsidebarwrapper p.blurb { - margin-top: 10px !important; - margin-bottom: 20px !important; -} - -/* Slightly increase the padding in the body */ -.bodywrapper div.body { - padding: 0 45px 0 45px !important; -} - -.body h1 { - margin-bottom: 50px !important; -} \ No newline at end of file diff --git a/manual/source/_static/to_rtd.css b/manual/source/_static/to_rtd.css deleted file mode 100644 index 0b69475425..0000000000 --- a/manual/source/_static/to_rtd.css +++ /dev/null @@ -1,10 +0,0 @@ -/* Theme override commands to control the html aspect in read the docs sphinx theme*/ - -/* Sidebar header (and topbar for mobile) */ -.wy-side-nav-search, .wy-nav-top { - background: #FF331C; - } -/* Sidebar */ -.wy-nav-side { - background: #005F73; - } \ No newline at end of file diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst deleted file mode 100644 index 11ef11f39b..0000000000 --- a/manual/source/apm-structure.rst +++ /dev/null @@ -1,90 +0,0 @@ -.. _Apm-Structure: - -========================= -B5: Atom-probe tomography -========================= - -.. index:: - IntroductionApm - ApmAppDef - ApmBC - ApmRemovedBC - ApmFurtherDefs - - -.. _IntroductionApm: - -Introduction -############## - -Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. - -.. _ApmAppDef: - -Application Definitions -####################### - -We created one new application definition whose intention is to serve both the description of atom probe tomography and field-ion microscopy measurements: - - :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). - -.. _ApmBC: - -Base Classes -############ - -We developed new base classes to structure the application definition into lab experiment and computational steps: - - :ref:`NXchamber`: - A base class to describe a component of the instrument which houses other components. A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. - - :ref:`NXcoordinate_system_set` - A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. - - :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. - - :ref:`NXpeak`: - A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. - - :ref:`NXpump`: - A base class to describe details about a pump in an instrument. - - :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. - - :ref:`NXreflectron`: - A base class to describe a kinetic-energy-sensitive filtering device for time of flight (ToF). - - :ref:`NXstage_lab`: - A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an - atom probe microscope or especially an electron microscope offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and one in an atom probe instrument, given that both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. - -Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually -a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. - -.. _ApmRemovedBC: - -.. Removed base classes -.. #################### - -.. _ApmFurtherDefs: - -Further data schemas for atom probe -################################### - -We have also developed a collection of application definition which exemplify how data post-processing workflows -with typical steps specific for atom probe and reconstruction of microstructural features can be described with NeXus. -These application definitions and base classes have an own section in the proposal which you can find on the landing -page by inspection the section on computational geometry and microstructures. - -Furthermore, we are working with the NFDI-MatWerk consortium to explore how tools from the FAIRmat and the NFDI-MatWerk -consortium can be used to describe research, data, metadata, and workflows. This work is organized in the infrastructure -use case IUC09 within the NFDI-MatWerk project. One example how NeXus could be used to describe processing of -atom probe data with a tool which was developed by Alaukik Saxena et al. at the Max-Planck-Institut für Eisenforschung GmbH -in Düsseldorf is available as the so-called :ref:`NXapm_composition_space_results` application definition. - diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst deleted file mode 100644 index e2d7c90368..0000000000 --- a/manual/source/cgms-structure.rst +++ /dev/null @@ -1,284 +0,0 @@ -.. _CgmsFeatures-Structure: - -========================= -Geometry & Microstructure -========================= - -.. index:: - IntroductionCgms - PhysicsCgms - CgmsAppDef - CgmsBC - IcmeMsModels - - -.. _IntroductionCgms: - -Introduction -############ - -The computational-geometry/microstructure-modeling-based part of the proposal -has the following aims: - -First, we would like to contribute to efforts on standardizing a controlled -vocabulary, definitions for these terms, and relations between the terms, for -computational-geometry-based descriptions of the microstructure of materials -and atomic configurations used when characterizing materials in experiments -and computer simulations. - -As far as NeXus is concerned, the here proposed distinct sets of simple -geometric primitives and shapes offer a complementary alternative to the -already existent base classes in NeXus for constructive solid geometry -such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name but a few. - -Second, we would like to explore with this proposal how we can harmonize terms -frequently used by materials scientists in the field of condensed-matter physics -with definitions and terms offer by the NOMAD MetaInfo description. - -Third, the proposal should yield a substantiated set of arguments and suggestions -how descriptors for the structure and atomic architecture of materials can be -harmonized. With this we especially would like to reach out and intensify the -cooperation between the materials-science-related consortia of the German -National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, -NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. - -.. The proposal reaches out to our colleagues in the materials engineering-based -.. consortia to document that there is value in discussing about controlled vocabulary. - -.. _PhysicsCgms: - -Physics background -################## -Microstructural features or crystal defects are spatial arrangements of atoms. -Given their specific atomic arrangement and composition, such features have -specific constraints on the degrees of freedom how atoms can arrange. This causes -that these defects have specific properties. -Provided well-defined coarse-graining procedures are used and regions-of-interest -and/or regions-of-applicability are defined, microstructural features are often -characterized and modelled to have associated thermodynamic descriptors. - -Another motivation for the proposal was the observation that frequently the design -of file formats for simulation software in the computational materials science especially -those tools at the interface between condensed-matter physics and materials engineering -are frequently reimplementing the wheel (at least partly) when it comes to decide how to store -e.g. atom and feature positions or shape of regions-of-interest, grids, crystals, -grains, precipitates, and dislocations. - -Maybe this is a historical burden given the large set of technical terms and jargon -in place, which then motivated pragmatic solutions that resulted in many research groups -have developed similar formats using similar descriptions. - -We see this work on base classes and application definitions not primarily an -effort to improve and extend NeXus for now. Rather this part of the proposal -is an effort to support activities in materials science to work towards -common terminology and using controlled vocabularies more frequently. -These are the foundation for more sophisticated thoughts about practically -useful ontologies. - -Defining crystal defects is a question of how to coarse-grain a given spatio- -temporal set of atoms, each having a nuclid type and position/trajectory. -In most cases, such a coarse-graining is an ill-posed task because different -mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric defect -can be described and be spatio-temporally constrained through a geometrical model -with defined geometric primitives and associated coarser-scale properties. - -The key motivation to such coarse-graining is to reduce the complexity of the -description. On the one hand to support visualization and scientific analyses - not only -of crystal defect arrangements. On the other hand it is the hope that using descriptors -at a coarser level, i.e. nanometer, micrometer, and larger, it is still possible -to find sufficiently accurate and precise descriptors which avoid that one has -to account for the dynamics of each atom to predict or understand the properties -of defects and their dynamics. - -Nevertheless, experience has shown that computational-geometry-based descriptions -when combined with hierarchical clustering/labeling methods, applied on set of -atoms and features turn out to yield useful descriptors. Examples include point, -line, surface defects, such as vacancies, solute cluster, dislocations, -disconnections, interfaces to name but a few. - -.. _CgmsBC: - -Base Classes -############ - -We propose the following base classes, starting with a set of descriptors -for frequently used shapes and geometric primitives: - - :ref:`NXcg_sphere_set`: - A description for a set of possibly dissimilar spheres. - - :ref:`NXcg_ellipsoid_set`: - A description for a set of possibly dissimilar rotated ellipsoids. - - :ref:`NXcg_cylinder_set`: - A description for a set of possibly dissimilar rotated cylinders. - - :ref:`NXcg_point_set`: - A collection of points with labels or mark data. - - :ref:`NXcg_polyline_set`: - A collection of lines and linearized segments. - - :ref:`NXcg_triangle_set`: - A collection (or soup) of triangles. - - :ref:`NXcg_parallelogram_set`: - A collection of possibly dissimilar parallelograms. - - :ref:`NXcg_triangulated_surface_mesh`: - A mesh of triangles. - - :ref:`NXcg_polygon_set`: - A collection (or soup) of polygons. - - :ref:`NXcg_polyhedron_set`: - A collection (or soup) of polyhedra. - - :ref:`NXcg_roi_set`: - A container to host a number of different types of primitives. - - :ref:`NXcg_tetrahedron_set`: - A collection (or soup) of tetrahedra. - - :ref:`NXcg_hexahedron_set`: - A collection (or soup) of hexahedra with capabilities to represent - also simpler (bounding) boxes for e.g. binary trees. - -These base classes make use of new base classes which describe data structures: - - :ref:`NXcg_face_list_data_structure`: - In essence, the usual way how polygon/polyhedra data are reported: - Via a list of vertices and faces with identifier and properties. - - :ref:`NXcg_half_edge_data_structure`: - A half-edge data structure is a useful complementary descriptor for - polygon/polyhedra which enables topological analyses and traversal - of the graph how polygons and polyhedra can alternatively be described. - - :ref:`NXcg_unit_normal_set`: - As an additional structuring element especially for meshes, well-documented - normal information is crucial for distance computations. - - :ref:`NXcg_geodesic_mesh`: - Geodesic meshes are useful for all applications when meshing the surface - of a sphere. - - :ref:`NXcg_alpha_complex`: - Alpha shapes and alpha wrappings, specifically the special case of the - convex hull, are frequently used geometrical models for describing - a boundary or edge to a set of geometric primitives. - -Furthermore, we propose a few base classes for operations when working with -discretized representations of material (area or volume) which can be useful -not only for stencil-based methods: - - :ref:`NXcg_grid`: - A grid of cells. - - :ref:`NXisocontour`: - A description for isocontour descriptions. - - :ref:`NXcg_marching_cubes`: - An approach to store metadata of a specific implementation of - the Marching Cubes algorithm, whose sensitivity to specific topological - configurations is known to result in different triangle soups. - - :ref:`NXdelocalization`: - An approach to document procedures whereby a scalar field - is smoothened in a controlled manner. - -Assuming that these base classes can serve as building blocks, we would like -to test with the proposal also how these base classes can be applied in base -classes for specific types of microstructural features and/or utility classes -to hold metadata for these features: - - :ref:`NXsimilarity_grouping`: - An alias for NXclustering. - - :ref:`NXclustering`: - A description for clustering of objects (such as atoms or features). - - :ref:`NXorientation_set`: - A set of rotations to describe the relative orientation of members of a set of features/objects. - - :ref:`NXslip_system_set`: - Metadata to a set of slip system/slip system family for - a given crystal structure. - - :ref:`NXms_feature_set`: - Generic base class to describe any nested set of features - of a microstructure at the continuum-, micron-, nano-scale, or - to represent a topology of molecules and atoms. - - :ref:`NXms_snapshot`: - A container to describe the state of microstructural features - at a given point in time. - - :ref:`NXms_snapshot_set`: - The corresponding class to hold a set of :ref:`NXms_snapshot` objects. - - :ref:`NXchemical_composition`: - (Chemical) composition of a sample or a set of things. - -Furthermore, we found that it can be useful to have a set of base classes with -which software documents it state and gives a summary for users about the performance -and elapsed time measured while processing data. These utility classes include: - - :ref:`NXprogram`: - A named and version of a program of library/component of a larger software framework. - - :ref:`NXcs_filter_boolean_mask`: - A boolean mask. - - :ref:`NXcs_prng`: - Metadata of a pseudo-random number generator (PRNG) algorithm. - - :ref:`NXcs_profiling`: - A structuring group holding a set of :ref:`NXcs_profiling_event` instances. - - :ref:`NXcs_profiling_event`: - Profiling/benchmark data to an event of - tracking an algorithm/computational step. - - :ref:`NXcs_computer`: - Metadata of a computer. - - :ref:`NXcs_cpu`: - Metadata of a central processing unit. - - :ref:`NXcs_gpu`: - Metadata of a graphical processing unit / accelerator. - - :ref:`NXcs_mm_sys`: - Metadata of the (main) memory (sub-)system. - - :ref:`NXcs_io_sys`: - Metadata of the input/output system. - - :ref:`NXcs_io_obj`: - Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. - -.. _IcmeMsModels: - -Application definitions for ICME models -####################################### - -To bridge to our colleagues from the NFDI-MatWerk and NFDI4Ing consortia we -have created an example how the proposed components of the nexus-fairmat-proposal -can be used to create data schemes for vanilla-type ICME microstructure models. -ICME is an abbreviation for Integrated Computational Materials Engineering, which -is a design strategy and workflow whereby physics-based modelling of microstructure -evolution at the mesoscopic scale is used to understand the relations between -the microstructure and technological relevant descriptors for the properties -of materials. - -To begin with we propose the following draft application definitions. - - :ref:`NXms`: - An application definition for arbitrary spatiotemporally resolved simulations. - - :ref:`NXms_score_config`: - A specific example how :ref:`NXapm_paraprobe_config_ranger` can be specialized for documenting the configuration of a computer simulation with the static recrystallization cellular automata model SCORE. - - :ref:`NXms_score_results`: - A specific example how :ref:`NXms` can be specialized for documenting results of computer simulations with the static recrystallization cellular automata model SCORE. diff --git a/manual/source/classes/applications/canSAS/2012-minimum.png b/manual/source/classes/applications/canSAS/2012-minimum.png deleted file mode 100644 index 84f7159d86f2c45ec4acef83cc5162a294bd5af9..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 8405 zcmbuF2T)UMxA%h_K}12CC_y+Py-V*XRiuN|(DX>JO793FO?oE+(tD5^S|Ez_CcQTi zr1u^Y?!!6nedo^oX1@E~`DU0**o3{Gz4ltq`u+baVH#?Rw{Ozigg_v-m7d9IK_J&y z!TXjQ*T5?*{tI~h6QU&d^o7T#tyzD4?GqH?uKMRlc&}{6rIWB z$`S%nA$tr~hHxNI(fhTCvT=={Sa`D zxfgaDNZ+%HkchBoHm|bI`aSKMMw@UA%3EF%kcDldmO6ByuG*8MAXf-Gs9ZSJhUq)pw>cZq|~%-uYw_vgQSh1 z0#u$cIlIzyTKi5HTTfV6wCC?r@#8iZL9sWV^=k~w*Q)g~rN<$h>32QDXQVqbeG|%J ziXuj8{h;H0lhpjszGM1&hyIt*zFl1;co6ihdcUZSo{osnk6t-gNZLwZdsa%(WI{$f zqEo{vT(AYxxAV69?Pjz|XuLmJzG zc!e3!+`rUsYNaIcO(dLh;37*bR95L@uI*d3agm3HGiJrbgvPX$+~x6oU4-3?@~WR2 zbJVtAPiEpdI6OYwJ?>QNjZzKe8ll|(y?weBRb6J?ce`&|3t3^0lUa^jj^hoRw3@qv z%xb8iaR%AN|LZ(Uh+)X+$L8r42?O5pM8_~Q<)@`oa|ez@b*OKky8WB z1OFGXS%r4RA5}wZTnueEY;+dckKPKxDSn!7^~QDQ#_=k(RuC|}Dr)UlolWTW5@qR8 zV=hzvNr=@?rSMjt$#c97;gzoUD~!B)Vt#v(UO5N_JyiMm3R?Aec)-=!o_bnKI8S#A z@hX@pD~{QoLOMl3u9AvxOuh2hV8C`DvrH0}X51~tA;(BUdB6lyLr(ZJW(Sk<2nfPM zJI5U33p%$*!|>Zs#whnS4*a_El+}sjC?P%MHH-4q!jxLK;n#}B^b$IaCE3e^7rQhO zG1vWwPp^-$9B0J5f9}=jb$06xVfZ9D{^g(kZYQMDN=x*=GHV4@>orp=SeIttzuU{Z z2m(@VcdRxrH)NZ6i$2R|vqd#XdC)`)r@{J24#ejC<}PZBCcmq9@s3H^y1hD%{q`t0 z?Hg_Y1JbrOnww#NcRywGZLIR62ix~)=v@U*8*`tHDylWWNOgksg8U7;{zJ~Mf&guKIA^)7Ldt6)QIguQg{#Y6w?NL%4g zr)_wUl>&o`;=aYM>lY1{4Bgtx24Y;twiEYq=ITVPo!_`tFvz|XN;~i=4Clyq-t0k4Rb_ zHifi8Xi9y@Narti#oT?5mP#IwR9H5X4L%=zj>~`H)*UH5n^O8X@aZnvE@0tZQN7|W zTHv9Fnb4D6^hiDl-T1&B1Wo$|rSF@EoL(C>S=*X3DRuLzSungo2XP8iN4Q0Pye*EJ zimg}#??q9DPF&+W1q1>0xp_L5En8f2302lC)6VTbcK2A)NePr3qHg7}343{Ypz=!2 znxbI~TL-VFbQ!#q^(b0i>)2x-W2&M?A2f(c9GcykD-$G~U0T|pUt zvLGHjfL2VM8&r(@dru9wMuf7PO!sxf1r1h^sgss-pl1E)&=j&OG@xCI^p$7M9?V3* zrEs~0h?89=hlkHif;W*<~?fEC+bl?W?GH<`bJq14(IQM>3mvLj|9t%vsk#@n- z7KE#6AdU#x;n-`Bgo`=c24vu_*`J^8xMq`P*w49pTr?$3=nvC*SsW93N4X&HFj9+Q zDzkB(2kp4f9$-@yE?H2=Q2rBC+2N?TE@(rZ#Z9GwoMYOHNQ3AQ$^D5j$43nINL{_0 zVO<-8;8N#SSLZf(_#~Zf?}LXPpn;!PFtm=U)-~QOH|(V|EWfFp*sRH(sMMj*&Ue?G z)1W37S#ko-zPWY^wpv3q9$mlYr)+t}I=#=P#snB%mG7S~^b*p4It$pcj7BFHbWV1dclGG+ zs;JVkTBK(kC%L`(Tz8C4wjH*|3fX3k4q3l^$dafuNo+JjmN7~IS@7vrF<%IJ$6xv# zce}G&B`@S8cSqNaXLSz(5qXNn$CFFI*)@bD6JB*&&>K#aw;hLsDz0UwNiP%o+u#yh zZSzwK>P_GJ_pBwArW?o!2=Uc!gc)D;A?T69arfh1aHd{c+*4dwQP@Df1c!Po9M*>~ zOrS4e#Zkkw9tRrD1UWu~mc6cZxZrsG#)|F%B^5g#<@8&YM?7zdisM~QoI@cC77Ue z;`wNI#o}W(3RctTR{N~Y+3w>V^V+|=CLjg2NN?o6aWKXM0$0v-hN^yQncSGh z&94W7VpF>$#_oZc&_A=ev7bxe5bduT({`3Ee;klF&3>vGSTAh{L8SGPsCwZnd(c%G zf5mC7N-|78pX?>Yacw$4yg}0eDA-itb5VxRv`(&F6_&0h2SP4tF3NAGGn*ym-trCt zF(Q%7nCzUgH<@Q7Y-##&V`ZW>O>I+hQ3GH3fop6- zLrnuH6Z8Bb4M$eZ=`>Nm>6sM{z8!j`9i* z1)aKmDUw7mB~7(kg~^+g%GXufWob_VB%yTYWxt^yuI(WN;tu)B?;RQWv7%#!4?q~n z^;<_D0Q7=PitK=PkOtl+y*2F*Sh|MO^M0n-g$5mViPb2qfl)%p=e5=QV1s9Jo&4Sz zvG0|hk1&;f@v3iFt;ts2F<$3$<=Tar6$*#qw`~@MZVEnBkvF+c*5~6y3R$7MRnrHS zVWcc~KY|bN+()lR(`&o8SdAm2Lj9Vze#=pkll|nqk(83Ak17{aPtteZp3O@&X{>LDs*lhk^?UIfWi0}ug>P0KoG(rir5eE&Yp zV?j8#X+vr6i*D^-gZrz1UwpK~IyD?`M3SJy{Xx5RT;1zc02KlPKzMKk%%hm%$)ABN z`x(#l;pk-RAt8WnrG)V~yYrRYz6+RGC~E;{$Mitso<~mJaOKGwDo#VmPG<9Xf2)+( zwQ}?Idj5;!4ALT%^?J0k^UzA9xX}LBc7nrPzBQKg%r6L1|4?-vL`aqC$e%=sfSyY6 zI4RHGNkJgqU?ExnR#R(LrpwA4%G6X;tBG7Bve&y*hNgEMEBV$@}vR5`j=A7O4p!Xj!z*@HQw=71t*^kTrmLj4jE23`MSd0tc zad>rb*5wa;0OzWJ-)D2}!&O6FhfJ@bt)(!-qe;407CmVu~)&_$%A(z{Yyyp?}X)qLS?|4l@8AVY$HPWN1(Tk z2ymP@cYnLrrO1+GS5<(ARQGSnfB0r6KwZjHD5=p1(rUaFMEAJdpPDcn<amO;PEjQ7-v6d9jqj|cm`efsr0aN@mw2;n5RkH8iAn(W!REh7{iyeK4HPgpJvo_{_h+}g z;7lx(#V}LWS{`27Is@Ie^DAG;p1xsnZ+TF$A#frrxb9HH8m)TyMgUS0QXHPwP1=NWQ1$62@ci^k>3i0WBe;%8$xl0)S z218OeV|saP#4D9y}l-BAQLB zilo}uX_=cJSCsR4?^2zb{pywYl*+OAq#r|N%X_nJ)CqLjbi%+e_VWCld%D)cK*CSx z)}ElqHG7`U0Z2c>2bA(;9zoBCrJJ;Es62RD-%v-1JFf{u+68rE*{ z_~|{gqu9~epDAATP&<8pg0$QOB_p?$AKlc{MC>kQTJC+>yVgz}Vd5bmFDfEpb(Y&` zaw0`0c@)8N?b>#H8`sO_5;YtPSsuG?u#Yh3sW@r6w7bGxWNzW9^!qcLCjUtFPVDju zyfuip$=A{Z3KrVxXD=LJ>-+X-Y3Bp+2-oUP3vPR@{p66|!^>;gZu+4q?d02v$(|l~ zC<&cs-|#R8_P2Vew$#4I)cNYY`(#~96#DbQp(OM^p7T8+zxIgas<$S&+T?k@$ek_o z4=@$5hCOQ*i3?RwR6PBnWO(*$vHy4Qna%N4%uZ&hPbV`GYW~&sH*aK=FD{7-&u2li zPIU^lne>p~&U}0<2UYm$x_^&*FUP)pi5Q(9r@rGvFWuGRVsLTk=fP&Z{OF<|jmE5% zyyGJjcJTSC6%q=TFxnw#2hSrJ7#_AgN=pcz-?Vq+$4#zRo``Yp?%k(x>yJd%MgO+F zMRIE{ErKr8X9UnL2LYjzqF79H^3IPRG0NPMB35vxmV%RUPHAYfsCCf5CkG!~eHk(R zh1+)RMcgdLVx)Nz51_eoWQ)jdd!*k>1Qiv9_fk7`sVu*k*nY)XboYp>-1i;3`U%=Q zPV?_Mt~Ik@agX~r>@YIU!_hCKQ+LVf;g_dY;rn~lN1Bf-RDaJm!sdT%__QDSVczYC zgW#+6>kOZ*+q+IyLG#DK{c&ZaT>nkF znGSw+rr#R_n+A*Px&e)8*poep{i=KK==&`y4tHnMqJ$`5$gz3<^u9fnmty9$>(q12 zl6fu%nMidE-B8ia(v=?Ued=xEv8*>B$?=PdMJ0HRvD>9vMYn}lYHdvn+b^zexguU7 z1C(3u)5^}g{gm7wo<<9HDMkU8N+PIxLY4V}@>#jao`F5k?J4kD%N?(i^!7_1l;Nqe zx0hGnuBKhp_a8rgXd6J|lMBR7+9dw|+%`7ZvB_l5p~ss`8uMnI+VnS?h=++TLTWC~)|Z@91pYu?b;?rGf6DI(LNW+ZvQkkDUKr zQqHotw1vU9K6DSto8~u7=qRgG)&u@7dd7VoxqZ1d)tiavb8(doxN&93{mJ`3+r8g> zB_K}IKE6Idcf*WkZ>FHY+X9jB1-yW1AzqP%b>;wQD~S33)-?X#SS>^u2zC5Oeu8JZY+V}9Xtpmw8+gV%Q@050lyAYUD+TM5Z)1j?EyOhy)6XadgPeY z#{28-3hliL2d@j9XN>^A13KMUX+DDb^^|lGfObK-zThmlodo3BzQR`gJgrC zhc6;Mlhh(4{bdAX;WN2VMip{$vh1=Epc9W3%Z=+TE;VDbzVK+o>V56de`S;HtAvr= zv{Exr8{IAjD#VDi;HEYkf1-hS)g~c+7%L+~t_sY}a-Q0(|H*DZW88Zs;I3}_dO6z5 z+uO;M+6CKn6*GYjzSvL?=p#`zQ7$3(Is25xcUR{N%BY5C#?@J!BX&2#ZWuJ#>7C3nrj{xlQpN|RQ;q@MnMi(j>l3c_gS7XfO!nrU`ba7wgILz z?UkyRn%9+-2TvVHu)n>@08e6B`-S$Kg28R0Z4b#F=38hFe#qYZzA2%Tfejri(o+Z0 zkCTq_{!OLAUqEqPXv%-ct}NmMI5cEkR92`HTr$!#s(^}pFsf?oth65{AisGfR{9vsqQ->0niRZ?0_#y%`kq1k=%WHzfIHY+x1nCqfJgpkgJ&aQe(%zbvohOX{0`pBm* z+&qvQffSpxO6t!2n^FP8a}~h! z?*qGI>lGZKP|&Gy@2DO4A3`DuazI;I!-f-}iGV2kQJzur(pf7XR`!4Qw7vVeu)6>d zyUC|1T!=D~$6~9>g2jSD6XckH8Vy%8cOSRwPg4k5^`Qsa*fq5Q3>-qv;sS#4F5Kd4 z*_fq1>|l9;^sfE>`SJh`y2bq-NG<)1jkty@&gDueBT zFL6h+Pf_rA^crLZoRy7_5)4QRx|j5%VVF{k^NF$ylUC};lqDD?jOCWU5wTT0PXlQP zo~P;=u(XAQ1r8LIN0^LAskx$=8AdG<^M=2Lgkyijv`$RH73W;)x+gj(P6@^z6kqLi zWMK}o4a@670Z@uCIc^_aD6F*i$mwD;LPVnp<imd7Cna2R0c|I+ zGcY^vRuL(k9tw)nPu?}G;roakIbpaxwibvO?W!W+2ndDhRcEn+2v8A|kb+%eVqFjc z*A6aW%py0>2S`-noLFC~BlnAXLD=apG!J?pn4@?}?#*e7L>(>I0KeCKZB2<>A?^2h zBG(g_ymxZwG&{4pyZSyF`9|cmP#TYEg9J!N-pzJusVnIis`_9L!-H}U3)L;wJtsV? zGNFb=_N|kWkRI>ugQS!8xoq8-IU0>FPkOHeHZ-Vz!{Z}a_igq+NP7ux(51vq-jU$- z1#fQicKr8wVecOLXb>^R}G^>!Lzset9V z)Y1jnCI^V||1*dDSCf#H!TZD}Ce)Bq);d}iuofO3W+PnF*g$na5=e+n6`K;<<#rM# z|GPu1Jo@L7KbG(UltRDZw###d{iYpMllbq@VHw}V6>fZU?$91vTtU~%l$7g=DA2DDqf@Bq;~dkQ~j z_X}1o9tojzaZ&;X?|?BvG(nqU`_H(RlN*wv|F#)N(r?&=Gq)7}eq9138Mdl@P@t9S z^6eTiy$P#bgqa#30F}+&3@Uf0q-P0o<&D^QV#b$oDW@r5?$uHku(2Z1BngzftDqPn z1cp7e8Lz!FL-PTk%C+LYV&JZT{Q%>!KB_$#HVFnrV22%QU{p%^Uekw<`~Vze6`&D$ z*CWBmFs)iOLXV3ik_0=m?|Ia0qg2RP@@LOz8U6|LmB=cYhVX7M{@&PeDO43mrXv@_ z#flo|b8A;AU5$4|seiHn(KY{M@hax=ab+=Gx}CIcG)L`&@EmSy(%##EwCW_6a&9ct zn!N#j;J*gd-!z~B{9w?rkeB4}y<@y%R5c|Ugr{FXgm-nF8Pe-^&j#e@Q(z}Uo@jtm zK<-ff7fL0wyzYPg->y^_O<1_# zgauy)h`IVMfY~*Z`6d=oQ-4AhZj;N(s_ARI`uE5?C8VNnTA3A!8Q!AEjq#SpWb4 diff --git a/manual/source/classes/applications/canSAS/Q-geometry.jpg b/manual/source/classes/applications/canSAS/Q-geometry.jpg deleted file mode 100644 index ecde6d88daf70a32c966d9d0cff0a05eacbf1108..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 12380 zcmb_?2Q-{r*Y=DaT|^(FNAE-@qD7C+2qFk$j5fMRltc@I(V|E11f#d;M0BGQLG&(4 zB=|hf`#$ggyx;$=@BhBF{xfUcYtK3NoPF-O_ugk;*V#8SH`f3MTRT^%jR(}lnc3w9 zvxkEnv#s3=sI#3dv%Q@Q+|I+@_qNm8G(&&*}*?!oNs;tpee?#ukd&clvb!wwF$cIF1$>;Y1rIJkJYARJs=nMDPJ0FsZ? zwQ+C&f3yG)mJdMl|KmbHSbhMazv%~IJ^4@HB>)5>LPBCfl0qVYn`HpGhN`+M00;yC zfVUsO%{)K}fQN&Nhl_)Uhl_`gk4HdAPDps?4&gmgGGcO?d$hDP_o%7q89A8f8Q4J7 z)XaR$Z1*|2dARAA_=WhnggCgkx&D|0h>wp?NI*zQNJz;=PfgGDziv0502BnkJ3urx zkQIPM0mP;N-gE;PZx@LTzy|)Y;D5H;Rbt~1U;*#k4x5kzfY{hTTx?w2d$>fne?Ao! zHV!TY9{ybxVMR(k>wBysZb4Mk`f=F=G;E?`l8=l{p1TLXLB%KJ)QnHCD;Xdhe6_U(KW*c1Q-z^Mi+GeLMDD=Q#89P4kQU|(aI zP5L=rZ7zF!AXb4RzqN{Shr{@^qjc$_R&>}UU)lR{p`({0*euQEq`l`@D`Obz7QPyi zyy^j&snYxpWdUuWsRdh}4!D!(X#AQHa@)9W5qXg7DoP3~$I7g1r)9mZ??ueAm%E92 zOy^QWxqRR2$hf*E2J=t`?Z=%n9RlpA4Y}^M#$nl~D?TV6RI^52>A<00#+R(*YyjLZ z(oz&AlVI^WXKY;P)q?J~8$iltyIfCOK+850X72`Y1K|0{I=yGV4Lh4SWtQu2ui5gO zJN$jJSL~1xW4udp1EBiBUF-B(WAX>;br~e};2I@5e@*B~9Z+_qR$tT{8yw(5BfTeK z^lgo@BkS6J^#&k?uzGY_W_@Xg>@gf08nfVt=$o7XGSwaxCzu(nt3Ne7WmPR}RXNp( zZWy>OG}GifV2=)n_SP9Gb%G!hJcn8*R)278Yu`)kj^Hi!R(72Or!nc2loiNfjJMyD zbzgK|$tX`SVWx+;_d}7s1ZU!JAG40Mv_G;uyCOKqqzX%c?~49XvZ)~cz2C>gvz|Xa z2g&hzBd~#={bsL(`?lz!9-ZYBL9#CS4&DPjtV+Y7Q8a z9|w)D$12j{c&a>%j@z8Oyu<&Y$F{5liS!fFwZs1IwdSt8r1b>})5N3qKKT^V`r4R9 zTs#3%czdCsc>G>j8Aw5nqx_J9O4On0SdJWS(VFwk{ahm-?Xj1`C+IOe%+Rz!>a!l$ zn6r|HQitZEd>D0kLoF!NL8kr@AbF0@f7)8ZHfLxm8^3Z@4}));8eY&I7pbz5dFYr2 z94Ci9L)U(9Fhp4xBcgtX6W}bCY%fnZ-iKdRK?m$&V-7h2KPH=0>ETxv)+H9v=p7Vh zeL&fBK_|)RN)9UeFHD)0S+bPpSx$aZL50I|;oJOUO|}q7FOnVQi~A(=)W2=bbQNAO z=WAlr)2hdHfTRrUSlE)h+AuotO!!*sfhLoxGi#O@WKu6l$DU(cVzagh+}=Q6g&Szp zLWTvMG!l0jTB~@&)F9iI?5#glj$IM$9tpz>=ixD<^A}}=uQCas*-nOIYQ)-W{d4qV zyF_tR_V<5sH%hs8vhvaX;d_Jf4l)^?UkmoM>M@gJ)dkHpsT#f(3=3oTki<*Qq<82x z&g5$qXQoOT<~^fvOB|ab-`VvHza7)%&7+VN9)``Q$MrPlk>dNyQP=AWr-ppb*s&se zx(LOH^T6RDT^5%%f>GY5a;)L+tULblb;6}l$*s-69~o}-wOMaqEF?c4L$E&VD9%0T z!au7|RhUUozX3dI=S{lSzp9L7WnD7+>z7#lo=M_NL)f`a&E=@19yRgxT>SV2f60zh zNwFBn6faNlW^rCoc_xpaPp=hUB{57bLKdsHj@z?-+oE8P>`7fkrbfheZf@=~FEI4E zGfp&gwP`gZ^Y94+F}dIWeMhq71;FHF z!%@UPw+!a&b?J}x@=q8ks`q{A49jAOVH{?s4v7`g1xQ!EfRaR-m7lZtV@{3eYxJ5) zJuL=DqQe^F(gX3eHW-B}lgqhnTNn3eWb)hSQwKHEFC|)Rl{bL#NVQlt*>D`Uht@X$ z(HGsS8If6r+uP4vbe*plLFJdRU|rYi(er?q%H*6ea@_TRMmXmJWBX>4mu|C)JqzZ& zB=%?7={3)8^9pe7R>&v2*V1)qE*Occyr(c2`gEIqzQ?dyZ$ev%*DmS7B}+8_V7)0l zsgyPFib};`RwbZ!wWbv3yh*x=Hy3J7q9yLy#Em_>PD9;*B~kC)szOfPee16jfPcB} zA0jT9*6YmE(DOTTGcsMxm*VmVyZc#=AGw4^5Owdof)?1C#(S*j4p6d6TxSvkx4}<` zhsyZ=u$^bb$MAP%MStuU4QU40C0QD?E8=|5;>Pf!&(J9B@O2>b(IFQB|LcP1n5O3? zQ|I9Yl1Z7*MQ1-xBxRW>Eo<~VKxDfd!S62ZUZpcQr ze>$*VzE%|FHAZ8+<(`cmlds+}(^h%>1z*>I*T%-(Rb+!4PrVZx9f|c00(IPaBL+zt zFyLOMBYCOoc81UW1BM5I#fFDJtJpz7_s}M?cL(hPBoDRC{HaVk@0?FMAwCz4526TX((ihul?&&k@&)fI=xF$Sz)XJBjSO`6 z;K&EHQ4S<9h!6l2NVN6mMnVBFt(a_U;7@pE{_A61e&n9!PVlVS_x5H2lHz}CHUHUk z)f~p?HFy{mX-~>d&L$|P5?9@wF7VU;9B;ul!#*Brd4KR6q@odb^kkLMd6aiLMeh8N7+b2k%F92v$ZpG z!m+Gjs-ZdwMKi)1I6&gS{yWH5z(UQtXtKsp6{D{1ld3bSPIqbgE&SpT0RTLU0@)r} zrp>A3lw4(3KA3mAPL{<{9(QY7R;m}B@TXnviafTkP&PCe!1eFpP`3AaTp}NO240zd z_SSf7h~wj>U?9BAvFW&ZZt1Ru>9>=S`K@y~ikhL)aVxvf`Pa4{G$yhAYtTzvr5NUM zpQ`Swh>b3sOrj^2DihMGN2U3;)J=51QF>t}nsiRYE}f+EDTmIw0!opm`NX6JIfX$d z^4=;8rgpL4N0@DVE;3a4r%xwVaoid(Au6`!X=4ZLqi-#UcbC`+eahDiJR35_@gFuZT462erl%0 zX!e0b2PMCyuLcjjg3_m$zxX&_FZZUlBJN__jG zIw-E$^GFs8d(IDZS0>iIHgbzd3=3r6H439R^zMI_%7WuC{< zk4m9*nXCDg>YDsY<9E}4+QC8xKh9>+U zt+HHU7VV74rBy0+c~UmqK1|<1mIIBQAzCso;6R0Zd4r4z<-D(%}EyX{}|OD@0PF$#lsU0X%KTI z`WQ}{xH7HoohybJJE-xIL*kP~td9AEBx}2}L649V^*mX;#Wj{-Mns;2{|gclswa1q z>;SI#%(b7~T{l4(*;2?#rbE$k+Y{A|={b-iHrAZwu=+NcEefqp zqECe~@KFj^tDYSr9{00N5q^J21Nm-_+Y||D%4H5_N%nG+RzvjRq3;F+dFcW5(;TR& zyU)eX8JEXZ;YL0qn^SB#ZH`TZ$YBy2yCjs-CyeL8Wc0abHs;NY^OV_JW4KzP4GX_nNTW9r8 zrxhWm&ksFNdsVCGRwr*Vt|O7_5!=S9w%me!%op!y^_2Rv0{_*FxqgpV{%MC(?(x^f zH+Yl(4*UK>fW@hG3ht-cIX{-jjh|yo{d~KdGWsTu&&cR7LrO3ig9AUvh9Xf2kKLP8 z@85UQHdJo_J^qk@ND<`sU{T~I`Xy`3#Poejrw2Rf+6#7evYx=gH1AYWvhd-1!5g5= zTck;}R`vGV_i{mO;LHlv<)5fRMREFL_TCl%*C;`s8S}KT1D(&H5*RM;*C~4SzB{ln`r?)n+ zG5YXpKNrzAdrH|_U2X$0KBt%$|9n|?Mi42Zx9~Pg*FwOqc_lIllCgBvOJlR9&y$}S zs)p7sU*L8=t&0}EM;@uJb$41z=8@$RDX~3ENL;dgxU6((Xiueg>2(aM{)rZk?QtVp zVbShf7oRo>9m@yeu(Rl8{2b~#AAYoUnJ(t$yghb4M75!hc0-U)5rYAJl8nE7v05!0 z>n9-P=*fE&1W;(Mlb(==11-26GNGZL=Kj*_dc=A~#zH~6KHugM_mn9j2@w_}`1>at zI{cm6Y9}i*v*6N;@-Z?OeCZ7_<*Tji5;rCWh9lm&9E&h`Iod;E)^HMY4Ht{M0W6u+ zdWFSq&ifKiSUAGY&@LPejrd4;=?1c86CM?oJt&ueBfnbL zPdw49Nq8b8M!Dn{zv8YDuhOveM{;6ycM!zCl(=i-Yu5(^o`n-Ile?1{ja9VF^Pjrv zPcJwWmpBrTcZu!UtZ@dCK&9lnalj!r0M2(6nchHX@nQkfW;N+JpO1t<)N7A&jZ*j9 zG5FmPV@Vay{G>(BsH$~`SNDJF_Le`!y2vzL4puMlH@gQH^iOxC2Mllo6qTE~B<>**kN{qq{d*wr;+#K^g4dvFVyG z58YZ0c@7EtOr(@G^MLO}aPPgUtm>UJ!I6~A61HlXXYr>VH}s$!BV6=C{*H2`7f9Mx zl8UN~dwAM2zhdwqqd-&@#@A@Lws6zPlY|y7>kLj3@eY@ylY98kQCbKiqc#)W-HIs) z#+G`WXS+M!ng#l9*Q|fJT&MTbWxsPSiMLj;g2;|3>3Wy>LEhgoa?_-da6ltmIL=^N@p9a+rjBCB)JWkpdZwl$Bp zEGJe#$8wRL2>U6mwV`$G58>}{9^Hn3>ge)4aEx+x}ds&FVMoF2SUen{<7R_9V!%ZM8=VkPZ3YepPH zb{s)Rg7b{>$9*jPRH?>K$rSNHq0!X7Hie<;g>i9844O;l4dUevbnNl{xKA4OWgxv{ zrWU&SwBLB&uQu$2ZuKu+2)W{ezAk^&A|83TO;j-4W>2UYJ*sZxmZ_%Zke}rrux@e% z43l*my7;z!Xz=S{^~6?ru%oY_09<>nAaKCKjG6Rht~u6;<z#N`7-WIi+fOv& zi;QIJZbUs^|2e!o5%s-|izx9W2H#E^a%#HKRJSzf*=gTC{;h$Nv%B}_EAd>eXcH&9 z5p_#`>klF&k&doYQO~4B#$uuaw#`tDaF>4W{xXBe-!?x^(XvE>A-(^0Pb zL!Pomp{3S57`lnG?&3$TDdPb>Jg?<+4PIg9StV?QciF@c6O-?=*RXQ{DPT1T$z>ao zMY`eq{K`}B@Nc2>1p>y>wBfKUkDypQG{w3arR7s~Iy#wh(C=O6G)HD4s=4H8-0GOY z*Iv|(8x$wSQ5fM1{T$D$ttgr;dmjy$%lL_Zv;U$xN{VDGbXzyM;dlW znb>9Jqj+0SkGAZOM4`#CAr3i10kTMkVNf4w?hQc57fhrv&A`#BZ&Bjt(aJ0E;4;F3 z7dp?&nuN8Y?ve=^AJxT9Uk#PC?V77IDl6R}E~@K-#jyE7n%;j6nhfpU*qD5LiiD*} zQ(35SYzGW?bvLn2K*x*qxQg;tCPrvsv^&4klD?d(W9IaU-h8q3jBA}d)w0jwa28Pu z!mYqAIFshp4;;OG9{+gjqCCOHqtItiY@gO+TqZ4is~;c@zy~`9c$j>-$e766(H=dv zTa{gvQ+OEOW*ZkL)TUM&1zK1Qq}IkC7wna*7Lu317dyf&WUie2Cnrh)q|BDwW^~XM zc7NM8!d57GyOC9Bq~*lemwLWoBK3338V)ME0iY{1vvofs%LQ2p!V9!mS+P>kaN;W$ zTsg6($Ro$x@USMLTi%MdqaP6g zUC_W5U`L+-$QTt)SXVS|xns3QvlD z4V;U6-Y%uNv1ny}-E;$3)lJVo*{>|W0a&~~`XH9^0eVt`hL3+9V7Qm42k29f$=-8C zAdo2zBVm3kdDSE4Wq8?*ACSkaR7)kk+G9QMANLx*GA+^?r?i=D@qDv-9^1K|vBe$4$`gdCbokcSP6z5d&5+v; zh0EdYO;j^@podEK@>#O08nZveZ}avU-6eR2GV$Ysx}D)}6NovPz!S~TLrdygizK-0 zx-SKQUr_f&TgZLtleFar+=|3I_ z*E!c#cAk361{1u? z_5FbQuF4#`YVP87=na2t3Rd&ZoF?`c?SM-#t{GYR8NG&I#{WpT0SxH=O@0W8GYZ%; zx~kvS9XGfEaLD~l20E%3o#&gJeJxf{*ZrOFHxakk$b%{EL7}~|W#LaVhW72hPiX<+ z$Gha_`Kn!V%Eo9ST=f1d;TmxcS-9eCEWe1QQT`vV#SF^oDaR+&2DSHaA`uykK97~- zdkNM#p#Lny^9z%Qs@G^=(*w(dxQq*7$tgId6xA0sbV`WR} zMZLC_M=>%9MUgzf@`>@2cYHsvJ5v*D+T65pX^|hCB{H`c#xJ@-B}#@RpCo7LEx^BW zk5gZ4%67OSK4)g8;AJ)zvX$~P%_S-A<-6*J6zr0nOx4=pKCE8Ml zcc88_vwZ`g=4N1Px2rID<4Ou81%!MG!H^_4Hi@(8%k~uh1nbYXrFxZN5)zP6ZHqeV zlT*!Lmlvdvt_x>?&GG^G9i}wNt?X1YZiu5K;h+P*^&UI!BTllI_keq_@dS6T8le`3`6sSS3D2bt3+GRt+j zl5^s+Oxo`e9b>K8L#}IzD}--SA81pqBxaAb=2t+s$!;@e!Ia}o20r(OCWz_FNHwtC zp=9UEO9Y*9`B&9Q{a_mvNx}Tz43GpmE9l(k@J- z=ND<#3gg0kL+1(eS+nwK;MS-GHwS)WWx}JApSPC9<4tsT;L)~Z<|9^q+-FVokV}|R zT}fM$;-8?VE?eCk-uXtNXQk3m)3+sEe zuhduDmSd9!BJA?>T#|S@CDGzB zzl756E98h7N#_l~Sim!m{9@VGKjEl3n|ZAzq(7akwI5d}x>bdPbM*VpHQ!i1On-53 zu945$?RclNZ?L$y_lVue-yJ)UjSWBYQrUuSg@wYfuCNG(Zi^~ug3Rh{7ibd0_vW7V zhV@U~eaM`p83u;oeKyQDb}J+`@BEcCX=#=W^;=Sp3el5i*74`s+&ae(%b@e#e3$>UKSI$Lh3?2-n&X*AhQe2?Z@!)zroNk<#?aSXRo?)9`cVIREy@r1nc}Lf z;@a~6G@-w4pwccqoNdc}ZCaG~-fu=C>^Dt-$AdCNO|%k|SuqpfNW?err87}m$-)`; z;u%4B>AhPz>7R$YH34OC%B5y=r<(BZty)9J8`0|qLdS?O6R@O9s4g+Ss=l6?U7C#a zbZxGS3*&e)!8p}x2WlEeID;p;8#24`PAEBDOrsCKMxJ5Facj5amsznGN7Dv^-_vGM zOkb{?giQGJ#ra1mTT#ve1d?zj?~z_ctqGWe=CZ(N9W~}v+RR`iUQ&B*oH0FqrYtRb z-hJrsYsGD)Ri*~cwa8Rp^8qo>Z(Au&rC%@UQ2_wie*l()Nk)vIDg}wO&Y`WhUYv7)?uV2h+Ppa3#Bfq`;TZ;4Fi#!Zk-f*W{bNoWLrtw|{Jc*x5H-P8( zWRCGq>P>zXq93z@o>h;fFfQ1qe`}lSV`xRa6)S!!JBTm8Zk8#B#mdj&`WF)`$Om`- zYM_X2?hZ&t4Om{3a5JPg!Oz5la{B@*9Kb-o3|DP6O*t(p$_XV76?rX@*1#s&D8_N0 zD5TGmVqAS0v*|JM$W*zJmI*T-*vWM!9aZ*j=DApO!MLVY0(#G>!iDp(PfLvXyO>%X zR_^o^^?^otQ)Oi#Uw>Gl=PEQcm}c6f8c!WNJEB%ZJlZ9`r>7hrd-&_wcf{^AxY{fG`PJ{HncU)i9DYk9c*7&}G$ z%;>DS=I{p448E4`jrzgiqL1=CoKCLr*YuMAy-`(=!}`(Z4=5Vc@R^SuMf9uTi7r8Q zL)Pvb$bz`Ms}ezxg$iWX z;(8B(lr6;%o7df^vi^Z<Ms*&z25L}le4y4TvO z`$6;Y_@G3FHS%F)18UPf9An>WD9jhZR;Xd{K80M;+msfy1@s-hvt6KlMi@b zTbM!FC&<01Ba;Aj^|?Zr7j0K0 z6KwK(j8B=UZ+4Ln^zmgzyMP5Gv0MFE(iq0deFSsLr-zh<;9DFR76;J;$yM_15g?lvuTC9tj*N_` zpb%wm?DHLQlR_-`CQG8!We08<+zOiiiHH6HTaRh{`$HCfMHvu*bi7d}y`2{;Q7C2o zRgScjMN&2ov;;foZFbI^<${m>h6N>jBK3+E>TdaV+HEC-CEk}J9nAh@MM$EL4bBiw zodupOBmQbGUaKvmvBt@o=4p173iA3qoFoDUrOG)gho6t% zz3Uzew=%r1$il67_hDvg0JJ`D2mWx#7#sb`lQYc*b{;?_lk27R9BZCeTZGO3@!Xvu8 zn(UFrVd8tT9r!_n`2vYe=18%jt=MsooW_US?^hYeTI4Dn4&8h}f!MT-tX+}Gs;YYW zn`4iU8J+fVw)&5{WG33>B|r6*a!$3)7ka9wVNx?u>ENVarq)c+d?@UlMR2}{3a$oG z6|O2#m9BHBQZi1sf z%k;>ft@pO@uTkAC@4b=gOldJ^0Kb-#ltWw?oy$^#bAvq+B-*3FMgQO@b^9c`;zR`o z-4{NW5k4dB3*V*7>SWyZeNxO=?XZqP&Y~$Ol&2_YR+naGHd;H%90uGZ0p1@J^h^TI zMlp{!oyaj(_V^y}5ZJ5GeUI+&)R#mjBf-0U4j39s@zcpV9-Av80xEGFpFuWnh7}y= zLvN#Mv3!Bv8NKudHNP!HHhMfYE#FR#QBrb`Ggi29e_&@hC#Usk#e&#kQjWt2&tT{& zqvR2ANJOEFcu|1>VNe&qVpnTK*k4Sd(oO6Ow^`Iv2)`?f8e3iJMG_aNO(~9Y?*x?Eh#P8X3 zR?+$gxs1y`ubfy{5rgrzI((nn!`f~#n%b~WyxaVUe7a-DVpVbJ8in&M2U*&|n#HlI zIi97}Z7jaT{`srU%HI?D2cFEwsGJ9SAN{(AVb}MmUaH`_P(o^h)a`0a7G4z;Q(N1M``&bl-QDq-E)fXCleF5$F9Jibj^6zFQ2s$FhHK%ZjVgpk&iLHVu nPX4HpvW3HF$3km!0i??` - I : NX_NUMBER - @units = - Q : NX_NUMBER - @units = NX_PER_LENGTH diff --git a/manual/source/classes/applications/index.rst b/manual/source/classes/applications/index.rst deleted file mode 100644 index 2818863833..0000000000 --- a/manual/source/classes/applications/index.rst +++ /dev/null @@ -1,171 +0,0 @@ - -.. do NOT edit this file - automatically generated by script /home/mkuehbach/SPRINT-8/update_nexus_fairmat_proposal/nexus_definitions/manual/source/classes/applications/../../../../utils/nxdl_summary.py - - -.. index:: - ! see: class definitions; application definition - ! application definition - -.. _application.definitions: - -Application Definitions -######################### - -A description of each NeXus application definition is given. -NeXus application definitions define the *minimum* -set of terms that -*must* be used in an instance of that class. -Application definitions also may define terms that -are optional in the NeXus data file. The definition, in this case, -reserves the exact term by declaring its spelling and description. -Consider an application definition as a *contract* -between a data provider (such as the beam line control system) and a -data consumer (such as a data analysis program for a scientific technique) -that describes the information is certain to be available in a data file. - -Use NeXus links liberally in data files to reduce duplication of data. -In application definitions involving raw data, -write the raw data in the :ref:`NXinstrument` tree and then link to it -from the location(s) defined in the relevant application definition. - - -:ref:`NXarchive` - This is a definition for data to be archived by ICAT (http://www.icatproject.org/). - -:ref:`NXarpes` - This is an application definition for angular resolved photo electron spectroscopy. - -:ref:`NXcanSAS` - Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. - -:ref:`NXdirecttof` - This is a application definition for raw data from a direct geometry TOF spectrometer - -:ref:`NXfluo` - This is an application definition for raw data from an X-ray fluorescence experiment - -:ref:`NXindirecttof` - This is a application definition for raw data from a direct geometry TOF spectrometer - -:ref:`NXiqproc` - Application definition for any :math:`I(Q)` data. - -:ref:`NXlauetof` - This is the application definition for a TOF laue diffractometer - -:ref:`NXmonopd` - Monochromatic Neutron and X-Ray Powder diffractometer - -:ref:`NXmx` - functional application definition for macromolecular crystallography - -:ref:`NXrefscan` - This is an application definition for a monochromatic scanning reflectometer. - -:ref:`NXreftof` - This is an application definition for raw data from a TOF reflectometer. - -:ref:`NXsas` - raw, monochromatic 2-D SAS data with an area detector - -:ref:`NXsastof` - raw, 2-D SAS data with an area detector with a time-of-flight source - -:ref:`NXscan` - Application definition for a generic scan instrument. - -:ref:`NXspe` - NXSPE Inelastic Format. Application definition for NXSPE file format. - -:ref:`NXsqom` - This is the application definition for S(Q,OM) processed data. - -:ref:`NXstxm` - Application definition for a STXM instrument. - -:ref:`NXtas` - This is an application definition for a triple axis spectrometer. - -:ref:`NXtofnpd` - This is a application definition for raw data from a TOF neutron powder diffractometer - -:ref:`NXtofraw` - This is an application definition for raw data from a generic TOF instrument - -:ref:`NXtofsingle` - This is a application definition for raw data from a generic TOF instrument - -:ref:`NXtomo` - This is the application definition for x-ray or neutron tomography raw data. - -:ref:`NXtomophase` - This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. - -:ref:`NXtomoproc` - This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. - -:ref:`NXxas` - This is an application definition for raw data from an X-ray absorption spectroscopy experiment. - -:ref:`NXxasproc` - Processed data from XAS. This is energy versus I(incoming)/I(absorbed). - -:ref:`NXxbase` - This definition covers the common parts of all monochromatic single crystal raw data application definitions. - -:ref:`NXxeuler` - raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` - -:ref:`NXxkappa` - raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` - -:ref:`NXxlaue` - raw data from a single crystal laue camera, extends :ref:`NXxrot` - -:ref:`NXxlaueplate` - raw data from a single crystal Laue camera, extends :ref:`NXxlaue` - -:ref:`NXxnb` - raw data from a single crystal diffractometer, extends :ref:`NXxbase` - -:ref:`NXxrot` - raw data from a rotation camera, extends :ref:`NXxbase` - -.. toctree:: - :hidden: - - NXarchive - NXarpes - NXcanSAS - NXdirecttof - NXfluo - NXindirecttof - NXiqproc - NXlauetof - NXmonopd - NXmx - NXrefscan - NXreftof - NXsas - NXsastof - NXscan - NXspe - NXsqom - NXstxm - NXtas - NXtofnpd - NXtofraw - NXtofsingle - NXtomo - NXtomophase - NXtomoproc - NXxas - NXxasproc - NXxbase - NXxeuler - NXxkappa - NXxlaue - NXxlaueplate - NXxnb - NXxrot diff --git a/manual/source/classes/base_classes/index.rst b/manual/source/classes/base_classes/index.rst deleted file mode 100644 index 5dbcbfa4f8..0000000000 --- a/manual/source/classes/base_classes/index.rst +++ /dev/null @@ -1,252 +0,0 @@ - -.. do NOT edit this file - automatically generated by script /home/mkuehbach/SPRINT-8/update_nexus_fairmat_proposal/nexus_definitions/manual/source/classes/base_classes/../../../../utils/nxdl_summary.py - - -.. index:: - ! see: class definitions; base class - ! base class - -.. _base.class.definitions: - -Base Class Definitions -###################### - -A description of each NeXus base class definition is given. -NeXus base class definitions define the set of terms that -*might* be used in an instance of that class. -Consider the base classes as a set of *components* -that are used to construct a data file. - - -:ref:`NXaperture` - A beamline aperture. This group is deprecated, use NXslit instead. - -:ref:`NXattenuator` - A device that reduces the intensity of a beam by attenuation. - -:ref:`NXbeam` - Properties of the neutron or X-ray beam at a given location. - -:ref:`NXbeam_stop` - A device that blocks the beam completely, usually to protect a detector. - -:ref:`NXbending_magnet` - A bending magnet - -:ref:`NXcapillary` - A capillary lens to focus the X-ray beam. - -:ref:`NXcite` - A literature reference - -:ref:`NXcollection` - An unvalidated set of terms, such as the description of a beam line. - -:ref:`NXcollimator` - A beamline collimator. - -:ref:`NXcrystal` - A crystal monochromator or analyzer. - -:ref:`NXcylindrical_geometry` - Geometry description for cylindrical shapes. - -:ref:`NXdata` - :ref:`NXdata` describes the plottable data and related dimension scales. - -:ref:`NXdetector` - A detector, detector bank, or multidetector. - -:ref:`NXdetector_group` - Logical grouping of detectors. When used, describes a group of detectors. - -:ref:`NXdetector_module` - Geometry and logical description of a detector module. When used, child group to NXdetector. - -:ref:`NXdisk_chopper` - A device blocking the beam in a temporal periodic pattern. - -:ref:`NXentry` - (**required**) :ref:`NXentry` describes the measurement. - -:ref:`NXenvironment` - Parameters for controlling external conditions - -:ref:`NXevent_data` - NXevent_data is a special group for storing data from neutron - -:ref:`NXfermi_chopper` - A Fermi chopper, possibly with curved slits. - -:ref:`NXfilter` - For band pass beam filters. - -:ref:`NXflipper` - A spin flipper. - -:ref:`NXfresnel_zone_plate` - A fresnel zone plate - -:ref:`NXgeometry` - legacy class - recommend to use :ref:`NXtransformations` now - -:ref:`NXgrating` - A diffraction grating, as could be used in a soft X-ray monochromator - -:ref:`NXguide` - A neutron optical element to direct the path of the beam. - -:ref:`NXinsertion_device` - An insertion device, as used in a synchrotron light source. - -:ref:`NXinstrument` - Collection of the components of the instrument or beamline. - -:ref:`NXlog` - Information recorded as a function of time. - -:ref:`NXmirror` - A beamline mirror or supermirror. - -:ref:`NXmoderator` - A neutron moderator - -:ref:`NXmonitor` - A monitor of incident beam data. - -:ref:`NXmonochromator` - A wavelength defining device. - -:ref:`NXnote` - Any additional freeform information not covered by the other base classes. - -:ref:`NXobject` - This is the base object of NeXus - -:ref:`NXoff_geometry` - Geometry (shape) description. - -:ref:`NXorientation` - legacy class - recommend to use :ref:`NXtransformations` now - -:ref:`NXparameters` - Container for parameters, usually used in processing or analysis. - -:ref:`NXpdb` - A NeXus transliteration of a PDB file, to be validated only as a PDB - -:ref:`NXpinhole` - A simple pinhole. - -:ref:`NXpolarizer` - A spin polarizer. - -:ref:`NXpositioner` - A generic positioner such as a motor or piezo-electric transducer. - -:ref:`NXprocess` - Document an event of data processing, reconstruction, or analysis for this data. - -:ref:`NXreflections` - Reflection data from diffraction experiments - -:ref:`NXroot` - Definition of the root NeXus group. - -:ref:`NXsample` - Any information on the sample. - -:ref:`NXsample_component` - One group like this per component can be recorded For a sample consisting of multiple components. - -:ref:`NXsensor` - A sensor used to monitor an external condition - -:ref:`NXshape` - legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. - -:ref:`NXslit` - A simple slit. - -:ref:`NXsource` - The neutron or x-ray storage ring/facility. - -:ref:`NXsubentry` - Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. - -:ref:`NXtransformations` - Collection of axis-based translations and rotations to describe a geometry. - -:ref:`NXtranslation` - legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. - -:ref:`NXuser` - Contact information for a user. - -:ref:`NXvelocity_selector` - A neutron velocity selector - -:ref:`NXxraylens` - An X-ray lens, typically at a synchrotron X-ray beam line. - -.. toctree:: - :hidden: - - NXaperture - NXattenuator - NXbeam - NXbeam_stop - NXbending_magnet - NXcapillary - NXcite - NXcollection - NXcollimator - NXcrystal - NXcylindrical_geometry - NXdata - NXdetector - NXdetector_group - NXdetector_module - NXdisk_chopper - NXentry - NXenvironment - NXevent_data - NXfermi_chopper - NXfilter - NXflipper - NXfresnel_zone_plate - NXgeometry - NXgrating - NXguide - NXinsertion_device - NXinstrument - NXlog - NXmirror - NXmoderator - NXmonitor - NXmonochromator - NXnote - NXobject - NXoff_geometry - NXorientation - NXparameters - NXpdb - NXpinhole - NXpolarizer - NXpositioner - NXprocess - NXreflections - NXroot - NXsample - NXsample_component - NXsensor - NXshape - NXslit - NXsource - NXsubentry - NXtransformations - NXtranslation - NXuser - NXvelocity_selector - NXxraylens diff --git a/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png b/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png deleted file mode 100644 index 597cee834c0426bd0e60b1afbf6554a5f3b04a99..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7089 zcmbVxgT!j8lW(I7CP9R3l4E<2>J5 z)AI_IpP{<#g$8#av2ACx&qHz?7*6{wc9+~vb1nw=8zsvCGZ@1U!ma35{YCTeb^go#}G;SGXdmMbu z&k(dLz+>M0rk*>Sf)`6r0rqXS-WdWA6B8%4ZJE%EdqQPyjwzkRB;aOHTl>4)o5x|d zk^nCj4;eIl%(n^F+aGp�Z2d70QK#NZGhGGt4!*DVv+aK@%#_`tEYYN5riu(%l4#$J*D7^Wj?wMl{e?}qh~ zY>s%K&(C)zD>TXgDhM0}O&=C2r+yy#K3pp3G_SZgw*E;r78oa{=-eoZRr2X4M1X%T zpwKhuUnefLT1P?+p*cUDbF;27;urNXIdV3GP9r`-Tm1Iz!5axr2q&_2aKHv)6R*sV zoC86Z4ZQcMBBg7vGph*EBH-3c92|H`VKT=wJcAF`QUTL~RppiMF@&7l+%|jh=q_Yl zl(4Ai%5;s*CbbwAZH2$YiG@Y5cQ^ujWfjnl_}!#bRb1n>F}OTlrVE!&9&uFk^!!4^ z;FHzbDye5^Xk#UxwXh=zxB3+h)q$p^rRmjVynV~|G~Rjyp=(MM0mu_vg>= zxp&taB#b47RTc~^Sn`WBaGB9RJ~<@SMf)iaypK+F>MgC7zsG<%r}Pqabh%S?=ZlnO z^3i`NU#PHfxzukcD5suN`yh?Xm0-C9poTO!`bZon&_&qD+`{Bx!n8>beH987Qkx%6 zRNOt{;*|T%y-h7HKpqjqJ|6|a$DY4jlDeCYdZAn2&+t{t*H<)>RWW_m=_B!yXoyoi~j%|VXyXk z04CaDLB0Woc^Km9>6tgSGvc<^MsnrPilHHjLv>{cIk;b)x=dF3^O!*;WI(#z7`=S_P(B*fsh&^#>LCqbFwo<4%S1-m5+rtCdO_86H82|ZC-J$ z^0QbYQ`^F#vI*`-R!K??acY7!^%XsR4*+eK%Hj)EVh@1o1ZacHTr3XZeXE%-cJZ^~ z?igTnbhO%Wgc-Tl^we?eguId(P0owu>bd@t3XpYIWGuOgQ3;QMy?OJ-3M_sY35mfq zuL>o*x~!TS!N0WzGR3%G{DKF@zLYPS60_t>W-)`#e=IG9h1bEVcPafZw@P#@ERv6p zy`y8B4KrpKCaWw_2M6wwSG%=MfhV6$c;?N^>W7f6Z-J zDZ9VEuFcES$qeV@;ra2!?iU#qRgB+afU-yn!0$B5%45;`0FQ+Jpvg1>NBLMTz?jA| z)(osl*JpZq(Vf!EzRs{Z#ZpRbFK?ztkBILl;4p?=3tZpa=+|-|^w7C6v9sgywH;Fs z5D@4!^2MZlIShqt{M-5$5}9@b3BTNuH88kO!XO#foj}bZFw%z41MhYee!kk11Oklz z`dh>Fa}3e4#Q&K^U0w$2y?M`4s?}sm*A~AeYh%N5dpXtdeQ1dE*Lyz0`5f+^M4G6z zHCqtGR@VAntA~)o{%h9k?(R;MI#dUbIHEcyL@Z3EPxQq*VzL9^&^mv_@!);Obxb`s0N9NAtehd-L8uV}6C42C7z=Ib>PI6$H_DA_up%NN{Fh^> z@6}Hj#FD_{!Tfx_zu5NJ|A5Ka53{$5E!*l!AM|fiPAus(m+^;m79F8dyynf(?=1rH zL1Z)>HwZHN>dAH-*ru$A9m`(xn;An7#+IpHMW`trs;7o`dodKo%*qNKlD;Z0@SS}M zHU)v8)BotDgVO^R+R17TGolBVnK8I7s(9m@l)VE3NI5x(eSbQnP-m9fpg%(h52&{L zb-y_Dz`Ik#*O}nHg zNlM)8!9#x}(&v1I@WQ?csp#Kj<(@;5C9WOi9N+_lr(szFV>MwNGCcRs0*lZ|JIVP9 zA=!WCs+T1Mg;0=m61V*fl8wT){%kq|Mn?2fwDZ(fo$MHgwK`?lUyM`_1(0Ukfxp`(RR^z-IUr-0Hi-PWow{Cu;JB3(UcuYs*w zS4*6aR_LvhhkwGVo|nTL3j)wU85OH)F@&*_VhEf6T494$f9%^o{wW)R-E2MjvGeza zFSC{4jJ5&0C5fpaM@X8+x{0vKT$s9P6dx_!2}!7${-?<)v7eVYfycvLXmo&twy8~2 zSzgxcRWV?%+mDKmCxGJOHY}zf zBEzVtsQQD4x4pr}DhW>kTOQr`_F+|Id_uJWpE4krDs1n$j^ z4~#^#*Vo<6%_-@S^o6&xx9o;ptbyqcres_rlnA$?e4mR+7B4CynP7Ygfwge$eLz}V zGHzyvt(_DOG`TG4bC_tSFx*_?tgdwH@@G^c9{#)#bZ|j__6fymYZZ3A(t^oZFRLDJ z<|7pqNdZ|D!)U?g&d%b-{%;MSR7p(6^ymT)h)QkekSh-{N&J1hTjn*>H)-(^OFEn3 zfYf#FlAvDXSZH;}`L!fzojkUZ-u6h1~<|ldl38{cs(Tz z^yf0hlCvn;jF)zoekSZnWBb{^yuUDabL6)Zuf3|k>+R2D zMvZ^Gh-lu&y-J9rKP7y=AV`reWqLvN9_W;5A}8f@GEIFJ>MP(|aY1j>ljymVg<{x4 zjTFww#AKCVyAHqe?wr(PU0Yvgn<*~*(cO)Zkf1efbUo?C5fXKog#!N9hvflQ_Ei@1S=cn*o&~0NkFVWeV!*?(Mf@_YaIXRWBoSN8N{9R{?_E)?I0Pl)- zSk3-lc6VCwGx2l6)(wj|_KY$|AtH*hpC?w_!mj9Eym)c1V@Ac9UMldOv9Ym=hDLYW znZ#o0TO2BlDK1H~Tb&O}SYUmu{fUFUp;BFPRH*QlWfB*sA(cD;7K8SsKm<0T%Jh2< zl25-sW)G5-%1!FyUy%-yRq84#LT$7pDM1{kASaKA|J*&W{>_j1Bet3!Q3ERr3${`r zxt8<=t9tQd$(x@834HBwAge03Xrmn&8TmB#UY;zXJtTXHv-mT3HX4_wdxXvk*q_u~ zB^KOt1>j_xQ&o(Mfjf`PTK&m~q|UNl_(H6f+C%*J+s^o{zeB+URn(uW&@u3)lKb|J z;p;&>2N*w%=;1HNUykTZO0!8|{kbxXs;a8Jy}g~u@F#jT#yUC?U%fU8K$QTFg)4oE z%_J{+UxjhaAyD}a+Cs@wwyCv08}-sKhMprLBO|M=zF~n3htt&!q@|o7$!ghePmm7z z=+^r^QYn-8Z8ux1OeYQ)J;h$WBE@i|1QQu8Z9J*;IbdgJ7r&Ia))|34-QYs^?AbGZ z=Sd!<%U1ubM*O7q$3I697l{b1@r}c zb#YGrIZ^e>4+;7>IyR=G?@1{o-#w>byhE2awIfv-SjnB5>qWm1bS$f`p7=skW1XFT zab*!&nTEAa*pl^45h`few>x}ywmtEbT}whUI9L)~CN=kUf=-|A2g^ng;RDWaM3N{S zftMEMw&v9*0uNO={Kbrmkq%3Z5NXTI?3koyUB@P}H98^f}=x3TKl?q2}O2mR_|A|nL zG%`hFHXWWohRc4KLB~t}UJ|dtfA+lL(mfBsorQsVS4B-NvMQG`*|mrnY;qfg*hFN{ zAVt)=7mvOnW!V#zSZ;&1_0}9V3d%PhmV*IWUO1bT7+5{`@uWt=L$Aen^UF!p7wjLOt42~RsEI<~v438pG3D_0z4+^UFEz|`) zvuD@Lii^O;!@>~8S9gxNMoiLx4hhjF6<`Q53Q7mdctdkR2MJQ(Hb3194@9I}(Z6jDB zJ-!i-Y^d~bBcC&hzN{R&7{>TGfa3hb5Hl;n^pGGf31?*`JccmBb>U5|n<%zhE5z0o zFs#D*K1$Z!-dX3=Ia(A>%e}X|NL+4)pCwH^KJlswMT6a+iTAMxVxlBhGDD=E4w!Xl zR`oTwY|rFK!#R0fgRZJNaIvu794Qm5yb=~B`#Y=?lD|D9mB+$H zGGJ}T z>oxbA*&q6uHWjLhk7x@@K%-tEY!@WtNf=nyYKLH|PiyahN^|b2kcg7p`!3!)O1;1M zD8B@WA@E4Zz66RO5QvrA8XNqw&$>ONTwlKIRz-bacHh*#f`TAOsjnZcp1tkwDX9tt zZ{qN8LFksZFmv_H?%aH{-5m}-3H#ct$VIS<=6#fu9l;H<{q^2lw`hBNw4T9Fhg>pw z-#_9?|jjKcL2)~hIOYm38(_cRw(@DuF$S@N9u3V*z!Az)-2&b_hHdUq^ z3xAG=x_$BS|6XF^xpYf4D&8f*`ZGCZZ*GH5cAFtri0_{bBW7wN&i!X;U;vBKFoUaB z6dC4ff2%rVim5w%$osJCH6|G^oQf{XGA&-h3Vz9;(IbvVh*_!@a$6 zyTloD+(iBw#EpzJ3i{pq)k`)&d?7g=D>&G!kx|lUUOLEtfpK)Sl+m;S2)lf}(;y}2HdDyC+iQAu1*gEi}#v~#)tauKr>f77x zt6>sJhdB3RN6g7o#Nn!O5c2@$o2<(txGSh4PEM)$;^+L99-&Aj;AE5vj1>sQN8#5B zF>QemN{)ubKP~$|T#CZT>1e}^Yd5Ps9XV5SNamaJ%QYO<)?X+s!HDn+>w zgkDCoQRbQqMq)6TbMKLEM=HzKk<4|35{?o}k|!F4XAzn)`Jp=2rzD#7Y<@KZ9_6xr z9pG^flGkOg=6S@9K%*$XI8h=F4-3p?WM;QM;o1v@ECrnoCksU7yJVMox*z0C<2SkI zpI;8id|nc0`Y*%L>%eNNE3z$!^6!M<_Bk7b8p6h(>7>O`A0 z<+Zv*G%oobe{*ED{dM1NZ?PGvV#``j4cAc7NNPgGz!Dkv{TaS@;b(}yo^=0#PGFJz zZnL536YPaW4f$FI*7aZ8k+WfKpLp58WA|%}Q@wZTZb|N&MlBd(NM`?fsxmB0elg5a zyhTfzYtn^Y>O}{*Xk9rgF>z5nn_pVy(}ezLUu)}VJ-yP^B{+!VuV+ohkm{K0X1(jcKbDH?b&>a_(vxDPrweFG!4ZAQaM@IzzoNjj}rA zDd{kJNtN8Ib6~C!yRUCI`0r^kQiz=V_+lWl4sGU=mKMH|Lz&xg`au%S7JWZM-(ZyC zY#>w0b+bZ4{R69Ou8h`8GW{N}ZKwn{hbDlMWY(nFn;@L7Cww3hUttM6+E&%TSqy$H zO&vQlZoeprsc76h-5UFw_||P67JNj!psA8~0(<040j;#8ZhWd1PAZ)@XY#1pN)8>I z64k46S?F;kD#aHQ)0rptsTt&LEW5MFr}iV=DwtlH#MuJc^?~}{NW{(*GKiKKp`5JJSn=tL zWw`ym#rh3c5D}+>zU7-!QKX}9Q^r3wOy16eEhKnz|J>v1gl6sbZ`IcmKef_PdcMtKNSG<9Xx4}|=|E$9hEynSWZfFpV5_G*B%drKT zf{p37pZB$gbas&@46(47YZbb@8iCPEJw!2f+^TU{;OoX*ofcVd4Ci}K&W{udOOZ=t z#S%e0z1B4hVGwq$;tgot*W3B8oi}G=XMrnFctcBY#-FJdPMc3$vx24TVrm__`JV{r zWa$;L>gx-iP}rwlo)7P^BtBUGJ-T&NRCFAm0y}ZW$gYQY;R;z9O3Hq_ZqLg}D}5gC-$dChBeP#=_&Wpc z6)^{U=SlU}^T*LAGHTrz*Ap~tFkB5b#KBBH*19n!!Q|!N93nX5?j!e>NF|R`ZpIhF zfmx@Ej=QHU&3KG@J$PDno7xgmx2veFAUE;jl8Mo>b>~UIVQ`vsRSAk>_BorqYgesWGUr@`D=W&OA`>A)AQ05o^3v}i5Lh$_1g0Db0lX8X^R58= zdf_PfS`7(&c_EpEf#a8U@*f-_5PbCK9~ip&QWWqep_7c3ld7$mldF+~Da6&)mG!fY zrK7QtohhrW!>5!(VIl~G0`gi~Ld`98f5FvDO??sJ_>&oD^1wR}x|gq!KA*>kW5EVw zuUbm{adpZ^)|#v<)Y9k-VZzhDP{*;_)>cuIo~8+KLbAq6P{#TvKm7Nd=TnVILXyxI zl%HESKB7158}lhreFI-Shi*ud+gI%T>QLF(*pdb}OAZlKLK#?DW!>D|G+hJ3hT`Qk zUH!BpqoSlOEG)n~d3pyk6^H@?0(uLmRDw!Sw1tuBKgK6BpE8`C`NC!=5?;L}APMt; zaR+}E78d4#hJZ*#MU@cM>JN@+jO{4EQ73XtfufD`t#80g8K5T(wmmSFzPQ|niIO#% zUOgN34?|k1wVv~&`)qK;1#&U|SUpzI;H)JFc+BQ?Po4OrOMFz>WFf8o z9?c@2ej~~&m*e?<85w(3)Uwse+1)OJ5mUdcTO9zA|L5vGqJP89V4Q zLZPB^_-L2eM9r>zZP#fA*Ywo1dUUg(N4JSGKmb1D~NPY=dncQ+j0(tM>i z71eHtTc`hR$-q0qBmFFo^&dP6g{;}xe&oJ58oC&mDk$LbTt#kZ%08?1cO#%9_&ha! z=6r>TS=o|>yj!oBigB55F8cCxgpz^-)9q%XWDg%xg|BN_+0eZBF}=T!_U223F&dv=VeyWm~`2Y7bj>l_ksTBB;}*4 z>ovbvbPPNMuVab10~F*RHt0m-_7C7u{h#Nam|r;$`Vz9_J>_!8qVvNhmTZCJc^C9eHBn(jF{TXU6 z?l($^k2k|5du(8~I>BrOzJGatj(yyL-BO_5hBy24PUxp~61hoX@4Ez(1+<<+#b!p43p z8BdoPDYKhnsF1fTi;HMzYZKAFOY%b{=1pDjr_WytMKR6p?dJ8bS?k)$j!QJG(4eesX z6PgCmwT@dZ*IPU0OI~NFi|$)#Xivgd3$Em>_50=ErSy0;2miqUYVn7Zd;qA)nY?!`;cw*oY5aGy9sqo=jkm9DvOR~@huRbmO4pY=SL?N zwlDEmw1Z?K@tmh`_-q%W@>PGkOy7iu{a7RU|6maK?^q;UR|f|S^2I<3A38CgjnzfX zf=y_ziKMr;NV?DMXXX#(KT$lUf}Z179x*)wgM_|*`W)}X#6;RS@f5$B#Q(fyCqIW^ z5HS5JEvMQ({`u=MzhXxrBt*Qkv!gdsIQgGoS_f0Cv3Dw9V6ddPAMQy~@P8o84&)RH zJ@4z52KTcv`?W5O*tr82g6J;R?Rfs@$ewMJ`Sa%scXxNag=k*;ynz1$@jtfY5CR+y zjOA2GaOcO*7d7oG;w~<{|Hj7ZGc`d}2mZ$yPP=$=!?CHUDQz12>VIba##{F9%&VUPR2&MNw#8UcrRPQcZL zn4j+>uW%t_Q9vFL@KtZ2QV~QJX=(4-d{xxvo65?fel%`8Zh=$DKA0>fjtWD<9p7zg zEb)8Z8@H(wg>V0SR>kGyvW&~HbrAJA>4aeoY;W=39op5e{!a+-9@4SJHM+YLq@gX~ z_@v1H@85m=kKKMd3Yh0OaY4kxqhYn69a&VQ9TY@wzvLaCeX!`s_R`2G9SQY7=L~xm z?my?5XZY&Ju;>I$pdq4dr>PUM)wE2R+7a-+n+q4&*L&U$d2*gN8(*etE70QO8Ff9a zk>0<*k4spMjHhm_ud{5#dcKVFTeAvMA=gPtt_nP&Xp*Z%CZ7w#i2~^t@a`0}U4>sf zr}>@@My2|spG|$bp_Yh{kZ1Z&4w_j7`ysnk(j>T}$PZ0CLG1rrj95w39XeMv(Kb8` zr~3Prnr8z2^JgCdvBlqo^|GJXpDz?@+0-2P`#02ek&t!va3gVT`JlL^%xE#;(lv9a z`+25GKX%6mS}p2E4-62QnDHJQu{-5~`^djO*&AT}CtwK7DI3lH>A@YWhW~qp_U%zo z`L~v{Oa30L&l^tAGC0`G#B`#~%yBt4MN(#tSqBd#`CZ=c%u&1ftctH*$1p`aJfto@ z&nH``x>S)pJ=mg_mj}gS(+xoUI;1Q6m+e-9AJb+!$!rg1E6cQ)i^*L1NqUBcWIa6U zex8x|ZW1OTBhS`*Dn8rJc<#-aWBfODxLVz$oMW*kY$r3z&uBt_@rx&&dEWlFD|$ZB zTUY%X?uQRNBYOumkGB}3yh_5DsG)F4+`afdK3;p&yLh{eL$JmfQqYMpE^umQ&lKc}o?D z5U>_18IE(-a%HA(c_0*wZ-R+!kT%NT{*!`?M{*w?DeGBx4kSxtTOT%yAz#gpq37o} z%`f>65e33kzE@R+%NgB1y(uVQ{8XQifR%Wl#)u0G3p?BB>#bmI%>qRT?B8NyVoE!h z_ZAZt5y2$r=^t!VP>9C$y;s>IahYz?n_i+6)j#0m*R>D6UUNFM;zh(k{-Eiaqsq>& z%oK^w*0noPIA>LD(u)NmOUK3;m)Sr|hzpUyUjO6cRkQI#fx2~-=k-eH$#FY+y_cwn z2x$tRtxb2jimTm0WoVgw4#uXpH*S*P1o`LBZI5W&HQqNH z5^hfqKT8fj{sz;Sn7iQ3w2s^U9sEdX1l`W5Y;)P>w)ym zTNYMJs)4jQbWL5%pugN=Q1YP%(xJq57%gTrH;)Jd5dtwEzIU|sXFggr z(!igi(JX|4xbSH*4r{E{;)seu(bi}6Y?(v(XXemt4+ovr0_nkyWZ-1D{Zl{viL z?0&xEi=5GzgE>oJJ7BXDJ@5GfMy8J+8|?O{;j_DSJ&UgyksOAts*Im}L>wHVMs}c| zM5B5Jd6sXs*6fzNi>r^n_xj-*L`jMJAtoen%fET=+W#xRphunnjWnR$B3Pj`v`xVq zDZl8`_m7N$frP*%)I~Ct@Gq0NC>L&kU76@9l!{n50h0{Pc0@ltQveTFeb)32;rysn z@=XMJTf2x}x+=4>6JJ43uIP``(@av)`-Y)Ue949kY={tgDamIqBiR4Pm^PK)sB67< zRbsiMzRe!EJm5gvlQ=|K*%DRXR#x)vFBzbxDb{$5xZzT=4TnV&%Z2$gBBH6SC4c%j ztSc}=K`DV+S?3ycmY1EKT3uLeC2+K?Ty2a<^68C{CnsGvw} zgqWD=^o&2~JqDurB93mv+eQN3yn5_v^6`eZsoN<#YYGj8!XdaBbw!EisjaT`kEw>x zrHAdrHM#ISeIB#BpZNp>p-cBfTXCI-3632W$T*r-RT8lEj3w;{E@&LnY)~-Fwpj#K zyap-?ypKTms0|_=N1d{UnS_hW*aTdfqE@Bdea*{n-x#tTk!cmrJ5M+4hujhE?JelP zd0$yXKYe8wfs#Snv!u-FS!5n_VyTQa`WywPdhrdUFLD)z?y~siK`9~a#9B~L#P2c? zq>|Ghlaay0L=cGZIqt`9$|g!s`&as#L@-_tp3Cdr^Tz&1Zql&=noZ=nNxEs zbew(I#CyS^WV=f$3kUI3_$-o#0q_t%RokZU5Y^upPq%x@7m1h7!ayxGy_DtaiyK3pK{5MSHP;e``f}&!@^S6bfvVUuxnfjPS4Ba&~A=A)Wu$#y2{XoQ~yZyM@aaa-T z^yvqmEg7%P{PeDU{la0@k5c+%=KucbPnr_OuYRp0u9Ukk8a zM-c`Zi9NiC<@)9ac17Os*q${#J-gAi^2x>F&d%fUX@U?F=Vj*uDH=KNau23dVIAUH z_uXA`1aSm`2f9HB!KG~3-OafJfK=f&_0$1{lPe{J^m0F6&aMorvvakO^stVJ z#B~98vA1#G3l+75iB{jC*9UAamqm2s_f!n8qvNSNx7;9YWpK_MwInN!n-u5Yb(BvY zuIQic9mj3v5FCxN%pHR@P@2!3Ug&#qwAnP`l2P5wfzYdx;c&Ge*zn{tW@gyh`eq=N zp~$67oAmg2d!gc_SOc-V;(|qknftNc&WI-6*T-+${^|Y`GY&EZ!|T8fX`X<9q2hZ1 zXVls^!Eu(QGCh@3un=ZbQ()b}m32gDg}7w?{>ljOtz67d&R=&&EFcD5FuDlYtp>gP z^JlgFAobUcUW@F*^s!HT8P*%DP)WP_e9gJ#y}aNZ|LsM>(; zs@#|WdWnaNOF1Glb|FI|UAD`~t^pl=@5RY2~Z}&w5Kh5F1E4t;aq(r#7Hc_)* zF8%_s-pAdboThKXas2MtxHoPu@`ifErR+JZDl3)UJf#SUkdNZ2SHw(_8|0!ByhIT~ z6~87Xh8{IPEm{+&42Co`2p92J=udw0JZi*`aGXE=kw@KdcUV8Ncfp#mRPiacA}u!M zv>H@61QYu*McHku4#Fb58uU!5-#0_Y)x@Gm=NzwG>6t1FuMX?X3h{z`BO?a*oy=3W zP~wVGT{_gi8M!c5&#=#9Z*k4TOsZoshU888hF%Iu6@;IT&Wcaym`)d>=Nd3E^O ziaq>=zWq+(yf|fnEB{XIIZ1S=bt6E6o-a?pVNEFOMtS4wBelmU}{rukC-1=+%M|t zy5tFclG@v^hk(w6LZaY;0o&~)8RBS)5n?5XZ)l|rt^L>GsXI z0?dYj+NSU)nxA4q60m@`S!dRQ4EM;t(DSM7KjY$e^6y!fhbD8br^YPYuWVi(KvjhP z-C8a@S`qJ=DBtl*XUsij5J9@xt+kQ9v!+cRT)Eo0UKq}luU#Lv=f2AD_a_@#c@fx( zP+WCkABbql?q+wSvm%jJy55ei0)ix@g-e*^Z(6o`KQ+QrC(~$bIdYii2j6g`b;B<43G;rQVb`dh7~OOKOg=H{$6Hx6IDZyAcz)$?X+;-7Do z*tzQWoKy6^nFk)0?QLY)XVI;x)} zJVV|dQoCroQn#m#uR^t3V&&{SG`AZRR3W;^rJILg;aKta2Y8Hm?aBfICJmg`p7>k} z44j|RZz9+V3X74T`}c{MUwUImg?6aSOblE@#}-w}qCnaF^9V)s_KWUI6V92H z6-w*{+m&m3Y+9woy@sO|N-5n`eAZeTjM34O>V`v>U%BDBDl&3XxoT}je=_&ahB4h{ zOcP>@m#Wbb($FBwTsEowF2H|#$Mu?YXZV7e&hEO53?3d^I+PTTEvD_?FH%htd4pF{ zkF2j;9xz@mixz3~V3amL(t+Yu*u-d{m4&QJWz5Ff>$b!!he7 z@MeR^{?*mj($c@)hai&gv)z)YDE*qS&=cL-+he*B=6JeB1S5dmcOhw7K^R|jCBJ=o zI2yV^QFIZCs;$ktz0f4_Jrv*uxHbf-`N73J6wTQk)TP;?KeO8c+Cx!mwzI{5=H61V zC`>O&{IbaS<5M_8UO(lz`gI8Iw-a*eKle<2Isbx>0-|}0p_9$dZt|(-t!Ymsft{(b zJm?Q7Y)#j|rRe=*eW2Wpy#M`9VjGn&bH8GExok%Hde*WmRWy2?>+U^w-`(9({MB+G z3)vYVAKD3%W}S#wAe;*NrwT#kvbiwoWDk;F?&WJAYW=BK60GGjqas)5?QOyFTRdW| zdYv78syl8gr@2}1&B{Vl304FmW6;Rg2${}yNHJ9_|2(7lYihB?KZg#dQS7216zib` zXOKr|7Q;f^Iy?T_nAp}z3!dku#MM~f;@FgU0oF)bWU`9Q^0p*Imluf*33P;FLW^5qfw zMikkK6p7R)X|5QYp1ctnMShyPspeb?@3HRxjbU=QvNp)Yes{6}Q%+WpI}kB%jX?8m zghD_)QsT2Vc-7Lcqs?D7Ly}iqNl77oZ)$k5nloLNh2>ZFl>=1O9L8SH$>;-4LxU34 z1MkU!XL#Nj{JWG8zt3Z-GFcEqD;HiI3!bm7t#R&E=~Lr);665++bTJZZ+GQxS?dT)ki5#8Nobsb()G(Bi|VF7opQgb$BNAoH_ zJ}%Q=w*3d9w1`FphxkQ{|CTf3^M#kUGMG*lJzqV8RIgtLo}JY2vu$6j`mQiF{?JEa zHbX2zMa%QeBn@zLcUsPZXd~u1N+NKOLx{g=02hvFc{&HuHyl?hNPvSd*`y>=O1Ecqy?6;HI zmYjVIp=mdf-5|D6jm?Lo?VCm~(Kf$4Wv`o!LIQr}1Bcj`RJ(J`8ynBLc0 zqD514`%v1&bd7zDc~&-XLhZ%XA+6nVFpY}{wYs!*O95G3A-{ib2puu0a|Y4nu|Haf zNuz4i?uY)?#0v;Sq!gIBxPL*lE3)fyD7~R1)~c%&7LrY+#mJ~V;Ar>j&-eD;jeeCn zkIFN9Q#|r?6Cm)1*4hRfnN{;k6`&}4J9@UF}Hh#bglo3a7d7+K{ zF)nuL5x(hT3iDaV1nYC@vK+T&6uIPJ%`vT=&q;VG>4eDYaH&AKVi6xDS#dFp3q1R?VKN0#KEW~hhW*O z4FA>qp+LfyZ@yHcuD{dA@MPrsI|3^bx#cQLJ!&27CeSgVX18f>8`Y!n)-)7 z9?s$0U$AMfKeoL%A*}`VB+j>Q#nn$xsM>1PTt{M%^_)he^_+!FM*YL3-6*n4W2LW- z=&7W)>7H$YYvzLKM&rEo8yvD9NE9!aG{3jB=j4kWEQlE*@D>#X%;#(fG{WJ^H!FB~ z`yTSbIaIy;0>iS&WOwhztWiY2ANS~euEIb>R3a{rT}JjhE%vSr?z4F#Di?*WNRLGS zD_ITxICSa~X(TiWbV5I7wKek!mqld?1Pf{L;7AN4+#gN0!SV=pEW9>F!P>=Lmj{*8 zO^tYe{^&o$)}uaFvue=~cY87!DPm%6G9R|t?@wJ=geQu9b3+x*WY5{zM$aBjUEslX z9|%dNXNEfZh|SjfcE_d|vJXg`X5sB={%xQUw9=k+o3777+xz}4z1Ed4hQ$BO(Y51h z$|OBd6{4~B_3VVetrm*rsS@f;Z+%fi!ud6|wvS>{HfW71Oi6yA(;R|*JZ=12TUgXs zHnSf;ovn$!y+FM)dw9WKt|oFBBT$LF5LS6&H`#MB#)*(b)cx;^5F%o~xp>W~^9S>z zM^aHMaqoqLyizy~wg=0nT>#K3kzIsj<(~8@2>Z!gZxXkdGuvD}*4_$ug3Xv{>lG`i z?f2uyr1w!+Df!(L$HUz+9C~8witg=IFWoP##=46=d7TH(eJDtiEPf`AJ3WMUbZxpT@!m~ZEM z;unukEgsuykQP>T~owx~fV!b^JNW%yzAE|Uy=)0eW9*8`B z<^x%Ds#+>OM4w#V-!9m9lWH{zV)s|wBgZz6b6lzQV{%E}D->jp1oTO+u&sV#t0QU; zg|4!+Sp@^+?$M$(VMxS^5 zY8Z}VPr4Uu7akHHXO{72Z(UWkGZ6PRR=jTN&rTlOuKoZxdLYfyvHq&`=HK+@>gqTW zDlWP9EFe%cEcYspNKY<|p9FJ#;SdWjvHtly^!IaRH#A&)Yp%NeJw^zkdF-}*^yXkn zXf!cjmB+kIb-OutHX#3it<$7?>@rkueQsS5?~D~&Jx?^qrlp44T>UtWiqO;8kO@T% zzUqlT&ftUx*)Cdai}>r`=KzJOzbPE!(X?$ktns9_`&E58tj=#oN8g9G6ekG@W%p^| zYiQ_LqL|C^6(?KmF3dVlc)UQ0cuz(D<{JJRlhg4Py49Iu#_*M9)`$e0EsglB)d~f@ zPU8(<9dcF;au$0_2uohqBbOtwg;8fHe=xc|@)R|6Ds#tTLWw^*tp=yXyx~~#WeD^{ z=6yn$WZS~~!h+8Q-8hxh^7VSOXqKtKThcHfGm>BelkqC!XH8G07Ahuy@cQ$AU6rFUC>*&%v? zb1QaDF*`e#{)IaH$EdjfTg;%h!%zjamH_GzDMS&3EK`DQbhaRB^3F2DJq;0`yW*jn z`I9wl4AKQbr{qDGq(QXn+Xw?%8Y&C)N}cMDOXoXf^$es7sSAeUk4sN6x88T`+iS54 zA&7u6;tR->M!t`y;k z&S~UOfAsS;!Fey;aYXp%i6JIlyobk2zVo}eCA(X(r`Gs6n?Qxq?vqa$GS{T8Efof0 zqX5;wNUJ7d{(yz->+8!;(gH@X)umzF^_OJvnL<5kOnf0uuRuz67(TCS6dS=|+|ez* zxBC~;)X|WK9VUM&2@)sFa7JmG{5XD1znI3xrpy@tc8PzK?L ze+1V6Q()Cas&Dl>WowpRZ@h}A+PLJGK9Hw{3qhOsxY&SH^nnX$XJ_@TRDT~c0jCM# z>gwZj6j4z#2~qrnp{L6FMF8RzS;N6N{{2Jz#b=&L7N*WUzO)uV&=o8B$ePB(qn&g@ zrN`eUqo5cu(nBE9Ec(n0+}sgKV&tG$hJo-960**nM8K)w+wqgQt;d_2m`xgvDXgjlf{qbgvQ`Y)No@ax{p!dt{0Lu)$< zt4!qET|^aS!>&;B?}q2*_F;`_}& z!ly?8%xGAQ%__l^ckYk3C+Rc89Ip}>^kT{=v%DvuMgA2+)cbl=RJ;l}{Gpdl2+&A( zX2sOFwILzrnw?zbB0VAb^O}GE5MI2XU)kC55x~QARzkBJ!}>IQd<0c$h|0}OJLB${wn6#oF_w;K!>iw(sgHj&7 z?0cPQWtxt6Z8@<`2jyDmkb!h>B;R|=uLFv2-e=^$&1zk4CHncRmQ~`d^g{Qh9t*%F%shk7>e6!|=2irsw`A zNoS|A-Q9s41oCj}zIrjW#^LGGxH>_`P zF|gPm@A#6$;5uY_SU0UqA}b0Z4mKx#qb7VPR8W)*&cG8@4xbHy1a16iG5VCP$sCtN zvGK;N(3pC282_@+F0j=<4<9A=sv|r0*7%7HpVGYrUaNfF+r&f-kl~Zo?v`JAS?f~r zas1<5UdToq*-X=O55=6%DbNq8WNw$i)-k{G^M|BMxz{S56GV3UM26FKoVxyf0M(B`hqW$p#;KOk%{^d?Y|PM7M0e#ZeGld`kJHqk+1By z$D0#_(Bpna1#nt%n-a`=mkEKyAI*0*A0x9r4C3Pbz$DDKu(TmiDP3RL3e7_#Ge4QW zo}WJx+HxmVkZx3TC`VZG75m%SL=3bBp|Wc>*V)EP$sjR*t{%6%0b4zY1R_B309P{^1j~K@PNm}_Mzm10xVT=i5R{wj+t5B@; z-9y#F)^@3opcj>M58@D`@Es6Tx1A8~A3ZB80yh7ChIz(DwmE()@`x9HYafnfD;&Q7 z^n;V*W~SA_EbrWp(=+?iPJERrGt>l)QrVWjpKa#O=u*RGqu<%c{G&lhpyi1ktD9xo z`l{&vJNE^Jz(l~h8jA3QC}ha`rMai)X>aZ?OQ5eh{aJQUTR+&0$0i!V*32yDRzrt{ ztuyqy=KeHuXqz{F%s?t|z8_`x+AS|TCo3W%pty-_^9vmaoPM=s7!X5N#B+&_qh(&PI-e^iw0Di!?s-9+zAXg1b84Z=$j)K>vHGi=Ee^(97y6AnzJd^f-$LV;KWBYd^DJwfa8a5pR&P@ zR0OmeJVRIaZqEps$J7|m^#SJ6ZZh|JHPT~iWC&Q8vjFDVwhA=@^cYK$@It%l)?>@M zbb7i%RG-Tn1K^H9zlsJ-i4j6$%y{AW<{@9dyErR>-j7f?J1&8@QH8I*gT-=P%$EY% zn)mO$I6fyB#HL5_TYTlyD6uNY{LDTbpJM5!_^Bi4<*MZ|pmOEqr_q#@j0(>;J-vVa zye=WHRsTixYzCs8?J{H)6g{z|lrb zE$dcqMV;7h_w=CB(~DX1zR1A9-?kZ-RaN-x9do)HDEqU4?+!y!%2Qh~PG+tg1e||g zCIx_6mG7IMBIEW-zIYWqE=z!P17c1n{ut4km9xHyoMm*h_@BXz-CvpQsx2qH9lB8) z`;D0S(}e0-xYd(qf7p1k68b7hY{{G9U@_Z3OsV1YjjFpfh~Evul+rYG^-Z(vKKC|i z8rm4ddlT8Lozs6r34|su?2w&{M|5l?M)yi{cB_}-u3F&2JRjYAgcpXr^Ox%J5ld?k zfJ7m#7sKJ8l68)g|8I2&g5k!S6}F#U%}K(-kiyEh^)ll*+~{b=-BtYz#7we_&WY^J z**~SHV0;UU+Bld9}?N!X~Lgn4Kw9RZ#^!!|0szBmseUE33w9)mo`O295qReeACQcT5zqN zO>7$-@q6Gh%k=2S`&3y4W-t)I0srw@=?;$mgj{|B0lD2aweSQy$k+W4(RMp^@dp?;$~aOHRIzXnXDkPWNuA=Eqm~CBpMwT*r%^dUI^q z>A5EnQpy;1Xk6{XQ|g-VIdy`#o|of7p?u}#7G=hAq&78_f5+~|NP9L~{(~#DcrQey z*dWV%%%1%q;RwnrNSk8e%*?80Y+oPq@o^j_dz|g-gHGQ*oG8$IRabu~InfpEw}4g( z11CLak&s|0=mG`sNzAlq|18PmvTJ_h%^lp^?~q7*l7AMstFjgC5Vw z4g2vx-;>d{Z3mL!y1d~eb7nMtt>Z7XzSOtWV-Kr25Y|EGud3%a&x};s%KY`e6`;BhXMEKeT>Ysec z|2K6KTF$83^J&yo<(QAv7XGpS1+cti4hTUeNE49 zpUw7O^}%i{Z6z#XH$`R+gw7=X(TCHi&ttHL6)#(v>AJ&;n2j>fgC!9HDHYC>faVZ* z< z*$rxPvO=}DmtP*eQGV{mz#}>$8d5)x*rQfn;=f>!%j&ng-w2(mfqA-}hpYm)dY-eB2xWN}H>B zZBo7b<#0MfMtbo!9b2GDRzW|RdNts>06*^-TUM8CAN(%_wdMXs+$hV=w-uH`gmimK z={_~BV@lH>C}lfdB_f&rBqk!6t}H}r4~?9P;CJZo)6{1G6uO-$m1xtIQr*|KIUWDe zoJJ0hzk9PdQX%Gl-0Xi=@OJVorG`8VnD-2&<;VmE®w_`d`gV3yjY{|b6NDG+(F z+Dfp*;kmaQ( zgpwxhnx_R<$?z+(zcBOG)xj(O-onKv&u}*Y!5QxL?cP`t?_fsj3Ui*C1C%hkGmf%^ z$sYlM5zvGrsp|LslzMZq9neG{PhO9SWE6y`=nDqj z1!%~VaeKI+f{24Yh5YfiTrykv1_s2|_N4heH8s^wYtsen8*a~)!^|IO3%vpGm`S1{nVrYa5Y=)!`dfCh0Rn_j zm(8`DmU7cSLw9JQWpjCopTxDauI}8wxVyF3n_>Ml8_BFdMt#r0e~v37)8hNY#B3_$ zfiq(6_mhS~fUxGc4Uesct@)l)-)3G`xg!LX*ly=n;_61Ce%o{7)XTJ^xpdD%0pY88 zN1%RdaOcWZOpDk`_r^Qh929y|N=iX#IE}EoixKkU;>s85%vWuxvKDu*Wq)CRHfT+r zGsd%^_-41J$(cGl94Iq+59(F4XZ=7A0hE}QjKol{eFad^uSSB(p%@Qe|YfeXzUdkFO8W_f}7`qNU|fp^x<*l}Vf9 z+x02ZF!KF&Fc*A>P3K}`N6!dbQY%|?u*bB|Ug&g&f1a-@{yN-FhZW!F`(0)kyOOSB z^qwFm@QUH4{V{Onv#wIpE&b^DdN^PK5W*Kt=Ch=>ysY-QhX2llv}W;fB?rB-yu0EP z!NZ`?HO(u*do2H}?Vn1ryc+5MDIF%=Eqm|wt=`ej?-WTXO#&|2>5S}b*t}wRpL@)j z(>GHG35bU|Ug1ztpIgzuFOQy>l zZ<11~->-5khf1P!O3D!^VSpbBTM(z(Eg3Tut#Kydl|mLJ6|7d}8?C3syj)qg74JK1 zqvgZ=-$6!^ufNp&tRL@uyoS4;YObq7cMxFrU zy=`(ee)9{8O^Y-aD0ZEByyvqX2J_rCP`)Xl7=tPHpceiW#~_Mi2NgY5RGB@$`p=xo z`J@hit(U+6ol>0*-51L12quiX^RW>$^2N>1gd`q?-giNn5G1yO6h63@FIncUZ(wYj z7@}UW8L%>c(y1vk?KRjX-rWT%GF%^oy4kmEFwIY_1A6?<$ONJ!0QNE5Rij{6){+33 zr$QDC2C|Hdoa=`~Pa*)daLWfu1nRPl>NGdOUM;chr({kr0@elnxsL`&wEuEHk*SVl zmI8e>KffhjfzQpagDx~gMc+FXMm{U?)7eU-&m^o){;gTn7ESH5|9%xqNjVOSGU+*JN?!^@FQXL%yo@TU$)hH`Q zs~s^1%AqYXb{luqdc%Pp&49gR9VTAk=PqFSe)*uNT8qN@>`>y z!!$xH_uUC11dA9x~48ZFS z`0DB)!=iXv2~`1*Gp=>N3>n~XA=J4u7)Bd1ePBJn+b-COB zOAF9)ePUf*n*X_O@THk|H`sJ*F7-P*Ee}^Hnt63_l|*j$_C{nwCu@>%^eniSe+YP? zVNv_LWS0!c!9|17zndPaV9~`=(IH4^8iIv7xw*)=cmhh?(Uu*gdWqHR$=mxmU+WEDh<=CA(S=MtUcBI}$q(dspoKg__2F0wzUgL@8?t=7 zV&8x~8uHxV_^-y)iwhKvpify|Ny+w%Wby~mv%DL~#P&*fr2@aa3t5j9>zWKh0(w*M z0cb3<0bS0_{V)9N*Mb%h^RGM~E^=$xfhrUOd#v&yi;Rt5%WElG?5RlVeS(`g5V;s# z9SR=S!_*XYpg@|MN?bo!52-0bx|3fI!KnUDpV-n233?7ayH|(7E6Wmz2iIt$Q`U0` z4Hw^mV?#{$ZL++RN~0F4|17yu^r7t=Vz$d<%~42wBVW^XHWYB%5b*yd7QK&zPet9%Octy%~{j4aaLGWQ&Ab33uzBsp*D@t z;ff|UalgK+w`yM=(cIX8;W9&7n}e{MgeeOocrEV#+^YpCrV8YQVoCY_GEp`1ki--x){S~laCA$%ViX;?S7!J_$ zZDQ9+65(mndK-T12*LRn(zb8GZIUZK4(05V#b)J47ohds?SNMv&TO6y_p>{i@dgBxvwK}DGV3NqJ_`|hzicY*f4-toWyBP=#DhG`^_1(( zqJOUK(_*6yrn4~jA_53Gx4#NZ+#tFbL^T&;YTEW-)E>lh*XZ28fkq_<&+Uc+rxKJ| zau}ud?OPj=B1q9AZJHsfWgl8y?qf8Z$O@Ycqe+1J#kSEInQy^~V03g&S=n%R_t3dE z?B*=3+VQZ7*c|{W{X1i}#`Omz8CfPMe>Y#vg5&nY>nl zTYMj>zosAhn{X0B{%-kVyaGuHB5i zmo!D14NAFtI2+ zxFf<(WH5s2{ny15IOxE`BS8(j5di{x$m#u1@>(O;QR7vxV^C-{?DsU+Th&s15f!xr zhy*{NQ&_CR|dJ2w--ev$C&PANTG!2#n;bM z%myW%Fm)x-gDEk?A)YQVh`NJrOoNE!IBYwj1Me7*-lflkHB1B>e=d? zJOY?+_uk87q6Aq-RU;(ZOe5%VgwPVj!ik3junQg=P5YgMUcM1@ z-6dnUgT%b*f@q&jto)@R?|eX9&FGYg{sCKQ!SiM)L#}tG;==aLuQEbmf+`=M3pUX0 zgL?2NFI{Xl$*lMLqm>oMP%4AOyC|C_)O;NIx5S~M-cYvg`46v6IH55S0b}PoH5DK& zQ=xCQLn$7gC9*LxI@Ybl(l|UETuf=rVj8pXhez3!3JiuXv!@=(d@AJHTWS_VGe@UD zcU=x>8Z;Q`D^T{={n=_ZP0q2K6Klso^TM^%V2bVM1g~IoN}ON)R0-u)BwI%{i{}NF z4(;xvI+S3fZsqV-q7!j4&(^leavS`@NfcpA7-rp?{hD?utMtLZ@Gzc_Pu)iO-sM7A zBvV&sq^UwkNK_Q#*RN`>ySQw6TSLKn^R;;mj)=duhNZrI2`oq@5ibmW_bXtq%*ZZ@ zJxhiq3yP*UlVZF39TUNcixz;wNj&`x&K5G1l#~F=r(QkrO^WV3c)YK;CYuOA@V#y) zH{3WxYrb~V{lSY0u1efIBEDPNHy|ycfrpGnhO<;rRvCQI6JN)QW?(???Pa)kguc^w z_^SM4@aGLYwi0wS$1MkY`dx>2Gp=xuD%)Yu0mHD`MC=@?Dst>+{d>-}y};I>k%#OM zF;Gg=c{A#<4w}N}nm+=8jO8i>7QRLASoigxk-S3;UAu;AeAjSW4X1-_-y+J9iN!F* zibk}xhwAvWFTqFrDCflK?v_gX`a--KGx{%f>}$$hD>4uH;I_7==h?binmVe_Qq!h* z^$Nnu>cBNMBK&_9_MPEyebKu|?>)LO(Sm5vJHsfE5TZtn7NSQ&ln~t@TBIYo45B4O zH%b_Sh~7IfdWjbGzvuow-RHUG>zO(G?0xpyYrU(zhlQiAXw;@SQ+a*?|7~eV{7v}qdubVtvZOoa?Bd{ndDwe!0eQ!ch@8{y2L#knCEQ_T850aAfExCG-WWT~ z+(g!$3XPCeBS^iJcDiLhonQ^wo?s%8%1xPl2yyu~#L46lRtB7{KfM>jT7+J=0H zV7AeTEZZiMQ^fG7qIchpXV6)4)a6t-99VK#xE}9}6yH`fZ}7jFjcnkx^8zC;s&p3emI!it_H1c;GA3Lj=C|9ty1%gP zjBCXEt*&@6{3MkkMNWmG=LfL0NdCK~c6*M~#D+vf!^k8tEua)Y8=<$Kj0!)XLc-Tx z`(EdzRy?d;Vwz?}(jJP}n;26hctgWUE84~lh2W2{^p_KM_sHHq@Yu5eyM}t^HC>zr zx(SZ|OnQln!e}pr$S`c1N!WWxbVitt8-y}<; zqSr=h-B~z!={v2hZ@Ns%Ubp)c5Uxib079D)RV z$s&lUTB|S5iPBf5Qa5w3iE zIjFxzh?mbSsy4q#b$RT6d~wXPp_Qc7@uyc#(Hlk&8a$nhZfh{m0f3i4^}4Can}VY4 zefK-N^%atX1omTjSTnZLhnQqd0)zxAcw9;Lyh(24(eU6oTP!!N>ii&IZL8rsi>n58 zyXhh0_Y$vNV+lBubEKwD=ulePn!fS2kb?Hmp+j7a*08?3yjr_&A|DHM{8#o;nKMPe zV3gmJsme9GeaUH|$#)_6kAa$pyfxT8(wAx0A%EZQiVmoG#!yFm6R>FY+%P}RR3Ivz zXXZY3Oev>EH+&sxm; z0wE+?jpdZrX;(bvI-{5`_bG4A#%lPVtbVr450TM`Zocec9i!y@5|sPBK8Kqx-|#+w z|Ew@1%K8e20x#!{wGb6n&|Yi(Dl?O-)TTbp%qD=SIuAW((xu@~V<(psfeM=!G{mp0 ziDY?>T&Y0NBW-zOcJ~MGE}kT;zn5^*EgtCus`9wKy#*{~x3O-ET;n4pZJ#R5(tEEM z1MW2i<5d1w)zm3mwX@%!$21m{j9 zLtr*bZ6{o4AkWMot2Z3M4L2~L9VxYrk7c<2{r>sVuU{+y8!V+gA0k>ovTf^=vbSyB z5LP$$F~YbTLR> z2JB1S>^JQR54UHNdV20`%rvqG9c{HAMA~{6N@)q_RvOwjH{TF2^qKXujh zoYGEn7ii1`KCM$`(^&p=^2pDQRi(U-u-=4kx|L8v}joqoNh) zL0(k#k|WqAkW5}=YPR+9&nu){&qMj3q4Se#4&6-Y2ZvgK7%W#pq{Kt$4q_Tm5%^jr zCML3|JeRYwvg)yBRO4=Grec5K=2#`;5JH@Mve&(%>_d2nhet_^7?yIt$%+Zc$otyiZk_-)*WoonH$6EB z2-`3y6Fw`R661ix@XjDt<1efi2MJwVGWvL5@fTQSTfSI7~7u`w~-#dQ%Qt5Hd<4~PjH=i9KQCC5XJf+LHr6qyjM;06mHjV6= zV$AxrelTi_Io(EkeP01VHU_{0_M`)JF`d09k9lLQVu2An+hfP0feJF%~7!Fw*k!a&gP6 zfF}<|iXRsj*TcjCH4hFl`1$#5URX6kyB+KYc-%@HoHtCtzWBm{Ua@a!Y0+7QdIyBw zkS}&5XgqydIlcy1YQjn^s}~m9;|&Up!Qi!p;St#&#nXQME;pY9{fEhF9=8>JV$vK@ zqyu;f!*WW;FfC3+V)T0!IpD4IY)<+*z(Dv=hL7)0DJNYO{&$cxC@!X;rLu&n=iM_V z_&wD`wZHLbONhQ-**>0tu8OsSXkqEr($Q)JEA;C6o#q5k@~G+awYFFrafG9HnMeou ztc5>4Ew`a7czAW9FIyrW2hXd6Dd+>TIpjpICbSiF)VjTNOOBA}+WKPBW6$3(+^@Ke zpU40=1Cb<0r(Vw{r+x@F4*@o>)14zcd@g8-^vvD?2&DqqFTh&#?a6yNx+d+!EICo? z!jzQGlVbd(C?dKhoA+7>L+4Hw?8kbBAPK*20L$6SE|gC7^=J zq3*U@KpbYiGBPZ>|T|wp#rD>obwtk6v(N$q76)(%3n5U)9eFa_NmxRV{5^u zuWyZ7ROL+kXUGLBM4SAYaQ))E*NR7iv0ey?>aO5YDnJr|L*r zDrOEHC<~XTesyIGVUr~OM?x*d$_A+c#J^9Y`a|B!Yw5-1`T27)#8oCsAcx&wX(%JN zX;ib8_8*;#zPz3piTU}4ze+97Yb`a+IWho*48ZSEZ5t{K)9u0SX`yl>rcw@ z4Z)`nT+P>zuJl(1MJ88BsE}NZ2pW;&hwCe~w#kJ+2U6!uWBoW}Xl;&MGAaJ?cP5_6 z4nzx+C&pNWK@A^0upa~my=lKqO}Te#SH%BJNGAqmiAGs7B8EJMh)BW0aC#jaX2fU| zuy(}t;yz8s_|p0Lb#9oXn4^vay=Y>{;NW-CDqXle-lGeSv5$6r#2bxkzl>j12+j&aMaf?fBHny;`_#^Z3^0p zOBZz1J82OYQBYhn5r94Oi{3;TVt3!6o9$W&BSuY~oELwc96-%Q1hvI(#h~%D4VUh-X@d;?mq@>W+5+fjwnn?ecxFgklNg$^ z_S=(hN9(|32lixoRo=mEx0rcogBM!*xK`mN9e7PJfJXN%YG}_#OCow&;AJoQWtppI zgPEZRt7~x|2k!AkM!{1v%gjp82KWGKqex=BF<14FN@#Gvd$|H*5O~oLQX9{la(Xb@ zIaAA^LPDc%|ETct-*WfD-wjNn=IXz{H5K01B0sWK+|l%rh|^D3J0am}J|8xluktJD z-;TIx0)mdDRGRbiZNz9*O-$mo&CTkYJF}Nsea@e1S5^$VaYRnTU%6zd!QRHMD1Y+D zuYM~M@jVCs&FX5++#*5Ja(6%INoP7dJUZj>aN-L|lOl6MpA$pLosQm=WMTHrkPaic zab7_V&~GNJtf4U2lSvtHiE^quyDNwZgIOGLD_bpy2SEicNn+q#y-rso0b2~gJT@)H z64;`amb)Jxo%rf_xIb9grumS|6SufvU~NnY8bt%IJd<$`Jsrr`QxS7mH=P!H3J(od zgE+WCSnj#GUBPtZz!ccj^{57B0x5StFNW^Y*}L|=OkP(H#3v)&XZ!boeLuF{7qc2Zsi zXC#Lo=UMEWA3f&b#)k~ve27gGYmCg}yZt~lL@6Ek*$z6S?&oI~m3#9UFV1gMQjOTy zumtQ2d}(ah|LJl=C>bakPxKKd1OpbNUrd5tLR&lH=!;t|w)O$u3Hr3O1~SpRMJC$! zDItg9Is}36oUvRN80dX;+&dz%5GhsOjbvd1en&^Lb^QZLN2E;!P;`ia zSA4WmY`kSwWT(x|Zdd6cuJ;zu78M&l-{XDt z4p1rPYA?S2CMgOE`S)p5)Rr?8duJqp>Dl$iZcQhs6J(uIOs;1<`_bq6v)eG_ps4>; z;Z8b=f`H1jq_Vs^W^~ePl$o9oVEvbNL5Ij}JcyTxiKWuFc` zq@d8r)Vr;c68Dtu+I;W928W1w&8mRy1~etpQ*%$S2Du>20gkaOfc7{h z<(Mtd+Dd0A8K{kT(6ii)Jv~Be{8<{p{#{$JUji69EuMMtWeka^URrcL85!|*ehDfR z_@aTJ?F1ZPn$z9IwCANiTJb^PYau}I{)hg+K(BH9SgRRqaD9L7!NbTJ^obDf*AA** zK==gMC|#t!8@@Nr7N6kmUukDk$x;>f|KE__{5c_3RFJYRlJ_9)e{go!$&)V$evbwA8w- zmG<5Ew}f9T6(GVowBxNA)lC>nRZoS1NHz!j>3O(q8L&dV#m}pj z@tzb|DFO6Tvi9BG-!qLj-qKZ0@RwC@j1OYT-%weyQ2HherA$o7SeikAM@81Mz>d@~ zt)@2s=qp!Of>#Jp%;t;B`f)d4o@`!BA#T%DapDf%DeQ?)_1E^^E$O zrPu01S(mDss;7eK&OI(?x2*yBxO#YaySHuMTJrHPwV{f+ zmAYfOiM;@FA|U^a8u%slwZMQ_QIf&CK1e2P+u7l@gYKTI(&WDeKl1?L1j^fO;M-)X z;GiK99Hn~GZdgxEmKf21$o@^iRp8<}LiWFw#ZBOOxqZ1XvbP*+8V^j!OT4N&?}AgZpye1q&=$Khe-I|zw;0~CUjzpDwdFz&^RwIs~~Tw ziD@!t1bD{?1o0RNA+mQJgf_5DN)m>80kty{T{00Q@fgkPcjGVsHn37r0dWC-EOJF; zTr9VQkyFLJk_b_3I@*_)tg|n3A))mLYmR;x0n2J`_8COKYj`e?Q-R=svTs~ukF*1; z>lo^LdEuQQsjY;Td7<)C%+~Wz0iFxr`|7kH77$e}yP=gpuL|O+SCT~19yRsNR8gq= zR{7fuhK09H7n`+Hl~Hz$eI+uve;BM0j(C!_gQk90vM`igJ}NE z2FL6tu*-L3U&UEM>Fin6OEL;YMJSYCj7Ak$C!p&oMJ4h~iVb~Eq(aCj5hpQRaoa(q zR)wH{ z^n3uin$*Mu1lEZ-MwpGTi>Q$7STl6{Fz;ksr-nXgL@e1QN>a?~JcU;l8x){uaN|=aZsOKA!Xr=&M_~-3G|(=@>c$fuUlB0Nx#_L)dBV2K(LV8W_blN@@fVJ_p&b)x3flVFDI~)w`FB1 z$7>nP{`7mA$@uC<&uGJ-w&lji+FnSF(r3LgSdqoD=#%w(LUi-1&ZtpGAn ztD`_Kup2SDYuiG9eOVs;g833>)skAV!tA)$k z6K()EIg{BY)Tzt{f<{#@?^n;iMuZpj+}RDL$iK&7Rp|bk$Q~K|AgiY4RYiu<8;zK_ zqu1=LVlbmZ@uk$e-a*p}IP*3@!JGvw8ow_KInV)G!m$uMjq}tCN@{^Z7NrGdbn2S4L7i+}z$vohe#9SBJ;J zrw3ec-w4=ttFk~1yE-~K*&VD6Bi+mYqU3k3Ta$eAS=N1G7KXgTYg7mpzjdl|@5T+C zk}nq7T7P&_x+j&6b%aF{JiiQ&J2^RB6BO*48g^lFHo" "+" "1j" "*" term -> kkr_term - - ?expression: term - | expression "+" term -> add - | expression "-" term -> sub - - ?term: factor - | term "*" factor -> mul - | term "/" factor -> div - - ?factor: power - | power "**" power -> power - - - ?power: "(" expression ")" - | FUNC "(" expression ")" -> func - | "sum" "[" repeated_expression "]" -> sum_expr - | NAME -> single_param_name - | SIGNED_NUMBER -> number - | BUILTIN -> builtin - - ?repeated_expression: repeated_term - | repeated_expression "+" repeated_term -> add - | repeated_expression "-" repeated_term -> sub - - - ?repeated_term: repeated_factor - | repeated_term "*" repeated_factor -> mul - | repeated_term "/" repeated_factor -> div - - ?repeated_factor: repeated_power - | repeated_power "**" repeated_power -> power - - ?repeated_power: "(" repeated_expression ")" - | FUNC "(" repeated_expression ")" -> func - | SIGNED_NUMBER -> number - | NAME -> param_name - | BUILTIN -> builtin - - FUNC.1: "sin" | "cos" | "tan" | "sqrt" | "dawsn" | "ln" | "log" | "heaviside" - BUILTIN.1: "1j" | "pi" | "eps_0" | "hbar" | "h" | "c" - - %import common.CNAME -> NAME - %import common.SIGNED_NUMBER - %import common.WS_INLINE - - %ignore WS_INLINE - diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst deleted file mode 100644 index dce0dad05b..0000000000 --- a/manual/source/em-structure.rst +++ /dev/null @@ -1,151 +0,0 @@ -.. _Em-Structure: - -======================= -B1: Electron microscopy -======================= - -.. index:: - IntroductionEm - EmAppDef - EmBC - EmCommonBC - EmPartnerClasses - EmDeprecated - - - -.. _IntroductionEm: - -Introduction -############ - -Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. Realizing that we need to start somewhere, though, we focus for now on the condensed-matter physics, chemical physics of solids, and materials science applications of electron microscopy. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. Partner consortia in the German National Research Data Infrastructure are here NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. - -Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it additionally difficult to keep track of workflows and challenging to identify which specific quantities in the control software mean and represent in technical detail which physical quantity (and how these -quantities can be connected to the development of ontologies for electron microscopy experiments). - -.. _EmAppDef: - -Application Definitions -####################### - -We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet remains easy enough and useful across a variety of instruments, technology partners, and instrument use cases. Therefore, we conceptualized first the basic components of an electron microscope and the usual workflow how an electron microscope is used. That is scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments or prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. The session ends with the scientist removing -the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as session on the microscope. Next, we wrote base classes to describe these steps and events. - - :ref:`NXem`: - A general application definition which explores the possibilities of electron microscopes. - -.. _EmBC: - -Base Classes -############ - -We developed entirely new base classes. Some of them are also used for other techniques of this proposal but mentioned here for the sake of completeness: - - - :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: - Base classes to describe procedures and values for the calibration of aberrations based on either CEOS or Nion. - - :ref:`NXaperture_em`: - A base class to describe an aperture. - - :ref:`NXchamber`: - A base class to describe the chamber as a part of the microscope or storage unit for transferring specimens in-between or within an instrument. - - :ref:`NXcoordinate_system_set`: - A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. - - :ref:`NXcorrector_cs`: - A base class to describe details about corrective lens or compound lens devices which reduce the aberration of an electron beam. - - :ref:`NXebeam_column`: - A base class serving the possibility to group the components relevant for generating and shaping the electron beam in an electron microscope. - - :ref:`NXevent_data_em`: - A base class representing a container to hold time-stamped and microscope-state-annotated data during a session at an electron microscope. - - :ref:`NXevent_data_em_set`: - A base class to group all :ref:`NXevent_data_em` instances. - - :ref:`NXibeam_column`: - A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused ion beam (milling) capabilities. - - :ref:`NXimage_set`: - Base classes for storing acquisition details for individual images or stacks of images. Specialized versions can be defined and use controlled vocabulary terms for group name prefixes like **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction, **ronchigram** - convergent beam diffraction pattern, or **se** secondary electron. - - :ref:`NXinteraction_vol_em`: - A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. - - :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. - - :ref:`NXlens_em`: - A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. - - :ref:`NXoptical_system_em`: - A base class to store for now qualitative and quantitative values of frequent interest which are affected by the interplay of the components and state of an electron microscope. - Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. - - :ref:`NXpeak`: - A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. - - :ref:`NXpump`: - A base class to describe details about a pump in an instrument. - - :ref:`NXscanbox_em`: - A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. - - :ref:`NXspectrum_set`: - Base class and specializations comparable to NXimage_set but for storing spectra. Specialized base classes should use controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. - - :ref:`NXstage_lab`: - As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. - - :ref:`NXcircuit_board`:, :ref:`NXadc`, and :ref:`NXdac`: - Base classes to describe electronic components of an electron microscope. These base classes need still to be harmonized with those used in the field of low-temperature scanning probe microscopy. - -.. _EmCommonBC: - -Common Base Classes -################### - -We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em` and :ref:`NXxraylens` have similarities. -It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general -base class lenses. We understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. - -The first result of such consolidations is the NXem_ebsd partner application definition. - -.. _EmPartnerClasses: - -Partner application definitions -############################### - -A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize these pieces of information in an own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that the pattern are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. in post-processing of these data. These numerical and algorithmic steps define computational workflows were data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints trigger the need for having an own but almost similar application definition. For this reason we use the concept of partner application definition which have fields/links where specifically relevant sources of information are connected to e.g. NXem. - -The first partner application definition is NXem_ebsd. - - :ref:`NXem_ebsd`: - Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- and four-dimensional case. - -Several new base classes are used by this application definition. - - :ref:`NXem_ebsd_conventions`: - A collection of reference frames and rotation conventions necessary to interpret the alignment and orientation data. - - :ref:`NXem_ebsd_crystal_structure_model`: - A description of a crystalline phase/structure used for a forward simulation using kinetic or dynamic diffraction theory to generate simulated diffraction pattern against which measured pattern can be indexed. - - -.. _EmDeprecated: - -Deprecated -########## - -In April/May 2023, we refactored the design of the NXimage_set and NXspectrum set base classes. Therefore, the following base classes should not longer be used: -NXimage_set_em_bf, NXimage_set_em_bse, NXimage_set_em_chamber, NXimage_set_em_df, NXimage_set_em_diffrac, NXimage_set_em_ecci, NXimage_set_em_kikuchi, NXimage_set_em_ronchigram, NXimage_set_em_se, NXimage_set_em, NXspectrum_set_em_eels, NXspectrum_set_em_xray, NXspectrum_set_em_auger, NXspectrum_set_em_cathodolum. - -With the NeXus 2022.06 Code Camp, we refactored the NXem application definition. Therefore, the following base classes and application definitions should no longer be used: -NXem_nion (replaced by :ref:`NXem`), NXfib (replaced by :ref:`NXibeam_column`). diff --git a/manual/source/fairmat-cover.rst b/manual/source/fairmat-cover.rst deleted file mode 100644 index d86dd303ec..0000000000 --- a/manual/source/fairmat-cover.rst +++ /dev/null @@ -1,146 +0,0 @@ -.. _FairmatCover: - -======================= -FAIRmat-NeXus Proposal -======================= - -.. index:: - IntroductionCover - OurScope - Outreach - WhichData - WhatIsNew - -Aim -######################### - -Experiments nowadays create a set of very often voluminous and diverse numerical data and metadata. -These pieces of information represent entities of what is effectively a graph of materials data. -This graph can have a very large number of nodes and edges representing the large variety of -relations which scientists ideally want to identify and master -when transforming experimental research into knowledge. - -Experimentalists face the challenge that these pieces of information come at different levels -of granularity and format, of which many need to be better documented. You have very likely experienced -yourself how file and data formats are routinely encountered tasks to master in your daily -research practice and you might have questioned how these formats are currently handled -when you want to produce FAIR research data and publications. - -The NeXus-FAIRmat proposal is an interdisciplinary data science activity initiated by scientists of the -condensed-matter physics community which strives to develop community-maintained open file and data formats -for describing specific experimental techniques, their numerical data and metadata, -and strategies how to exchange these pieces of information. - -.. _IntroductionCover: - -The FAIRmat proposal to NeXus is an effort by the community of scientists of the `FAIRmat consortium `_ -to refine and expand the structure of NeXus. As a project which aims at creating an infrastructure -for experimental data to be findable, accessible, interoperable, and reusable (FAIR) in the fields of -condensed-matter physics and the chemical physics of solids, FAIRmat has adopted NeXus as the common format. - -`NeXus `_ is a common data exchange format which has its origin in the community of -scientists performing neutron, x-ray, and muon experiments. The development of NeXus is coordinated by the -NeXus International Advisory Committee (NIAC). -NeXus defines a schema of data entries with a controlled vocabulary and defined relations between the entries. -NeXus offers not only tools to document these schema definitions in a version-controlled manner but -also tools to check and verify how and if specific instances of NeXus schemata comply with the intended -schema definition when the data are written to files. Although, the Hierarchical Data Format (HDF5) is the -most commonly used file format to write NeXus file to, NeXus can also be used with other file formats. - -NeXus defines domain-specific rules for organizing data in e.g. HDF5 files (:ref:`application.definitions`) -and defines a dictionary of well-defined domain-specific (a vocabulary) of terms (:ref:`base.class.definitions`). -The meta- and numerical data in a NeXus file represent a hierarchical graph which encodes a specifically -granularized representation of relevant pieces of information and results that should be stored with -an experiment. - -Base classes and application definitions are two key components of the NeXus data model. -A base class represents a set of numerical data and metadata which specify details about -scientists, projects, instruments, and other physical devices, including the numerical data -and metadata which are deemed relevant for their description and the associated -computational analyses. Application definitions are constructed from combining such experiment- -and research-question-specifically customized base classes. - -In this combination, an application definition is a data contract between -a producer and a consumer of these scientific data. - -This design has sufficient flexibility to cover any experimental technique and instrumentation, while -ensuring rigorous, application-specific structures that can be processed in an automated manner. - -In cases where base classes or application definitions have not yet been proposed advantage of NeXus can be taken -if the respective scientific community explicitly designs, implements, uses, and continuously evolves -these classes and definitions. Here the role of the NIAC is to support the community with -data modeling and data science technical expertise, thus taking an important role of -cross-disciplinary review. - -The NeXus-FAIRmat proposal represents the results of this development for experiments and use cases which have not yet used NeXus. -Specifically, the proposal includes cases in the materials-science-branch of electron microscopy (EM), photo-emission spectroscopy, -ellipsometry, and the field of atom probe tomography and related field-ion microscopy, here jointly referred to as atom probe microscopy. - - -The documentation available here includes parts of the contents of the NeXus User Manual (also available `here `_), -reported here for the convenience of the user, but is restricted to the parts most pertinent to the our proposal. - -For more extensive information, please visit the original manual. - -.. _OurScope: - -Our scope and perspective -######################### - -Thanks to a cooperative approach across a wide variety of experimental techniques, -the NeXus-FAIRmat proposal of the FAIRmat project has an opportunity -to expand the set of data/metadata accurately described via NeXus. - -With a closely-connected team of domain experts, we will develop such expansion while at the same time maintaining -a consistent structure across different techniques and methods, striving for the maximum simplicity of use. - -Achieving a standardized and FAIR data structure has a wide spectrum of advantages, ranging from radical -progress in scientific transparency to the development of new, far-reaching tools that can be shared across -the whole scientific community. The convenience of such tools can range from guaranteeing data reusability within -a single lab, to enabling open-source availability of ready-to-use advanced analysis software. - -Perhaps the greatest resource, however, is the inclusion of experimental datasets in the `NOMAD Laboratory `_: -a data infrastructure that already hosts the largest computational material science repository in the world, representing a -homogeneous and machine-readable archive, a human-accessible encyclopedia of materials data -with tools for automated artificial intelligence analyses and data access. - -.. _Outreach: - -Outreach to the community -########################## - -A data infrastructure is not effective if it does not integrate seamlessly in the day-to-day workflow of a laboratory. -For this reason, we approach our newly developed NeXus proposal as a community-driven development. -We have drafted an accurate and consistent expansion of NeXus capabilities for a number of lab-based techniques, -but need extensive testing and tweaking of its characteristics by the community. - -If your data is generated with these techniques and you are interested in producing FAIR data and accessing the FAIRmat tools, we -invite you to try out our proposed structure. If you find any conflicts or inconsistencies, please raise them to us using the -comment section. These comments are implemented with `Hypothesis `_, a modern web annotation -tool from the journalism community. The commenting function for each page of the proposal enable you to contribute to the -creation of a more consistent and practical NeXus structure which, in our firm belief, can serve your community and beyond. - -If you do not find your specific experimental technique but would be interested in participating in the development -of a standard using NeXus, feel also very much invited to contact us directly at the `FAIRmat-Team `_. - -.. _WhichData: - -Which data should I convert? -############################ - -You are free to choose at which point in the workflow you wish to convert the data to NeXus, as its flexibility allows to -describe raw data, pre-processed data and fully processed data. As an entry step, we suggest to use a test dataset -that is fully processed and already published (or, alternatively, of negligible scientific content). These datasets, indeed, require often the most -extensive metadata description, but are most easily converted to NeXus, with minimal to no impact on the data processing pipeline. - -In fact, a low barrier (but high yield!) way to participate to FAIRmat consists in converting only fully processed datasets that -are used for a publication, and publishing them via FAIRmat only when your manuscript is in press. This makes the task of -converting to NeXus much more sporadic than fairifying raw data, to the point that it may be even acceptable not to automate it. At the same time, -it guarantees full control on the data until publication. We are confident that if you take this approach, more appetite will come with eating, -and you will be naturally inclined to gradually integrate FAIRmat structures and tools further in your workflow. - - -.. _WhatIsNew: - -.. What is New? -.. ############## diff --git a/manual/source/img/FAIRmat.png b/manual/source/img/FAIRmat.png deleted file mode 100644 index 034aa452deb2c7695940d513cf0efe94291a1d69..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 114746 zcmeFZhd-77|37}AXc&1VWs8bRD0_8OMzSLzvqH$;`?QdiO0p??6S6rnLu7}HjAUi+ z^?O|Bc)i}=f8lq#eY(|+bI$X+uIKYH?vMLpoL;IZ$x8mT=`z_rr233@kQ~vt`%f?wl^zRFm122UC{T=a( zJ4W{J3rT94k$-=}p9NCXJf6 z{TfReQeJEk>>I^M8m{DlrIiyOg{j<_l9 zS^f{k@f#C++oN}C_S{ahAezsGtU65QSrqH2>$5wCV6o)c^C*vzydw}n?Gs;#3D}E| z^;%S6Mt)nkag20*E!^8$J4s#7{#F}S#XTk5+01OkchKK=ceirS3ghMHysK`E@V2)8 z%1f_QHr`3^0mBSL=1uZ;{fSyQJ9 z_Y5hI7tb;kqZ^S9!_%ib-_2wh8Izv&-}sh9-P)Jbf#BB6_}M*+Zy6Q(L2m>mIcika>^IXZ7!XvE44-nYmG8y}X`{@-=s%<0vCz z^(p=5o|Tm+)wkFJ_6nUQT7)^iOX=W>OPC^ii!ytVtnEPr!Jg&AbFt9OjzHm3zdv)W zPEVUZ`20oYAMNaHcw}lzc$7EUT0Qbp8VwNb8XA3W0c5Rms@Vs6&mc{${D(w zPmJt64qjMVd}ZP-(@_8`u_Bl8g82PGLwQ;?J)d}Xql4dr6j?9T5IfPHHnQ$ev+?q9 zHmsbF##_j++sf)~x-5^OivAw~fu+SskMt`4(Kr_rwPzE5om zLwrcEy3MzZ!Wl;}DecTTI#_yzpzXi$9f7CF?=BfGgYaURI*gFGHig>NJN9-=Hv9qW z&f}tB&NvJ&ULw14=}b1Or!#Nrc75e?dOM343@`<0tho(6k|`5?>AWO(->#_uG6<{{ zVSPnXo5Jy5pPd>v!aaA--@oE$L8PhNFP5sJ;kS0u^#0GsQ+?>&S@6jPj-_jgy8I+{ zd3jg#p|wkIZ7$Rj;Y3Rqlh2!<4d1uZEFReTc3q=7{3z;}l!?-nUS4auSS_8fk{z8j zO^(}~q-unh+n;GYFzEqc(SetC}OD>tcvx3;DiST}x)j%)<2m?0Ujv?WFcikd%d z=>tOWkWuSr={mu}?$E<%f|8M~EpcDi&w0twBPs1Mf5$CNMDrwB^$I6EZK=6*!F8t@ zR?VNpdt^?`<}=^H!Og2&p51~Hq}W9ZOX(;N&DK~C!9Y+?RBQ~WC=xO^Z0+H-sx6`DC$^Py^{q81pA~OgnkOUgnF>s$zs(o4AF!Bn7N(T! z71fP(@RA@Ah zsCbuVYluZhddJ%b!Sk`icyq>0m0onv+S_n$?E{gIBRI3ti_Qzy@Q@Ao`|@ip+%tn8 zpJQs=OJ=xyD&oLW`MFWwSg$uENct?m+wV}uiu!L3HEp~jqwlz2xu%>(5*F+A_AQ{ZZ0O>wd9MVTF;?zCpJc zk&7uBubhQ6-snF^jWbFh4c*5fyeKp&3S6ZCksL2pU#gSgGa^UQlh&@&S*kjgPHv9} zz(SlK-sG`U)Ak)Vegr0Q(OL)wI(G{mB*k{MJxcmQ>+fU-(v(sd1L%@;z+;i5LqQ+4 z)u0SxP{^;)M2%O%ry7Z{T{gmRsy>0e_0D|jSC>M)X@AF4rrV!O>%?FJ*SF;; z5%qpuml$z8f}cafr^4Gs}R#p3+~wTE_*ifZToZmZM6 ze$}7i%|^X?RmnAFVCb%Q`cny9H*ktlGjDb4-ImF(mjV@odSNH!G^0F^P4O`h@%*>q%uT>De_*bN~>8EyG*rj(^1qQbNC5H=ksuv}@6I^NG zCaP%h2t1mJ>m@VTI3|)8T9V$NLvqAh=%(W}lzX;pqx^zl)jXjnBmQ$BA+%bxMn;W! z+SslBh8YqX-?0*&7bF-lnX&QPLaJKpI4I61_sR+Qv1QKB4zM?n#nnCV%|S}`8WHv& z1fDb6<8FVuQ(BTf!HtLY34+*JCZn#@IbZ$yF+aPj8*J6al_%ua`mEj$e`g`bRdl5u z-W-NwE#{;c$t8k+&k;nXjf7P~IFB37zUt*C>`Hgp#tYrB1KuR&9e@&o3zdngdXG+< zt?-K+11`rKLbT^8V<8+5qMdglEHo)_jW}c?aA9p_+cct^7+Lymmi*=T&-#UF-=*Wn z%|U1DEO=jE*R|rwz>h;+Aj}Nsiw;^2DLw|(zwSAn>24h?FH-54dL5|nQ^h)GK*dGFFR6kBQxfl z$N7n+@qX&eX*Epcsjnmk?i~OJO=rxmLA=BD~EiJ zr@cn_xCN~BOGG)9N*dVy8r#Q8o};1WSCkTkk)l^kHW4ESo32F4M8(Q5Mk;{2tFT>E zgG+7|l*g0HGG{tUC0`^%c6F_k>4L`7yE;UAU4R?K-NYkUVo8}Vig06XED1i}koijm zuA608#&e_gdQd2h6UHw(E9QEhWbwzNq<7`8g6zh)>7t0|C6xYL$Fuy9$5(=!tric4 zFR!uFcMlWIp8#7a?Y{Ho>z2R05_+Hghlw#uHz(P$zN%6oMYad3K9Dy&5LBFa01Dhc zUkOhS^+YnPn2q+;xJQYsKaQhsQSR6{1<$%KQEVY#RSSz%ihxhdT)1DodFu*FJvY=u zkYR=EdO|(aOhyW@w4I8K9+0b)ONa#5KV)23xP@}${dLidc;Mo_f$aLH!!EOGrFJF7xy3oM$482J>M`7mgOb`Up{e4^*fA*r{pg){4 zNX844UJ36|w4ilht|xdHnl=*-CUV)w08O&;la1EGbKs>p>Ufn-n_W@zV)faTyha>n zA80J)rB5k5{r`MClbA~P@HY4u`8cBT>B*W)lpUCq=2gN;R>wt0w$&-ea{B{+{Cq))<32zq}rK74fk1vodLhK;It~rIpqA8pdUa|_Pe;W*ZOG>37 z6A5EIpb|3}b2x5{kABk#2pm>mZR~Sb*$J>Q#Adas+I$ht>Rd7UOF;54B#BO=%R*fJ z6Ux-Bv5l}TgKv0!OWH2qCLPOd3;0tWOd@$0_2eit_B7nWW647Z(avX4ElKl7*dm%n zfyS;FAI7VCiAyN6F;~W~8VdBjf(BH@6T}7%OhFGNne$TZ(9ieqnHX-aLPwUdGL*yx zD84ojpNx+h{cge=QL#z*RnPGZ&C9{_P10jY${i2T^v4gA)(>s%qFeBZ3W|#GT{CSWP^M(;Bn_U9-RhE|dh6R8%JTsKaFBJrM~fnu6?wF^;ok9IMZsMSa!|(;xrQER>3-_S+S70&Q53jdScKie zr+ip1-Q<;~zxBjH6GZm^tTeSC^CKX+A68tSlU@8rjJ2qb}72``j=U zeT9my65l2n-VO4`A9~dK3<)+0q7Z1?v?kXM9)he9^u6;f$yAhV49W(N=NgDueUyam z+sRXo*@!R7qeSIr|9^)TZ}@-QGJhP&Q9wDH%_f8UDhOD`h7cXCtDk`1$J4br?GbU^ znR{`Cu_YSrlR=KR3ua5aTMowDC&hgNin8M>e-E=|;kaZS*3#ubqSYR;f@TO}z7- z{!8cJ>U4st>o@*Y(5y^;ADDOoAd#Ca>~>o;S_nL0_z6DMaW32U%bYJ%2D#qsbiwr~ z`(i`;OU(PXLK!TjEd(;uM7ge8@!(DL6va+Eh#7gc`k#9ajT7<&%?dnOWsV?e2JJ6c zM(uhVZS8|Ikb_5r&@F?p$7sbhJ? zC)y?(KllN9UwEg+n9bw?SD{#LG3*X?^V2B{|{88#dQTiAz{QiA)z7Gg1^H9YBeRw4RZ#6 z9By5ecdlFa|x$d5mUt$ADAWQc&f&6>2!K`ZH$moqG@Q;1MTk zcE1S_Q@g%z!H)_QIqoF^3&=}X&$vA4U!T&|v12Eqw069yZPGRSOze_cr8p=AcU}Bn zR)D+SIhA@Q??23upf$6*I5KQq@gjo7D|k9>bER@=OB;^TbnU|3Q9k%P0 zu!iC54jI0Wg&aQ8U^m|JzIjwh^0}un9kt_KdHEfzRZ$k*P`_~uFzn!M6fzBRA#})L zf^T@mDdhPo3bwfnLhE= zbhOZIp-ZlW$0h1tFZZN}>Ma^UxH|tsB`%%JnC`*wn>Q%omMDwqYKe~(WRlBr*Rva;Rvk*H0fkQ6KAvTBLBYSzcAW##$tuIaF9C;b z(#?C1kL*6WqI7)p+=HH9_Y}-(O;9dnzJHxLfwpuUQQ6IE3vhP$XW@6|q-sWzhS)%5 zwQ5Q1M(M639pwZDF6kyTzMBN-B8P8WEtfC~$E0B|b$RZCTTM2iOlS&ARB2^2L%95(x}q+yBl2yan3c zV8R~)hW6j39>qbz7%=M@#}3z82ZuuKMeC66hU=+<8N|Co=AO|*OAXWO4x($QasKl^ zv}o^|GF5z#$$d1`3M~~RuWW`heB)=bD!ey4w^YyaGZxi_#@3b?1}$SXCrvx(a@RLz zk6n(G5jW2sG6%I{XZF+mUj7ruS$#CbGRbvM?p&+kx!c84UBw2aQR>pdLOo306~^KK z??!9b^g}|$$R*lCbMB7gSRUnDbEt?>dZ*v|0$UV z5K6@b4;o`a^o>||(icCy%FESfRG&WanVw7TQBDr-X|4KTehZDx3pY^ZMud!G%Y5QCv{MOq5Dr2l8%s|w#0wGK^cpY z7WXRA9ck1=YXY0~7 z)U5b7sqB#YdO^^T|Jy8E;E%r*iI(cY+By zzhH#a*nRg5Dx?cH@PT(qWIs=C~b*% zPX!}B8El{_yF7PTeqZW=!oRhlEMC@onQ8iarGuC~NXTr1Zw)kUXSfSxb#H38Yk(M!0IhLtj3i9a=#P{zF}px zApLfib>w|I)KplyS30gFH zVSf)8Rd_K5v9(;~vRoWB;51ouF%?Clbl3h>9zYIuukWWy5ko!wKX0Y0>PIIOWJvbz zu18okF9-~oCEvd^X1$Nz^LxFeZpoiNKi2;dpKf_!TxBZcxeAkxG*39AW{dTSnPazt zE=A=v2(f)W@+B}$!T3^oi|MUco|(L9bWu`rJAmysQaiezQ6I{+}HXY;roRf`Nt&7sb4#k zo5bGoDH>@%{nr#~k)!ea^xL`i3TKrIg{VujJK-X1V)6}CthKKlI{y)yR<>tSC0$FJ_QkZtZ;HUN*QJYxvIRwU3YP1M(;D z?`;{6EfzAJpQecB_^Ld2M#2mBC3$UowAFQ186{b9Di^vs1LcvI;y(wa+<(0K^N{+U z;!0S7*Nz&6-_+2a>NBnBSn1^w>WODGq0givp=in99t#($93w^*K-1BpS92|iGRN$| zh@U(wrADhN$H?M!CisYxh8-;gaVG6*O?4hba5I74U(l#P^F|UcO9%G^0PUskVygIq z$l(t%LQlb-MK%RIPX6x6NfET~aO5W8h||Vq@b<+HIjQV))cI*b3HNan5^O(;7-(#o zOm0B*K#trZ+-W*C$r92N@u3|}CzKl;Q6{_}sT81e5OGd@(5i;sB^G~|^k0i?_xaVy z5bOjLxbZtcB!3-7Ehb0Ql>?qU&sZ-DKM>rlV|f1M5a3OH_v93OKy&vbb)gXa_TOg( zAh3>?(2f+Zv;W5?DiuB8MS`ZfY=wgU#KJqc2SrdUf`$S${&p+N%ItsZ(cAH@asLA! z9u0=#41!D>x8ygD+nM%e{`+{dsF{6gPV z+<&(}(l`C61AL&d$2DS^fr>BV%o9{98vQo3m!nfi5J@Rl?kR^ZI576zSv+Ahi&VOO zk_JK8O2Y9?`wV`<75do>Hdb7x5EWZ+koR?8;dD8D1grJQh$lrPiRS1mS|o z^_vvX8tNvP-Yr?YVc7m_dKpRS{>x>k&d##q9oPlGM~zm{<%|e;G}iVXRA+Hzf9qsk z5+UiyUZK}fXHdCLIN80u&L@|_ZvNI&muI0(X%%h42mSWlb-Ea^@ zQ)1-dSvVe!>JaLPxK?nhwYt|ti2TUvxsi5Fw2Qk=P1y50)ben)!stfe-NXCuw(-Kj z#wJ~d!_iWb=QaGpnMZHF7e-iR;mJa3=!Vx1;+H!I{A+#g%dPE8XznzxMmV}=x#d&~ zF_Lq0ZPa%+6;%?Bov^6~iX7)@$l#Of8|eB+g!ME#dA|J&;BmAM(76B=^eN5+k8@7L z`zUR^(?^uF&L1FLp$?-iE0Q4Gjgpd^t*Ck9;_>){v$IEC>@#&BUZO)0?b{4U;*|$-u%8Ed8q^Nb>~Ug8@ENlHy%^s_2fKpWYG}VdbMgfrMpe8c)&mVEq5Y z$|!J{p&!1A!;=nijnd-_E}Z0K2$xJ^MBS%YDmLvHGy@&JOz@YxQ-QushN8h)>abDG zi~{W%L!rRinL_x}cwQ&?+r#ou${392Ei$M(xTFcS+sSpGXb0QCvJfO#nXb-G`H7$T z&PiItpto#LsrCG9kTyI8H$<@WLTxW5-np67gGf#paJQBn+f%t+>gc$`x<6j5QVB}d z6Z&kFfvhCRk%yVI3tOi2i6yzIXooB$2ESzd^WS51h$a!$uia+~MF2(E+jtv{i@MO| z>&Ou(D_~5HXr2&rtE&V}?89J)vborZ`>{69Y+3|2m8!0mT-0PZ#faMVS-ee1x^yy_ z@=qBG-Oo&7hB1SC>4_$>uVUN7oMFj+_|OP;qVHcf<1xP zH_pu5iEa0kRN0`$QGn)F={Ysttnp&N0BqNOIP5c%(V^_9%2wh;5IN99eXLiT$Vpi6 z?hI-%IJ4d#3h}C5m_W_+R5ApY9TVOy!3QRtBf9$vAJP8-xiLGKC|`m?r+Ip~XzfZX z+h#H_g$UTF$|IDYrq^aVVr~0+{ny25yus{(ZV3d2V_2l}KX;MDWeh>sxQHrLlVZBS zHzV@PvFkR-xT=+u4kbI~mB=+P-U1DO;h7}WG=|72B9)|qmAz8At@Q40n1@)ek6r1D zZ3N1rkw~AL7b{9E@wgjE%-moa1@6MVz3H6KgDOWg1^&mtbIh{1*@E~Us1s=n)GO=v z^mNG4#}7=W9Ys_$(aqL&^(l?&^v&%}e5-Z6AxUg-2b^G5Y3k5a9y4N4p=Xsmk>x0R z3DLM?zU7sb%~JPBU)zZUsZ9jCRuN~2gqAsGD7ctKHvjPtBqOBTQHq1F;-E$}r470y z~0O>U}X)_Y0DhI_4_a&M^u>n zxI}@2+KPTs8SyhI552mlZwBj(Br{O0@YhEOxn zlOi^7umkLf->+?XZJ*X#b7ww!nFR>Ks6_zGsD;*-)n$V7EMGvHl5Yn#l+gUywlG^gv+_thv=RtC4P^m56wMyWv5w9PGy*Wl&o+svd>k|}5 zDgVTZuxX;92&LPFMNLNw5KY>5W=FEV*)d(EPYSZBdqjeWv_qcX(CUin#`jh1Zw7Dw zn|oVgTV|9wiK($4Rm*otieuk*QH9gALSNWQhS{+ zYH08QJqm4lLA0PAEfZ|wTA5?LITBnyF?S720L>a3Cs!P6Sf16|a}W=EiOu}ZWBKmM zVsrK8))%y_3TB*hYDET$i#2t|yI${|tk`94WFN+{&CG}_ABd5`=aiJr8F)K(`9O>K z=X3?E@9^(c);~IB<4$AaHYxxUqiDVomc62VnsyQmhu&@J&MyL>Q|VqUhowq6EH9MR4xo0USFIa&!!fd}&&~e`GPZ+HF4By-}}> z=3Co3<2z{!seC`75F|C*D)q;N*KIck=jeoxt{Hc44UAi`lzllmjZh~{SqbrOd$F+pnSBWw@~1UWuPKn!PR z@i-~BQ+nz9rOt;CzYn61*Gn3Z(|zK1%G=-f&qKW%*ktW&>4yXMZud@6B3PFcp?1$3 z)Fli=T=CDU@9&m7t+r3>wZ!xsL!1SH8V$RAjxY_7+w#a2N-B)_!iXrh{gv9j%xQUy z9=J4h0ODNI?U=hJ&T{UJ4(03sG17YfA!(r7VM!Na9kbnwGO`lf?z&#V1%jxE&jFU%CAV6yE#f`c?tKhPT0<*N3{zsiV2>r)yPs zZT(FLiaSRX7X?n6Va|Ucn1`S!R2f5b$@S7emSY~hCMmH^Ev(^smhSJXcbAu#GZt7CL*)2&p)v>c z4j(GOy(=)8bW^+EwE1RuwKes5^4oPS&XUDDUf&iiBS;{3ZvD*diWqhDaj%tB+*aJ` zn;=0i^ZgEI09!DA@@*s=va?Go$Svb?T2OY`XB+Y{1%ksi^mj?u*d&P^Q{jGRR`N$D zHLdnp8}CP_`+%DvVc;+-8ff%oSXg+=`*SFB=fn{r&bN>`bjv-6x3U7(g&lz!f}?)o zgqERj++)Yp7r%D125)W+Y6;CgBS8}50XISv!QkZ_S09ILH{1WSaF6ex6w;Vdz|{8D z{Vw94ysyc=9bt#(rOYV@Rg|U+I+=o4p#B1BZF!b9BKZ>a8>3HM0m3W^)TzXjn7gS{ z|B!|Bk4x7?%Ftg10@?IXRIW9(R1r4uQ#71@`&MGaYBi6KsTU){c@PXCj$BZXosu$8 z#v{nds^iZI?3H`jiHeR4^*FXa_|QY-Z|(59Wc$w_%8-F-O_dm9{s7^tensV~M-fd! zNCk2l0imC9jjVju7Vmi!23#cJ+iC^_uYz z@lqQd&jbx>+#yigwc9H)Qt}i;Y-~(dKhp~a5FwgTlV?U!;-87(3LRIU|I(XUaqPnk z^{T;>uR+MgrL~ottbzth6@O7-t?s0qcefZl6(+Ec6y2_1C~DI-*vjmB3{^*LbKQtl65J8giZyB>_KYSkvy%(mGcWLs_HaNT=Y1nuTWIGnh-XHRB9lNicPBA|)t`<{oT%Ro*G9Gj%D>j8sdwyd zZJcxp2Zo29Q+U+oHc30ScX8dw=f(MXq#LcF>q_b=J2aqowb;RM`4R zrS@MFR^RxI4Xuejd3 z6gm*;y}*sM-m#K`FJh>6B17#2we4E+2mFanzz{i?0C`&CnaY{T;=cW-U+*%)g_fB# zX=T2iXvGsOQKam7+c0kEFhoX4#`$5-sHa3SUx~^BC?D1?@Y0ugMeM>P{za&M8qhr! zU~eI#o?Rm*lD=*ABbeAZwaI5ei^GfvQL%>vIji5|NHtNJx_STLgV*Y5re1sQ!Fpl{ z>s_#M$rwSwjv`?OhFS+q&?A=}#Q1(Wt<8^>@62ZD!qUP&~5l`=!3lwms zfqvFGfk|FMSjo_vFoTO`Fxc$Ye(-9`>|*Oh+{XejYB4w3s&s&p(cPru1xQ$8bop}mq}cIBX#!$4 z7SjGTh7i=;2afgXNx^)YhskOyo2xG9?;z@Nw26bhKwk2P`kOTc-kG5lVa**GE_-fkk$@j&X+ZL@pgdkHG|XnTr5NRGT?q6eGFZjKmPhP$ zIs!~pO)*fg2Z^H3moKLVR2E&odJxe=%f`PGZ|{gQzk>=S`(XJUGOSCVSyEOM2nu`W zEI=HwO->1bh!#ht8&McUnaS&?#^-ru97F-(!Y-o@AxbOSPLM2Gme# zzx20&_eus00j4xB-934p+{EK(PT0yU@UgeH?SUr{<6D3hVJ}v+Yvz)vSulsI-wkMA zx^JS-gwPs_%0<@B4fX*>g}rOzy}x$HwdEgg63u{U4|p`By-P13?R6nR=Gjn;lm~;# z`?#ZbY28fp<$5NajgZDsthAYhY`&Q3aXLvGB++5Kfp%3uEQNTft77ciU7E+_~$xz3tZbYLV-Sf;x3L`#*ZWCgbm zwYh-9uuT>j^?*V!d`+pUK^<9tcT3>luiaCJsu%bfBDMQS#w_?1evQQ|(UXxPD#qZ0 z-0f|QtX^VnU#!KyY4Am><%>=JBqmU$;k!qhpEcJVXcdZm>JPMC<*yL*b#K1qn<&M+dd&dT9h}l$T3qvn$OMmYMEP z<5@^Xfl%Xj)b%$(aOI12bG6}J3MBN~qf-!xvTRBcVUla)!$nK^yE@oJd+QX^=E3P% zUkvGF6bS+~B5VrE8Uf1sI{Ajy!n;?Hrc|#`Q5QYk6etPNw+ig=L9!=vPtompvvOiY ziwL*RWH~8v))<)bc!8e0Zs}vm9L}{-`x`9S@q*lN%W1c(*lj{6y6%am_LohOroT{D z(oiF#U30fa6Qp=rBm_n9kdAAib@8Gz#;>7RC+0SV2>6C+x~jyMbbJM- zMw;y3#HeWpF8?IP*`}-OhMdK$c$ZTkXk!3tD+;B>MJPZ}zCdVhWHSI)8=1O(2~u}! z2kM2S*D-1cr}wkwvs#O99Xg>%4;AsaD482VDPLPbe1VD%2&Z4EO`o{unxMoDs6`v{ z2mJ7O7b9=)Lc|#aP)l}Qua#=`3c~rpYg;ROCzTutX$KU|d%-F~N1>KOj2$txNT&XQ zVwTH#52hR@!7!u9NGZI!afLO(uUBN8+(vR zo12$SiAXyN1%Ynr42A|%$dLIfg+i0XBh?kWjFN4$Ge@gm$6B5vCzDKtA}J0S>!TF7 z(uBw1Br(1XGH{o=KAge?8J>g`Ctk@lCP$V?#eKRUe~!$hsQj`e6TTOM^#vHF4}Nt^ z;NyTQOsKYD7kqIQTHFy+l2^0HR@o3%D6|e=WcWUox}!&dXnY$G z1`@PvhtZ%ySc~_5)BS4UBgQp~2&#l`Ef%xWW5Qqo6)nY4qrj68|Q^$CMDOP{hPY+L-I&Q z7Fs8kAN}-XZtH(Gz*1at(@=O?0^6lG=fRwWF>J##;#PY2x*CcVb3uFptStMOlksWt z4BNESOhr2#Dbi@buQ0TwRZk>E*{Qk>R@LyZIvY_HFi z9~UYnGB}~YG3i#`bmCJRl$|03=P-L`Nyw|Y= z)xF*>>CLNihozB_Tjhp4uiRrXG9|}}aYJC?3;B0Q*P}4eJmCOR&g3S;8f`@;%`!k;#T)f5FsO-&$HZT*u;eS$2=ALHGa-$S z_ye5R1V>UHs4*a+z4mV^vWHMO;Y^Q~Fce-H^Z-vWln zYSr^>x%}rekiZb#Qg-l0P#J=aMe$ajjw0~tX^fZ~^|UAramXMTU9~6uS4Y(9H1qo- zmnF6hF&;c5DwYh9rbCo4NKwL1hE$>*zgIR1@+U<^XVQp}uaClHJ~En=v?Dk+R0mFL z@0x58cL%`tF;rE^@JZCTF9Trg@cj=k*3-N~>k3@1LKG`RxVkm?W_zybwQ}Iw+?DgM zFw+H?cSH#DhueYc;tF10J`TK6lVydk&aP-rotu*MzO#_+m3B>aXA5J7Gdo40mh2p_ zO0*vHKRvuyaR?y8>Z5g#m`^`ujKR|Y*e&ASh}MHjZNQ$WSyt7s^oVoJmd)l>k2Q@` zl-N0Qr{}*Kl(R2Faqv|Fh*i96<2{P71`9ut1H+g5qJ5(!bS=*B6C1y>?y1zOf8Zit&m>MRQL%`{V*UiC;;2rvRHd3AcnLS>iPfZRU=!xm&dR~iL|2a z7oINYbT4*%1(beYTy~RPQ@jJoxnRC5L_yX7#X$~vcD2*lCiKW~FKVobz!okt%#J-w zr$aFu;aTE6vJ3gRYaBB|V`s6O^tz(e{_4Tu#HqmiIZ~IRE8(Pw9$IBJuJRUh5e1lr zmZl}+f*}Ug$5yT@WI=!HC*7t2)FnufJcG)>GI1SEC@P|@OK4m&wqanuxw&+0eHvs? z>EsW1Bmj+(4_-)U2k0YNn}SIl3CjecZ1qfhx%K%rkpby{`UrsLOt;w-ZbXs8R6O`Q zF_Nc&X4SxA%&P8hPsf_6sPFB*qR%;X_vH0{q}gg`$t7&}xpXOu?2MqqC^R$COgzs% z3hc=F&_x87Az?q<>yb!8g>2AMbgZd%+o+J^fYyM?$_}$2#%P1x7&_i@VcRn^(izh# zhj38!!snyXzEO&%}u(I+h(L=4V>bPc*8SYo#s9lOw0 zG_zDbJunHO9wL-Dcnsy!Q~DBxVYbZ1z7`WB%^_f~&3&_q=*&igZ24er6k2IL<+;1myxjadN{FXs8vt)($+_q34XM8x7W0rkhl3LupaR-ts383hn zGp@nhi+=)$HDlktf7Wb%%QK1v!Tp2=Do#AmTc$iXwx=H|nNuqEz{@sHW}j6N2fw1) zGF={+4Rl53yJi(PJ%Ke<@IV2_1T!+qF}-{zCpUbxm6fUm8Wvfoeg=bnF0#pz`GDO( zVmzd5@rk5X2z9kvtx_d>NJu|Ay^%O~kPIjJT0%#!LpS5cOyp~h2~wDi2Oi981&;GrEgCe;Sz($UYhs`;M@wGKT#0|7-2>T=5?Qh&$~s8GfmZvMoy zWcWYnQcq1%vUz`lD4k8D0c@4h((ztDn^)t@4^tgazi;AsN6*(^Cutb6~Oy9ZugPz4r}T^?j!biH^>9+5hv} zfep&UCg%{pg6;v2cUS8jwhyeQ-3}C!R)6;J!vX$JZ{4Ax zL$m>*s~CFHyr}jbIgRquk}u}unyS}-gx)P#c>ge>4DCgLH&+hs;|NzIIQ`W*L3ZxI zQc~x9uwF0nfZ667O=AaaJ2CPT#0c&SShpni(P1?vWuSe~wBQ8B66*t<)R^R+K(y>| z)|x1X21=@S#XTo9Nzs-L{TvWx+cG~h^eBZHaangvD4^s(cnbg5?7pllwv{>Fb|WLb*%g9)?_4BYL`L6%hZ^F{8iZ`H1s zW}jWtGuIp)CnDS|8BH`|Z|EK|`E9sdH(>}#l?3v87N1mU9WkIb?}kWKjQG#Hip^d; zH7jxtio6Z23$N)BNhR=ER%PJG@17mB1%AMym$Z^&IQ#iB?z%)koL7f0FbgtVMo*d* zy^K2%mo^mXPjdULJ~sX^Xl?U)8!G0nmk>#A^e$HQ;UuJsZzum*drZZyNEyga)X+s> zg^5!+M8if9!nDUk*3Mt& zp*VVTeL=0J4gi45A75CiQLQ&3!A@kzzsmE~VE2e2&S9Ji?0mP&YDYJhs@=b8(V)E7 zTtb7`qS3o4u18U5;WX83kYZPTin>}RVUB_-W_55ujMU!_>P6ed*2ui@4qt3!&ZB7o z-Ad<(=yI9>yVQk+>3JwBjg5Lnt!@!vbKMY1Y1M4J?-U7QvDR9>taDOUNDn*aiBba( z!9mDexo(+@9sJcd*Y)(h%a8Q+9rfg@Ij!u;1X-w923#WB7c5*nSA;ZR-$o1h$l+z6Ca*wYeu<_PD@{8N)JoS{H=dle&GAA z&yDyCU)xk+*v>!>4Hj35%b}{2O0t3Ws?2&N0=o9bi@PSsc zSVtFae*Zaq822Tkr(HViRjf|_{ffT1j;k_FS7kaGJck;b%3YHA;A?b8fuv~)mS?q` z9h+diI9KTbQwtkC>-0otX+PXnoGV;HZ=JB8C0@y5*7S%sqz{a6VEq2&dhC+eByoVh z2G^p86DO7~d{{^%i%(Y^CZo|29NO0TF6~PeKi_|Ky<~A}&og3oC%ArYpt`CSObYk$ z=U_r`gU^ny+i7ZpT5$J_*@bHFzc?l{PB;0q1O)r^N9M;;AzbJPsHR4^BBSkXZ^at0!sq?H zORjnDFs-td{LNi6%7?PNQh+_{z)kE^pg(1%e^iM5^)My__PMpv7eg0zdOc%HXe|Zq zZVkBx7i-FR;-@o1gMkTgrMG>5#IU&J>LwtxGz~*p9|CWO4uKTLtyieH4Z?p0b|fBP zCw;=U;do#hy(#`{7(NVJ5DsL34W16v@Ti1@ycb}f3;-Q(U0$G;DNx8yzwKmGFz$+($w1j(>9$n{1p;ktb3sM2?xEtr zn?kEprJ|;}C6({ft*wcq?eL{0nN-wab2QgRmp7LFW-6V@xtVEk^0uah`H=lp9Ujez zYDd{ZnZ=Ijk|_8-73#Ns!;4?4E<$$3Q}g59LCQPmTQExYAj_h;Fx?Ia&E#n#pfKaBwCz1V0>%1-rY+EsxY_lO8KwrXEusU za#l&OPtl44+oUn2R6}dkuf=U$LBYx(KOMdc|Ljix8vgRf;9r28@XTPwEy2J;kmzLI z*s6?#fvR@DK94q$zDMcWrwS=I9?!d9o9sW@@gOw5;1e`o2YzUBFXrWj%b1L%!i-Vq zdgv7{e^+)UoreSCqD9y{z+Lm{O`iwJljC5PcGB)aA)SrO2j-kVCcmq*{59tJ?tSZ& zu%W99`TTj7>@^I#_QjGRN6<;$BZc!oh@K)4mk~^2-8A|BrFmYo-kKzOM z>;w0(`b8za>zUzKg$|e+UIqb=_+~ZE^UtoOM&7@e>=6#t!?!L#6Y<{?;5-HP#z~*q z`&A7(Y6AZ1=xAL>UAiQd_|n>H_A`Ir$T+sxUYN)Fo8BoxIef2B$duo#yUp|fZR&vB zNg18|rxRM~iCKOw2W~m7&K`XoI|?2bXMifsmz#$%<4tUId2N7!PIe+i_p8`|>?c~9 z>C)St5uVA=)F7c9KfP?***1RireQC;p_XP*W|F@KuRImIPu}1Ap2@KLwUg*KW^|}v z68;F9>G`F>81dMIb&&3ni)b?*W+*F2jkD3t@u#9^M_G%@e1BLZnFv3i{!nIK1mhwu z2v=R5@sZhW|mnyaU0^S$`yOo?R@-z1}R$yj0-ZpD5?XWO@#FGShfzHxPJ4T79oW_v#&g>R4i)t`E6xFC=^Ki5N6?Y8&a~{Um4(*(G zd@iC*xyiL{U@~r0T;Bc~Xc=Ov4j9T*i||F@zVcU@x%r8Z7t4EjPK8Pq*}Axt_rih; zyltn>T%dHgeQoLwx%!uc2rS3C;2&c@u4bCM#{xx*7@v(DvL|(4q+-mCa9Wxv?^is% zF+N>lY!(}CV)5qZbVZNPQ^@bu61GPa7{h|zHBNKLXDa>qM6^Y7{#ugC_Dmd~e^k#yc& zZloltoD*ql9i})3yfJ2={TdKcpzwsp%cNe4l+%)OB{#TDCUwU-U!kf4jWz7VxmX<4zHY1ukUf|uRjB5l{O4}Umi1f*nj%?rWE-yFJ zh`(>!uT?S$agM$eu+J5k?vD{AOS1FFd6`a5Rxt&-P(;ol-_qYm?G?g?lnk^uR9p! zUT)Q>{q3Yqi`|PNJhwnR{c^`#{$@c{N{ir&M%^m+lM*t!n#gy(+k9!a8B{;seiAa! zqm};ajz#gru;o{+mcKFn!`@tX4czwc8J~qfMq0nZ5eN8UE!LW(EcU z%$&*PG1a$yCW+bU>D1pfQMPL%OAW`xC&Ek}k@h~k*k=7`rJuh_2*#(Uu}{I1{fnU3=(j6t@Y5%#EJg ziiqz;02`E?y6Rb=h3G;uU$cyV;n?U;Kf!G*9b2=PKQ0;X_FFE|SM$oXn-S$qhADDA z$DR2|0|rKQiHOJ`ir;Rvg(EZ7ddcU!R(4D;>SdHL1{^&!AZwvaI5coa;RN3~FH6xQ z_g~qxy?gn}p2#eNT4b4AItQTN@*ga!DSkfZs8{(=#N!~#j1tQ{dE2v3GmZ$kSh=(1 zj&Q_M2gKSF45J@1bDHEm+r}wSaqDkpq&m)Len=9D?PmsO>htDRZuXZ*wY|+HqoT88 zC#y)EdENVE-72-~gud&xo;sW6lMmS4ef7MK!!Mm6V0*Qii8Si|le!9H=ALkZ<0Qz- zmZr{3TvBF_yUu_5r3U+|f5NJMqKEH6e#x0{6iT(9tMFaLr!I3+7m%c!loCt{&;;lU z{5AH4Nd)EG7^YgLQFI(a`gJAjSsKr z5a3J(U#*l4(l*D;-{WO?s84C3xDW z*3>`Gc^VO23MD`t-+(%Xy|`hU-f zr~*69M`Z1Cg!xfJm=*6e_&v;SlV%G~#7LY2denf3Z`oSXr_%|BaiSi*i$; zeS@zX_5IF(tG!KU3qRh`Mv|Tn?)hI5w}th!;t`}^(jj0Z z;mOEmuJ^Z}Slw~8DiYp}k(A<4Ghyw9NII`A_)ypb40*!bMyiN`m~YeOqrS_+L-qby z%0p21YfQ|vpG(IEyc_>M$Z3(cquJ8zXtYHIYIvuzZ4gGFV0Inb!!~2T37HxU?i(nL zvML}AGzG-za+KIPIPf(Dg0u#8T8`YZCeB6Oy+oC2UopfwZ(<`)xdnnc2>H~&oh|*) zHASbplP|aZME@p|Y))Q`)$um5H1uCDKoQT8cP}+!T)6mU6^^mmdM?g?vpD?qUy#_2 zh}&zGUk%X+rCO)zUTr%xK4B8PTlzXf+CW|r4Rw@nzb4V{%uv0XO;EQ{Khd&vd&|@} zN<{_xB*FYF$gE)b{JW#jlYBIIG#Abkg+0O4*Qz|@QUfVW-Q=O-3=my!ZY;W7`(vbX z6gLNa(mS2!;GJo#D$)d2a66k`#}hc#`L_EDCxmeqFa>keyZ#nNG@FFT@e)GY*=)ML za>Qt|tEx6t>tv|3eqyTDNxxP3o@&=Yf_KN(j?mx~iYUel6VS$usG*|yRA!7kNcf{R z_OeW+?@rbCri&(&ewNqjE4@F!nQ*mfe~9Z-9()F7yO`OM3{HmQtO4c z09Hs9`qA!hH_&a4M^>u0yRr%sE zEBV-uXn0}D7sMQ`wF5Mzfnf`+D?0HL6ts$Dyp^TnU$7>14N9)Qu=C(KNADvVkCcxO zcuE-8FK#3qu=f@%fTM)iU+as*E&|a#?W#ji#O6a9X>Y2p1P3H?)!p81|LO@6Zl11e+lZj@W!v4gNDT7f-JeJ^E&yTzWnE8x4(xpC9ch)siIl; z`(Z2lmy%ZF?hh6h4zR8=5IdUUW;UTdJJ2Y!{%asGa066-z=-Uzk^)5iYN1k^`LL4U zsn0y@+>Ix zAHN6?y=lA_n%qO{ID$-L6;7lKFdz;NZZi&cZ#dHW=h5C%6aM`W%k2{sNMhG3%4n#R zLXx7h6Jq~b@%b~OM_XCkjkcjFUMx)ObDt?0a;Q(@@FlJAbX|ju=uxftwPpLR6c@B0 z*VqLI<1iJ#P+zP{IQkn+vGcaZwdh6ir!$bk_0rGfcIsGHEr`!XzFm#J+Virc7e=j$}7=TKxUW;XpMd3Corv zSeQx(CCQG@>xwo`fLJ#}!_ZfAWv@w-_XIRWs610u%?$)z^T#}w9&1c6h&gsugDH$g;vmbuT4Y6 zb&Rf#f_RhRB@@F6sL$lWuzs9NYrV52oG$6=s6ShX#gf!sSnf2x6_rNdMLVmj<}r}2 z>m?7J$^)ZN#)Bk{ln*zv>uJ4WB3r?ZV)B6=67&Vc`1w>}bR^4IUv*4*RO5sq*i$bB zbhfuuGog?D17edg4A8NO<Hi{%Sn|CD3ks{ zd7+;S#FY!f(VVWW^|gS1)^F|1{?Z>*ghBJ)Pv=#^(Mo9yi*DdAfA0lRc+_>_Kzo+= z$}_7DL>dJsvzxK+vUEfd|AG^yb{$A{9pnEa3SE27cciUGE4TdK#Ez77=|Z{H%_Wm;GX6iXq20|(U#V7 z4bWp#y+*AL-9uYlGz4?PU!e>DU zBz0n3s&2!AB-Iif&JFHs{~!t{gZH%ha`{jGdXO7=MN65y&VX(?deb_3a zoPo6?e{|;|hEvs^|By%0%4IGsn2DGTh76|OwA)re2nf}3x=&6Vz+bN}998~42mfQL zmK+^2@CSDyuFp>R(`?TTk~ct)fKq$-FMkHoS&V@J3Crxrw7t_KBXoJ;KzjoNxfILg zH+wnbYP;R2;dTGMS1nvDD1JMp^}zRD6YhOTvgCwSk#b(MlmQE=L+g+V;N@1cI#E!S zz??q_bRVM{r&-R(Q${qRG`Np-aIDLifxLB1U7F@B9@S7j2yclFCcUZHRJ?Yp4QLp z>LbkdV=i+u#y8C_fmU9&wo&n#@F;|_t~}|8cvPBA zu&IQ@d7Q#Pnx<=BJ4jJGUq0bE6It+3=(F4o%9+s3*I4+2 zTQ6i}EUq*zfgo)>e931SLkVfR*_;{G&v&ga>YYoCnTN*EO#HN43~VjQd-BB&CRA^p z5NY*O*G7pIl|EKJ3}>G7x;TtV+9DcUvtl9Fo98m3HLCvYCoRS? ztcb)-x3fjf`y+0K5E1DhfTbP45S%ez;RZ60D|FnC$-3C!@`wV~RJU?i?B9-?VU9=B zg##2;u;DOpdrduI7n(X~_MkHCIJ9ijZOr-!dRk-rGeWU96CyQz3HnG95-reN6I0e8 z;W}3Zoyl~kt+y*pDcaT1JID{L!U1J=Zs+^6=;B5Aq~v2-)s4dgDdF3+5vsuP*Mh6n zct`g7^u-K$I8q!0v>1q4pMt8a^;j41f;6p@yyEOyHuj4LEgZxmv3@8NzFdRBDweAo z@-^CzCszjZfm*~BU~y1s^HnEyw8D;`HBugLNP}A_gc~cF$pc@2{+!^%E}C?goj^EV zMvIE}t${Mu?oT$NfL6%%c!0QY4SAL&!?r{WlcO~)b`3Eh?2?6bSsrL__gcf!C@Ft9 z)T?k|1%I`aM_N~!O-h#mwH(*&=&_`(o&=!CLARvg^C;rb{k&KEx4MdH)FzjC$hIf=t0iOai^p8G21kEIwWM77JZ%@ZR zIl=mKY#|TU3dtah0PnWjVreFI6kK_@uyEjDXGVG;oKs)`N@V@eIpN4@`{oM@}P=$`LXj;0u@7L z1SEM9Q=n8N)N$Ll`Pdo*aK8rn8T;IOpW@H?*yTX86|b7w1|)e9KSIWYaI z;Nvb?8&|BXL}kn)om}18R_SM!pcd{+w{INVktKE_h2y$BUhUxNn-E)#mNY?%!;$`B z2&rS*=M6LF8L?`l=x|c|8MSYvhOT5RuZXkW1;bvEK2b`sgAf6kVqY&}*X)G;V5`h_ zShpbXm+NwJbW30PylUkJBr>)F3X)vP)6GB>#&T%Et0p3AJKo8HL?ZoIiBG@!axMMB z1`yk44xpO%dP<28iV((}5KnZ-7+qRXYd?+1x$@qH+IrmV#B%GaLQTH65<;&5q_ikR zc~1_1H8eYpBDUaHwgtfyGd-{lFm6d%=>Y!`l6zK41UDj@PW*h)!-_O9dIjX_)H~}3 zF|k7eBBuc|t@RLv<}P*S{n`WOk7DDOZe98ga*11T(jy>CxAyTW1d)4TFhY*qf11NkFl~g-e#c0Rdk@?T|diaIX z&a`3AGYQFXkB%^Q5LE-D^+4QB62|%&0Y3QXIUmqtQuSw`T?NF>h_o4-z`^{>jd{9$ z;_Ps+A@D7B)ZohxeS4*7%ck}7+n{qrCwb_%Q4l+lbiop;uXPwmdTYiK(1&b%IF!~u zu;K?)2gK_zZUMP9t{i@|-*2(X(uNFN`8jZAMw& zsUJR`QDF@MlDuKi%T`EKhb4a??@YavCy8MWZ7nN^jC%3cwg3 zkfW7waIfGv{?w6y{DUx~wgsH^ z71ns)06A$0MTxB&@V-oBK3UwJwJbjg?iEIekE3J9Y9fpv>kiDy$>+yueKY-Ze-=)g zyk~LmDZPSPUK;@l6Raj7B(cTH_FXwf-_F?qfX9?>tBW$4oeo8m(!7}$6hwgkW`$cg2~*|E&K z!ecuz8H6WrscGb^jDaB#ub%Em9_GU`@zErK$9_%dVC9RdP4Fv_aEod2k|-Pv0IwhC zJw@t(6PL@%ffK;XtEDZLhkNd{YvW+y)hAA%Xi51aH={s^-x$#r{8Ir^eCKi_|D=}j zZ$Wa%)f$k0?ObwnT-0Qle`BN@jIcXhP==Gv%7ot#{BFSnOzK}d64IBj>aTKM5<;;n zhg7841nCmBP==B7qymsy@<{Nie~4*0llfy7(g#cvi{eq`uc@%=XnvSKGnjRyHZK@_ zOP+uFd~L4MX!hTmD6sTL7pYRl1zh&dqFhMw04Bchjv*H)kyYhw*n>z%JKv7*e5%w^ z558wopbMkbb9OgzD#4CNlX$1|Bj;Cn`WT2QSbWpmeyHR=(g4wA1V>0xond>uHO~3* zX6K1>VZmHA=ouH7pvo&CNoV{!ZQtjPxu1s0&V^Xu{=FKXb0vw>cZXeCq|>oLLSmlZ zcRom;6`A5-A>!KgaE_8Ze<)}G0y)IA5U%6=IL;)d1|A1rq;Hmb!JP{=;4+S6{eyea z#HswqmaXs)MYhH6kEJ+R*It-;TMknz_k-51RoO^Tp2q3Uh@prZcs2Zl-$J0op<}Bt zz=bKRc~^H^LMO#>|I|3a>bH*jZyg5Icaq;XcCSKdh#B+AZxpm-f zv=pt>d~6q?SMB60!^YVU@Nu*ji+|Mpax61){2Mz@34u9$^*;8(K$8{c)1{!vZprF$ z3M%cVL3z%_vUXQ8k@ay1L9_h&VonR%+R0y_xaj_Q!;RfWv8~4}I1q7^mezgJ{m64z z$Dc=ky@Ud+!J6k!a5u@v+`Jq%dfndmZ+1yVJ*B<5oWKfB+)P@+DuJb^7jnZ5M}bCJ zA`o=rdc)Or_=#6MYMV2nc5J;5LF&)8AssM^v1ZQd$0@~F;KgtfIm;Z1fKkrgASfts zXz3Wmo!bnO);w&-C>};Y5+r6EJ6j$`l}E%I7 zFM{D`rdPYFZ*OnL=~yNGiwh8pf0;FjZ9fG$b@#fQo?;$pe1*dAh$( z`y6b(XES&Ln#zZF>opQG8ED~VI`&(Uq~0%By-ThHh4H_tPV0~6+1JUCZYApSFT3-% zq@lnNvx)MjKpxeW+fS(3-6vrS+E?&aI}8lg__%!!!6KE$qJiu)&`)I=>r9sorDB5cj4|#vLlkbWBxoS`DDp7Jy=grV;kAbPZ)jc=!eKz?3g%N=| zqDz0|*`)oZ5do{~+7XJ5%Ch?}#;}8wr73j~N6F2>mzuBw^wFa_h3+}QvEos9)>y`0 z#sWIVj~>`Eq=N}=Kdcj{>t6m0HsOoixP?5B;p4vab!N(5!nNsr@Uy%9#xGJuQC|W6 z{fd)gxt^&lY;Y*U*3;eR*yb$@2C*g%`@ts|)+weq` zLR+9UKxra24*5{m@KUFu3FGDp6g4_-uh5qpSM&$nG$B8Wgc2++IcqvIz$eMyX40B0 zVnb|;0pbZ!K)XH@kXt4fEVpEblJW+}=IR&P=)ZkUTDhNwp!sjSj&NRF_VVvODf|+S zj8gN%sqtDZ=ME}jT4fN%D@zFM^4g;8s1)N--z>2H*}&^P(?6a;Ky@3?7xZf#vWYBo zTByW2e`%lvCjtJ1VtNcZI`8=-r|`H~Z2vxr?5riODkHpT8E82ubu_VoFoz#6WtxXg z5Yp=N((KhRn!T{Rfu{CGoQv#4OS8g%xeHoanm!_{(hp!tPvX_OWnF;bXb7~7k{jt> z&Jf`e+iF>t1E(}j=x+1H5{mvyoAWbKd4LD?2`_A_aL%Vckgh~5U^Ji(IUBUBhjkbKQbfcHpyPfZon>6wX#}hJAkdKr+t_Ob&{h$_ z4>(2sZ4f>DZG~;~TSX@yB|xVDj3JV72;K zSh15G0wYWe(-sW>K|i9$4sAe&wm{Ky-A?;Sg%iW`FGZm$RydOul>tI~Tm^5d3xsph zkuIEZMIfB#fY0cXL3AyAJDjRBX$68xOagn3OnU*iEJuELhv3-P0Xt$LRF<7jkWbuy z2t%pQIbB*$tGu`CCoCVMV?%IrV*UB!1I>x7XzJu28I`~?N_PC-J3K!^w+##Pgz@?HFeS3vRD{xpS~XJY|?n@f3H~J zJT-XP@?K2PIg0(BddEAAY^3(_T$<->XXQyGmL6r>Q-TR5OHUNqv1=tTkgxEhU$K*> z5rDX~w6Ioll;sqgaU~pZ#u4*8Yd4rEzzX%qVlF6QY-3sU%>0KbJ_76FN{{z%5jMp7 zzrEA57+KmGM;xQqv3`?ZjYf}5u7pbap!-yvlDrlEHqr(ZI6R;V3>M?V3?A6SCJ68; zsG=eSC1mK2$#Cu5aug-KFmvwYn6z3fgS=5em*EJ2A7(;7W-eFz-wN%^UT$V(>|n~5 zOIG$ObW(bqk*N^nR3~MU3bkV}P_%`irmOgOMCiX$GNJU1J0b0lC$NPKg{B-C7r!PfdF7jdIL0W88Rb*&~iT~*153_wK%n`c96UBI~c+D!(S%U zKrO*s;re#0Ls0E#bE#6k#)pz_Bt-UBBE@O235GM~3X`G?Xh9q=+IIkZh{6M!7rBMu z`Tp$PNcHbQ#jPmb9EyDBk53BOd4i#uQpMyj9Dx3$o%%RZ;2Q~DHa1I)}8J;QYiHzlIfI}Y$R*+;rp6i(Yel`&lZojmiF_Ije)H$5OKy=8E zpz%)+sDcOl5$9#d`yqfzH?8``8xsT7VF-kSQe=?o2W9CBGf446U9s#&sznQw!8c&0 zM7&-u@n@d|&F2XA292_pBXBXH-b^GZz`x7^fNSIi4OIy3#PL!5rvHTo8JE!RH_+1- zBX1A?v*hAa!H5Qr@(q;{%XsVo#31*BQBmVLX8B`?&I-#p+0pLs{{+uoBvdF8_a)f_ z5-*e0^M<2YUF*=AgR6c{RTbjFyluCOGt~0^PcH^9y;E-1>HRCA7P(l z+waMVxb$#j7B&wV7u6t4YaK~!Wp#GD;+?oX46KdGT&w#zFMl!G=lZGz=4IU?te z9#ryFpB6?><{j*8oDhm&0YP>v%A55nWC*bL<;F(4*{6!Web@YaTIrUM6NktvJ)Yf5 zEs)Hy-)`R%^wuu$aP{!4-dYbhu)w5)z@(~sa<}{T5Bh`PCScZ?zWWK=$9xYdz|4sQ;kLh)$+x7E^BsnmUz`zHK%oeVfK>Xdt~N z!TUh<*v7v5_V_VGw6v_n{h+pU?b*8-0bR%@3M4Pot%5UREkFbCVhZO3c*N@kLOi_Rw#N~64 zfKb*twB_OMOR+7`oG_toHb#V&iMtsdN&Lt7gOZYY(bU(Q7!W7hp$Ua408Z$@3Fe(p zts&KFFUoc<(F&qpAXpnASTf2$iUjtl!LVY0iH&9U7?j7Ouhphr5sQLUXBbTApZrcV(t}- zBeX@mDtpg4VT;-vw;<(~-figIIenv%RUL4sG@iE}R69*?tEvJmjo+P+-A-?#B51>a zm-U)97cP$XzM?o^<`w^9wqnot{RK_l)|Jy6NG2{_^~>+Hj!#lZ#xrTk$7$g>O(SU! zs}VWTFKbKPZ5{knBl`cN^1mcksU ze>g)mv?Rn1i)~T71EQc&nl~GrKQ(>vam~g6`~MdZ!djGDtBlvWO~qO3cvxs97aS4= zDFgFk!X}JaRZtW!$tx9L3aEb%9Xw|?gZIoJiGwdm`KY`&gEMNi+c{0JXO<(Weoze6 zf9eQ%6MJGjP3#|z7lc6HdU0#m(e}cz;ai0!p7DFqAB37MmP1P7L~(DiLk07FDvv-##6Mffs(7Q; zot;hDok2<3ikBgo8pfuJ!m3OgtI|xML!2d&(o6VEXv|Ty(PjgQz#jpLI4i@uJzgf! z;l%d{`qpc74kTtb{{_i)=+)#FJYs-hqQ4VI{GT^N3GOd8GVjJgR67L^-+|HO4(bgt3c4UhC zinpAAIS-5RUliS6lsoJBNbFVrzBlh%Q}g*0pF)cvIo_T)Accs{X3v<02vg)Q*cm%Y%F6N_`dW{ zLl>!jzZmEq1!;>_p6QWmP31Ug03C?*!q?D?E3wREK5z-h1N$v{J!PfUpKZj=uMm0{ z91&*FenNZwP@6{U9itU^#p_&7J3#s1x(BgRaZ|DQWDLppPe--B6)q6c&kJaa$$2gk zHG8=LqVKitLSp`5ECnyL4pDs*D7~C3s)s4>j?~VB6ZpkOVlrH}vDA){t|o*@yS6GO z(tQk_)vA3^b!_YUdk-h|KkxDI8|bht)kzjvcyTR(B~m;{LbEZ4O>ZVmXFWP1aub>0 z@lz#QDrfgEC{}1ZrzeG9+3y2Qz=4if27n9yG=R%8fQx;Y)m4e6Dn`;`i@EML*^Bgk zBd_@BUZvRT%+R_m9t;tepk1w7x2iP}G~z^xdy;~!)mupFK@duu2K|ftw?<8*=|2y2 zjuHC0#*HH~TI-CIuJfA@>8un~hOM)qhH!}Zc%3^>Y*T#du9X^76qZauV%X&o3;uZK z@p^_{&W8K$Kd8llkOx?Wp!;4-S@d0{X=N+fih084PdRQGdCueiGDHYKD)y37Zrr@G z;u-23^wwlJ3ZaWQms)R<`0OUxS@BFZJ(Zd9{_`v=nIJ>py7y}0r^#Q@dBHPcUPcUA zZlKm7*!S$(5dROjo~ec>-bILPCGWu6?*JL@n`)^sH$U7lcIqr*8(g{qIpI~>fT95CvNU z&Sj#|Zj$WnZ#(Xt*G(T9Y=E*Q5T>-syjl`9q(F1@2XD)c-AE~xLk|~dcn-p-a1iGB zt4;R(*X1=8P2f{R> z$IqOo-Yb&CC@GY-u(Imtl)87?%xI8pMob|XMX1bI`p?VhR1}qQz;TDpb{65Lf6>&w zZBYF@99GUNUvB+dhI3?Kyf~=mDL}fxtg<0t%F$|^Fm*u3I2vBc?UUl86uLjy7o-{ zm1$^pv&H8mZ%m&nO)M_kPh1R!#tcC2OFvd+rMcl$(8D#2N5i^ReuE8phGkHvTu|bH zYT?ln1+)(zpKljw>UK?)`Qr!)Ph?#tZ-!Jps z8;GYeSahJ>Kj$|l}d?9X#z(A+W<>eHGoC3Ixt5%VWzyI_hf3TTt7E3U6D0%RHsA}~$5 zI-ZqxiqfPUPbsHPT-hFQjDPrbVZkCh!CcvUR$j zca;CMZfkR_WoFFTna2@0cGuLgt9`F~o78FFq@%~g{r0+ZT|GcK_4Ax{*->wSfZQ*S z3U?1xvh$ijvfTnIFX311hD_AnM2#nsjDHsw^$gDFixF*4x2r4`mCLM8Qc4~kP`y}k zyqB9B2F;9yM{lLxeW25rGqULEc;o272V^OI_IDhRcc)GKgp=m{JZJ0;%bIe2`rTv~ zfO+cp7X;HXR8~4%UqJaMSn!mMMD)v_8B6YGTE^Gh1Z!`3Z05ANan#t+Y|Y20KCd)- zaY0nV3g^5i_ZAy-bZr{ns#5yz5Lib#X7|z3Dj(MdYus8}$Os93Y#qu#;(h~TzXDX< z^gLxZdMAp4J?o0n&vg5ILTO9gkWWNh_q-g3tHR<>!&!q*$K=z?7GG>2yilI)aNp(L z_Eo$+P1Mw*N&Q&xGqd+ABRVC#3X~iYHK!=XJ&d*&aVmq*a@y2ZZHov9r1?XrWbk`w zk7>KxbImPnJQeLja|xot8vnYyS*h^Lt9_j=Z*-|H&aCn8kTIY3_UEH9)gBeos|P7} zcX;Oq`zTNtW0QJ5`SDJk5?*Iie2+y&Dx@EjI40xP?to)O-xm|$u<{XpNvkGx2OCO9 z?c}sOB7pYb$TDVGxL;>?1RNJ-6A)pmyb8kHGdYwv+C4SuThVJU%}lXK)_VLgs+PGiZq+M- zVJ5BPi)EDHhu=<}Ghz`1go}=cIL#);E9cu{AuqJ`Go)N{ZY76lo;vMQm%LZ;=n>)Z zzaN7mDak)fwMpl&Z}sh|nD01mh~7)(cIK45vQOM&-$`NR8NZwiCB=TXd|KLlrI5-O zvEygfo|&Clq@|^g(5O1(;8tFaH%5YUC6Jzt_=~>ykROzL(Wd(zJ}_1lzF1~MSXbIU z)i^w4{G0h;k$k(;&IN;zQLCJh)^WQ=Md3@AO%69^YRZ}Bx?fwXk=k4OInJn;s>9>d zXF^L;h+K3({(>VQTR-rJ)A4qXSzYJ>`)CfruajRC!+pZ4P3O#wUk{43Zn;)I7j;u_ zzqg|AyhS@^cE?WjKG!C@oMU$^Zyc2{SFd<(X0V_0W!_0o_qNpbw%y0&%??s>%Gb=? z+iu-YAg~$=Q;KOFcR$ReX~_*x%4xi)K@#9!ZsCk_vpG@ZfD2T;N6XNPtD4@=B00(65jcJNJpcb@=FTPrx(q4jMC5+$042*sBDisE;%Su2Xxr(c;)!H0)F} z-@{Pj!rg`OcX}IhPIZqC>sXERD;$;YZgS#j8Pb_@D@#~eQ5B-xO^MqxU&3+Gl7=)k z0uSP?wIXFF5?WnqH!JN4cDVb#jaMSG|GNIH(3<&3?o$i(H5s`R?*ERCauN>M7KL$3 z2`CiB->K0ypyXXwqUwZ%>Pc=ZIN4(J_QjBn9q)|TLMvh1=H?PWUhN0t5tsY|q&SMX z@Xm5#*lkYQDl1;H;AGL`p;h&aI~#mf_7p|kp?m^;zC`2+v#gdX5))G{9Ur>4nOkb= zH>G7iMc0ChM*04|xvK6rA3ux|tLfH=Wj3kHi9e(}(U7Cn+RG6C2sByog?Ouj>T=Dc zBZ@EoxxVV3r<@@=eTa9)@%HD~M$rIns{5S{Em=jY??RIPAhcdue-SN>z2=2kna8Tb zdh~E4MWUtA!gS)hFy-!gQ;uq?-vHf~Eoyvt029!~fya{UV?m{9qfWFd%p%H}QR5em zP^#~aosz4iyszHs%Vuh_w7K>8i=Me1W)&?Gi}NmLm?WaiVti@|;|ES#DP@}7pKP4r z1c$+^KBq|?6zZLRJU-LV&g_F(J=IH-=5y^w)Mvy(vY(hSNZ8Cg z8KsfApl4GE>l**gg*L;-&PEmiES$q0Pt@#LCj6IQx=B|2@>?t`FFCr*o!mR_qAzk( zesV6Z->bcem4_-9;S)Q{$DMd-wFm`E^D9N~4X5_b&k0jvCS8YgJ^@k}V5F9wLz1o- zPD^!~U{~mu35$iEH9b`@StE{USpa!$FAnGgL z&c9w1mT*+u#C!kk*7Yzm_aSoWuufUR%!rQ02;YS9laT(jEEZDHYk<>~C*R|I9{zAT zFt71^TI5xGqx8WxsblO%D759GpW95#YJ>wNdFzj(L<{${9;{ z-WBnK>3;YlmwIzY&CrfrNjH+YvWsZ6^==1ofn#1PzX?`*?u5^lSmmE^C0sT37%>T$ z?UtmxDd82i{ENcq(+G}AY78~MMtyQ4x}XFm?W*{+Z+or%)Di8MG9kwEcZ^RSuve&Q zjOL~uQGXHJIN^6)EFZgWw7-}%$_eAY>nq*c92%EyCQ%*OD2na(2$^*`z+!ftYH8H3Ut~pxE&^qqjF+5dckm);JSw@7alWJb zQ=X`#c*r%)n7I|B=RT8JgJ%OqEhdJU8!2sv8Hd-?;^vN1#v<5io`cbAdYl?+rgQ!w zfi=bA*wbZ-&*^iF=#U!zDi@cdS81S*NE<{G=`Usd27**LSSCteClBO)nEte6ob;yW z_8F#Y*;nfc^_>4CC8lU5!{Bi}J1pcN5Rr@9U*?(Z+=8}q04Yf8zgNdHOu|oSMC63% zPu>g?Qu?uXc)m-ix}w*^U?&d)Y0+8!c2Crh4*%JGl)H<+y~VqjHlRK^{BA|Tmj>yS z^!)42Sc2P=t;?pLMTgtBQdlEX)VD0k`RzRl*8~2JcHFlygfN~JLM6I$ft6-w4J>-r zlfM)7v4El>c5rnI7p1Mr=xAy@oh=sGvgL|G-xXLetnY|dPzWIIK&gY}5tDi9#bnbgzWSfM|Xlf_kozZo> zTblZBQhz{;j5AoM>N~xTF3+qy0qzFOZ0)Kb4V38^ubgRApVM=~A(DUPaiHTO6Q@N{ znDl6H+)V!o=mN$5$4YtYEZ@am%RpvwS`q(Hb#6#*g1r>^_$!Rn0`~{N=|n=_=@QQt;P5&^J06n=ytX1$dANAAH^~`Ffcysuz zNfBf0`fvxok&&}!*n*z7&ywAzk~5Y#pu@;0ihrv{DGa##eNp{^o;DPz`kFDDD1T=& z#zQ+)5r6Bg9BNB88%$bAu4Fpu#uifh-WS@>wvp@g=6=9rTtiGfs!6mwxgLTu>$2Jr z@sPu@3i<6!P;;sq2EFl_@%r_^y{D)9_UR37qO5^%0JkmVIu7j!ym-kpJ?)0`_T2ZP z`B=!bLIGtyud?Tk{fiE4s&HWL!mVS?kHYQcKhfsz)QBL8rH%YRu0V4qv{}+)5MkAhyk_>85)*7y*a5j0o{w_%#tyPYMq*Oa&vA@L%q9qRkA(t%A;DT@`5138>Xr8 zFt~Tf_C#d|^njIO=Sk6C*Rx}HLH-dg1lI|WXx3nunYP9YorXKOZqmz z!7SjGJy-cgJv)G|Bvz)Cm{8NI>U{ziy7-_0>mR@f$-S9|RJRrO8rdTPB>$ev8Aio2 z+<`jwZu{UWQtMNadu>glV}@jVmUKzKy(e7HPjDlVSom#XF*s01Dq80*Y=4^po_+jm zvGB!)f%cIUsCbjDNB0hQs+-ohJ%`C7CscnirC5O_x+%8_NqS?Jj{?`S7vF%x;yjHM zQa-l-uNNR?&}Vmc$|YUJ^@*UoSXI$*IavJrYB>j?`-M#{&<1luYC<} z5=^>;w;%_}f#q(#H!f(!MR? zczs@4zt75Zb~xy1>W_)wlAb}0Sk=-KBhAp|7p$e4zeobM(Yv6>w3v;(Dn8AuR$Y$9 zu=CZOcd%=V+i@)U@cH8y_9eR@ouTU~>*5QMjpE`Xl|L%$@QP*F+5Q*fP81QFTAuSy zM|aOH!zrH{p*``@ZRMwlJ>R*YD=`T|TvP`}dAeUlWvaqMoL|xXd(Y7D0oqH~{lGjY zCplwDiHs%wdNd68D@6M|{5CnlWD50G9J-2xpPwE!P?=_i$tLWA;L*XY#9EUg1Gdnv z!fDkZWP;+Ou`Uni7TFLKP>cPy>;X9I)U+x&@KYP~8NlY;A92J%8Qs}Mb-?6<)dpK( zDh1-a0rDuv0Vn@+jj<=Pjq}{fJyyWdRM|MW%Jhu-|!7Ww|9DbqlGv$ z1Hi4&_BRaV5cAuU@5+mN8$AxgHBoq{BQToR>Z+biCO3ndJKbCuYE42V)=dXMfv#2` z;4Zk$n5iok6DBvmcNS|y3vR}eY#uWtGW28RtkBdu-HEh>jFbdMM8m#=B&3rZOV>xa zC3qR!Wc^r-;a1a%X_4!>OyrB&7RvftXKrMx@xpm1jIRv^*E1czulo)94?}Hjsub>S z0DOm|0ET7L313B@PK!wF zYI;n|WayKHtX{yL%rOQM^|k`s6jP_i;MP-`*ZTMyFt=`a?&AypvCh_e=+eu-*kV(9 zKDA4s=QXR6*D3nZaBiG((@}1~Km`tuzVWQs3HZ!{VkL}h^5h2?MWW!|^R0cG(^Q#J ziW#_Uy^Rk>JpLxY{ckxT)`c74s;2QfrZD?j1!lk<{ZykD*^fv8&9K3%?YHX8-lU3b zAh$SoVp25r-`Nc}#DUbiW2wK#fDU2EAdh)eQO{(+opd$D{6iA(pF%=#VHxn6-|WWG z@hA{*csmqJ*}eg*_vRAqo3KeD)yRI<--ZYu+&JyO(I2*%>2rmHXy`2dXoX&il9x>gIp_g7R`kuA{?Iwj}^v_J^Ho0)xR7s)6OXBHqy6s&E4 zn>q!s6`nc{uqyfsJn%snuz#dU2rM|T`P=Ni0Ss;{-#b03EEHblnI$m8^ayMP7Oq{) z)Bk&FS~KGSBKh(0`$G#%*1dcnUe@)@9R8x-#-;tRmPEW3*H&IQ``S9kvy&und>Srs z|I~55s#}8(EqKxexoVVK?=Tz{3jq}&)mZ+YB+nOP7iq1_jk9??fC>3#wl)yWN? zgGV3rOw|QVXgl75Wh5SNCA~~PFdl8xkaw;0&)Er$A}OOTAh}nYJBRN4ge=h?lS!5m z^DYqVZ?&36Z=V^S9Ox;QLT?|z_4KS(EewYedp;HS`kWN_#E3LR@IqQ(03U#_Tl-}` zrnk>3AHyb1*1jujXCkF&XDB%pcWk|G=MN3>&oLV#m_bxe-@u}p(w8DYr`?p}&JA-NZPc_cHTk~?P&vuGl) z_l`^(uZXuF@>+Rr1)(v%-7uUAf2EE6+)u}R+F0v&TCcZElLvhL_}^F~(^5`41X-p| zIE#`?PyHPFy&LYsrN=ShBJVXxl0s zb(St;YDmzM8+S?_gQk}pRrs>v9!Pim^mN}M84fAO0O(K`fUtwR?G;l)D0q{`PuQ>9 zIKXG!@n`FXTF2prRq#ty#M-Nvh=wqP2G;!w+c=tWQCMCf{A1Wx{3ON^#XXR|So=wh z+?aWVp>ERSNd;VWUqYBSJ4GgF(_QA-xB1d=oAYC=U++K=q__R&hlrFgX+p&J6_+t! zm_nWH{|RgSYYaEfyRV2FS45@qmTEJLWR~2h>UaoK26SR#hT^E`xhBBr(g6_JPx#hn zyz&vHvZreHF&VG+D(cJ@%fc8Dk?`f0qqmXCf8v^l-E2fpg1~V3)bXOWmnO6Pilaci z?#J-y4!$KCZ@d#1SB}q|`}XWF;9!$vUtz{$^5@P89^w3rE>H&uFeIE0#ft$EufxO> zk&wLFdtYGI1&a8azK)J(q3kHp3A=QC6dM$)SN7ET9RR5aGa??rYWVgp-HER%d2B2| zPJ>?9=ZuhqgG$KyQUx%(O}t(3RJZkm)RS-si`Ybe<5}Z`K1+5H)bVmm|0EC#;~7ZD zRu{`ADR!h6ZT|yRI3gN=K~+Qg52*Hi*htiZbYRxcyKsfeXzO_Nso(uFZ?-c?dLM2~ z^Ua&HRz>LTZmc-h@~+miM!_)PZ%FlGSwB2KQhVWe)OS4_-+U(3`gygwiqm|^n5GdB(`4(xZmeMSeO?&uw?WZK%J zGN@??MZsB}g$wxW>l3Zx{|{SV9#3`l|Nlm+X)}hj*cxWgO3IdNX(CgTtt1taLRmxh z;x#hB@uXw}!#85{ZX2TYqGVz)3jVQYceyAvJMm|8`e z{f3#bwZegD!AEO`RVRpg6+Esok$9sf!vQ5!bC&R6a@mC{oR5U`eLrmnyr1UL*!>I~v{#nxc2}!MkF&e_7IYeV<%dqX?FZ4U8s4D<5 zMW3T{&nEjrC|!MQhfvycaSf||U?RtWskyycrb{B%QyP4S`{Gp-z)|r&VPMSC!zNcx z^mSbb|{Q3&9FT%k||#nit}? zrtoK`*|=?mj@J_y8T2Kwvy#iG)20=jXD3_YA!`Z+2t#cjM{nTRBfudJkS&*ms{ta( zykfg6zDNk)y}0tug%W=~CD)C;cOm1Y2)%gv-dG$_g@cqkxomfxC;>Xj<#Ar-a~8_k zKz|fZu!RQF?nTI;-Rc_$UM$SYm0Fs==>!rW2d9f0tpx1OT|acvI`3hcO%VmXmhdJ@ z*6z`*6^d{rCv%nGYkj$R^?K0EL3pMfOdB^HyIs{kd4Uf%zOWQe%RTH zHie;V7Hkf1SWdh`js3Y*iVYGLeOr)nOdzlM1jkD`adfk=yT)M-hHnjuq(JNQ?Oth7 zXYYtKB|@f@AY0t8*3Rz-9>(^(Yb8=t`)Et6mIy>CidVy;;e&TC{j!^~P)BU`OEwhR zCluU6{vS{4w$5jkPSk6ZP|<~dDO1#g?%H1a4YQ{r?G|wbAcj{SJ)H=B(!!UHwpD-1 zc%`iQ=9b;T-tnFQFguVhxY^?Yw1FO(({!3B*L%(le#$sx4YoA>vFEey7 z$uEG5aqgnBXV727h|CpPp;)-Dx;H^>y$?l65u@`4#J~n->A^(pR8=V_m;}&-^ewH{ zL5exJJ$1i_QkNv)@5j@ep#T7Y>8Bx`2A(|s)viKGU*A+nA-jv4zh z1PjL8Ms})8dDc5$ONtw zOc$80zxD0jw}G{LD{7r{Bg+Dc;WG$a@i6G7HT$5{Fb`#5N#kq=;Ff{eDfuRv%Rzc8 zc-G(GLP`BUl{yO((oOI(a1$l&E?H_rE6NR?ifX}exXmiY|gD!hx%Jm8KLcP(VGsVYm zD;Zt7v2dL&(NxHqs9X0i`@~xLVE`OFCpDxOXKKQr&!EM+R&1~Rg8k6MhtjW& z0C02qVAxX7h2K_J`DV{w#N-Cx6W>)K9wbS}aOL!k>m}7OBoqaQ>sAIojpn2ub(4o) zxSasL#?6O79p#D5OG|jzEzd3WmZ(f$7tq3|+gy*>$wGtMckbM{hZ64RhMQO%5Fku~ z@a{dOu>D>Kz4I1;V$1jNPh(Z-3-JWYH1{LXVBH{icZC$sj$aYkZ*_h51Xs;`M8vS> zkhf0O&dv_g4Xj0A_DlY0tk{Kv8*%oGdHpz)*tuunerNaVBQYrgP~ zUgC=92E4eJdBdPH)NeDtQ^LbPhh(Hn@*Lj%NTJ+|AjaS@T&6j~d(guj0D+3GiWcN1(6l}Xxpx0i_CTC{;yY{_1VLfyfyXsrnUOx6KPSu-dX3}5-)5P zO~|fVkAS+m*ZapOBT~{uUY{0ooIo3DpbbwF&zj-60YzXJ%den(nhq*nhPy= zu0gM*qTwp&m_~!|oyC2Do`t!f-XFwb7O1@8!QXl#VUT_*`c58dpIA{Nzv6@R6)~#t zG1UMQJ1x_Z5}wBvwDc9g@3sG$>m9YvU$rH2_mav2IxV3t++Gxa_~E~qa2OYJT{a_Q z_43E=Umg0w(c)Y4$s99HIW{hBRN}HR_IlExJ4-aRr)m8HwpTRKoc5nqds&}d&jaYt zYPvH&_~7XlK1uJENC{q}9Tk~BY#8_F?Few zcKDAxe{}Yd6f#(jkXv6+vmmnvIHW(U@f!s<`zI1aRw&xOKb~alWJ%Os07z2)Mz8Vd zpWb}h7WdnJ(@33MhvR1#!3L*=HeXJU-$rG3$rqACXw2E;rl&b`O5}+VD(T=~rClL< z3iH`*o*^TTG6LfdVB383eGfpqesC_UzM$nAWcp*RS@wlAEGHmlu(L9 z-D>_zqEKV0F(rcdV{CZM^@x|q2y*_$)>b!{r;rYnMXN?rwrnyg|2x{vT>|QW)?Wls zB!;#74$Io!k-uf9qS6Vq^l#u0=Y`<$hqs1gdJj1XE5aP4?c;y`mpYJyp1U%h7zE65 zjoJL(4@Sqkk377Xla!W-oHMkNVO=LgW%TAl?dRJEQVdo>9xtpXo_Ff8)u)^v$||IO z!S+W|`fF96F6E+Ff6|Xv!3i4-zv1HVCW)_-^l?z=&FU9GUxkK-m5=Y#S8aROl?Cx{ z^zy%y+ap5Uh4JtVK%;4H^#@V7Y?Pfau19QxnyCR!_i34)xPGqup^}Sj_VRKnc1b>2HVX` z{7v1cB(9!+;A_HJFqqiEi`4{r%bpxwnO)=d_2T192z|^}`FUBG6LP1nPJX8dnesV`I5|fV=^0A}B)F*Egu*o&n*Top zk;|m5O6q~zCa1oxRQAmWL})KfnV$izB@zprZ^8y$rU zE}L~drX~Q)zFoob54!AZur{JeW$oUeWt#jmBl??}(sEE-SWDnx&^?cniCu7qd{X;E zVKeiwVGIu?vy@1r6ihq2kY1#x2TcU)!7)bpwwAhx_$FweHwZ>n-km&JJQ?NR66l|E z$CEr$7@wI}mfbQL72k=6_R$Yrp9>w;p_MqCmspjL<9zENwbE7b?;q)3>KJC!-}{;k z8pg7E)4LNHkQ1P;eZ)~}(Fo%mQ5s~a?II7bu7WAFHMP9-7RM7DzrP^ncOzxN`^)nR zL-K*J#bj*E_TolwxZ%N#V1@k|4pC{4`Ynp}b_u-^&c_Z$uV0=d1fvX)77d%s=-kV) zQ+4oy<1|yNgP$%NOD91-xEKB;tV`y3pDsj)7J9!!vm(FtFaYijoS3h*mAI-F6a94X zI{5l|_u{$;|K4*nWHk4i@jcb^e4VZaK1MR|;NQ!;XL{+BGa_7An%T0pFlc@#Rb&+SlCjazcWl z^l4}2BdH{n`ds!r@(r=~-v1gYDGEveV(1giwS6rRAmJJPql3pfuc18;Jh*?idU}yP z1=EjgreUA^4#Dc~P1Pg=s5tn1I!BVC_@Lfx>x>DS!!;2|RTWYjdeBG6;gYS=41nGDs*y-*V?$WCAxK4I%cJvzuTTbSXLS~~ zUw$E}eS$fz-oP!j9P`ubVf zvOpLj{)aASpJU}eQ^CW*1wCm6e{nH&Fxpq$_ooFUEG&KUgvI>wkF(Q9Hd8YHjI4=$ zezWUy=6`g3O=myz&yM~)2I?cA!d^q(E{ko7RPb@wo^l0JN#gaZuUq3B?i!URpIhae zLShOAR%+Z%c~Z9=odev}UV5J#c==%?W#LFLgIxpvPSZ}fD{(KN0YmfojwFw+VsbK5 zcxP@~*~R=O;Ulzf8aTw+);Dg3cM3UCqHT)9 zdy{(hZNg0+98Z=6@e_m^sc#81MH!-j1TdUA92TG1*pfVqV8*2uKc(eWk^z1mpoc$6 z3L=eC;L%Sv;X){bpU4X?4~GeE`?h$72)wRaEoL~iJ2Ji1AIyg)h2ddB3R~zPbyMPm zu_?HS-5&MHvl&V%+5^*idbOZr@m0Z3^(H|GhY^}3R1>D#cBJwk+4c@8yU1m#Vup;m z{Ti`7BSFO|;JwtcG{rF|=RNi?C!tbGdZe(0T2O#8K{n?w0WoV(K2;NGCd{3YM3YSX@?t?IJ)14lmak-5GAb#KAS zwj7v_pZywS&x=_>blkeG%gg*O4V~&QK`!zQ$g;15bkduA2MrpP4giJAgV~9P9sh)j zQ8L8K&ssT$#vSEXG-Y1F(Q@gSGsQAZoM;m>R91cUb$q69T#WhC#Hq+}d4sD^d!HY6 z+H)4o01<4d@xrb;{>P_lr?gmCIKfJciu3zYyXw5L+!Da zh4K*%I@VDcquNp#d(P4{(xxTT<9MUow*Xl60LeLfu>63*->@V|60UFY<1|?+1o1<~ zy|zW!S@w;bpNnYP4MPYr=XUs03UizEcZMr_Y6rhawtn(6!eyFyFr2ctq<&96UF<(6)0oI&Jguw*(7 z*~^^N9$?_N4grFX)cVBM0Tb-v5Q&aT9P%-Lz+)hGBTYxtE_kfxam+q$FfD0HCip^0 zWvT4^@E9Cp^3avmmO&u#*hX@UBU{9@Mcm^v|GbL;2@LbGZ(4Bqd*3iV8FwWY`IS?# z2oMHa>+#KFJ~er4k_;6t}a$X@0W z2-VL)!S$z=j1P`sH9Q_ljBGBJX-{BfeVf}J=Svcg_VG{!Bq%?4>;{B?>-Hy#87ay6 z#NitPx4zy~k6V=J_;l_u56O-~TQlmzK%xE~#c-tGkyHFke%mjlW6=Z5=~kZZxS&FH z$)B|DNpmNnY=AmnI_@M96=cxG17n zfjWo(T!!qDnKaFOX>#iQvrUqVY;*$352VAt?T*em2AdM{DoJx?42==9ifR(HqaHGF zbc6k)JJu&!tnLXkz4NqfWUmO*B}&vo$;Gn1#egBx3c5N*YXn_SlEcPlKZV9Gpi06R z+!`lrHX-;-0PyfOvPDcC6cRH3l=v1T+c$3kYmZH7kzVnkBFRP8-IGHJ13J`hB=g5F zIGue^oI-J9wA&y-W=-N4Vy;8_;nbVdjzs~f|4v3olj3FmwE5bVgKnd4mhby7LTe4F z=<%*waL8d_=N;g3T~V9jQ}tz((Vt`&e>Mq|b09{KP-b29Z%Q;dSKKA!Tsbq^b4XI! zcg&oZwE>P^y;F_BCY)2t7P%@_PK@>MtgGN+W)VG_-SEvhckKR;f+wFY>MC+BzP?|E z3MqzU(GoK>kh*bMoJbYgG5s~?payY7v1H)r3KdUPdyLp5{h3;#XZ`WBOeHB)5=Kn) zZtIVHNK|5!|8UsOc%k9&Kxa^?CKY0UDCA#y^{2gL{weXQtFA_BIK}=KjuWP2Z2Igp zd^#};_~YuLAe%#v$e!~ydt#xE{HBm1koL$NY4uL;}pH!i)u-s801xteqH)^30B;!bdl zz`kSKSN-eMihaeRQ4yinFMdrU<$69>miK>%^mw&L-J;V$BlvifZ`2QslNt4p0Yj&y z9`^3}adD5e;FG4xzDqO03s@W0)mE;!*y$hmz+2N$EWe^|>3$4PB2G-J(XAzQ@+I>x z97@oRH1Be{kKqR)MV-HN9Fx}g(%klF!Ijy>w*%U_c5Fp0L|<&l`k=EuC(+}N(eIFoUq=>-t(_`UEf?VMu~YJwB5YAbSQ8dX=I z-!sTwF3GWU-0(q@Gf3`j+9@7}f*)UPS&(c?QaLcJD{qE^d{@NsoYZUwHdkda9)P&>{@vN6iP`kue8 zjW#92FC5QW$=9YRC)U?A#-*8M?`YNfrvKfaeA?lL<>G5+V zm)B$7(UuNN!8huHOCbF+I?;43E35oR6dYQIG_9PJp6TPFPawA9p8u`wnlhC|zi?*G z_f^hfY6iJd^P-v`qFa>o1~som>s=Cw(T-OZ<<{KAm|$_czCYPnI-Rs8!Aj&`};&AwlR8?CpZLjQ=2x36!Eh2V`d1L1<8X+R~I*c&`?hCNYK(Sx%l-b}8 z-6N|5TY`RGBy*mIc$3I<1Q;i%`j7um^`x-{zGO~}P|vk(F`4osycquUKUA%xD{AlK z{@338$q|WG1=k!&Dx_rh#*VQKTSE4)S|rGJk8E4I1gzl-Q4eLG&4GfDvj$Dhj0x$i zqqYyP&EMU3^m>yhUpnXSbyNrvO1#P^6E{v8e9W+_Wy{e(fddAq zb;k2ERDEp0rJJwLh}<3gyzt7X`PdtupMgy&(nrqSt$Hx7c62n*;XO4-N{9+wJtMV5 z`kLlZ+K7&B%HMhBW4Oh976VP9vW8A*DDCFDa&jzHWlD=&WbD$Z9l~SpYg+}x^Q5^8 z2Z*Ira7=NUQ(Rm1yBbR-F3rC)#lI#FdA;CCjOrk9-I=1{ye+<}7rNTiD66M?E1J8; zHn^^2tyH=<)%uzyYv1#LR!0Yo}6Q<8W>~vu)}Oi!44Q)q~c*JKDM^2B?xf%yUw_{MCR_`c}R2MP}WtLtxQTKWY+gWA+}kS=R%-iD zj)TEP8K&Q8s>1NFDS^Un1y1;tr0{z1CeiMkuF{}8i>NVDEz+*@g%I`K??nBSns zLe!MT*U{&%ms3`tX)oQ3(D9{&rVI9c(TABcgFrM!3n|@mk_}V4f!(`HcW`7ZYgR3z zc7O1;=oA>_^bfdnmcH?I42357uDN{bK}%Vmb74h&X{T=i+}zj6N7n00CkB0u zf)TE3`Bz<4ML@{2zr=`M;z^^}r9~c1uLb~C=I}!$d2ts7YLRb7Usq0Fn#W=4)+OBN zt)fxs#67=lcRqA@)#?7vk07g@w@kSDKTnaAs~*V05Wp+<3-)6VucC7o1}H|bN3XRg zrN{6j3zFY|Cnl|D`pgay$2rm-cg+@qs)Ptq3RPFhbePqE$?XNd@Bff>1;EB{hITh-x_BiDX^yMy0d_x24GEz(E ztre?mN{uButp64(beW#+T`j@G`YZb4=A69BdrVA$8*jPqcNaW}WW1Mug8oxrv-gL9 zxBXgY#I)_V9p=)!Y|1xt#(kcN@u)|ZDCdMmh84HwK}c?~+Wrq;mD{_(u9r;{$;I3Y zZmXHa(33Cp079m{xwL6IX-&2qX#UJC3DlZc+#=Bq~70q2k7Hc!&W7+ zK1Ioks~ObHo1$MbPKenHtMkxyYeKeK{Swyiq22lQl))mPSlAKZXYV_Va*}^F%gcO< zYR?Dve5+F=3zKsF#O=G?bz_rpB~=NPPZ~wjn0FawUmDIH130n>fsS*OFDo|^co-8h z&sz2B_(sag*)J4AT+eYEcYFQP1zA=p^cCm;_tYy*EAI2i%$%J%(S~EV5?=tPlc=Tq z&Rh0^i`j1M__EG#y#f(mi3_Cu;WGcwk{gOGu=W_|S7aJnnHq#e82Z+Kih1{LSz$92 z`@%D0GsVjduI^T--gRcP+G5RJ4GR~vJ8eLUw6`Q@(}5pZCi**;*Mr#GYvK27cWVg( zcdmckSZ-CG*19J4vw;Bb~y%Payl3`OIhh2N!;msM% zpZ^xLQ6DW-3xv4}7n9gzML5AjN%uCb=Ac@hfW1y1e(>kZ^ItB#hP>GB_t0pIhH73p zW2wvwNEYF01uV{c9V=uJ!W95T1gD@-9f z;}C_&zI)*4U37IopQlqIP>+$w05A+-S2j5-t@<(W@O_Tcp5Xk=T!WL~ErUMRHU2ZZ zv?{(V6GWAnz6z}hcafi>s;%$e%4z}youVlyuWY#lB`S zUBkY`v;G1M-b_#>pY6M$N* zCEXeV{d>1-6|5MNGelT*g(cbYAGRLD8~(IbroZF59@?2}(eC|fh^dpFJj~GK@9Y>w zO!%rktiFrjzQ|(nG$vb(uAw;#3;;`F_+u3wIsC{f$n!gKRwLezsQyDE$yN^z!1$raam;!8^E$OgvzK0qgdrMj>zp6SVr9@7| zY}@~6XDZ(okJFdAsrJyRJBX8NoJPbp3M?Lpg8%Cov-a(33DHQ_C> z%NjnVqz(?bpJo#`#81#Xmd zdF9VmJ|G+6i$wL&7=J>7zwEK9Q)HW(LqL<5W*SZW=0ItDX99>ew34Vlcy-oQ3o~Giq4cujQFKhMJoRQ4yei>qr)F@nC4bgW$ZUh z$pCz4l$FL-t{7@f8ZhZFambEIIpNMj^UrWmbCpD1mhC%aElVyFh#@r+=AM#%k_0iu zs9TL7RkViQt>|_`~P5x#iw`J?uJ-*>FR|ikoAcrR5iz9SYR>eJ51`$ zl1&wF^A|Z|8$Z(9*pRqe!S(eOL-t)fK$4A;MQFO@Co&l#h^$*hyEnSN`DRj4LUirr z6B=i|#L`*~KvUR{3MolGA_>{Lg<@VHZa5QDRiB2187Z-}fWbIaU`YgxB^yW@bzui> z^foWC`G=o;q5TLx*;iC)XjX@vUj<5AIRD#6V{AJI)Jy$ptFQ)#Kom?D;-I4~P7@j) zo||skItJv7-B#H^X_i4KLAeK}_WfJy#79t>ceq;QD~!m46!SVkl8_xlsiYMu$2oSU z$**|ZYiC-EGiG$i@RH+BHJ#WwCzn=`oiOWP6Tx)roE2(X2&Z7zkFFm-5dVQ@G@kpR z&%j}kK5`K^=lY57S75gu@wWADMfNZDz`(}!g!y5z`pR}3y(>i(HYek_VX}RCi7oYW znHO?xiWv~0^7RQu2=j$4CI=ojppB8f9nX;c5283|^ffS5L>J{-A@1=$TpCm5pDN5^G(K-o)Qm`!e=V%G{uZd>}7nW&#Wv=+VkC+Qsg%XX; z(R_TC^%04mwyRzfm`$g&H-JilJ*muc8k@ zAd=k1!CbiAeP-|2Jf~5ZSz!E#{U8%&^?DwPaf7gCPocOpMsRl4{W%n#LN_~+r}?Y2 zksM3&CEqLLR|Xy#rSSK2ekZBsSOwPi!flM2MC*0H`G~7$%uTpzj`Wcci&Z#aCvJVr zw1QGZES3lwje(OFreWn0(~c}p^|{-BP2avo7rA|3lmEJXN;V165(gyCOHAbXU%Gr7 zWgjm=G3}+Ps#y=rzimXju{mIjQ68DScR%Xlod}Z6nCJ0t7SVyYLbe`OZV<@7=ZazR z&V9JrSvrhU|G$EnN^-gn9qv}c2+jXyiK~RB)q$MrEU?E&qR^txQW3uMKQH8axc)C z_@ywB9=E^YinnBavERq8Mua7?2nx?zi*$(Yehcu zlsHPh-@TTW{Z`IZ+ngIso#29mQiMh>_$mjT5cj?_w++AgIkI=5Otyj^Ev_*V&SJfe2ebi|C=kMw#)2_y_nn->>p=~Ap>dpJ9u zqAzS(Kk8!0YOi;2)P{MNs;c6@j0z#pkcs;ylg%q>By1n0*)8yrzIzsN6=*hq;p!y~ zXYAcaQv~JdxSqJvP*e{eIklUBEkyf2P6YB(gHL+`{jVhPw?x}*oJ&byEje`fzxcjE zYL%19*_?YAmC=pgC}jBDW=vWPFCi~e=KG07baiF+2h>B8yuQkNwIu5B-{Q6~*W{6v zuOH|huIB^vCmtEOwoHUN(>o`hu`mbScNYv~4|7wlWS5m!Xy;o!xGz~<$^X84TK&sS z$K5~1-QRYj|IRX9SKBP;F{I$?2NQ`XD1*C=?YzXicDh)7&joOE{exDl!0O@?x__Li zLWO;xXV}9ZD8Wj=*K=u~UUBy|Yg#>{Otgfn821{9{YH-#z=0cP0Ic zLS}Q~{{t6GhWvS<{`!A{t0lh6IjZ9B-oUZf6$A5VG*~p^ydd)Lj9OkH}hH1X5z_hD!|6(p$B_(}QuXRaa< zAdkNqjMON)MwS`6HDc#!RWvJyPBtfpsfr%V_l5rpLqA}oP=mh_^m!wj6>N@aWLOp_ zD^z zXEsDOIV(ON@tF@8S&)sUG4@DgM=|bu`^D0lDP`aue4}z2o@rGSJSvmZH9~2`Hr3tt z%;`~@tEwLG$7J&->}1bSg>l5w&9PJ-OIM$UGnp*bhE3I5+6oZNqQZFaBNoxv_q2Jw za@*B8!A7xbYk0%-%~n`Y7D2?T==DVo_I|MPyCBafp54%= ze79DPl*C{qIVc8xj5+Q&P`;R|B;BkG=7)BB?HnPVT(Vdv>d#kxnnVnYsX{#I<(7(7 zy3TN_xz5Rx!KaR;UaQlZoXdEr-9$wTshT#+KSRu2y>EMrZlZ&D9M2s+l)*ZJPw@bF z!cMK(Vx!gck1#^#Y;t7-IGjk(-C$w`$DHJ3rLAzKpBS@Jx>wmWsdoP3Tpf)CKOkWi zhcr~I_E?OY%J;?OAvr@nN=5}ANd6tZn15!T2n>C^54#L&=3c{A&X*RYi&b0}=Lo3C zWUJ4Lk`vP4xn#}u4>PLoEra8hT1-si4UZeP-fgQ`F%fYMS`Jnr!i*gKmdZC=-7VGxzI6%HSLk;?o|NcMKnX2bLX|ZoA&FPkQpt2oLf$8gHo={N-DHK- z1H>mZwhYkM{42?ldU-O-STf^9_$`{)SbJ#uo87D=2|W0f+~gS2-l7fj#2(U|o8k<3 zqf}(on*nGSbkmb2_`bK3Oaqm(ylDMowjR;*ys0toc{&pw_ zC5ty3bnb9m&*79XHMW5Kkoc(F<&TH7Y1XgF)juE~tln6CW;NV@Jpuky6OL6BN-wC*qD-~!$L$r080 zoDV0h=}IojoY)-gU21zImZhVGwxpOet^g}}kC=2gpSZmaiI7u+cL~5tvQ}xQuI8T> zsPQ9@P*)rks~Db$j>=J*T=WCIqr+EwNbHd;p*QHDNU*=!+sVz3byuixTtEXhIQpb81j zhxrvf%SfC2M(~5Hfda941O+S-35Jv(#i>W-Pi;n{dn|*iP0sA6G1;3?!B5<|Py?}z zXYMoKK|lDDm^7xCgqNtlwB%wA)20^UjCZZp&6$h`!QFxAN1S%zs_1%pRx|G3Z1y|g zebL33Q|GI{kz)QsC_bbOIM}E4Ilrt5ZVarcOl%>pCFlyO1L&Mkq0(tH0tNu1Q)>=d zGp}gw>RL-kpAw>BI@Eks;!q$2+R2^dGfYsjwQn|(AC`e7n-G!CEU6`_6gy29pC(UG z5)zz$JgO@7mkMHRHBqz?7?I*{aaup?^i8O4h@H%-+?5kmsf*fc64|v-X%5=*dHmhx z5gJ?@f*ZEFz5#zl-VzNilTDb7(*!O*C(M{7hz&4K6BciAl2F{OIg0!7^f!vLc+z|| zf9d>D(@Gfi#3^Cn1#CyR_z+BUoV)d|ugYb)hyif)!Ncg(^f~sruRiq`atZ_Wl#}cT zaMvjK3y8v2c%y>DkUWJD3i-39%1gLwW-j2{%mFpsz4;2eXfv~NbExdM@F25b7y|U& ztF~|8WsZZLDK}Ps9-h$yyk`Q*y9KVQK_?U>CZr!A5uX^#TOzFW8f>+iiB$gPm;pay z-1An$X|Y%)5TepVh=Q5<$skph@3yXFc9cIdKu5*lMp3vU0x|mAd6$W#Sz~a(!RQj# zZF$#w4H65Krf*CgfrUl-DKTT*{6g<|*sX`-4>~!$`N1<{(pgI#KUyLmw%SF0In{mu zb2W0RB40=9&e@$~YJf^$jxKRD(YbJi1IQ!T%Yim?NRwv%Q+Fc_*;l8dxlF<9Xy=p4 z|Iua&gOSBzig>pxFv|A|*-Q6n)gVlf9eQ#sfc74aRa@6o@_V!$Ph3b9rqJH0pFsO? zna_Mu7l|A|5xD0u5!*!6EZ%fc0pxdN52Q21mL5G4S^<9k$sRggk2d|%o{8|nQ zqS()%WY_wCj0sy!fXI|b5=p(Cf_yh{U_ap}VbZXHz}LQ!yG5%RpL}&MQZOhBJwgCs zN)RZH()#O(gP-h!UDc<|$#InCF!1je#H%J33zcy}r+=NXR*t}vz58fDd+G+?Xr8Zh z`aKs+iw5uwxq)vyc8=28)4u4-$JW5hB3BP?KG?gic8W{ZNwKP|2AAo3_-3_B8Kpz3wC{1e2i$15F-}cA)`epyojsh#J3QLEmxrvblyUa$s;;7 zB<%s>3GdfbE0{*d&7oyt1*fve zy?o1(BZiV;@q>ZiDTW5*3hl)?eB_Km1CKT&%$!(_C(sx?5S_Rw)zpmn+xJ9*KXy>L zq%%iuZrX^c$JsNtdXvsse(~{QzxO6Mk5@i;|0}Bj2&rk9KWm)YahRWyC4J6H8s?%$ zZ}|kRh~$-UZwot3Kwy!D!$_n5sxk8}^100F|Dt3_q%@#j9o@pU>BK7+zZK5OqGayo zH@)OmDNywZP_>L{`T29#-M@6(&djh+CMG-Ev-j1Y58Nq0Bb9Nu)c#)0f&4! zDtYB47(#|BcrH0{#S9k*cNo_OA(wV(WpoHakon?wuPy%!#x4YNyCLU2tx>$_OrxR_*YAs1?SIu8SW)8Y#$E>uXR{q6BO zXxwI+&ecK4gdi@Ixv=BZ!AA(lckS*&t_|}p2A9F2o6Eh!4EL-jO(~m~k!DllN+Ua} zFRw=?px^bZIxr`L52z)o$2?dwOn-pE#2ohv_ih`J=S7wn;Z{F7+5bhcv}ot0M5AbR z5Ty~fx9UYl&HBSiTr!~%Z!);5qbn8|gzW!gDO3)yiZDM_pE`#fZy-@I^vtq@XzjF9 zR=skIU&6)_L<0Ks@?D)Ka(>Xf+}vj6=$0CzB4qGdbu`1Klw<^E4rZO84ev&EwA2mki(ryK$dvr1c7AEg;|2o{_1@?nHqS9T~ z1`C?_`Q&9}_T=2C4vNUnK|=-rRHgu~RksM2OO`F)6rE4l$g%skY`77XFpl!!5;D!Z z7FaltlOBh(J%~Tugp2EW4gLK&HA~lowvd& zLy5cQVYYl4oL_n6J1vlI3Qc_vG<8C_=^YLHOkOyVnI$P0AD2A-PB=a^GCrCXru3znQ(Ni8Ox;wujK zg@*2g_U4~${;LCcPP;N5nN#H>pT|y1S=WZIWc|_;*xWO8$L5c1NLG)qc1&%$nz;(! z82_v+(rplCqeBUi;>TOvzYcs^cej^^OVFC=!V;}ND00b!2eLCZ{sBZUoH~?X#WV0N z*km9E%D)224oQ#>N%pU|hpM6?P?S6bVtU4%RBa(TLP&JSm zqtj5hn9e~MH^{i*#c$A@(i!?>{WgrY1n=DNX>t3}MBdRMDgav6oPIH}g6X2B>ie-v z{3lwdJ8#&_P4!W1Gbk4WDBlx8u+PO#8SFdAHb0xTsNnGRJf8{m^rGi z*tdn!Moy~J>r2rB2dI!gW`A*IAu*Qq(x&uE()i~S{ulyH?B{6nWo;gLBEK2ZX2cRL z-T6EQQW1x}9wfI6eO{QGyIVonSwG4C(L9zZB7zXv@|0cTi!WzxXv{-CW{Y5Z!3K%BljM+ zrWS~eIXm7lmM^?nBqINk1hFjxn^)V|u0*ZG=Cgdc%s}h>8|i!wcjqCWIFT#Wl!y6S zTDpr#MT#UfMXFE`9<&95gLhv=bq1r_bu~$|U@>T?s8`+V1q<5`BqVgJejGZOe*9oaiu#luxK*`o=m>b+Dvsl%^K-O7D}*pqml1W z?E@F|qjirAJf%3Z<4JW;OEhqbHr(6c&*yYn+x-EB0`qV{&pMO*-+^()T_osiBn;_S z=J|GWxm!a}@!9a*ZMWvRaMEMA!MVl**@HApb@o5b@@@XGe2Pw1uTryHIkNg>`LWS8 z`hPgfs0FHSi!J;l^26RgBUj%LtC4>2Vs|-HFk6$~b5!4f9hhc-7PbY+7FuNOwB%cz1@CfgGFmrXPlA?pruRjM&Cg}vURDe zZdR#oSa8HHt)vKP6?9ghSjv&wf4RgN6+~w~brxYtpr+A1=D6Amwr|*xe$RI|RJjY) z2*OPIhPf}3cy$r;2+`N#s!oHTNBqjgn$KKHi_D7~bb?nKNF}(dTe~kS=4N(eMjdbI zDoOFLjw$A0m&h%r7$o>H_+ycg`>uJz^o zclYuWIw(QN8Mj+4)^%pg@vflIdm?wQV5d z1CGUwTiF>M=wBFjJnz=hq}YKJE+HzQ!+YgWZn&F}@c7Z0tj^o#)>59tOl{w6pHZOh z$jx!ya@jL0CYAvg1ed1s>1FaB_DFjRh~Hb~ROnG;@5#%&J2thpcdhJbN!rvkbs%;2g< ziq2W-L}*#hcGc-_k}c+DhpR@Pt!#etBQM2R2cXIg1h*7L2b+b3BKfOC%^~dce3nUi zlb8FGnwzT6y_+>{WX=rRVdhGRExBbc|wSs&mLQ#&sH4YhMcbU_Bg}sJ0^!`#9ng1zUaa~t{Jd}Uf~@Qx7gGVGNNO@H)}8UN zaLV4Et<)5!G`@5JrR_YU*egyz#*PBeyMm}>;@Y=Z^;X!+CAMZH^9PPR?KR5L-}5_< z!G@;3q%6rn&wfRpn6s%3!c0pPfVK{0+w6e4a31q0>5UqmZ0zjD~iu zr;u}VU}ls*ijWK*S@(OY48P+JK58RdP(|k55oFiOZLZ!{+O3a1O8m*1pg+d~N@*6LB9@6(LBhIxKItC#|CEz;TVQwg-T{TVmcBaI z{7vYX7z;;?CpYx^H2>uVU2*=jf4460aVh{cCV}&Ad$w1{`_-6cvnLlbxwEqUJsV$o z&tC)VlAyOx(C1#9b2QOx6yR{~EM7?Qc2!DFMeiQzg%Xj?C4&|Uy+V13x}$Q{%|pr3 zxJ+(>-P+@?`$e=Omr5RTK>HP%D`<(V-^62(jHgyOe|;mlbn5rGsNnD@o+n@;j?xEX zJ%JQLg=bc(b2EPg=NnQo0o5^2X9is~die{dTuS*Q!FL6T(qeL%@5_1rKg2)E9YE)*IDTNtHXuz` zkj`|oivhaH#3j`RDGRfeZY;e_36|Ke2AaG(Yx##-r7GA&IWA9TD+n}sU0wdc_xa`m zd|{!S3`9VBe#7vpAf#)&FhA1&(sou%qo+ILCw##y>iym*E}`qHtM5|Gn?yt!4|Pr# z$#f)lcZ#x!0TV->g-Qz z__Q{p1Xd-rso3SaQZoOFyTSii?$i zXe~3h!R)e{{yO{hjg&nVV1?|pv)A3Yg}aXWW*tkC1y)}t=w$U)QXJtU)-|~ zP&NKCpQVYUBT-o$v0#&Bn9jHn#To=j`+n)@@~z`l_xlO=hCYR*4sNF?8PfXRz!NOk+lP0Kpj#^k{0IyxNn4sV z4jDv{2j&t%E-bx|l991l?`40pr(WQI;vsya)6lnjG<&>-uTt8B@fml>oF%@1!TtAd z+kL41w*cqQ(U&kEb@4$#(64w-JM!$8kHtl{X`Ia|u4}$QATy%sROdCqjdY5(QH4t2 zj?}DOf{^pu>e^x92=F_X8O7>{(FN$15pe9-7S4+UPQzOKQ;z_G4Z#!X#^Ac=Z@^7o z+y%G*4NSPfpqT?X>(_k|TyEh=hb2;v-W6e5HrV<$^wi!|9rmfSYcM#uW&!hVmKb|< zlI7H?`Vwa#In%x^0N5}T73Evp?wuX`{6uVXcyEU z>F*v@l`Ci-D*7GJn<9X3uQz%;p6T_dopMDJ3WzA*l2jE+yIeGQA}j3<3MOX`#ECj9 zRyr*a=H-$JK(r@Q_{n6kv4@EfJ~6nMK%l^;FXHBxUIoGzzi^gR)LtNJ%*al5U|xRn zwb>~(fX4{|#{f>oxS8*#91+5ko|2&4R5&8=HR50GPcsQ4_m+CYCBy1-k1qLqx+}